From terry.manderson@icann.org Thu Apr 8 23:56:11 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE093A67EC for ; Thu, 8 Apr 2010 23:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCTudRV1dJZf for ; Thu, 8 Apr 2010 23:56:11 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 134F83A6767 for ; Thu, 8 Apr 2010 23:56:11 -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; Thu, 8 Apr 2010 23:56:07 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 8 Apr 2010 23:56:06 -0700 Thread-Topic: [lisp] request for adoption of draft-farinacci-lisp-lig-02 as a WG item Thread-Index: AcrLtc6mRmZzql4IME+AEaHfAdafLwL++sqM 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] request for adoption of draft-farinacci-lisp-lig-02 as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 06:56:11 -0000 Workgroup, I note that there has been no objections against draft-farinacci-lisp-lig-0= 2 becoming a workgroup item, and all responses have been supportive of the adoption in this 14 day call. I will close the call here and declare consensus for the adoption. I have further noted the individuals who have said they will provide review and I will be calling on them from time to time to ensure that review does occur. :) Can the authors, as soon as time permits, please post a new WG version as appropriate. Cheers Terry (& Joel) On 25/03/10 10:55 AM, "Terry Manderson" wrote: > Workgroup, >=20 > The authors of draft-farinacci-lisp-lig-02 have requested for it to be > considered as a workgroup item. >=20 > I am opening a 14 day call for comments on the adoption of this document = as > a WG item. >=20 > You will find the ID and past versions at: >=20 > http://tools.ietf.org/html/draft-farinacci-lisp-lig-02 >=20 > Please email the WG list stating that you either accept, or not accept, t= he > item before Friday the 9th April 2010. >=20 > If you email to support the acceptance of this document as a WG item, ple= ase > also indicate if you are able to either contribute to, or review, (or bot= h) > the draft. >=20 > Sitting in silence does not indicate support, please respond appropriatel= y. >=20 >=20 > Cheers > Terry (& Joel) >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Sat Apr 10 07:14:16 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3543A6853 for ; Sat, 10 Apr 2010 07:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.284 X-Spam-Level: X-Spam-Status: No, score=-7.284 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_COMMENT_SAVED_URL=0.114, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhM4BcuTj2o0 for ; Sat, 10 Apr 2010 07:14:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 492193A67A6 for ; Sat, 10 Apr 2010 07:14:12 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: rfcdiff-lig-02-to-ietf-00.html, draft-ietf-lisp-lig-00.txt : 23397, 24854 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP4kwEurR7H+/2dsb2JhbACbRHGgNpkPgl6CLgSDJQ X-IronPort-AV: E=Sophos;i="4.52,182,1270425600"; d="txt'?html'217?scan'217,208,217";a="512617877" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 10 Apr 2010 14:14:01 +0000 Received: from [192.168.2.2] (sjc-vpn3-846.cisco.com [10.21.67.78]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3AEDwhk005152; Sat, 10 Apr 2010 14:13:59 GMT Message-Id: <3071B489-14CC-4D15-BB19-2F0C95D54910@cisco.com> From: Dino Farinacci To: Terry Manderson In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-25-543862682 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Apr 2010 07:13:58 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] request for adoption of draft-farinacci-lisp-lig-02 as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 14:14:16 -0000 --Apple-Mail-25-543862682 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > Workgroup, > > I note that there has been no objections against draft-farinacci- > lisp-lig-02 > becoming a workgroup item, and all responses have been supportive of > the > adoption in this 14 day call. I will close the call here and declare > consensus for the adoption. > > I have further noted the individuals who have said they will provide > review > and I will be calling on them from time to time to ensure that > review does > occur. :) > > Can the authors, as soon as time permits, please post a new WG > version as > appropriate. Done. Diffs and draft enclosed and posted to the ID directory. Dino --Apple-Mail-25-543862682 Content-Disposition: attachment; filename=rfcdiff-lig-02-to-ietf-00.html Content-Type: text/html; x-unix-mode=0600; name="rfcdiff-lig-02-to-ietf-00.html" Content-Transfer-Encoding: 7bit wdiff draft-farinacci-lisp-lig-02.txt draft-ietf-lisp-lig-00.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                              cisco Systems
Expires: August 13, October 12, 2010                                February 9,                                 April 10, 2010

                       LISP Internet Groper (LIG)
                    draft-farinacci-lisp-lig-02.txt
                         draft-ietf-lisp-lig-00

Abstract

   A simple tool called the LISP Internet Groper or 'lig' can be used to
   query the LISP mapping database.  This draft describes how it works.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 13, October 12, 2010.

Copyright Notice

   Copyright (c) 2010 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 BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  5
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Implementation Details . . . . . . . . . . . . . . . . . . . .  9
     5.1.  LISP Router Implementation . . . . . . . . . . . . . . . .  9
     5.2.  Public Domain Host Implementation  . . . . . . . . . . . . 10
   6.  Testing the ALT  . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Future Enhancements  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Deployed Network Diagnostic Tools  . . . . . . . . . . . . . . 14
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   LISP [LISP] specifies an architecture and mechanism for replacing the
   addresses currently used by IP with two separate name spaces:
   Endpoint IDS (EIDs), used within sites, and Routing Locators (RLOCs),
   used on the transit networks that make up the Internet
   infrastructure.  To achieve this separation, the Locator/ID
   Separation Protocol (LISP) defines protocol mechanisms for mapping
   from EIDs to RLOCs.  In addition, LISP assumes the existence of a
   database to store and propagate those mappings globally.  Several
   such databases have been proposed, among them: LISP-CONS [CONS],
   LISP-NERD [NERD], and LISP+ALT [ALT], with LISP+ALT being the system
   that is currently being implemented and deployed on the pilot LISP
   network.

   In conjunction with the various mapping systems, there exists a
   network based API called LISP Map-Server [LISP-MS].  Using Map
   Resolvers and Map Servers allows LISP sites to query and register
   into the database in a uniform way independent of the mapping system
   used.  Sending Map-Requests to Map Resolvers provides a secure
   mechanism mechanism to obtain a Map-Reply containing the
   authoritative EID-to-RLOC mapping for a destination LISP site.

   The 'lig' is a manual management tool to query the mapping database.
   It can be run by all devices which implement LISP, including ITRs,
   ETRs, PTR, Map-Resolvers, Map-Servers, and LISP-ALT routers, as well
   as by a host system at either a LISP-capable or non-LISP-capable
   site.

3.  Definition of Terms

   Map-Server:   a network infrastructure component which learns EID-to-
      RLOC mapping entries from an authoritative source (typically, an
      ETR, though static configuration or another out-of-band mechanism
      may be used).  A Map-Server advertises these mappings in the
      distributed mapping database.

   Map-Resolver:   a network infrastructure component which accepts LISP
      Encapsulated Map-Requests, typically from an ITR, quickly
      determines whether or not the destination IP address is part of
      the EID namespace; if it is not, a Negative Map-Reply is
      immediately returned.  Otherwise, the Map-Resolver finds the
      appropriate EID-to-RLOC mapping by consulting the distributed
      mapping database system.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
      tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
      lookup.  An EID maps to one or more RLOCs.  Typically, RLOCs are
      numbered from topologically-aggregatable blocks that are assigned
      to a site at each point to which it attaches to the global
      Internet; where the topology is defined by the connectivity of
      provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains an destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.

   EID-to-RLOC Cache:   a short-lived, on-demand table in an ITR that
      stores, tracks, and is responsible for timing-out and otherwise
      validating EID-to-RLOC mappings.  This cache is distinct from the
      full "database" of EID-to-RLOC mappings, it is dynamic, local to
      the ITR(s), and relatively small while the database is
      distributed, relatively static, and much more global in scope.

   EID-to-RLOC Database:   a global distributed database that contains
      all known EID-prefix to RLOC mappings.  Each potential ETR
      typically contains a small piece of the database: the EID-to-RLOC
      mappings for the EID prefixes "behind" the router.  These map to
      one of the router's own, globally-visible, IP addresses.

   Encapsulated Map-Request (EMR):   an EMR is a Map-Request message
      which is encapsulated with another LISP header using UDP
      destination port number 4341.  It is used so an ITR, PTR, or a
      system initiating a 'lig' command can get the Map-Request to a
      Map-Resolver by using locater addresses.  When the Map-Request is
      decapsulated by the Map-Resolver it will be forwarded on the ALT
      network to the Map-Server that has injected the EID-prefix for a
      registered site.  The Map-Server will then encapsulate the Map-
      Request in a LISP packet and send it to an an ETR at the site.
      The ETR will then return an authoritative reply to the system that
      initiated the request.

4.  Basic Overview

   When the lig command is run, a Map-Request is sent for a destination
   EID.  When a Map-Reply is returned, the contents are displayed to the
   user.  The information displayed includes:

   o  The EID-prefix for the site the queried destination EID matches.

   o  The locator address of the Map Replier.

   o  The locator-set for the mapping entry which includes the locator
      address, up/down status, priority, and weight of each locator.

   o  An round-trip-time estimate for the Map-Request/Map-Reply
      exchange.

   A possible syntax for a lig command could be:

       lig <destination> [source <source>] [to <map-resolver>]

   Parameter description:

   <destination>:  is either a Fully Qualified Domain Name or a
      destination EID for a remote LISP site.

   source <source>:  is an optional source EID to be inserted in the
      "Source EID" field of the Map-Request.

   to <map-resolver>:  is an optional Fully Qualified Domain Name or
      RLOC address for a Map-Resolver.

   The lig utility has two usage cases.  The first being a way to query
   the mapping database for a particular EID.  And the other to verify
   if a site has registered successfully with a Map-Server.

   The first usage has already been described.  Verifying registration
   is called "ligging yourself".  What occurs is in the lig initiator, a
   Map-Request is sent for one of the EIDs for the lig initiator's site.
   The Map-Request is then returned to one of the ETRs for the lig
   initiating site.  In response to the Map-Request, a Map-Reply is sent
   back to the locator address of the lig initiator (note the Map-Reply
   could be sent by the lig initiator).  That Map-Reply is processed and
   the mapping data for lig initiating site is displayed for the user.
   Refer to the syntax in section Section 5.1 for an implementation of
   "ligging yourself".  However, for host-based implementations within a
   LISP site, "lig self" is less useful since the host may not have an
   RLOC to receive a Map-Reply with.  But, lig can be used in a non-LISP
   site as well as from infrastructure hosts to get mapping information.

5.  Implementation Details

5.1.  LISP Router Implementation

   The cisco LISP prototype implementation has support for lig for IPv4
   and IPv6.  The command line description is:

       lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>]

   This command initiates the LISP Internet Groper.  It is similar to
   the DNS analogue 'dig' but works on the LISP mapping database.  When
   this command is invoked, the local system will send a Map-Request to
   the configured Map-Resolver.  When a Map-Reply is returned, its
   contents will be displayed to the user.  By default, up to 3 Map-
   Requests are sent if no Map-Reply is returned but once a Map-Reply is
   returned no other Map-Requests are sent.  The destination can take a
   DNS name, or an IPv4 or IPv6 EID address.  The <source-eid> can be
   one of the EID addresses assigned to the site in the default VRF.
   When <mr> is specified, then the Map-Request is sent to the address.
   Otherwise, the Map-Request is sent to a configured Map-Resolver.
   When a Map-Resolver is not configured then the Map-Request is sent on
   the ALT network if the local router is attached to the ALT.  When
   "count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent.

   Some sample output:

     titanium-dino# lig titanium-dmm.lisp4.net
     Send map-request to 10.0.0.1 for 192.168.1.1 ...
     Received map-reply from 10.0.0.2 with rtt 0.081468 secs

     Map-cache entry for titanium-dmm.lisp4.net EID 192.168.1.1:
     192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58,
                     via map-reply, auth
       Locator          Uptime    State  Priority/Weight  Packets In/Out
       10.0.0.2         13:59:59  up     1/100            0/14

   Using lig to "lig yourself" is accomplished with the following
   syntax:

       lig {self | self6} [source <source-eid>] [to <mr>] [count <1-5>]

   Use this command for a simple way to see if the site is registered
   with the mapping database system.  The destination-EID address for
   the Map-Request will be the first configured EID-prefix for the site
   (with the host-bits set to 0).  For example, if the site's EID-prefix
   is 192.168.1.0/24, the destination-EID for the Map-Request is
   192.168.1.0.  The source-EID address for the Map-Request will also be
   192.168.1.0 (in this example) and the Map-Request is sent to the
   configured Map-Resolver.  If the Map-Resolver and Map-Server are the
   same LISP system, then the "lig self" is testing if the Map-Resolver
   can "turn back a Map-Request to the site".  If another Map-Resolver
   is used, it can test that the site's EID-prefix has been injected
   into the ALT infrastructure in which case the lig Map-Request is
   processed by the Map-Resolver, propagated through each ALT router hop
   to the site's registered Map-Server.  Then the Map-Server returns the
   Map-Request to originating site.  In which case, an xTR at the
   originating site sends a Map-Reply to the source of the Map-Request
   (could be itself or another xTR for the site).  All other command
   parameters are described above.  Using "lig self6" tests for
   registering of IPv6 EID- prefixes.

   Some sample output for ligging yourself:

     rutile# lig self
     Send loopback map-request to 10.0.0.1 for 192.168.2.0 ...
     Received map-reply from 10.0.0.3 with rtt 0.001592 secs

     Map-cache entry for EID 192.168.2.0:
     192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57
                     via map-reply, self
       Locator       Uptime    State  Priority/Weight  Packets In/Out
       10.0.0.3      00:00:02  up     1/100            0/0

     titanium-simlo# lig self6
     Send loopback map-request to 10.0.0.1 for 192:168:1:: ...
     Received map-reply from 10::1 with rtt 0.044372 secs

     Map-cache entry for EID 192:168:1:::
     192:168:1::/48, uptime: 00:00:01, expires: 23:59:58
                        via map-reply, self
       Locator          Uptime    State  Priority/Weight  Packets In/Out
       10.0.0.3         00:00:01  up     1/100            0/0
       10::1            00:00:01  up     2/0              0/0

5.2.  Public Domain Host Implementation

   There is a public domain implementation that can run on any x86 based
   system.  The only requirement is that the system that initiates lig
   must have an address assigned from the locator namespace.

       lig [-d] <eid> -m <map-resolver> [-c <count>] [-t <timeout>]

   Parameter description:

   -d:  prints additional protocol debug output.

   <eid>:  is the destination EID or FQDN of a LISP host.

   -m <map-resolver>:  is the RLOC address or FQDN of a Map-Resolver.

   -c <count>:  the number of Map-Requests to send before the first Map-
      Reply is returned.  The default value is 3.  The range is from 1
      to 5.

   -t <timeout>:  the amount of time, in seconds, before another Map-
      Request is sent when no Map-Reply is returned.  The default value
      is 2 seconds.  The range is from 1 to 5.

   Some sample output:

     % lig titanium-test.lisp4.net -m 10.0.0.1
     Send map-request to 10.0.0.1 for 192.168.1.1 ...
     Received map-reply from 10.0.0.2 with rtt 0.04000 sec

     Mapping entry for EID 192.168.1.1:
     192.168.1.0/24, record ttl: 60
      Locator           State     Priority/Weight
      10.0.0.1          up        1/25
      10.0.0.2          up        1/25
      10.0.0.3          up        1/25
      10.0.0.4          up        2/25

   The public domain implementation of lig is available at
   http://github.com/davidmeyer/lig.

6.  Testing the ALT

   There are cases where a Map-Reply is returned from a lig request but
   the user doesn't really know how much of the mapping infrastructure
   was tested.  There are two cases to consider, avoiding the ALT and
   traversing the ALT.

   When an ITR sends a lig request to its Map-Resolver for a
   destination-EID, the Map-Resolver could also be configured as a Map-
   Server.  And if the destination-EID is for a site that registers with
   this Map-Server, the Map-Request is sent to the site directly without
   testing the ALT.  This occurs because the Map-Server is the source of
   the advertisement for the site's EID-prefix.  So if the map-reply is
   returned to the lig requesting site, you cannot be sure that other
   sites can reach the same destination-EID.

   If a Map-Resolver is used that is not a Map-Server for the EID-prefix
   being sought, then the ALT infrastructure can be tested.  This test
   case is testing the functionality of the Map-Resolver, traversal of
   the ALT (testing BGP-over-GRE), and the Map-Server.

   It is recommended that users issue 2 lig requests, each which send
   Map-Requests to different Map-Resolvers.

   The network can have a LISP-ALT router deployed as a "ALT looking-
   glass" node.  This type of router has BGP peering sessions with other
   ALT routers where it does not inject any EID-prefixes into the ALT
   but just learns ones advertised by other ALT routers and Map-Servers.
   This router is configured as a Map-Resolver.  Lig users can point to
   the ALT looking-glass router for Map-Resolver services via the "to
   <map-resolver>" parameter on the lig command.  The ALT looking-glass
   node can be used to lig other sites as well as your own site.  When
   the ALT looking-glass is used as a Map-Resolver, you can be assured
   the ALT network is being tested.

7.  Future Enhancements

   When negative Map-Replies have been further developed and
   implemented, lig should be modified appropriately to process and
   clearly indicate how and why a negative Map-Reply was received.
   Negative Map-Replies could be sent in the following cases, the lig
   request was initiated for a non-EID address or the Map-Request
   initiated by lig request is being rejected due to rate-limiting on
   the replier.

8.  Deployed Network Diagnostic Tools

   There is an web-based interface to do auto-polling with lig on the
   back-end for most of the LISP sites on the LISP test network.  The
   web-page can be accessed at http://www.lisp4.net/status.

   There is a LISP site monitoring web-based interface that can be found
   at http://www.lisp4.net/lisp-site.

   At http://baldomar.ccaba.upc.edu/lispmon, written by the folks at
   UPC, shows a geographical map indicating where each LISP site
   resides.

9.  Security Considerations

   The use of lig does not affect the security of the LISP
   infrastructure as it is simply a tool that facilities diagnostic
   querying.  See [LISP], [ALT], and [LISP-MS] for descriptions of the
   security properties of the LISP infrastructure.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietfr-lisp-alt-03.txt
              draft-ietfr-lisp-alt-04.txt (work in progress),
              February
              April 2010.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network  Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-06.txt
              draft-ietf-lisp-07.txt (work in progress), April 2010.

   [LISP-LIG]
              Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-02.txt (work in progress), January
              February 2010.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-04.txt
              draft-ietf-lisp-ms-05.txt (work in progress),
              October 2009. April 2010.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-04.txt (work in progress),
              April 2008.

Appendix A.  Acknowledgments

   Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and
   Vince Fuller for providing critical feedback on the lig design and
   prototype implementations.  These folks as well as all the people on
   lisp-beta@external.cisco.com who tested lig functionality and
   continue to do so, we extend our sincere thanks.

   This working group draft is based on individual contribution
   draft-farinacci-lisp-lig-02.txt [LISP-LIG].

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com
--Apple-Mail-25-543862682 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-25-543862682 Content-Disposition: attachment; filename=draft-ietf-lisp-lig-00.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-lig-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental cisco Systems Expires: October 12, 2010 April 10, 2010 LISP Internet Groper (LIG) draft-ietf-lisp-lig-00 Abstract A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 12, 2010. Copyright Notice Copyright (c) 2010 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 Farinacci & Meyer Expires October 12, 2010 [Page 1] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 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 BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Implementation Details . . . . . . . . . . . . . . . . . . . . 9 5.1. LISP Router Implementation . . . . . . . . . . . . . . . . 9 5.2. Public Domain Host Implementation . . . . . . . . . . . . 10 6. Testing the ALT . . . . . . . . . . . . . . . . . . . . . . . 12 7. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 13 8. Deployed Network Diagnostic Tools . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Farinacci & Meyer Expires October 12, 2010 [Page 2] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci & Meyer Expires October 12, 2010 [Page 3] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 2. Introduction LISP [LISP] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: Endpoint IDS (EIDs), used within sites, and Routing Locators (RLOCs), used on the transit networks that make up the Internet infrastructure. To achieve this separation, the Locator/ID Separation Protocol (LISP) defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings globally. Several such databases have been proposed, among them: LISP-CONS [CONS], LISP-NERD [NERD], and LISP+ALT [ALT], with LISP+ALT being the system that is currently being implemented and deployed on the pilot LISP network. In conjunction with the various mapping systems, there exists a network based API called LISP Map-Server [LISP-MS]. Using Map Resolvers and Map Servers allows LISP sites to query and register into the database in a uniform way independent of the mapping system used. Sending Map-Requests to Map Resolvers provides a secure mechanism mechanism to obtain a Map-Reply containing the authoritative EID-to-RLOC mapping for a destination LISP site. The 'lig' is a manual management tool to query the mapping database. It can be run by all devices which implement LISP, including ITRs, ETRs, PTR, Map-Resolvers, Map-Servers, and LISP-ALT routers, as well as by a host system at either a LISP-capable or non-LISP-capable site. Farinacci & Meyer Expires October 12, 2010 [Page 4] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 3. Definition of Terms Map-Server: a network infrastructure component which learns EID-to- RLOC mapping entries from an authoritative source (typically, an ETR, though static configuration or another out-of-band mechanism may be used). A Map-Server advertises these mappings in the distributed mapping database. Map-Resolver: a network infrastructure component which accepts LISP Encapsulated Map-Requests, typically from an ITR, quickly determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is immediately returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting the distributed mapping database system. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings, it is dynamic, local to the ITR(s), and relatively small while the database is distributed, relatively static, and much more global in scope. Farinacci & Meyer Expires October 12, 2010 [Page 5] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 EID-to-RLOC Database: a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. Encapsulated Map-Request (EMR): an EMR is a Map-Request message which is encapsulated with another LISP header using UDP destination port number 4341. It is used so an ITR, PTR, or a system initiating a 'lig' command can get the Map-Request to a Map-Resolver by using locater addresses. When the Map-Request is decapsulated by the Map-Resolver it will be forwarded on the ALT network to the Map-Server that has injected the EID-prefix for a registered site. The Map-Server will then encapsulate the Map- Request in a LISP packet and send it to an an ETR at the site. The ETR will then return an authoritative reply to the system that initiated the request. Farinacci & Meyer Expires October 12, 2010 [Page 6] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 4. Basic Overview When the lig command is run, a Map-Request is sent for a destination EID. When a Map-Reply is returned, the contents are displayed to the user. The information displayed includes: o The EID-prefix for the site the queried destination EID matches. o The locator address of the Map Replier. o The locator-set for the mapping entry which includes the locator address, up/down status, priority, and weight of each locator. o An round-trip-time estimate for the Map-Request/Map-Reply exchange. A possible syntax for a lig command could be: lig [source ] [to ] Parameter description: : is either a Fully Qualified Domain Name or a destination EID for a remote LISP site. source : is an optional source EID to be inserted in the "Source EID" field of the Map-Request. to : is an optional Fully Qualified Domain Name or RLOC address for a Map-Resolver. The lig utility has two usage cases. The first being a way to query the mapping database for a particular EID. And the other to verify if a site has registered successfully with a Map-Server. The first usage has already been described. Verifying registration is called "ligging yourself". What occurs is in the lig initiator, a Map-Request is sent for one of the EIDs for the lig initiator's site. The Map-Request is then returned to one of the ETRs for the lig initiating site. In response to the Map-Request, a Map-Reply is sent back to the locator address of the lig initiator (note the Map-Reply could be sent by the lig initiator). That Map-Reply is processed and the mapping data for lig initiating site is displayed for the user. Refer to the syntax in section Section 5.1 for an implementation of "ligging yourself". However, for host-based implementations within a LISP site, "lig self" is less useful since the host may not have an RLOC to receive a Map-Reply with. But, lig can be used in a non-LISP Farinacci & Meyer Expires October 12, 2010 [Page 7] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 site as well as from infrastructure hosts to get mapping information. Farinacci & Meyer Expires October 12, 2010 [Page 8] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 5. Implementation Details 5.1. LISP Router Implementation The cisco LISP prototype implementation has support for lig for IPv4 and IPv6. The command line description is: lig [source ] [to ] [count <1-5>] This command initiates the LISP Internet Groper. It is similar to the DNS analogue 'dig' but works on the LISP mapping database. When this command is invoked, the local system will send a Map-Request to the configured Map-Resolver. When a Map-Reply is returned, its contents will be displayed to the user. By default, up to 3 Map- Requests are sent if no Map-Reply is returned but once a Map-Reply is returned no other Map-Requests are sent. The destination can take a DNS name, or an IPv4 or IPv6 EID address. The can be one of the EID addresses assigned to the site in the default VRF. When is specified, then the Map-Request is sent to the address. Otherwise, the Map-Request is sent to a configured Map-Resolver. When a Map-Resolver is not configured then the Map-Request is sent on the ALT network if the local router is attached to the ALT. When "count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent. Some sample output: titanium-dino# lig titanium-dmm.lisp4.net Send map-request to 10.0.0.1 for 192.168.1.1 ... Received map-reply from 10.0.0.2 with rtt 0.081468 secs Map-cache entry for titanium-dmm.lisp4.net EID 192.168.1.1: 192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58, via map-reply, auth Locator Uptime State Priority/Weight Packets In/Out 10.0.0.2 13:59:59 up 1/100 0/14 Using lig to "lig yourself" is accomplished with the following syntax: lig {self | self6} [source ] [to ] [count <1-5>] Use this command for a simple way to see if the site is registered with the mapping database system. The destination-EID address for the Map-Request will be the first configured EID-prefix for the site (with the host-bits set to 0). For example, if the site's EID-prefix Farinacci & Meyer Expires October 12, 2010 [Page 9] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 is 192.168.1.0/24, the destination-EID for the Map-Request is 192.168.1.0. The source-EID address for the Map-Request will also be 192.168.1.0 (in this example) and the Map-Request is sent to the configured Map-Resolver. If the Map-Resolver and Map-Server are the same LISP system, then the "lig self" is testing if the Map-Resolver can "turn back a Map-Request to the site". If another Map-Resolver is used, it can test that the site's EID-prefix has been injected into the ALT infrastructure in which case the lig Map-Request is processed by the Map-Resolver, propagated through each ALT router hop to the site's registered Map-Server. Then the Map-Server returns the Map-Request to originating site. In which case, an xTR at the originating site sends a Map-Reply to the source of the Map-Request (could be itself or another xTR for the site). All other command parameters are described above. Using "lig self6" tests for registering of IPv6 EID- prefixes. Some sample output for ligging yourself: rutile# lig self Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... Received map-reply from 10.0.0.3 with rtt 0.001592 secs Map-cache entry for EID 192.168.2.0: 192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57 via map-reply, self Locator Uptime State Priority/Weight Packets In/Out 10.0.0.3 00:00:02 up 1/100 0/0 titanium-simlo# lig self6 Send loopback map-request to 10.0.0.1 for 192:168:1:: ... Received map-reply from 10::1 with rtt 0.044372 secs Map-cache entry for EID 192:168:1::: 192:168:1::/48, uptime: 00:00:01, expires: 23:59:58 via map-reply, self Locator Uptime State Priority/Weight Packets In/Out 10.0.0.3 00:00:01 up 1/100 0/0 10::1 00:00:01 up 2/0 0/0 5.2. Public Domain Host Implementation There is a public domain implementation that can run on any x86 based system. The only requirement is that the system that initiates lig must have an address assigned from the locator namespace. Farinacci & Meyer Expires October 12, 2010 [Page 10] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 lig [-d] -m [-c ] [-t ] Parameter description: -d: prints additional protocol debug output. : is the destination EID or FQDN of a LISP host. -m : is the RLOC address or FQDN of a Map-Resolver. -c : the number of Map-Requests to send before the first Map- Reply is returned. The default value is 3. The range is from 1 to 5. -t : the amount of time, in seconds, before another Map- Request is sent when no Map-Reply is returned. The default value is 2 seconds. The range is from 1 to 5. Some sample output: % lig titanium-test.lisp4.net -m 10.0.0.1 Send map-request to 10.0.0.1 for 192.168.1.1 ... Received map-reply from 10.0.0.2 with rtt 0.04000 sec Mapping entry for EID 192.168.1.1: 192.168.1.0/24, record ttl: 60 Locator State Priority/Weight 10.0.0.1 up 1/25 10.0.0.2 up 1/25 10.0.0.3 up 1/25 10.0.0.4 up 2/25 The public domain implementation of lig is available at http://github.com/davidmeyer/lig. Farinacci & Meyer Expires October 12, 2010 [Page 11] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 6. Testing the ALT There are cases where a Map-Reply is returned from a lig request but the user doesn't really know how much of the mapping infrastructure was tested. There are two cases to consider, avoiding the ALT and traversing the ALT. When an ITR sends a lig request to its Map-Resolver for a destination-EID, the Map-Resolver could also be configured as a Map- Server. And if the destination-EID is for a site that registers with this Map-Server, the Map-Request is sent to the site directly without testing the ALT. This occurs because the Map-Server is the source of the advertisement for the site's EID-prefix. So if the map-reply is returned to the lig requesting site, you cannot be sure that other sites can reach the same destination-EID. If a Map-Resolver is used that is not a Map-Server for the EID-prefix being sought, then the ALT infrastructure can be tested. This test case is testing the functionality of the Map-Resolver, traversal of the ALT (testing BGP-over-GRE), and the Map-Server. It is recommended that users issue 2 lig requests, each which send Map-Requests to different Map-Resolvers. The network can have a LISP-ALT router deployed as a "ALT looking- glass" node. This type of router has BGP peering sessions with other ALT routers where it does not inject any EID-prefixes into the ALT but just learns ones advertised by other ALT routers and Map-Servers. This router is configured as a Map-Resolver. Lig users can point to the ALT looking-glass router for Map-Resolver services via the "to " parameter on the lig command. The ALT looking-glass node can be used to lig other sites as well as your own site. When the ALT looking-glass is used as a Map-Resolver, you can be assured the ALT network is being tested. Farinacci & Meyer Expires October 12, 2010 [Page 12] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 7. Future Enhancements When negative Map-Replies have been further developed and implemented, lig should be modified appropriately to process and clearly indicate how and why a negative Map-Reply was received. Negative Map-Replies could be sent in the following cases, the lig request was initiated for a non-EID address or the Map-Request initiated by lig request is being rejected due to rate-limiting on the replier. Farinacci & Meyer Expires October 12, 2010 [Page 13] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 8. Deployed Network Diagnostic Tools There is an web-based interface to do auto-polling with lig on the back-end for most of the LISP sites on the LISP test network. The web-page can be accessed at http://www.lisp4.net/status. There is a LISP site monitoring web-based interface that can be found at http://www.lisp4.net/lisp-site. At http://baldomar.ccaba.upc.edu/lispmon, written by the folks at UPC, shows a geographical map indicating where each LISP site resides. Farinacci & Meyer Expires October 12, 2010 [Page 14] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 9. Security Considerations The use of lig does not affect the security of the LISP infrastructure as it is simply a tool that facilities diagnostic querying. See [LISP], [ALT], and [LISP-MS] for descriptions of the security properties of the LISP infrastructure. Farinacci & Meyer Expires October 12, 2010 [Page 15] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietfr-lisp-alt-04.txt (work in progress), April 2010. [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-03.txt (work in progress), November 2007. [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-07.txt (work in progress), April 2010. [LISP-LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-farinacci-lisp-lig-02.txt (work in progress), February 2010. [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-05.txt (work in progress), April 2010. [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-04.txt (work in progress), April 2008. Farinacci & Meyer Expires October 12, 2010 [Page 16] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 Appendix A. Acknowledgments Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and Vince Fuller for providing critical feedback on the lig design and prototype implementations. These folks as well as all the people on lisp-beta@external.cisco.com who tested lig functionality and continue to do so, we extend our sincere thanks. This working group draft is based on individual contribution draft-farinacci-lisp-lig-02.txt [LISP-LIG]. Farinacci & Meyer Expires October 12, 2010 [Page 17] =0C Internet-Draft LISP Internet Groper (LIG) April 2010 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Dave Meyer cisco Systems 170 Tasman Drive San Jose, CA USA Email: dmm@cisco.com Farinacci & Meyer Expires October 12, 2010 [Page 18] =0C --Apple-Mail-25-543862682 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > > Cheers > Terry (& Joel) > > On 25/03/10 10:55 AM, "Terry Manderson" > wrote: > >> Workgroup, >> >> The authors of draft-farinacci-lisp-lig-02 have requested for it to >> be >> considered as a workgroup item. >> >> I am opening a 14 day call for comments on the adoption of this >> document as >> a WG item. >> >> You will find the ID and past versions at: >> >> http://tools.ietf.org/html/draft-farinacci-lisp-lig-02 >> >> Please email the WG list stating that you either accept, or not >> accept, the >> item before Friday the 9th April 2010. >> >> If you email to support the acceptance of this document as a WG >> item, please >> also indicate if you are able to either contribute to, or review, >> (or both) >> the draft. >> >> Sitting in silence does not indicate support, please respond >> appropriately. >> >> >> Cheers >> Terry (& Joel) >> >> _______________________________________________ >> 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 --Apple-Mail-25-543862682-- From root@core3.amsl.com Sat Apr 10 09:15:02 2010 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2ED2E3A6926; Sat, 10 Apr 2010 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100410161502.2ED2E3A6926@core3.amsl.com> Date: Sat, 10 Apr 2010 09:15:02 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-lig-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 16:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Internet Groper (LIG) Author(s) : D. Farinacci, D. Meyer Filename : draft-ietf-lisp-lig-00.txt Pages : 18 Date : 2010-04-10 A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-lig-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-lig-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-10091443.I-D@ietf.org> --NextPart-- From dino@cisco.com Tue Apr 13 08:32:15 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6791B3A6993 for ; Tue, 13 Apr 2010 08:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.941 X-Spam-Level: X-Spam-Status: No, score=-8.941 tagged_above=-999 required=5 tests=[AWL=1.658, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcJ4qdCsoPNP for ; Tue, 13 Apr 2010 08:32:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ACC9E3A67E3 for ; Tue, 13 Apr 2010 08:32:14 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYGAE8rxEurR7H+/2dsb2JhbACPaYtfcaNAmhqFDQSDJw X-IronPort-AV: E=Sophos;i="4.52,198,1270425600"; d="scan'208";a="514150293" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 13 Apr 2010 15:32:09 +0000 Received: from [192.168.1.7] (sjc-vpn4-1316.cisco.com [10.21.85.35]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3DFVL5o023959 for ; Tue, 13 Apr 2010 15:32:09 GMT Message-Id: <6021B7B0-E9C2-4851-8F77-CD98BA6C7A85@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Apr 2010 08:32:09 -0700 References: <20100413153046.A18613A6A3F@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [lisp] Fwd: New Version Notification for draft-farinacci-lisp-lcaf-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 15:32:15 -0000 This might be of interest to the working group. Thanks, Dino Begin forwarded message: > From: IETF I-D Submission Tool > Date: April 13, 2010 8:30:45 AM PDT > To: dino@cisco.com > Cc: dmm@cisco.com, job@instituut.net > Subject: New Version Notification for draft-farinacci-lisp-lcaf-00 > > > A new version of I-D, draft-farinacci-lisp-lcaf-00.txt has been > successfully submitted by Dino Farinacci and posted to the IETF > repository. > > Filename: draft-farinacci-lisp-lcaf > Revision: 00 > Title: LISP Canonical Address Format (LCAF) > Creation_date: 2010-04-13 > WG ID: Independent Submission > Number_of_pages: 16 > > Abstract: > This draft defines a canonical address format encoding used in LISP > control messages and in the encoding of lookup keys for the LISP > Mapping Database System. > > > > The IETF Secretariat. > > From dino@cisco.com Tue Apr 13 08:41:13 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673653A6A26 for ; Tue, 13 Apr 2010 08:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9174jwAUc9nx for ; Tue, 13 Apr 2010 08:41:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B56193A659A for ; Tue, 13 Apr 2010 08:41:12 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: lisp-ietf-sna-multicast-draft.ppt, rfcdiff-lisp-multicast-02-to-03.html, draft-ietf-lisp-multicast-03.txt : 79872, 73542, 72136 X-IronPort-AV: E=Sophos;i="4.52,198,1270425600"; d="ppt'32?txt'32?html'32,217?scan'32,217,208,217,32";a="250270336" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2010 15:41:07 +0000 Received: from [192.168.1.7] (sjc-vpn4-1316.cisco.com [10.21.85.35]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o3DFf5vR025113; Tue, 13 Apr 2010 15:41:05 GMT Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-4-808289125 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Apr 2010 08:41:05 -0700 X-Mailer: Apple Mail (2.936) Cc: Stig Venaas , David Meyer Subject: [lisp] Proposed changes to draft-ietf-lisp-multicast-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 15:41:13 -0000 --Apple-Mail-4-808289125 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Enclosed you will find: (1) Slide-set from Anaheim IETF where I presented proposed changes to the next revision of the LISP-Multicast draft. (2) A 02-to-03 diff file with the proposed changes. (3) The -03 draft itself. Here are the proposed changes: A.1. Changes to draft-ietf-lisp-multicast-03.txt o Posted April 2010. o Added section 8.1.2 to address Joel Halpern's comment about receiver sites joining the same source site via 2 different RLOCs, each being a separate ITR. o Change all occurences of "mPTR" to "mPETR" to become more consistent with uPITRs and uPETRs described in [INTWORK]. That is, an mPETR is a LISP multicast router that decapsulates multicast packets that are encapsulated to it by ITRs in multicast source sites. o Add clarifications in section 9 about how homogeneous multicast encapsulation should occur. As well as describing in this section, how to deal with mixed-locator sets to avoid heterogeneous encapsulation. o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges of LISP global multicast network. ---- Since the number of changes are small, We would like to have review comments back by Friday, close of business PDT. If we receive no comments, or the comments are resolved to the commentor's satisfaction, we will post on Friday. Thanks, Dino/Dave/JohnZ/Stig --Apple-Mail-4-808289125 Content-Disposition: attachment; filename=lisp-ietf-sna-multicast-draft.ppt Content-Type: application/vnd.ms-powerpoint; x-mac-creator=50505433; x-unix-mode=0644; x-mac-type=534C4438; name="lisp-ietf-sna-multicast-draft.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAlAAAAAAAAAAA EAAAmAAAAAEAAAD+////AAAAAJYAAACVAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A UgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgAFAP//////////AQAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAAAAtjx/QMfK AVAAAABABgAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAAKvsAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEEAAAA//////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRAAAAnCcAAAAAAAAFAEQAbwBjAHUAbQBlAG4A dABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMBQAAAAAAAGYA AAD9////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAs AAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoA AAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAA AEkAAABKAAAASwAAAEwAAABNAAAATgAAAGkAAAD9////ZQAAAFIAAABTAAAAVAAAAFUAAABWAAAA VwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAAD+ ////eQAAAP7////+/////v///2oAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMA AAB0AAAAdQAAAHYAAAB3AAAAeAAAAHoAAABoAAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAADwDo AyAvAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAUAAAAAAAAAAQAAAAABAAEPAPID rgEAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB+QAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAA/78wwwAAEABafEDY/78Ix/+/MMP/v8j1kXyc9gAAAAAAAATgEAC3D0QA AABDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAbgAAAP+/MMMAABAAWnxA2P+/CMf/vzDD/7/I 9ZF8nPYAAAAAAAAE4CAAtw9EAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAUwAAAG4AAAD/vzDD AAAQAFp8QNj/vwjH/78ww/+/yPWRfJz2AAAAAAAABOAAAKQPCgAAAIAAYAAAAP////8AAKUPDAAA AAAAAAguAAAAAgAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAA AABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAA BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEUAYAAA8AAPBIBgAAAAAG8MAD AAAC3AEAdwAAACUAAAAJAAAAAQAAAAkAAAAEAAAABAAAAAgAAAAHAAAABgAAAAgAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAACUAAAAAAAAABAAAAAAAAAAFAAAA AAAAAAQAAAAAAAAABQAAAAAAAAAGAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAYAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAEgAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAA AAYAAAAAAAAACQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAfAAAAAAAAAB0AAAAAAAAA BAAAAAIAAAAJAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAXAAAAAAAAAB0AAAAAAAAAEQAAAAAAAAAc AAAAAAAAABkAAAAAAAAABgAAAAAAAABCAAAAAAAAAAQAAAAAAAAAfQAAAAAAAAAFAAAAAAAAAAgA AAAAAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAACgAA AAAAAAAEAAAAAAAAAFkAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAFAAAA AAAAAAQAAAAAAAAABgAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAHAAAAAAAAAAUAAAAAAAAABAAAAAAA AAAEAAAAAAAAABcAAAAAAAAAHQAAAAAAAAAsAAAAAAAAAC8AAAAAAAAAQwAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAEQAAAAAAAAArAAAAAAAAAAQAAAAAAAAABAAAAAAAAABn AAAABQAAAAQAAAAJAAAABAAAAAAAAAAEAAAAAAAAACsAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAMAAAAEAAAABwAAAAQAAAAjBgvwTAIA AIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAgAAAIgAAAAAAIkAAAAAAL8AAAANAAwB9AAAEA0B AAAAIA4BAAAAIIEBBAAACIMBAAAACL8BEAAQAMABAQAACMEBAAABAMIB////AMMBAAAAIMQBAAAA AMVBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4B AAAAAM/BAAAAANcBAgAAAP8BDgAOAAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQCAAABAAcCAAAA AAgCAAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABEC AAAAAD8CAAABAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAA EIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcC AAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5 /9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoC cJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4B AIUDAAAAAIYDfL4BAIcDAAAAADAAGvEMAAAA/wAAAP//AADWAJMAQAAe8RAAAADWAJMA/wAAAP// ///3AAAQHwDwDzgAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAAAADzAxQAAAApAAAAAAAA AAAAAAABAACAAAAAAA8A0AchHAAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAfQAAAGQAAAB9 AAAAZAAAAADA6AEAAAAAAAAAAFDD/78AAAAAwJ9gfED9//+Q////AQAAAHAA+wMIAAAAAAAAAHAI AABwAPsDCAAAAAEAAABACwAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ACAQ8AAAAAAD9 AzQAAABCAAAAZAAAAEIAAABkAAAAsMP/vykAAACwNVh8AAAAABQAAAAAypo7AAAAAAAAAAAAAAAA HwAUBBwAAAAAABUEFAAAALoddewAypo7Mk7NyQDKmjsAAgABHwAHBDwAAAAAAP0DNAAAACEAAABk AAAAIQAAAGQAAACww/+/KQAAALA1WHwAAAAAuh117ADKmjsAAAAAAAAAAAABAAEfABMEPAAAAAAA /QM0AAAAZAAAAGQAAABkAAAAZAAAALDD/78pAAAAsDVYfAAAAAC6HXXsAMqaOwAAAAAAAAAAAAEA AQ8AiBOeGgAADwCKE5gBAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTeAEAAA8Asw9wAQAA AACvDwgAAAAAAQAABgAAAAAAsQ8gAAAAAAAABAAAAAAAAAAEAQAAAAAAAAQCAAAAAAAABAMAAAAQ AK8PCAAAAAABAAAFAAAAAACxDxgAAAAAAAAEAAAAAAAAAAQBAAAAAAAABAIAAAAQAK8PCAAAAAEB AAABAAAAAACxD3gAAAAAAAAEAAAAAAAAAAQBAAAAAAAABAIAAAAAAAAEAwAAAAAAAAQEAAAAAAAA BAUAAAAAAAAEBgAAAAAAAAQHAAAAAAAABAgAAAAAAAAECQAAAAAAAAQKAAAAAAAABAsAAAAAAAAE DAAAAAAAAAQNAAAAAAAABA4AAAAQAK8PCAAAABgBAAABAAAAAACxD2AAAAAAAAAEAAAAAAAAAAQB AAAAAAAABAIAAAAAAAAEAwAAAAAAAAQEAAAAAAAABAUAAAAAAAAEBgAAAAAAAAQHAAAAAAAABAgA AAAAAAAECQAAAAAAAAQKAAAAAAAABAsAAAAPAIoTpgIAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAA AIsTiAIAAA8Arg+AAgAAAACvDwgAAAAAAQAABgAAAAAArA9AAAAAAAAAAAAAEAAAAAAAAAAAAAAA AAAAABAAAQAAAAAAAAAAAAAAAAAQAAIAAAAAAAAAAAAAAAAAEAADAAAAAAAAABAArw8IAAAAAAEA AAUAAAAAAKwPMAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAA AAAAABAArw8IAAAAAQEAAAEAAAAAAKwP8AAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAA AAAAAAAAAAAAEAACAAAAAAAAAAAAAAAAABAAAwAAAAAAAAAAAAAAAAAQAAQAAAAAAAAAAAAAAAAA EAAFAAAAAAAAAAAAAAAAABAABgAAAAAAAAAAAAAAAAAQAAcAAAAAAAAAAAAAAAAAEAAIAAAAAAAA AAAAAAAAABAACQAAAAAAAAAAAAAAAAAQAAoAAAAAAAAAAAAAAAAAEAALAAAAAAAAAAAAAAAAABAA DAAAAAAAAAAAAAAAAAAQAA0AAAAAAAAAAAAAAAAAEAAOAAAAAAAAABAArw8IAAAAGAEAAAEAAAAA AKwPwAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAA AAAAABAAAwAAAAAAAAAAAAAAAAAQAAQAAAAAAAAAAAAAAAAAEAAFAAAAAAAAAAAAAAAAABAABgAA AAAAAAAAAAAAAAAQAAcAAAAAAAAAAAAAAAAAEAAIAAAAAAAAAAAAAAAAABAACQAAAAAAAAAAAAAA AAAQAAoAAAAAAAAAAAAAAAAAEAALAAAAAAAAAA8AihNoAAAAAAC6DxQAAABfAF8AXwBQAFAAVAAy ADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkXNAAAAAAAAAAAAAAAAAAAAFgCAAAAAQEAAQEAAAEB AQABAAAAAAAAAAjHAAAAAAAAAAAAAIACAeAPAIoT2BUAAAAAug8WAAAAXwBfAF8AUABQAFQATQBh AGMAMQAxAAAAixOyFQAAQAAaEGYFAAAFAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAAB AAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIA AAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAA AAMAAAABAAAECQAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQA eQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAA AAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAA AAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAA AQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAE CQAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABU AHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkA EQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAA AAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAA AAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAECQAAAAoAQQBy AGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcA cgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAECQAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAECQAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAHBAUAQAAAAAACAwBAAAAAAAC AAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEA AAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAA AGhuYW1kAAAAYAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAA AwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAE ABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwAbECAPAAAAAK8PCAAAAAABAAAG AAAAAAAZECgBAAAAAAAAAAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAA AAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAAB AwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJ AAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkA YwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQALAAAAAABBwAAAAYAAAAAAAAAAAAE AAAADgAJABEAAAAaAAEAAAAAAAAAABAArw8IAAAAAAEAAAUAAAAAABkQJAEAAAAAAAAAAAAIFAEA AAAAAAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEA AAAAAQAAAAAAAAEBAAAAAQEAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAA AAEFAAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBu AHMAIABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIA cAAuAAAAAAEGAAAABAAgAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAQAK8P CAAAAAEBAAABAAAAAAAZEMwGAAAAAAAAAAAAAAAAAAgUAQAAAAAAAgAAARQAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAAAGgAAAACAAAA BAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAACAAAAAMAAAAB AAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAEABgAAAAAAQcA AAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAA AAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAAB AgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAE AAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEA AAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQAGAAAAAABBwAA AAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIFAEAAAAAAAIAAAEUAAAAAAAAABQAAAAgAAAA AQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAEC AAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAcG5hbWQAAABoAAAAAgAAAAQA AAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAAAAgAAAADAAAAAQAA BAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIAcAAuAAAAAAEGAAAABAAYAAAAAAEHAAAA BgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAAAAAAAAAAAAAAAAgUAQAAAAAAAgAAARQAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAA AGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAA CAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAE ABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAAAAAAAAAAAAAAAAAACBQBAAAA AAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAA AAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAAB BQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBz ACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAA LgAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIFAEAAAAA AAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBuAHMA IABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIAcAAu AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAQAK8PCAAA ABgBAAABAAAAAAAZEKgFAAAAAAAAAAAAAAAAAAAAAAAAAAAACBQBAAAAAAACAAABFAAAAAAAAAAU AAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEA AAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAA AAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAA AwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQAHAAA AAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAAAAAAAAAAAAgUAQAAAAAAAgAAARQA AAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAA AQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFt ZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAA AAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYA AAAEACAAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACBQBAAAAAAACAAABFAAA AAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAAB AQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1k AAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAA AAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAA AAQAIAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIFAEAAAAAAAIAAAEUAAAA AAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEB AAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAcG5hbWQA AABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAA AAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIAcAAuAAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgUAQAAAAAAAgAAARQAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAA AGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAA CAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAE ACAAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAAAD8A2Q8MAAAAAADaDwQAAAAA AC0ATwDZDwwAAAAAANoPBAAAAAAAPQAPAPAP5QkAAAAA8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAA AAAAAJ8PBAAAAAYAAAAAAKgPMAAAAERyYWZ0IFN0YXR1cyBVcGRhdGULZHJhZnQtaWV0Zi1saXNw LW11bHRpY2FzdC0wMgAAoQ8+AAAAMQAAAAAAABAAAIIAFAAAAAAAAAABAAAAAARDABAEAgACACQA GwAAAAAIQwAQCAIAAgAkAAEAAAAADAAAEAwQAJ8PBAAAAAUAAAAAAKgPVwAAAEFuYWhlaW0gSUVU RiAtIExJU1AgV0cNRGF2ZSBNZXllciwgSm9obiBad2llYmVsLCBTdGlnIFZlbmFhcywgRGlubyBG YXJpbmFjY2kNTWFyY2ggMjAxMAAAoQ8uAAAAWAAAAAAAAAAAAA8AAAACAAIAAgAcAAgAAAACBAIA AgQcAEEAAAACCAIAAggUAAAAqg9QAAAAFgAAAAAAAAABAAAAAQAAAAAAEQAAAAAAAAAHAAAAAQAA AAMAAgAAAAAAAAALAAAAAQAAAAMABwAAAAAAAAAKAAAAAQAAAAMACwAAAAAAAAAAAPMDFAAAAAQA AAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABEcmFmdCBIaXN0b3J5EACfDwQA AAABAAAAAACoD4YBAABkcmFmdC1pZXRmLWxpc3AtbXVsdGljYXN0LTAwDVB1Ymxpc2hlZCBpbiBB cHJpbCAyMDA4DVJlbmFtZWQgZnJvbSBkcmFmdC1mYXJpbmFjY2ktbGlzcC1tdWx0aWNhc3QtMDEN ZHJhZnQtaWV0Zi1saXNwLW11bHRpY2FzdC0wMQ1QdWJsaXNoZWQgaW4gTm92ZW1iZXIgMjAwOA1F eHBlcnQgUmV2aWV3IGJ5IExpbWluZyBXZWksIFlpcXVuIENhaSwgVG9tIFB1c2F0ZXJpLCBTdGV2 ZSBDYXNuZXIsIE1hcnNoYWxsIEV1YmFua3MsIERpbWl0cmkgUGFwYWRpbWl0cmlvdSwgUm9uIEJv bmljYSwgYW5kIExlbm55IEd1YXJkaW5vDWRyYWZ0LWlldGYtbGlzcC1tdWx0aWNhc3QtMDINUHVi bGlzaGVkIGluIFNlcHRlbWJlciAyMDA5DUJyaW5nIGluIHN5bmMgd2l0aCBkcmFmdC1pZXRmLWxp c3AtMDYAAKEPAgEAAB0AAAAAAAAAAABHAAAAAQAAAAAAHQAAAAAAAAAAAKcAAAABAAAAAAAdAAAA AAAAAAAAQgAAAAEAAAAAAB0AAAAAAEMAAgACABgAGAAAAAAEAgAABBQADQAAAAAIAgAACBQAIQAA AAAMQwAADAIAAgAUAAEAAAAAEAIAABAUABwAAAAAFEMAABQCAAIAGAABAAAAABgCAAAYGAAbAAAA ABwCAAAcFAARAAAAACACAAAgFAB7AAAAACQCAAAkFAAdAAAAAChDAAAoAgACABgAHAAAAAAsAgAA LBQAEwAAAAAwAgAAMBQAEgAAAAA0QwAANAIAAgAUAAEAAAAAOAIAADgUAAAAqg+YAAAAmwAAAAAA AAABAAAAAQAAAAAAGAAAAAAAAAADAAAAAQAAAAMAAgAAAAAAAAAJAAAAAQAAAAMABgAAAAAAAAAI AAAAAQAAAAMACAAAAAAAAAAGAAAAAQAAAAMAFAAAAAAAAAAIAAAAAQAAAAMAEwAAAAAAAAAGAAAA AQAAAAMADAAAAAAAAAAJAAAAAQAAAAMAXwAAAAAAAAAAAPMDFAAAAHYAAAAAAAAAAgAAABgBAAAA AAAAAACfDwQAAAAAAAAAAACoDw0AAABQbGFucyBmb3IgLTAzEACfDwQAAAABAAAAAACgD+gCAABC AHIAaQBuAGcAIABpAG4AIABzAHkAbgBjACAAdwBpAHQAaAAgAGQAcgBhAGYAdAAtAGkAZQB0AGYA LQBsAGkAcwBwAC0AaQBuAHQAZQByAHcAbwByAGsALQAwADEADQBVAG4AaQBjAGEAcwB0ACAAUABU AFIAcwAgAGEAcgBlACAAYwBhAGwAbABlAGQAIAB1AFAASQBUAFIAcwANAE0AdQBsAHQAaQBjAGEA cwB0ACAAUABUAFIAcwAgAGEAcgBlACAAYwBhAGwAbABlAGQAIABtAFAARQBUAFIAcwANAEoAbwBl AGwAIABjAG8AbQBtAGUAbgB0AA0AKABTAC0ARQBJAEQALAAgAEcAKQAgAGoAbwBpAG4AZQBkACAA dABoAHIAbwB1AGcAaAAgAGQAaQBmAGYAZQByAGUAbgB0ACAAcwBvAHUAcgBjAGUAIABSAEwATwBD AHMAIABkAG8AZQBzACAAbgBvAHQAIABjAGEAdQBzAGUAIABkAHUAcABsAGkAYwBhAHQAZQBzAA0A RABpAG4AbwAgAGYAbwB1AG4AZAAgAGIAdQBnAHMADQBDAGwAYQByAGkAZgB5ACAAaABvAHcAIABt AGkAeABlAGQAIABsAG8AYwBhAHQAbwByAHMAIABzAGgAbwB1AGwAZABuABkgdAAgAGIAZQAgAHUA cwBlAGQAIABmAG8AcgAgAG0AdQBsAHQAaQBjAGEAcwB0ACAADQBDAGwAYQByAGkAZgB5ACAAdwBo AGEAdAAgAG0AUABFAFQAUgBzACAAcwBvACAAdwBoAGUAbgAgAGQAZQBjAGEAcABzAHUAbABhAHQA ZQBkACAAcABhAGMAawBlAHQAIABpAHMAIABkAGkAZgBmAGUAcgBlAG4AdAAgAEEARgAgAHcAaQB0 AGgAIABuAG8AIAByAGUAYwBlAGkAdgBlAHIAcwAgAC0AIABkAHIAbwBwACAAcABhAGMAawBlAHQA DQAAAKEP2gAAADAAAAAAAAAQAABaAEAAAAABAAAQAABaAA0AAAAAAAAQAABaAEsAAAABAAAQAABa ABAAAAAAAAAQAABaAJ0AAAABAAAQAABaABMAAAAAAAIAHAAcAAAAAARDAAAEAgACABQAAQAAAAAI AgAACBQAHwAAAAAMAgAADBgAIQAAAAAQAgAAEBgADQAAAAAUAgAAFBwASwAAAAAYAgAAGBgAEAAA AAAcAgAAHBwAPAAAAAAgAgAAIBgAXwAAAAAkAgAAJBgAAQAAAAAoAgAAKBgAAQAAAAAsAgAALBgA AACqD6IAAAAwAAAAAAAAAA0AAAABAAAAAwAKAAAAAAAAAAEAAAABAAAAAAAHAAAAAQAAAAMACgAA AAAAAAAFAAAAAQAAAAMACwAAAAAAAAAHAAAAAQAAAAMAOAAAAAAAAAAGAAAAAQAAAAMAZAAAAAAA AAACAAAAAQAAAAAADQAAAAAAAAAHAAAAAQAAAAMACAAAAAAAAAANAAAAAQAAAAMAOAAAAAAAAAAv APAPVAAAAAAA8wMUAAAAaQAAAAAAAAAAAAAAAAEAAAAAAAAAAPMDFAAAAGoAAAAAAAAAAAAAAAEB AAAAAAAAAADzAxQAAAB3AAAAAAAAAAAAAAACAQAAAAAAAAAA6gMAAAAADwD4AwsJAAACAO8DGAAA AAEAAAABAgcJCAAAAAAAAAAAAAAAAADHsGAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wA zMz/ALKysgBgAPAHIAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYAYADwByAAAAD/ /8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAAAzMzMAAAAAAN3d 3QCAgIAATU1NAOrq6gBgAPAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwAzADAwMAAYADw ByAAAAD///8AAAAAAICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8AcgAAAA////AAAAAACAgIAA AAAAADOZ/wCZ/8wAzADMALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAAAAAAAAAA AEACAAAAAAIAAAD//+8AEAABAP///////ywAAAAABQAAEACjD3wAAAAFAP/9PwAFACIgAABkAAAA AAUAAGQAFAAAANgAAABAAgAAAAACAAAA///vAAAAAQD///////8gAAAAAAEAAIAFAAATINQBIAEA AAIAHACABQAAIiDQAkACAAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24A AAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///vAAAAAAD///////8M AAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAA ow9SAAAABQAAAAEJAAAEAAEAAAAAAAAAAQABCQAABAABACABAAAAAAIAAQkAAAQAAQBAAgAAAAAD AAEJAAAEAAEAYAMAAAAABAABCQAABAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4A AAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAA AAAAAgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAA AAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwERQUAAA8AAvA9BQAAEAAI8AgAAAAGAAAACAQAAA8AA/DV BAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIA AAASAArwCAAAAAIEAAAACgAAkwAL8DYAAAB/AAEAAQCAAHCAIS+HAAEAAACBAQQAAAiDAQAAAAi/ AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAPAAsAHQFMADDwAR8BAAAAAAAMMLCAAAAAAA AAABAHoADwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRp dGxlIHN0eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAA AwQAAAAKAACDAAvwMAAAAH8AAQABAIAAAEsgHYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACAAAEPAIAAAAgASwAdAUoA4PABHwEAAAAAAAwwsIAAAAAQAAAAIAegAPAA3wngAAAAAA nw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25k IGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAA DQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8MsAAAASAArwCAAA AAQEAAAACgAAgwAL8DAAAAB/AAEAAQCAAFA77ReBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEA CQABAgIAAAgAABDwCAAAAGAPsAGwB4AQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAXoADwAN8FMAAAAA AJ8PBAAAAAQAAAAAAKgPGwAAAExJU1AtTXVsdGljYXN0IERyYWZ0IFN0YXR1cwAAoQ8cAAAAHAAA AAAAAAAAABwAAAARAAcAEQABAAwAAAAABQ8ABPDKAAAAEgAK8AgAAAAFBAAAAAoAAIMAC/AwAAAA fwABAAEAgAAwskQogQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABg D7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAACQJ6AA8ADfBSAAAAAACfDwQAAAAEAAAAAACoDwwA AABBbmFoZWltIElFVEYAAKEPKgAAAA0AAAAAAAAIAAABAAwAAAARAAcAEQABAAwAAAAABQEAAAAA BAIAAAQOAA8ABPAAAQAAEgAK8AgAAAAGBAAAAAoAAIMAC/AwAAAAfwABAAEAgAAQS+spgQEEAAAI gwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgDyAQ0BSAEA8AEfAQAAAAAADD CwgAAAAEAAAACAJ6AA8ADfCIAAAAAACfDwQAAAAEAAAAAACgDw4AAABTAGwAaQBkAGUAIAAqAAAA oQ8wAAAACAAAAAAAAAgAAAIABwAAABEABwARAAEADAAAAAAFAQAAAAAEBwAABAEADgAAAAAFAADY DwQAAAAGAAAAAACqDxoAAAAGAAAAAAAAAAEAAAABAAAAAAABAAAAAAAAAA8ABPBIAAAAEgAK8AgA AAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ AAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyACAAug8cAAAA RABlAGYAYQB1AGwAdAAgAEQAZQBzAGkAZwBuAA8A7gP3BAAAAgDvAxgAAAACAAAAAwQHCQgAAAAA AACAAAAAAAAAx7APAAwEpwQAAA8AAvCfBAAAIAAI8AgAAAAGAAAACKgAAA8AA/A3BAAADwAE8CgA AAABAAnwEAAAAAAQgEAAAAAAAGh/QAAAAAACAArwCAAAAACoAAAFAAAADwAE8NIAAAASAArwCAAA AAKoAAAACgAAkwAL8DYAAAB/AAEAAQCAAIB8GC6HAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEA AAj/AQEACQABAgIAAAgAABDwCAAAAKAFsAHQFHAIDwAR8BAAAAAAAMMLCAAAAAAAAAADAHoADwAN 8FQAAAAAAJ8PBAAAAAYAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxl AACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwzwAAABIACvAIAAAAA6gAAAAKAACD AAvwMAAAAH8AAQABAIAAwMLpF4EBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAAkAlgAyAT4A0PABHwEAAAAAAAwwsIAAAAAQAAAAQAegAPAA3wVwAAAAAAnw8EAAAABQAA AAAAqA8jAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgc3VidGl0bGUgc3R5bGUAAKIPBgAAACQAAAAA AAAAqg8KAAAAJAAAAAEAAAAAAA8ABPCyAAAAEgAK8AgAAAAEqAAAAAoAAIMAC/AwAAAAfwABAAEA gACwujsXgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7ABYAaA EA8AEfAQAAAAAADDCwgAAAACAAAABwF6AA8ADfA6AAAAAACfDwQAAAAEAAAAAAChDxQAAAABAAAA AAAAAAAAAQAAAAAAAgAOAAAAqg8KAAAAAQAAAAEAAAAAAA8ABPDSAAAAEgAK8AgAAAAFqAAAAAoA AIMAC/AwAAAAfwABAAEAgACwSSsugQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAI AAAQ8AgAAABgD7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAACQJ6AA8ADfBaAAAAAACfDwQAAAAE AAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAEAAgAAAAAAAgAOAAAA+g8EAAAAAAAAAAAA qg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE8LoAAAASAArwCAAAAAaoAAAACgAAgwAL8DAAAAB/ AAEAAQCAAMCcKy6BAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAP IBDQFIAQDwAR8BAAAAAAAMMLCAAAAAQAAAAIAnoADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKEPHAAA AAEAAAAAAAAIAAACAAEAAAAAAAcAAQAOAAAAAAUAAKoPCgAAAAEAAAABAAAAAAAPAATwSAAAABIA CvAIAAAAAagAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAPAD GgYAAAEA8QMIAAAAAAAAgAAAwAAPAAwEmgUAAA8AAvCSBQAAYAAI8AgAAAAHAAAABxAAAA8AA/Aq BQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA/////wAAAAACAArwCAAAAAAQAAAFAAAADwAE8NAA AAASAArwCAAAAAIQAAAACgAAgwAL8DAAAAB/AAEAAQCAAADtSjaBAQQAAAiDAQAAAAi/AQEAEQDA AQEAAAj/AQEACQABAgIAAAgAABDwCAAAAAAAAABQByABDwAR8BAAAAAAAMMLCAAAAAAAAAAKAnoA DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAM AAAA+Q8EAAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE8NIAAAASAArwCAAAAAMQ AAAACgAAgwAL8DAAAAB/AAEAAQCAABDySjaBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAB AgIAAAgAABDwCAAAAAAAkAngECABDwAR8BAAAAAAAMMLCAAAAAEAAAAHAHoADwAN8FoAAAAAAJ8P BAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAAD4DwQAAAAA AAAAAACqDxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATwZAAAABIACvAIAAAABBAAAAAKAABjAAvw JAAAAH8ABAAEAIcAAQAAAH8BAAABAL8BEQARAP8BCAAJAD8CAQABAAAAEPAIAAAAsAHQAhAOIAoP ABHwEAAAAAAAwwsIAAAAAgAAAAUAegAPAATwFgEAABIACvAIAAAABRAAAAAKAACDAAvwMAAAAH8A AQABAIAAIPdKNoEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAsApA AqAO0BQPABHwEAAAAAAAwwsIAAAAAwAAAAYCegAPAA3wngAAAAAAnw8EAAAAAgAAAAAAqA9SAAAA Q2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVs DUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMA DAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8NYAAAASAArwCAAAAAYQAAAACgAAkwAL8DYAAAB/ AAEAAQCAAND9SjaHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDw CAAAAGAVAABQB4AWDwAR8BAAAAAAAMMLCAAAAAQAAAAJAnoADwAN8FgAAAAAAJ8PBAAAAAQAAAAA AKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+g8EAAAAAAAAAAAAqg8SAAAA AQAAAAEAAAAAAAEAAAAAAAAADwAE8NgAAAASAArwCAAAAAcQAAAACgAAkwAL8DYAAAB/AAEAAQCA AGADSzaHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAV kAngEIAWDwAR8BAAAAAAAMMLCAAAAAUAAAAIAnoADwAN8FoAAAAAAJ8PBAAAAAQAAAAAAKAPAgAA ACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAADYDwQAAAAAAAAAAACqDxIAAAABAAAA AQAAAAAAAQAAAAAAAAAPAATwSAAAABIACvAIAAAAARAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAA CJMB3r1oAJQBjp+LAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAA AAAAAADMmQAzM8wAzMz/ALKysgAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLExAAAAAAAOsuCAAAAM0TdwAAvowbDwDuA40CAAACAO8DGAAAAAAAAAAPEAAAAAAAAAEA AIAAAQAABwByYA8A2Q8MAAAAAADaDwQAAAAAAC0ADwAMBJQBAAAPAALwjAEAAEAACPAIAAAAAwAA AAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAA BQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/AeAAAABAAAAAAAgABAt4AvvwEAAAEA/wEA AAEAAQMCqAAAAAAQ8AgAAABABQAAgBYQCA8AEfAQAAAAAADDCwgAAAAAAAAADwB6AA8ADfAMAAAA AACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAgAgAAUwAL8B4AAAAEAAAAAACAAFAf9zK/ AQAAAQD/AQAAAQABAwOoAAAAABDwCAAAAPAJEAJwFEAODwAR8BAAAAAAAMMLCAAAAAEAAAAQAHoA DwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAQgAAAAMAACDAAvwMAAAAIEBAAAA CIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAA AACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAIgTjQAAAA8AihOFAAAAAAC6DxAAAABfAF8AXwBQ AFAAVAAxADAAAACLE2UAAAAAAB0QBAAAAAAAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAA AAAAAAMAAAAAAAAAAAAAAAAAAAAA/7oQ/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIr AAAAAA8A7gMhKAAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAQEAAAcAcmAPAAwEwAEAAA8AAvC4 AQAAgAAI8AgAAAADAAAABgwAAA8AA/BQAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA/////wAC AAACAArwCAAAAAAMAAAFAAAADwAE8HIAAAASAArwCAAAAAIMAAAgAgAAUwAL8B4AAAAEAAAAAACA AODlTDa/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAPAAsAHQFMADDwAR8BAAAAAAAMMLCAAAAAAA AAANAHoADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwngAAABIACvAIAAAAAwwAACACAABTAAvwHgAA AAQAAAAAAIAAwKtMNr8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAAIASwAfAVQA4PABHwPAAAAA8A FBAkAAAAAQDxDxwAAAAAAAAHAAAAAAAAAAAAAAAAAgABAAIMAwAAAAA8AADDCwgAAAABAAAADgC8 IA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEMAAAADAAAgwAL8DAAAACBAQAA AAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAA AAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwCIEwkmAAAPAIoTASYAAAAAug8QAAAAXwBfAF8A UABQAFQAMQAwAAAAixPhJQAAAAAdEAQAAAAAAAAAAAAAKwQAAAAheQa8HwBE8YElAAAAACfxIAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAECAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAAHwBE 8TwlAAAAACfxIAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAP////8YAAAADwA98Q0AAABAAULx BQAAAAEEAAAAAABB8RQAAAABAAAAAQAAAAAAAAAAAAAAAwAAAD8AJfEsAAAAAAAo8RAAAAABAAAA CQAAAAAAAAAAAAAADwA88QwAAAAAAAErBAAAAAEAAABPACXxLAAAAAAAKPEQAAAAAQAAAAoAAAAA AAAAAAAAAA8APPEMAAAAAAABKwQAAAABAAAAHwBE8SEMAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMA AAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA//// /x8ARPHJCwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAA HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQEAAACQAELxBQAAAAECAAAA oABC8QUAAAABBAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAA AAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAA ABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBs AGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0 AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMM AAAAAAAAHQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAA AAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAA AQAAADgAAAABAAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAA QvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8A KvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgA AAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAADDAAAAAAAAB0AAAAfAETxGQEAAAAAJ/EgAAAAAAAA AAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAA OAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIA AAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAAD AAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQA XwB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAAAAAAAdAAAAHwBE8csDAAAAACfxIAAA AAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC 8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAA AAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAA AAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2 AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAA QvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAA AgAAAAEAAAADDAAAHQAAADUAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPER AQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8dkA AAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBwAHAA dABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC 8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAAD cABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAB0AAAA1AAAAHwBE8RkBAAAA ACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAAAAAA NPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBwAHAA dABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeQAA ABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvEN AAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAAAdAAAANQAAAB8ARPHL AwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUA AAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAA AAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAA EABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAA HwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwA AAAAAPsqFAAAAAIAAAABAAAAAwwAADUAAABkAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA AAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3x AAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAAQvEP AAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0 AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAA AAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAAA1AAAAZAAA AB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAA DwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcAAAAD MQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBw AHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+ 8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAADDAAANQAA AGQAAAAfAETxIQwAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x AAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8ckLAAAAACfxIAAAAAAAAAAA AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAA AAAAAAAAAAAAAB8ARPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA AA8APfFBAAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAAB AQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAA AAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAA ADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAE AAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBs AGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAGQAAACBAAAAHwAl8RgAAAAAACjx EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAA AAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAA Q/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAA AELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAA AAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAA AQAAAAMMAABkAAAAgQAAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0 AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQA AAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADo AwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAA AAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAA AgAAAAEAAAADDAAAZAAAAIEAAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAA AAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAECAAAAoABC8QUAAAABBAAA ALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA AAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAA AA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAA AAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBp AHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAACBAAAAnAAAAB8A JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAA AAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAA DwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD 8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAA AAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA +yoUAAAAAgAAAAEAAAADDAAAgQAAAJwAAAAfAETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAA AAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/x ZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMA AAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAA M/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwA AAAAAPsqFAAAAAIAAAABAAAAAwwAAIEAAACcAAAAHwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAA AAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAgAAAKAA QvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAA AAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZ AAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABl AAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5 AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAADDAAA nAAAACgBAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAA AAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEA AAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELx AwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrx WQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAA DwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAJwAAAAoAQAAHwBE8RkBAAAAACfxIAAAAAAAAAAA AAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgA AAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAA EABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAA DwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8A eQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAACcAAAAKAEAAB8ARPEhDAAAAAAn8SAAAAAA AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAA AAAAAAAAAAAAAP////8fAETxyQsAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA AAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8csDAAAAACfx IAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAEBAAAA kABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEY AAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMA AAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAA AAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAA AAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoU AAAAAgAAAAEAAAADDAAAKAEAAEUBAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8A RPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr 8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBw AHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAA EABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0A AAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAACgBAABFAQAAHwBE8RkB AAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAA AAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBw AHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8A eQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAA QvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAAAoAQAARQEAAB8A RPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC 8QUAAAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAA AQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAA AAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAAB AAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAA AAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA8 8RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAEUBAABhAQAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAP AD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAA QvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAA cAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7x FQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAABFAQAA YQEAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEA AAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcA AAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAAD IwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAA HwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAADDAAA RQEAAGEBAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP AD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAECAAAAoABC8QUAAAABBAAAALAAQvEFAAAAAQEA AAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAA J/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA6 8QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAA AAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABp AHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAABhAQAAhwEAAB8AJfEYAAAAAAAo8RAA AAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAA APQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8VwAAAAAAEPx BAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC 8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAA AAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEA AAADDAAAYQEAAIcBAAAfAETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEA ABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAA AAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMA AAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAA AAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwAAAAAAPsqFAAAAAIA AAABAAAAAwwAAGEBAACHAQAADwACKzgAAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAADDAAAAQAA AAEACSsQAAAAAQAAAAEAAAAAAAAAAAAAAA8A7gNSJAAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACA AgEAAAcAcmAPAAwEtAEAAA8AAvCsAQAAMAAI8AgAAAADAAAAA9QBAA8AA/BEAQAADwAE8CgAAAAB AAnwEAAAAAAAAADTwbGhAACxodPBsaECAArwCAAAAADUAQAFAAAADwAE8GwAAAASAArwCAAAAALU AQAgAgAAQwAL8BgAAACAANBF/TK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAJAAsAHQFGADDwAR 8BAAAAAAAMMLCAAAAAAAAAANAHoADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwmAAAABIACvAIAAAA A9QBACACAABDAAvwGAAAAIAAoEX3Mr8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAAwANQASAW4A0P ABHwPAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHAAAAAAAAAAAAAAAAAgABAAIMAwAAAAA8AADDCwgA AAABAAAADgC8IA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAHUAQAADAAAgwAL 8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAH IAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwCIE0YiAAAPAIoTPiIAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAwAAAAixMeIgAAAADrLggAAACpFHcAAFrJGgAAHRAEAAAAAAAAAAAA ACsEAAAAIXkGvB8ARPGuIQAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAABAgAD/////EgAA AA8APfENAAAAQAFC8QUAAAABCQAAAB8ARPFpIQAAAAAn8SAAAAAAAAAAAAAAAAEAAAAAAAAAAAAA AAAAAAD/////GAAAAA8APfENAAAAQAFC8QUAAAABBAAAAAAAQfEUAAAAAQAAAAEAAAAAAAAAAAAA AAMAAAA/ACXxLAAAAAAAKPEQAAAAAQAAAAkAAAAAAAAAAAAAAA8APPEMAAAAAAABKwQAAAABAAAA TwAl8SwAAAAAACjxEAAAAAEAAAAKAAAAAAAAAAAAAAAPADzxDAAAAAAAASsEAAAAAQAAAB8ARPEh DAAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgA AAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETxyQsAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA HwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABA AULxBQAAAAEBAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUA AAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAA AAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAA AAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAA AAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAP ADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAAAAAADAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAA AAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAA AA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAA AABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMA cABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8A PvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAAAA AAAwAAAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA9 8QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELx FwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAA AAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAA AAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPU AQAAAAAAMAAAAB8ARPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA AA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAAB AQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAA AAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAA ADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAE AAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBs AGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBADAAAABPAAAAHwAl8RgAAAAAACjx EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAA AAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAA Q/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAA AELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAA AAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAA AQAAAAPUAQAwAAAATwAAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0 AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQA AAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADo AwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAA AAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAA AgAAAAEAAAAD1AEAMAAAAE8AAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAA AAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAECAAAAoABC8QUAAAABBAAA ALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA AAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAA AA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAA AAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBp AHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQBPAAAAcAAAAB8A JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAA AAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAA DwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD 8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAA AAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA +yoUAAAAAgAAAAEAAAAD1AEATwAAAHAAAAAfAETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAA AAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/x ZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMA AAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAA M/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwA AAAAAPsqFAAAAAIAAAABAAAAA9QBAE8AAABwAAAAHwBE8U4IAAAAACfxIAAAAAAAAAAAAAAAAAAA AAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA /////x8ARPH2BwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEA AAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEC AAAAoABC8QUAAAABBAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAA AAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA AQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkA YgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAAD cwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAA AAPUAQBwAAAAfQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfx IAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEM AAAAAQAAADgAAAABAAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAA ABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMA AA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABf AHgAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAcAAAAH0AAAAfAETxGQEAAAAAJ/EgAAAA AAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAAB AAAAOAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAv ADIAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMA AAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABw AHQAXwB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAHAAAAB9AAAAHwBE8csDAAAAACfx IAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAA kABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEY AAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMA AAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAA AAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAA AAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoU AAAAAgAAAAEAAAAD1AEAfQAAAMgAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8A RPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr 8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBw AHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAA EABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0A AAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAH0AAADIAAAAHwBE8RkB AAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAA AAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBw AHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8A eQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAA QvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQB9AAAAyAAAAB8A RPEhDAAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl 8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETxyQsAAAAAJ/EgAAAAAAAAAAAAAAAAAAAA AwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA AAAAHwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEA AABAAULxBQAAAAEBAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC 8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAA AAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAA AQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAA AAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkA AAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAyAAAANgAAAAfACXxGAAAAAAAKPEQAAAAAAAA AAAAAAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAA GQAAAA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAA AAAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAA AyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAA AB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QB AMgAAADYAAAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAA DwA98QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAA AELxFwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELx DwAAAAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAA AAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAA AAPUAQDIAAAA2AAAAB8ARPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUA AAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4 AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAA AAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAA AAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIA aQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBANgAAAAUAQAAHwAl8RgAAAAA ACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAA AAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAA AAAAQ/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgD AAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAA AAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAAC AAAAAQAAAAPUAQDYAAAAFAEAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAA AAD0AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD 8QQAAAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQA AADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAF AAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoU AAAAAgAAAAEAAAAD1AEA2AAAABQBAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAA AAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAECAAAAoABC8QUAAAAB BAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA AAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3x AAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrx bwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4A dgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQAUAQAAdAEA AB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAA AwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAAB AAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAA AABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz 8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAA AAAA+yoUAAAAAgAAAAEAAAAD1AEAFAEAAHQBAAAfAETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAA AwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAP AD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAA AAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAA AAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA8 8RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBABQBAAB0AQAADwACKzgAAAAPAAgrMAAAAAAAAysQAAAA AQAAAAAAAAAD1AEAAQAAAAEACSsQAAAAAQAAAAEAAAAAAAAAAAAAAA8A8APMAQAAAQDxAwgAAAAA AQAABwBAiA8ADASMAQAADwAC8IQBAABQAAjwCAAAAAMAAAADqAEADwAD8BwBAAAPAATwKAAAAAEA CfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAKgBAAUAAAAPAATwWAAAABIACvAIAAAAAqgB ACACAABDAAvwGAAAAH8ABAAEAL8BAQABAP8BAQABAAEDBBAAAAAAEPAIAAAAsAHQAhAOIAoPABHw EAAAAAAAwwsIAAAAAAAAAAsAegAPAATwhAAAABIACvAIAAAAA6gBACACAABTAAvwHgAAAH8AAAAE AIAAoFxLNr8BAQABAP8BAQABAAEDBRAAAAAAEPAIAAAAsApAAqAO0BQPABHwEAAAAAAAwwsIAAAA AQAAAAwAegAPAA3wHgAAAAAAnw8EAAAAAgAAAAAAqg8KAAAAAQAAAAEAAAAAAA8ABPBIAAAAEgAK 8AgAAAABqAEAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A8APM AQAAAQDxAwgAAAABAQAABwBAiA8ADASMAQAADwAC8IQBAACQAAjwCAAAAAMAAAADrAEADwAD8BwB AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAKwBAAUAAAAPAATwWAAA ABIACvAIAAAAAqwBACACAABDAAvwGAAAAH8ABAAEAL8BAQABAP8BAQABAAEDBBAAAAAAEPAIAAAA sAHQAhAOIAoPABHwEAAAAAAAwwsIAAAAAAAAAAsAegAPAATwhAAAABIACvAIAAAAA6wBACACAABT AAvwHgAAAH8AAAAEAIAAwGJLNr8BAQABAP8BAQABAAEDBRAAAAAAEPAIAAAAsApAAqAO0BQPABHw EAAAAAAAwwsIAAAAAQAAAAwAegAPAA3wHgAAAAAAnw8EAAAAAgAAAAAAqg8KAAAAAQAAAAEAAAAA AA8ABPBIAAAAEgAK8AgAAAABrAEAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADM zP8AsrKyAA8A8AP0AQAAAQDxAwgAAAAYAQAABwBAiA8ADAR0AQAADwAC8GwBAABwAAjwCAAAAAMA AAAD2AEADwAD8AQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAANgB AAUAAAAPAATwUgAAABIACvAIAAAAAtgBACACAAAzAAvwEgAAAL8BAQABAP8BAQABAAEDBBAAAAAA EPAIAAAAsAHQAhAOIAoPABHwEAAAAAAAwwsIAAAAAAAAAAsAegAPAATwcgAAABIACvAIAAAAA9gB ACACAAAjAAvwDAAAAIAAQIFMNgEDBRAAAAAAEPAIAAAAsApAAqAO0BQPABHwEAAAAAAAwwsIAAAA AQAAAAwAegAPAA3wHgAAAAAAnw8EAAAAAgAAAAAAqg8KAAAAAQAAAAEAAAAAAA8ABPBIAAAAEgAK 8AgAAAAB2AEAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBM4 AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAArRR3AIB9 IbsQABEQYwAAAAAGAAB4nLtwXvDBwo1SDxnQgB0DM8O//5wMbEhijFAMBgIMQPn//0FMGA0C/0fB kAJ/gfjfQDtiFAwYYAhCz/mkASYGVpQ8j1fxstOsX4+dYvxHSB2JgGj7aQSGsv0A5NrzzQAAchc8 AAAAAQBQAAAAAAAoLwAAXEMAAPFFAAA6PQAAKQAQADs4AABpACAAdJIAAEiUAAB2ADAAGm4AAByW AAAYmAAAAAD1DxwAAAAAAQAAByIAAwAAAACDmAAAAQAAAHgAAAABAMdoDwDoAyIvAAABAOkDKAAA AIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAUAAAAAAAAAAQAAAAABAAEPAPIDrgEAAC8AyA8MAAAA MADSDwQAAAAAAAAADwDVB+QAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBu AAAA/78wwwAAEABafEDY/78Ix/+/MMP/v8j1kXyc9gAAAAAAAATgEAC3D0QAAABDAG8AbQBpAGMA IABTAGEAbgBzACAATQBTAAAAbgAAAP+/MMMAABAAWnxA2P+/CMf/vzDD/7/I9ZF8nPYAAAAAAAAE 4CAAtw9EAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAU4EAAACCAAAAgwAAAIQAAACFAAAAhgAA AIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAAD+//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAA AgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rnQCAAAwAgAAEAAAAAEAAACI AAAAAwAAAJAAAAAPAAAAqAAAAAQAAADMAAAABgAAANQAAAAHAAAA3AAAAAgAAADkAAAACQAAAOwA AAAKAAAA9AAAABcAAAD8AAAACwAAAAQBAAAQAAAADAEAABMAAAAUAQAAFgAAABwBAAANAAAAJAEA AAwAAADOAQAAAgAAABAnAAAeAAAAEAAAAE9uLXNjcmVlbiBTaG93AAAeAAAAHAAAAERlbGwgQ29t cHV0ZXIgQ29ycG9yYXRpb24AAAADAAAAq+wAAAMAAAAXAAAAAwAAAAMAAAADAAAAAwAAAAMAAAAA AAAAAwAAAAAAAAADAAAABQMLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAcA AAAQAAAAVGltZXMgTmV3IFJvbWFuAA4AAABDb21pYyBTYW5zIE1TAAwAAABDb3VyaWVyIE5ldwAP AAAARGVmYXVsdCBEZXNpZ24AMQAAAERyYWZ0IFN0YXR1cyBVcGRhdGUgZHJhZnQtaWV0Zi1saXNw LW11bHRpY2FzdC0wMgAOAAAARHJhZnQgSGlzdG9yeQD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAAB AAAA4IWf8vlPaBCrkQgAKyez2TAAAABsJwAACwAAAAEAAABgAAAAAgAAAGgAAAAEAAAAhAAAAAgA AACcAAAACQAAALQAAAASAAAAwAAAAAoAAADgAAAADAAAAOwAAAANAAAA+AAAAA8AAAAEAQAAEQAA AAwBAAACAAAAECcAAB4AAAAUAAAATVJJQiBEZXNpZ24gUmV2aWV3AAAeAAAAEAAAAERpbm8gRmFy aW5hY2NpAAAeAAAAEAAAAERpbm8gRmFyaW5hY2NpAAAeAAAABAAAADQzNwAeAAAAGAAAAE1pY3Jv c29mdCBQb3dlclBvaW50AAAAAEAAAADgz63bUQEAAEAAAAAAoQfnsdS/AUAAAACAoEn6L8fKAQMA AAB7AAAARwAAAFgmAAD+////UElDVCZQAAAAAACHALQAEQL/DAD//gAAAEgAAABIAAAAAAAAAIcA tAAAAAAAHgABAAoAAAAAAIcAtACaAAAA/4LQAAAAAACHALQAAAAEAAAAAABIAAAASAAAABAAIAAE AAgAAAAgAa5BaBemHgwAAAAAAIcAtAAAAAAAhwC0AAAADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8AZoH/qP8C vaf78P8D3lEz9/b/Avvr8+D/ANr9/wHn5/f/Avdc+6j/AZvH7/8CvTNm9f8C9+v34f8B9979/wHa 9/f/Adp4qP8C+9zz7/8C3czi9f8C+/j+4f8B9vn9/wDw9v8B4eXM/wC4gf+o/wRcMzOU8/L/BjNa q939sq36/wCn/jMEdv//3n/4/wGyrfH/AuMz5/7/AmaE+fj/A9Uz1v78/wL7b/ey/wD3/jMArfL/ B+szgLbi/3je+/8B94f+MwSx//+trfj/AXje8f8IsjP3///7M8X9+P8Cm0/k+/8B43+x/wTvzMzR 7fL/B+nM19rr/NX8+/8B9tP+zAT0///Y8/n/AvzV/PH/B9Xa+///8szw9/8C0Nfu+/8B5eXV/wDy gf+o/wVca5czM9P0/wj3M9Pg8f+Of+38/wvCM7jTwcHk/8wz4vv6/wiOf+3/+/v///v+/wLrwu/+ /wnRM9P7//9Rhebn+f8D1ULd/Pz/A+8z0vmz/wb3M5J9M0Hz9P8I1TPd5vT/M7P3/P8KfzPJ073M 7v+Ofu35/wQzs/f/9/7/APv+/wHjwv3/CZVB3f//8zO27+/5/wKbg9/7/wPMM+X7s/8F78zWz8zV 8/8I3dfd6vj4zOD8/P8KzNXe29jc+P/O2/f6/wj4zOD8//z///7+/wL+8O39/wnQ1Of//+/M3Pf8 +f8C0Nnp+/8C3Nbu1v8BRIH/qP8XUYTk6nEz3tpRlTNR/+NRM1Hnx1wzM1Dj/TMAzP3/BpszzOv8 9/P9MwaN/pszM5vn/TMpzJuN/usz8tVDMzOp+///1TPT/P//UYTdM20zZvf/zDMzQ0/e93gzM8d/ /jMGQ/7jMzNR3rn/GPczuuvZM0D8oX9vM47/xzMzb/+bUTMzh739MwDz/f8GUV7X8Pz23v0zBsz3 eDMzzL39MwfzQ8//wkP+rf4zANr+/w+bQd7///cztsgzbjOV//+h/jMGiefjUTNR6/0zBo7+wjMz Zve5/xjvzNzx28zT/9Xfzszs/9/MzOH+187MzOrY/swBzv7+/wf5zNPj+Pv14/3MBvn10MzQ9tj+ zAjO+sz3/9jf/tr+zADy/v8P0NPp///vzNvczNHM7P/+2P7MBtn06szM1/T9zAXt/93MzNzc/wFQ gf+o/x1RhOj//kCD0DNKtjPEM227M7O5WECcqdzQamq91/P+/wDa/TNFzP/djT+6zI4zsn0/5tBq ar3XYonn0TPTUFnNja3u///VM9D8//9chN0zP5szhekzmro/U99cM79KfduvM63F3jOKwTOJ97r/ HvcztvX/5zO2mzN0mzO+M5qlM9mVM1ycttzFM5LB3fz+/wCn/jNGW+v/0GpqvddOM8NKfejFM5LB 1zO29JVC1zOL02rM+f//mzPe///3M7bMM2OWM8PCM7epM4PdM227M7PajTO6zNUzs60zvv26/x3v zNv9/+PM5dPM2NDR2cze0c3o2MzR1Nrr28zW2t79/wDX/sxF2vz74s3T2dvM1dnM2PHbzNba2czb +9DV4Mza2tDd/v//0NLp///wzNvdzNHSzO/Y0N7TzNfmzNvVzODsz9DY3OLM4NLM5d3/AU6B/6j/ HVyE6P//oVPDM9ffjpIz3dwzuvPNM97u8f6bXuT2/f3/SfbQwWoz7P/TM9vuM63dn1be/pte5PZb hejVM9NQM2Ta6vL//9Uz0/v/+zO03TPQ3pFqmWTd6slAwDPL3WOO5/EzwfLQM6lBM7rpuv8d9zO2 9P//UI2VVt3MoVN73cAz1/yOd+Lu9PxOl+v3/P9J5NC2M1T6/5Ve5NIzzt1ajuf8Tpfr8DO29JtB 1zMzfPTk+v//oUHd///jM9PMM93jQaVZn93yh32ZM93gM73z0zPd9ZhQnDNC0/W6/x3vzNv7//zM 2M/V3d7czNzd19Df/c7X5+749szZ8vj8/0nj29TM1v38z9Tr3czd48zY8/bM2fLqzNv70NPgzM3a +OX+///R0+f//+XO3dzV3ebM2czf3/XN19LX3eLM3Prb0OX20NfSzNPd/N7/AU2B/6j/FVGP6P// f324Qt39/45g3fszxfXRQt3+/wKbQeL8/yHz///77DPQ/dUz0PYzvfCtaOD/m0Hi/4eE6NUz0/Sd WzPc/v8l9zO6/P/jM8noM9f7oVaGfeL/2kK6M9f5b5/q8zOy99UzM5nb3fW6/xb3M730//8zs4mJ 4P/4QZTl4zPd/ZWD5v7/AlGE7f3/Ivf7//37wzPg/5tB4toz2vpmnur/UYTt/zO29JtB3umSPzP5 /v8l1TPX//+tM93TQt3/UY4ztOv/m4KTV937M8X21TPT/5szM7bd3vy6/xzvzNz7//bM28/Z6//u zNjx5NHi/9DZ9P//+8zX9/3/Ifv///z61dLq/9DS7d/Q3f7M2vX7zNf39szc+9HT6erSzNP9/yTf zun//9XU3t3W5/zM18zb9//Q2NDV5vPM3fzfzuP/0czQ4d3l3f8BToH/qP8VUavq/8czr8FC3v// pzPb8zOp+NFC3v7/AptM3v3/I9Ez3P/veDPX+9Uz0/MznPatM+P/m0ze/5Vu4b0zw6v53DOy+P7/ JGU/4vtcWt3uM7LhQ4mwM8Xzb0++M8H9eHru8zO289ozrd3MQ/O6/xb3M8z2/5UzzI6C6P//XGvr 2jPQ/5WC5/7/AlGE6P3/So5D8v/jQ1nd/5tB3tozwf54c+7/UYTo/0OX7YdMtsf6uDPT/v//9zNq +eczkd3VM8bRM7d9P+TjM4mTM9nzM6341TPT/KEzyd29XLn/HO/O3fz70c/dz9n0//zM1PbkzeT/ 0Nn0///7zNf0/f8iztv+/uzM1+j/0NPo4czh+8zW+PvM1/T7zNj3ztPa8/bUzeX+/yTwzNX/7Mzb 5d3R5eTM3M3R+OzM2dLR6/LM2/7fzt//0c/c4drf3f8BQIH/qP8MbzNCMzOH3cYz3v//8/0zBFPx 0TPe/v8CmzPf/f8B9079MwfD3f3VM9P8rP0zBrr/mzPf/9X9MwC5/TMB0PP+/wHrS/4zAtLg8/4z A0LR6Hr+MwJL33T9Mwbf8zO29P+Q/jMCdN78u/8N9zMzQzMzsd2Lguf//9r9MwSN+5WC5/7/AkN+ 6P3/AOP9Mwhk1OD/lTPe/2z9Mwbe/0N+6P+h/jMBQJj+MwJq3fz+/wDU/jMDbd3p1f4zA3Pd6UD+ MwGD3f0zB1Py1TPT/PtW/jMBn+C6/w3wzMzOzMzd38zZ9P//4f3MCtn/ztj0///7zNf0/f8A6f3M B9nd6//O0un7/cwHzvL7zNf0/9P+zAHS0f7MAdff/f8A3/7MA9vd9N/+zALa3fD9zAHX6P3MBtP6 3c3f//X9zAHg6d7/AUWB/6f/CLqXmMXd5/fR3f7/CPjB0NrF4Npz3f7/AvfT3fz/Iv3Owcnd3fb/ /9bd/P/bwd3F2vX3093//+bF0Lbd6r3B2t37/f8j+s7M2t378zPJ0N3e+//TzN3X3//Lyd3B3f3c 2vT//9rM093kuf8J+a2SptDd8efR5/7/COu919DQ6qeZ5/7/AufU5/z/IfjFwczd4vz/99Ld///K xd3B3f3n1Of//9TJycHe273F3eP8/yP1zMzd4//VM9fQ3eT//MnQ3dro+L3Q2sXg/9bd/P/+z8zX 3eu5/wnw1dPX3d358tz0/v8I59nd2t3219nz/v8C8d30/P8h7trZ3N3o///23ej/+9nb3Nri//Hd 9P//3dvY2+jf2Nvd6vz/I+vb293q/93V3Nzd6//12tzc3fTy2dzb2+v7497///jb293d9d7/ASKB /6b/B/Tt7fj///32/f8H/vf7/vj/9uT9/wH9+fr/Avr3+fz/APf+/wf69//4/v/9+f7/CPv4+/T/ /Pb3/vr/CPr6/v/zM9P5+/3/Dfr6//3///j5//f///f+/v8C+/r8t/8I/vLr8Pv///n5/f8H/Pb9 +/v/6+v9/wH5/Pr/Avj3+v3/Af35/v8H+Pj/9///+fz+//75BPf/+vb4+f8I+vr//9Ez3f37/f8M +fv//v/+9vv++P//9/3/Avr6/bf/CPvw6/L+///2/f3/B/r3//j+/+T2/f8B9/77/wP9+Pf8/f8M +fz///73+/35///3/v7/B/j69vv/+fb6+v8J/fr7///d1ef9/P7/Df74/f3///z3/fv7//z5/f8B +vrc/wAdgf+B/9r/A/cz0/yB/9H/AtUz3YH/0P8C39Xow/8AGoH/gf/Z/wL93fyB/9D/AfXdgf/P /wHp6MP/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B /4H/sf8A2oH/u/8B44f0/wXaf4fr/+P3/wHMwvn/AfPv/P8ClYey+/8C43ja/f8Af+P/Asx48/7/ AOP8/wGb6+7/AOP3/wh/b9r//6d/h/vh/wG9rfT/BbJ/lf//5/f/AZXv+f8B5/v9/wPzf4fV+/8C x3jz/v8B847j/wGhh/3/AOf8/wB47f8A5/j/COtvePf/+4d/p+D/Ad3y9P8F3drl//v59/8A2Pj/ APX8/wPw2Nr4+/8B4dz9/wHt7OT/Avza5f7/Afv5/f8B+d/u/wH7+fj/CO3V3f//+NjX7/L/AVWB /7z/A/f/uOb6/wD3/f8Gh/bl5vp4+Pj/Avvv8f7/APP+/wLMwPv+/wTVvejm7vv/Aum39v7/AfPl /v8B9/v9/wD37f8Gx8/8//94+P3/Avfp+v7/APP9/wD3/f8B9/v+/wF4+Pn/CrLV5Wz276frwLD+ 4/8D8/+j7fr/APP+/wf7ju7l6POH+fj/Avfo+/7/APP+/wKH6v7+/wSb6OXm9fv/AsbS/P7/AfDn /v8A8/z/APPt/waf5v//84f5/f8B8+T+/wH79/3/APP9/wDz/v8C84f5+f8Jh/bShv3M0OaS2eL/ A/z73/b6/wD8/v8H8Oro5u7s6vv4/wH75f7/Af78/v8B1/j9/wTY9eXm+vv/Advn/v8C/vLy/v8A +/z/APzu/wf92e7//+zq+/3/Afjp/v8A/Pz/APz9/wD7/v8C7Or7+v8K/trz2d//4fbl0vTz/wGp gf+9/xmhf3eH8KeOh2/r+5Wbf/f/pzOHp//HM4aV9/v/FOd/rP7/+4eVduP7ZmKNx//nXGOG5/r/ E+vJ8///rW/w//+yjoab+39/h3fn/P8w1UNvf1zewqf/h9X//9Hh+f/HM4aV9//Mb9T//+NvlUPv +5Wbf/f/so6Gm//HM4aV9/v/CqHf9a3h//vrvcnx5P8Yf452p+qHoXh//+uHlZP/+39DiMz/lTOH p/r/FMxv2P//53iVfvvnM3uM5//MM32S+/r/E8zh+v/7lX/8//+Om2XR529/jn77/P8vrUN4eFz7 ldXrb/P//63t//+VM4en//+nb/T//8J/hlv/64eVk///jptl0f+VM4en+v8Kh+b+nuj/8/SO3/rl /xn419rW7e3Y4dXi/+3c3On/9tHT1/b/09HX7fr/E+TV+P//7dja4P/szNTd/P/izNPk+f8S5e7/ //bY4/7/+9jf0fns19ja4fv/CdrR19Xc/Nj87dr+/yLl7v//09HX7f/83dr9///f2tXf/+3c3On/ +9jf0fn/09HX7fv/Cvni5vji9P/q+9rm8/8B1YH/vv8b3q3q5Wbm/3fg5uP61bGJ0/3/d93o6/96 3ejo9f54F47///GB7f+ym8W2ZvjQteLo8v/MtOLn8f54BY7//+vI8/7/DpHS/P+np8LF6dCz5eOM 8f54Mo7/ptuA3rD3pOvzufX/0eH6//963ejo/f/HrvX/h/jjy9T71bGJ0/2np8LF6f963ejo9f54 DI7/p+f7m97+/72b8PTl/3+y3uXVgOv2derk5f/DtHXo//aH3ujz94jd6OvjZnhvsv//x7L2/3i+ w46X/pjT5uf5/47T5ujiZnhvsv//zOD6///+buX//3+5v9H0mNnlyrPiZnhvsvO+ure/z/K69dHS /P+t7f//94jd6Ov//4rV/feH8eW54P/DtHXo/3+5vxfR9PeI3ejr42Z4b7L/m+b/f+r//4fM5/zl /z7c+eTa2/Tr2Orj6/vj29fx/+nZ4+f57dvi5/Pp1dfV8v//2OD8/9Ho39Dj/9bd6Oj9/9Td5+3p 1dfV8v//5e7+/1T11O3/+Nnd3+D71+Tl2efp1dfV8u/k0+PW5+3h/d/m///l7v//7dvi5/P//dPm //Dp6ebb6fvj29fx+Nnd3+D77dvi5/Pp1dfV8vjo6/ne8v/81ffm8/8BzoH/vv8T2rft/3jj/73l /f/RrfGp3fr/f+X+/wF45f7/AP3+5A7n//eU5/+9otPf1+PHw/P+/wXVw/P///3+5ATn//PN8/7/ D6He+v/n5Mx09sy18vOb6f3+5BPnveab4M/ysu3rzvP/1eX6//945f3/FtHD8f9/5v//8M6t8and +ufkzHT2/3jl/v8A/f7kCuen0f6b6futsvDp5P8Yp9j375Ln89Tl//+b2u6U5f/3lOj//++U6P7/ Evji5OPu/9HD8v9/v9bb1+uO4vz+/w2b4fz///ji5OPu/9Xo+v7/Jnjk//fv27mV+pXT/NHB8vji 5OPj08fJzObnzvPH6vr/su3//++U6P3/FpXh+/ON5v/775va7pTl9+/buZX675To/v8O+OLk4+54 6f+b5f+H4+bz5P8Y3Of+6uTz8PLu///a9ezd6v/v5vT//+zm9P7/EfDj5OP2/9/n+v/V3O3u4PfY 5v3/Adrm/v8H8OPk4/b/6e7+/yf73+j/+fbj2ej+2Of/4en68OPk4+ry3ufk7e3x+uTu///p7v// 7Ob0/f8W2uX/7eXw//z02vXs3er59uPZ6P7s5vT+/w7w4+Tj8tnx8+vq+dj84/rz/wGzgf+9/xmJ mIdmsZtvjdX/2oiRQ5L8rUOHx///oYyOsvv/FLKOUI7393mckZj473Kgf/fnZmuU9/v/FbKOdpX3 65VcfcX/XJigluTVenl/7On9/zDVZt1b1430h5dcffCbf4Kl//+hjI6y+6F4a6X/0W2nZuPYiJFD kvxcmKCW5P+hjI6y+/8J82iKp+nVM5x/0eT/GvtgqXhlv4d2j+//rZSJM7f7h1CI4///dpl43vv/ E5t4a6D/422mfL360Xyajv/MQ4Om+/8W+5t4iaX/0ZVDhuPzQ6qFwemndYSO9PL9/zCnjM2CzKzz dptDpeiVb4zH//92mXje65VRfMb/n4Kbb/qslIkzt/NDqoXB6f92mXje+/8J1XR42umVXJh17+T/ GvPR4tfV5dfY4P7/3NfVz+f209Tb/P/41d3Y/Pz/FPjf0dTr/+rS4NXw/OHV3On/5M7V7Pv/Fvbf 1djs/+Xcz9f87dPi1uT13NLY5er6/f8w2OXe3+Dm8NfbzOPv3dXY9f/41d3Y/O/dztT1/9Xb2t39 3NfVz+ft0+LW5PX41d3Y/Pv/COHU1fPzztnW2vL/Aa6B/7z/Gdnj5t/x6ePo9f/v2enb6fvt2+Xy ///Y4ufu+/8U7uff6f390+To6f/z0uvl/fni4+n9+/8Q7ufk6f366ODm8v/S2+rp0eb+5QD7/P8w 9eL64Prn/9Tq3eX+6eXm6///2OLn7v7q5OPt/+3S6+L479np2+n/0tvq6f//2OLn7vv/CfzV5+v/ 9d3r5vTk/xr+0e3k4vTm5Oj7/97j59ry+ubY6Pj//9Lo5Pf7/xPp5OPr//jS6uXx/+Xc6ef/897n 6/v/FP7p5Ofr//To3uj4/M3m5vOt6+Xm5/v/MOvn9eb17vXW6tvt+ujj6PL//9Lo5Pf66N/m8v/f 2enj/t7j59ry/M3m5vP//9Lo5Pf7/wnu3uT2/+jg6+T75P8a9uHr4+Xy5Ofq/v/k6uTf+fjh4+n9 //fi6+X9/P8U+ung5vP/7+Pt5Pn/5ufn8P/t3ujy+/8U+enj6PL/7uff6f3y3+zk+uXn5eXu+/8w 5fLp8+r38uXn3fX06OPo+P/34uvl/fTo3uf4/+Ln5uj/5Ork3/ny3+zk+v/34uvl/fv/COfn4/z/ 3ubq5vP/AOqB/7v/A/v9//77/wj9+//+//7//v7+/wH6/fP/Afr9/v8B/fro//77Ao6C3/H/Avr/ /vn/Afr9+f8B/fr+/wf9+//+///7+/3/Afr9+P8A+9v/APr4/wf7/f/+//7//f3/Afr+8/8B+v7+ /wH7/Oj/Bfr953+F+/L/A/37//75/wH6/vn/Afz7/v8H+/3//v//+v39/wH6/vn/Af393P8D/vv/ /vr/Afv+/v/+/v7/Af378/8B/fv9/wH6/en/Bf76/uzY2/H/Afz9+P8B/fv4/wH7/P7/Afv+/v8C /vr+/v8B/fv4/wD77P8AHoH/gf/y/wP+5+b4gf/R/wP55ef+gf/R/wLy5eur/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8AeYH/mf8AAPr/AAD6/wAA+//7AAH///oA8f/9AAD//AD8/wQA//8A//4A mv8AAPr/AAD6/wAA+//7AAH///oA8f/9AAD//AD8/wQA//8A//4Amv8AAPr/AAD6/wAA+//7AAH/ //oA8f/9AAD//AD8/wQA//8A//4Azv8Au4H/mv8FAAD/AP8A/v8CAP8A/f8EAAD//wD9/wIA/wD8 /wIA/wDx/wAA/v8IAP//AP//AP8A/v8GAP8A//8AAJj/BQAA/wD/AP7/AgD/AP3/BAAA//8A/f8C AP8A/P8CAP8A8f8AAP7/CAD//wD//wD/AP7/BgD/AP//AACY/wUAAP8A/wD+/wIA/wD9/wQAAP// AP3/AgD/APz/AgD/APH/AAD+/wgA//8A//8A/wD+/wYA/wD//wAAy/8AnYH/m/8DAP8A//gAAP/5 AP3/AQD//gD+/wEA//4A8/8AAP7/AgD///wA/f/+AAb/AP8A/wAAnP8DAP8A//gAAP/5AP3/AQD/ /gD+/wEA//4A8/8AAP7/AgD///wA/f/+AAb/AP8A/wAAnP8DAP8A//gAAP/5AP3/AQD//gD+/wEA //4A8/8AAP7/AgD///wA/f/+AAb/AP8A/wAAzv8A04H/nP8RAP8AAP8A/wD/AP8A/wD/AAD//gAB /wD9/wIA/wD9/wMA//8A/P8BAAD5/wAA/f8AAP3/AAD7/wkA/wAA/wD/AP8Anf8RAP8AAP8A/wD/ AP8A/wD/AAD//gAB/wD9/wIA/wD9/wMA//8A/P8BAAD5/wAA/f8AAP3/AAD7/wkA/wAA/wD/AP8A nf8RAP8AAP8A/wD/AP8A/wD/AAD//gAB/wD9/wIA/wD9/wMA//8A/P8BAAD5/wAA/f8AAP3/AAD7 /wkA/wAA/wD/AP8Azv8AiIH/mf8DAAD///4A/v8BAP/9AAP/AP8A/v/8AP7/AADv//YA+/8FAP8A AP///gCZ/wMAAP///gD+/wEA//0AA/8A/wD+//wA/v8AAO//9gD7/wUA/wAA///+AJn/AwAA///+ AP7/AQD//QAD/wD/AP7//AD+/wAA7//2APv/BQD/AAD///4Azf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wCygf+y/wAA6f8EAAD//wDz//4A /v8DAP//AP7/AAD3/wQAAP//AP7/AADt/wMA//8A+P/+AP3/AAD5/wAAzP8AAOn/BAAA//8A8//+ AP7/AwD//wD+/wAA9/8EAAD//wD+/wAA7f8DAP//APj//gD9/wAA+f8AAMz/AADp/wQAAP//APP/ /gD+/wMA//8A/v8AAPf/BAAA//8A/v8AAO3/AwD//wD4//4A/f8AAPn/AADn/wEGgf+y//4A+v8C AP8A+f8AAP7/AAD+/wMAAP8A9f8AAP7/CAD//wD/AP//APj/BAD//wAA/f/+AP7/AAD8/wAA+f/+ AAL//wD6/wAA/P8DAP//AP7/AgD/AMv//gD6/wIA/wD5/wAA/v8AAP7/AwAA/wD1/wAA/v8IAP// AP8A//8A+P8EAP//AAD9//4A/v8AAPz/AAD5//4AAv//APr/AAD8/wMA//8A/v8CAP8Ay//+APr/ AgD/APn/AAD+/wAA/v8DAAD/APX/AAD+/wgA//8A/wD//wD4/wQA//8AAP3//gD+/wAA/P8AAPn/ /gAC//8A+v8AAPz/AwD//wD+/wIA/wDm/wCggf+z/wIA///zAAD//QD9//0AAP/+APb/AgD///cA 9v/6AAD/9QD5/wIA///7AP3/AgD///MAzP8CAP//8wAA//0A/f/9AAD//gD2/wIA///3APb/+gAA //UA+f8CAP//+wD9/wIA///zAMz/AgD///MAAP/9AP3//QAA//4A9v8CAP//9wD2//oAAP/1APn/ AgD///sA/f8CAP//8wDm/wEAgf+z//wAAP/8AAL/AP/6AP7/AgAA//4AA/8A/wD3/wEAAP7/AQD/ +gD4//4ACP8A/wAA//8A//4AAP/7APn//gAE/wD/AAD8/wIA///+AAP//wD/+wDL//wAAP/8AAL/ AP/6AP7/AgAA//4AA/8A/wD3/wEAAP7/AQD/+gD4//4ACP8A/wAA//8A//4AAP/7APn//gAE/wD/ AAD8/wIA///+AAP//wD/+wDL//wAAP/8AAL/AP/6AP7/AgAA//4AA/8A/wD3/wEAAP7/AQD/+gD4 //4ACP8A/wAA//8A//4AAP/7APn//gAE/wD/AAD8/wIA///+AAP//wD/+wDl/wBAgf+j/wAA/P8A ANn/AAD3/wAA7f8AAJ3/AAD8/wAA2f8AAPf/AADt/wAAnf8AAPz/AADZ/wAA9/8AAO3/AADH/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8AN4H/gf/2/wAA/v8DAP//AP3/AACB/9r/AAD+/wMA //8A/f8AAIH/2v8AAP7/AwD//wD9/wAAsf8AS4H/gf8D/wD/AP3/AQD//gAB///9AAD//QCB/+T/ AgD/AP3/AQD//gAB///9AAD//QCB/+T/AgD/AP3/AQD//gAB///9AAD//QCx/wA+gf+B//YADP8A /wD/AP8A/wAA/wCB/+X/9gAM/wD/AP8A/wD/AAD/AIH/5f/2AAz/AP8A/wD/AP8AAP8Asf8ATYH/ gf8DAP8A//4AAP/+AAL/AP/8AAD//QCB/+X/AwD/AP/+AAD//gAC/wD//AAA//0Agf/l/wMA/wD/ /gAA//4AAv8A//wAAP/9ALH/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADgAAAFBsYW5zIGZvciAtMDMADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQA AwAAAAMAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0 bGVzAAMAAAADAAAAAAAYAwAAFgAAAAAAAAC4AAAAAQAAAEsCAAACAAAAUwIAAAMAAABbAgAABAAA AGMCAAAFAAAAawIAAAYAAABzAgAABwAAAHsCAAAIAAAAlwIAAAkAAACjAgAACgAAAK8CAAALAAAA twIAAAwAAAC/AgAADQAAAMcCAAAOAAAAzwIAAA8AAADXAgAAEAAAAN8CAAARAAAA5wIAABIAAADv AgAAEwAAAPcCAAAUAAAA/wIAABUAAAAHAwAAFAAAAAIAAAANAAAAVGVtcGxhdGVUeXBlAAMAAAAM AAAAR3JhcGhpY1R5cGUABAAAAAwAAABDb21wcmVzc2lvbgAFAAAACwAAAFNjcmVlblNpemUABgAA AAwAAABTY3JlZW5Vc2FnZQAHAAAADAAAAE1haWxBZGRyZXNzAAgAAAAJAAAASG9tZVBhZ2UACQAA AAYAAABPdGhlcgAKAAAAEQAAAERvd25sb2FkT3JpZ2luYWwACwAAABEAAABEb3dubG9hZElFQnV0 dG9uAAwAAAAQAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABcAAABKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAA AA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAD+////GAAAAP7///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////bgBhAGMAYwBpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABuAAAA/78wwwAAEABafEDY/78Ix/+/MMP/v8j1kXyc9gAAAAAAAATgAACkDwoA AACAAGAAAAD/////AAClDwwAAAAAAAAILgAAAAIAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////xgA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwAL BFAGAAAPAADwSAYAAAAABvDAAwAAAtwBAHcAAAAlAAAACQAAAAEAAAAJAAAABAAAAAQAAAAIAAAA BwAAAAYAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAl AAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABgAAAAAAAAAFAAAAAAAAAAQA AAAAAAAABQAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAA AAAAAAAEAAAAAAAAABIAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAkAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAAHwAAAAAAAAAdAAAAAAAAAAQAAAACAAAACQAAAAAAAAAIAAAAAAAAAAQAAAAAAAAAFwAAAAAA AAAdAAAAAAAAABEAAAAAAAAAHAAAAAAAAAAZAAAAAAAAAAYAAAAAAAAAQgAAAAAAAAAEAAAAAAAA AH0AAAAAAAAABQAAAAAAAAAIAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAFAAAAAAAAAAoAAAAAAAAABAAAAAAAAABZAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAUAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAYA AAAAAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAIAAAAAAAAAAgAAAAAAAAABwAA AAAAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAXAAAAAAAAAB0AAAAAAAAALAAAAAAAAAAvAAAA AAAAAEMAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAABEAAAAAAAAAKwAAAAAA AAAEAAAAAAAAAAQAAAAAAAAAZwAAAAUAAAAEAAAACQAAAAQAAAAAAAAABAAAAAAAAAArAAAAAAAA AAcAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAADAAAA BAAAAAcAAAAEAAAAIwYL8EwCAACBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAIAAACIAAAAAACJ AAAAAAC/AAAADQAMAfQAABANAQAAACAOAQAAACCBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAjBAQAA AQDCAf///wDDAQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAAAADL ATUlAADMAQAACADNAQAAAADOAQAAAADPwQAAAADXAQIAAAD/AQ4ADgAAAgAAAAABAgIAAAgCAsvL ywADAgAAACAEAgAAAQAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAO AgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAQCAAgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAA AACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADE AgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBU iQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCUAADX ArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+ AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAAAwABrxDAAAAP8AAAD//wAA1gCT AEAAHvEQAAAA1gCTAP8AAAD/////9wAAEB8A8A84AAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACA AAAAAAAA8wMUAAAAKQAAAAAAAAAAAAAAAQAAgAAAAAAPANAHIRwAAA8A+gNnAAAAAAD+AwMAAAAA AQAAAP0DNAAAAH0AAABkAAAAfQAAAGQAAAAAwOgBAAAAAAAAAABQw/+/AAAAAMCfYHxA/f//kP// /wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAA AAAAAAIAAAAfAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAALDD/78pAAAAsDVYfAAAAAAU AAAAAMqaOwAAAAAAAAAAAAAAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaOzJOzckAypo7AAIAAR8A BwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAAsMP/vykAAACwNVh8AAAAALoddewAypo7AAAA AAAAAAAAAQABHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAACww/+/KQAAALA1WHwAAAAA uh117ADKmjsAAAAAAAAAAAABAAEPAIgTnhoAAA8AihOYAQAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLE3gBAAAPALMPcAEAAAAArw8IAAAAAAEAAAYAAAAAALEPIAAAAAAAAAQAAAAAAAAABAEA AAAAAAAEAgAAAAAAAAQDAAAAEACvDwgAAAAAAQAABQAAAAAAsQ8YAAAAAAAABAAAAAAAAAAEAQAA AAAAAAQCAAAAEACvDwgAAAABAQAAAQAAAAAAsQ94AAAAAAAABAAAAAAAAAAEAQAAAAAAAAQCAAAA AAAABAMAAAAAAAAEBAAAAAAAAAQFAAAAAAAABAYAAAAAAAAEBwAAAAAAAAQIAAAAAAAABAkAAAAA AAAECgAAAAAAAAQLAAAAAAAABAwAAAAAAAAEDQAAAAAAAAQOAAAAEACvDwgAAAAYAQAAAQAAAAAA sQ9gAAAAAAAABAAAAAAAAAAEAQAAAAAAAAQCAAAAAAAABAMAAAAAAAAEBAAAAAAAAAQFAAAAAAAA BAYAAAAAAAAEBwAAAAAAAAQIAAAAAAAABAkAAAAAAAAECgAAAAAAAAQLAAAADwCKE6YCAAAAALoP DgAAAF8AXwBfAFAAUABUADkAAACLE4gCAAAPAK4PgAIAAAAArw8IAAAAAAEAAAYAAAAAAKwPQAAA AAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAAAAAAABAA AwAAAAAAAAAQAK8PCAAAAAABAAAFAAAAAACsDzAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAB AAAAAAAAAAAAAAAAABAAAgAAAAAAAAAQAK8PCAAAAAEBAAABAAAAAACsD/AAAAAAAAAAAAAQAAAA AAAAAAAAAAAAAAAAEAABAAAAAAAAAAAAAAAAABAAAgAAAAAAAAAAAAAAAAAQAAMAAAAAAAAAAAAA AAAAEAAEAAAAAAAAAAAAAAAAABAABQAAAAAAAAAAAAAAAAAQAAYAAAAAAAAAAAAAAAAAEAAHAAAA AAAAAAAAAAAAABAACAAAAAAAAAAAAAAAAAAQAAkAAAAAAAAAAAAAAAAAEAAKAAAAAAAAAAAAAAAA ABAACwAAAAAAAAAAAAAAAAAQAAwAAAAAAAAAAAAAAAAAEAANAAAAAAAAAAAAAAAAABAADgAAAAAA AAAQAK8PCAAAABgBAAABAAAAAACsD8AAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAABAAAAAAAA AAAAAAAAABAAAgAAAAAAAAAAAAAAAAAQAAMAAAAAAAAAAAAAAAAAEAAEAAAAAAAAAAAAAAAAABAA BQAAAAAAAAAAAAAAAAAQAAYAAAAAAAAAAAAAAAAAEAAHAAAAAAAAAAAAAAAAABAACAAAAAAAAAAA AAAAAAAQAAkAAAAAAAAAAAAAAAAAEAAKAAAAAAAAAAAAAAAAABAACwAAAAAAAAAPAIoTaAAAAAAA ug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsTRAAAAA8AiBc8AAAAAACJFzQAAAAAAAAAAAAA AAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAAAIxwAAAAAAAAAAAACAAgHgDwCKE9gVAAAAALoP FgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsTshUAAEAAGhBmBQAABQAAAAAIDAEAAAAAAAIA AAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAA AAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAA aG5hbWQAAABgAAAAAgAAAAQAAAADAAAAAQAABAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAAD AAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQA GAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAA ABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAA AQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABg AAAAAgAAAAQAAAADAAAAAQAABAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYA TQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAA AAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAA AQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAEC AAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQA AAADAAAAAQAABAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0 AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAA AAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAA AAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAA AAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAADAAAAAQAA BAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAA VAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJ ABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgA AAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAA AAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAADAAAAAQAABAkAAAAKAEEA cgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBn AHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEA ABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAA AAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAA AAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAECQAAAAoAQQBy AGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcA cgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8A GxAgDwAAAACvDwgAAAAAAQAABgAAAAAAGRAoAQAAAAAAAAAAAAgUAQAAAAAAAgAAARQAAAAAAAAA FAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAAB AAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAAAGgA AAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAACAAA AAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAEACwA AAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAAAAAAAAAQAK8PCAAAAAABAAAFAAAA AAAZECQBAAAAAAAAAAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEA AADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEBAAAAAAABAgAAAAEAAAAAAAABAwAA AAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAA GgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwBy AG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQAIAAAAAABBwAAAAYAAAAAAAAAAAAEAAAA DgAJABEAAAAaAAEAAAAAEACvDwgAAAABAQAAAQAAAAAAGRDMBgAAAAAAAAAAAAAAAAAIFAEAAAAA AAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBuAHMA IABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIAcAAu AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgUAQAAAAAA AgAAARQAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABwbmFtZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAg AE0AUwAAAAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4A AAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACBQBAAAAAAAC AAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEA AAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAA AHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAA TQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAA AAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAAAAAAAAAAAAAA AAAIFAEAAAAAAAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAg AFMAYQBuAHMAIABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAA QwBvAHIAcAAuAAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAA AAAAAAAAAAAAAAAAAAgUAQAAAAAAAgAAARQAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA 8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAAB AAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoA QwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBv AHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4A CQARAAAAGgABAAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADw AAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEA AAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBD AG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8A cwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJ ABEAAAAaAAEAAAAAEACvDwgAAAAYAQAAAQAAAAAAGRCoBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAgU AQAAAAAAAgAAARQAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAA AQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAA AAAAAQUAAABwbmFtZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBh AG4AcwAgAE0AUwAAAAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8A cgBwAC4AAAAAAQYAAAAEABwAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAAAAAA AAAAAAAIFAEAAAAAAAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAA BAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEE AAAAAQAAAAAAAAEFAAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkA YwAgAFMAYQBuAHMAIABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBVc2VCcm93 c2VyQ29sb3IADQAAAAoAAABCYWNrQ29sb3IADgAAAAoAAABUZXh0Q29sb3IADwAAAAoAAABMaW5r Q29sb3IAEAAAAA0AAABWaXNpdGVkQ29sb3IAEQAAABIAAABUcmFuc3BhcmVudEJ1dHRvbgASAAAA CwAAAEJ1dHRvblR5cGUAEwAAAAoAAABTaG93Tm90ZXMAFAAAAAoAAABOYXZCdG5Qb3MAFQAAAAoA AABPdXRwdXREaXIAAgAAABAnAAADAAAAAQAAAAMAAAABAAAAAwAAAGQAAAADAAAAAgAAAAMAAAAB AAAAHgAAABQAAABkaW5vQHByb2NrZXQuY29tAAAAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAAsA AAAAAAAACwAAAAAAAAALAAAAAQAAAAMAAADm5uYAAwAAAAAAAAADAAAAZgD/AAMAAADMM5kAAwAA AAAAAAADAAAAAwAAAAsAAAAAAAAAAwAAAAEAAAAeAAAACAAAAEM6XFRlbXAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPJgAAABQAAABfwJHj h+wAAA4A9AMDAAACRGlubyBGYXJpbmFjY2kIAAAARABpAG4AbwAgAEYAYQByAGkAAHMAbwBmAHQA IABDAG8AcgBwAC4AAAAAAQYAAAAEACAAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgAB AAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQA AAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAA AAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMA IABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAg AEMAbwByAHAALgAAAAABBgAAAAQAIAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEA AAAIFAEAAAAAAAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAg AFMAYQBuAHMAIABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAA QwBvAHIAcAAuAAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAA AAgUAQAAAAAAAgAAARQAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABwbmFtZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAA UwBhAG4AcwAgAE0AUwAAAAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABD AG8AcgBwAC4AAAAAAQYAAAAEACAAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAA AD8A2Q8MAAAAAADaDwQAAAAAAC0ATwDZDwwAAAAAANoPBAAAAAAAPQAPAPAP5wkAAAAA8wMUAAAA AwAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPMAAAAERyYWZ0IFN0YXR1cyBVcGRh dGULZHJhZnQtaWV0Zi1saXNwLW11bHRpY2FzdC0wMgAAoQ8+AAAAMQAAAAAAABAAAIIAFAAAAAAA AAABAAAAAARDABAEAgACACQAGwAAAAAIQwAQCAIAAgAkAAEAAAAADAAAEAwQAJ8PBAAAAAUAAAAA AKgPVwAAAEFuYWhlaW0gSUVURiAtIExJU1AgV0cNRGF2ZSBNZXllciwgSm9obiBad2llYmVsLCBT dGlnIFZlbmFhcywgRGlubyBGYXJpbmFjY2kNTWFyY2ggMjAxMAAAoQ8uAAAAWAAAAAAAAAAAAA8A AAACAAIAAgAcAAgAAAACBAIAAgQcAEEAAAACCAIAAggUAAAAqg9QAAAAFgAAAAAAAAABAAAAAQAA AAAAEQAAAAAAAAAHAAAAAQAAAAMAAgAAAAAAAAALAAAAAQAAAAMABwAAAAAAAAAKAAAAAQAAAAMA CwAAAAAAAAAAAPMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABE cmFmdCBIaXN0b3J5EACfDwQAAAABAAAAAACoD4YBAABkcmFmdC1pZXRmLWxpc3AtbXVsdGljYXN0 LTAwDVB1Ymxpc2hlZCBpbiBBcHJpbCAyMDA4DVJlbmFtZWQgZnJvbSBkcmFmdC1mYXJpbmFjY2kt bGlzcC1tdWx0aWNhc3QtMDENZHJhZnQtaWV0Zi1saXNwLW11bHRpY2FzdC0wMQ1QdWJsaXNoZWQg aW4gTm92ZW1iZXIgMjAwOA1FeHBlcnQgUmV2aWV3IGJ5IExpbWluZyBXZWksIFlpcXVuIENhaSwg VG9tIFB1c2F0ZXJpLCBTdGV2ZSBDYXNuZXIsIE1hcnNoYWxsIEV1YmFua3MsIERpbWl0cmkgUGFw YWRpbWl0cmlvdSwgUm9uIEJvbmljYSwgYW5kIExlbm55IEd1YXJkaW5vDWRyYWZ0LWlldGYtbGlz cC1tdWx0aWNhc3QtMDINUHVibGlzaGVkIGluIFNlcHRlbWJlciAyMDA5DUJyaW5nIGluIHN5bmMg d2l0aCBkcmFmdC1pZXRmLWxpc3AtMDYAAKEPAgEAAB0AAAAAAAAAAABHAAAAAQAAAAAAHQAAAAAA AAAAAKcAAAABAAAAAAAdAAAAAAAAAAAAQgAAAAEAAAAAAB0AAAAAAEMAAgACABgAGAAAAAAEAgAA BBQADQAAAAAIAgAACBQAIQAAAAAMQwAADAIAAgAUAAEAAAAAEAIAABAUABwAAAAAFEMAABQCAAIA GAABAAAAABgCAAAYGAAbAAAAABwCAAAcFAARAAAAACACAAAgFAB7AAAAACQCAAAkFAAdAAAAAChD AAAoAgACABgAHAAAAAAsAgAALBQAEwAAAAAwAgAAMBQAEgAAAAA0QwAANAIAAgAUAAEAAAAAOAIA ADgUAAAAqg+YAAAAmwAAAAAAAAABAAAAAQAAAAAAGAAAAAAAAAADAAAAAQAAAAMAAgAAAAAAAAAJ AAAAAQAAAAMABgAAAAAAAAAIAAAAAQAAAAMACAAAAAAAAAAGAAAAAQAAAAMAFAAAAAAAAAAIAAAA AQAAAAMAEwAAAAAAAAAGAAAAAQAAAAMADAAAAAAAAAAJAAAAAQAAAAMAXwAAAAAAAAAAAPMDFAAA AHYAAAAAAAAAAgAAABgBAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABQbGFucyBmb3IgLTAzEACf DwQAAAABAAAAAACgD+oCAABCAHIAaQBuAGcAIABpAG4AIABzAHkAbgBjACAAdwBpAHQAaAAgAGQA cgBhAGYAdAAtAGkAZQB0AGYALQBsAGkAcwBwAC0AaQBuAHQAZQByAHcAbwByAGsALQAwADEADQBV AG4AaQBjAGEAcwB0ACAAUABUAFIAcwAgAGEAcgBlACAAYwBhAGwAbABlAGQAIAB1AFAASQBUAFIA cwANAE0AdQBsAHQAaQBjAGEAcwB0ACAAUABUAFIAcwAgAGEAcgBlACAAYwBhAGwAbABlAGQAIABt AFAARQBUAFIAcwANAEoAbwBlAGwAIABjAG8AbQBtAGUAbgB0AA0AKABTAC0ARQBJAEQALAAgAEcA KQAgAGoAbwBpAG4AZQBkACAAdABoAHIAbwB1AGcAaAAgAGQAaQBmAGYAZQByAGUAbgB0ACAAcwBv AHUAcgBjAGUAIABSAEwATwBDAHMAIABkAG8AZQBzACAAbgBvAHQAIABjAGEAdQBzAGUAIABkAHUA cABsAGkAYwBhAHQAZQBzAA0ARABpAG4AbwAgAGYAbwB1AG4AZAAgAGIAdQBnAHMADQBDAGwAYQBy AGkAZgB5ACAAaABvAHcAIABtAGkAeABlAGQAIABsAG8AYwBhAHQAbwByAHMAIABzAGgAbwB1AGwA ZABuABkgdAAgAGIAZQAgAHUAcwBlAGQAIABmAG8AcgAgAG0AdQBsAHQAaQBjAGEAcwB0ACAADQBD AGwAYQByAGkAZgB5ACAAdwBoAGEAdAAgAG0AUABFAFQAUgBzACAAZABvACAAdwBoAGUAbgAgAGQA ZQBjAGEAcABzAHUAbABhAHQAZQBkACAAcABhAGMAawBlAHQAIABoAGEAcwAgAGQAaQBmAGYAZQBy AGUAbgB0ACAAQQBGACAAdwBpAHQAaAAgAG4AbwAgAHIAZQBjAGUAaQB2AGUAcgBzACAALQAgAGQA cgBvAHAAIABwAGEAYwBrAGUAdAANAAAAoQ/aAAAAMAAAAAAAABAAAFoAQAAAAAEAABAAAFoADQAA AAAAABAAAFoASwAAAAEAABAAAFoAEAAAAAAAABAAAFoAngAAAAEAABAAAFoAEwAAAAAAAgAcABwA AAAABEMAAAQCAAIAFAABAAAAAAgCAAAIFAAfAAAAAAwCAAAMGAAhAAAAABACAAAQGAANAAAAABQC AAAUHABLAAAAABgCAAAYGAAQAAAAABwCAAAcHAA8AAAAACACAAAgGABgAAAAACQCAAAkGAABAAAA ACgCAAAoGAABAAAAACwCAAAsGAAAAKoPogAAADAAAAAAAAAADQAAAAEAAAADAAoAAAAAAAAAAQAA AAEAAAAAAAcAAAABAAAAAwAKAAAAAAAAAAUAAAABAAAAAwALAAAAAAAAAAcAAAABAAAAAwA4AAAA AAAAAAYAAAABAAAAAwBkAAAAAAAAAAIAAAABAAAAAAANAAAAAAAAAAcAAAABAAAAAwAIAAAAAAAA AA0AAAABAAAAAwA5AAAAAAAAAC8A8A9UAAAAAADzAxQAAABpAAAAAAAAAAAAAAAAAQAAAAAAAAAA 8wMUAAAAagAAAAAAAAAAAAAAAQEAAAAAAAAAAPMDFAAAAHcAAAAAAAAAAAAAAAIBAAAAAAAAAADq AwAAAAAPAO4DUiQAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAIBAAAHAHJgDwAMBLQBAAAPAALw rAEAADAACPAIAAAAAwAAAAPUAQAPAAPwRAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA08GxoQAAsaHT wbGhAgAK8AgAAAAA1AEABQAAAA8ABPBsAAAAEgAK8AgAAAAC1AEAIAIAAEMAC/AYAAAAgADQRf0y vwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACQALAB0BRgAw8AEfAQAAAAAADDCwgAAAAAAAAADQB6 AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8JgAAAASAArwCAAAAAPUAQAgAgAAQwAL8BgAAACAAKBF 9zK/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAMADIAHwFeANDwAR8DwAAAAPABQQJAAAAAEA8Q8c AAAAAAAABwAAAAAAAAAAAAAAAAIAAQACDAMAAAAAPAAAwwsIAAAAAQAAAA4AvCAPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAAB1AEAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAA AMyZADMzzADMzP8AsrKyAA8AiBNGIgAADwCKEz4iAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA AIsTHiIAAAAA6y4IAAAAqRR3AABayRoAAB0QBAAAAAAAAAAAAAArBAAAACF5BrwfAETxriEAAAAA J/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAQIAA/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkA AAAfAETxaSEAAAAAJ/EgAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAA/////xgAAAAPAD3xDQAA AEABQvEFAAAAAQQAAAAAAEHxFAAAAAEAAAABAAAAAAAAAAAAAAADAAAAPwAl8SwAAAAAACjxEAAA AAEAAAAJAAAAAAAAAAAAAAAPADzxDAAAAAAAASsEAAAAAQAAAE8AJfEsAAAAAAAo8RAAAAABAAAA CgAAAAAAAAAAAAAADwA88QwAAAAAAAErBAAAAAEAAAAfAETxIQwAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAD/////HwBE8ckLAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA9 8QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPHLAwAAAAAn8SAAAAAAAAAA AAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAQAAAJAAQvEFAAAA AQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQ AAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAA AAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMA aQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAA AANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAAB AAAAA9QBAAAAAAAwAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAA J/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA0 8QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4 AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAA AwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0 AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQAAAAAAMAAAAB8ARPEZAQAAAAAn8SAA AAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAA AAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBo AC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELx AwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANw AHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAAAAAADAAAAAfAETxywMAAAAA J/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIA AACQAELxBQAAAAECAAAAoABC8QUAAAABBAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl 8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAA AwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvER AAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvEr AAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7 KhQAAAACAAAAAQAAAAPUAQAwAAAATwAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA HwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAP ACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMj AHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgA AAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELx DQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAMAAAAE8AAAAfAETx GQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/Hh AAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAj AHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQA XwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAA AABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBADAAAABPAAAA HwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABA AULxBQAAAAECAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUA AAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAA AAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAA AAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAA AAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAP ADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEATwAAAHAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAA AAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAA AA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAA AABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMA cABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8A PvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAE8A AABwAAAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA9 8QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELx FwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAA AAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAA AAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPU AQBPAAAAcAAAAB8ARPFOCAAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA AA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETx9gcAAAAAJ/EgAAAA AAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAA AAAAAAAAAAAAAAAAAAAAHwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAA AAABAAAADwA98UEAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELx BQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE 8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHx oAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPx EAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkA YgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAcAAAAH0AAAAfACXxGAAA AAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAA AAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/Fc AAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA 6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAA AAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAA AAIAAAABAAAAA9QBAHAAAAB9AAAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAA AAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAA AEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPx BAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAA AAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7 KhQAAAACAAAAAQAAAAPUAQBwAAAAfQAAAB8ARPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAA AAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAA AAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAA AAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8A PfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8A KvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUA LgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAH0AAADI AAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAA AAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAA AAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAAD AAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAA ADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEc AAAAAAD7KhQAAAACAAAAAQAAAAPUAQB9AAAAyAAAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMA AAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAA AA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvED AAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZ AAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAP ADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAfQAAAMgAAAAfAETxIQwAAAAAJ/EgAAAAAAAAAAAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAA AAAAAAD/////HwBE8ckLAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAA DwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPHLAwAAAAAn8SAAAAAA AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAQAAAJAAQvEF AAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAA KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAA AAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBp AHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELx IwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIA AAABAAAAA9QBAMgAAADYAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEA AAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAA AAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQA XwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvED AAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AA cAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQDIAAAA2AAAAB8ARPEZAQAAAAAn 8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTx DAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcAAAADMQArACMAcABwAHQA XwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQ AELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAA AANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAyAAAANgAAAAfAETxywMA AAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAA AQIAAACQAELxBQAAAAECAAAAoABC8QUAAAABBAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAA HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAAD AAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAA QvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8A PvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAA AAD7KhQAAAACAAAAAQAAAAPUAQDYAAAAFAEAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA AAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAA AAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAA AAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABf AHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAA AELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEA2AAAABQBAAAf AETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8A K/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEA KwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABw AHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEV AAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBANgAAAAU AQAAHwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEA AABAAULxBQAAAAECAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC 8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAA AAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAA AQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAA AAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkA AAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAFAEAAHUBAAAfACXxGAAAAAAAKPEQAAAAAAAA AAAAAAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAA GQAAAA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAA AAAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAA AyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAA AB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QB ABQBAAB1AQAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAA DwA98QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAA AELxFwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELx DwAAAAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAA AAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAA AAPUAQAUAQAAdQEAAA8AAis4AAAADwAIKzAAAAAAAAMrEAAAAAEAAAAAAAAAA9QBAAEAAAABAAkr EAAAAAEAAAABAAAAAAAAAAAAAAAAAHIXEAAAAAEAEADrmAAAdgAQABXIAAAAAPUPHAAAABgBAAAH IgADx5gAAG/sAAABAAAAeAAAAAEAx2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAUA//////////8BAAAAEI2BZJtPzxGG6gCq ALkp6AAAAAAAAAAAAAAAAACKf4ivycoBUAAAAEAGAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAg AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAq+wAAAAAAAAFAFMAdQBt AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFEAAACc JwAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAIwFAAAAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAA igAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAP7///+XAAAA/f////3////+ /////v////7///+ZAAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA ACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAA NQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABD AAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABpAAAA/////2UA AABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAA AGAAAABhAAAAYgAAAGMAAABkAAAA/v///5oAAAD///////////////9qAAAAawAAAGwAAABtAAAA bgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB6AAAA/////3sAAAB8 AAAAfQAAAH4AAAB/AAAAgAAAAEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFwAAAEoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAA AAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAAP7///8YAAAA /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////9uAGEAYwBjAGkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABVc2VCcm93c2VyQ29sb3IADQAAAAoAAABCYWNrQ29sb3IADgAAAAoA AABUZXh0Q29sb3IADwAAAAoAAABMaW5rQ29sb3IAEAAAAA0AAABWaXNpdGVkQ29sb3IAEQAAABIA AABUcmFuc3BhcmVudEJ1dHRvbgASAAAACwAAAEJ1dHRvblR5cGUAEwAAAAoAAABTaG93Tm90ZXMA FAAAAAoAAABOYXZCdG5Qb3MAFQAAAAoAAABPdXRwdXREaXIAAgAAABAnAAADAAAAAQAAAAMAAAAB AAAAAwAAAGQAAAADAAAAAgAAAAMAAAABAAAAHgAAABQAAABkaW5vQHByb2NrZXQuY29tAAAAAB4A AAAEAAAAAAAAAB4AAAAEAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAQAAAAMAAADm5uYAAwAA AAAAAAADAAAAZgD/AAMAAADMM5kAAwAAAAAAAAADAAAAAwAAAAsAAAAAAAAAAwAAAAEAAAAeAAAA CAAAAEM6XFRlbXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAPYPJgAAABQAAABfwJHjh+wAAA4A9AMDAAACRGlubyBGYXJpbmFjY2kIAAAARABp AG4AbwAgAEYAYQByAGkA --Apple-Mail-4-808289125 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-4-808289125 Content-Disposition: attachment; filename=rfcdiff-lisp-multicast-02-to-03.html Content-Type: text/html; x-unix-mode=0600; name="rfcdiff-lisp-multicast-02-to-03.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-multicast-02.txt draft-ietf-lisp-multicast-03.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                                 J. Zwiebel
Expires: April 2, October 14, 2010                                      S. Venaas
                                                           cisco Systems
                                                      September 29, 2009
                                                          April 12, 2010

                    LISP for Multicast Environments
                    draft-ietf-lisp-multicast-02.txt
                      draft-ietf-lisp-multicast-03

Abstract

   This draft describes how inter-domain multicast routing will function
   in an environment where Locator/ID Separation is deployed using the
   LISP architecture.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 2, October 14, 2010.

Copyright Notice

   Copyright (c) 2009 2010 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 (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   This draft describes how inter-domain multicast routing will function  Code Components extracted from this document must
   include Simplified BSD License text as described in an environment where Locator/ID Separation is deployed using Section 4.e of
   the
   LISP architecture. Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Source Addresses versus Group Addresses  . . . . . . . . . . . 12
   6.  Locator Reachability Implications on LISP-Multicast  . . . . . 13
   7.  Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14
   8.  LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16
     8.1.  ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
       8.1.1.  Multiple RLOCs for an ITR  . . . . . . . . . . . . . . 16
       8.1.2.  Multiple ITRs for a LISP Source Site . . . . . . . . . 17
     8.2.  ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
     8.3.  Replication Locations  . . . . . . . . . . . . . . . . . . 17
   9.  LISP-Multicast Interworking  . . . . . . . . . . . . . . . . . 19
     9.1.  LISP and non-LISP Mixed Sites  . . . . . . . . . . . . . . 19
       9.1.1.  LISP Source Site to non-LISP Receiver Sites  . . . . . 20
       9.1.2.  Non-LISP Source Site to non-LISP Receiver  Sites . . . 21
       9.1.3.  Non-LISP Source Site to Any Receiver Site  . . . . . . 22
       9.1.4.  Unicast LISP Source Site to Any Receiver Sites . . . 22 . 23
       9.1.5.  LISP Source Site to Any Receiver Sites . . . . . . . . 23
     9.2.  LISP Sites with Mixed Address Families . . . . . . . . . . 23 24
     9.3.  Making a Multicast Interworking Decision . . . . . . . . . 25 26
   10. Considerations when RP Addresses are Embedded in Group
       Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . . 26 27
   11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27 28
   12. Mtrace Considerations  . . . . . . . . . . . . . . . . . . . . 28 29
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 29 30
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 30 31
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 32
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 32
     15.2. Informative References . . . . . . . . . . . . . . . . . . 31 32
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 33 34
     A.1.  Changes to draft-ietf-lisp-multicsat-02.txt draft-ietf-lisp-multicast-03.txt  . . . . . . . 33 34
     A.2.  Changes to draft-ietf-lisp-multicsat-01.txt draft-ietf-lisp-multicast-02.txt  . . . . . . . 33 34
     A.3.  Changes to draft-ietf-lisp-multicsat-00.txt draft-ietf-lisp-multicast-01.txt  . . . . . . . 34
     A.4.  Changes to draft-ietf-lisp-multicast-00.txt  . . . . . . . 33 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 36

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   The Locator/ID Separation Architecture [LISP] provides a mechanism to
   separate out Identification and Location semantics from the current
   definition of an IP address.  By creating two namespaces, an EID
   namespace used by sites and a Locator (RLOC) namespace used by core
   routing, the core routing infrastructure can scale by doing
   topological aggregation of routing information.

   Since LISP creates a new namespace, a mapping function must exist to
   map a site's EID prefixes to its associated locators.  For unicast
   packets, both the source address and destination address must be
   mapped.  For multicast packets, only the source address needs to be
   mapped.  The destination group address doesn't need to be mapped
   because the semantics of an IPv4 or IPv6 group address are logical in
   nature and not topology-dependent.  Therefore, this specifications
   focuses on to map a source EID address of a multicast flow during
   distribution tree setup and packet delivery.

   This specification will address the following scenarios:

   1.  How a multicast source host in a LISP site sends multicast
       packets to receivers inside of its site as well as to receivers
       in other sites that are LISP enabled.

   2.  How inter-domain (or between LISP sites) multicast distribution
       trees are built and how forwarding of multicast packets leaving a
       source site toward receivers sites is performed.

   3.  What protocols are affected and what changes are required to such
       multicast protocols.

   4.  How ASM-mode, SSM-mode, and Bidir-mode service models will
       operate.

   5.  How multicast packet flow will occur for multiple combinations of
       LISP and non-LISP capable source and receiver sites, for example:

       A.  How multicast packets from a source host in a LISP site are
           sent to receivers in other sites when they are all non-LISP
           sites.

       B.  How multicast packets from a source host in a LISP site are
           sent to receivers in both LISP-enabled sites and non-LISP
           sites.

       C.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in other sites when they are all LISP-
           enabled sites.

       D.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in both LISP-enabled sites and non-LISP
           sites.

   This specification focuses on what changes are needed to the
   multicast routing protocols to support LISP-Multicast as well as
   other protocols used for inter-domain multicast, such as Multi-
   protocol BGP (MBGP) [RFC4760].  The approach proposed in this
   specification requires no changes to the multicast infrastructure
   inside of a site when all sources and receivers reside in that site,
   even when the site is LISP enabled.  That is, internal operation of
   multicast is unchanged regardless of whether or not the site is LISP
   enabled or whether or not receivers exist in other sites which are
   LISP-enabled.

   Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
   and PIM-SSM [RFC4607].  Bidir-PIM [RFC5015], which typically does not
   run in an inter-domain environment is not addressed in depth in this
   version of the specification.

   Also, the current version of this specification does not describe
   multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
   descriptions in [LISP].

3.  Definition of Terms

   The terminology in this section is consistent with the definitions in
   [LISP] but is extended specifically to deal with the application of
   the terminology to multicast routing.

   LISP-Multicast:   a reference to the design in this specification.
      That is, when any site that is participating in multicast
      communication has been upgraded to be a LISP site, the operation
      of control-plane and data-plane protocols is considered part of
      the LISP-Multicast architecture.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source address field of the first (most inner) LISP
      header of a multicast packet.  The host obtains a destination
      group address the same way it obtains one today, as it would when
      it is a non-LISP site.  The source EID is obtained via existing
      mechanisms used to set a host's "local" IP address.  An EID is
      allocated to a host from an EID prefix block associated with the
      site the host is located in.  An EID can be used by a host to
      refer to another host, as when it joins an SSM (S-EID,G) route
      using IGMP version 3 [RFC4604].  LISP uses Provider Independent
      (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs.
      Note that EID blocks may be assigned in a hierarchical manner,
      independent of the network topology, to facilitate scaling of the
      mapping database.  In addition, an EID block assigned to a site
      may have site-local structure (subnetting) for routing within the
      site; this structure is not visible to the global routing system.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an ingress
      tunnel router (ITR), the router in the multicast source host's
      site that encapsulates multicast packets.  It is the output of a
      EID-to-RLOC mapping lookup.  An EID maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically-aggregatable
      blocks that are assigned to a site at each point to which it
      attaches to the global Internet; where the topology is defined by
      the connectivity of provider networks, RLOCs can be thought of as
      Provider Assigned (PA) addresses.  Multiple RLOCs can be assigned
      to the same ITR device or to multiple ITR devices at a site.

   Ingress Tunnel Router (ITR):   a router which accepts an IP multicast
      packet with a single IP header (more precisely, an IP packet that
      does not contain a LISP header).  The router treats this "inner"
      IP destination multicast address opaquely so it doesn't need to
      perform a map lookup on the group address because it is
      topologically insignificant.  The router then prepends an "outer"
      IP header with one of its globally-routable RLOCs as the source
      address field.  This RLOC is known to other multicast receiver
      sites which have used the mapping database to join a multicast
      tree for which the ITR is the root.  In general, an ITR receives
      IP packets from site end systems on one side and sends LISP-
      encapsulated multicast IP packets out all external interfaces
      which have been joined.

      An ITR would receive a multicast packet from a source inside of
      its site when 1) it is on the path from the multicast source to
      internally joined receivers, or 2) when it is on the path from the
      multicast source to externally joined receivers.

   Egress Tunnel Router (ETR):   a router that is on the path from a
      multicast source host in another site to a multicast receiver in
      its own site.  An ETR accepts a PIM Join/Prune message from a site
      internal PIM router destined for the source's EID in the multicast
      source site.  The ETR maps the source EID in the Join/Prune
      message to an RLOC address based on the EID-to-RLOC mapping.  This
      sets up the ETR to accept multicast encapsulated packets from the
      ITR in the source multicast site.  A multicast ETR decapsulates
      multicast encapsulated packets and replicates them on interfaces
      leading to internal receivers.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality can be at the
      CE router.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP header.  An ITR
      prepends headers and an ETR strips headers.  A LISP encapsulated
      multicast packet will have an "inner" header with the source EID
      in the source field; an "outer" header with the source RLOC in the
      source field: and the same globally unique group address in the
      destination field of both the inner and outer header.

   (S,G) State:   the formal definition is in the PIM Sparse Mode
      [RFC4601] specification.  For this specification, the term is used
      generally to refer to multicast state.  Based on its topological
      location, the (S,G) state resides in routers can be either
      (S-EID,G) state (at a location where the (S,G) state resides) or
      (S-RLOC,G) state (in the Internet core).

   (S-EID,G) State:   refers to multicast state in multicast source and
      receiver sites where S-EID is the IP address of the multicast
      source host (its EID).  An S-EID can appear in an IGMPv3 report,
      an MSDP SA message or a PIM Join/Prune message that travels inside
      of a site.

   (S-RLOC,G) State:   refers to multicast state in the core where S is
      a source locator (the IP address of a multicast ITR) of a site
      with a multicast source.  The (S-RLOC,G) is mapped from (S-EID,G)
      entry by doing a mapping database lookup for the EID prefix that
      S-EID maps to.  An S-RLOC can appear in a PIM Join/Prune message
      when it travels from an ETR to an ITR over the Internet core.

   uLISP Site:   a unicast only LISP site according to [LISP] which has
      not deployed the procedures of this specification and therefore,
      for multicast purposes, follows the procedures from Section 9.

   mPTR:

   mPETR:   this is a multicast PTR proxy-ETR that is responsible for
      advertising a very coarse EID prefix which non-LISP and uLISP
      sites can target their (S-EID,G) PIM Join/Prune message to. mPTRs mPETRs
      are used so LISP source multicast sites can send multicast packets
      using source addresses from the EID namespace. mPTRs mPETRs act as Proxy
      ETRs for supporting multicast routing in a LISP infrastructure.
      It is likely an uPITR and a mPETR will be co-loacted since the
      single device advertises a coarse EID-prefix in the underlying
      unicast routing system.

   Mixed Locator-Sets:   this is a locator-set for a LISP database
      mapping entry where the RLOC addresses in the locator-set are in
      both IPv4 and IPv6 format.

   Unicast Encapsulated PIM Join/Prune Message:   this is a standard PIM
      Join/Prune message (encapsulated in a LISP Encapsulated Control
      Message with destination UDP port 4342) which is sent by ETRs at
      multicast receiver sites to an ITR at a multicast source site.
      This message is sent periodically as long as there are interfaces
      in the oif-list for the (S-EID,G) entry the ETR is joining for.

4.  Basic Overview

   LISP, when used for unicast routing, increases the site's ability to
   control ingress traffic flows.  Egress traffic flows are controlled
   by the IGP in the source site.  For multicast, the IGP coupled with
   PIM can decide which path multicast packets ingress.  By using the
   traffic engineering features of LISP, a multicast source site can
   control the egress of its multicast traffic.  By controlling the
   priorities of locators from a mapping database entry, a source
   multicast site can control which way multicast receiver sites join to
   the source site.

   At this point in time, we don't see a requirement for different
   locator-sets, priority, and weight policies for multicast than we
   have for unicast.

   The fundamental multicast forwarding model is to encapsulate a
   multicast packet into another multicast packet.  An ITR will
   encapsulate multicast packets received from sources that it serves in
   another LISP multicast header.  The destination group address from
   the inner header is copied to the destination address of the outer
   header.  The inner source address is the EID of the multicast source
   host and the outer source address is the RLOC of the encapsulating
   ITR.

   The LISP-Multicast architecture will follow this high-level protocol
   and operational sequence:

   1.  Receiver hosts in multicast sites will join multicast content the
       way they do today, they use IGMP.  When they use IGMPv3 where
       they specify source addresses, they use source EIDs, that is they
       join (S-EID,G).  If the S-EID is a local multicast source host.
       If the multicast source is external to this receiver site, the
       PIM Join/Prune message flows toward the ETRs, finding the
       shortest exit (that is the closest exit for the Join/Prune
       message but it is the closest entrance for the multicast packet
       to the receiver).

   2.  The ETR does a mapping database lookup for S-EID.  If the mapping
       is cached from a previous lookup (from either a previous Join/
       Prune for the source multicast site or a unicast packet that went
       to the site), it will use the RLOC information from the mapping.
       The ETR will use the same priority and weighting mechanism as for
       unicast.  So the source site can decide which way multicast
       packets egress.

   3.  The ETR will build two PIM Join/Prune messages, one that contains
       a (S-EID,G) entry that is unicast to the ITR that matches the
       RLOC the ETR selects, and the other which contains a (S-RLOC,G)
       entry so the core network can create multicast state from this
       ETR to the ITR.

   4.  When the ITR gets the unicast Join/Prune message (see Section 3
       for formal definition), it will process (S-EID,G) entries in the
       message and propagate them inside of the site where it has
       explicit routing information for EIDs via the IGP.  When the ITR
       receives the (S-RLOC,G) PIM Join/Prune message it will process it
       like any other join it would get in today's Internet.  The S-RLOC
       address is the IP address of this ITR.

   5.  At this point there is (S-EID,G) state from the joining host in
       the receiver multicast site to the ETR of the receiver multicast
       site.  There is (S-RLOC,G) state across the core network from the
       ETR of the multicast receiver site to the ITR in the multicast
       source site and (S-EID,G) state in the source multicast site.
       Note, the (S-EID,G) state is the same S-EID in each multicast
       site.  As other ETRs join the same multicast tree, they can join
       through the same ITR (in which case the packet replication is
       done in the core) or a different ITR (in which case the packet
       replication is done at the source site).

   6.  When a packet is originated by the multicast host in the source
       site, it will flow to one or more ITRs which will prepend a LISP
       header by copying the group address to the outer destination
       address field and insert its own locator address in the outer
       source address field.  The ITR will look at its (S-RLOC,G) state,
       where S-RLOC is its own locator address, and replicate the packet
       on each interface a (S-RLOC,G) joined was received on.  The core
       has (S-RLOC,G) so where fanout occurs to multiple sites, a core
       router will do packet replication.

   7.  When either the source site or the core replicates the packet,
       the ETR will receive a LISP packet with a destination group
       address.  It will also decapsulate packets because it has
       receivers for the group.  Otherwise, it would have not received
       the packets because it would not have joined.  The ETR
       decapsulates and does a (S-EID,G) lookup in its multicast FIB to
       forward packets out one or more interfaces to forward the packet
       to internal receivers.

   This architecture is consistent and scalable with the architecture
   presented in [LISP] where multicast state in the core operates on
   locators and multicast state at the sites operates on EIDs.

   Alternatively, [LISP] does present a mechanism where (S-EID,G) state
   can reside in the core through the use of RPF-vectors [RPFV] in PIM
   Join/Prune messages.  However, this will require EID state in core as
   well as the use of RPF-vector formatted Join/Prune messages which are
   not the default implementation choice.  So we choose a design that
   can allow the separation of namespaces as unicast LISP provides.  It
   will be at the expense of creating new (S-RLOC,G) state when ITRs go
   unreachable.  See Section 5 for details.

   However, we have some observations on the algorithm above.  We can
   scale the control plane but at the expense of sending data to sites
   which may have not joined the distribution tree where the
   encapsulated data is being delivered.  For example, one site joins
   (S-EID1,G) and another site joins (S-EID2,G).  Both EIDs are in the
   same multicast source site.  Both multicast receiver sites join to
   the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the
   ITR.  The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the
   site.  The ITR receives (S-RLOC,G) joins and populates the oif-list
   state for it.  Since both (S-EID1,G) and (S-EID2, G) map to the one
   (S-RLOC,G) packets will be delivered by the core to both multicast
   receiver sites even though each have joined a single source-based
   distribution tree.  This behavior is a consequence of the many-to-one
   mapping between S-EIDs and a S-RLOC.

   There is a possible solution to this problem which reduces the number
   of many-to-one occurrences of (S-EID,G) entries aggregating into a
   single (S-RLOC,G) entry.  If a physical ITR can be assigned multiple
   RLOC addresses and these addresses are advertised in mapping database
   entries, then ETRs at receiver sites have more RLOC address options
   and therefore can join different (RLOC,G) entries for each (S-EID,G)
   entry joined at the receiver site.  It would not scale to have a one-
   to-one relationship between the number of S-EID sources at a source
   site and the number of RLOCs assigned to all ITRs at the site, but we
   can reduce the "n" to a smaller number in the "n-to-1" relationship.
   And in turn, reduce the opportunity for data packets to be delivered
   to sites for groups not joined.

5.  Source Addresses versus Group Addresses

   Multicast group addresses don't have to be associated with either the
   EID or RLOC namespace.  They actually are a namespace of their own
   that can be treated as logical with relatively opaque allocation.
   So, by their nature, they don't detract from an incremental
   deployment of LISP-Multicast.

   As for source addresses, as in the unicast LISP scenario, there is a
   decoupling of identification from location.  In a LISP site, packets
   are originated from hosts using their allocated EIDs, those addresses
   are used to identify the host as well as where in the site's topology
   the host resides but not how and where it is attached to the
   Internet.

   Therefore, when multicast distribution tree state is created anywhere
   in the network on the path from any multicast receiver to a multicast
   source, EID state is maintained at the source and receiver multicast
   sites, and RLOC state is maintained in the core.  That is, a
   multicast distribution tree will be represented as a 3-tuple of
   {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the
   3-tuple is the state stored in routers from the source to one or more
   ITRs in the source multicast site, the second element of the 3-tuple
   is the state stored in routers downstream of the ITR, in the core, to
   all LISP receiver multicast sites, and the third element in the
   3-tuple is the state stored in the routers downstream of each ETR, in
   each receiver multicast site, reaching each receiver.  Note that
   (S-EID,G) is the same in both the source and receiver multicast
   sites.

   The concatenation/mapping from the first element to the second
   element of the 3-tuples is done by the ITR and from the second
   element to the third element is done at the ETRs.

6.  Locator Reachability Implications on LISP-Multicast

   Multicast state as it is stored in the core is always (S,G) state as
   it exists today or (S-RLOC,G) state as it will exist when LISP sites
   are deployed.  The core routers cannot distinguish one from the
   other.  They don't need to because it is state that RPFs against the
   core routing tables in the RLOC namespace.  The difference is where
   the root of the distribution tree for a particular source is.  In the
   traditional multicast core, the source S is the source host's IP
   address.  For LISP-Multicast the source S is a single ITR of the
   multicast source site.

   An ITR is selected based on the LISP EID-to-RLOC mapping used when an
   ETR propagates a PIM Join/Prune message out of a receiver multicast
   site.  The selection is based on the same algorithm an ITR would use
   to select an ETR when sending a unicast packet to the site.  In the
   unicast case, the ITR can change on a per-packet basis depending on
   the reachability of the ETR.  So an ITR can change relatively easily
   using local reachability state.  However, in the multicast case, when
   an ITR goes unreachable, new distribution tree state must be built
   because the encapsulating root has changed.  This is more significant
   than an RPF-change event, where any router would typically locally
   change its RPF-interface for its existing tree state.  But when an
   encapsulating LISP-Multicast ITR goes unreachable, new distribution
   state must be rebuilt and reflect the new encapsulator.  Therefore,
   when an ITR goes unreachable, all ETRs that are currently joined to
   that ITR will have to trigger a new Join/Prune message for (S-RLOC,G)
   to the new ITR as well as send a unicast encapsulated Join/Prune
   message telling the new ITR which (S-EID,G) is being joined.

   This issue can be mitigated by using anycast addressing for the ITRs
   so the problem does reduce to an RPF change in the core, but still
   requires a unicast encapsulated Join/Prune message to tell the new
   ITR about (S-EID,G).  The problem with this approach is that the ETR
   really doesn't know when the ITR has changed so the new anycast ITR
   will get the (S-EID,G) state only when the ETR sends it the next time
   during its periodic sending procedures.

7.  Multicast Protocol Changes

   A number of protocols are used today for inter-domain multicast
   routing:

   IGMPv1-v3, MLDv1-v2:   These protocols do not require any changes for
      LISP-Multicast for two reasons.  One being that they are link-
      local and not used over site boundaries and second they advertise
      group addresses that don't need translation.  Where source
      addresses are supplied in IGMPv3 and MLDv2 messages, they are
      semantically regarded as EIDs and don't need to be converted to
      RLOCs until the multicast tree-building protocol, such as PIM, is
      received by the ETR at the site boundary.  Addresses used for IGMP
      and MLD come out of the source site's allocated addresses which
      are therefore from the EID namespace.

   MBGP:   Even though MBGP is not a multicast routing protocol, it is
      used to find multicast sources when the unicast BGP peering
      topology and the multicast MBGP peering topology are not
      congruent.  When MBGP is used in a LISP-Multicast environment, the
      prefixes which are advertised are from the RLOC namespace.  This
      allows receiver multicast sites to find a path to the source
      multicast site's ITRs.  MBGP peering addresses will be from the
      RLOC namespace.

   MSDP:   MSDP is used to announce active multicast sources to other
      routing domains (or LISP sites).  The announcements come from the
      PIM Rendezvous Points (RPs) from sites where there are active
      multicast sources sending to various groups.  In the context of
      LISP-Multicast, the source addresses advertised in MSDP will
      semantically be from the EID namespace since they describe the
      identity of a source multicast host.  It will be true that the
      state stored in MSDP caches from core routers will be from the EID
      namespace.  An RP address inside of site will be from the EID
      namespace so it can be advertised and reached by internal unicast
      routing mechanism.  However, for MSDP peer-RPF checking to work
      properly across sites, the RP addresses must be converted or
      mapped into a routable address that is advertised and maintained
      in the BGP routing tables in the core.  MSDP peering addresses can
      come out of either the EID or a routable address namespace.  And
      the choice can be made unilaterally because the ITR at the site
      will determine which namespace the destination peer address is out
      of by looking in the mapping database service.

   PIM-SSM:   In the simplest form of distribution tree building, when
      PIM operates in SSM mode, a source distribution tree is built and
      maintained across site boundaries.  In this case, there is a small
      modification to the operation of the PIM protocol (but not to any
      message format) to support taking a Join/Prune message originated
      inside of a LISP site with embedded addresses from the EID
      namespace and converting them to addresses from the RLOC namespace
      when the Join/Prune message crosses a site boundary.  This is
      similar to the requirements documented in [MNAT].

   PIM-Bidir:   Bidirectional PIM is typically run inside of a routing
      domain, but if deployed in an inter-domain environment, one would
      have to decide if the RP address of the shared-tree would be from
      the EID namespace or the RLOC namespace.  If the RP resides in a
      site-based router, then the RP address is from the EID namespace.
      If the RP resides in the core where RLOC addresses are routed,
      then the RP address is from the RLOC namespace.  This could be
      easily distinguishable if the EID address were well-known address
      allocation block from the RLOC namespace.  Also, when using
      Embedded-RP for RP determination [RFC3956], the format of the
      group address could indicate the namespace the RP address is from.
      However, refer to Section 10 for considerations core routers need
      to make when using Embedded-RP IPv6 group addresses.  When using
      Bidir-PIM for inter-domain multicast routing, it is recommended to
      use staticly configured RPs so core routers think the Bidir group
      is associated with an ITR's RLOC as the RP address and site
      routers think the Bidir group is associated with the site resident
      RP with an EID address.  With respect to DF-election in Bidir PIM,
      no changes are required since all messaging and addressing is
      link-local.

   PIM-ASM:   The ASM mode of PIM, the most popular form of PIM, is
      deployed in the Internet today is by having shared-trees within a
      site and using source-trees across sites.  By the use of MSDP and
      PIM-SSM techniques described above, we can get multicast
      connectivity across LISP sites.  Having said that, that means
      there are no special actions required for processing (*,G) or
      (S,G,R) Join/Prune messages since they all operate against the
      shared-tree which is site resident.  Just like with ASM, there is
      no (*,G) in the core when LISP-Multicast is in use.  This is also
      true for the RP-mapping mechanisms Auto-RP and BSR.

   Based on the protocol description above, the conclusion is that there
   are no protocol message format changes, just a translation function
   performed at the control-plane.  This will make for an easier and
   faster transition for LISP since fewer components in the network have
   to change.

   It should also be stated just like it is in [LISP] that no host
   changes, whatsoever, are required to have a multicast source host
   send multicast packets and for a multicast receiver host to receive
   multicast packets.

8.  LISP-Multicast Data-Plane Architecture

   The LISP-Multicast data-plane operation conforms to the operation and
   packet formats specified in [LISP].  However, encapsulating a
   multicast packet from an ITR is a much simpler process.  The process
   is simply to copy the inner group address to the outer destination
   address.  And to have the ITR use its own IP address (its RLOC), and
   as the source address.  The process is simpler for multicast because
   there is no EID-to-RLOC mapping lookup performed during packet
   forwarding.

   In the decapsulation case, the ETR simply removes the outer header
   and performs a multicast routing table lookup on the inner header
   (S-EID,G) addresses.  Then the oif-list for the (S-EID,G) entry is
   used to replicate the packet on site-facing interfaces leading to
   multicast receiver hosts.

   There is no Data-Probe logic for ETRs as there can be in the unicast
   forwarding case.

8.1.  ITR Forwarding Procedure

   The following procedure is used by an ITR, when it receives a
   multicast packet from a source inside of its site:

   1.  A multicast data packet sent by a host in a LISP site will have
       the source address equal to the host's EID and the destination
       address equal to the group address of the multicast group.  It is
       assumed the group information is obtained by current methods.
       The same is true for a multicast receiver to obtain the source
       and group address of a multicast flow.

   2.  When the ITR receives a multicast packet, it will have both S-EID
       state and S-RLOC state stored.  Since the packet was received on
       a site-facing interface, the RPF lookup is based on the S-EID
       state.  If the RPF check succeeds, then the oif-list contains
       interfaces that are site-facing and external-facing.  For the
       site-facing interfaces, no LISP header is prepended.  For the
       external-facing interfaces a LISP header is prepended.  When the
       ITR prepends a LISP header, it uses its own RLOC address as the
       source address and copies the group address supplied by the IP
       header the host built as the outer destination address.

8.1.1.  Multiple RLOCs for an ITR

   Typically, an ITR will have a single RLOC address but in some cases
   there could be multiple RLOC addresses assigned from either the same
   or different service providers.  In this case when (S-RLOC,G) Join/
   Prune messages are received for each RLOC, there is a oif-list
   merging action that must take place.  Therefore, when a packet is
   received from a site-facing interface that matches on a (S-EID,G)
   entry, the interfaces of the oif-list from all (RLOC,G) entries
   joined to the ITR as well as the site-facing oif-list joined for
   (S-EID,G) must be part be included in packet replication.  In
   addition to replicating for all types of oif-lists, each oif entry
   must be tagged with the RLOC address, so encapsulation uses the outer
   source address for the RLOC joined.

8.1.2.  Multiple ITRs for a LISP Source Site

   Note when ETRs from different multicast receiver sites receive
   (S-EID,G) joins, they may select a different S-RLOC for a multicast
   source site due to policy (the multicast ITR can return different
   multicast priority and weight values per ETR Map-Request).  In this
   case, the same (S-EID,G) is being realized by different (S-RLOC,G)
   state in the core.  This will not result in duplicate packets because
   each ITR in the multicast source site will choose their own RLOC for
   the source address for encapsulated multicast traffic.  The RLOC
   addresses are the ones joined by remote multicast ETRs.

8.2.  ETR Forwarding Procedure

   The following procedure is used by an ETR, when it receives a
   multicast packet from a source outside of its site:

   1.  When a multicast data packet is received by an ETR on an
       external-facing interface, it will do an RPF lookup on the S-RLOC
       state it has stored.  If the RPF check succeeds, the interfaces
       from the oif-list are used for replication to interfaces that are
       site-facing as well as interfaces that are external-facing (this
       ETR can also be a transit multicast router for receivers outside
       of its site).  When the packet is to be replicated for an
       external-facing interface, the LISP encapsulation header are not
       stripped.  When the packet is replicated for a site-facing
       interface, the encapsulation header is stripped.

   2.  The packet without a LISP header is now forwarded down the
       (S-EID,G) distribution tree in the receiver multicast site.

8.3.  Replication Locations

   Multicast packet replication can happen in the following topological
   locations:

   o  In an IGP multicast router inside a site which operates on S-EIDs.

   o  In a transit multicast router inside of the core which operates on
      S-RLOCs.

   o  At one or more ETR routers depending on the path a Join/Prune
      message exits a receiver multicast site.

   o  At one or more ITR routers in a source multicast site depending on
      what priorities are returned in a Map-Reply to receiver multicast
      sites.

   In the last case the source multicast site can do replication rather
   than having a single exit from the site.  But this only can occur
   when the priorities in the Map-Reply are modified for different
   receiver multicast site so that the PIM Join/Prune messages arrive at
   different ITRs.

   This policy technique, also used in [ALT] for unicast, is useful for
   multicast to mitigate the problems of changing distribution tree
   state as discussed in Section 6.

9.  LISP-Multicast Interworking

   This section will describe the multicast corollary to [INTWORK] which
   describes the interworking of multicast routing among LISP and non-
   LISP sites.

9.1.  LISP and non-LISP Mixed Sites

   Since multicast communication can involve more than two entities to
   communicate together, the combinations of interworking scenarios are
   more involved.  However, the state maintained for distribution trees
   at the sites is the same regardless of whether or not the site is
   LISP enabled or not.  So most of the implications are in the core
   with respect to storing routable EID prefixes from either PA or PI
   blocks.

   Before we enumerate the multicast interworking scenarios, we must
   define 3 deployment states of a site:

   o  A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it
      does today.  The addresses for the site are globally routable.

   o  A site that deploys LISP for unicast routing.  The addresses for
      the site are not globally routable.  Let's define the name for
      this type of site as a uLISP site.

   o  A site that deploys LISP for both unicast and multicast routing.
      The addresses for the site are not globally routable.  Let's
      define the name for this type of site as a LISP-Multicast site.

   We will not consider a LISP site enabled for multicast purposes only
   but do consider a uLISP site as documented in [INTWORK].  In this
   section we don't discuss how a LISP site sends multicast packets when
   all receiver sites are LISP-Multicast enabled; that has been
   discussed in previous sections.

   The following scenarios exist to make LISP-Multicast sites interwork
   with non-LISP-Multicast sites:

   1.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of non-LISP sites and uLISP sites.

   2.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of non-LISP sites and uLISP sites.

   3.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of LISP sites, uLISP sites, and
       non-LISP sites.

   4.  A uLISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

   5.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

9.1.1.  LISP Source Site to non-LISP Receiver Sites

   In the first scenario, a site is LISP capable for both unicast and
   multicast traffic and as such operates on EIDs.  Therefore there is a
   possibility that the EID prefix block is not routable in the core.
   For LISP receiver multicast sites this isn't a problem but for non-
   LISP or uLISP receiver multicast sites, when a PIM Join/Prune message
   is received by the edge router, it has no route to propagate the
   Join/Prune message out of the site.  This is no different than the
   unicast case that LISP-NAT in [INTWORK] solves.

   LISP-NAT allows a unicast packet that exits a LISP site to get its
   source address mapped to a globally routable address before the ITR
   realizes that it should not encapsulate the packet destined to a non-
   LISP site.  For a multicast packet to leave a LISP site, distribution
   tree state needs to be built so the ITR can know where to send the
   packet.  So the receiver multicast sites need to know about the
   multicast source host by its routable address and not its EID
   address.  When this is the case, the routable address is the
   (S-RLOC,G) state that is stored and maintained in the core routers.
   It is important to note that the routable address for the host cannot
   be the same as an RLOC for the site.  Because we want the ITRs to
   process a received PIM Join/Prune message from an external-facing
   interface to be propagated inside of the site so the site-part of the
   distribution tree is built.

   Using a globally routable source address allows non-LISP and uLISP
   multicast receiver to join, create, and maintain a multicast
   distribution tree.  However, the LISP multicast receiver site will
   want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
   Prune message is received on a site-facing interface.  It does this
   because it wants to find a (S-RLOC,G) entry to Join in the core.  So
   we have a conflict of behavior between the two types of sites.

   The solution to this problem is the same as when an ITR wants to send
   a unicast packet to a destination site but needs determine if the
   site is LISP capable or not.  When it is not LISP capable, the ITR
   does not encapsulate the packet.  So for the multicast case, when ETR
   receives a PIM Join/Prune message for (S-EID,G) state, it will do a
   mapping table lookup on S-EID.  In this case, S-EID is not in the
   mapping database because the source multicast site is using a
   routable address and not an EID prefix address.  So the ETR knows to
   simply propagate the PIM Join/Prune message to a external-facing
   interface without converting the (S-EID,G) because it is an (S,G)
   where S is routable and reachable via core routing tables.

   Now that the multicast distribution tree is built and maintained from
   any non-LISP or uLISP receiver multicast site, the way packet
   forwarding model is performed can be explained.

   Since the ITR in the source multicast site has never received a
   unicast encapsulated PIM Join/Prune message from any ETR in a
   receiver multicast site, it knows there are no LISP-Multicast
   receiver sites.  Therefore, there is no need for the ITR to
   encapsulate data.  Since it will know a priori (via configuration)
   that its site's EIDs are not routable, it assumes that the multicast
   packets from the source host are sent by a routable address.  That
   is, it is the responsibility of the multicast source host's system
   administrator to ensure that the source host sends multicast traffic
   using a routable source address.  When this happens, the ITR acts
   simply as a router and forwards the multicast packet like an ordinary
   multicast router.

   There is an alternative to using a LISP-NAT scheme just like there is
   for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
   (PTRs).
   (PxTRs).  This can work the same way for multicast routing as well,
   but the difference is that non-LISP and uLISP sites will send PIM
   Join/Prune messages for (S-EID,G) which make their way in the core to
   PTRs.
   multicast PxTRs.  Let's call this use of a PTR PxTR as a "Multicast PTR"
   Proxy-ETR" (or mPTR). mPETR).  Since the PTRs mPETRs advertise very coarse EID
   prefixes, they draw the PIM Join/Prune control traffic making them
   the target of the distribution tree.  To get multicast packets from
   the LISP source multicast sites, the tree needs to be built on the
   path from the mPTR mPETR to the LISP source multicast site.  To make this
   happen the mPTR mPETR acts as a "Proxy ETR" (where in unicast it acts as a
   "Proxy ITR"). ITR", or an uPITR).

   The existence of mPTRs mPETRs in the core allows LISP source multicast site ITRs
   to encapsulate multicast packets so the according to (S-RLOC,G) state.  The
   (S-RLOC,G) state is built between from the
   ITRs and mPETRs to the mPTRs is (S-RLOC,G) state.  Then the mPTRs can
   decapsulate multicast ITRs.  The
   encapsulated multicast packets are decapsulated by mPETRs and forward natively then
   forwarded according to (S-EID,G) state.  The (S-EID,G) state is built
   from the non-LISP and uLISP receiver multicast sites. sites to the mPETRs.

9.1.2.  Non-LISP Source Site to non-LISP Receiver  Sites

   Clearly non-LISP multicast sites can send multicast packets to non-
   LISP receiver multicast sites.  That is what they do today.  However,
   discussion is required to show how non-LISP multicast sites send
   multicast packets to uLISP receiver multicast sites.

   Since uLISP receiver multicast sites are not targets of any (S,G)
   state, they simply send (S,G) PIM Join/Prune messages toward the non-
   LISP source multicast site.  Since the source multicast site, in this
   case has not been upgraded to LISP, all multicast source host
   addresses are routable.  So this case is simplified to where a uLISP
   receiver multicast site looks to the source multicast site as a non-
   LISP receiver multicast site.

9.1.3.  Non-LISP Source Site to Any Receiver Site

   When a non-LISP source multicast site has receivers in either a non-
   LISP/uLISP site or a LISP site, one needs to decide how the LISP
   receiver multicast site will attach to the distribution tree.  We
   know from Section 9.1.2 that non-LISP and uLISP receiver multicast
   sites can join the distribution tree, but a LISP receiver multicast
   site ETR will need to know if the source address of the multicast
   source host is routable or not.  We showed in Section 9.1.1 that an
   ETR, before it sends a PIM Join/Prune message on an external-facing
   interface, does a EID-to-RLOC mapping lookup to determine if it
   should convert the (S,G) state from a PIM Join/Prune message received
   on a site-facing interface to a (S-RLOC,G).  If the lookup fails, the
   ETR can conclude the source multicast site is a non-LISP site so it
   simply forwards the Join/Prune message (it also doesn't need to send
   a unicast encapsulated Join/Prune message because there is no ITR in
   a non-LISP site and there is namespace continuity between the ETR and
   source).

   For a non-LISP source multicast site, (S-EID,G) state could be
   limited to the edges of the network with the use of multicast proxy-
   ITRs (mPITRs).  The mPITRs can take native, unencapsulated multicast
   packets from non-LISP source multicast and uLISP sites and
   encapsulate them to ETRs in receiver multicast sites or to mPETRs
   that can decapsulate for non-LISP receiver multicast or uLISP sites.
   The mPITRs are responsible for sending (S-EID,G) joins to the non-
   LISP source multicast site.  To connect the distribution trees
   together, multicast ETRs will need to be configured with the mPITR's
   RLOC addresses so they can send both (S-RLOC,G) joins to build a
   distribution tree to the mPITR as well as for sending unicast oins to
   mPITRs so they can propogate (S-EID,G) joins into source multicast
   sites.  The use of mPITRs is undergoing more study and is work in
   progress.

9.1.4.  Unicast LISP Source Site to Any Receiver Sites

   In the last section, it was explained how an ETR in a multicast
   receiver site can determine if a source multicast site is LISP-
   enabled by looking into the mapping database.  When the source
   multicast site is a uLISP site, it is LISP enabled but the ITR, by
   definition is not capable of doing multicast encapsulation.  So for
   the purposes of multicast routing, the uLISP source multicast site is
   treated as non-LISP source multicast site.

   Non-LISP receiver multicast sites can join distribution trees to a
   uLISP source multicast site since the source site behaves, from a
   forwarding perspective, as a non-LISP source site.  This is also the
   case for a uLISP receiver multicast site since the ETR does not have
   multicast functionality built-in or enabled.

   Special considerations are required for LISP receiver multicast sites
   since they think the source multicast site is LISP capable, the ETR
   cannot know if ITR is LISP-Multicast capable.  To solve this problem,
   each mapping database entry will have a multicast 2-tuple (Mpriority,
   Mweight) per RLOC.  When the Mpriority is set to 255, the site is
   considered not multicast capable.  So an ETR in a LISP receiver
   multicast site can distinguish whether a LISP source multicast site
   is LISP-Multicast site from a uLISP site.

9.1.5.  LISP Source Site to Any Receiver Sites

   When a LISP source multicast site has receivers in LISP, non-LISP,
   and uLISP receiver multicast sites, it has a conflict about how it
   sends multicast packets.  The ITR can either encapsulate or natively
   forward multicast packets.  Since the receiver multicast sites are
   heterogeneous in their behavior, one packet forwarding mechanism
   cannot satisfy both.  However, if a LISP receiver multicast site acts
   like a uLISP site then it could receive packets like a non-LISP
   receiver multicast site making all receiver multicast sites have
   homogeneous behavior.  However, this poses the following issues:

   o  LISP-NAT techniques with routable addresses would be required in
      all cases.

   o  Or alternatively, mPTR mPETR deployment would be required forcing
      coarse EID prefix advertisement in the core.

   o  But what is most disturbing is that when all sites that
      participate are LISP-Multicast sites but then a non-LISP or uLISP
      site joins the distribution tree, then the existing joined LISP
      receiver multicast sites would have to change their behavior.
      This would create too much dynamic tree-building churn to be a
      viable alternative.

   So the solution space options are:

   1.  Make the LISP ITR in the source multicast site send two packets,
       one that is encapsulated with (S-RLOC,G) to reach LISP receiver
       multicast sites and another that is not encapsulated with
       (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.

   2.  Make the LISP ITR always encapsulate packets with (S-RLOC,G) to
       reach LISP-Multicast sites and to reach mPTRs mPETRs that can
       decapsulate and forward (S-EID,G) packets to non-LISP and uLISP
       receiver multicast sites.

9.2.  LISP Sites with Mixed Address Families

   A LISP database mapping entry that describes the locator-set,
   Mpriority and Mweight per locator address (RLOC), for an EID prefix
   associated with a site could have RLOC addresses in either IPv4 or
   IPv6 format.  When a mapping entry has a mix of RLOC formatted
   addresses, it is an implicit advertisement by the site that it is a
   dual-stack site.  That is, the site can receive IPv4 or IPv6 unicast
   packets.

   To distinguish if the site can receive dual-stack unicast packets as
   well as dual-stack multicast packets, the Mpriority value setting
   will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format
   details.

   If you consider the combinations of LISP, non-LISP, and uLISP sites
   sharing the same distribution tree and considering the capabilities
   of supporting IPv4, IPv6, or dual-stack, the number of total
   combinations grows beyond comprehension.

   Using some combinatorial math, we have the following profiles of a
   site and the combinations that can occur:

   1.  LISP-Multicast IPv4 Site

   2.  LISP-Multicast IPv6 Site

   3.  LISP-Multicast Dual-Stack Site

   4.  uLISP IPv4 Site

   5.  uLISP IPv6 Site
   6.  uLISP Dual-Stack Site

   7.  non-LISP IPv4 Site

   8.  non-LISP IPv6 Site

   9.  non-LISP Dual-Stack Site

   Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to
   illustrate some combinatorial math below.

   When 1 site talks to another site, the combinatorial is (9 2), when 1
   site talks to another 2 sites, the combinatorial is (9 3).  If sum
   this up to (9 9), we have:

   (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =

     36  +   84  +  126  +  126  +   84  +   36  +   9   +   1

   Which results in the total number of cases to be considered at 502.

   This combinatorial gets even worse when you consider a site using one
   address family inside of the site and the xTRs use the other address
   family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4
   RLOCs).

   To rationalize this combinatorial nightmare, there are some
   guidelines which need to be put in place:

   o  Each distribution tree shared among between sites will either be an IPv4
      distribution tree or an IPv6 distribution tree.  Therefore, we can
      avoid head-end replication by building and sending packets on each
      address family based distribution tree.  Even though there might
      be an urge to do multicast packet translation from one address
      family format to the other, it is a non-viable over-complicated
      urge.  Multicast ITRs will only encapsulate packets where the
      inner and outer headers are from the same address family.

   o  All LISP sites on a multicast distribution tree must share a
      common address family which is determined by the source site's
      locator-set in its LISP database mapping entry.  All receiver
      multicast sites will use the best RLOC priority controlled by the
      source multicast site.  This is true when the source site is
      either LISP-Multicast or uLISP capable.  This means that priority-
      based policy modification is prohibited.  When a receiver
      multicast site ETR receives a (S-EID,G) join, it must select a
      S-RLOC for the same address family as S-EID.

   o  A mixed multicast locator-set with the best multicast priority
      values MUST not be configured on multicast ITRs.  A mixed locator-
      set can exist (for unicast use), but the multicast priorities MUST
      be the set for the same address family locators.

   o  When the source site is not LISP capable, it is up to how
      receivers find the source and group information for a multicast
      flow.  That mechanism decides the address family for the flow.

9.3.  Making a Multicast Interworking Decision

   This Multicast Interworking section has shown all combinations of
   multicast connectivity that could occur.  As you might have already
   concluded, this can be quite complicated and if the design is too
   ambitious, the dynamics of the protocol could cause a lot of
   instability.

   The trade-off decisions are hard to make and we want the same single
   solution to work for both IPv4 and IPv6 multicast.  It is imperative
   to have an incrementally deployable solution for all of IPv4 unicast
   and multicast and IPv6 unicast and multicast while minimizing (or
   eliminating) both unicast and multicast EID namespace state.

   Therefore the design decision to go with PTRs uPITRs for unicast routing
   and
   mPTRs mPETRs for multicast routing seems to be the sweet spot in the
   solution space so we can optimize state requirements and avoid head-
   end data replication at ITRs.

10.  Considerations when RP Addresses are Embedded in Group Addresses

   When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a
   technique exists to embed the unicast address of an RP in a IPv6
   group address [RFC3956].  When routers in end sites process a PIM
   Join/Prune message which contain an embedded-RP group address, they
   extract the RP address from the group address and treat it from the
   EID namespace.  However, core routers do not have state for the EID
   namespace, need to extract an RP address from the RLOC namespace.

   Therefore, it is the responsibility of ETRs in multicast receiver
   sites to map the group address into a group address where the
   embedded-RP address is from the RLOC namespace.  The mapped RP-
   address is obtained from a EID-to-RLOC mapping database lookup.  The
   ETR will also send a unicast (*,G) Join/Prune message to the ITR so
   the branch of the distribution tree from the source site resident RP
   to the ITR is created.

   This technique is no different than the techniques described in this
   specification for translating (S,G) state and propagating Join/Prune
   messages into the core.  The only difference is that the (*,G) state
   in Join/Prune messages are mapped because they contain unicast
   addresses encoded in an Embedded-RP group address.

11.  Taking Advantage of Upgrades in the Core

   If the core routers are upgraded to support [RPFV] and [RFC5496],
   then we can pass EID specific data through the core without,
   possibly, having to store the state in the core.

   By doing this we can eliminate the ETR from unicast encapsulating PIM
   Join/Prune messages to the source site's ITR.

   However, this solution is restricted to a small set of workable cases
   which would not be good for general use of LISP-Multicast.  In
   addition to slow convergence properties, it is not being recommended
   for LISP-Multicast.

12.  Mtrace Considerations

   Mtrace functionality must be consistent with unicast traceroute
   functionality where all hops from multicast receiver to multicast
   source are visible.

   The design for mtrace for use in LISP-Multicast environments is to be
   determined but should build upon the mtrace version 2 specified in
   [MTRACE].

13.  Security Considerations

   Refer to the [LISP] specification.

14.  Acknowledgments

   The authors would like to gratefully acknowledge the people who have
   contributed discussion, ideas, and commentary to the making of this
   proposal and specification.  People who provided expert review were
   Scott Brim, Greg Shepherd, and Dave Oran.  Other commentary from
   discussions at Summer 2008 Dublin IETF were Toerless Eckert and
   Ijsbrand Wijnands.

   We would also like to thank the MBONED working group for constructive
   and civil verbal feedback when this draft was presented at the Fall
   2008 IETF in Minneapolis.  In particular, good commentary came from
   Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
   Ron Bonica, and Lenny Guardino.

   An expert review of this specification was done by Yiqun Cai and
   Liming Wei. We thank them for their detailed comments.

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [MLISP] was converted into this IETF LISP
   working group draft.

15.  References

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

15.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
              Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt draft-ietf-lisp-alt-04.txt (work in
              progress), May 2009. April 2010.

   [INTWORK]  Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
              with IPv4 and IPv6", draft-ietf-lisp-interworking-00.txt draft-ietf-lisp-interworking-01.txt
              (work in progress), May 2009. March 2010.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-05.txt
              draft-ietf-lisp-07.txt (work in progress), September 2009. April 2010.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-farinacci-lisp-multicast-01.txt (work in progress),
              November 2008.

   [MNAT]     Wing, D. and T. Eckert, "Multicast Requirements for a
              Network Address (and  port) Translator (NAT)",
              draft-ietf-behave-multicast-07.txt (work in progress),
              June 2007.

   [MTRACE]   Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
              Version 2: Traceroute Facility for IP Multicast",
              draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
              March 2009.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),
              February 2008.

Appendix A.  Document Change Log

A.1.  Changes to draft-ietf-lisp-multicsat-02.txt draft-ietf-lisp-multicast-03.txt

   o  Posted April 2010.

   o  Added section 8.1.2 to address Joel Halpern's comment about
      receiver sites joining the same source site via 2 different RLOCs,
      each being a separate ITR.

   o  Change all occurences of "mPTR" to "mPETR" to become more
      consistent with uPITRs and uPETRs described in [INTWORK].  That
      is, an mPETR is a LISP multicast router that decapsulates
      multicast packets that are encapsulated to it by ITRs in multicast
      source sites.

   o  Add clarifications in section 9 about how homogeneous multicast
      encapsulation should occur.  As well as describing in this
      section, how to deal with mixed-locator sets to avoid
      heterogeneous encapsulation.

   o  Introduce concept of mPITRs to help reduce (S-EID,G) to the edges
      of LISP global multicast network.

A.2.  Changes to draft-ietf-lisp-multicast-02.txt

   o  Posted September 2009.

   o  Added Document Change Log appendix.

   o  Specify that the LISP Encapsulated Control Message be used for
      unicasting PIM Join/Prune messages from ETRs to ITRs.

A.2.

A.3.  Changes to draft-ietf-lisp-multicsat-01.txt draft-ietf-lisp-multicast-01.txt

   o  Posted November 2008.

   o  Specified that PIM Join/Prune unicast messages that get sent from
      ETRs to ITRs of a source multicast site get LISP encapsulated in
      destination UDP port 4342.

   o  Add multiple RLOCs per ITR per Yiqun's comments.

   o  Indicate how static RPs can be used when LISP is run using Bidir-
      PIM in the core.

   o  Editorial changes per Liming comments.

   o  Add Mttrace Considersations section.

A.3.

A.4.  Changes to draft-ietf-lisp-multicsat-00.txt draft-ietf-lisp-multicast-00.txt

   o  Posted April 2008.

   o  Renamed from draft-farinacci-lisp-multicast-01.txt.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dino@cisco.com

   Dave Meyer
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   John Zwiebel
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: jzwiebel@cisco.com

   Stig Venaas
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: stig@cisco.com
--Apple-Mail-4-808289125 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-4-808289125 Content-Disposition: attachment; filename=draft-ietf-lisp-multicast-03.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-multicast-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel Expires: October 14, 2010 S. Venaas cisco Systems April 12, 2010 LISP for Multicast Environments draft-ietf-lisp-multicast-03 Abstract This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 14, 2010. Copyright Notice Copyright (c) 2010 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 Farinacci, et al. Expires October 14, 2010 [Page 1] =0C Internet-Draft LISP for Multicast Environments April 2010 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 BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 6. Locator Reachability Implications on LISP-Multicast . . . . . 13 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 17 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 21 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 23 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 24 9.3. Making a Multicast Interworking Decision . . . . . . . . . 26 10. Considerations when RP Addresses are Embedded in Group Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 28 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32 15.2. Informative References . . . . . . . . . . . . . . . . . . 32 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 34 A.1. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 34 A.2. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 34 A.3. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 34 A.4. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Farinacci, et al. Expires October 14, 2010 [Page 2] =0C Internet-Draft LISP for Multicast Environments April 2010 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires October 14, 2010 [Page 3] =0C Internet-Draft LISP for Multicast Environments April 2010 2. Introduction The Locator/ID Separation Architecture [LISP] provides a mechanism to separate out Identification and Location semantics from the current definition of an IP address. By creating two namespaces, an EID namespace used by sites and a Locator (RLOC) namespace used by core routing, the core routing infrastructure can scale by doing topological aggregation of routing information. Since LISP creates a new namespace, a mapping function must exist to map a site's EID prefixes to its associated locators. For unicast packets, both the source address and destination address must be mapped. For multicast packets, only the source address needs to be mapped. The destination group address doesn't need to be mapped because the semantics of an IPv4 or IPv6 group address are logical in nature and not topology-dependent. Therefore, this specifications focuses on to map a source EID address of a multicast flow during distribution tree setup and packet delivery. This specification will address the following scenarios: 1. How a multicast source host in a LISP site sends multicast packets to receivers inside of its site as well as to receivers in other sites that are LISP enabled. 2. How inter-domain (or between LISP sites) multicast distribution trees are built and how forwarding of multicast packets leaving a source site toward receivers sites is performed. 3. What protocols are affected and what changes are required to such multicast protocols. 4. How ASM-mode, SSM-mode, and Bidir-mode service models will operate. 5. How multicast packet flow will occur for multiple combinations of LISP and non-LISP capable source and receiver sites, for example: A. How multicast packets from a source host in a LISP site are sent to receivers in other sites when they are all non-LISP sites. B. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. C. How multicast packets from a source host in a non-LISP site are sent to receivers in other sites when they are all LISP- Farinacci, et al. Expires October 14, 2010 [Page 4] =0C Internet-Draft LISP for Multicast Environments April 2010 enabled sites. D. How multicast packets from a source host in a non-LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multi- protocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled. Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not run in an inter-domain environment is not addressed in depth in this version of the specification. Also, the current version of this specification does not describe multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR descriptions in [LISP]. Farinacci, et al. Expires October 14, 2010 [Page 5] =0C Internet-Draft LISP for Multicast Environments April 2010 3. Definition of Terms The terminology in this section is consistent with the definitions in [LISP] but is extended specifically to deal with the application of the terminology to multicast routing. LISP-Multicast: a reference to the design in this specification. That is, when any site that is participating in multicast communication has been upgraded to be a LISP site, the operation of control-plane and data-plane protocols is considered part of the LISP-Multicast architecture. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source address field of the first (most inner) LISP header of a multicast packet. The host obtains a destination group address the same way it obtains one today, as it would when it is a non-LISP site. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID prefix block associated with the site the host is located in. An EID can be used by a host to refer to another host, as when it joins an SSM (S-EID,G) route using IGMP version 3 [RFC4604]. LISP uses Provider Independent (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress tunnel router (ITR), the router in the multicast source host's site that encapsulates multicast packets. It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ITR device or to multiple ITR devices at a site. Ingress Tunnel Router (ITR): a router which accepts an IP multicast packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination multicast address opaquely so it doesn't need to perform a map lookup on the group address because it is topologically insignificant. The router then prepends an "outer" IP header with one of its globally-routable RLOCs as the source address field. This RLOC is known to other multicast receiver Farinacci, et al. Expires October 14, 2010 [Page 6] =0C Internet-Draft LISP for Multicast Environments April 2010 sites which have used the mapping database to join a multicast tree for which the ITR is the root. In general, an ITR receives IP packets from site end systems on one side and sends LISP- encapsulated multicast IP packets out all external interfaces which have been joined. An ITR would receive a multicast packet from a source inside of its site when 1) it is on the path from the multicast source to internally joined receivers, or 2) when it is on the path from the multicast source to externally joined receivers. Egress Tunnel Router (ETR): a router that is on the path from a multicast source host in another site to a multicast receiver in its own site. An ETR accepts a PIM Join/Prune message from a site internal PIM router destined for the source's EID in the multicast source site. The ETR maps the source EID in the Join/Prune message to an RLOC address based on the EID-to-RLOC mapping. This sets up the ETR to accept multicast encapsulated packets from the ITR in the source multicast site. A multicast ETR decapsulates multicast encapsulated packets and replicates them on interfaces leading to internal receivers. xTR: is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality can be at the CE router. LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR prepends headers and an ETR strips headers. A LISP encapsulated multicast packet will have an "inner" header with the source EID in the source field; an "outer" header with the source RLOC in the source field: and the same globally unique group address in the destination field of both the inner and outer header. (S,G) State: the formal definition is in the PIM Sparse Mode [RFC4601] specification. For this specification, the term is used generally to refer to multicast state. Based on its topological location, the (S,G) state resides in routers can be either (S-EID,G) state (at a location where the (S,G) state resides) or (S-RLOC,G) state (in the Internet core). (S-EID,G) State: refers to multicast state in multicast source and receiver sites where S-EID is the IP address of the multicast source host (its EID). An S-EID can appear in an IGMPv3 report, an MSDP SA message or a PIM Join/Prune message that travels inside Farinacci, et al. Expires October 14, 2010 [Page 7] =0C Internet-Draft LISP for Multicast Environments April 2010 of a site. (S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) entry by doing a mapping database lookup for the EID prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message when it travels from an ETR to an ITR over the Internet core. uLISP Site: a unicast only LISP site according to [LISP] which has not deployed the procedures of this specification and therefore, for multicast purposes, follows the procedures from Section 9. mPETR: this is a multicast proxy-ETR that is responsible for advertising a very coarse EID prefix which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPETRs act as Proxy ETRs for supporting multicast routing in a LISP infrastructure. It is likely an uPITR and a mPETR will be co-loacted since the single device advertises a coarse EID-prefix in the underlying unicast routing system. Mixed Locator-Sets: this is a locator-set for a LISP database mapping entry where the RLOC addresses in the locator-set are in both IPv4 and IPv6 format. Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (encapsulated in a LISP Encapsulated Control Message with destination UDP port 4342) which is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces in the oif-list for the (S-EID,G) entry the ETR is joining for. Farinacci, et al. Expires October 14, 2010 [Page 8] =0C Internet-Draft LISP for Multicast Environments April 2010 4. Basic Overview LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the traffic engineering features of LISP, a multicast source site can control the egress of its multicast traffic. By controlling the priorities of locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site. At this point in time, we don't see a requirement for different locator-sets, priority, and weight policies for multicast than we have for unicast. The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet. An ITR will encapsulate multicast packets received from sources that it serves in another LISP multicast header. The destination group address from the inner header is copied to the destination address of the outer header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR. The LISP-Multicast architecture will follow this high-level protocol and operational sequence: 1. Receiver hosts in multicast sites will join multicast content the way they do today, they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs, that is they join (S-EID,G). If the S-EID is a local multicast source host. If the multicast source is external to this receiver site, the PIM Join/Prune message flows toward the ETRs, finding the shortest exit (that is the closest exit for the Join/Prune message but it is the closest entrance for the multicast packet to the receiver). 2. The ETR does a mapping database lookup for S-EID. If the mapping is cached from a previous lookup (from either a previous Join/ Prune for the source multicast site or a unicast packet that went to the site), it will use the RLOC information from the mapping. The ETR will use the same priority and weighting mechanism as for unicast. So the source site can decide which way multicast packets egress. Farinacci, et al. Expires October 14, 2010 [Page 9] =0C Internet-Draft LISP for Multicast Environments April 2010 3. The ETR will build two PIM Join/Prune messages, one that contains a (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects, and the other which contains a (S-RLOC,G) entry so the core network can create multicast state from this ETR to the ITR. 4. When the ITR gets the unicast Join/Prune message (see Section 3 for formal definition), it will process (S-EID,G) entries in the message and propagate them inside of the site where it has explicit routing information for EIDs via the IGP. When the ITR receives the (S-RLOC,G) PIM Join/Prune message it will process it like any other join it would get in today's Internet. The S-RLOC address is the IP address of this ITR. 5. At this point there is (S-EID,G) state from the joining host in the receiver multicast site to the ETR of the receiver multicast site. There is (S-RLOC,G) state across the core network from the ETR of the multicast receiver site to the ITR in the multicast source site and (S-EID,G) state in the source multicast site. Note, the (S-EID,G) state is the same S-EID in each multicast site. As other ETRs join the same multicast tree, they can join through the same ITR (in which case the packet replication is done in the core) or a different ITR (in which case the packet replication is done at the source site). 6. When a packet is originated by the multicast host in the source site, it will flow to one or more ITRs which will prepend a LISP header by copying the group address to the outer destination address field and insert its own locator address in the outer source address field. The ITR will look at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicate the packet on each interface a (S-RLOC,G) joined was received on. The core has (S-RLOC,G) so where fanout occurs to multiple sites, a core router will do packet replication. 7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group address. It will also decapsulate packets because it has receivers for the group. Otherwise, it would have not received the packets because it would not have joined. The ETR decapsulates and does a (S-EID,G) lookup in its multicast FIB to forward packets out one or more interfaces to forward the packet to internal receivers. This architecture is consistent and scalable with the architecture presented in [LISP] where multicast state in the core operates on locators and multicast state at the sites operates on EIDs. Farinacci, et al. Expires October 14, 2010 [Page 10] =0C Internet-Draft LISP for Multicast Environments April 2010 Alternatively, [LISP] does present a mechanism where (S-EID,G) state can reside in the core through the use of RPF-vectors [RPFV] in PIM Join/Prune messages. However, this will require EID state in core as well as the use of RPF-vector formatted Join/Prune messages which are not the default implementation choice. So we choose a design that can allow the separation of namespaces as unicast LISP provides. It will be at the expense of creating new (S-RLOC,G) state when ITRs go unreachable. See Section 5 for details. However, we have some observations on the algorithm above. We can scale the control plane but at the expense of sending data to sites which may have not joined the distribution tree where the encapsulated data is being delivered. For example, one site joins (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the same multicast source site. Both multicast receiver sites join to the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the site. The ITR receives (S-RLOC,G) joins and populates the oif-list state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one (S-RLOC,G) packets will be delivered by the core to both multicast receiver sites even though each have joined a single source-based distribution tree. This behavior is a consequence of the many-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution to this problem which reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one- to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but we can reduce the "n" to a smaller number in the "n-to-1" relationship. And in turn, reduce the opportunity for data packets to be delivered to sites for groups not joined. Farinacci, et al. Expires October 14, 2010 [Page 11] =0C Internet-Draft LISP for Multicast Environments April 2010 5. Source Addresses versus Group Addresses Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental deployment of LISP-Multicast. As for source addresses, as in the unicast LISP scenario, there is a decoupling of identification from location. In a LISP site, packets are originated from hosts using their allocated EIDs, those addresses are used to identify the host as well as where in the site's topology the host resides but not how and where it is attached to the Internet. Therefore, when multicast distribution tree state is created anywhere in the network on the path from any multicast receiver to a multicast source, EID state is maintained at the source and receiver multicast sites, and RLOC state is maintained in the core. That is, a multicast distribution tree will be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 3-tuple is the state stored in routers from the source to one or more ITRs in the source multicast site, the second element of the 3-tuple is the state stored in routers downstream of the ITR, in the core, to all LISP receiver multicast sites, and the third element in the 3-tuple is the state stored in the routers downstream of each ETR, in each receiver multicast site, reaching each receiver. Note that (S-EID,G) is the same in both the source and receiver multicast sites. The concatenation/mapping from the first element to the second element of the 3-tuples is done by the ITR and from the second element to the third element is done at the ETRs. Farinacci, et al. Expires October 14, 2010 [Page 12] =0C Internet-Draft LISP for Multicast Environments April 2010 6. Locator Reachability Implications on LISP-Multicast Multicast state as it is stored in the core is always (S,G) state as it exists today or (S-RLOC,G) state as it will exist when LISP sites are deployed. The core routers cannot distinguish one from the other. They don't need to because it is state that RPFs against the core routing tables in the RLOC namespace. The difference is where the root of the distribution tree for a particular source is. In the traditional multicast core, the source S is the source host's IP address. For LISP-Multicast the source S is a single ITR of the multicast source site. An ITR is selected based on the LISP EID-to-RLOC mapping used when an ETR propagates a PIM Join/Prune message out of a receiver multicast site. The selection is based on the same algorithm an ITR would use to select an ETR when sending a unicast packet to the site. In the unicast case, the ITR can change on a per-packet basis depending on the reachability of the ETR. So an ITR can change relatively easily using local reachability state. However, in the multicast case, when an ITR goes unreachable, new distribution tree state must be built because the encapsulating root has changed. This is more significant than an RPF-change event, where any router would typically locally change its RPF-interface for its existing tree state. But when an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be rebuilt and reflect the new encapsulator. Therefore, when an ITR goes unreachable, all ETRs that are currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) to the new ITR as well as send a unicast encapsulated Join/Prune message telling the new ITR which (S-EID,G) is being joined. This issue can be mitigated by using anycast addressing for the ITRs so the problem does reduce to an RPF change in the core, but still requires a unicast encapsulated Join/Prune message to tell the new ITR about (S-EID,G). The problem with this approach is that the ETR really doesn't know when the ITR has changed so the new anycast ITR will get the (S-EID,G) state only when the ETR sends it the next time during its periodic sending procedures. Farinacci, et al. Expires October 14, 2010 [Page 13] =0C Internet-Draft LISP for Multicast Environments April 2010 7. Multicast Protocol Changes A number of protocols are used today for inter-domain multicast routing: IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for LISP-Multicast for two reasons. One being that they are link- local and not used over site boundaries and second they advertise group addresses that don't need translation. Where source addresses are supplied in IGMPv3 and MLDv2 messages, they are semantically regarded as EIDs and don't need to be converted to RLOCs until the multicast tree-building protocol, such as PIM, is received by the ETR at the site boundary. Addresses used for IGMP and MLD come out of the source site's allocated addresses which are therefore from the EID namespace. MBGP: Even though MBGP is not a multicast routing protocol, it is used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology are not congruent. When MBGP is used in a LISP-Multicast environment, the prefixes which are advertised are from the RLOC namespace. This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace. MSDP: MSDP is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of site will be from the EID namespace so it can be advertised and reached by internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. And the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. PIM-SSM: In the simplest form of distribution tree building, when PIM operates in SSM mode, a source distribution tree is built and maintained across site boundaries. In this case, there is a small modification to the operation of the PIM protocol (but not to any Farinacci, et al. Expires October 14, 2010 [Page 14] =0C Internet-Draft LISP for Multicast Environments April 2010 message format) to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [MNAT]. PIM-Bidir: Bidirectional PIM is typically run inside of a routing domain, but if deployed in an inter-domain environment, one would have to decide if the RP address of the shared-tree would be from the EID namespace or the RLOC namespace. If the RP resides in a site-based router, then the RP address is from the EID namespace. If the RP resides in the core where RLOC addresses are routed, then the RP address is from the RLOC namespace. This could be easily distinguishable if the EID address were well-known address allocation block from the RLOC namespace. Also, when using Embedded-RP for RP determination [RFC3956], the format of the group address could indicate the namespace the RP address is from. However, refer to Section 10 for considerations core routers need to make when using Embedded-RP IPv6 group addresses. When using Bidir-PIM for inter-domain multicast routing, it is recommended to use staticly configured RPs so core routers think the Bidir group is associated with an ITR's RLOC as the RP address and site routers think the Bidir group is associated with the site resident RP with an EID address. With respect to DF-election in Bidir PIM, no changes are required since all messaging and addressing is link-local. PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is deployed in the Internet today is by having shared-trees within a site and using source-trees across sites. By the use of MSDP and PIM-SSM techniques described above, we can get multicast connectivity across LISP sites. Having said that, that means there are no special actions required for processing (*,G) or (S,G,R) Join/Prune messages since they all operate against the shared-tree which is site resident. Just like with ASM, there is no (*,G) in the core when LISP-Multicast is in use. This is also true for the RP-mapping mechanisms Auto-RP and BSR. Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control-plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change. It should also be stated just like it is in [LISP] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive multicast packets. Farinacci, et al. Expires October 14, 2010 [Page 15] =0C Internet-Draft LISP for Multicast Environments April 2010 8. LISP-Multicast Data-Plane Architecture The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in [LISP]. However, encapsulating a multicast packet from an ITR is a much simpler process. The process is simply to copy the inner group address to the outer destination address. And to have the ITR use its own IP address (its RLOC), and as the source address. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding. In the decapsulation case, the ETR simply removes the outer header and performs a multicast routing table lookup on the inner header (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is used to replicate the packet on site-facing interfaces leading to multicast receiver hosts. There is no Data-Probe logic for ETRs as there can be in the unicast forwarding case. 8.1. ITR Forwarding Procedure The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site: 1. A multicast data packet sent by a host in a LISP site will have the source address equal to the host's EID and the destination address equal to the group address of the multicast group. It is assumed the group information is obtained by current methods. The same is true for a multicast receiver to obtain the source and group address of a multicast flow. 2. When the ITR receives a multicast packet, it will have both S-EID state and S-RLOC state stored. Since the packet was received on a site-facing interface, the RPF lookup is based on the S-EID state. If the RPF check succeeds, then the oif-list contains interfaces that are site-facing and external-facing. For the site-facing interfaces, no LISP header is prepended. For the external-facing interfaces a LISP header is prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address and copies the group address supplied by the IP header the host built as the outer destination address. 8.1.1. Multiple RLOCs for an ITR Typically, an ITR will have a single RLOC address but in some cases there could be multiple RLOC addresses assigned from either the same or different service providers. In this case when (S-RLOC,G) Join/ Farinacci, et al. Expires October 14, 2010 [Page 16] =0C Internet-Draft LISP for Multicast Environments April 2010 Prune messages are received for each RLOC, there is a oif-list merging action that must take place. Therefore, when a packet is received from a site-facing interface that matches on a (S-EID,G) entry, the interfaces of the oif-list from all (RLOC,G) entries joined to the ITR as well as the site-facing oif-list joined for (S-EID,G) must be part be included in packet replication. In addition to replicating for all types of oif-lists, each oif entry must be tagged with the RLOC address, so encapsulation uses the outer source address for the RLOC joined. 8.1.2. Multiple ITRs for a LISP Source Site Note when ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site due to policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In this case, the same (S-EID,G) is being realized by different (S-RLOC,G) state in the core. This will not result in duplicate packets because each ITR in the multicast source site will choose their own RLOC for the source address for encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs. 8.2. ETR Forwarding Procedure The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site: 1. When a multicast data packet is received by an ETR on an external-facing interface, it will do an RPF lookup on the S-RLOC state it has stored. If the RPF check succeeds, the interfaces from the oif-list are used for replication to interfaces that are site-facing as well as interfaces that are external-facing (this ETR can also be a transit multicast router for receivers outside of its site). When the packet is to be replicated for an external-facing interface, the LISP encapsulation header are not stripped. When the packet is replicated for a site-facing interface, the encapsulation header is stripped. 2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site. 8.3. Replication Locations Multicast packet replication can happen in the following topological locations: Farinacci, et al. Expires October 14, 2010 [Page 17] =0C Internet-Draft LISP for Multicast Environments April 2010 o In an IGP multicast router inside a site which operates on S-EIDs. o In a transit multicast router inside of the core which operates on S-RLOCs. o At one or more ETR routers depending on the path a Join/Prune message exits a receiver multicast site. o At one or more ITR routers in a source multicast site depending on what priorities are returned in a Map-Reply to receiver multicast sites. In the last case the source multicast site can do replication rather than having a single exit from the site. But this only can occur when the priorities in the Map-Reply are modified for different receiver multicast site so that the PIM Join/Prune messages arrive at different ITRs. This policy technique, also used in [ALT] for unicast, is useful for multicast to mitigate the problems of changing distribution tree state as discussed in Section 6. Farinacci, et al. Expires October 14, 2010 [Page 18] =0C Internet-Draft LISP for Multicast Environments April 2010 9. LISP-Multicast Interworking This section will describe the multicast corollary to [INTWORK] which describes the interworking of multicast routing among LISP and non- LISP sites. 9.1. LISP and non-LISP Mixed Sites Since multicast communication can involve more than two entities to communicate together, the combinations of interworking scenarios are more involved. However, the state maintained for distribution trees at the sites is the same regardless of whether or not the site is LISP enabled or not. So most of the implications are in the core with respect to storing routable EID prefixes from either PA or PI blocks. Before we enumerate the multicast interworking scenarios, we must define 3 deployment states of a site: o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it does today. The addresses for the site are globally routable. o A site that deploys LISP for unicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a uLISP site. o A site that deploys LISP for both unicast and multicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a LISP-Multicast site. We will not consider a LISP site enabled for multicast purposes only but do consider a uLISP site as documented in [INTWORK]. In this section we don't discuss how a LISP site sends multicast packets when all receiver sites are LISP-Multicast enabled; that has been discussed in previous sections. The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites: 1. A LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 2. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 3. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. Farinacci, et al. Expires October 14, 2010 [Page 19] =0C Internet-Draft LISP for Multicast Environments April 2010 4. A uLISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 5. A LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 9.1.1. LISP Source Site to non-LISP Receiver Sites In the first scenario, a site is LISP capable for both unicast and multicast traffic and as such operates on EIDs. Therefore there is a possibility that the EID prefix block is not routable in the core. For LISP receiver multicast sites this isn't a problem but for non- LISP or uLISP receiver multicast sites, when a PIM Join/Prune message is received by the edge router, it has no route to propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP-NAT in [INTWORK] solves. LISP-NAT allows a unicast packet that exits a LISP site to get its source address mapped to a globally routable address before the ITR realizes that it should not encapsulate the packet destined to a non- LISP site. For a multicast packet to leave a LISP site, distribution tree state needs to be built so the ITR can know where to send the packet. So the receiver multicast sites need to know about the multicast source host by its routable address and not its EID address. When this is the case, the routable address is the (S-RLOC,G) state that is stored and maintained in the core routers. It is important to note that the routable address for the host cannot be the same as an RLOC for the site. Because we want the ITRs to process a received PIM Join/Prune message from an external-facing interface to be propagated inside of the site so the site-part of the distribution tree is built. Using a globally routable source address allows non-LISP and uLISP multicast receiver to join, create, and maintain a multicast distribution tree. However, the LISP multicast receiver site will want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ Prune message is received on a site-facing interface. It does this because it wants to find a (S-RLOC,G) entry to Join in the core. So we have a conflict of behavior between the two types of sites. The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the Farinacci, et al. Expires October 14, 2010 [Page 20] =0C Internet-Draft LISP for Multicast Environments April 2010 mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. Now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, the way packet forwarding model is performed can be explained. Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) that its site's EIDs are not routable, it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a router and forwards the multicast packet like an ordinary multicast router. There is an alternative to using a LISP-NAT scheme just like there is for unicast [INTWORK] forwarding by using Proxy Tunnel Routers (PxTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) which make their way in the core to multicast PxTRs. Let's call this use of a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree needs to be built on the path from the mPETR to the LISP source multicast site. To make this happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a "Proxy ITR", or an uPITR). The existence of mPETRs in the core allows source multicast site ITRs to encapsulate multicast packets according to (S-RLOC,G) state. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The encapsulated multicast packets are decapsulated by mPETRs and then forwarded according to (S-EID,G) state. The (S-EID,G) state is built from the non-LISP and uLISP receiver multicast sites to the mPETRs. 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites Clearly non-LISP multicast sites can send multicast packets to non- LISP receiver multicast sites. That is what they do today. However, Farinacci, et al. Expires October 14, 2010 [Page 21] =0C Internet-Draft LISP for Multicast Environments April 2010 discussion is required to show how non-LISP multicast sites send multicast packets to uLISP receiver multicast sites. Since uLISP receiver multicast sites are not targets of any (S,G) state, they simply send (S,G) PIM Join/Prune messages toward the non- LISP source multicast site. Since the source multicast site, in this case has not been upgraded to LISP, all multicast source host addresses are routable. So this case is simplified to where a uLISP receiver multicast site looks to the source multicast site as a non- LISP receiver multicast site. 9.1.3. Non-LISP Source Site to Any Receiver Site When a non-LISP source multicast site has receivers in either a non- LISP/uLISP site or a LISP site, one needs to decide how the LISP receiver multicast site will attach to the distribution tree. We know from Section 9.1.2 that non-LISP and uLISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast site ETR will need to know if the source address of the multicast source host is routable or not. We showed in Section 9.1.1 that an ETR, before it sends a PIM Join/Prune message on an external-facing interface, does a EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to a (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site so it simply forwards the Join/Prune message (it also doesn't need to send a unicast encapsulated Join/Prune message because there is no ITR in a non-LISP site and there is namespace continuity between the ETR and source). For a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network with the use of multicast proxy- ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast packets from non-LISP source multicast and uLISP sites and encapsulate them to ETRs in receiver multicast sites or to mPETRs that can decapsulate for non-LISP receiver multicast or uLISP sites. The mPITRs are responsible for sending (S-EID,G) joins to the non- LISP source multicast site. To connect the distribution trees together, multicast ETRs will need to be configured with the mPITR's RLOC addresses so they can send both (S-RLOC,G) joins to build a distribution tree to the mPITR as well as for sending unicast oins to mPITRs so they can propogate (S-EID,G) joins into source multicast sites. The use of mPITRs is undergoing more study and is work in progress. Farinacci, et al. Expires October 14, 2010 [Page 22] =0C Internet-Draft LISP for Multicast Environments April 2010 9.1.4. Unicast LISP Source Site to Any Receiver Sites In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP- enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled but the ITR, by definition is not capable of doing multicast encapsulation. So for the purposes of multicast routing, the uLISP source multicast site is treated as non-LISP source multicast site. Non-LISP receiver multicast sites can join distribution trees to a uLISP source multicast site since the source site behaves, from a forwarding perspective, as a non-LISP source site. This is also the case for a uLISP receiver multicast site since the ETR does not have multicast functionality built-in or enabled. Special considerations are required for LISP receiver multicast sites since they think the source multicast site is LISP capable, the ETR cannot know if ITR is LISP-Multicast capable. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC. When the Mpriority is set to 255, the site is considered not multicast capable. So an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is LISP-Multicast site from a uLISP site. 9.1.5. LISP Source Site to Any Receiver Sites When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site then it could receive packets like a non-LISP receiver multicast site making all receiver multicast sites have homogeneous behavior. However, this poses the following issues: o LISP-NAT techniques with routable addresses would be required in all cases. o Or alternatively, mPETR deployment would be required forcing coarse EID prefix advertisement in the core. o But what is most disturbing is that when all sites that participate are LISP-Multicast sites but then a non-LISP or uLISP site joins the distribution tree, then the existing joined LISP receiver multicast sites would have to change their behavior. This would create too much dynamic tree-building churn to be a Farinacci, et al. Expires October 14, 2010 [Page 23] =0C Internet-Draft LISP for Multicast Environments April 2010 viable alternative. So the solution space options are: 1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to reach LISP-Multicast sites and to reach mPETRs that can decapsulate and forward (S-EID,G) packets to non-LISP and uLISP receiver multicast sites. 9.2. LISP Sites with Mixed Address Families A LISP database mapping entry that describes the locator-set, Mpriority and Mweight per locator address (RLOC), for an EID prefix associated with a site could have RLOC addresses in either IPv4 or IPv6 format. When a mapping entry has a mix of RLOC formatted addresses, it is an implicit advertisement by the site that it is a dual-stack site. That is, the site can receive IPv4 or IPv6 unicast packets. To distinguish if the site can receive dual-stack unicast packets as well as dual-stack multicast packets, the Mpriority value setting will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format details. If you consider the combinations of LISP, non-LISP, and uLISP sites sharing the same distribution tree and considering the capabilities of supporting IPv4, IPv6, or dual-stack, the number of total combinations grows beyond comprehension. Using some combinatorial math, we have the following profiles of a site and the combinations that can occur: 1. LISP-Multicast IPv4 Site 2. LISP-Multicast IPv6 Site 3. LISP-Multicast Dual-Stack Site 4. uLISP IPv4 Site 5. uLISP IPv6 Site Farinacci, et al. Expires October 14, 2010 [Page 24] =0C Internet-Draft LISP for Multicast Environments April 2010 6. uLISP Dual-Stack Site 7. non-LISP IPv4 Site 8. non-LISP IPv6 Site 9. non-LISP Dual-Stack Site Lets define (m n) =3D m!/(n!*(m-n)!), pronounced "m choose n" to illustrate some combinatorial math below. When 1 site talks to another site, the combinatorial is (9 2), when 1 site talks to another 2 sites, the combinatorial is (9 3). If sum this up to (9 9), we have: (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =3D 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 Which results in the total number of cases to be considered at 502. This combinatorial gets even worse when you consider a site using one address family inside of the site and the xTRs use the other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 RLOCs). To rationalize this combinatorial nightmare, there are some guidelines which need to be put in place: o Each distribution tree shared between sites will either be an IPv4 distribution tree or an IPv6 distribution tree. Therefore, we can avoid head-end replication by building and sending packets on each address family based distribution tree. Even though there might be an urge to do multicast packet translation from one address family format to the other, it is a non-viable over-complicated urge. Multicast ITRs will only encapsulate packets where the inner and outer headers are from the same address family. o All LISP sites on a multicast distribution tree must share a common address family which is determined by the source site's locator-set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP capable. This means that priority- based policy modification is prohibited. When a receiver multicast site ETR receives a (S-EID,G) join, it must select a S-RLOC for the same address family as S-EID. Farinacci, et al. Expires October 14, 2010 [Page 25] =0C Internet-Draft LISP for Multicast Environments April 2010 o A mixed multicast locator-set with the best multicast priority values MUST not be configured on multicast ITRs. A mixed locator- set can exist (for unicast use), but the multicast priorities MUST be the set for the same address family locators. o When the source site is not LISP capable, it is up to how receivers find the source and group information for a multicast flow. That mechanism decides the address family for the flow. 9.3. Making a Multicast Interworking Decision This Multicast Interworking section has shown all combinations of multicast connectivity that could occur. As you might have already concluded, this can be quite complicated and if the design is too ambitious, the dynamics of the protocol could cause a lot of instability. The trade-off decisions are hard to make and we want the same single solution to work for both IPv4 and IPv6 multicast. It is imperative to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state. Therefore the design decision to go with uPITRs for unicast routing and mPETRs for multicast routing seems to be the sweet spot in the solution space so we can optimize state requirements and avoid head- end data replication at ITRs. Farinacci, et al. Expires October 14, 2010 [Page 26] =0C Internet-Draft LISP for Multicast Environments April 2010 10. Considerations when RP Addresses are Embedded in Group Addresses When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in a IPv6 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message which contain an embedded-RP group address, they extract the RP address from the group address and treat it from the EID namespace. However, core routers do not have state for the EID namespace, need to extract an RP address from the RLOC namespace. Therefore, it is the responsibility of ETRs in multicast receiver sites to map the group address into a group address where the embedded-RP address is from the RLOC namespace. The mapped RP- address is obtained from a EID-to-RLOC mapping database lookup. The ETR will also send a unicast (*,G) Join/Prune message to the ITR so the branch of the distribution tree from the source site resident RP to the ITR is created. This technique is no different than the techniques described in this specification for translating (S,G) state and propagating Join/Prune messages into the core. The only difference is that the (*,G) state in Join/Prune messages are mapped because they contain unicast addresses encoded in an Embedded-RP group address. Farinacci, et al. Expires October 14, 2010 [Page 27] =0C Internet-Draft LISP for Multicast Environments April 2010 11. Taking Advantage of Upgrades in the Core If the core routers are upgraded to support [RPFV] and [RFC5496], then we can pass EID specific data through the core without, possibly, having to store the state in the core. By doing this we can eliminate the ETR from unicast encapsulating PIM Join/Prune messages to the source site's ITR. However, this solution is restricted to a small set of workable cases which would not be good for general use of LISP-Multicast. In addition to slow convergence properties, it is not being recommended for LISP-Multicast. Farinacci, et al. Expires October 14, 2010 [Page 28] =0C Internet-Draft LISP for Multicast Environments April 2010 12. Mtrace Considerations Mtrace functionality must be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible. The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon the mtrace version 2 specified in [MTRACE]. Farinacci, et al. Expires October 14, 2010 [Page 29] =0C Internet-Draft LISP for Multicast Environments April 2010 13. Security Considerations Refer to the [LISP] specification. Farinacci, et al. Expires October 14, 2010 [Page 30] =0C Internet-Draft LISP for Multicast Environments April 2010 14. Acknowledgments The authors would like to gratefully acknowledge the people who have contributed discussion, ideas, and commentary to the making of this proposal and specification. People who provided expert review were Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from discussions at Summer 2008 Dublin IETF were Toerless Eckert and Ijsbrand Wijnands. We would also like to thank the MBONED working group for constructive and civil verbal feedback when this draft was presented at the Fall 2008 IETF in Minneapolis. In particular, good commentary came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Ron Bonica, and Lenny Guardino. An expert review of this specification was done by Yiqun Cai and Liming Wei. We thank them for their detailed comments. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [MLISP] was converted into this IETF LISP working group draft. Farinacci, et al. Expires October 14, 2010 [Page 31] =0C Internet-Draft LISP for Multicast Environments April 2010 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 15.2. Informative References [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-04.txt (work in progress), April 2010. [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt (work in progress), March 2010. [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, et al. Expires October 14, 2010 [Page 32] =0C Internet-Draft LISP for Multicast Environments April 2010 "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-07.txt (work in progress), April 2010. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress), November 2008. [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a Network Address (and port) Translator (NAT)", draft-ietf-behave-multicast-07.txt (work in progress), June 2007. [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-03.txt (work in progress), March 2009. [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), February 2008. Farinacci, et al. Expires October 14, 2010 [Page 33] =0C Internet-Draft LISP for Multicast Environments April 2010 Appendix A. Document Change Log A.1. Changes to draft-ietf-lisp-multicast-03.txt o Posted April 2010. o Added section 8.1.2 to address Joel Halpern's comment about receiver sites joining the same source site via 2 different RLOCs, each being a separate ITR. o Change all occurences of "mPTR" to "mPETR" to become more consistent with uPITRs and uPETRs described in [INTWORK]. That is, an mPETR is a LISP multicast router that decapsulates multicast packets that are encapsulated to it by ITRs in multicast source sites. o Add clarifications in section 9 about how homogeneous multicast encapsulation should occur. As well as describing in this section, how to deal with mixed-locator sets to avoid heterogeneous encapsulation. o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges of LISP global multicast network. A.2. Changes to draft-ietf-lisp-multicast-02.txt o Posted September 2009. o Added Document Change Log appendix. o Specify that the LISP Encapsulated Control Message be used for unicasting PIM Join/Prune messages from ETRs to ITRs. A.3. Changes to draft-ietf-lisp-multicast-01.txt o Posted November 2008. o Specified that PIM Join/Prune unicast messages that get sent from ETRs to ITRs of a source multicast site get LISP encapsulated in destination UDP port 4342. o Add multiple RLOCs per ITR per Yiqun's comments. o Indicate how static RPs can be used when LISP is run using Bidir- PIM in the core. o Editorial changes per Liming comments. Farinacci, et al. Expires October 14, 2010 [Page 34] =0C Internet-Draft LISP for Multicast Environments April 2010 o Add Mttrace Considersations section. A.4. Changes to draft-ietf-lisp-multicast-00.txt o Posted April 2008. o Renamed from draft-farinacci-lisp-multicast-01.txt. Farinacci, et al. Expires October 14, 2010 [Page 35] =0C Internet-Draft LISP for Multicast Environments April 2010 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA USA Email: dino@cisco.com Dave Meyer cisco Systems Tasman Drive San Jose, CA USA Email: dmm@cisco.com John Zwiebel cisco Systems Tasman Drive San Jose, CA USA Email: jzwiebel@cisco.com Stig Venaas cisco Systems Tasman Drive San Jose, CA USA Email: stig@cisco.com Farinacci, et al. Expires October 14, 2010 [Page 36] =0C --Apple-Mail-4-808289125 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-4-808289125-- From dino@cisco.com Tue Apr 13 22:32:59 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74AAA3A6B9D for ; Tue, 13 Apr 2010 22:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL7pC2pkXnI0 for ; Tue, 13 Apr 2010 22:32:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 280283A684F for ; Tue, 13 Apr 2010 22:32:07 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: rfcdiff-lisp-06-to-07.html, draft-ietf-lisp-07.txt : 188878, 182182 X-IronPort-AV: E=Sophos;i="4.52,202,1270425600"; d="txt'?html'217?scan'217,208,217";a="514584597" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2010 05:32:01 +0000 Received: from [192.168.1.7] (sjc-vpn5-702.cisco.com [10.21.90.190]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3E5Vxe9006743 for ; Wed, 14 Apr 2010 05:32:00 GMT Message-Id: <481E6DE2-4D76-49A0-B1C6-1635F8914C1A@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-17-858143068 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Apr 2010 22:31:59 -0700 X-Mailer: Apple Mail (2.936) Subject: [lisp] Proposed changes for draft-ietf-lisp-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 05:32:59 -0000 --Apple-Mail-17-858143068 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello LISPers, we'd like to open a review period for the -07 changes before the draft is posted to the ID directory. We would like comments and discussion by Friday April 23rd. The major changes were presented and discussed at the Anaheim IETF, 2 by me and 1 by Luigi, and they are: (1) Changing the data-header format to add V-bit for Versioning and I- bit for Instance IDs. (2) Adding a list ITR-RLOCs in the Map-Request to deal with heterogeneous address-families in different sites. (3) Using Map-Versioning (and not Version-Hashing) as the mapping update solution. Changes to draft-ietf-lisp-07.txt include: o Posted April 2010. o Added I-bit to data header so LSB field can also be used as an Instance ID field. When this occurs, the LSB field is reduced to 8-bits (from 32-bits). o Added V-bit to the data header so the 24-bit nonce field can also be used for source and destination version numbers. o Added Map-Version 12-bit value to the EID-record to be used in all of Map-Request, Map-Reply, and Map-Register messages. o Added multiple ITR-RLOC fields to the Map-Request packet so an ETR can decide what address to select for the destination of a Map- Reply. o Added L-bit (Local RLOC bit) and P-bit (Probe-Reply RLOC bit) to the Locator-Set record of an EID-record for a Map-Reply message. The L-bit indicates which RLOCs in the locator-set are local to the sender of the message. The P-bit indicates which RLOC is the source of a RLOC-probe Reply (Map-Reply) message. o Add reference to the LISP Canonical Address Format [LCAF] draft. o Made editorial and clarification changes based on comments from Dhirendra Trivedi. o Added wordsmithing comments from Joel Halpern on DF=1 setting. o Add John Zwiebel clarification to Echo Nonce Algorithm section 6.3.1. o Add John Zwiebel comment about expanding on proxy-bit for Map- Register messages. o Add NAT section per Ron Bonica comments. o Fix IDnits issues per Ron Bonica. o Added section on Virtualization and Segmentation to explain the use if the Instance ID field in the data header. Thanks, Dino/Dave/Darrel/Vince/Luigi/Damien ---- --Apple-Mail-17-858143068 Content-Disposition: attachment; filename=rfcdiff-lisp-06-to-07.html Content-Type: text/html; x-unix-mode=0600; name="rfcdiff-lisp-06-to-07.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-06.txt draft-ietf-lisp-07.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: July 24, October 15, 2010                                       D. Lewis
                                                           cisco Systems
                                                        January 20,
                                                          April 13, 2010

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-06.txt
                           draft-ietf-lisp-07

Abstract

   This draft describes a simple, incremental, network-based protocol to
   implement separation of Internet addresses into Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  This mechanism requires no
   changes to host stacks and no major changes to existing database
   infrastructures.  The proposed protocol can be implemented in a
   relatively small number of routers.

   This proposal was stimulated by the problem statement effort at the
   Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
   place in October 2006.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 24, October 15, 2010.

Copyright Notice
   Copyright (c) 2010 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 BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  Tunneling Details  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 18
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 21 22
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 22
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 22 23
       5.4.3.  Using Virtualization and Segmentation with LISP  . . . 24
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 24 25
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 24 25
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 26 27
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 26 27
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 28 29
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 30 31
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 33 34
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 35 37
       6.1.7.  Encapsualted  Encapsulated Control Message Format  . . . . . . . . . 37 38
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 39 40
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 40 41
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 43 44
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 44 45
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 45 46
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 46 47
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 46 47
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 47 48
       6.5.3.  Database Map Versioning  . . . . . . . . . . . . . . . 49
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 49 51
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 50 52
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 51 53
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 51 53
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 52 54
     8.4.  LISP Functionality with Conventional NATs  . . . . . . . . 54
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 53 55
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 54 56
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 54 56
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 54 56
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 56 58
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 56 58
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 56 58
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 56 58
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 58 60
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 58 60
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 60 62
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 61 63
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 64
   14. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 62
   14. 65
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
     14.1. 68
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 65
     14.2. 68
     15.2. Informative References . . . . . . . . . . . . . . . . . . 66 69
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 69 73
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 70 74
     B.1.  Changes to draft-ietf-lisp-06.txt draft-ietf-lisp-07.txt  . . . . . . . . . . . . 70 74
     B.2.  Changes to draft-ietf-lisp-05.txt draft-ietf-lisp-06.txt  . . . . . . . . . . . . 71 75
     B.3.  Changes to draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt  . . . . . . . . . . . . 71 76
     B.4.  Changes to draft-ietf-lisp-03.txt draft-ietf-lisp-04.txt  . . . . . . . . . . . . 73 76
     B.5.  Changes to draft-ietf-lisp-02.txt draft-ietf-lisp-03.txt  . . . . . . . . . . . . 74 78
     B.6.  Changes to draft-ietf-lisp-01.txt draft-ietf-lisp-02.txt  . . . . . . . . . . . . 74 78
     B.7.  Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 79
     B.8.  Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 74 79
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 80

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Many years of discussion about the current IP routing and addressing
   architecture have noted that its use of a single numbering space (the
   "IP address") for both host transport session identification and
   network routing creates scaling issues (see [CHIAPPA] and [RFC1498]).
   A number of scaling benefits would be realized by separating the
   current IP address into separate spaces for Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs); among them are:

   1.  Reduction of routing table size in the "default-free zone" (DFZ).
       Use of a separate numbering space for RLOCs will allow them to be
       assigned topologically (in today's Internet, RLOCs would be
       assigned by providers at client network attachment points),
       greatly improving aggregation and reducing the number of
       globally-visible, routable prefixes.

   2.  More cost-effective multihoming for sites that connect to
       different service providers where they can control their own
       policies for packet flow into the site without using extra
       routing table resources of core routers.

   3.  Easing of renumbering burden when clients change providers.
       Because host EIDs are numbered from a separate, non-provider-
       assigned and non-topologically-bound space, they do not need to
       be renumbered when a client site changes its attachment points to
       the network.

   4.  Traffic engineering capabilities that can be performed by network
       elements and do not depend on injecting additional state into the
       routing system.  This will fall out of the mechanism that is used
       to implement the EID/RLOC split (see Section 4).

   5.  Mobility without address changing.  Existing mobility mechanisms
       will be able to work in a locator/ID separation scenario.  It
       will be possible for a host (or a collection of hosts) to move to
       a different point in the network topology either retaining its
       home-based address or acquiring a new address based on the new
       network location.  A new network location could be a physically
       different point in the network topology or the same physical
       point of the topology with a different provider.

   This draft describes protocol mechanisms to achieve the desired
   functional separation.  For flexibility, the mechanism used for
   forwarding packets is decoupled from that used to determine EID to
   RLOC mappings.  This document covers the former.  For the later, latter, see
   [CONS], [ALT], [EMACS], [RPMD], and [NERD].  This work is in response
   to and intended to address the problem statement that came out of the
   RAWS effort [RFC4984].

   The Routing and Addressing problem statement can be found in [RADIR].

   This draft focuses on a router-based solution.  Building the solution
   into the network will facilitate incremental deployment of the
   technology on the Internet.  Note that while the detailed protocol
   specification and examples in this document assume IP version 4
   (IPv4), there is nothing in the design that precludes use of the same
   techniques and mechanisms for IPv6.  It should be possible for IPv4
   packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4
   RLOCs.

   Related work on host-based solutions is described in Shim6 [SHIM6] [RFC5533]
   and HIP [RFC4423].  Related work on a router-based solution is
   described in [GSE].  This draft attempts to not compete or overlap
   with such solutions and the proposed protocol changes are expected to
   complement a host-based mechanism when Traffic Engineering
   functionality is desired.

   Some of the design goals of this proposal include:

   1.  Require no hardware or software changes to end-systems (hosts).

   2.  Minimize required changes to Internet infrastructure.

   3.  Be incrementally deployable.

   4.  Require no router hardware changes.

   5.  Minimize the number of routers which have to be modified.  In
       particular, most customer site routers and no core routers
       require changes.

   6.  Minimize router software changes in those routers which are
       affected.

   7.  Avoid or minimize packet loss when EID-to-RLOC mappings need to
       be performed.

   There are 4 variants of LISP, which differ along a spectrum of strong
   to weak dependence on the topological nature and possible need for
   routability of EIDs.  The variants are:

   LISP 1:  uses EIDs that are routable through the RLOC topology for
      bootstrapping EID-to-RLOC mappings.  [LISP1] This was intended as
      a prototyping mechanism for early protocol implementation.  It is
      now deprecated and should not be deployed.

   LISP 1.5:  uses EIDs that are routable for bootstrapping EID-to-RLOC
      mappings; such routing is via a separate topology.

   LISP 2:  uses EIDS that are not routable and EID-to-RLOC mappings are
      implemented within the DNS.  [LISP2]

   LISP 3:  uses non-routable EIDs that are used as lookup keys for a
      new EID-to-RLOC mapping database.  Use of Distributed Hash Tables
      [DHTs] [LISPDHT] to implement such a database would be an area to
      explore.  Other examples of new mapping database services are
      [CONS], [ALT], [RPMD], [NERD], and [APT].

   This document on LISP 1.5, and LISP 3 variants, both of which rely on
   a router-based distributed cache and database for EID-to-RLOC
   mappings.  The LISP 1.0 mechanism works but does not allow reduction
   of routing information in the default-free-zone of the Internet.  The
   LISP 2 mechanisms are put on hold and may never come to fruition
   since it is not architecturally pure to have routing depend on
   directory and directory depend on routing.  The LISP 3 mechanisms
   will be documented elsewhere but may use the control-plane options
   specified in this specification.

3.  Definition of Terms

   Provider Independent (PI) Addresses:   an address block assigned from
      a pool where blocks are not associated with any particular
      location in the network (e.g. from a particular service provider),
      and is therefore not topologically aggregatable in the routing
      system.

   Provider Assigned (PA) Addresses:   a block of IP addresses that are
      assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider CIDR block and is aggregated into the larger block before
      being advertised into the global Internet.  Traditionally, IP
      multihoming has been implemented by each multi-homed site
      acquiring its own, globally-visible prefix.  LISP uses only
      topologically-assigned and aggregatable address blocks for RLOCs,
      eliminating this demonstrably non-scalable practice.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
      tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
      lookup.  An EID maps to one or more RLOCs.  Typically, RLOCs are
      numbered from topologically-aggregatable blocks that are assigned
      to a site at each point to which it attaches to the global
      Internet; where the topology is defined by the connectivity of
      provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains an destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.  When used in
      discussions with other Locator/ID separation proposals, a LISP EID
      will be called a "LEID".  Throughout this document, any references
      to "EID" refers to an LEID.

   EID-prefix:   A power-of-2 block of EIDs which are allocated to a
      site by an address allocation authority.  EID-prefixes are
      associated with a set of RLOC addresses which make up a "database
      mapping".  EID-prefix allocations can be broken up into smaller
      blocks when an RLOC set is to be associated with the smaller EID-
      prefix.  A globally routed address block (whether PI or PA) is not
      an EID-prefix.  However, a globally routed address block may be
      removed from global routing and reused as an EID-prefix.  A site
      that receives an explicitly allocated EID-prefix may not use that
      EID-prefix as a globally routed prefix assigned to RLOCs.

   End-system:   is an IPv4 or IPv6 device that originates packets with
      a single IPv4 or IPv6 header.  The end-system supplies an EID
      value for the destination address field of the IP header when
      communicating globally (i.e. outside of its routing domain).  An
      end-system can be a host computer, a switch or router device, or
      any network appliance.

   Ingress Tunnel Router (ITR):   a router which accepts an IP packet
      with a single IP header (more precisely, an IP packet that does
      not contain a LISP header).  The router treats this "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally-routable RLOCs in the source address field and the
      result of the mapping lookup in the destination address field.
      Note that this destination RLOC may be an intermediate, proxy
      device that has better knowledge of the EID-to-RLOC mapping closer
      to the destination EID.  In general, an ITR receives IP packets
      from site end-systems on one side and sends LISP-encapsulated IP
      packets toward the Internet on the other side.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating hosts
      supplied EID).

   TE-ITR:   is an ITR that is deployed in a service provider network
      that prepends an additional LISP header for Traffic Engineering
      purposes.

   Egress Tunnel Router (ETR):   a router that accepts an IP packet
      where the destination address in the "outer" IP header is one of
      its own RLOCs.  The router strips the "outer" header and forwards
      the packet based on the next IP header found.  In general, an ETR
      receives LISP-encapsulated IP packets from the Internet on one
      side and sends decapsulated IP packets to site end-systems on the
      other side.  ETR functionality does not have to be limited to a
      router device.  A server host can be the endpoint of a LISP tunnel
      as well.

   TE-ETR:   is an ETR that is deployed in a service provider network
      that strips an outer LISP header for Traffic Engineering purposes.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality is at the CE
      router.

   EID-to-RLOC Cache:   a short-lived, on-demand table in an ITR that
      stores, tracks, and is responsible for timing-out and otherwise
      validating EID-to-RLOC mappings.  This cache is distinct from the
      full "database" of EID-to-RLOC mappings, it is dynamic, local to
      the ITR(s), and relatively small while the database is
      distributed, relatively static, and much more global in scope.

   EID-to-RLOC Database:   a global distributed database that contains
      all known EID-prefix to RLOC mappings.  Each potential ETR
      typically contains a small piece of the database: the EID-to-RLOC
      mappings for the EID prefixes "behind" the router.  These map to
      one of the router's own, globally-visible, IP addresses.

   Recursive Tunneling:   when a packet has more than one LISP IP
      header.  Additional layers of tunneling may be employed to
      implement traffic engineering or other re-routing as needed.  When
      this is done, an additional "outer" LISP header is added and the
      original RLOCs are preserved in the "inner" header.  Any
      references to tunnels in this specification refers to dynamic
      encapsulating tunnels and never are they statically configured.

   Reencapsulating Tunnels:   when a packet has no more than one LISP IP
      header (two IP headers total) and when it needs to be diverted to
      new RLOC, an ETR can decapsulate the packet (remove the LISP
      header) and prepends a new tunnel header, with new RLOC, on to the
      packet.  Doing this allows a packet to be re-routed by the re-
      encapsulating router without adding the overhead of additional
      tunnel headers.  Any references to tunnels in this specification
      refers to dynamic encapsulating tunnels and never are they
      statically configured.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
      header that follows the UDP header, an ITR prepends or an ETR
      strips.

   Address Family Indicator Identifier (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI] and [RFC1700] for details.  An
      AFI value of 0 used in this specification indicates an unspecified
      encoded address where the the length of the address is 0 bytes
      following the 16-bit AFI value of 0.  Also, refer to [LCAF] for
      LISP specific AFI encodings.

   Negative Mapping Entry:   also known as a negative cache entry, is an
      EID-to-RLOC entry where an EID-prefix is advertised or stored with
      no RLOCs.  That is, the locator-set for the EID-to-RLOC entry is
      empty or has an encoded locator count of 0.  This type of entry
      could be used to describe a prefix from a non-LISP site, which is
      explicitly not in the mapping database.  There are a set of well
      defined actions that are encoded in a Negative Map-Reply.

   Data Probe:   a LISP-encapsulated data packet where the inner header
      destination address equals the outer header destination address
      used to trigger a Map-Reply by a decapsulating ETR.  In addition,
      the original packet is decapsulated and delivered to the
      destination host.  A Data Probe is used in some of the mapping
      database designs to "probe" or request a Map-Reply from an ETR; in
      other cases, Map-Requests are used.  See each mapping database
      design for details.

   Proxy ITR (PITR):   also known as a PTR is defined and described in
      [INTERWORK], a PITR acts like an ITR but does so on behalf of non-
      LISP sites which send packets to destinations at LISP sites.

   Proxy ETR (PETR):   is defined and described in [INTERWORK], a PETR
      acts like an ETR but does so on behalf of LISP sites which send
      packets to destinations at non-LISP sites.

4.  Basic Overview

   One key concept of LISP is that end-systems (hosts) operate the same
   way they do today.  The IP addresses that hosts use for tracking
   sockets, connections, and for sending and receiving packets do not
   change.  In LISP terminology, these IP addresses are called Endpoint
   Identifiers (EIDs).

   Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC.

   This design introduces "Tunnel Routers", which prepends LISP headers
   on host-originated packets and strip them prior to final delivery to
   their destination.  The IP addresses in this "outer header" are
   RLOCs.  During end-to-end packet exchange between two Internet hosts,
   an ITR prepends a new LISP header to each packet and an egress tunnel
   router strips the new header.  The ITR performs EID-to-RLOC lookups
   to determine the routing path to the the ETR, which has the RLOC as
   one of its IP addresses.

   Some basic rules governing LISP are:

   o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.

   o  EIDs are always IP addresses assigned to hosts.

   o  LISP routers mostly deal with Routing Locator addresses.  See
      details later in Section 4.1 to clarify what is meant by "mostly".

   o  RLOCs are always IP addresses assigned to routers; preferably,
      topologically-oriented addresses from provider CIDR blocks.

   o  When a router originates packets it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g. when
      terminating a transport session such as SSH, TELNET, or SNMP), it
      may use an EID that is explicitly assigned for that purpose.  An
      EID that identifies the router as a host MUST NOT be used as an
      RLOC; an EID is only routable within the scope of a site.  A
      typical BGP configuration might demonstrate this "hybrid" EID/RLOC
      usage where a router could use its "host-like" EID to terminate
      iBGP sessions to other routers in a site while at the same time
      using RLOCs to terminate eBGP sessions to routers outside the
      site.

   o  EIDs are not expected to be usable for global end-to-end
      communication in the absence of an EID-to-RLOC mapping operation.
      They are expected to be used locally for intra-site communication.

   o  EID prefixes are likely to be hierarchically assigned in a manner
      which is optimized for administrative convenience and to
      facilitate scaling of the EID-to-RLOC mapping database.  The
      hierarchy is based on a address allocation hierarchy which is not
      dependent on the network topology.

   o  EIDs may also be structured (subnetted) in a manner suitable for
      local routing within an autonomous system.

   An additional LISP header may be prepended to packets by a transit
   router (i.e.  TE-ITR) when re-routing of the path for a packet is
   desired.  An obvious instance of this would be an ISP router that
   needs to perform traffic engineering for packets in flow through its
   network.  In such a situation, termed Recursive Tunneling, an ISP
   transit acts as an additional ingress tunnel router and the RLOC it
   uses for the new prepended header would be either a TE-ETR within the
   ISP (along intra-ISP traffic engineered path) or a TE-ETR within
   another ISP (an inter-ISP traffic engineered path, where an agreement
   to build such a path exists).

   This specification mandates that no more than two LISP headers get
   prepended to a packet.  This avoids excessive packet overhead as well
   as possible encapsulation loops.  It is believed two headers is
   sufficient, where the first prepended header is used at a site for
   Location/Identity separation and second prepended header is used
   inside a service provider for Traffic Engineering purposes.

   Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
   For example, the ITR for a particular end-to-end packet exchange
   might be the first-hop or default router within a site for the source
   host.  Similarly, the egress tunnel router might be the last-hop
   router directly-connected to the destination host.  Another example,
   perhaps for a VPN service out-sourced to an ISP by a site, the ITR
   could be the site's border router at the service provider attachment
   point.  Mixing and matching of site-operated, ISP-operated, and other
   tunnel routers is allowed for maximum flexibility.  See Section 8 for
   more details.

4.1.  Packet Flow Sequence

   This section provides an example of the unicast packet flow with the
   following conditions:

   o  Source host "host1.abc.com" is sending a packet to
      "host2.xyz.com", exactly what host1 would do if the site was not
      using LISP.

   o  Each site is multi-homed, so each tunnel router has an address
      (RLOC) assigned from the service provider address block for each
      provider to which that particular tunnel router is attached.

   o  The ITR(s) and ETR(s) are directly connected to the source and
      destination, respectively.

   o  Data Probes are used to solicit Map-Replies versus using Map-
      Requests.  And the Data Probes are sent on the underlying topology
      (the LISP 1.0 variant) but could also be sent over an alternative
      topology (the LISP 1.5 variant) as it would in [ALT].

   Client host1.abc.com wants to communicate with server host2.xyz.com:

   1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
       It does a DNS lookup on host2.xyz.com.  An A/AAAA record is
       returned.  This address is used as the destination EID and the
       locally-assigned address of host1.abc.com is used as the source
       EID.  An IPv4 or IPv6 packet is built using the EIDs in the IPv4
       or IPv6 header and sent to the default router.

   2.  The default router is configured as an ITR.  The ITR must be able
       to map the EID destination to an RLOC of the ETR at the
       destination site.  The ITR prepends a LISP header to the packet,
       with one of its RLOCs as the source IPv4 or IPv6 address.  The
       destination EID from the original packet header is used as the
       destination IPv4 or IPv6 in the prepended LISP header.
       Subsequent packets, where the outer destination address is the
       destination EID will be sent until EID-to-RLOC mapping is
       learned.

   3.  In LISP 1, the packet is routed through the Internet as it is
       today.  In LISP 1.5, the packet is routed on a different topology
       which may have EID prefixes distributed and advertised in an
       aggregatable fashion.  In either case, the packet arrives at the
       ETR.  The router is configured to "punt" the packet to the
       router's processor.  See Section 7 for more details.  For LISP
       2.0 and 3.0, the behavior is not fully defined yet.

   4.  The LISP header is stripped so that the packet can be forwarded
       by the router control plane.  The router looks up the destination
       EID in the router's EID-to-RLOC database (not the cache, but the
       configured data structure of RLOCs).  An EID-to-RLOC Map-Reply
       message is originated by the ETR and is addressed to the source
       RLOC in the LISP header of the original packet (this is the ITR).
       The source RLOC of the Map-Reply is one of the ETR's RLOCs.

   5.  The ITR receives the Map-Reply message, parses the message (to
       check for format validity) and stores the mapping information
       from the packet.  This information is put in the ITR's EID-to-
       RLOC mapping cache (this is the on-demand cache, the cache where
       entries time out due to inactivity).

   6.  Subsequent packets from host1.abc.com to host2.xyz.com will have
       a LISP header prepended by the ITR using the appropriate RLOC as
       the LISP header destination address learned from the ETR.  Note,
       the packet may be sent to a different ETR than the one which
       returned the Map-Reply due to the source site's hashing policy or
       the destination site's locator-set policy.

   7.  The ETR receives these packets directly (since the destination
       address is one of its assigned IP addresses), strips the LISP
       header and forwards the packets to the attached destination host.

   In order to eliminate the need for a mapping lookup in the reverse
   direction, an ETR MAY create a cache entry that maps the source EID
   (inner header source IP address) to the source RLOC (outer header
   source IP address) in a received LISP packet.  Such a cache entry is
   termed a "gleaned" mapping and only contains a single RLOC for the
   EID in question.  More complete information about additional RLOCs
   SHOULD be verified by sending a LISP Map-Request for that EID.  Both
   ITR and the ETR may also influence the decision the other makes in
   selecting an RLOC.  See Section 6 for more details.

5.  Tunneling Details

   This section describes the LISP Data Message which defines the
   tunneling header used to encapsulate IPv4 and IPv6 packets which
   contain EID addresses.  Even though the following formats illustrate
   IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2
   combinations are supported as well.

   Since additional tunnel headers are prepended, the packet becomes
   larger and in theory can exceed the MTU of any link traversed from
   the ITR to the ETR.  It is recommended, in IPv4 that packets do not
   get fragmented as they are encapsulated by the ITR.  Instead, the
   packet is dropped and an ICMP Too Big message is returned to the
   source.

   Based on informal surveys of large ISP traffic patterns, it appears
   that most transit paths can accommodate a path MTU of at least 4470
   bytes.  The exceptions, in terms of data rate, number of hosts
   affected, or any other metric are expected to be vanishingly small.

   To address MTU concerns, mainly raised on the RRG mailing list, the
   LISP deployment process will include collecting data during its pilot
   phase to either verify or refute the assumption about minimum
   available MTU.  If the assumption proves true and transit networks
   with links limited to 1500 byte MTUs are corner cases, it would seem
   more cost-effective to either upgrade or modify the equipment in
   those transit networks to support larger MTUs or to use existing
   mechanisms for accommodating packets that are too large.

   For this reason, there is currently no plan for LISP to add any new
   additional, complex mechanism for implementing fragmentation and
   reassembly in the face of limited-MTU transit links.  If analysis
   during LISP pilot deployment reveals that the assumption of
   essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect,
   then LISP can be modified prior to protocol standardization to add
   support for one of the proposed fragmentation and reassembly schemes.
   Note that two simple existing schemes are detailed in Section 5.4.

5.1.  LISP IPv4-in-IPv4 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|  rflags |                 Nonce   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       Locator                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  LISP IPv6-in-IPv6 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Payload Length        | Next Header=17|   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|  rflags |                 Nonce   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       Locator                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Tunnel Header Field Descriptions

   Inner Header:  is the inner header, preserved from the datagram
      received from the originating host.  The source and destination IP
      addresses are EIDs.

   Outer Header:  is the outer header prepended by an ITR.  The address
      fields contain RLOCs obtained from the ingress router's EID-to-
      RLOC cache.  The IP protocol number is "UDP (17)" from [RFC0768].
      The DF bit of the Flags field is set to 0 when the method in
      Section 5.4.1 is used and set to 1 when the method in
      Section 5.4.2 is used.

   UDP Header:  contains a ITR selected source port when encapsulating a
      packet.  See Section 6.4 for details on the hash algorithm used to
      select a source port based on the 5-tuple of the inner header.
      The destination port MUST be set to the well-known IANA assigned
      port value 4341.

   UDP Checksum:  this field SHOULD be transmitted as zero by an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is received by an ETR, the ETR
      MUST accept the packet for decapsulation.  When an ITR transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes will
      be made to align LISP with the outcome of the broader discussion.

   UDP Length:  for an IPv4 encapsulated packet, the inner header Total
      Length plus the UDP and LISP header lengths are used.  For an IPv6
      encapsulated packet, the inner header Payload Length plus the size
      of the IPv6 header (40 bytes) plus the size of the UDP and LISP
      headers are used.  The UDP header length is 8 bytes.

   N: this is the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.  Both N and V bits MUST
      NOT be set in the same packet.  If they are, a decapsulating ETR
      must treat the "Nonce/Map-Version" field as having a Nonce value
      present.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

     x 1 x x 0 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Locator Status Bits                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1.  This bit should be ignored and has no
      meaning when the N bit is set to 0.  See section Section 6.3.1 for
      details.

   rflags:

   V: this 5-bit field is reserved for future flag use.  It is set
      to 0 on transmit and ignored on receipt.

   LISP Nonce:  is a 24-bit value that is randomly generated by an ITR
      when the N-bit Map-Version present bit.  When this bit is set to 1.  The nonce is 1,
      the N bit must be 0.  Refer to Section 6.5.3 for more details.
      This bit indicates that the first 4 bytes of the LISP header is
      encoded as:

     0 x 0 1 x x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator Status Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I: this is the Instance ID bit.  See Section 5.4.3 for more details.
      When this bit is set to 1, the Locator Status Bits field is
      reduced to 8-bits and the high-order 24-bits are used as an
      Instance ID.  If the L-bit is set to 0, then the low-order 8 bits
      are transmited as zero and ignored on receipt.  The format of the
      last 4 bytes of the LISP header would look like:

     x x x x 1 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID                   |     LSBs      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   flags:  this 3-bit field is reserved for future flag use.  It is set
      to 0 on transmit and ignored on receipt.

   LISP Nonce:  is a 24-bit value that is randomly generated by an ITR
      when the N-bit is set to 1.  The nonce is also used when the E-bit
      is set to request the nonce value to be echoed by the other side
      when packets are returned.  When the E-bit is clear but the N-bit
      is set, a remote ITR is either echoing a previously requested
      echo-nonce or providing a random nonce.  See section Section 6.3.1 for
      more details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the least
      significant bit of the 32-bit field.  The field is 32-bits when the I-bit is
      set to 0 and is 8 bits when the I-bit is set to 1.  When a bit Locator
      Status Bit is set to 1, the ITR is indicating to the ETR the RLOC
      associated with the bit ordinal has up status.  See Section 6.3
      for details on how an ITR can determine other ITRs at the site are
      reachable.  When a site has multiple EID-prefixes which result in
      multiple mappings (where each could have a different locator-set),
      the Locator Status Bits setting in an encapsulated packet MUST
      reflect the mapping for the EID-prefix that the inner-header
      source EID address matches.

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

   o  The outer header Type of Service field (or the Traffic Class
      field, in the case of IPv6) SHOULD be copied from the inner header
      Type of Service field (with one caveat, see below).

   When doing Re-encapsulated Tunneling:

   o  The new outer header Time to Live field SHOULD be copied from the
      stripped outer header Time to Live field.

   o  The new outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below).

   Copying the TTL serves two purposes: first, it preserves the distance
   the host intended the packet to travel; second, and more importantly,
   it provides for suppression of looping packets in the event there is
   a loop of concatenated tunnels due to misconfiguration.

   The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
   field and the IPv6 Traffic Class field [RFC3168].  The ECN field
   requires special treatment in order to avoid discarding indications
   of congestion [RFC3168].  ITR encapsulation MUST copy the 2-bit ECN
   field from the inner header to the outer header.  Re-encapsulation
   MUST copy the 2-bit ECN field from the stripped outer header to the
   new outer header.  If the ECN field contains a congestion indication
   codepoint (the value is '11', the Congestion Experienced (CE)
   codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
   the stripped outer header to the surviving inner header that is used
   to forward the packet beyond the ETR.  These requirements preserve
   Congestion Experienced (CE) indications when a packet that uses ECN
   traverses a LISP tunnel and becomes marked with a CE indication due
   to congestion between the tunnel endpoints.

5.4.  Dealing with Large Encapsulated Packets

   In the event that the MTU issues mentioned above prove to be more
   serious than expected, this section proposes 2 simple mechanisms to
   deal with large packets.  One is stateless using IP fragmentation and
   the other is stateful using Path MTU Discovery [RFC1191].

   It is left to the implementor to decide if the stateless or stateful
   mechanism should be implemented.  Both or neither can be decided as
   well since it is a local decision in the ITR regarding how to deal
   with MTU issues.  Sites can interoperate with differing mechanisms.

   Both stateless and stateful mechanisms also apply to Reencapsulating
   and Recursive Tunneling.  So any actions reference below to an ITR
   also apply to an TE-ITR.

5.4.1.  A Stateless Solution to MTU Handling

   An ITR stateless solution to handle MTU issues is described as
   follows:

   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would receive from a source inside of
       its site.

   2.  Define L to be the maximum size, in bytes, a packet of size S
       would be after the ITR prepends the LISP header, UDP header, and
       outer network layer header of size H.

   3.  Calculate: S + H = L.

   When an ITR receives a packet from a site-facing interface and adds H
   bytes worth of encapsulation to yield a packet size greater than L
   bytes, it resolves the MTU issue by first splitting the original
   packet into 2 equal-sized fragments.  A LISP header is then prepended
   to each fragment.  This will ensure that the new, encapsulated
   packets are of size (S/2 + H), which is always below the effective
   tunnel MTU.

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

   This behavior is performed by the ITR when the source host originates
   a packet with the DF field of the IP header is set to 0.  When the DF
   field of the IP header is set to 1, or the packet is an IPv6 packet
   originated by the source host, the ITR will drop the packet when the
   size is greater than L, and sends an ICMP Too Big message to the
   source with a value of S, where S is (L - H).

   When the outer header encapsulation uses an IPv4 header, an
   implementation should consider a default behavior of setting SHOULD set the DF bit to 1 so ETR fragment reassembly
   can be avoided.  An implementation MAY set the DF bit in such headers
   to 0 if it has good reason to believe there are unresolvable path MTU
   issues between the sending ITR and the receiving ETR.

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

   An ITR stateful solution to handle MTU issues is described as follows
   and was first introduced in [OPENLISP]:

   1.  The ITR will keep state of the effective MTU for each locator per
       mapping cache entry.  The effective MTU is what the core network
       can deliver along the path between ITR and ETR.

   2.  When an IPv6 encapsulated packet or an IPv4 encapsulated packet
       with DF bit set to 1, exceeds what the core network can deliver,
       one of the intermediate routers on the path will send an ICMP Too
       Big message to the ITR.  The ITR will parse the ICMP message to
       determine which locator is affected by the effective MTU change
       and then record the new effective MTU value in the mapping cache
       entry.

   3.  When a packet is received by the ITR from a source inside of the
       site and the size of the packet is greater than the effective MTU
       stored with the mapping cache entry associated with the
       destination EID the packet is for, the ITR will send an ICMP Too
       Big message back to the source.  The packet size advertised by
       the ITR in the ICMP Too Big message is the effective MTU minus
       the LISP encapsulation length.

   Even though this mechanism is stateful, it has advantages over the
   stateless IP fragmentation mechanism, by not involving the
   destination host with reassembly of ITR fragmented packets.

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4

5.4.3.  Using Virtualization and IPv6 Control Plane Packet Formats

   The following new UDP packet types Segmentation with LISP

   When multiple organizations inside of a LISP site are used to retrieve EID-to-RLOC
   mappings:

       0                   1                   2                   3 using private
   addresses [RFC1918] as EID-prefixes, their address spaces must remain
   segregated due to possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.  See [LCAF] for details on address encodings.

   An Instance ID can be carried in a LISP encapsulated packet.  An ITR
   that prepends a LISP header, will copy a 24-bit value, used by the
   LISP router to uniquely identify the address space.  The value is
   copied to the Instance ID field of the LISP header and the I-bit is
   set to 1.

   When an ETR desapsulates a packet, the Instance ID from the LISP
   header is used as a table identifier to locate the forwarding table
   to use for the inner destination EID lookup.

   Some examples of the 24-bit value to copy or map into the Instance ID
   field could be a 802.1Q VLAN tag or a configured VRF-ID value.

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

   The following new UDP packet types are used to retrieve EID-to-RLOC
   mappings:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|  IHL  |Type of Service|          Total Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identification        |Flags|      Fragment Offset    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time to Live | Protocol = 17 |         Header Checksum       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Source Routing Locator                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Traffic Class |           Flow Label                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        | Next Header=17|   Hop Limit   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                     Source Routing Locator                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                  Destination Routing Locator                  +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LISP UDP-based messages are the Map-Request and Map-Reply
   messages.  When a UDP Map-Request is sent, the UDP source port is
   chosen by the sender and the destination UDP port number is set to
   4342.  When a UDP Map-Reply is sent, the source UDP port number is
   set to 4342 and the destination UDP port number is copied from the
   source port of either the Map-Request or the invoking data packet.

   The UDP Length field will reflect the length of the UDP header and
   the LISP Message payload.

   The UDP Checksum is computed and set to non-zero for Map-Request,
   Map-Reply, Map-Register and ECM control messages.  It MUST be checked
   on receipt and if the checksum fails, the packet MUST be dropped.

   LISP-CONS [CONS] use TCP to send LISP control messages.  The format
   of control messages includes the UDP header so the checksum and
   length fields can be used to protect and delimit message boundaries.

   This main LISP specification is the authoritative source for message
   format definitions for the Map-Request and Map-Reply messages.

6.1.1.  LISP Packet Type Allocations

   This section will be the authoritative source for allocating LISP
   Type values.  Current allocations are:

       Reserved:                          0    b'0000'
       LISP Map-Request:                  1    b'0001'
       LISP Map-Reply:                    2    b'0010'
       LISP Map-Register:                 3    b'0011'
       LISP Encapsulated Control Message: 8    b'1000'

6.1.2.  Map-Request Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|       Reserved      |   IRC   | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |            ITR-AFI   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Source EID         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Originating ITR RLOC                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.

   M: When set, it indicates a Map-Reply Record segment is included in
      the Map-Request.

   P: Indicates that a Map-Request should be treated as a "piggyback"
      locator reachability probe.  The receiver should respond with a
      Map-Reply with the P bit set and the nonce copied from the Map-
      Request.  See section Section 6.3.2 for more details.

   S: This is the SMR bit.  See Section 6.5.2 for details.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   IRC:  This 5-bit field is the ITR-RLOC Count which encodes the number
      of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this
      message.  Multiple ITR-RLOC Address fields are used so a Map-
      Replier can select which destination address to use for a Map-
      Reply.  The IRC value ranges from 0 to 31, where IRC value 0 means
      an ITR-RLOC address count of 1, an IRC value of 1 means an ITR-
      RLOC address count of 2, and so on up to an IRC value of 31, which
      means an ITR-RLOC address count of 32.

   Record Count:  The number of records in this Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   Source-EID-AFI:  Address family of the "Source EID Address" field.

   ITR-AFI:  Address family of the "Originating ITR RLOC Address" field.

   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, the value 0 is used.

   Originating ITR RLOC

   ITR-RLOC-AFI:  Address family of the "ITR-RLOC Address" field that
      follows this field.

   ITR-RLOC Address:  Used to give the ETR the option of
      returning a Map-Reply in selecting the address-family of this locator.
      destination address from any address family for the Map-Reply
      message.  This address MUST be a routable RLOC address.

   EID mask-len:  Mask length for EID prefix.

   EID-AFI:

   EID-prefix-AFI:  Address family of EID-prefix according to [RFC2434] [RFC5226]

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.  When a Map-Request is sent by an ITR because a
      data packet is received for a destination where there is no
      mapping entry, the EID-prefix is set to the destination IP address
      of the data packet.  And the 'EID mask-len' is set to 32 or 128
      for IPv4 or IPv6, respectively.  When an xTR wants to query a site
      about the status of a mapping it already has cached, the EID-
      prefix used in the Map-Request has the same mask-length as the
      EID-prefix returned from the site when it sent a Map-Reply
      message.

   Map-Reply Record:  When the M bit is set, this field is the size of
      the "Record" field in the Map-Reply format.  This Map-Reply record
      contains the EID-to-RLOC mapping entry associated with the Source
      EID.  This allows the ETR which will receive this Map-Request to
      cache the data if it chooses to do so.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.3.  EID-to-RLOC UDP Map-Request Message

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the later latter 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.

   In all cases, the UDP source port number for the Map-Request message
   is a randomly allocated 16-bit value and the UDP destination port
   number is set to the well-known destination port number 4342.  A
   successful Map-Reply updates the cached set of RLOCs associated with
   the EID prefix range.

   One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
   be filled in by the ITR.  The number of fields encoded must be placed
   in the IRC field.  The ITR MAY include all locally configured
   locators in this list or just provide one locator address from each
   address family it supports.  If the ITR erroneously provides no ITR-
   RLOC addresses, the Map-Replier MUST drop the Map-Request.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4342 with a LISP type value set to "Encapsulated Control Message",
   when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
   LISP encapsulated the same way from a Map-Server to an ETR.  Details
   on encapsulated Map-Requests and Map-Resolvers can be found in
   [LISP-MS].

   Map-Requests MUST be rate-limited.  It is recommended that a Map-
   Request for the same EID-prefix be sent no more than once per second.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request and it does
   not have this mapping in the map-cache, it may originate a "verifying
   Map-Request", addressed to the map-requesting ITR.  If the ETR has a
   map-cache entry that matches the "piggybacked" EID and the RLOC is in
   the locator-set for the entry, then it may send the "verifying Map-
   Request" directly to the originating Map-Request source.  If the RLOC
   is not in the locator-set, then the ETR MUST send the "verifying Map-
   Request" to the "piggybacked" EID.  Doing this forces the "verifying
   Map-Request" to go through the mapping database system to reach the
   authoritative source of information about that EID, guarding against
   RLOC-spoofing in in the "piggybacked" mapping data.

6.1.4.  Map-Reply Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=2 |P|E|            Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved Rsvd  |  Map-Version Number   |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags      |R|     |L|P|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   2 (Map-Reply)

   P: Indicates that the Map-Reply is in response to a "piggyback"
      locator reachability Map-Request.  The nonce field should contain
      a copy of the nonce value from the original Map-Request.  See
      section
      Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site is enabled for the Echo-Nonce locator
      reachability algorithm.  See Section 6.3.1 for more details.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   Record Count:  The number of records in this reply message.  A record
      is comprised of that portion of the packet labeled 'Record' above
      and occurs the number of times equal to Record count.

   Nonce:  A 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of the Map-
      Reply.

   Record TTL:  The time in minutes the recipient of the Map-Reply will
      store the mapping.  If the TTL is 0, the entry should be removed
      from the cache immediately.  If the value is 0xffffffff, the
      recipient can decide locally how long to store the mapping.

   Locator Count:  The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc'.  The locator count can
      be 0 indicating there are no locators for the EID-prefix.

   EID mask-len:  Mask length for EID prefix.

   ACT:  This 3-bit field describes negative Map-Reply actions.  These
      bits are used only when the 'Locator Count' field is set to 0.
      The action bits are encoded only in Map-Reply messages.  The
      actions defined are used by an ITR or PTR when a destination EID
      matches a negative mapping cache entry.  Unassigned values should
      cause a map-cache entry to be created and, when packets match this
      negative cache entry, they will be dropped.  The current assigned
      values are:

      (0) Drop:  The packet is dropped silently.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
         but natively forwarded.

      (2) Send-Map-Request:  The packet invokes sending a Map-Request.

   A: The Authoritative bit, when sent by a UDP-based message UDP-based message is always
      set to 1 by an ETR.  See [CONS] for TCP-based Map-Replies.  When a
      Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the
      Authoritative bit is set to 0.  This indicates to requesting ITRs
      that the Map-Reply was not originated by a LISP node managed at
      the site that owns the EID-prefix.

   Map-Version Number:  When this 12-bit value is always
      set by non-zero the ETR. Map-Reply
      reply sender is informing the ITR what the version number is for
      the EID-record contained in the Map-Reply.  The ETR can allocate
      this number internally but MUST coordinate this value with other
      ETRs for the site.  When this value is 0, there is no versioning
      information conveyed.  The Map-Version Number can be included in
      Map-Request and Map-Register messages.  See [CONS] Section 6.5.3 for TCP-based Map-Replies. more
      details.

   EID-AFI:  Address family of EID-prefix according to [RFC2434]. [RFC5226].

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

   Priority:  each RLOC is assigned a unicast priority.  Lower values
      are more preferable.  When multiple RLOCs have the same priority,
      they may be used in a load-split fashion.  A value of 255 means
      the RLOC MUST NOT be used for unicast forwarding.

   Weight:  when priorities are the same for multiple RLOCs, the weight
      indicates how to balance unicast traffic between them.  Weight is
      encoded as a percentage of total unicast packets that match the
      mapping entry.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to load-split traffic.  See
      Section 6.4 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.  When
      a single RLOC exists in a mapping entry, the weight value MUST be
      set to 100 and ignored on receipt.

   M Priority:  each RLOC is assigned a multicast priority used by an
      ETR in a receiver multicast site to select an ITR in a source
      multicast site for building multicast distribution trees.  A value
      of 255 means the RLOC MUST NOT be used for joining a multicast
      distribution tree.

   M Weight:  when priorities are the same for multiple RLOCs, the
      weight indicates how to balance building multicast distribution
      trees across multiple ITRs.  The weight is encoded as a percentage
      of total number of trees build to the source site identified by
      the EID-prefix.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to distribute multicast state across
      ITRs.

   Unused Flags:  set to 0 when sending and ignored on receipt.

   L: when this bit is set, the locator is flagged as a local locator to
      the ETR that is sending the Map-Reply.  When a Map-Server is doing
      proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to
      0 for all locators in this locator-set.

   P: when this bit is set, an ETR informs the RLOC-probing ITR that the
      locator address, for which this bit is set for, is the one being
      RLOC-probed and may be different from the source address of the
      Map-Reply.  An ITR that RLOC-probes a particular locator, MUST use
      this locator for retrieving the data structure used to store the
      fact that the locator is reachable.  The P bit is set for a single
      locator in the same locator set.  If an implementation sets more
      than one P bit erroneously, the receiver of the Map-Reply MUST
      select the first locator.  The P bit MUST NOT be set for locator-
      set records sent in Map-Request and Map-Register messages.

   R: when this bit is set, the locator is known to be reachable from
      the Map-Reply sender's perspective.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR or router acting as a proxy replier for the
      EID-prefix.  Note that the destination RLOC address MAY be an
      anycast address.  A source RLOC can be an anycast address as well.
      The source or destination RLOC MUST NOT be the broadcast address
      (255.255.255.255 or any subnet broadcast address known to the
      router), and MUST NOT be a link-local multicast address.  The
      source RLOC MUST NOT be a multicast address.  The destination RLOC
      SHOULD be a multicast address if it is being mapped from a
      multicast destination EID.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.5.  EID-to-RLOC UDP Map-Reply Message

   When a Data Probe packet or a Map-Request triggers a Map-Reply to be
   sent, the RLOCs associated with the EID-prefix matched by the EID in
   the original packet destination IP address field will be returned.
   The RLOCs in the Map-Reply are the globally-routable IP addresses of
   the ETR but are not necessarily reachable; separate testing of
   reachability is required.

   Note that a Map-Reply may contain different EID-prefix granularity
   (prefix + length) than the Map-Request which triggers it.  This might
   occur if a Map-Request were for a prefix that had been returned by an
   earlier Map-Reply.  In such a case, the requester updates its cache
   with the new prefix information and granularity.  For example, a
   requester with two cached EID-prefixes that are covered by a Map-
   Reply containing one, less-specific prefix, replaces the entry with
   the less-specific EID-prefix.  Note that the reverse, replacement of
   one less-specific prefix with multiple more-specific prefixes, can
   also occur but not by removing the less-specific prefix rather by
   adding the more-specific prefixes which during a lookup will override
   the less-specific prefix.

   When an ETR is configured with overlapping EID-prefixes, a Map-
   Request with an EID that longest matches any EID-prefix MUST be
   returned in a single Map-Reply message.  For instance, if an ETR had
   database mapping entries for EID-prefixes:

     10.0.0.0/8
     10.1.0.0/16
     10.1.1.0/24
     10.1.2.0/24

   A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
   count of 1 to be returned with a mapping record EID-prefix of
   10.1.1.0/24.

   A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record
   count of 3 to be returned with mapping records for EID-prefixes
   10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.

   Note that not all overlapping EID-prefixes need to be returned, only
   the more specifics (note in the second example above 10.0.0.0/8 was
   not returned for requesting EID 10.1.5.5) entries for the matching
   EID-prefix of the requesting EID.  When more than one EID-prefix is
   returned, all SHOULD use the same Time-to-Live value so they can all
   time out at the same time.  When a more specific EID-prefix is
   received later, its Time-to-Live value in the Map-Reply record can be
   stored even when other less specifics exist.  When a a less specific
   EID-prefix is received later, its map-cache expiration time should be
   set to the minimum expiration time of any more specific EID-prefix in
   the map-cache.

   Map-Replies SHOULD be sent for an EID-prefix no more often than once
   per second to the same requesting router.  For scalability, it is
   expected that aggregation of EID addresses into EID-prefixes will
   allow one Map-Reply to satisfy a mapping for the EID addresses in the
   prefix range thereby reducing the number of Map-Request messages.

   Map-Reply records can have an empty locator-set.  This type of a Map-
   Reply is called a Negative Map-Reply.  Negative Map-Replies convey
   special actions by the sender to the ITR or PTR which have solicited
   the Map-Reply.  There are two primary applications for Negative Map-
   Replies.  The first is for a Map-Resolver to instruct an ITR or PTR
   when a destination is for a LISP site versus a non-LISP site.  And
   the other is to source quench Map-Requests which are sent for non-
   allocated EIDs.

   For each Map-Reply record, the list of locators in a locator-set MUST
   appear in the same order for each ETR that originates a Map-Reply
   message.  The locator-set MUST be sorted in order of ascending IP
   address where an IPv4 locator address is considered numerically 'less
   than' an IPv6 locator address.

   When sending a Map-Reply message, the destination address is copied
   from the one of the ITR-RLOC fields from the Map-Request.  The ETR
   can choose a locator address from one of the address families it
   supports.  For Data-Probes, the destination address of the Map-Reply
   is copied from the source address of the Map-Request or Data-Probe message which is
   invoking the reply.  The source address of the Map-Reply is one of
   the local locator addresses listed in the locator-set of any mapping
   record in the message. message and should be chosen to allow uRPF checks to
   succeed in the upstream service provider.  The destination port of a
   Map-Reply message is copied from the source port of the Map-Request
   or Data-
   Probe Data-Probe and the source port of the Map-Reply message is set to
   the well-known UDP port 4342.

6.1.5.1.  Traffic Redirection with Coarse EID-Prefixes

   When an ETR is misconfigured or compromised, it could return coarse
   EID-prefixes in Map-Reply messages it sends.  The EID-prefix could
   cover EID-prefixes which are allocated to other sites redirecting
   their traffic to the locators of the compromised site.

   To solve this problem, there are two basic solutions that could be
   used.  The first is to have Map-Servers proxy-reply on behalf of ETRs
   so their registered EID-prefixes are the ones returned in Map-
   Replies.  Since the interaction between an ETR and Map-Server is
   secured with shared-keys, it is more difficult for an ETR to
   misbehave.  The second solution is to have ITRs and PTRs cache EID-
   prefixes with mask-lengths that are greater than or equal to a
   configured prefix length.  This limits the damage to a specific width
   of any EID-prefix advertised, but needs to be coordinated with the
   allocation of site prefixes.  These solutions can be used
   independently or at the same time.

   At the time of this writing, other approaches are being considered
   and researched.

6.1.6.  Map-Register Message Format

   The usage details of the Map-Register message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent in UDP with a destination UDP port of 4342 and a
   randomly selected UDP source port number.

   The Map-Register message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3 |P| |p|            Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved Rsvd  |  Map-Version Number   |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags      |R|     |L|P|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   3 (Map-Register)

   P: Set

   p: This is the Map-Reply proxy-bit, when set to 1 by an ETR which sends a Map-Register Map-
      Register message requesting for the Map-Server to proxy Map-Reply.
      The Map-Server will send non-authoritative Map-Replies on behalf
      of the ETR.  Details on this usage will be provided in a future
      version of this draft.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   Record Count:  The number of records in this Map-Register message.  A
      record is comprised of that portion of the packet labeled 'Record'
      above and occurs the number of times equal to Record count.

   Nonce:  This 8-byte Nonce field is set to 0 in Map-Register messages.

   Key ID:  A configured ID to find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The length in bytes of the
      Authentication Data field that follows this field.  The length of
      the the Authentication Data field is dependent on the Message
      Authentication Code (MAC) algorithm used.  The length field allows
      a device that doesn't know the MAC algorithm to correctly parse
      the packet.

   Authentication Data:  The message digest used from the output of the
      Message Authentication Code (MAC) algorithm.  The entire Map-
      Register payload is authenticated with this field preset to 0.
      After the MAC is computed, it is placed in this field.
      Implementations of this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   The definition of the rest of the Map-Register can be found in the
   Map-Reply section.  However, the record TTL field is not used and set
   to 0.

6.1.7.  Encapsualted  Encapsulated Control Message Format

   An Encapsulated Control Message is used to encapsulate control
   packets sent between xTRs and the mapping database system described
   in [LISP-MS].

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=8 |                   Reserved                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   IH  |                  (uses RLOC or EID addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The outer IPv4 or IPv6 header which uses RLOC addresses in the
      source and destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source
      port is randomly allocated.  The checksum field MUST be non-zero.

   LH:   Type 8 is defined to be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or IPv6 header as encoded by
      the first 4 bits after the reserved field.

   IH:   The inner IPv4 or IPv6 header which can use either RLOC or EID
      addresses in the header address fields.  When a Map-Request is
      encapsulated in this packet format the destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on the
      control packet being encapsulated.  When the control packet is a
      Map-Request or Map-Register, the source port is randomly assigned
      and the destination port is 4342.  When the control packet is a
      Map-Reply, the source port is 4342 and the destination port is
      assigned from the source port of the invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be non-zero.

   LCM:   The format is one of the control message formats described in
      this section.  At this time, only Map-Request messages and PIM
      Join-Prune messages [MLISP] are allowed to be encapsulated.
      Encapsulating other types of LISP control messages are for further
      study.  When Map-Requests are sent for RLOC-probing purposes (i.e
      the P-bit is set), they MUST not NOT be sent inside Encapsulated
      Control Messages.

6.2.  Routing Locator Selection

   Both client-side and server-side may need control over the selection
   of RLOCs for conversations between them.  This control is achieved by
   manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information may be gleaned from
   received tunneled packets or EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for choosing RLOCs and
   the controls that are available:

   o  Server-side returns one RLOC.  Client-side can only use one RLOC.
      Server-side has complete control of the selection.

   o  Server-side returns a list of RLOC where a subset of the list has
      the same best priority.  Client can only use the subset list
      according to the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing of control exists: the server-side determines the
      destination RLOC list and load distribution while the client-side
      has the option of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight of 0 for the RLOC subset list.  In this
      case, the client-side can choose how the traffic load is spread
      across the subset list.  Control is shared by the server-side
      determining the list and the client determining load distribution.
      Again, the client can use alternative RLOCs if the server-provided
      list of RLOCs are unreachable.

   o  Either side (more likely on the server-side ETR) decides not to
      send a Map-Request.  For example, if the server-side ETR does not
      send Map-Requests, it gleans RLOCs from the client-side ITR,
      giving the client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR RLOC is done by caching the inner header source
      EID and the outer header source RLOC of received packets.  The
      client-side ITR controls how traffic is returned and can alternate
      using an outer header source RLOC, which then can be added to the
      list the server-side ETR uses to return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR must assume each client-side ITR RLOC uses the same best
      Priority with a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed in data packets, the EID-to-RLOC cache
      on tunnel routers can grow to be very large.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the Routing Locator Reachability Algorithms described in the
   next section.

6.3.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the LISP header of an
       encapsulated data packet received from an ITR.  If the ETR is
       also acting as an ITR and has traffic to return to the original
       ITR site, it can use this status information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  An ITR which participates in the global routing system can
       determine that an RLOC is down if no BGP RIB route exists that
       matches the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts to use
       interworking [INTERWORK] and LISP-encapsulated data is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR, the
       source RLOC from the outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at the site.  CE-based ITRs at the source
   site can determine reachability relative to each other using the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP.

   o  If an ITR fails or if the upstream link to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack of a default route
   originated by the others to determine the Locator Status Bits it sets
   for them.

   RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit.  For example, if an RLOC
   listed in the 3rd position of the Map-Reply goes down (ordinal value
   2), then all ITRs at the site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to an RLOC that is indicated as
   down.  It will only resume using that RLOC if the corresponding Loc-
   Status-Bit returns to a value of 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the Loc-Status-Bit that corresponds to that locator's
   position in the list returned by the last Map-Reply will be set to
   zero for that particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can
   still be used to determine the reachability of Locators provided they
   are injected into the IGP.  This is typically done when a /32 address
   is configured on a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as a
   method to determine unreachability, they will refrain from using
   Locators which are described in Locator lists of Map-Replies.
   However, using this approach is unreliable because many network
   operators turn off generation of ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or Host Unreachable message,
   it MAY originate its own ICMP Unreachable message destined for the
   host that originated the data packet the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if
   a locator address from a locator-set in a mapping entry matches a
   prefix.  If it does not find one and BGP is running in the Default
   Free Zone (DFZ), it can decide to not use the locator even though the
   Loc-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can send a Map-Request to a Locator and if a Map-
   Reply is returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages originated by tunnel routers for active flows, so Locators
   are assumed to be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the receipt of ICMP Host Unreachable messages.  When an
   Locator has been determined to be unreachable, it is not used for
   active traffic; this is the same as if it were listed in a Map-Reply
   with priority 255.

   The ITR can test the reachability of the unreachable Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the risk of packet loss for end-to-end
   sessions.

   When an ETR decapsulates a packet, it knows that it is reachable from
   the encapsulating ITR because that is how the packet arrived.  In
   most cases, the ETR can also reach the ITR but cannot assume this to
   be true due to the possibility of path asymmetry.  In the presence of
   unidirectional traffic flow from an ITR to an ETR, the ITR should not
   use the lack of return traffic as an indication that the ETR is
   unreachable.  Instead, it must use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there is bidirectional data flow flows bidirectionally between a pair of locators, locators from different
   sites, a simple mechanism called "nonce echoing" can be used to
   determine reachability between an ITR and ETR.  When an ITR wants to
   solicit a nonce echo, it sets the N and E bits and places a 24-bit
   nonce in the LISP header of the next encapsulated data packet.

   When this packet is received by the ETR, the encapsulated packet is
   forwarded as normal.  When the ETR next sends a data packet to the
   ITR, it includes the nonce received earlier with the N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path to
   and from the ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is unreachable is variable
   and a choice left for the implementation.

   If the ITR is receiving packets from the ETR but does not see the
   nonce echoed while being in echo-nonce-request state, then the path
   to the ETR is unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the ETR is down it can switch to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices must
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the same
   time.  The number of packets sent or the time during which echo nonce
   requests are sent is an implementation specific setting.  However,
   when an ITR is in echo-nonce-request state, it can echo the ETR's
   nonce in the next set of packets that it encapsulates and then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve the forward path
   reachability problem as traffic may be unidirectional.  That is, the
   ETR receiving traffic at a site may not may not be the same device as an ITR
   which transmits traffic from that site or the site to site traffic is
   unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the nonce does not occur and the requesting side may
   regard the locator unreachable erroneously.  An ITR should only set
   the E-bit in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the Map-
   Reply message.

   Note that other locator reachability mechanisms are being researched
   and can be used to compliment or even override the Echo Nonce
   Algorithm.  See next section for an example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR can use to determine the
   reachability status of one or more locators that it has cached in a
   map-cache entry.  The P-bit (Probe Bit) of the Map-Request and Map-
   Reply messages are used for RLOC Probing.

   RLOC probing is done in the control-plane on a timer basis where an
   ITR or PTR will originate a Map-Request destined to a locator address
   from one of its own locator addresses.  A Map-Request used as an
   RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the Map-Request is the EID-prefix of the map-cache entry
   cached by the ITR or PTR.  The ITR or PTR may include a mapping data
   record for its own database mapping information.

   When an ETR receives a Map-Request message with the P-bit set, it
   returns a Map-Reply with the P-bit set.  The source address of the
   Map-Reply is set from the destination address of the Map-Request and
   the destination address of the Map-Reply is set from the source
   address of the Map-Request.  The Map-Reply should contain mapping
   data for the EID-prefix contained in the Map-Request.  This provides
   the opportunity for the ITR or PTR, which sent the RLOC-probe to get
   mapping updates if there were changes to the ETR's database mapping
   entries.

   There are advantages and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing is that it can handle many failure scenarios
   allowing the ITR to determine when the path to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator from the cached
   locator.  RLOC Probing can also provide RTT estimates between a pair
   of locators which can be useful for network management purposes as
   well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in the number of control messages required and the
   amount of bandwidth used to obtain those benefits, especially if the
   requirement for failure detection times are very small.

   Continued research and testing will attempt to characterize the
   tradeoffs of failure detection times versus message overhead.

6.4.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
   a requesting ITR, the locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best priority locator exists, the ITR can decide how to load
   share traffic against the corresponding locators.

   The following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash can be used or the
       traditional 5-tuple hash which includes the source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only from the header are used to
       compute the hash.

   2.  Take the hash value and divide it by the number of locators
       stored in the locator-set for the EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the remainder to select the locator in the
       locator-set.

   Note that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs to be set.  Selecting a random value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links of
   such LAGs.  Otherwise, core routers would see a single flow, since
   packets have a source address of the ITR, for packets which are
   originated by different EIDs at the source site.  A suggested setting
   for the source port number computed by an ITR is a 5-tuple hash
   function on the inner header, as described above.

   Many core router implementations use a 5-tuple hash to decide how to
   balance packet load across members of a LAG.  The 5-tuple hash
   includes the source and destination addresses of the packet and the
   source and destination ports when the protocol number in the packet
   is TCP or UDP.  For this reason, UDP encoding is used for LISP
   encapsulation.

6.5.  Changing the Contents of EID-to-RLOC Mappings

   Since the LISP architecture uses a caching scheme to retrieve and
   store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, the ITRs do not
   know when the mappings change and the ETRs do not keep track of who
   requested its mappings.  For scalability reasons, we want to maintain
   this approach but need to provide a way for ETRs change their
   mappings and inform the sites that are currently communicating with
   the ETR site using such mappings.

   When a locator record is added to the end of a locator-set, it is
   easy to update mappings.  We assume new mappings will maintain the
   same locator ordering as the old mapping but just have new locators
   appended to the end of the list.  So some ITRs can have a new mapping
   while other ITRs have only an old mapping that is used until they
   time out.  When an ITR has only an old mapping but detects bits set
   in the loc-status-bits that correspond to locators beyond the list it
   has cached, it simply ignores them.  However, this can only happen
   for locator addresses that are lexicographically greater than the
   locator addresses in the existing locator-set.

   When a locator record is removed from a locator-set, ITRs that have
   the mapping cached will not use the removed locator because the xTRs
   will set the loc-status-bit to 0.  So even if the locator is in the
   list, it will not be used.  For new mapping requests, the xTRs can
   set the locator AFI to 0 (indicating an unspecified address), as well
   as setting the corresponding loc-status-bit to 0.  This forces ITRs
   with old or new mappings to avoid using the removed locator.

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the locator-set and new
   records appended to the locator-set.  At some point, it would be
   useful to compact the locator-set so the loc-status-bit settings can
   be efficiently packed.

   We propose here two three approaches for locator-set compaction, one
   operational and the other a two protocol mechanism. mechanisms.  The operational approach
   uses a clock sweep method.  The protocol approach uses approaches use the concept
   of Solicit-Map-Requests. Solicit-Map-Requests and Map-Versioning.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning in advance and the use of
   count-down TTLs to time out mappings that have already been cached.
   The default setting for an EID-to-RLOC mapping TTL is 24 hours.  So
   there is a 24 hour window to time out old mappings.  The following
   clock sweep procedure is used:

   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the ETRs at a site to start the clock
       sweep window.

   2.  During the clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have timed out,
       and any active cache entries will time out within 1 hour.  During
       this 1 hour window the ETRs continue to send Map-Reply messages
       with the current (unchanged) mapping records with the TTL set to
       1 minute.

   4.  At the end of the 1 hour window, the ETRs will send Map-Reply
       messages with the new (changed) mapping records.  So any active
       caches can get the new mapping contents right away if not cached,
       or in 1 minute if they had the mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for xTRs, at the site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to tell remote ITRs to update
   the mappings they have cached.

   Since the xTRs don't keep track of remote ITRs that have cached their
   mappings, they can not tell exactly who needs the new mapping
   entries.  So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to, and only from those sites.
   The xTRs can locally decide the algorithm for how often and to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in a Map-Request message.  An ITR
   or PTR will send a Map-Request when they receive an SMR message.
   Both the SMR sender and the Map-Request responder must rate-limited
   these messages.

   The following procedure shows how a SMR exchange occurs when a site
   is doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the database mappings in an ETR change, the ETRs at the site
       begin to send Map-Requests with the SMR bit set for each locator
       in each map-cache entry the ETR caches.

   2.  A remote xTR which receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message.  A newly allocated random nonce is selected and the EID-
       prefix uses is the one copied from the SMR message.

   3.  The remote xTR retransmits the Map-Request slowly until it gets a
       Map-Reply while continuing to use the cached mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message provided the Map-Request
       nonce matches the nonce from the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the site with the changed mapping, records the fact
       that the site that sent the Map-Request has received the new
       mapping data in the mapping cache entry for the remote site so
       the loc-status-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending SMR
       messages.

   For security reasons an ITR MUST NOT process unsolicited Map-Replies.
   The nonce MUST be carried from SMR packet, into the resultant Map-
   Request, and then into Map-Reply to reduce spoofing attacks.

   To avoid map-cache entry corruption by a third-party, a sender of an
   SMR-based Map-Request must be verified.  If an ITR receives reduce spoofing attacks.

   To avoid map-cache entry corruption by a third-party, a sender of an
   SMR-based Map-Request must be verified.  If an ITR receives an SMR-
   based Map-Request and the source is not in the locator-set for the
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to the mapping database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it will deliver the Map-Request to the authoritative source of the
   mapping data.

6.5.3.  Database Map Versioning

   When there is unidirectional packet flow between an ITR and ETR, and
   the EID-to-RLOC mappings change on the ETR, it needs to inform the
   ITR so encapsulation can stop to a removed locator and start to a new
   locator in the locator-set.

   An ETR, when it sends Map-Reply messages, conveys its own Map-Version
   number.  This is known as the Destination Map-Version Number.  ITRs
   include the Destination Map-Version Number in packets they
   encapsulate to the site.  When an ETR decapsulates a packet and
   detects the Destination Map-Version Number is less than the current
   version for its mapping, the SMR procedure described in Section 6.5.2
   occurs.

   An ITR, when it encapsulates packets to ETRs, can convey its own Map-
   Version number.  This is known as the Source Map-Version Number.

   When an SMR-
   based Map-Request ETR decapsulates a packet and detects the source Source Map-Version
   Number is not in greater than the locator-set for last Map-Version Number sent in a Map-
   Reply from the
   stored map-cache entry, then ITR's site, the responding ETR will send a Map-Request MUST be sent
   with an EID destination to one of
   the mapping database system.  Since ETRs for the
   mapping database system source site.

   A Map-Version Number is more secure used as a sequence number per EID-prefix.  So
   values that are greater, are considered to reach be more recent.  A value
   of 0 for the Source Map-Version Number or the Destination Map-Version
   Number conveys no versioning information and an authoritative ETR,
   it will deliver xTR does no
   comparison with previosly received Map-Version Numbers.

   A Map-Version Number can be included in Map-Register messages as
   well.  This is a good way for the Map-Request Map-Server can assure that all ETRs
   for a site registering to the authoritative source it will be Map-Version number synchronized.

   See [VERSIONING] for a more details analysis and description of the
   mapping data.
   Database Map Versioning.

7.  Router Performance Considerations

   LISP is designed to be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] and stripping instead of re-
   writing addresses, existing hardware can support the forwarding model
   with little or no modification.  Where modifications are required,
   they should be limited to re-programming existing hardware rather
   than requiring expensive design changes to hard-coded algorithms in
   silicon.

   A few implementation techniques can be used to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special FIB entries
      for the EID-prefixes of EIDs served by the ETR (those for which
      the router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be performed.  The forwarding logic of testing for particular IP
      protocol number value is not necessary.  No changes to existing,
      deployed hardware should be needed to support this.

   o  On an ITR, prepending a new IP header is as simple as adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this action.

   o  When a received packet's outer destination address contains an EID
      which is not intended to be forwarded on the routable topology
      (i.e.  LISP 1.5), the source address of a data packet or the
      router interface with which the source is associated (the
      interface from which it was received) can be associated with a VRF
      (Virtual Routing/Forwarding), in which a different (i.e. non-
      congruent) topology can be used to find EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and will discuss the pros and cons of each deployment scenario.
   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or re-encapsulating
   tunneling.

   When deciding on centralized versus distributed caching, the
   following issues should be considered:

   o  Are the tunnel routers spread out so that the caches are spread
      across all the memories of each router?

   o  Should management "touch points" be minimized by choosing few
      tunnel routers, just enough for redundancy?

   o  In general, using more ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, the
   following issues should be considered:

   o  Flat tunneling implements a single tunnel between source site and
      destination site.  This generally offers better paths between
      sources and destinations with a single tunnel path.

   o  Recursive tunneling is when tunneled traffic is again further
      encapsulated in another tunnel, either to implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the
      site has some control since the site is prepending a new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is prepending a new tunnel header, but if the site's
      ISP is doing the TE, then the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at the
      benefit of steering traffic to resource available parts of the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated with
      a new tunnel header using a new RLOC.

   The next sub-sections will describe where tunnel routers can reside
   in the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to hosts, the EID-prefix set is at
   the granularity of an IP subnet.  So at the expense of more EID-
   prefix-to-RLOC sets for the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on the number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Map-Replies are traveling between more routers.

   The advantage of placing the caches and databases at these stub
   routers is that the products deployed in this part of the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in these devices and fewer routes
   are stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and routing state.

   LISP functionality can also be deployed in edge switches.  These
   devices generally have layer-2 ports facing hosts and layer-3 ports
   facing the Internet.  Spare capacity is also often available in these
   devices as well.

8.2.  Border/Edge Tunnel Routers

   Using customer-edge (CE) routers for tunnel endpoints allows the EID
   space associated with a site to be reachable via a small set of RLOCs
   assigned to the CE routers for that site.

   This offers the opposite benefit of the first-hop/last-hop tunnel
   router scenario: the number of mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage is that less of the network's resources are used to
   reach host endpoints thereby centralizing the point-of-failure domain
   and creating network choke points at the CE router.

   Note that more than one CE router at a site can be configured with
   the same IP address.  In this case an RLOC is an anycast address.
   This allows resilience between the CE routers.  That is, if a CE
   router fails, traffic is automatically routed to the other routers
   using the same anycast address.  However, this comes with the
   disadvantage where the site cannot control the entrance point when
   the anycast route is advertised out from all border routers.

8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers gives an ISP control
   over the location of the egress tunnel endpoints.  That is, the ISP
   can decide if the tunnel endpoints are in the destination site (in
   either CE routers or last-hop routers within a site) or at other PE
   edges.  The advantage of this case is that two or more tunnel headers
   can be avoided.  By having the PE be the first router on the path to
   encapsulate, it can choose a TE path first, and the ETR can
   decapsulate and re-encapsulate for a tunnel to the destination end
   site.

   An obvious disadvantage is that the end site has no control over
   where its packets flow or the RLOCs used.

   As mentioned in earlier sections a combination of these scenarios combination of these scenarios is
   possible at the expense of extra packet header overhead, if both site
   and provider want control, then recursive or re-encapsulating tunnels
   are used.

8.4.  LISP Functionality with Conventional NATs

   LISP routers can be deployed behind Network Address Translator (NAT)
   devices to provide the same set of packet services hosts have today
   when they are addressed out of private address space.

   It is important to note that a locator addresss in any LISP control
   message MUST be a globally routable address and therefore should not
   contain [RFC1918] addresses.  If a LISP router is
   possible at configured with
   private addresses, they must be used only in the expense of extra packet outer IP header overhead, if both site so
   the NAT device can translate properly.  Otherwise, EID addresses must
   be translated before encapsulation is performed.  Both NAT
   translation and provider want control, then recursive or re-encapsulating tunnels
   are used. LISP encapsulation functions could be co-located in
   the same device.

   More details on LISP address translation can be found in [INTERWORK].

9.  Traceroute Considerations

   When a source host in a LISP site initiates a traceroute to a
   destination host in another LISP site, it is highly desirable for it
   to see the entire path.  Since packets are encapsulated from ITR to
   ETR, the hop across the tunnel could be viewed as a single hop.
   However, LISP traceroute will provide the entire path so the user can
   see 3 distinct segments of the path from a source LISP host to a
   destination LISP host:

      Segment 1 (in source LISP site based on EIDs):

          source-host ---> first-hop ... next-hop ---> ITR

      Segment 2 (in the core network based on RLOCs):

          ITR ---> next-hop ... next-hop ---> ETR

      Segment 3 (in the destination LISP site based on EIDs):

          ETR ---> next-hop ... last-hop ---> destination-host

   For segment 1 of the path, ICMP Time Exceeded messages are returned
   in the normal matter as they are today.  The ITR performs a TTL
   decrement and test for 0 before encapsulating.  So the ITR hop is
   seen by the traceroute source has an EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are returned
   to the ITR because the TTL decrement to 0 is done on the outer
   header, so the destination of the ICMP messages are to the ITR RLOC
   address, the source source RLOC address of the encapsulated traceroute
   packet.  The ITR looks inside of the ICMP payload to inspect the
   traceroute source so it can return the ICMP message to the address of
   the traceroute client as well as retaining the core router IP address
   in the ICMP message.  This is so the traceroute client can display
   the core router address (the RLOC address) in the traceroute output.
   The ETR returns its RLOC address and responds to the TTL decrement to
   0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will be
   decrementing the TTL for the packet that was encapsulated, sent into
   the core, decapsulated by the ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the destination of the traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the traceroute client.  The ICMP message will be
   encapsulated by the local ITR and sent back to the ETR in the
   originated traceroute source site, where the packet will be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs to pay special
   attention for forwarding ICMP messages back to the traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the above procedure since IPv4
   ICMP Time Exceeded messages only include the invoking IP header and 8
   bytes that follow the IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP
   payload is the encapsulated header it prepended followed by a UDP
   header.  The original invoking IP header, and therefore the identity
   of the traceroute source is lost.

   The solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the ETR.  The
   ITR will use a circular buffer for caching the IPv4 and UDP headers
   of traceroute packets.  It will select a 16-bit number as a key to
   find them later when the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as the UDP source port in the encapsulating header.
   When the ICMP Time Exceeded message is returned to the ITR, the UDP
   header of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload
   and sends the ICMP Time Exceeded message to the traceroute source
   retaining the source address of the original ICMP Time Exceeded
   message (a core router or the ETR of the site of the traceroute
   destination).

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is originated and
   the ITR encapsulates it in the other address family header, you
   cannot get all 3 segments of the traceroute.  Segment 2 of the
   traceroute can not be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the tunnel look like one hop.  All the ITR has to
   do to make this work is to not copy the inner TTL to the outer,
   encapsulating header's TTL when a traceroute packet is encapsulated
   using an RLOC from a different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the ITR and ETR.

10.  Mobility Considerations

   There are several kinds of mobility of which only some might be of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in EID-RLOC mappings for sites are expected to be
   handled by configuration, outside of the LISP protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering is involved.  LISP can
   help with the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a site from the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves relatively
   rapidly, changing its IP layer network attachment point.  Maintenance
   of session continuity is a goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to be explored.

   The problem is that as an endpoint moves, it may require changes to
   the mapping between its EID and a set of RLOCs for its new network
   location.  When this is added to the overhead of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint is away from home, packets to it
   are encapsulated and forwarded via a home agent which resides in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the endpoint or to
   a foreign agent which resides where the endpoint has moved to.
   Packets from the endpoint may be sent directly to the correspondent
   node, may be sent via the foreign agent, or may be reverse-tunneled
   back to the home agent for delivery to the mobile node.  As the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between the mobile node and
   the home agent, whether via foreign agent or not.  As a mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an old location to a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one of the new visited network's ITRs, which needs a EID-RLOC
      mapping for the home agent.

   o  The home agent might not have the EID-RLOC mappings for the mobile
      node's "care-of" address or its foreign agent in the new visited
      network, in which case it will need to acquire them.

   o  When packets are sent directly to the correspondent node, it may
      be that no traffic has been sent from the new visited network to
      the correspondent node's network, and the new visited network's
      ITR will need to obtain an EID-RLOC mapping for the correspondent
      node's site.

   In addition, if the IPv4 endpoint is sending packets from the new
   visited network using its original EID, then LISP will need to
   perform a route-returnability check on the new EID-RLOC mapping for
   that EID.

   In IPv6 mobility, packets can flow directly between the mobile node
   and the correspondent node in either direction.  The mobile node uses
   its "care-of" address (EID).  In this case, the route-returnability
   check would not be needed but one more LISP mapping lookup may be
   required instead:

   o  As above, three mapping changes may be needed for the mobile node
      to communicate with its home agent and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order for the correspondent node to send packets to
      the mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the number of potential mapping
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the mobile node, correspondent node, and home agent, but also state
   changes in the ITRs and ETRs for at least some EID-prefixes.

   The goal is to support rapid adaptation, with little delay or packet
   loss for the entire system.  Heuristics can be added to LISP to
   reduce the number of mapping changes required and to reduce the delay
   per mapping change.  Also IP mobility can be modified to require
   fewer mapping changes.  In order to increase overall system
   performance, there may be a need to reduce the optimization of one
   area in order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It can do this after
   performing a route-returnability check, to ensure that the new
   network location does have a internal route to that endpoint.
   However, this does not cover the case where an ITR (the node assigned
   the RLOC) at the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment in which all
   routing information is disseminated before packets can be forwarded.
   In order to allow the Internet to grow to support expected future
   use, we are moving to an environment where some information may have
   to be obtained after packets are in flight.  Modifications to IP
   mobility should be considered in order to optimize the behavior of
   the overall system.  Anything which decreases the number of new EID-
   RLOC mappings needed when a node moves, or maintains the validity of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network" can be as small as a single router and as large as
   a whole site.  This is different from site mobility in that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any endpoint will return a binding for the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   to revisit the design of the mapping service and allow for dynamic
   updates of the database.

   The issue of interactions between mobility and LISP needs to be
   explored further.  Specific improvements to the entire system will
   depend on the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   A mobile device can use the LISP infrastructure to achieve mobility
   by implementing the LISP encapsulation and decapsulation functions
   and acting as a simple ITR/ETR.  By doing this, such a "LISP mobile
   node" can use topologically-independent EID IP addresses that are not
   advertised into and do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
   only the correspondents of the LISP mobile node.

   Refer to the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined in the original Internet
   architecture is an identifier of a grouping of topologically
   independent receiver host locations.  The address encoding itself
   does not determine the location of the receiver(s).  The multicast
   routing protocol, and the network-based state the protocol creates,
   determines where the receivers are located.

   In the context of LISP, a multicast group address is both an EID and
   a Routing Locator.  Therefore, no specific semantic or action needs
   to be taken for a destination address, as it would appear in an IP
   header.  Therefore, a group address that appears in an inner IP
   header built by a source host will be used as the destination EID.
   The outer IP header (the destination Routing Locator address),
   prepended by a LISP router, will use the same group address as the
   destination Routing Locator.

   Having said that, only the source EID and source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address in the source Routing Locator field when prepending
   the outer IP header.  This source Routing Locator address, like any
   other Routing Locator address MUST be globally routable.

   Therefore, an EID-to-RLOC mapping does not need to be performed by an
   ITR when a received data packet is a multicast data packet or when
   processing a source-specific Join (either by IGMPv3 or PIM).  But the
   source Routing Locator is decided by the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach is to have the ITR not encapsulate a multicast
   packet and allow the the host built packet to flow into the core even
   if the source address is allocated out of the EID namespace.  If the
   RPF-Vector TLV [RPFV] [RFC5496] is used by PIM in the core, then core
   routers can RPF to the ITR (the Locator address which is injected
   into core routing) rather than the host source address (the EID
   address which is not injected into core routing).

   To avoid any EID-based multicast state in the network core, the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and Interworking with non-LISP sites is described in specification
   [MLISP].

12.  Security Considerations

   It is believed that most of the security mechanisms will be part of
   the mapping database service when using control plane procedures for
   obtaining EID-to-RLOC mappings.  For data plane triggered mappings,
   as described in this specification, protection is provided against
   ETR spoofing by using Return- Routability mechanisms evidenced by the
   use of a 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  The nonce, coupled
   with the ITR accepting only solicited Map-Replies goes a long way
   toward providing decent authentication.

   LISP does not rely on a PKI infrastructure or a more heavy weight
   authentication system.  These systems challenge the scalability of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies to the control plane as well as rate-
   limiting the number of data-triggered Map-Replies.

   To deal with map-cache exhaustion attempts in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list for special or frequently accessed
   sites.  This should be a configuration policy control set by the
   network administrator who manages ITRs and PTRs.

13.  IANA Considerations

   Refer to LISP Canonical Address Format specification [LCAF] for IANA
   considerations.

14.  Prototype Plans and Status

   The operator community has requested that the IETF take a practical
   approach to solving the scaling problems associated with global
   routing state growth.  This document offers a simple solution which
   is intended for use in a pilot program to gain experience in working
   on this problem.

   The authors hope that publishing this specification will allow the
   rapid implementation of multiple vendor prototypes and deployment on
   a small scale.  Doing this will help the community:

   o  Decide whether a new EID-to-RLOC mapping database infrastructure
      is needed or if a simple, UDP-based, data-triggered approach is
      flexible and robust enough.

   o  Experiment with provider-independent assignment of EIDs while at
      the same time decreasing the size of DFZ routing tables through
      the use of topologically-aligned, provider-based RLOCs.

   o  Determine whether multiple levels of tunneling can be used by ISPs
      to achieve their Traffic Engineering goals while simultaneously
      removing the more specific routes currently injected into the
      global routing system for this purpose.

   o  Experiment with mobility to determine if both acceptable
      convergence and session continuity properties can be scalably
      implemented to support both individual device roaming and site
      service provider changes.

   Here is a rough set of milestones:

   1.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   2.  Continue pilot deployment using LISP-ALT as the database mapping
       mechanism.

   3.  Continue prototyping and studying other database lookup schemes,
       be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms.

   4.  Implement the LISP Multicast draft [MLISP].

   5.  Implement the LISP Mobile Node draft [LISP-MN].

   6.  Research more on how policy affects what gets returned in a Map-
       Reply from an ETR.

   7.  Continue to experiment with mixed locator-sets to understand how
       LISP can help the IPv4 to IPv6 transition.

   8.  Add more robustness to locator reachability between LISP sites.

   9.  Continue the deployment of Proxy-ETRs (PETRs) for uses like uRPF
       avoidance, IPv6 connectivity, and LISP-MN.

   As of this writing the following accomplishments have been achieved:

   1.   A unit- and system-tested software switching implementation has
        been completed on cisco NX-OS for this draft for both IPv4 and
        IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators.

   2.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [ALT].

   3.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [INTERWORK].  Support
        for IPv4 translation is provided and PTR support for IPv4 and
        IPv6 is provided.

   4.   The cisco NX-OS implementation supports an experimental
        mechanism for slow mobility.

   5.   There are 5 LISP implementations that exist and the first 4
        below have gone through interoperability testing at IETF
        Hiroshima, based on the draft-ietf-lisp-05.txt spec:

        1.  cisco NX-OS

        2.  OpenLISP

        3.  LISP-Click

        4.  ZLisp

        5.  cisco IOS

   6.   Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and Gregg Schudel, Andrew
        Partan and the rest of the lisp-beta team continue to test all
        the features described above on a dual-stack infrastructure.

   7.   Darrel Lewis and Dave Meyer have deployed both LISP translation
        and LISP PTR support in the pilot network.  Point your browser
        to http://www.lisp4.net to see translation happening in action
        so your non-LISP site can access a web server in a LISP site.

   8.   Soon http://www.lisp6.net will work where your IPv6 LISP site
        can talk to a IPv6 web server in a LISP site by using mixed
        address-family based locators.

   9.   An public domain implementation of LISP is underway. available.  See
        [OPENLISP] for details.

   10.  We have deployed Map-Resolvers and Map-Servers on the LISP pilot
        network to gather experience with [LISP-MS].  The first layer of
        the architecture are the xTRs which use Map-Servers for EID-
        prefix registration and Map-Resolvers for EID-to-RLOC mapping
        resolution.  The second layer are the Map-Resolvers and Map-
        Servers which connect to the ALT BGP peering infrastructure.
        And the third layer are ALT-routers which aggregate EID-prefixes
        and forward Map-Requests.

   11.  A cisco IOS implementation is underway available which currently supports
        IPv4 and IPv6 encapsulation and decapsulation features.

   12.  A LISP router based LIG implementation is supported, deployed,
        and used daily to debug and test the LISP pilot network.  See
        [LIG] for details.

   13.  A Linux implementation of LIG has been made available and
        supported by Dave Meyer.  It can be run on any Linux system
        which resides in either a LISP site or non-LISP site.  See [LIG]
        for details.  Public domain code can be downloaded from
        http://github.com/davidmeyer/lig/tree/master.

   14.  An experimental implementation has been written for three
        locator reachability algorithms.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented in this
        specification.  The third is called TCP-counts which will be
        documented in future drafts.

   15.  The LISP pilot network has been converted from using MD5 HMAC
        authentication for Map-Register messages to SHA-1 HMAC
        authentication.  ETRs send with SHA-1 but Map-Servers can
        received from either for compatibility purposes.

   16.  The LISP pilot network is in its 3rd generation.  Current
        experiments are being performed to test EID-prefix aggregation
        at multiple service boundaries as well as deploying models for
        the existence of multiple Mapping Service Providers (MSPs).

   If interested in writing a LISP implementation, testing any of the
   LISP implementations, or want to be part of the LISP pilot program,
   please contact lisp@ietf.org.

14.

15.  References

14.1.

15.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1498]  Saltzer, J., "On the Naming and Binding of Network
              Destinations", RFC 1498, August 1993.

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

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

   [RFC1955]  Hinden, R., "New Scheme for Internet Routing and
              Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 2006.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

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

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009.

   [UDP-TUNNELS]
              Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
              Packets"", draft-eubanks-chimento-6man-00.txt (work in
              progress), February 2009.

14.2.

15.2.  Informative References

   [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-02.txt
              draft-ietf-lisp-alt-04.txt (work in progress),
              January April 2010.

   [APT]      Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01.txt (work in progress), November 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network  Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [DHTs]     Ratnasamy, S., Shenker, S., and I. Stoica, "Routing
              Algorithms for DHTs: Some Open Questions", PDF
              file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.

   [EMACS]    Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              draft-curran-lisp-emacs-00.txt (work in progress),
              November 2007.

   [GSE]      "GSE - An Alternate Addressing Architecture for  IPv6",
              draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-01.txt (work in progress),
              January
              March 2010.

   [LCAF]     Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format", draft-farinacci-lisp-lcaf-00.txt (work in
              progress), April 2010.

   [LIG]      Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-01.txt
              draft-ietf-lisp-lig-00.txt (work in progress),
              May 2009. April 2010.

   [LISA96]   Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
              "Renumbering: Threat or Menace?", Usenix , September 1996.

   [LISP-MAIN]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress),
              March 2009.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), July 2009.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-03.txt
              draft-ietf-lisp-ms-05.txt (work in progress),
              September 2009. April 2010.

   [LISP1]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP1) [Routable  ID
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
              October 2006.

   [LISP2]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP2) [DNS-based
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
              November 2006.

   [LISPDHT]  Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT:
              Towards a DHT to map identifiers onto locators",
              draft-mathy-lisp-dht-00.txt (work in progress),
              February 2008.

   [LOC-ID-ARCH]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID  Separation",
              draft-meyer-loc-id-implications-01.txt (work in progress),
              Januaryr 2009.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-ietf-lisp-multicast-02.txt
              draft-ietf-lisp-multicast-03.txt (work in progress),
              September 2009.
              April 2010.

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

   [OPENLISP]
              Iannone, L. and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-08.txt (work in progress),
              January 2009.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.txt (work in
              progress), July 2007.

   [SHIM6]    Nordmark, E.

   [VERSIONING]
              Iannone, L., Saucez, D., and M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt O. Bonaventure, "LISP Mapping
              Versioning", draft-iannone-lisp-mapping-versioning-01.txt
              (work in progress), October 2006. March 2010.

Appendix A.  Acknowledgments

   An initial thank you goes to Dave Oran for planting the seeds for the
   initial ideas for LISP.  His consultation continues to provide value
   to the LISP authors.

   A special and appreciative thank you goes to Noel Chiappa for
   providing architectural impetus over the past decades on separation
   of location and identity, as well as detailed review of the LISP
   architecture and documents, coupled with enthusiasm for making LISP a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
   Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
   Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
   Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
   Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko,
   Gregg Schudel, Srinivas Subramanian, Amit Jain, and Xu Xiaohu. Xiaohu, and
   Dhirendra Trivedi.

   In particular, we would like to thank Dave Meyer for his clever
   suggestion for the name "LISP". ;-)

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-07.txt

   o  Posted April 2010.

   o  Added I-bit to data header so LSB field can also be used as an
      Instance ID field.  When this occurs, the LSB field is reduced to
      8-bits (from 32-bits).

   o  Added V-bit to the data header so the 24-bit nonce field can also
      be used for source and destination version numbers.

   o  Added Map-Version 12-bit value to the EID-record to be used in all
      of Map-Request, Map-Reply, and Map-Register messages.

   o  Added multiple ITR-RLOC fields to the Map-Request packet so an ETR
      can decide what address to select for the destination of a Map-
      Reply.

   o  Added L-bit (Local RLOC bit) and P-bit (Probe-Reply RLOC bit) to
      the Locator-Set record of an EID-record for a Map-Reply message.
      The L-bit indicates which RLOCs in the locator-set are local to
      the sender of the message.  The P-bit indicates which RLOC is the
      source of a RLOC-probe Reply (Map-Reply) message.

   o  Add reference to the LISP Canonical Address Format [LCAF] draft.

   o  Made editorial and clarification changes based on comments from
      Dhirendra Trivedi.

   o  Added wordsmithing comments from Joel Halpern on DF=1 setting.

   o  Add John Zwiebel clarification to Echo Nonce Algorithm section
      6.3.1.

   o  Add John Zwiebel comment about expanding on proxy-bit for Map-
      Register messages.

   o  Add NAT section per Ron Bonica comments.

   o  Fix IDnits issues per Ron Bonica.

   o  Added section on Virtualization and Segmentation to explain the
      use if the Instance ID field in the data header.

B.2.  Changes to draft-ietf-lisp-06.txt

   Editorial based changes:

   o  Posted December 2009.

   o  Fix typo for rflags flags in LISP data header.  Changed from "4" to "5".

   o  Add text to indicate that Map-Register messages must contain a
      computed UDP checksum.

   o  Add definitions for PITR and PETR.

   o  Indicate an AFI value of 0 is an unspecified address.

   o  Indicate that the TTL field of a Map-Register is not used and set
      to 0 by the sender.  This change makes this spec consistent with
      [LISP-MS].

   o  Change "... yield a packet size of L bytes" to "... yield a packet
      size greater than L bytes".

   o  Clarify section 6.1.5 on what addresses and ports are used in Map-
      Reply messages.

   o  Clarify that LSBs that go beyond the number of locators do not to
      be SMRed when the locator addresses are greater lexicographically
      than the locator in the existing locator-set.

   o  Add Gregg, Srini, and Amit to acknowledgment section.

   o  Clarify in the definition of a LISP header what is following the
      UDP header.

   o  Clarify "verifying Map-Request" text in section 6.1.3.

   o  Add Xu Xiaohu to the acknowledgment section for introducing the
      problem of overlapping EID-prefixes among multiple sites in an RRG
      email message.

   Design based changes:

   o  Use stronger language to have the outer IPv4 header set DF=1 so we
      can avoid fragment reassembly in an ETR or PETR.  This will also
      make IPv4 and IPv6 encapsulation have consistent behavior.

   o  Map-Requests should not be sent in ECM with the Probe bit is set.
      These type of Map-Requests are used as RLOC-probes and are sent
      directly to locator addresses in the underlying network.

   o  Add text in section 6.1.5 about returning all EID-prefixes in a
      Map-Reply sent by an ETR when there are overlapping EID-prefixes
      configure.

   o  Add text in a new subsection of section 6.1.5 about dealing with
      Map-Replies with coarse EID-prefixes.

B.2.

B.3.  Changes to draft-ietf-lisp-05.txt

   o  Posted September 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in Map-Registers.  Put key-id, auth-length, and auth-
      data in Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.

   o  Make more clear what source-RLOC should be for a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

   o  Removed nonce from Map-Register message, it wasn't used so no need
      for it.

   o  Clarify what to do for unspecified Action bits for negative Map-
      Replies.  Since No Action is a drop, make value 0 Drop.

B.3.

B.4.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  How do deal with record count greater than 1 for a Map-Request.
      Damien and Joel comment.  Joel suggests: 1) Specify that senders
      compliant with the current document will always set the count to
      1, and note that the count is included for future extensibility.
      2) Specify what a receiver compliant with the draft should do if
      it receives a request with a count greater than 1.  Presumably, it
      should send some error back?

   o  Add Fred Templin in acknowledgment section.

   o  Add Margaret and Sam to the acknowledgment section for their great
      comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums on
      ETR.  From the mailing list: "You'd need to word it as an ITR MAY
      send a zero checksum, an ETR MUST accept a 0 checksum and MAY
      ignore the checksum completely.  And of course we'd need to
      confirm that can actually be implemented.  In particular, hardware
      that verifies UDP checksums on receive needs to be checked to make
      sure it permits 0 checksums."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      for MNs but often enough to get mapping updates.

   o  Indicate SHA1 can be used as well for Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about spec'ing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

   o  Margaret's comment on gleaning: "The current specification does
      not make it clear how long gleaned map entries should be retained
      in the cache, nor does it make it clear how/ when they will be
      validated.  The LISP spec should, at the very least, include a
      (short) default lifetime for gleaned entries, require that they be
      validated within a short period of time, and state that a new
      gleaned entry should never overwrite an entry that was obtained
      from the mapping system.  The security implications of storing
      "gleaned" entries should also be explored in detail."

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

   o  Change LISP header to allow a "Research Bit" so the Nonce and LSB
      fields can be turned off and used for another future purpose.  For
      Luigi et al versioning convergence.

   o  Add a N-bit to the data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

   o  Indicate when doing data-gleaning that a verifying Map-Request is
      sent to the source-EID of the gleaned data packet so we can avoid
      map-cache corruption by a 3rd party.  Comment from Pedro.

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro and Dino.

   o  Jesper made a comment to loosen the language about requiring the
      copy of inner TTL to outer TTL since the text to get mixed-AF
      traceroute to work would violate the "MUST" clause.  Changed from
      MUST to SHOULD in section 5.3.

B.4.

B.5.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from John Zwiebel in Echo-Nonce section.

B.5.

B.6.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.

B.6.

B.7.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.

   o  Added Proxy-Map-Reply bit to Map-Register.

B.7.

B.8.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com
--Apple-Mail-17-858143068 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-17-858143068 Content-Disposition: attachment; filename=draft-ietf-lisp-07.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-07.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: October 15, 2010 D. Lewis cisco Systems April 13, 2010 Locator/ID Separation Protocol (LISP) draft-ietf-lisp-07 Abstract This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 15, 2010. Copyright Notice Farinacci, et al. Expires October 15, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Copyright (c) 2010 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 BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 22 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 23 5.4.3. Using Virtualization and Segmentation with LISP . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 25 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 25 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 27 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 27 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 29 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 31 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 34 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 37 6.1.7. Encapsulated Control Message Format . . . . . . . . . 38 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 40 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 41 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 44 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 45 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 46 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 47 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 47 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 48 6.5.3. Database Map Versioning . . . . . . . . . . . . . . . 49 7. Router Performance Considerations . . . . . . . . . . . . . . 51 Farinacci, et al. Expires October 15, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 52 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 53 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 53 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 54 8.4. LISP Functionality with Conventional NATs . . . . . . . . 54 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 55 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 56 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 56 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 56 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 58 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 58 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 58 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 58 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 60 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 60 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 62 12. Security Considerations . . . . . . . . . . . . . . . . . . . 63 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 14. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 65 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 15.1. Normative References . . . . . . . . . . . . . . . . . . . 68 15.2. Informative References . . . . . . . . . . . . . . . . . . 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 73 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 74 B.1. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 74 B.2. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 75 B.3. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 76 B.4. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 76 B.5. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 78 B.6. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 78 B.7. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 79 B.8. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80 Farinacci, et al. Expires October 15, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires October 15, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 2. Introduction Many years of discussion about the current IP routing and addressing architecture have noted that its use of a single numbering space (the "IP address") for both host transport session identification and network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). A number of scaling benefits would be realized by separating the current IP address into separate spaces for Endpoint Identifiers (EIDs) and Routing Locators (RLOCs); among them are: 1. Reduction of routing table size in the "default-free zone" (DFZ). Use of a separate numbering space for RLOCs will allow them to be assigned topologically (in today's Internet, RLOCs would be assigned by providers at client network attachment points), greatly improving aggregation and reducing the number of globally-visible, routable prefixes. 2. More cost-effective multihoming for sites that connect to different service providers where they can control their own policies for packet flow into the site without using extra routing table resources of core routers. 3. Easing of renumbering burden when clients change providers. Because host EIDs are numbered from a separate, non-provider- assigned and non-topologically-bound space, they do not need to be renumbered when a client site changes its attachment points to the network. 4. Traffic engineering capabilities that can be performed by network elements and do not depend on injecting additional state into the routing system. This will fall out of the mechanism that is used to implement the EID/RLOC split (see Section 4). 5. Mobility without address changing. Existing mobility mechanisms will be able to work in a locator/ID separation scenario. It will be possible for a host (or a collection of hosts) to move to a different point in the network topology either retaining its home-based address or acquiring a new address based on the new network location. A new network location could be a physically different point in the network topology or the same physical point of the topology with a different provider. This draft describes protocol mechanisms to achieve the desired functional separation. For flexibility, the mechanism used for forwarding packets is decoupled from that used to determine EID to RLOC mappings. This document covers the former. For the latter, see [CONS], [ALT], [EMACS], [RPMD], and [NERD]. This work is in response to and intended to address the problem statement that came out of the Farinacci, et al. Expires October 15, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 RAWS effort [RFC4984]. The Routing and Addressing problem statement can be found in [RADIR]. This draft focuses on a router-based solution. Building the solution into the network will facilitate incremental deployment of the technology on the Internet. Note that while the detailed protocol specification and examples in this document assume IP version 4 (IPv4), there is nothing in the design that precludes use of the same techniques and mechanisms for IPv6. It should be possible for IPv4 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 RLOCs. Related work on host-based solutions is described in Shim6 [RFC5533] and HIP [RFC4423]. Related work on a router-based solution is described in [GSE]. This draft attempts to not compete or overlap with such solutions and the proposed protocol changes are expected to complement a host-based mechanism when Traffic Engineering functionality is desired. Some of the design goals of this proposal include: 1. Require no hardware or software changes to end-systems (hosts). 2. Minimize required changes to Internet infrastructure. 3. Be incrementally deployable. 4. Require no router hardware changes. 5. Minimize the number of routers which have to be modified. In particular, most customer site routers and no core routers require changes. 6. Minimize router software changes in those routers which are affected. 7. Avoid or minimize packet loss when EID-to-RLOC mappings need to be performed. There are 4 variants of LISP, which differ along a spectrum of strong to weak dependence on the topological nature and possible need for routability of EIDs. The variants are: Farinacci, et al. Expires October 15, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 LISP 1: uses EIDs that are routable through the RLOC topology for bootstrapping EID-to-RLOC mappings. [LISP1] This was intended as a prototyping mechanism for early protocol implementation. It is now deprecated and should not be deployed. LISP 1.5: uses EIDs that are routable for bootstrapping EID-to-RLOC mappings; such routing is via a separate topology. LISP 2: uses EIDS that are not routable and EID-to-RLOC mappings are implemented within the DNS. [LISP2] LISP 3: uses non-routable EIDs that are used as lookup keys for a new EID-to-RLOC mapping database. Use of Distributed Hash Tables [DHTs] [LISPDHT] to implement such a database would be an area to explore. Other examples of new mapping database services are [CONS], [ALT], [RPMD], [NERD], and [APT]. This document on LISP 1.5, and LISP 3 variants, both of which rely on a router-based distributed cache and database for EID-to-RLOC mappings. The LISP 1.0 mechanism works but does not allow reduction of routing information in the default-free-zone of the Internet. The LISP 2 mechanisms are put on hold and may never come to fruition since it is not architecturally pure to have routing depend on directory and directory depend on routing. The LISP 3 mechanisms will be documented elsewhere but may use the control-plane options specified in this specification. Farinacci, et al. Expires October 15, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 3. Definition of Terms Provider Independent (PI) Addresses: an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g. from a particular service provider), and is therefore not topologically aggregatable in the routing system. Provider Assigned (PA) Addresses: a block of IP addresses that are assigned to a site by each service provider to which a site connects. Typically, each block is sub-block of a service provider CIDR block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multi-homed site acquiring its own, globally-visible prefix. LISP uses only topologically-assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called a "LEID". Throughout this document, any references to "EID" refers to an LEID. Farinacci, et al. Expires October 15, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 EID-prefix: A power-of-2 block of EIDs which are allocated to a site by an address allocation authority. EID-prefixes are associated with a set of RLOC addresses which make up a "database mapping". EID-prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the smaller EID- prefix. A globally routed address block (whether PI or PA) is not an EID-prefix. However, a globally routed address block may be removed from global routing and reused as an EID-prefix. A site that receives an explicitly allocated EID-prefix may not use that EID-prefix as a globally routed prefix assigned to RLOCs. End-system: is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e. outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. Ingress Tunnel Router (ITR): a router which accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating hosts supplied EID). TE-ITR: is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. Egress Tunnel Router (ETR): a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the Farinacci, et al. Expires October 15, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. TE-ETR: is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. xTR: is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality is at the CE router. EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings, it is dynamic, local to the ITR(s), and relatively small while the database is distributed, relatively static, and much more global in scope. EID-to-RLOC Database: a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. Recursive Tunneling: when a packet has more than one LISP IP header. Additional layers of tunneling may be employed to implement traffic engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added and the original RLOCs are preserved in the "inner" header. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. Reencapsulating Tunnels: when a packet has no more than one LISP IP header (two IP headers total) and when it needs to be diverted to new RLOC, an ETR can decapsulate the packet (remove the LISP header) and prepends a new tunnel header, with new RLOC, on to the packet. Doing this allows a packet to be re-routed by the re- encapsulating router without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. Farinacci, et al. Expires October 15, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte header that follows the UDP header, an ITR prepends or an ETR strips. Address Family Identifier (AFI): a term used to describe an address encoding in a packet. An address family currently pertains to an IPv4 or IPv6 address. See [AFI] and [RFC1700] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the the length of the address is 0 bytes following the 16-bit AFI value of 0. Also, refer to [LCAF] for LISP specific AFI encodings. Negative Mapping Entry: also known as a negative cache entry, is an EID-to-RLOC entry where an EID-prefix is advertised or stored with no RLOCs. That is, the locator-set for the EID-to-RLOC entry is empty or has an encoded locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well defined actions that are encoded in a Negative Map-Reply. Data Probe: a LISP-encapsulated data packet where the inner header destination address equals the outer header destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host. A Data Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design for details. Proxy ITR (PITR): also known as a PTR is defined and described in [INTERWORK], a PITR acts like an ITR but does so on behalf of non- LISP sites which send packets to destinations at LISP sites. Proxy ETR (PETR): is defined and described in [INTERWORK], a PETR acts like an ETR but does so on behalf of LISP sites which send packets to destinations at non-LISP sites. Farinacci, et al. Expires October 15, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 4. Basic Overview One key concept of LISP is that end-systems (hosts) operate the same way they do today. The IP addresses that hosts use for tracking sockets, connections, and for sending and receiving packets do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. This design introduces "Tunnel Routers", which prepends LISP headers on host-originated packets and strip them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet and an egress tunnel router strips the new header. The ITR performs EID-to-RLOC lookups to determine the routing path to the the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems (hosts) only send to addresses which are EIDs. They don't know addresses are EIDs versus RLOCs but assume packets get to LISP routers, which in turn, deliver packets to the destination the end-system has specified. o EIDs are always IP addresses assigned to hosts. o LISP routers mostly deal with Routing Locator addresses. See details later in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers; preferably, topologically-oriented addresses from provider CIDR blocks. o When a router originates packets it may use as a source address either an EID or RLOC. When acting as a host (e.g. when terminating a transport session such as SSH, TELNET, or SNMP), it may use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC Farinacci, et al. Expires October 15, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. o EIDs are not expected to be usable for global end-to-end communication in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication. o EID prefixes are likely to be hierarchically assigned in a manner which is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The hierarchy is based on a address allocation hierarchy which is not dependent on the network topology. o EIDs may also be structured (subnetted) in a manner suitable for local routing within an autonomous system. An additional LISP header may be prepended to packets by a transit router (i.e. TE-ITR) when re-routing of the path for a packet is desired. An obvious instance of this would be an ISP router that needs to perform traffic engineering for packets in flow through its network. In such a situation, termed Recursive Tunneling, an ISP transit acts as an additional ingress tunnel router and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). This specification mandates that no more than two LISP headers get prepended to a packet. This avoids excessive packet overhead as well as possible encapsulation loops. It is believed two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the egress tunnel router might be the last-hop router directly-connected to the destination host. Another example, perhaps for a VPN service out-sourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other tunnel routers is allowed for maximum flexibility. See Section 8 for more details. Farinacci, et al. Expires October 15, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow with the following conditions: o Source host "host1.abc.com" is sending a packet to "host2.xyz.com", exactly what host1 would do if the site was not using LISP. o Each site is multi-homed, so each tunnel router has an address (RLOC) assigned from the service provider address block for each provider to which that particular tunnel router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively. o Data Probes are used to solicit Map-Replies versus using Map- Requests. And the Data Probes are sent on the underlying topology (the LISP 1.0 variant) but could also be sent over an alternative topology (the LISP 1.5 variant) as it would in [ALT]. Client host1.abc.com wants to communicate with server host2.xyz.com: 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. It does a DNS lookup on host2.xyz.com. An A/AAAA record is returned. This address is used as the destination EID and the locally-assigned address of host1.abc.com is used as the source EID. An IPv4 or IPv6 packet is built using the EIDs in the IPv4 or IPv6 header and sent to the default router. 2. The default router is configured as an ITR. The ITR must be able to map the EID destination to an RLOC of the ETR at the destination site. The ITR prepends a LISP header to the packet, with one of its RLOCs as the source IPv4 or IPv6 address. The destination EID from the original packet header is used as the destination IPv4 or IPv6 in the prepended LISP header. Subsequent packets, where the outer destination address is the destination EID will be sent until EID-to-RLOC mapping is learned. 3. In LISP 1, the packet is routed through the Internet as it is today. In LISP 1.5, the packet is routed on a different topology which may have EID prefixes distributed and advertised in an aggregatable fashion. In either case, the packet arrives at the ETR. The router is configured to "punt" the packet to the router's processor. See Section 7 for more details. For LISP 2.0 and 3.0, the behavior is not fully defined yet. Farinacci, et al. Expires October 15, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 4. The LISP header is stripped so that the packet can be forwarded by the router control plane. The router looks up the destination EID in the router's EID-to-RLOC database (not the cache, but the configured data structure of RLOCs). An EID-to-RLOC Map-Reply message is originated by the ETR and is addressed to the source RLOC in the LISP header of the original packet (this is the ITR). The source RLOC of the Map-Reply is one of the ETR's RLOCs. 5. The ITR receives the Map-Reply message, parses the message (to check for format validity) and stores the mapping information from the packet. This information is put in the ITR's EID-to- RLOC mapping cache (this is the on-demand cache, the cache where entries time out due to inactivity). 6. Subsequent packets from host1.abc.com to host2.xyz.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note, the packet may be sent to a different ETR than the one which returned the Map-Reply due to the source site's hashing policy or the destination site's locator-set policy. 7. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), strips the LISP header and forwards the packets to the attached destination host. In order to eliminate the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner header source IP address) to the source RLOC (outer header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both ITR and the ETR may also influence the decision the other makes in selecting an RLOC. See Section 6 for more details. Farinacci, et al. Expires October 15, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 5. Tunneling Details This section describes the LISP Data Message which defines the tunneling header used to encapsulate IPv4 and IPv6 packets which contain EID addresses. Even though the following formats illustrate IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2 combinations are supported as well. Since additional tunnel headers are prepended, the packet becomes larger and in theory can exceed the MTU of any link traversed from the ITR to the ETR. It is recommended, in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source. Based on informal surveys of large ISP traffic patterns, it appears that most transit paths can accommodate a path MTU of at least 4470 bytes. The exceptions, in terms of data rate, number of hosts affected, or any other metric are expected to be vanishingly small. To address MTU concerns, mainly raised on the RRG mailing list, the LISP deployment process will include collecting data during its pilot phase to either verify or refute the assumption about minimum available MTU. If the assumption proves true and transit networks with links limited to 1500 byte MTUs are corner cases, it would seem more cost-effective to either upgrade or modify the equipment in those transit networks to support larger MTUs or to use existing mechanisms for accommodating packets that are too large. For this reason, there is currently no plan for LISP to add any new additional, complex mechanism for implementing fragmentation and reassembly in the face of limited-MTU transit links. If analysis during LISP pilot deployment reveals that the assumption of essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect, then LISP can be modified prior to protocol standardization to add support for one of the proposed fragmentation and reassembly schemes. Note that two simple existing schemes are detailed in Section 5.4. Farinacci, et al. Expires October 15, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 5.1. LISP IPv4-in-IPv4 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires October 15, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 5.2. LISP IPv6-in-IPv6 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload Length | Next Header=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | Farinacci, et al. Expires October 15, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer Header: is the outer header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to- RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used. UDP Header: contains a ITR selected source port when encapsulating a packet. See Section 6.4 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA assigned port value 4341. UDP Checksum: this field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. UDP Length: for an IPv4 encapsulated packet, the inner header Total Length plus the UDP and LISP header lengths are used. For an IPv6 encapsulated packet, the inner header Payload Length plus the size of the IPv6 header (40 bytes) plus the size of the UDP and LISP Farinacci, et al. Expires October 15, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 headers are used. The UDP header length is 8 bytes. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See Section 6.3.1 for details. Both N and V bits MUST NOT be set in the same packet. If they are, a decapsulating ETR must treat the "Nonce/Map-Version" field as having a Nonce value present. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit must be 1. This bit should be ignored and has no meaning when the N bit is set to 0. See Section 6.3.1 for details. V: this is the Map-Version present bit. When this bit is set to 1, the N bit must be 0. Refer to Section 6.5.3 for more details. This bit indicates that the first 4 bytes of the LISP header is encoded as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: this is the Instance ID bit. See Section 5.4.3 for more details. When this bit is set to 1, the Locator Status Bits field is reduced to 8-bits and the high-order 24-bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmited as zero and ignored on receipt. The format of the last 4 bytes of the LISP header would look like: Farinacci, et al. Expires October 15, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags: this 3-bit field is reserved for future flag use. It is set to 0 on transmit and ignored on receipt. LISP Nonce: is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least significant bit of field. The field is 32-bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator Status Bit is set to 1, the ITR is indicating to the ETR the RLOC associated with the bit ordinal has up status. See Section 6.3 for details on how an ITR can determine other ITRs at the site are reachable. When a site has multiple EID-prefixes which result in multiple mappings (where each could have a different locator-set), the Locator Status Bits setting in an encapsulated packet MUST reflect the mapping for the EID-prefix that the inner-header source EID address matches. When doing Recursive Tunneling or ITR/PTR encapsulation: o The outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: Farinacci, et al. Expires October 15, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer header Type of Service field SHOULD be copied from the stripped OH header Type of Service field (with one caveat, see below). Copying the TTL serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service field and the IPv6 Traffic Class field [RFC3168]. The ECN field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit ECN field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit ECN field from the stripped outer header to the new outer header. If the ECN field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve Congestion Experienced (CE) indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. 5.4. Dealing with Large Encapsulated Packets In the event that the MTU issues mentioned above prove to be more serious than expected, this section proposes 2 simple mechanisms to deal with large packets. One is stateless using IP fragmentation and the other is stateful using Path MTU Discovery [RFC1191]. It is left to the implementor to decide if the stateless or stateful mechanism should be implemented. Both or neither can be decided as well since it is a local decision in the ITR regarding how to deal with MTU issues. Sites can interoperate with differing mechanisms. Both stateless and stateful mechanisms also apply to Reencapsulating and Recursive Tunneling. So any actions reference below to an ITR also apply to an TE-ITR. 5.4.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: Farinacci, et al. Expires October 15, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 1. Define an architectural constant S for the maximum size of a packet, in bytes, an ITR would receive from a source inside of its site. 2. Define L to be the maximum size, in bytes, a packet of size S would be after the ITR prepends the LISP header, UDP header, and outer network layer header of size H. 3. Calculate: S + H =3D L. When an ITR receives a packet from a site-facing interface and adds H bytes worth of encapsulation to yield a packet size greater than L bytes, it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. This will ensure that the new, encapsulated packets are of size (S/2 + H), which is always below the effective tunnel MTU. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. This behavior is performed by the ITR when the source host originates a packet with the DF field of the IP header is set to 0. When the DF field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L, and sends an ICMP Too Big message to the source with a value of S, where S is (L - H). When the outer header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification recommends that L be defined as 1500. 5.4.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each locator per mapping cache entry. The effective MTU is what the core network can deliver along the path between ITR and ETR. Farinacci, et al. Expires October 15, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Too Big message to the ITR. The ITR will parse the ICMP message to determine which locator is affected by the effective MTU change and then record the new effective MTU value in the mapping cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the mapping cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Too Big message back to the source. The packet size advertised by the ITR in the ICMP Too Big message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 5.4.3. Using Virtualization and Segmentation with LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. See [LCAF] for details on address encodings. An Instance ID can be carried in a LISP encapsulated packet. An ITR that prepends a LISP header, will copy a 24-bit value, used by the LISP router to uniquely identify the address space. The value is copied to the Instance ID field of the LISP header and the I-bit is set to 1. When an ETR desapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. Some examples of the 24-bit value to copy or map into the Instance ID field could be a 802.1Q VLAN tag or a configured VRF-ID value. Farinacci, et al. Expires October 15, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6. EID-to-RLOC Mapping 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats The following new UDP packet types are used to retrieve EID-to-RLOC mappings: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol =3D 17 | Header Checksum = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires October 15, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 | | + Destination Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. The UDP Length field will reflect the length of the UDP header and the LISP Message payload. The UDP Checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register and ECM control messages. It MUST be checked on receipt and if the checksum fails, the packet MUST be dropped. LISP-CONS [CONS] use TCP to send LISP control messages. The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries. This main LISP specification is the authoritative source for message format definitions for the Map-Request and Map-Reply messages. Farinacci, et al. Expires October 15, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6.1.1. LISP Packet Type Allocations This section will be the authoritative source for allocating LISP Type values. Current allocations are: Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Encapsulated Control Message: 8 b'1000' 6.1.2. Map-Request Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D1 |A|M|P|S| Reserved | IRC | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-EID-AFI | Source EID Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI n | ITR-RLOC Address n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Reserved | EID mask-len | EID-prefix-AFI | Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | EID-prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Map-Reply Record ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Farinacci, et al. Expires October 15, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Type: 1 (Map-Request) A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. M: When set, it indicates a Map-Reply Record segment is included in the Map-Request. P: Indicates that a Map-Request should be treated as a "piggyback" locator reachability probe. The receiver should respond with a Map-Reply with the P bit set and the nonce copied from the Map- Request. See Section 6.3.2 for more details. S: This is the SMR bit. See Section 6.5.2 for details. Reserved: Set to 0 on transmission and ignored on receipt. IRC: This 5-bit field is the ITR-RLOC Count which encodes the number of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this message. Multiple ITR-RLOC Address fields are used so a Map- Replier can select which destination address to use for a Map- Reply. The IRC value ranges from 0 to 31, where IRC value 0 means an ITR-RLOC address count of 1, an IRC value of 1 means an ITR- RLOC address count of 2, and so on up to an IRC value of 31, which means an ITR-RLOC address count of 32. Record Count: The number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. Source-EID-AFI: Address family of the "Source EID Address" field. Farinacci, et al. Expires October 15, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Source EID Address: This is the EID of the source host which originated the packet which is invoking this Map-Request. When Map-Requests are used for refreshing a map-cache entry or for RLOC-probing, the value 0 is used. ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that follows this field. ITR-RLOC Address: Used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address. EID mask-len: Mask length for EID prefix. EID-prefix-AFI: Address family of EID-prefix according to [RFC5226] EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-prefix is set to the destination IP address of the data packet. And the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID- prefix used in the Map-Request has the same mask-length as the EID-prefix returned from the site when it sent a Map-Reply message. Map-Reply Record: When the M bit is set, this field is the size of the "Record" field in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the Source EID. This allows the ETR which will receive this Map-Request to cache the data if it chooses to do so. Mapping Protocol Data: See [CONS] or [ALT] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. 6.1.3. EID-to-RLOC UDP Map-Request Message A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map-Request is the destination-EID from the packet which had a mapping cache lookup failure. For the latter 2 cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the locator-set of the map cache entry. The source address is either an IPv4 or IPv6 RLOC address depending if the Map-Request is using an IPv4 versus IPv6 header, respectively. Farinacci, et al. Expires October 15, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 In all cases, the UDP source port number for the Map-Request message is a randomly allocated 16-bit value and the UDP destination port number is set to the well-known destination port number 4342. A successful Map-Reply updates the cached set of RLOCs associated with the EID prefix range. One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST be filled in by the ITR. The number of fields encoded must be placed in the IRC field. The ITR MAY include all locally configured locators in this list or just provide one locator address from each address family it supports. If the ITR erroneously provides no ITR- RLOC addresses, the Map-Replier MUST drop the Map-Request. Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on encapsulated Map-Requests and Map-Resolvers can be found in [LISP-MS]. Map-Requests MUST be rate-limited. It is recommended that a Map- Request for the same EID-prefix be sent no more than once per second. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the map-cache, it may originate a "verifying Map-Request", addressed to the map-requesting ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map- Request" directly to the originating Map-Request source. If the RLOC is not in the locator-set, then the ETR MUST send the "verifying Map- Request" to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" mapping data. Farinacci, et al. Expires October 15, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6.1.4. Map-Reply Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|P|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 2 (Map-Reply) P: Indicates that the Map-Reply is in response to a "piggyback" locator reachability Map-Request. The nonce field should contain a copy of the nonce value from the original Map-Request. See Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce locator reachability algorithm. See Section 6.3.1 for more details. Reserved: Set to 0 on transmission and ignored on receipt. Farinacci, et al. Expires October 15, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Record Count: The number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of the Map- Reply. Record TTL: The time in minutes the recipient of the Map-Reply will store the mapping. If the TTL is 0, the entry should be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping. Locator Count: The number of Locator entries. A locator entry comprises what is labeled above as 'Loc'. The locator count can be 0 indicating there are no locators for the EID-prefix. EID mask-len: Mask length for EID prefix. ACT: This 3-bit field describes negative Map-Reply actions. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. The actions defined are used by an ITR or PTR when a destination EID matches a negative mapping cache entry. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned values are: (0) Drop: The packet is dropped silently. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. A: The Authoritative bit, when sent by a UDP-based message is always set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-prefix. Map-Version Number: When this 12-bit value is non-zero the Map-Reply reply sender is informing the ITR what the version number is for the EID-record contained in the Map-Reply. The ETR can allocate this number internally but MUST coordinate this value with other Farinacci, et al. Expires October 15, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 ETRs for the site. When this value is 0, there is no versioning information conveyed. The Map-Version Number can be included in Map-Request and Map-Register messages. See Section 6.5.3 for more details. EID-AFI: Address family of EID-prefix according to [RFC5226]. EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. Priority: each RLOC is assigned a unicast priority. Lower values are more preferable. When multiple RLOCs have the same priority, they may be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding. Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance unicast traffic between them. Weight is encoded as a percentage of total unicast packets that match the mapping entry. If a non-zero weight value is used for any RLOC, then all RLOCs must use a non-zero weight value and then the sum of all weight values MUST equal 100. If a zero value is used for any RLOC weight, then all weights MUST be zero and the receiver of the Map-Reply will decide how to load-split traffic. See Section 6.4 for a suggested hash algorithm to distribute load across locators with same priority and equal weight values. When a single RLOC exists in a mapping entry, the weight value MUST be set to 100 and ignored on receipt. M Priority: each RLOC is assigned a multicast priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. M Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance building multicast distribution trees across multiple ITRs. The weight is encoded as a percentage of total number of trees build to the source site identified by the EID-prefix. If a non-zero weight value is used for any RLOC, then all RLOCs must use a non-zero weight value and then the sum of all weight values MUST equal 100. If a zero value is used for any RLOC weight, then all weights MUST be zero and the receiver of the Map-Reply will decide how to distribute multicast state across ITRs. Farinacci, et al. Expires October 15, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Unused Flags: set to 0 when sending and ignored on receipt. L: when this bit is set, the locator is flagged as a local locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to 0 for all locators in this locator-set. P: when this bit is set, an ETR informs the RLOC-probing ITR that the locator address, for which this bit is set for, is the one being RLOC-probed and may be different from the source address of the Map-Reply. An ITR that RLOC-probes a particular locator, MUST use this locator for retrieving the data structure used to store the fact that the locator is reachable. The P bit is set for a single locator in the same locator set. If an implementation sets more than one P bit erroneously, the receiver of the Map-Reply MUST select the first locator. The P bit MUST NOT be set for locator- set records sent in Map-Request and Map-Register messages. R: when this bit is set, the locator is known to be reachable from the Map-Reply sender's perspective. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR or router acting as a proxy replier for the EID-prefix. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router), and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID. Mapping Protocol Data: See [CONS] or [ALT] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. 6.1.5. EID-to-RLOC UDP Map-Reply Message When a Data Probe packet or a Map-Request triggers a Map-Reply to be sent, the RLOCs associated with the EID-prefix matched by the EID in the original packet destination IP address field will be returned. The RLOCs in the Map-Reply are the globally-routable IP addresses of the ETR but are not necessarily reachable; separate testing of reachability is required. Note that a Map-Reply may contain different EID-prefix granularity (prefix + length) than the Map-Request which triggers it. This might occur if a Map-Request were for a prefix that had been returned by an Farinacci, et al. Expires October 15, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-prefixes that are covered by a Map- Reply containing one, less-specific prefix, replaces the entry with the less-specific EID-prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur but not by removing the less-specific prefix rather by adding the more-specific prefixes which during a lookup will override the less-specific prefix. When an ETR is configured with overlapping EID-prefixes, a Map- Request with an EID that longest matches any EID-prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-prefixes: 10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24 A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-prefix of 10.1.1.0/24. A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. Note that not all overlapping EID-prefixes need to be returned, only the more specifics (note in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) entries for the matching EID-prefix of the requesting EID. When more than one EID-prefix is returned, all SHOULD use the same Time-to-Live value so they can all time out at the same time. When a more specific EID-prefix is received later, its Time-to-Live value in the Map-Reply record can be stored even when other less specifics exist. When a a less specific EID-prefix is received later, its map-cache expiration time should be set to the minimum expiration time of any more specific EID-prefix in the map-cache. Map-Replies SHOULD be sent for an EID-prefix no more often than once per second to the same requesting router. For scalability, it is expected that aggregation of EID addresses into EID-prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range thereby reducing the number of Map-Request messages. Map-Reply records can have an empty locator-set. This type of a Map- Reply is called a Negative Map-Reply. Negative Map-Replies convey Farinacci, et al. Expires October 15, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 special actions by the sender to the ITR or PTR which have solicited the Map-Reply. There are two primary applications for Negative Map- Replies. The first is for a Map-Resolver to instruct an ITR or PTR when a destination is for a LISP site versus a non-LISP site. And the other is to source quench Map-Requests which are sent for non- allocated EIDs. For each Map-Reply record, the list of locators in a locator-set MUST appear in the same order for each ETR that originates a Map-Reply message. The locator-set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address. When sending a Map-Reply message, the destination address is copied from the one of the ITR-RLOC fields from the Map-Request. The ETR can choose a locator address from one of the address families it supports. For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local locator addresses listed in the locator-set of any mapping record in the message and should be chosen to allow uRPF checks to succeed in the upstream service provider. The destination port of a Map-Reply message is copied from the source port of the Map-Request or Data-Probe and the source port of the Map-Reply message is set to the well-known UDP port 4342. 6.1.5.1. Traffic Redirection with Coarse EID-Prefixes When an ETR is misconfigured or compromised, it could return coarse EID-prefixes in Map-Reply messages it sends. The EID-prefix could cover EID-prefixes which are allocated to other sites redirecting their traffic to the locators of the compromised site. To solve this problem, there are two basic solutions that could be used. The first is to have Map-Servers proxy-reply on behalf of ETRs so their registered EID-prefixes are the ones returned in Map- Replies. Since the interaction between an ETR and Map-Server is secured with shared-keys, it is more difficult for an ETR to misbehave. The second solution is to have ITRs and PTRs cache EID- prefixes with mask-lengths that are greater than or equal to a configured prefix length. This limits the damage to a specific width of any EID-prefix advertised, but needs to be coordinated with the allocation of site prefixes. These solutions can be used independently or at the same time. At the time of this writing, other approaches are being considered and researched. Farinacci, et al. Expires October 15, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6.1.6. Map-Register Message Format The usage details of the Map-Register message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. The Map-Register message format is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D3 |p| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|P|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Farinacci, et al. Expires October 15, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Type: 3 (Map-Register) p: This is the Map-Reply proxy-bit, when set to 1 an ETR sends a Map- Register message requesting for the Map-Server to proxy Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR. Details on this usage will be provided in a future version of this draft. Reserved: Set to 0 on transmission and ignored on receipt. Record Count: The number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] is recommended. The definition of the rest of the Map-Register can be found in the Map-Reply section. However, the record TTL field is not used and set to 0. 6.1.7. Encapsulated Control Message Format An Encapsulated Control Message is used to encapsulate control packets sent between xTRs and the mapping database system described in [LISP-MS]. Farinacci, et al. Expires October 15, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 | Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is randomly assigned and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum Farinacci, et al. Expires October 15, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 field MUST be non-zero. LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages and PIM Join-Prune messages [MLISP] are allowed to be encapsulated. Encapsulating other types of LISP control messages are for further study. When Map-Requests are sent for RLOC-probing purposes (i.e the P-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. 6.2. Routing Locator Selection Both client-side and server-side may need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply messages. Alternatively, RLOC information may be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following enumerates different scenarios for choosing RLOCs and the controls that are available: o Server-side returns one RLOC. Client-side can only use one RLOC. Server-side has complete control of the selection. o Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o Server-side sets weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs are unreachable. o Either side (more likely on the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the Farinacci, et al. Expires October 15, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 client-side ITR RLOC is done by caching the inner header source EID and the outer header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server- side ETR must assume each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-prefix encoding cannot be conveyed in data packets, the EID-to-RLOC cache on tunnel routers can grow to be very large. o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that Farinacci, et al. Expires October 15, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated Farinacci, et al. Expires October 15, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the Loc-Status-Bit that corresponds to that locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-prefix. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. When ITRs receive ICMP Network or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators which are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Unreachable messages. If an ITR does receive an ICMP Network or Host Unreachable message, it MAY originate its own ICMP Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if a locator address from a locator-set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default Free Zone (DFZ), it can decide to not use the locator even though the Loc-Status-Bits indicate the locator is up. In this case, the path from the ITR to the ETR that is assigned the locator is not available. More details are in [LOC-ID-ARCH]. Optionally, an ITR can send a Map-Request to a Locator and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by tunnel routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When an Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with priority 255. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In Farinacci, et al. Expires October 15, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 most cases, the ETR can also reach the ITR but cannot assume this to be true due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR should not use the lack of return traffic as an indication that the ETR is unreachable. Instead, it must use an alternate mechanisms to determine reachability. 6.3.1. Echo Nonce Algorithm When data flows bidirectionally between locators from different sites, a simple mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N and E bits and places a 24-bit nonce in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N bit set and E bit cleared. The ITR sees this "echoed nonce" and knows the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in echo-nonce-request state, then the path to the ETR is unreachable. This decision may be overridden by other locator reachability algorithms. Once the ITR determines the path to the ETR is down it can switch to another locator for that EID-prefix. Note that "ITR" and "ETR" are relative terms here. Both devices must be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR may both go into echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation specific setting. However, when an ITR is in echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and then subsequently, continue sending echo-nonce-request packets. This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional. That is, the ETR receiving traffic at a site may not be the same device as an ITR which transmits traffic from that site or the site to site traffic is unidirectional so there is no ITR returning traffic. Farinacci, et al. Expires October 15, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may regard the locator unreachable erroneously. An ITR should only set the E-bit in a encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the Map- Reply message. Note that other locator reachability mechanisms are being researched and can be used to compliment or even override the Echo Nonce Algorithm. See next section for an example of control-plane probing. 6.3.2. RLOC Probing Algorithm RLOC Probing is a method that an ITR or PTR can use to determine the reachability status of one or more locators that it has cached in a map-cache entry. The P-bit (Probe Bit) of the Map-Request and Map- Reply messages are used for RLOC Probing. RLOC probing is done in the control-plane on a timer basis where an ITR or PTR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the ALT like one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-prefix of the map-cache entry cached by the ITR or PTR. The ITR or PTR may include a mapping data record for its own database mapping information. When an ETR receives a Map-Request message with the P-bit set, it returns a Map-Reply with the P-bit set. The source address of the Map-Reply is set from the destination address of the Map-Request and the destination address of the Map-Reply is set from the source address of the Map-Request. The Map-Reply should contain mapping data for the EID-prefix contained in the Map-Request. This provides the opportunity for the ITR or PTR, which sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC Probing. The greatest benefit of RLOC Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another locator from the cached locator. RLOC Probing can also provide RTT estimates between a pair of locators which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the Farinacci, et al. Expires October 15, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 requirement for failure detection times are very small. Continued research and testing will attempt to characterize the tradeoffs of failure detection times versus message overhead. 6.4. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to a requesting ITR, the locator-set for the EID-prefix may contain different priority values for each locator address. When more than one best priority locator exists, the ITR can decide how to load share traffic against the corresponding locators. The following hash algorithm may be used by an ITR to select a locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash can be used or the traditional 5-tuple hash which includes the source and destination addresses, source and destination TCP, UDP, or SCTP port numbers and the IP protocol number field or IPv6 next- protocol fields of a packet a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of locators stored in the locator-set for the EID-to-RLOC mapping. 3. The remainder will be yield a value of 0 to "number of locators minus 1". Use the remainder to select the locator in the locator-set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a random value allows core routers which are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets which are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. Farinacci, et al. Expires October 15, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6.5. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change and the ETRs do not keep track of who requested its mappings. For scalability reasons, we want to maintain this approach but need to provide a way for ETRs change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. When a locator record is added to the end of a locator-set, it is easy to update mappings. We assume new mappings will maintain the same locator ordering as the old mapping but just have new locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the loc-status-bits that correspond to locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing locator-set. When a locator record is removed from a locator-set, ITRs that have the mapping cached will not use the removed locator because the xTRs will set the loc-status-bit to 0. So even if the locator is in the list, it will not be used. For new mapping requests, the xTRs can set the locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding loc-status-bit to 0. This forces ITRs with old or new mappings to avoid using the removed locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the locator-set and new records appended to the locator-set. At some point, it would be useful to compact the locator-set so the loc-status-bit settings can be efficiently packed. We propose here three approaches for locator-set compaction, one operational and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning. 6.5.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So there is a 24 hour window to time out old mappings. The following clock sweep procedure is used: Farinacci, et al. Expires October 15, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window. 2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour. 3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1 hour window the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. 4. At the end of the 1 hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. 6.5.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for xTRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the xTRs don't keep track of remote ITRs that have cached their mappings, they can not tell exactly who needs the new mapping entries. So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites. The xTRs can locally decide the algorithm for how often and to how many sites it sends SMR messages. An SMR message is simply a bit set in a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder must rate-limited these messages. The following procedure shows how a SMR exchange occurs when a site is doing locator-set compaction for an EID-to-RLOC mapping: 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- Farinacci, et al. Expires October 15, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 prefix uses is the one copied from the SMR message. 3. The remote xTR retransmits the Map-Request slowly until it gets a Map-Reply while continuing to use the cached mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message provided the Map-Request nonce matches the nonce from the SMR. The Map-Reply messages SHOULD be rate limited. This is important to avoid Map-Reply implosion. 5. The ETRs, at the site with the changed mapping, records the fact that the site that sent the Map-Request has received the new mapping data in the mapping cache entry for the remote site so the loc-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. For security reasons an ITR MUST NOT process unsolicited Map-Replies. The nonce MUST be carried from SMR packet, into the resultant Map- Request, and then into Map-Reply to reduce spoofing attacks. To avoid map-cache entry corruption by a third-party, a sender of an SMR-based Map-Request must be verified. If an ITR receives an SMR- based Map-Request and the source is not in the locator-set for the stored map-cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. 6.5.3. Database Map Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation can stop to a removed locator and start to a new locator in the locator-set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 6.5.2 occurs. An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version number. This is known as the Source Map-Version Number. Farinacci, et al. Expires October 15, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 When an ETR decapsulates a packet and detects the Source Map-Version Number is greater than the last Map-Version Number sent in a Map- Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-prefix. So values that are greater, are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information and an xTR does no comparison with previosly received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server can assure that all ETRs for a site registering to it will be Map-Version number synchronized. See [VERSIONING] for a more details analysis and description of Database Map Versioning. Farinacci, et al. Expires October 15, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 7. Router Performance Considerations LISP is designed to be very hardware-based forwarding friendly. By doing tunnel header prepending [RFC1955] and stripping instead of re- writing addresses, existing hardware can support the forwarding model with little or no modification. Where modifications are required, they should be limited to re-programming existing hardware rather than requiring expensive design changes to hard-coded algorithms in silicon. A few implementation techniques can be used to incrementally implement LISP: o When a tunnel encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special FIB entries for the EID-prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing should be performed. The forwarding logic of testing for particular IP protocol number value is not necessary. No changes to existing, deployed hardware should be needed to support this. o On an ITR, prepending a new IP header is as simple as adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Many routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already support this action. o When a received packet's outer destination address contains an EID which is not intended to be forwarded on the routable topology (i.e. LISP 1.5), the source address of a data packet or the router interface with which the source is associated (the interface from which it was received) can be associated with a VRF (Virtual Routing/Forwarding), in which a different (i.e. non- congruent) topology can be used to find EID-to-RLOC mappings. Farinacci, et al. Expires October 15, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8. Deployment Scenarios This section will explore how and where ITRs and ETRs can be deployed and will discuss the pros and cons of each deployment scenario. There are two basic deployment trade-offs to consider: centralized versus distributed caches and flat, recursive, or re-encapsulating tunneling. When deciding on centralized versus distributed caching, the following issues should be considered: o Are the tunnel routers spread out so that the caches are spread across all the memories of each router? o Should management "touch points" be minimized by choosing few tunnel routers, just enough for redundancy? o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, more ETRs does require more management since EID-prefix-to-RLOC mappings need to be explicitly configured. When deciding on flat, recursive, or re-encapsulation tunneling, the following issues should be considered: o Flat tunneling implements a single tunnel between source site and destination site. This generally offers better paths between sources and destinations with a single tunnel path. o Recursive tunneling is when tunneled traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control since the site is prepending a new tunnel header. In the case of TE-based tunneling, the site may have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. o The technique of re-encapsulation ensures that packets only require one tunnel header. So if a packet needs to be rerouted, it is first decapsulated by the ETR and then re-encapsulated with a new tunnel header using a new RLOC. The next sub-sections will describe where tunnel routers can reside in the network. Farinacci, et al. Expires October 15, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8.1. First-hop/Last-hop Tunnel Routers By locating tunnel routers close to hosts, the EID-prefix set is at the granularity of an IP subnet. So at the expense of more EID- prefix-to-RLOC sets for the site, the caches in each tunnel router can remain relatively small. But caches always depend on the number of non-aggregated EID destination flows active through these tunnel routers. With more tunnel routers doing encapsulation, the increase in control traffic grows as well: since the EID-granularity is greater, more Map-Requests and Map-Replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios then their core router counterparts. Memory is typically less expensive in these devices and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing state. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices as well. 8.2. Border/Edge Tunnel Routers Using customer-edge (CE) routers for tunnel endpoints allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE routers for that site. This offers the opposite benefit of the first-hop/last-hop tunnel router scenario: the number of mapping entries and network management touch points are reduced, allowing better scaling. One disadvantage is that less of the network's resources are used to reach host endpoints thereby centralizing the point-of-failure domain and creating network choke points at the CE router. Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Farinacci, et al. Expires October 15, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8.3. ISP Provider-Edge (PE) Tunnel Routers Use of ISP PE routers as tunnel endpoint routers gives an ISP control over the location of the egress tunnel endpoints. That is, the ISP can decide if the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. The advantage of this case is that two or more tunnel headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. An obvious disadvantage is that the end site has no control over where its packets flow or the RLOCs used. As mentioned in earlier sections a combination of these scenarios is possible at the expense of extra packet header overhead, if both site and provider want control, then recursive or re-encapsulating tunnels are used. 8.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator addresss in any LISP control message MUST be a globally routable address and therefore should not contain [RFC1918] addresses. If a LISP router is configured with private addresses, they must be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses must be translated before encapsulation is performed. Both NAT translation and LISP encapsulation functions could be co-located in the same device. More details on LISP address translation can be found in [INTERWORK]. Farinacci, et al. Expires October 15, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 9. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from ITR to ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: Segment 1 (in source LISP site based on EIDs): source-host ---> first-hop ... next-hop ---> ITR Segment 2 (in the core network based on RLOCs): ITR ---> next-hop ... next-hop ---> ETR Segment 3 (in the destination LISP site based on EIDs): ETR ---> next-hop ... last-hop ---> destination-host For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal matter as they are today. The ITR performs a TTL decrement and test for 0 before encapsulating. So the ITR hop is seen by the traceroute source has an EID address (the address of site-facing interface). For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destination of the ICMP messages are to the ITR RLOC address, the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client as well as retaining the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0 like the previous core routers did. For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be Farinacci, et al. Expires October 15, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host. 9.1. IPv6 Traceroute IPv6 traceroute follows the procedure described above since the entire traceroute data packet is included in ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention for forwarding ICMP messages back to the traceroute source. 9.2. IPv4 Traceroute For IPv4 traceroute, we cannot follow the above procedure since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 bytes that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source is lost. The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination). 9.3. Traceroute using Mixed Locators When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, you cannot get all 3 segments of the traceroute. Segment 2 of the traceroute can not be conveyed to the traceroute source since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, Farinacci, et al. Expires October 15, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. Farinacci, et al. Expires October 15, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 10. Mobility Considerations There are several kinds of mobility of which only some might be of concern to LISP. Essentially they are as follows. 10.1. Site Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-RLOC mappings for sites are expected to be handled by configuration, outside of the LISP protocol. 10.2. Slow Endpoint Mobility An individual endpoint wishes to move, but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs. [RFC4984] 10.3. Fast Endpoint Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, and primarily where interactions with LISP need to be explored. The problem is that as an endpoint moves, it may require changes to the mapping between its EID and a set of RLOCs for its new network location. When this is added to the overhead of mobile IP binding updates, some packets might be delayed or dropped. In IPv4 mobility, when an endpoint is away from home, packets to it are encapsulated and forwarded via a home agent which resides in the home area the endpoint's address belongs to. The home agent will encapsulate and forward packets either directly to the endpoint or to a foreign agent which resides where the endpoint has moved to. Packets from the endpoint may be sent directly to the correspondent node, may be sent via the foreign agent, or may be reverse-tunneled back to the home agent for delivery to the mobile node. As the mobile node's EID or available RLOC changes, LISP EID-to-RLOC mappings are required for communication between the mobile node and the home agent, whether via foreign agent or not. As a mobile endpoint changes networks, up to three LISP mapping changes may be required: Farinacci, et al. Expires October 15, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 o The mobile node moves from an old location to a new visited network location and notifies its home agent that it has done so. The Mobile IPv4 control packets the mobile node sends pass through one of the new visited network's ITRs, which needs a EID-RLOC mapping for the home agent. o The home agent might not have the EID-RLOC mappings for the mobile node's "care-of" address or its foreign agent in the new visited network, in which case it will need to acquire them. o When packets are sent directly to the correspondent node, it may be that no traffic has been sent from the new visited network to the correspondent node's network, and the new visited network's ITR will need to obtain an EID-RLOC mapping for the correspondent node's site. In addition, if the IPv4 endpoint is sending packets from the new visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-RLOC mapping for that EID. In IPv6 mobility, packets can flow directly between the mobile node and the correspondent node in either direction. The mobile node uses its "care-of" address (EID). In this case, the route-returnability check would not be needed but one more LISP mapping lookup may be required instead: o As above, three mapping changes may be needed for the mobile node to communicate with its home agent and to send packets to the correspondent node. o In addition, another mapping will be needed in the correspondent node's ITR, in order for the correspondent node to send packets to the mobile node's "care-of" address (EID) at the new network location. When both endpoints are mobile the number of potential mapping lookups increases accordingly. As a mobile node moves there are not only mobility state changes in the mobile node, correspondent node, and home agent, but also state changes in the ITRs and ETRs for at least some EID-prefixes. The goal is to support rapid adaptation, with little delay or packet loss for the entire system. Heuristics can be added to LISP to reduce the number of mapping changes required and to reduce the delay per mapping change. Also IP mobility can be modified to require fewer mapping changes. In order to increase overall system Farinacci, et al. Expires October 15, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 performance, there may be a need to reduce the optimization of one area in order to place fewer demands on another. In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have a internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything which decreases the number of new EID- RLOC mappings needed when a node moves, or maintains the validity of an EID-RLOC mapping for a longer time, is useful. 10.4. Fast Network Mobility In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix. If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes. 10.5. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically-independent EID IP addresses that are not advertised into and do not impose a cost on the global routing Farinacci, et al. Expires October 15, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 system. These EIDs are maintained at the edges of the mapping system (in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. Refer to the LISP Mobility Architecture specification [LISP-MN] for more details. Farinacci, et al. Expires October 15, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 11. Multicast Considerations A multicast group address, as defined in the original Internet architecture is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determines where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, will use the same group address as the destination Routing Locator. Having said that, only the source EID and source Routing Locator needs to be dealt with. Therefore, an ITR merely needs to put its own IP address in the source Routing Locator field when prepending the outer IP header. This source Routing Locator address, like any other Routing Locator address MUST be globally routable. Therefore, an EID-to-RLOC mapping does not need to be performed by an ITR when a received data packet is a multicast data packet or when processing a source-specific Join (either by IGMPv3 or PIM). But the source Routing Locator is decided by the multicast routing protocol in a receiver site. That is, an EID to Routing Locator translation is done at control-time. Another approach is to have the ITR not encapsulate a multicast packet and allow the the host built packet to flow into the core even if the source address is allocated out of the EID namespace. If the RPF-Vector TLV [RFC5496] is used by PIM in the core, then core routers can RPF to the ITR (the Locator address which is injected into core routing) rather than the host source address (the EID address which is not injected into core routing). To avoid any EID-based multicast state in the network core, the first approach is chosen for LISP-Multicast. Details for LISP-Multicast and Interworking with non-LISP sites is described in specification [MLISP]. Farinacci, et al. Expires October 15, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 12. Security Considerations It is believed that most of the security mechanisms will be part of the mapping database service when using control plane procedures for obtaining EID-to-RLOC mappings. For data plane triggered mappings, as described in this specification, protection is provided against ETR spoofing by using Return- Routability mechanisms evidenced by the use of a 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. The nonce, coupled with the ITR accepting only solicited Map-Replies goes a long way toward providing decent authentication. LISP does not rely on a PKI infrastructure or a more heavy weight authentication system. These systems challenge the scalability of LISP which was a primary design goal. DoS attack prevention will depend on implementations rate-limiting Map-Requests and Map-Replies to the control plane as well as rate- limiting the number of data-triggered Map-Replies. To deal with map-cache exhaustion attempts in an ITR/PTR, the implementation should consider putting a maximum cap on the number of entries stored with a reserve list for special or frequently accessed sites. This should be a configuration policy control set by the network administrator who manages ITRs and PTRs. Farinacci, et al. Expires October 15, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 13. IANA Considerations Refer to LISP Canonical Address Format specification [LCAF] for IANA considerations. Farinacci, et al. Expires October 15, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 14. Prototype Plans and Status The operator community has requested that the IETF take a practical approach to solving the scaling problems associated with global routing state growth. This document offers a simple solution which is intended for use in a pilot program to gain experience in working on this problem. The authors hope that publishing this specification will allow the rapid implementation of multiple vendor prototypes and deployment on a small scale. Doing this will help the community: o Decide whether a new EID-to-RLOC mapping database infrastructure is needed or if a simple, UDP-based, data-triggered approach is flexible and robust enough. o Experiment with provider-independent assignment of EIDs while at the same time decreasing the size of DFZ routing tables through the use of topologically-aligned, provider-based RLOCs. o Determine whether multiple levels of tunneling can be used by ISPs to achieve their Traffic Engineering goals while simultaneously removing the more specific routes currently injected into the global routing system for this purpose. o Experiment with mobility to determine if both acceptable convergence and session continuity properties can be scalably implemented to support both individual device roaming and site service provider changes. Here is a rough set of milestones: 1. Interoperable implementations have been available since the beginning of 2009. 2. Continue pilot deployment using LISP-ALT as the database mapping mechanism. 3. Continue prototyping and studying other database lookup schemes, be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms. 4. Implement the LISP Multicast draft [MLISP]. 5. Implement the LISP Mobile Node draft [LISP-MN]. 6. Research more on how policy affects what gets returned in a Map- Reply from an ETR. Farinacci, et al. Expires October 15, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 7. Continue to experiment with mixed locator-sets to understand how LISP can help the IPv4 to IPv6 transition. 8. Add more robustness to locator reachability between LISP sites. 9. Continue the deployment of Proxy-ETRs (PETRs) for uses like uRPF avoidance, IPv6 connectivity, and LISP-MN. As of this writing the following accomplishments have been achieved: 1. A unit- and system-tested software switching implementation has been completed on cisco NX-OS for this draft for both IPv4 and IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators. 2. A unit- and system-tested software switching implementation on cisco NX-OS has been completed for draft [ALT]. 3. A unit- and system-tested software switching implementation on cisco NX-OS has been completed for draft [INTERWORK]. Support for IPv4 translation is provided and PTR support for IPv4 and IPv6 is provided. 4. The cisco NX-OS implementation supports an experimental mechanism for slow mobility. 5. There are 5 LISP implementations that exist and the first 4 below have gone through interoperability testing at IETF Hiroshima, based on the draft-ietf-lisp-05.txt spec: 1. cisco NX-OS 2. OpenLISP 3. LISP-Click 4. ZLisp 5. cisco IOS 6. Dave Meyer, Vince Fuller, Darrel Lewis, Gregg Schudel, Andrew Partan and the rest of the lisp-beta team continue to test all the features described above on a dual-stack infrastructure. 7. Darrel Lewis and Dave Meyer have deployed both LISP translation and LISP PTR support in the pilot network. Point your browser to http://www.lisp4.net to see translation happening in action so your non-LISP site can access a web server in a LISP site. Farinacci, et al. Expires October 15, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8. Soon http://www.lisp6.net will work where your IPv6 LISP site can talk to a IPv6 web server in a LISP site by using mixed address-family based locators. 9. An public domain implementation of LISP is available. See [OPENLISP] for details. 10. We have deployed Map-Resolvers and Map-Servers on the LISP pilot network to gather experience with [LISP-MS]. The first layer of the architecture are the xTRs which use Map-Servers for EID- prefix registration and Map-Resolvers for EID-to-RLOC mapping resolution. The second layer are the Map-Resolvers and Map- Servers which connect to the ALT BGP peering infrastructure. And the third layer are ALT-routers which aggregate EID-prefixes and forward Map-Requests. 11. A cisco IOS implementation is available which currently supports IPv4 and IPv6 encapsulation and decapsulation features. 12. A LISP router based LIG implementation is supported, deployed, and used daily to debug and test the LISP pilot network. See [LIG] for details. 13. A Linux implementation of LIG has been made available and supported by Dave Meyer. It can be run on any Linux system which resides in either a LISP site or non-LISP site. See [LIG] for details. Public domain code can be downloaded from http://github.com/davidmeyer/lig/tree/master. 14. An experimental implementation has been written for three locator reachability algorithms. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts which will be documented in future drafts. 15. The LISP pilot network has been converted from using MD5 HMAC authentication for Map-Register messages to SHA-1 HMAC authentication. ETRs send with SHA-1 but Map-Servers can received from either for compatibility purposes. 16. The LISP pilot network is in its 3rd generation. Current experiments are being performed to test EID-prefix aggregation at multiple service boundaries as well as deploying models for the existence of multiple Mapping Service Providers (MSPs). If interested in writing a LISP implementation, testing any of the LISP implementations, or want to be part of the LISP pilot program, please contact lisp@ietf.org. Farinacci, et al. Expires October 15, 2010 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 15. References 15.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. Farinacci, et al. Expires October 15, 2010 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 15.2. Informative References [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-04.txt (work in progress), April 2010. [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and L. Zhang, "APT: A Practical Transit Mapping Service", draft-jen-apt-01.txt (work in progress), November 2007. [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", Internet- Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-03.txt (work in progress), November 2007. Farinacci, et al. Expires October 15, 2010 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing Algorithms for DHTs: Some Open Questions", PDF file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", draft-curran-lisp-emacs-00.txt (work in progress), November 2007. [GSE] "GSE - An Alternate Addressing Architecture for IPv6", draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. [INTERWORK] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt (work in progress), March 2010. [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-farinacci-lisp-lcaf-00.txt (work in progress), April 2010. [LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-ietf-lisp-lig-00.txt (work in progress), April 2010. [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, "Renumbering: Threat or Menace?", Usenix , September 1996. [LISP-MAIN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-12.txt (work in progress), March 2009. [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP Mobility Architecture", draft-meyer-lisp-mn-00.txt (work in progress), July 2009. [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-05.txt (work in progress), April 2010. [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, "Locator/ID Separation Protocol (LISP1) [Routable ID Version]", Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, October 2006. [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, Farinacci, et al. Expires October 15, 2010 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 "Locator/ID Separation Protocol (LISP2) [DNS-based Version]", Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, November 2006. [LISPDHT] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt (work in progress), February 2008. [LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01.txt (work in progress), Januaryr 2009. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-ietf-lisp-multicast-03.txt (work in progress), April 2010. [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08.txt (work in progress), March 2010. [OPENLISP] Iannone, L. and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01.txt (work in progress), July 2008. [RADIR] Narten, T., "Routing and Addressing Problem Statement", draft-narten-radir-problem-statement-00.txt (work in progress), July 2007. [RFC3344bis] Perkins, C., "IP Mobility Support for IPv4, revised", draft-ietf-mip4-rfc3344bis-05 (work in progress), July 2007. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol for Routing Protocol Meta-data Dissemination", draft-handley-p2ppush-unpublished-2007726.txt (work in progress), July 2007. Farinacci, et al. Expires October 15, 2010 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 [VERSIONING] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Versioning", draft-iannone-lisp-mapping-versioning-01.txt (work in progress), March 2010. Farinacci, et al. Expires October 15, 2010 [Page 72] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed review of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussion and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, and Dhirendra Trivedi. In particular, we would like to thank Dave Meyer for his clever suggestion for the name "LISP". ;-) This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [LISP-MAIN] was converted into this IETF LISP working group draft. Farinacci, et al. Expires October 15, 2010 [Page 73] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-07.txt o Posted April 2010. o Added I-bit to data header so LSB field can also be used as an Instance ID field. When this occurs, the LSB field is reduced to 8-bits (from 32-bits). o Added V-bit to the data header so the 24-bit nonce field can also be used for source and destination version numbers. o Added Map-Version 12-bit value to the EID-record to be used in all of Map-Request, Map-Reply, and Map-Register messages. o Added multiple ITR-RLOC fields to the Map-Request packet so an ETR can decide what address to select for the destination of a Map- Reply. o Added L-bit (Local RLOC bit) and P-bit (Probe-Reply RLOC bit) to the Locator-Set record of an EID-record for a Map-Reply message. The L-bit indicates which RLOCs in the locator-set are local to the sender of the message. The P-bit indicates which RLOC is the source of a RLOC-probe Reply (Map-Reply) message. o Add reference to the LISP Canonical Address Format [LCAF] draft. o Made editorial and clarification changes based on comments from Dhirendra Trivedi. o Added wordsmithing comments from Joel Halpern on DF=3D1 setting. o Add John Zwiebel clarification to Echo Nonce Algorithm section 6.3.1. o Add John Zwiebel comment about expanding on proxy-bit for Map- Register messages. o Add NAT section per Ron Bonica comments. o Fix IDnits issues per Ron Bonica. o Added section on Virtualization and Segmentation to explain the use if the Instance ID field in the data header. Farinacci, et al. Expires October 15, 2010 [Page 74] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 B.2. Changes to draft-ietf-lisp-06.txt Editorial based changes: o Posted December 2009. o Fix typo for flags in LISP data header. Changed from "4" to "5". o Add text to indicate that Map-Register messages must contain a computed UDP checksum. o Add definitions for PITR and PETR. o Indicate an AFI value of 0 is an unspecified address. o Indicate that the TTL field of a Map-Register is not used and set to 0 by the sender. This change makes this spec consistent with [LISP-MS]. o Change "... yield a packet size of L bytes" to "... yield a packet size greater than L bytes". o Clarify section 6.1.5 on what addresses and ports are used in Map- Reply messages. o Clarify that LSBs that go beyond the number of locators do not to be SMRed when the locator addresses are greater lexicographically than the locator in the existing locator-set. o Add Gregg, Srini, and Amit to acknowledgment section. o Clarify in the definition of a LISP header what is following the UDP header. o Clarify "verifying Map-Request" text in section 6.1.3. o Add Xu Xiaohu to the acknowledgment section for introducing the problem of overlapping EID-prefixes among multiple sites in an RRG email message. Design based changes: o Use stronger language to have the outer IPv4 header set DF=3D1 so = we can avoid fragment reassembly in an ETR or PETR. This will also make IPv4 and IPv6 encapsulation have consistent behavior. o Map-Requests should not be sent in ECM with the Probe bit is set. These type of Map-Requests are used as RLOC-probes and are sent Farinacci, et al. Expires October 15, 2010 [Page 75] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 directly to locator addresses in the underlying network. o Add text in section 6.1.5 about returning all EID-prefixes in a Map-Reply sent by an ETR when there are overlapping EID-prefixes configure. o Add text in a new subsection of section 6.1.5 about dealing with Map-Replies with coarse EID-prefixes. B.3. Changes to draft-ietf-lisp-05.txt o Posted September 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. o Removed nonce from Map-Register message, it wasn't used so no need for it. o Clarify what to do for unspecified Action bits for negative Map- Replies. Since No Action is a drop, make value 0 Drop. B.4. Changes to draft-ietf-lisp-04.txt o Posted September 2009. o How do deal with record count greater than 1 for a Map-Request. Damien and Joel comment. Joel suggests: 1) Specify that senders compliant with the current document will always set the count to 1, and note that the count is included for future extensibility. 2) Specify what a receiver compliant with the draft should do if it receives a request with a count greater than 1. Presumably, it should send some error back? Farinacci, et al. Expires October 15, 2010 [Page 76] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 o Add Fred Templin in acknowledgment section. o Add Margaret and Sam to the acknowledgment section for their great comments. o Say more about LAGs in the UDP section per Sam Hartman's comment. o Sam wants to use MAY instead of SHOULD for ignoring checksums on ETR. =46rom the mailing list: "You'd need to word it as an ITR = MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. And of course we'd need to confirm that can actually be implemented. In particular, hardware that verifies UDP checksums on receive needs to be checked to make sure it permits 0 checksums." o Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. o Fix description in Map-Request section. Where we describe Map- Reply Record, change "R-bit" to "M-bit". o Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. o Indicate SHA1 can be used as well for Map-Registers. o More Fred comments on MTU handling. o Isidor comment about spec'ing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. o Margaret's comment on gleaning: "The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail." o Add section on RLOC-probing per working group feedback. o Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. o Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. Farinacci, et al. Expires October 15, 2010 [Page 77] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 o Change LISP header to allow a "Research Bit" so the Nonce and LSB fields can be turned off and used for another future purpose. For Luigi et al versioning convergence. o Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. o Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. o Indicate when doing data-gleaning that a verifying Map-Request is sent to the source-EID of the gleaned data packet so we can avoid map-cache corruption by a 3rd party. Comment from Pedro. o Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the the ALT (or to the EID). o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. o Jesper made a comment to loosen the language about requiring the copy of inner TTL to outer TTL since the text to get mixed-AF traceroute to work would violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3. B.5. Changes to draft-ietf-lisp-03.txt o Posted July 2009. o Removed loc-reach-bits longword from control packets per Damien comment. o Clarifications in MTU text from Roque. o Added text to indicate that the locator-set be sorted by locator address from Isidor. o Clarification text from John Zwiebel in Echo-Nonce section. B.6. Changes to draft-ietf-lisp-02.txt o Posted July 2009. o Encapsulation packet format change to add E-bit and make loc- reach-bits 32-bits in length. Farinacci, et al. Expires October 15, 2010 [Page 78] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 o Added Echo-Nonce Algorithm section. o Clarification how ECN bits are copied. o Moved S-bit in Map-Request. o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference draft-meyer-lisp-mn-00.txt. B.7. Changes to draft-ietf-lisp-01.txt o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Defined LEID to be a "LISP EID". o Indicate encapsulation use IPv4 DF=3D0. o Added negative Map-Reply messages with drop, native-forward, and send-map-request actions. o Added Proxy-Map-Reply bit to Map-Register. B.8. Changes to draft-ietf-lisp-00.txt o Posted May 2009. o Rename of draft-farinacci-lisp-12.txt. o Acknowledgment to RRG. Farinacci, et al. Expires October 15, 2010 [Page 79] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Dave Meyer cisco Systems 170 Tasman Drive San Jose, CA USA Email: dmm@cisco.com Darrel Lewis cisco Systems 170 Tasman Drive San Jose, CA USA Email: darlewis@cisco.com Farinacci, et al. Expires October 15, 2010 [Page 80] =0C --Apple-Mail-17-858143068 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit ---- --Apple-Mail-17-858143068-- From jmh@joelhalpern.com Wed Apr 14 19:29:28 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128D828C0F5 for ; Wed, 14 Apr 2010 19:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=-2.903, BAYES_50=0.001, FRT_PROFIT1=3.858] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5dFWR2NOcPU for ; Wed, 14 Apr 2010 19:29:26 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9E80E3A6A69 for ; Wed, 14 Apr 2010 19:29:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 965C9322851B; Wed, 14 Apr 2010 19:29:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-51-173.clppva.btas.verizon.net [71.161.51.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 6AE583228449; Wed, 14 Apr 2010 19:29:14 -0700 (PDT) Message-ID: <4BC679F8.5080607@joelhalpern.com> Date: Wed, 14 Apr 2010 22:29:12 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "lisp@ietf.org" , PAPADIMITRIOU Dimitri Content-Type: multipart/mixed; boundary="------------000106000107030103000203" Subject: [lisp] [Fwd: RE: LISP Reviews] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 02:29:28 -0000 This is a multi-part message in MIME format. --------------000106000107030103000203 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Attached and copied below are the review comments prepared several weeks ago for us by Dimitri Papadimitriou, based on a request by our routing ADs. THe comments were held up by the chairs, who apologise to Dimitri and the working group for the delay. Please review and comment. Thank you, Joel (& Terry) ------------------- Section 2: Section 2 states “greatly improving aggregation and reducing the number of globally-visible, routable prefixes.” If aggregation is perceived as resolving scalability of routing in terms memory size then one should also be ready to assume that routing will result in higher stretch due to the characteristics of the Internet topology. Section 2 states “More cost-effective multi-homing” but it is not stated what is actually meant by this statement and why the Loc/ID scheme as proposed would make multi-homing cost-effective. Section 2 states “Mobility without address changing” but then “… or acquiring a new address based on the new network location.” These statements are contradicting each other. Section 2 states “This draft describes protocol mechanisms to achieve the desired functional separation.” But separation between which functions ? If this statement is related to the separation between forwarding and control/routing, then it is defeated looking at i) the way RLOC reachability testing inter-twin control as part of the forwarding plane, and ii) the use of “Data Probes” forwarding date as part of the control plane of TR’s. Section 2 the statement “This draft attempts to not compete or overlap with such solutions and the proposed protocol changes are expected to complement a host-based mechanism when Traffic Engineering functionality is desired.” raises the question if these solutions would still be complementary if TE functionality is not desired (this is not clearly stated in the document). On the other hand, the statement “Building the solution into the network will facilitate incremental deployment of the technology on the Internet.” should be further developed to explain why “network deployment” is considered as facilitating incremental deployment ? Section 2 states “Some of the design goals of this proposal include:” Which are the other goals ? there is only partial match with the design goals specified at RRG (the term “design goal” seems to have a different meaning) and it is unclear what changes are referring to. The statement “Minimize required changes to Internet infrastructure.” is vague. The statement “most customer site routers” under which condition the remaining fraction would have to change. Section 2 states “7. Avoid or minimize packet loss when EID-to-RLOC mappings need to be performed.” This condition is not addressed by the present proposal as the ITRs drop the packet(s) for which they have no EID-to-RLOC mapping for (as long as response to Map Request is not received and RLOC reachability “tested”). Section 2 describes LISP variants depending on EID “routability” it would be appropriate to state “routability” refers to the core i.e. between ITR/ETR (as EID remain routable in “sites” otherwise there is no difference with host-based solutions) Section 2. LISP 1.5 is assumed to make use of a “separate topology” also referred to as “alternative topology”. The key question is what is this topology ? Section 2. LISP 3 assumes the existence of EID-to-RLOC database. How the existence of the databases is made aware to ITR. This is what determines the use of Data probes vs Map requests if both modes are supported. Section 3: Section 3. The definition of Provider Independent (PI) Addresses states what a PI is not instead of defining what a PI is. Also the document refers to EID prefixes and EID “blocks” what is a “block” and a “sub-block”? Section 3. Definition of PA “LISP uses only topologically-assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice”. Provide a reference of such demonstration. Section 3. ITR/ETR are described as routers while they are actually functions. Describe them as functions instead of “routers”. Section 3. Definition of RLOC seems to be limited to ETR. Thus how ITR set the Source RLOC ? Section 7 (third bullet) makes this assignment even less understandable (the well-defined concept of VRF suddenly appears). Section 3. Validation of “EID-to-RLOC mappings” in cache is defined as time-based only ? not on frequency of usage neither replacement ? Section 3. The most important definition “EID-to-RLOC mapping lookup” is missing. In particular, how a ITR knows that the “incoming” destination address is part of an EID prefix ? More generally which event or condition triggers such lookup ? Section 4: Section 4 states “End-systems (hosts) only send to addresses which are EIDs. They don't know addresses are EIDs versus RLOCs but assume packets get to LISP routers,…” Section 4 “an EID is only routable within the scope of a site” what is the scope of a site ? Section 4 “This specification mandates that no more than two LISP headers get prepended to a packet.” Is there any mechanism preventing ITR (or TE ITR) to perform additional prepending ? and at which cost ? Section 4 last paragraph of p13, refers to Section 8 concerning “flexible” placement of TR’s but does not respond to the question is there a deployment scenario that would not be supported. Section 4.1 states “And the Data Probes are sent on the underlying topology (the LISP 1.0 variant) but could also be sent over an alternative topology (the LISP 1.5 variant) as it would in [ALT].” but in Section 2 does refer to [ALT] in LISP 3 context ? Section 4.1 point 2 (same remark applies to Section 6) misses an important aspect how the mapping is performed the first time a new destination EID is seen at ITR and how subsequent maps are performed. It seems that a) EID-to-RLOC Cache must be first entirely scanned for each incoming packet at ITR (not only the first one) and then if there is no entry i) Data probe i.e. copy the destination EID value in the destination RLOC field (for LISP 1.5) or ii) originate a Map Request; otherwise use the corresponding RLOC value in the retrieved entry as destination RLOC. Needless to say that the delay is proportional to the number of entries in the cache. Nothing is being said if the cache is full (which entry should be replaced i.e. the least frequently used, the least recently used, or the least recently replaced entry). Nothing is said what happens if a more accurate EID prefix is being made available when a less EID prefix is being in use for a set of one or more RLOCs. Section 4.1 point 3 states “The router is configured to "punt" the packet to the router's processor. See Section 7 for more details.” Looking at Section 7 there is no definition of “punting packets”. Section 4.1 point 4 states “The LISP header is stripped so that the packet can be forwarded by the router control plane.” … forwarding traffic by routing control engines result in major drawbacks such as attacks, intrusions, etc. if the value encoded in the destination EID is one of the routers addresses. Section 4.1 point 4 supposedly if there the destination EID is not found in the ETR's EID-to-RLOC database the packet gets dropped ? On the other hand how to prevent that a Map Reply is sent in response for EID prefix not reachable but statically configured in the ETR's EID-to-RLOC database. The case of ETR responding with “coarser EID-RLOC” mapping due e.g. to sub-segmentation is partially addressed in Section 6.1.5.1 Section 4.1 on “gleaned mapping” states “More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID.” But there is no detail on what happens in case of mismatch between the “gleaned mapping” and the result of Map-Request (further details are provided in Section 6.2 last bullet but it does not respond to the question of mismatch). Section 5: Section 5.3 sets the nonce space to 2^24 but does not explain the space of applicability of this field as reading goes this value is limiting the number of bi-directional relationships between TR’s to this number. Section 6: Section 6.1.3 does not explain the result of refresh for which the received EID block would be larger than the requested one. Section 6.1.5 assumes that a “that a Map-Reply may contain different EID-prefix granularity (prefix + length) than the Map-Request which triggers it.” But it doesn’t say if the associated RLOC shall be identical or not ? Section 6.1.4 states “R: when this bit is set, the locator is known to be reachable from the Map-Reply sender's perspective.” Can author explain how a receiver can test its reachability i.e. what is the decision criteria to set the R bit ? Section 6.1.5 where is the “Data Probe packet” format defined actually ? Section 6.1.5 states “The RLOCs in the Map-Reply are the globally-routable IP addresses of the ETR but are not necessarily reachable; separate testing of reachability is required.” Section 6.3 does not define any procedure actually and does not define any criteria for deciding when the RLOC is reachable or not. The key question is if the ITR persists in testing reachability and there is no criteria process by which such decision would stop, the traffic would be forwarded by means of the “separate/alternative topology” forever. Section 6.2 introduces the terms client-side and server-side where are these terms defined ? without such definition readability of the section is low. Section 6.2 RLOC reachability can determined and selected but there is no description on how the EID-to-RLOC selection is performed. Section 6.3 proposes “encapsulated traffic” based procedures thus, if there is no traffic there is no RLOC reachability “test” possible. On the other hand, that section states certain “ICMP exchanges” are documented but reachability of RLOC does not mean availability of the associated EID. There no actual “EID-to-RLOC” testing procedure being defined in the document? What is struggling here is that the “introductory” sections of the document refer to “functional” separations but all the techniques described in this document (and for RLOC reachability testing in particular) result in a complex inter-twin between control messaging as part of the forwarding plane and forwarding date as part of the control plane of routers. The latter is typical from Data Probes processing. If this is the design choice of LISP so let it be but 1) please proof it offers any better functionality compared to “current” design and 2) better cost/performance. It is far from obvious that the complexity concentrated at TR taking into the proposed design offers any real compelling argument. This may also defeat the argument stated in the introduction that “network deployment” is facilitated by network-based solutions. Section 6.3 Point 1 what is the use of the “Loc-Status-Bits” if there is no return traffic (or more precisely no return traffic passing via this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The ETR may process this information but never use it. Section 6.3 states “Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them.” This does not tell which technique to use when no default route are used at all (under “non-normal” circumstances … what should define normality in this context). Section 6.3.1 states “This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional.” The forwarding path may simply be asymmetric (there is nothing that imposes reverse path reaching the source RLOC in case of dual attached sites). This shortcoming defeats this mechanism as an ITR is not “aware” of its neighboring ITR EID-to-RLOC mappings (connected to the same site). This mechanism can only be safely used if the RLOC pair between two sites is unique and remains unique. Section 6.3.2 RLOC Probing by means of the “control plane” this opens the question of what is actually probed the “RLOC” or the EID-to-RLOC entries of the ETR’s database. The difference stems because the latter are static entries the liveness of the former are dependent on the incoming interface liveness. That is entries can be available in the database but if database entries are not in sync with the actual RLOC status there is no possibility to detect reachability of RLOCs by means of this mechanism. Section 6.3.2 states “RLOC Probing can also provide RTT estimates between a pair of locators which can be useful for network management purposes as well as for selecting low delay paths.” If the exchanges are performed in the control plane it is not clear how such RTT/delay values can be derived for the forwarding path ? Can authors explain ? Authors should also check the accuracy of the estimate vs overhead generated by such technique. Section 6.5 the section does not actually explain which messages are used to update the list of Loc-Reach or Loc-Status bits. If it is data traffic-driven then the mechanism is again dependent on the symmetry of the reverse path and the packet rate but also packet differential delays between packets. In the latter case, it is not clear how ITR could retrieve the correct RLOCs to be used if a sequence of 8 packets sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC (indicated as available at arrival of the 8th packet) is received as 1,0,0,0,0,0,0,0. The section makes a long digression on ordering locator set this is not the issue without a sequence number it will never be possible for the receiving ITR to determine the actual state of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep track of who requested mappings upon communication they should tell the state of their mapping but also their transition. Section 6.5.2 is this technique mandatory or not (this is not specified in the text). Point 5 results in obvious situations where the ETR may never stop sending SMR messages. As there is no means a way to prevent that ITR use “old mappings” this result in a deadlock situation (a non-cooperating ITR prevents ETR to stop sending SMR messages). Section 6.5.2 states “So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites.” Thus instead of keeping track of ITR, ETR keep track of the encapsulated traffic ITR send. The mechanism is often cited but never explained e.g. over which time period is the ETR expected to determine the set of communicating ITR’s ? Section 6.5.2 states “Map request” shall be rate limited … rather unclear: assume a single ETR sends one SMR message to 10 different ITRs how the 10 ITR will individually rate limit a single Map Request in response to this SMR message. It is thus worth specifying the flow control of SMR and Map-Request messages in a more systematic way to prevent ETR overloads. Section 7: the first paragraph is a wish not a fact. As such it is doubtful what such paragraph actually brings in the context of a protocol architecture/specification. Section 8: Section 8.1 first paragraph, it is not the location of the source that determines the “size” of the working set of the EID prefix-to-RLOC cache but the number of EID prefixes this “source site” has to reach. The same issue occurs at ETR, small sites may have to be configured with a large list of EID-to-RLOC mapping entries. Next to this the granularity of the EID prefix allocation is also important. --------------000106000107030103000203 Content-Type: application/rtf; name="LISP Core review.rtf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="LISP Core review.rtf" e1xydGYxXGFkZWZsYW5nMTAyNVxhbnNpXGFuc2ljcGcxMjUyXHVjMVxhZGVmZjBcZGVmZjBc c3RzaGZkYmNoMFxzdHNoZmxvY2gwXHN0c2hmaGljaDBcc3RzaGZiaTBcZGVmbGFuZzEwMzNc ZGVmbGFuZ2ZlMTAzM3tcZm9udHRibHtcZjBcZnJvbWFuXGZjaGFyc2V0MFxmcHJxMntcKlxw YW5vc2UgMDIwMjA2MDMwNTA0MDUwMjAzMDR9VGltZXMgTmV3IFJvbWFuO317XGYyXGZtb2Rl cm5cZmNoYXJzZXQwXGZwcnExe1wqXHBhbm9zZSAwMjA3MDMwOTAyMDIwNTAyMDQwNH1Db3Vy aWVyIE5ldzt9DQp7XGYzNlxmc3dpc3NcZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAwMjBi MDYwMzAyMDIwMjAyMDIwNH1UcmVidWNoZXQgTVM7fXtcZjM3XGZzd2lzc1xmY2hhcnNldDBc ZnBycTJ7XCpccGFub3NlIDAyMGIwNTAyMDIwMjA0MDIwMzAzfUZ1dHVyYUEgQmsgQlQ7fXtc ZjM4XGZzd2lzc1xmY2hhcnNldDBcZnBycTJ7XCpccGFub3NlIDAyMGIwNjA0MDMwNTA0MDQw MjA0fVRhaG9tYTt9DQp7XGYxMTBcZnJvbWFuXGZjaGFyc2V0MjM4XGZwcnEyIFRpbWVzIE5l dyBSb21hbiBDRTt9e1xmMTExXGZyb21hblxmY2hhcnNldDIwNFxmcHJxMiBUaW1lcyBOZXcg Um9tYW4gQ3lyO317XGYxMTNcZnJvbWFuXGZjaGFyc2V0MTYxXGZwcnEyIFRpbWVzIE5ldyBS b21hbiBHcmVlazt9e1xmMTE0XGZyb21hblxmY2hhcnNldDE2MlxmcHJxMiBUaW1lcyBOZXcg Um9tYW4gVHVyO30NCntcZjExNVxmYmlkaSBcZnJvbWFuXGZjaGFyc2V0MTc3XGZwcnEyIFRp bWVzIE5ldyBSb21hbiAoSGVicmV3KTt9e1xmMTE2XGZiaWRpIFxmcm9tYW5cZmNoYXJzZXQx NzhcZnBycTIgVGltZXMgTmV3IFJvbWFuIChBcmFiaWMpO317XGYxMTdcZnJvbWFuXGZjaGFy c2V0MTg2XGZwcnEyIFRpbWVzIE5ldyBSb21hbiBCYWx0aWM7fXtcZjExOFxmcm9tYW5cZmNo YXJzZXQxNjNcZnBycTIgVGltZXMgTmV3IFJvbWFuIChWaWV0bmFtZXNlKTt9DQp7XGYxMzBc Zm1vZGVyblxmY2hhcnNldDIzOFxmcHJxMSBDb3VyaWVyIE5ldyBDRTt9e1xmMTMxXGZtb2Rl cm5cZmNoYXJzZXQyMDRcZnBycTEgQ291cmllciBOZXcgQ3lyO317XGYxMzNcZm1vZGVyblxm Y2hhcnNldDE2MVxmcHJxMSBDb3VyaWVyIE5ldyBHcmVlazt9e1xmMTM0XGZtb2Rlcm5cZmNo YXJzZXQxNjJcZnBycTEgQ291cmllciBOZXcgVHVyO30NCntcZjEzNVxmYmlkaSBcZm1vZGVy blxmY2hhcnNldDE3N1xmcHJxMSBDb3VyaWVyIE5ldyAoSGVicmV3KTt9e1xmMTM2XGZiaWRp IFxmbW9kZXJuXGZjaGFyc2V0MTc4XGZwcnExIENvdXJpZXIgTmV3IChBcmFiaWMpO317XGYx MzdcZm1vZGVyblxmY2hhcnNldDE4NlxmcHJxMSBDb3VyaWVyIE5ldyBCYWx0aWM7fXtcZjEz OFxmbW9kZXJuXGZjaGFyc2V0MTYzXGZwcnExIENvdXJpZXIgTmV3IChWaWV0bmFtZXNlKTt9 DQp7XGY0NzBcZnN3aXNzXGZjaGFyc2V0MjM4XGZwcnEyIFRyZWJ1Y2hldCBNUyBDRTt9e1xm NDcxXGZzd2lzc1xmY2hhcnNldDIwNFxmcHJxMiBUcmVidWNoZXQgTVMgQ3lyO317XGY0NzNc ZnN3aXNzXGZjaGFyc2V0MTYxXGZwcnEyIFRyZWJ1Y2hldCBNUyBHcmVlazt9e1xmNDc0XGZz d2lzc1xmY2hhcnNldDE2MlxmcHJxMiBUcmVidWNoZXQgTVMgVHVyO317XGY0NzdcZnN3aXNz XGZjaGFyc2V0MTg2XGZwcnEyIFRyZWJ1Y2hldCBNUyBCYWx0aWM7fQ0Ke1xmNDgwXGZzd2lz c1xmY2hhcnNldDIzOFxmcHJxMiBGdXR1cmFBIEJrIEJUIENFO317XGY0ODNcZnN3aXNzXGZj aGFyc2V0MTYxXGZwcnEyIEZ1dHVyYUEgQmsgQlQgR3JlZWs7fXtcZjQ4NFxmc3dpc3NcZmNo YXJzZXQxNjJcZnBycTIgRnV0dXJhQSBCayBCVCBUdXI7fXtcZjQ5MFxmc3dpc3NcZmNoYXJz ZXQyMzhcZnBycTIgVGFob21hIENFO317XGY0OTFcZnN3aXNzXGZjaGFyc2V0MjA0XGZwcnEy IFRhaG9tYSBDeXI7fQ0Ke1xmNDkzXGZzd2lzc1xmY2hhcnNldDE2MVxmcHJxMiBUYWhvbWEg R3JlZWs7fXtcZjQ5NFxmc3dpc3NcZmNoYXJzZXQxNjJcZnBycTIgVGFob21hIFR1cjt9e1xm NDk1XGZiaWRpIFxmc3dpc3NcZmNoYXJzZXQxNzdcZnBycTIgVGFob21hIChIZWJyZXcpO317 XGY0OTZcZmJpZGkgXGZzd2lzc1xmY2hhcnNldDE3OFxmcHJxMiBUYWhvbWEgKEFyYWJpYyk7 fXtcZjQ5N1xmc3dpc3NcZmNoYXJzZXQxODZcZnBycTIgVGFob21hIEJhbHRpYzt9DQp7XGY0 OThcZnN3aXNzXGZjaGFyc2V0MTYzXGZwcnEyIFRhaG9tYSAoVmlldG5hbWVzZSk7fXtcZjQ5 OVxmc3dpc3NcZmNoYXJzZXQyMjJcZnBycTIgVGFob21hIChUaGFpKTt9fXtcY29sb3J0Ymw7 XHJlZDBcZ3JlZW4wXGJsdWUwO1xyZWQwXGdyZWVuMFxibHVlMjU1O1xyZWQwXGdyZWVuMjU1 XGJsdWUyNTU7XHJlZDBcZ3JlZW4yNTVcYmx1ZTA7XHJlZDI1NVxncmVlbjBcYmx1ZTI1NTtc cmVkMjU1XGdyZWVuMFxibHVlMDsNClxyZWQyNTVcZ3JlZW4yNTVcYmx1ZTA7XHJlZDI1NVxn cmVlbjI1NVxibHVlMjU1O1xyZWQwXGdyZWVuMFxibHVlMTI4O1xyZWQwXGdyZWVuMTI4XGJs dWUxMjg7XHJlZDBcZ3JlZW4xMjhcYmx1ZTA7XHJlZDEyOFxncmVlbjBcYmx1ZTEyODtccmVk MTI4XGdyZWVuMFxibHVlMDtccmVkMTI4XGdyZWVuMTI4XGJsdWUwO1xyZWQxMjhcZ3JlZW4x MjhcYmx1ZTEyODtccmVkMTkyXGdyZWVuMTkyXGJsdWUxOTI7fXtcc3R5bGVzaGVldHsNClxx bCBcbGkwXHJpMFx3aWRjdGxwYXJcd3JhcGRlZmF1bHRcYXNwYWxwaGFcYXNwbnVtXGZhYXV0 b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgXHJ0bGNoXGZjczEgXGFmMFxhZnMyNFxh bGFuZzEwMjUgXGx0cmNoXGZjczAgXGYzN1xmczIyXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dy aWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMgXHNuZXh0MCBOb3JtYWw7fXtcKlxjczEwIFxh ZGRpdGl2ZSBcc3NlbWloaWRkZW4gDQpEZWZhdWx0IFBhcmFncmFwaCBGb250O317XCpcdHMx MVx0c3Jvd2RcdHJmdHNXaWR0aEIzXHRycGFkZGwxMDhcdHJwYWRkcjEwOFx0cnBhZGRmbDNc dHJwYWRkZnQzXHRycGFkZGZiM1x0cnBhZGRmcjNcdGJsaW5kMFx0YmxpbmR0eXBlM1x0c2Nl bGx3aWR0aGZ0czBcdHN2ZXJ0YWx0XHRzYnJkcnRcdHNicmRybFx0c2JyZHJiXHRzYnJkcnJc dHNicmRyZGdsXHRzYnJkcmRnclx0c2JyZHJoXHRzYnJkcnYgDQpccWwgXGxpMFxyaTBcd2lk Y3RscGFyXHdyYXBkZWZhdWx0XGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRc cmluMFxsaW4wXGl0YXAwIFxydGxjaFxmY3MxIFxhZjBcYWZzMjAgXGx0cmNoXGZjczAgXGZz MjBcbGFuZzEwMjRcbGFuZ2ZlMTAyNFxjZ3JpZFxsYW5nbnAxMDI0XGxhbmdmZW5wMTAyNCBc c25leHQxMSBcc3NlbWloaWRkZW4gTm9ybWFsIFRhYmxlO317DQpcczE1XHFsIFxsaTBccmkw XHdpZGN0bHBhclx3cmFwZGVmYXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJp Z2h0XHJpbjBcbGluMFxpdGFwMCBccnRsY2hcZmNzMSBcYWYzOFxhZnMxNlxhbGFuZzEwMjUg XGx0cmNoXGZjczAgXGYzOFxmczE2XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25w MTAzM1xsYW5nZmVucDEwMzMgXHNiYXNlZG9uMCBcc25leHQxNSBcc3NlbWloaWRkZW4gQmFs bG9vbiBUZXh0O317DQpcczE2XHFsIFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4MzJc dHgyNzQ4XHR4MzY2NFx0eDQ1ODBcdHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4OTE2 MFx0eDEwMDc2XHR4MTA5OTJcdHgxMTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3cmFw ZGVmYXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxp dGFwMCBccnRsY2hcZmNzMSBcYWYyXGFmczIwXGFsYW5nMTAyNSBcbHRyY2hcZmNzMCANClxm MlxmczIwXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEw MzMgXHNiYXNlZG9uMCBcc25leHQxNiBcc3R5cnNpZDE1MDkyOTA4IEhUTUwgUHJlZm9ybWF0 dGVkO319e1wqXGxhdGVudHN0eWxlc1xsc2RzdGltYXgxNTZcbHNkbG9ja2VkZGVmMH17XCpc cGdwdGJsIHtccGdwXGlwZ3AwXGl0YXAwXGxpMFxyaTBcc2IwXHNhMH17XHBncFxpcGdwMFxp dGFwMFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDANClxpdGFwMFxsaTBccmkwXHNiMFxz YTB9e1xwZ3BcaXBncDBcaXRhcDBcbGkwXHJpMFxzYjBcc2EwfXtccGdwXGlwZ3AwXGl0YXAw XGxpMFxyaTBcc2IwXHNhMH17XHBncFxpcGdwMFxpdGFwMFxsaTBccmkwXHNiMFxzYTB9e1xw Z3BcaXBncDBcaXRhcDBcbGkwXHJpMFxzYjBcc2EwfXtccGdwXGlwZ3AwXGl0YXAwXGxpMFxy aTBcc2IwXHNhMH17XHBncFxpcGdwMFxpdGFwMFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBn cDBcaXRhcDBcbGkwXHJpMA0KXHNiMFxzYTB9e1xwZ3BcaXBncDBcaXRhcDBcbGkwXHJpMFxz YjBcc2EwfXtccGdwXGlwZ3AwXGl0YXAwXGxpMFxyaTBcc2IwXHNhMH17XHBncFxpcGdwMFxp dGFwMFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDBcaXRhcDBcbGkwXHJpMFxzYjBcc2Ew fXtccGdwXGlwZ3AwXGl0YXAwXGxpMFxyaTBcc2IwXHNhMH17XHBncFxpcGdwMFxpdGFwMFxs aTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDBcaXRhcDBcbGkwXHJpMFxzYjBcc2EwfXtccGdw DQpcaXBncDBcaXRhcDBcbGkwXHJpMFxzYjBcc2EwfXtccGdwXGlwZ3AwXGl0YXAwXGxpMFxy aTBcc2IwXHNhMH17XHBncFxpcGdwMFxpdGFwMFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBn cDBcaXRhcDBcbGkwXHJpMFxzYjBcc2EwfXtccGdwXGlwZ3AwXGl0YXAwXGxpMFxyaTBcc2Iw XHNhMH17XHBncFxpcGdwMFxpdGFwMFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDBcaXRh cDBcbGkwXHJpMFxzYjBcc2EwfXtccGdwXGlwZ3AwXGl0YXAwXGxpMA0KXHJpMFxzYjBcc2Ew fXtccGdwXGlwZ3AwXGl0YXAwXGxpMFxyaTBcc2IwXHNhMH17XHBncFxpcGdwMFxpdGFwMFxs aTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDBcaXRhcDBcbGkwXHJpMFxzYjBcc2EwfXtccGdw XGlwZ3AwXGl0YXAwXGxpMFxyaTBcc2IwXHNhMH17XHBncFxpcGdwMFxpdGFwMFxsaTBccmkw XHNiMFxzYTB9e1xwZ3BcaXBncDBcaXRhcDBcbGkwXHJpMFxzYjBcc2EwfXtccGdwXGlwZ3Aw XGl0YXAwXGxpMFxyaTBcc2IwXHNhMH0NCntccGdwXGlwZ3AwXGl0YXAwXGxpMFxyaTBcc2Iw XHNhMH17XHBncFxpcGdwMFxpdGFwMFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDBcaXRh cDBcbGkwXHJpMFxzYjBcc2EwfX17XCpccnNpZHRibCBccnNpZDg3MTM3XHJzaWQ5MTI2OVxy c2lkNjY3ODEzXHJzaWQ4NjUyNDhccnNpZDEwNzU5MzVccnNpZDE0NDY0MjFccnNpZDE4NDM0 MzNccnNpZDIzNjMwMDVccnNpZDI2MzQ5NDJccnNpZDI4Mjc0NzlccnNpZDMwODg2OTBccnNp ZDMyMTk2OTUNClxyc2lkMzI4MTAwNFxyc2lkMzc2NDE4N1xyc2lkNDA3MjQ1MFxyc2lkNDM1 MzYzOFxyc2lkNDkxOTMzOVxyc2lkNDk4NDg3OFxyc2lkNTA1OTczNVxyc2lkNTIwNTk1MVxy c2lkNTU3NjY2N1xyc2lkNjA0MDk5Mlxyc2lkNjYyNzAwNlxyc2lkNjkwNjEyNVxyc2lkNzE1 MDc4OFxyc2lkNzE2OTcyNlxyc2lkNzY3NjI0OVxyc2lkNzk2MjAwOFxyc2lkODAxNjkwN1xy c2lkODE0NzQwOVxyc2lkODI2OTA0MFxyc2lkOTAxMDMyMFxyc2lkOTM3MzE1OA0KXHJzaWQ5 Mzc0NjQ3XHJzaWQ5NTE2NDA1XHJzaWQ5NTI0MjM0XHJzaWQ5NjYzNDM1XHJzaWQxMDEyMTY0 N1xyc2lkMTA1NTUxMThccnNpZDEyMDYwMDgyXHJzaWQxMjczMTE2Nlxyc2lkMTI5MjI0OTlc cnNpZDEyOTg0MTY0XHJzaWQxMzExMjQwOFxyc2lkMTM1MDA0NzhccnNpZDE0MzY0Nzk0XHJz aWQxNDM4NDU3Mlxyc2lkMTQ4MTM0NDNccnNpZDE0OTU5NDAxXHJzaWQxNDk2NzYxNFxyc2lk MTUwMjc1MTlccnNpZDE1MDM0OTg2DQpccnNpZDE1MDkyOTA4XHJzaWQxNTI4NTU2MVxyc2lk MTUzNDExNjZccnNpZDE2MDIxMDEzXHJzaWQxNjIxODg1OFxyc2lkMTY1MzM5NzRccnNpZDE2 NzI1MzExfXtcKlxnZW5lcmF0b3IgTWljcm9zb2Z0IFdvcmQgMTEuMC4wMDAwO317XGluZm97 XG9wZXJhdG9yIHBhcGFkaW1pdHJpb3UgZGltaXRyaX17XGNyZWF0aW1ceXIyMDEwXG1vM1xk eTdcaHIyMVxtaW40fXtccmV2dGltXHlyMjAxMFxtbzNcZHk3XGhyMjFcbWluOH17XHZlcnNp b24zfQ0Ke1xlZG1pbnMxfXtcbm9mcGFnZXM1fXtcbm9md29yZHMyNTIxfXtcbm9mY2hhcnMx MjY1Mn17XG5vZmNoYXJzd3MxNTEzN317XHZlcm4yNDYxM317XCpccGFzc3dvcmQgMDAwMDAw MDB9fXtcKlx4bWxuc3RibCB7XHhtbG5zMSBodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L29mZmljZS93b3JkLzIwMDMvd29yZG1sfX0NClxwYXBlcncxMTkwNlxwYXBlcmgxNjgzOFxt YXJnbDE4MDBcbWFyZ3IxODAwXG1hcmd0MTQ0MFxtYXJnYjE0NDBcZ3V0dGVyMFxsdHJzZWN0 IA0KXHdpZG93Y3RybFxmdG5ialxhZW5kZG9jXGRvbm90ZW1iZWRzeXNmb250MVxkb25vdGVt YmVkbGluZ2RhdGEwXGdyZmRvY2V2ZW50czBcdmFsaWRhdGV4bWwxXHNob3dwbGFjZWhvbGR0 ZXh0MFxpZ25vcmVtaXhlZGNvbnRlbnQwXHNhdmVpbnZhbGlkeG1sMFxzaG93eG1sZXJyb3Jz MVxub3hsYXR0b3llblxleHBzaHJ0blxub3VsdHJsc3BjXGRudGJsbnNiZGJcbm9zcGFjZWZv cnVsXGZvcm1zaGFkZVxob3J6ZG9jXGRnbWFyZ2luXGRnaHNwYWNlMTgwDQpcZGd2c3BhY2Ux ODBcZGdob3JpZ2luMTgwMFxkZ3ZvcmlnaW4xNDQwXGRnaHNob3cxXGRndnNob3cxXGpleHBh bmRcdmlld2tpbmQxXHZpZXdzY2FsZTEwMFxwZ2JyZHJoZWFkXHBnYnJkcmZvb3Rcbm9sbmh0 YWRqdGJsXG5vamtlcm5wdW5jdFxyc2lkcm9vdDE1MDkyOTA4IFxmZXQwe1wqXHdncmZmbXRm aWx0ZXIgMDEzZn1caWxmb21hY2F0Y2xudXAwXGx0cnBhciBcc2VjdGQgXGx0cnNlY3QNClxs aW5leDBcaGVhZGVyeTcwOFxmb290ZXJ5NzA4XGNvbHN4NzA4XGVuZG5oZXJlXHNlY3RsaW5l Z3JpZDM2MFxzZWN0ZGVmYXVsdGNsXHNmdG5iaiB7XCpccG5zZWNsdmwxXHBudWNybVxwbnN0 YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGEgLn19e1wqXHBuc2VjbHZsMlxwbnVj bHRyXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBuaGFuZyB7XHBudHh0YSAufX17XCpccG5zZWNs dmwzXHBuZGVjXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBuaGFuZw0Ke1xwbnR4dGEgLn19e1wq XHBuc2VjbHZsNFxwbmxjbHRyXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBuaGFuZyB7XHBudHh0 YSApfX17XCpccG5zZWNsdmw1XHBuZGVjXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBuaGFuZyB7 XHBudHh0YiAofXtccG50eHRhICl9fXtcKlxwbnNlY2x2bDZccG5sY2x0clxwbnN0YXJ0MVxw bmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGIgKH17XHBudHh0YSApfX17XCpccG5zZWNsdmw3 DQpccG5sY3JtXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBuaGFuZyB7XHBudHh0YiAofXtccG50 eHRhICl9fXtcKlxwbnNlY2x2bDhccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhh bmcge1xwbnR4dGIgKH17XHBudHh0YSApfX17XCpccG5zZWNsdmw5XHBubGNybVxwbnN0YXJ0 MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGIgKH17XHBudHh0YSApfX1ccGFyZFxwbGFp biBcbHRycGFyXHMxNlxxbCBcbGkwXHJpMFx3aWRjdGxwYXINClx0eDkxNlx0eDE4MzJcdHgy NzQ4XHR4MzY2NFx0eDQ1ODBcdHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4OTE2MFx0 eDEwMDc2XHR4MTA5OTJcdHgxMTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3cmFwZGVm YXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFw MFxwYXJhcnNpZDEyNzMxMTY2IFxydGxjaFxmY3MxIFxhZjJcYWZzMjBcYWxhbmcxMDI1IFxs dHJjaFxmY3MwIA0KXGYyXGZzMjBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAx MDMzXGxhbmdmZW5wMTAzMyB7XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGlu c3JzaWQxMzExMjQwOCBTZWN0aW9uIDI6DQpccGFyIA0KXHBhciB9XHBhcmQgXGx0cnBhclxz MTZccWogXGxpMFxyaTBcd2lkY3RscGFyXHR4OTE2XHR4MTgzMlx0eDI3NDhcdHgzNjY0XHR4 NDU4MFx0eDU0OTZcdHg2NDEyXHR4NzMyOFx0eDgyNDRcdHg5MTYwXHR4MTAwNzZcdHgxMDk5 Mlx0eDExOTA4XHR4MTI4MjRcdHgxMzc0MFx0eDE0NjU2XHdyYXBkZWZhdWx0XGFzcGFscGhh XGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkOTAx MDMyMCB7XHJ0bGNoXGZjczEgXGFmMiANClxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEyNzMx MTY2IFNlY3Rpb24gMiBzdGF0ZXMgXCc5M2dyZWF0bHkgaW1wcm92aW5nIGFnZ3JlZ2F0aW9u IGFuZCByZWR1Y2luZyB0aGUgbnVtYmVyIG9mIGdsb2JhbGx5LXZpc2libGUsIHJvdXRhYmxl IHByZWZpeGVzLlwnOTQgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5z cnNpZDEwNTU1MTE4IElmIGFnZ3JlZ2F0aW9uIGlzIHBlcmNlaXZlZCBhcyByZXNvbHZpbmcg c2NhfXsNClxydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkOTAxMDMy MCBsYWJpbGl0eSBvZiByb3V0aW5nIGluIHRlcm1zIG1lbX17XHJ0bGNoXGZjczEgXGFmMiBc bHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNDgxMzQ0MyBvcnkgfXtccnRsY2hcZmNzMSBcYWYy IFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDkwMTAzMjAgDQpzaXplIHRoZW4gb25lIHNob3Vs ZCBhbHNvIGJlIHJlYWR5IHRvIGFzc3VtZSB0aGF0IHJvdXRpbmcgd2lsbCByZXN1bHQgaW4g aGlnaGVyIHN0cmV0Y2ggZHVlIHRvIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIEludGVy bmV0IHRvcG9sb2d5LiAgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5z cnNpZDEyNzMxMTY2IA0KXHBhciB9XHBhcmQgXGx0cnBhclxzMTZccWogXGxpMFxyaTBcd2lk Y3RscGFyXHR4OTE2XHR4MTgzMlx0eDI3NDhcdHgzNjY0XHR4NDU4MFx0eDU0OTZcdHg2NDEy XHR4NzMyOFx0eDgyNDRcdHg5MTYwXHR4MTAwNzZcdHgxMDk5Mlx0eDExOTA4XHR4MTI4MjRc dHgxMzc0MFx0eDE0NjU2XHdyYXBkZWZhdWx0XGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRq dXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkNzE1MDc4OCB7XHJ0bGNoXGZjczEg XGFmMiANClxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEyNzMxMTY2IA0KXHBhciB9e1xydGxj aFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTYwMjEwMTMgU2VjdGlvbiAy fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE1MDkyOTA4ICBz dGF0ZXMgXCc5M01vcmUgY29zdC1lZmZlY3RpdmUgbXVsdGl9e1xydGxjaFxmY3MxIFxhZjIg XGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTQ4MTM0NDMgLX17XHJ0bGNoXGZjczEgXGFmMiBc bHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNTA5MjkwOCANCmhvbWluZ1wnOTQgYnV0IGl0IGlz IG5vdCBzdGF0ZWQgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNp ZDE2MDIxMDEzIHdoYXQgaXMgYWN0dWFsbHkgbWVhbnQgYnkgdGhpcyBzdGF0ZW1lbnQgYW5k IHdoeSB0aGUgTG9jL0lEIHNjaGVtZSBhcyBwcm9wb3NlZCB3b3VsZCBtYWtlIG11bHRpLWhv bWluZyBjb3N0LWVmZmVjdGl2ZS59e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNm MVxpbnNyc2lkMTUwOTI5MDggDQoNClxwYXIgDQpccGFyIH17XHJ0bGNoXGZjczEgXGFmMiBc bHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNjAyMTAxMyBTZWN0aW9uIDIgc3RhdGVzIFwnOTNN b2JpbGl0eSB3aXRob3V0IGFkZHJlc3MgY2hhbmdpbmdcJzk0IGJ1dCB0aGVuIFwnOTNcJzg1 IG9yIGFjcXVpcmluZyBhIG5ldyBhZGRyZXNzIGJhc2VkIG9uIHRoZSBuZXcgbmV0d29yayBs b2NhdGlvbi5cJzk0IFRoZXNlIHN0YXRlbWVudHMgYXJlIGNvbnRyYWRpY3RpbmcgZWFjaCBv dGhlci4NClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNp ZDE1MDkyOTA4IA0KXHBhciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxp bnNyc2lkMTYwMjEwMTMgU2VjdGlvbiAyIHN0YXRlcyBcJzkzfXtccnRsY2hcZmNzMSBcYWYy IFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE2MDIxMDEzXGNoYXJyc2lkMTYwMjEwMTMgVGhp cyBkcmFmdCBkZXNjcmliZXMgcHJvdG9jb2wgbWV9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNo XGZjczAgXGNmMVxpbnNyc2lkMTYwMjEwMTMgDQpjaGFuaXNtcyB0byBhY2hpZXZlIHRoZSBk ZXNpcmVkIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNjAy MTAxM1xjaGFycnNpZDE2MDIxMDEzIGZ1bmN0aW9uYWwgc2VwYXJhdGlvbi59e1xydGxjaFxm Y3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTYwMjEwMTMgXCc5NCBCdXR9e1xy dGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTI3MzExNjYgIHNlcGFy YXRpb259ew0KXHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNjAy MTAxMyAgYmV0d2VlbiB3aGljaCBmdW5jdGlvbnMgP317XHJ0bGNoXGZjczEgXGFmMiBcbHRy Y2hcZmNzMCBcY2YxXGluc3JzaWQ3MTUwNzg4ICB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNo XGZjczAgXGNmMVxpbnNyc2lkNjA0MDk5MiANCklmIHRoaXMgc3RhdGVtZW50IGlzIHJlbGF0 ZWQgdG8gdGhlIHNlcGFyYXRpb24gYmV0d2VlbiBmb3J3YXJkaW5nIGFuZCBjb250cm9sL3Jv dXRpbmcsIHRoZW4gaXQgaXMgZGVmZWF0ZWQgbG9va2luZyBhdCBpKSB0aGUgd2F5IFJMT0Mg cmVhY2hhYmlsaXR5IHRlc3RpbmcgaW50ZXItdHdpbiBjb250cm9sIGFzIHBhcnQgb2YgdGhl IGZvcndhcmRpbmcgcGxhbmUsIGFuZCBpaSkgdGhlIHVzZSBvZiBcJzkzRGF0YSBQcm9iZXNc Jzk0DQogZm9yd2FyZGluZyBkYXRlIGFzIHBhcnQgb2YgdGhlIGNvbnRyb2wgcGxhbmUgb2Yg VFJccnF1b3RlIHMuIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3Jz aWQxNjAyMTAxMyANClxwYXIgfVxwYXJkIFxsdHJwYXJcczE2XHFqIFxsaTBccmkwXHdpZGN0 bHBhclx0eDkxNlx0eDE4MzJcdHgyNzQ4XHR4MzY2NFx0eDQ1ODBcdHg1NDk2XHR4NjQxMlx0 eDczMjhcdHg4MjQ0XHR4OTE2MFx0eDEwMDc2XHR4MTA5OTJcdHgxMTkwOFx0eDEyODI0XHR4 MTM3NDBcdHgxNDY1Nlx3cmFwZGVmYXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVz dHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDE1MDM0OTg2IHtccnRsY2hcZmNzMSAN ClxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTYwMjEwMTMgDQpccGFyIH1ccGFyZCBc bHRycGFyXHMxNlxxaiBcbGkwXHJpMFx3aWRjdGxwYXJcdHg5MTZcdHgxODMyXHR4Mjc0OFx0 eDM2NjRcdHg0NTgwXHR4NTQ5Nlx0eDY0MTJcdHg3MzI4XHR4ODI0NFx0eDkxNjBcdHgxMDA3 Nlx0eDEwOTkyXHR4MTE5MDhcdHgxMjgyNFx0eDEzNzQwXHR4MTQ2NTZcd3JhcGRlZmF1bHRc YXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFy YXJzaWQ3MTUwNzg4IHtccnRsY2hcZmNzMSBcYWYyIA0KXGx0cmNoXGZjczAgXGNmMVxpbnNy c2lkMTYwMjEwMTMgU2VjdGlvbiAyIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBc Y2YxXGluc3JzaWQ0MDcyNDUwIHRoZSBzdGF0ZW1lbnR9e1xydGxjaFxmY3MxIFxhZjIgXGx0 cmNoXGZjczAgXGNmMVxpbnNyc2lkMTYwMjEwMTMgIFwnOTNUaGlzIGRyYWZ0IGF0dGVtcHRz IHRvIG5vdCANCmNvbXBldGUgb3Igb3ZlcmxhcCB3aXRoIHN1Y2ggc29sdXRpb25zIGFuZCB0 aGUgcHJvcG9zZWQgcHJvdG9jb2wgY2hhbmdlcyBhcmUgZXhwZWN0ZWQgdG8gY29tcGxlbWVu dCBhIGhvc3QtYmFzZWQgbWVjaGFuaXNtIHdoZW4gVHJhZmZpYyBFbmdpbmVlcmluZyBmdW5j dGlvbmFsaXR5IGlzIGRlc2lyZWQuXCc5NCB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZj czAgXGNmMVxpbnNyc2lkNDA3MjQ1MCByfXtccnRsY2hcZmNzMSBcYWYyIA0KXGx0cmNoXGZj czAgXGNmMVxpbnNyc2lkMTYwMjEwMTMgYWlzZXMgdGhlIHF1ZXN0aW9uIGlmIHRoZXNlIHNv bHV0aW9ucyB3b3VsZCBzdGlsbCBiZSBjb21wbGVtZW50YXJ5IGlmIFRFIGZ1bmN0aW9uYWxp dHkgaXMgbm90IGRlc2lyZWR9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxp bnNyc2lkNjA0MDk5MiAgKHRoaXMgaXMgbm90IGNsZWFybHkgc3RhdGVkIGluIHRoZSBkb2N1 bWVudCl9e1xydGxjaFxmY3MxIFxhZjIgDQpcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNjAy MTAxMyAufXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE1MDM0 OTg2ICBPbiB0aGUgb3RoZXIgaGFuZH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBc Y2YxXGluc3JzaWQ0MDcyNDUwICx9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNm MVxpbnNyc2lkMTUwMzQ5ODYgIHRoZSBzdGF0ZW1lbnQgXCc5Mw0KQnVpbGRpbmcgdGhlIHNv bHV0aW9uIGludG8gdGhlIG5ldHdvcmsgd2lsbCBmYWNpbGl0YXRlIGluY3JlbWVudGFsIGRl cGxveW1lbnQgb2YgdGhlIHRlY2hub2xvZ3kgb24gdGhlIEludGVybmV0LlwnOTQgfXtccnRs Y2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDQwNzI0NTAgc317XHJ0bGNo XGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNTAzNDk4NiBob3VsZCBiZX17 XHJ0bGNoXGZjczEgXGFmMiANClxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDQwNzI0NTAgIGZ1 cnRoZXJ9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNzE2OTcy NiAgZGV2ZWxvcGVkIHRvIGV4cGxhaW4gd317XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNz MCBcY2YxXGluc3JzaWQxNTAzNDk4NiBoeSBcJzkzbmV0d29yayBkZXBsb3ltZW50XCc5NCBp cyBjb25zaWRlcmVkIGFzIGZhY2lsaXRhdGluZyBpbmNyZW1lbnRhbCBkZXBsb3ltZW50ID99 ew0KXHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNjAyMTAxM1xj aGFycnNpZDE2MDIxMDEzIA0KXHBhciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAg XGNmMVxpbnNyc2lkMTYwMjEwMTMgDQpccGFyIFNlY3Rpb24gMiBzdGF0ZXMgXCc5M1NvbWUg b2YgdGhlIGRlc2lnbiBnb2FscyBvZiB0aGlzIHByb3Bvc2FsIGluY2x1ZGU6XCc5NA0KXHBh ciB9XHBhcmQgXGx0cnBhclxzMTZccWogXGxpMFxyaTBcd2lkY3RscGFyXHR4OTE2XHR4MTgz Mlx0eDI3NDhcdHgzNjY0XHR4NDU4MFx0eDU0OTZcdHg2NDEyXHR4NzMyOFx0eDgyNDRcdHg5 MTYwXHR4MTAwNzZcdHgxMDk5Mlx0eDExOTA4XHR4MTI4MjRcdHgxMzc0MFx0eDE0NjU2XHdy YXBkZWZhdWx0XGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4w XGl0YXAwXHBhcmFyc2lkOTUxNjQwNSB7XHJ0bGNoXGZjczEgXGFmMiANClxsdHJjaFxmY3Mw IFxjZjFcaW5zcnNpZDE2MDIxMDEzIFdoaWNoIGFyZSB0aGUgb3RoZXIgZ29hbHMgPyB0aGVy ZSBpcyBvbmx5IHBhcnRpYWwgbWF0Y2ggd2l0aCB0aGUgZGVzaWduIGdvYWxzIHNwZWNpZmll ZCBhdCBSUkd9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNzE1 MDc4OCAgKHRoZSB0ZXJtIFwnOTNkZXNpZ24gZ29hbFwnOTQgc2VlbXMgdG8gaGF2ZSBhIGRp ZmZlcmVudCBtZWFuaW5nKX17DQpccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFc aW5zcnNpZDEyNzMxMTY2ICBhbmQgaXQgaXMgdW5jbGVhciB3aGF0IGNoYW5nZXMgYXJlIHJl ZmVycmluZyB0b317XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQx NjAyMTAxMyAuIFRoZSBzdGF0ZW1lbnQgXCc5M01pbmltaXplIHJlcXVpcmVkIGNoYW5nZXMg dG8gSW50ZXJuZXQgaW5mcmFzdHJ1Y3R1cmUuXCc5NCB9e1xydGxjaFxmY3MxIFxhZjIgDQpc bHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ3MTUwNzg4IGlzIHZhZ3VlLiBUaGUgc3RhdGVtZW50 IFwnOTNtb3N0IGN1c3RvbWVyIHNpdGUgcm91dGVyc1wnOTQgdW5kZXIgd2hpY2ggY29uZGl0 aW9uIHRoZSByZW1haW5pbmcgZnJhY3Rpb24gd291bGQgaGF2ZSB0byBjaGFuZ2UuDQpccGFy IA0KXHBhciBTZWN0aW9uIDIgc3RhdGVzIFwnOTM3LiAgQXZvaWQgb3IgbWluaW1pemUgcGFj a2V0IGxvc3Mgd2hlbiBFSUQtdG8tUkxPQyBtYXBwaW5ncyBuZWVkIHRvIGJlIHBlcmZvcm1l ZC5cJzk0IFRoaXMgY29uZGl0aW9uIGlzIG5vdCBhZGRyZXNzZWQgYnkgdGhlIHByZXNlbnQg cHJvcG9zYWwgYXMgdGhlIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGlu c3JzaWQ3MTUwNzg4XGNoYXJyc2lkNzE1MDc4OCANCklUUnMgZHJvcCB0aGUgcGFja2V0KHMp IH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ3MTUwNzg4IGZv ciB3aGljaCB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNzE1 MDc4OFxjaGFycnNpZDcxNTA3ODggdGhleSBoYXZlIG5vIH17XHJ0bGNoXGZjczEgXGFmMiBc bHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ3MTUwNzg4IEVJRC10by1STE9DIH17XHJ0bGNoXGZj czEgXGFmMiANClxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDcxNTA3ODhcY2hhcnJzaWQ3MTUw Nzg4IG1hcHBpbmcgZm9yfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5z cnNpZDY2MjcwMDYgICh9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNy c2lkMTg0MzQzMyBhcyBsb25nIGFzIHJlc3BvbnNlIHRvIE1hcCBSZXF1ZXN0IGlzIG5vdCBy ZWNlaXZlZCBhbmQgUkxPQyByZWFjaGFiaWxpdHkgXCc5M3Rlc3RlZFwnOTQpfXsNClxydGxj aFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNzE1MDc4OFxjaGFycnNpZDcx NTA3ODggLg0KXHBhciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNy c2lkNzE1MDc4OCANClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFc aW5zcnNpZDEyNzMxMTY2IFNlY3Rpb24gMiBkZXNjcmliZXMgTElTUCB2YXJpYW50cyBkZXBl bmRpbmcgb24gRUlEIFwnOTNyb3V0YWJpbGl0eVwnOTQgaXQgd291bGQgYmUgYXBwcm9wcmlh dGUgdG8gc3RhdGUgXCc5M3JvdXRhYmlsaXR5XCc5NCByZWZlcnMgdG8gdGhlIGNvcmV9e1xy dGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMjYzNDk0MiANCiBpLmUu IGJldHdlZW4gSVRSL0VUUn17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGlu c3JzaWQxMjczMTE2NiAgKGFzIEVJRCByZW1haW4gcm91dGFibGUgaW4gXCc5M3NpdGVzXCc5 NH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQyNjM0OTQyICBv dGhlcndpc2UgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSB3aXRoIGhvc3QtYmFzZWQgc29sdXRp b25zKX17XHJ0bGNoXGZjczEgXGFmMiANClxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEyNzMx MTY2IA0KXHBhciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lk MjYzNDk0MiANClxwYXIgU2VjdGlvbiAyLiBMSVNQIDEuNSBpcyBhc3N1bWVkIHRvIG1ha2Ug dXNlIG9mIGEgXCc5M3NlcGFyYXRlIHRvcG9sb2d5XCc5NCB9e1xydGxjaFxmY3MxIFxhZjIg XGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNjYyNzAwNiBhbHNvIHJlZmVycmVkfXtccnRsY2hc ZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE1MDM0OTg2ICB0byBhcyBcJzkz YWx0ZXJuYXRpdmUgdG9wb2xvZ3lcJzk0LiBUfXtccnRsY2hcZmNzMSBcYWYyIA0KXGx0cmNo XGZjczAgXGNmMVxpbnNyc2lkNjYyNzAwNiBoZSB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNo XGZjczAgXGNmMVxpbnNyc2lkMTUwMzQ5ODYga2V5IH17XHJ0bGNoXGZjczEgXGFmMiBcbHRy Y2hcZmNzMCBcY2YxXGluc3JzaWQ2NjI3MDA2IHF1ZXN0aW9uIGlzIHdoYXQgaXMgdGhpc317 XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQyNjM0OTQyICB0b3Bv bG9neSA/DQpccGFyIA0KXHBhciBTZWN0aW9uIDIuIExJU1AgMyBhc3N1bWVzIHRoZSBleGlz fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEzMTEyNDA4IA0K dGVuY2Ugb2YgRUlELXRvLVJMT0MgZGF0YWJhc2UuIEhvdyB0aGUgZXhpc3RlbmNlIG9mIHRo ZSBkYXRhYmFzZXMgaXMgbWFkZSBhd2FyZSB0byBJVFIuIFRoaXMgaXMgd2hhdCBkZXRlcm1p bmVzIHRoZSB1c2Ugb2YgRGF0YSBwcm9iZXMgdnMgTWFwIHJlcXVlc3RzIGlmIGJvdGggbW9k ZXMgYXJlIHN1cHBvcnRlZC59e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxp bnNyc2lkMjYzNDk0MiANClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxj ZjFcaW5zcnNpZDYwNDA5OTIgDQpccGFyIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNz MCBcY2YxXGluc3JzaWQxMzExMjQwOCBTZWN0aW9uIDM6DQpccGFyIA0KXHBhciB9e1xydGxj aFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMjYzNDk0MiBTZWN0aW9uIDMu fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE1MDkyOTA4XGNo YXJyc2lkMTUwOTI5MDggIFRoZSBkZWZpbml0aW9uIG9mIFByb3ZpZGVyIEluZGVwZW5kZW50 IChQSSkgQWRkcmVzc2VzIHN9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxp bnNyc2lkMTYwMjEwMTMgdGF0ZXMgfXsNClxydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAg XGNmMVxpbnNyc2lkMTUwOTI5MDhcY2hhcnJzaWQxNTA5MjkwOCB3aGF0fXtccnRsY2hcZmNz MSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE2MDIxMDEzICBhIFBJIH17XHJ0bGNo XGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNTA5MjkwOFxjaGFycnNpZDE1 MDkyOTA4IGlzIG5vdCB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgDQpcY2YxXGlu c3JzaWQxNjAyMTAxMyBpbnN0ZWFkIG9mIGRlZmluaW5nIHdoYXQgYX17XHJ0bGNoXGZjczEg XGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNTA5MjkwOFxjaGFycnNpZDE1MDkyOTA4 ICBQSSB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTYwMjEw MTMgaXMufXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDI4Mjc0 NzkgDQogQWxzbyB0aGUgZG9jdW1lbnQgcmVmZXJzIHRvIEVJRCBwcmVmaXhlcyBhbmQgRUlE IFwnOTNibG9ja3NcJzk0IHdoYXQgaXMgYSBcJzkzYmxvY2tcJzk0IGFuZCBhIFwnOTNzdWIt YmxvY2tcJzk0P317XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQx NTA5MjkwOFxjaGFycnNpZDE1MDkyOTA4ICANClxwYXIgDQpccGFyIH1ccGFyZCBcbHRycGFy XHMxNlxxaiBcbGkwXHJpMFx3aWRjdGxwYXJcdHg5MTZcdHgxODMyXHR4Mjc0OFx0eDM2NjRc dHg0NTgwXHR4NTQ5Nlx0eDY0MTJcdHg3MzI4XHR4ODI0NFx0eDkxNjBcdHgxMDA3Nlx0eDEw OTkyXHR4MTE5MDhcdHgxMjgyNFx0eDEzNzQwXHR4MTQ2NTZcd3JhcGRlZmF1bHRcYXNwYWxw aGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQx MjczMTE2NiB7XHJ0bGNoXGZjczEgDQpcYWYyIFxsdHJjaFxmY3MwIFxpbnNyc2lkMTUwOTI5 MDhcY2hhcnJzaWQxNTA5MjkwOCBTZWN0aW9uIDMuIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRy Y2hcZmNzMCBcaW5zcnNpZDI2MzQ5NDIgRGVmaW5pdGlvbiBvZiBQQSBcJzkzfXtccnRsY2hc ZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxpbnNyc2lkMTUwOTI5MDhcY2hhcnJzaWQxNTA5Mjkw OCBMSVNQIHVzDQplcyBvbmx5IHRvcG9sb2dpY2FsbHktYXNzaWduZWQgYW5kIGFnZ3JlZ2F0 YWJsZSBhZGRyZXNzIGJsb2NrcyBmb3IgUkxPQ3MsIGVsaW1pbmF0aW5nIHRoaXMgZGVtb317 XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcaW5zcnNpZDEyNzMxMTY2IG5zdHJhYmx5 IG5vbi1zY2FsYWJsZSBwcmFjdGljZX17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBc aW5zcnNpZDI2MzQ5NDIgXCc5NH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCANClxp bnNyc2lkMTI3MzExNjYgLiBQfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxpbnNy c2lkMTUwOTI5MDhcY2hhcnJzaWQxNTA5MjkwOCByb3ZpZGUgYSByZWZlcmVuY2UgfXtccnRs Y2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxpbnNyc2lkNjYyNzAwNiBvZn17XHJ0bGNoXGZj czEgXGFmMiBcbHRyY2hcZmNzMCBcaW5zcnNpZDE1MDkyOTA4XGNoYXJyc2lkMTUwOTI5MDgg IHN1Y2ggZGVtb25zdHJhdGlvbn17XHJ0bGNoXGZjczEgDQpcYWYyIFxsdHJjaFxmY3MwIFxp bnNyc2lkNjYyNzAwNiAufXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5z cnNpZDU1NzY2NjdcY2hhcnJzaWQxMjczMTE2NiANClxwYXIgfVxwYXJkXHBsYWluIFxsdHJw YXJccWogXGxpMFxyaTBcd2lkY3RscGFyXHdyYXBkZWZhdWx0XGFzcGFscGhhXGFzcG51bVxm YWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkOTUxNjQwNSBccnRs Y2hcZmNzMSBcYWYwXGFmczI0XGFsYW5nMTAyNSBcbHRyY2hcZmNzMCBcZjM3XGZzMjJcbGFu ZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XHJ0bGNo XGZjczEgXGFmMlxhZnMyMCANClxsdHJjaFxmY3MwIFxmMlxmczIwXGluc3JzaWQxNTA5Mjkw OFxjaGFycnNpZDE1MDkyOTA4IA0KXHBhciBTZWN0aW9uIDMuIElUUi9FVFIgYXJlIGRlc2Ny aWJlZCBhcyByb3V0ZXJzIHdoaWxlIHRoZXkgYXJlIGFjdHVhbGx5IGZ1bmN0aW9uc317XHJ0 bGNoXGZjczEgXGFmMlxhZnMyMCBcbHRyY2hcZmNzMCBcZjJcZnMyMFxpbnNyc2lkMTI3MzEx NjYgLiBEfXtccnRsY2hcZmNzMSBcYWYyXGFmczIwIFxsdHJjaFxmY3MwIFxmMlxmczIwXGlu c3JzaWQxNTA5MjkwOCBlc2NyaWJlIHRoZW0gYXMgZnVuY3Rpb25zIGluc3RlYWQgb2YgXCc5 M3JvdXRlcnMNClwnOTR9e1xydGxjaFxmY3MxIFxhZjJcYWZzMjAgXGx0cmNoXGZjczAgXGYy XGZzMjBcaW5zcnNpZDY2MjcwMDYgLn17XHJ0bGNoXGZjczEgXGFmMlxhZnMyMCBcbHRyY2hc ZmNzMCBcZjJcZnMyMFxpbnNyc2lkMjYzNDk0MiAgfXtccnRsY2hcZmNzMSBcYWYyXGFmczIw IFxsdHJjaFxmY3MwIFxmMlxmczIwXGluc3JzaWQ2NjI3MDA2IA0KXHBhciANClxwYXIgU2Vj dGlvbiAzLiBEZWZpbml0aW9uIG9mIFJMT0Mgc2VlbXMgdG8gYmUgbGltaXRlZCB0byBFVFIu IFRodXMgaG93IElUUiBzZXQgdGhlIFNvdXJjZSBSTE9DID99e1xydGxjaFxmY3MxIFxhZjJc YWZzMjAgXGx0cmNoXGZjczAgXGYyXGZzMjBcaW5zcnNpZDQ5MTkzMzkgDQogU2VjdGlvbiA3 ICh0aGlyZCBidWxsZXQpIG1ha2VzIHRoaXMgYXNzaWdubWVudCBldmVuIGxlc3MgdW5kZXJz dGFuZGFibGUgKHRoZSB3ZWxsLWRlZmluZWQgY29uY2VwdCBvZiBWUkYgc3VkZGVubHkgYXBw ZWFycykufXtccnRsY2hcZmNzMSBcYWYyXGFmczIwIFxsdHJjaFxmY3MwIFxmMlxmczIwXGlu c3JzaWQxNTA5MjkwOCANClxwYXIgDQpccGFyIH1ccGFyZFxwbGFpbiBcbHRycGFyXHMxNlxx aiBcbGkwXHJpMFx3aWRjdGxwYXJcdHg5MTZcdHgxODMyXHR4Mjc0OFx0eDM2NjRcdHg0NTgw XHR4NTQ5Nlx0eDY0MTJcdHg3MzI4XHR4ODI0NFx0eDkxNjBcdHgxMDA3Nlx0eDEwOTkyXHR4 MTE5MDhcdHgxMjgyNFx0eDEzNzQwXHR4MTQ2NTZcd3JhcGRlZmF1bHRcYXNwYWxwaGFcYXNw bnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQ5NTE2NDA1 IFxydGxjaFxmY3MxIA0KXGFmMlxhZnMyMFxhbGFuZzEwMjUgXGx0cmNoXGZjczAgXGYyXGZz MjBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7 XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcaW5zcnNpZDE1MDkyOTA4IFNlY3Rpb24g My4gVmFsaWRhdGlvbiBvZiBcJzkzfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxj ZjFcaW5zcnNpZDE1MDkyOTA4IEVJRC10by1STE9DIG1hcHBpbmdzXCc5NCB9ew0KXHJ0bGNo XGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ2NjI3MDA2IGluIGNhY2hlIH17 XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNTA5MjkwOCBpcyBk ZWZpbmVkIGFzIHRpbWUtYmFzZWQgb25seSB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZj czAgXGNmMVxpbnNyc2lkNjYyNzAwNiA/IG5vdCBvbiBmcmVxdWVuY3kgb2YgdXNhZ2UgbmVp dGhlciByZXBsYWNlbWVudCA/fXtccnRsY2hcZmNzMSANClxhZjIgXGx0cmNoXGZjczAgXGNm MVxpbnNyc2lkMTUwOTI5MDggDQpccGFyIH1ccGFyZCBcbHRycGFyXHMxNlxxaiBcbGkwXHJp MFx3aWRjdGxwYXJcdHg5MTZcdHgxODMyXHR4Mjc0OFx0eDM2NjRcdHg0NTgwXHR4NTQ5Nlx0 eDY0MTJcdHg3MzI4XHR4ODI0NFx0eDkxNjBcdHgxMDA3Nlx0eDEwOTkyXHR4MTE5MDhcdHgx MjgyNFx0eDEzNzQwXHR4MTQ2NTZcd3JhcGRlZmF1bHRcYXNwYWxwaGFcYXNwbnVtXGZhYXV0 b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQxNDQ2NDIxIHtccnRsY2hc ZmNzMSBcYWYyIA0KXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNjYyNzAwNiANClxwYXIgU2Vj dGlvbiAzLiBUaGUgbW9zdCBpbXBvcnRhbnQgZGVmaW5pdGlvbiBcJzkzRUlELXRvLVJMT0Mg bWFwcGluZyBsb29rdXBcJzk0IGlzIG1pc3NpbmcufXtccnRsY2hcZmNzMSBcYWYyIFxsdHJj aFxmY3MwIFxjZjFcaW5zcnNpZDY5MDYxMjUgIEluIHBhcnRpY3VsYXIsIGhvdyBhIElUUiBr bm93cyB0aGF0IHRoZSBcJzkzaW5jb21pbmdcJzk0IGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMg fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIA0KXGNmMVxpbnNyc2lkMTUyODU1NjEg cGFydCBvZiB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNjkw NjEyNSBhbiBFSUQgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNp ZDE1Mjg1NTYxIHByZWZpeCB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxp bnNyc2lkNjkwNjEyNSA/IE1vcmUgZ2VuZXJhbGx5IHdofXtccnRsY2hcZmNzMSBcYWYyIFxs dHJjaFxmY3MwIA0KXGNmMVxpbnNyc2lkMTUyODU1NjEgaWNoIGV2ZW50IG9yIGNvbmRpdGlv biB0cmlnZ2VycyBzdWNoIGxvb2t1cCA/fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3Mw IFxjZjFcaW5zcnNpZDY2MjcwMDYgDQpccGFyIA0KXHBhciB9e1xydGxjaFxmY3MxIFxhZjIg XGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkOTM3NDY0NyBTZWN0aW9uIDQ6DQpccGFyIA0KXHBh ciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTUwMzQ5ODYg U2VjdGlvbiA0IHN0YXRlcyBcJzkzRW5kLXN5c3RlbXMgKGhvc3RzKSBvbmx5IHNlbmQgdG8g YWRkcmVzc2VzIHdoaWNoIGFyZSBFSURzLiBUaGV5IGRvbid0IGtub3cgYWRkcmVzc2VzIGFy ZSBFSURzIHZlcnN1cyBSTE9DcyBidXQgYXNzdW1lIHBhY2tldHMgZ2V0IHRvIExJU1Agcm91 dGVycyx9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgDQpcY2YxXGluc3JzaWQ4MDE2 OTA3IFwnODVcJzk0fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNp ZDE1MDM0OTg2IA0KXHBhciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxp bnNyc2lkODAxNjkwNyANClxwYXIgU2VjdGlvbiA0IFwnOTNhbiBFSUQgaXMgb25seSByb3V0 YWJsZSB3aXRoaW4gdGhlIHNjb3BlIG9mIGEgc2l0ZVwnOTQgd2hhdCBpcyB0aGUgc2NvcGUg b2YgYSBzaXRlID8gIA0KXHBhciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNm MVxpbnNyc2lkMTUwMzQ5ODYgDQpccGFyIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNz MCBcY2YxXGluc3JzaWQ4MDE2OTA3IFNlY3Rpb24gNCBcJzkzVGhpcyBzcGVjaWZpY2F0aW9u IG1hbmRhdGVzIHRoYXQgbm8gbW9yZSB0aGFuIHR3byBMSVNQIGhlYWRlcnMgZ2V0IHByZXBl bmRlZCB0byBhIHBhY2tldC5cJzk0DQogSXMgdGhlcmUgYW55IG1lY2hhbmlzbSBwcmV2ZW50 aW5nIElUUiAob3IgVEUgSVRSKSB0byBwZXJmb3JtIGFkZGl0aW9uYWwgcHJlcGVuZGluZyA/ IGFuZCBhdCB3aGljaCBjb3N0ID8NClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxm Y3MwIFxjZjFcaW5zcnNpZDY2MjcwMDYgDQpccGFyIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRy Y2hcZmNzMCBcY2YxXGluc3JzaWQ0OTE5MzM5IFNlY3Rpb24gNCBsYXN0IHBhcmFncmFwaCBv ZiBwMTMsIHJlZmVycyB0byBTZWN0aW9uIDggfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxm Y3MwIFxjZjFcaW5zcnNpZDEzMTEyNDA4IGNvbmNlcm5pbmcgfXtccnRsY2hcZmNzMSBcYWYy IFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDQ5MTkzMzkgXCc5M2ZsZXhpYmxlXCc5NCBwbGFj ZW1lbnQgb2YgVFINClxycXVvdGUgc317XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBc Y2YxXGluc3JzaWQxMzExMjQwOCAgYnV0IGRvZXMgbm90IHJlc3BvbmQgdG8gdGhlIHF1ZXN0 aW9uIGlzIHRoZXJlIGEgZGVwbG95bWVudCBzY2VuYXJpbyB0aGF0IHdvdWxkIG5vdCBiZSBz dXBwb3J0ZWQufXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDQ5 MTkzMzkgDQpccGFyIA0KXHBhciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNm MVxpbnNyc2lkNjkwNjEyNSBTZWN0aW9uIDQuMSBzdGF0ZXMgXCc5M0FuZCB0aGUgRGF0YSBQ cm9iZXMgYXJlIHNlbnQgb24gdGhlIHVuZGVybHlpbmcgdG9wb2xvZ3kgKHRoZSBMSVNQIDEu MCB2YXJpYW50KSBidXQgY291bGQgYWxzbyBiZSBzZW50IG92ZXIgYW4gYWx0ZXJuYXRpdmUg dG9wb2xvZ3kgKHRoZSBMSVNQIDEuNSB2YXJpYW50KSBhcyBpdCB3b3VsZCBpbiBbQUxUXS5c Jzk0DQogYnV0IGluIFNlY3Rpb24gMiBkb2VzIHJlZmVyIHRvIFtBTFRdIGluIExJU1AgMyBj b250ZXh0ID8NClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5z cnNpZDcxNjk3MjYgDQpccGFyIH1ccGFyZCBcbHRycGFyXHMxNlxxaiBcbGkwXHJpMFx3aWRj dGxwYXJcdHg5MTZcdHgxODMyXHR4Mjc0OFx0eDM2NjRcdHg0NTgwXHR4NTQ5Nlx0eDY0MTJc dHg3MzI4XHR4ODI0NFx0eDkxNjBcdHgxMDA3Nlx0eDEwOTkyXHR4MTE5MDhcdHgxMjgyNFx0 eDEzNzQwXHR4MTQ2NTZcd3JhcGRlZmF1bHRcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1 c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQ0OTE5MzM5IHtccnRsY2hcZmNzMSBc YWYyIA0KXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNzE2OTcyNiBTZWN0aW9uIDQuMSBwb2lu dCAyfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEyOTIyNDk5 ICAoc2FtZSByZW1hcmsgYXBwbGllcyB0byBTZWN0aW9uIDYpfXtccnRsY2hcZmNzMSBcYWYy IFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDcxNjk3MjYgIG1pc3NlcyBhbiBpbXBvcnRhbnQg fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIA0KXGNmMVxpbnNyc2lkMTQ0NjQyMSBh c3BlY3QgaG93IHRoZSBtYXBwaW5nIGlzIHBlcmZvcm1lZCB0aGUgZmlyc3QgdGltZSBhIG5l dyBkZXN0aW5hdGlvbiBFSUQgaXMgc2VlbiBhdCBJVFIgYW5kIGhvdyBzdWJzZXF1ZW50IG1h cHMgYXJlIHBlcmZvcm1lZC4gSXQgc2VlbXMgdGhhdCBhKSBFSUQtdG8tUkxPQyBDYWNoZSBt dXN0IGJlIGZpcnN0IH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3Jz aWQ1MjA1OTUxIA0KZW50aXJlbHkgc2Nhbm5lZCBmb3IgZWFjaCBpbmNvbWluZyBwYWNrZXQg YXQgSVRSIChub3Qgb25seSB0aGUgZmlyc3Qgb25lKSBhbmQgdGgNCmVuIGlmIHRoZXJlIGlz IG5vIGVudHJ5IGkpIERhdGEgcHJvYmUgaS5lLiBjb3B5IHRoZSBkZXN0aW5hdGlvbiBFSUQg dmFsdWUgaW4gdGhlIGRlc3RpbmF0aW9uIFJMT0MgZmllbGQgKGZvciBMSVNQIDEuNSkgb3Ig aWkpIG9yaWdpbmF0ZSBhIE1hcCBSZXF1ZXN0OyBvdGhlcndpc2UgdXNlIHRoZSBjb3JyZXNw b25kaW5nIFJMT0MgdmFsdWUgaW4gdGhlIHJldHJpZXZlZCBlbnRyeSBhcyBkZXN0aW5hdGlv biBSTE9DLiBOZWVkbGVzcyB0byBzYXkgdA0KaGF0IHRoZSBkZWxheSBpcyBwcm9wb3J0aW9u YWwgdG8gdGhlIG51bWJlciBvZiBlbnRyaWVzIGluIHRoZSBjYWNoZS4gTm90aGluZyBpcyBi ZWluZyBzYWlkIGlmIHRoZSBjYWNoZSBpcyBmdWxsICh3aGljaCBlbnRyeSBzaH17XHJ0bGNo XGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ4MTQ3NDA5IG91bGR9e1xydGxj aFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNTIwNTk1MSAgYmUgcmVwbGFj ZWR9ew0KXHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ4MTQ3NDA5 ICBpLmUuIHRoZSBsZWFzdCBmcmVxdWVudGx5IHVzZWQsIHRoZSBsZWFzdCByZWNlbnRseSB1 c2VkLCBvciB0aGUgbGVhc3QgcmVjZW50bHkgcmVwbGFjZWQgZW50cnl9e1xydGxjaFxmY3Mx IFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNTIwNTk1MSApLn17XHJ0bGNoXGZjczEg XGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ4MTQ3NDA5IA0KIE5vdGhpbmcgaXMgc2Fp ZCB3aGF0IGhhcHBlbnMgaWYgYSBtb3JlIGFjY3VyYXRlIEVJRCBwcmVmaXggaXMgYmVpbmcg bWFkZSBhdmFpbGFibGUgd2hlbiBhIGxlc3MgRUlEIHByZWZpeCBpcyBiZWluZyBpbiB1c2Ug Zm9yIGEgc2V0IG9mIG9uZSBvciBtb3JlIFJMT0NzLn17XHJ0bGNoXGZjczEgXGFmMiBcbHRy Y2hcZmNzMCBcY2YxXGluc3JzaWQxMjkyMjQ5OSANClxwYXIgDQpccGFyIH1ccGFyZCBcbHRy cGFyXHMxNlxxaiBcbGkwXHJpMFx3aWRjdGxwYXJcdHg5MTZcdHgxODMyXHR4Mjc0OFx0eDM2 NjRcdHg0NTgwXHR4NTQ5Nlx0eDY0MTJcdHg3MzI4XHR4ODI0NFx0eDkxNjBcdHgxMDA3Nlx0 eDEwOTkyXHR4MTE5MDhcdHgxMjgyNFx0eDEzNzQwXHR4MTQ2NTZcd3JhcGRlZmF1bHRcYXNw YWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJz aWQyODI3NDc5IHtccnRsY2hcZmNzMSBcYWYyIA0KXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lk ODE0NzQwOSBTZWN0aW9uIDQuMSBwb2ludCAzIHN0YXRlcyBcJzkzVGhlIHJvdXRlciBpcyBj b25maWd1cmVkIHRvICJwdW50IiB0aGUgcGFja2V0IHRvIHRoZSByb3V0ZXIncyBwcm9jZXNz b3IuIFNlZSBTZWN0aW9uIDcgZm9yIG1vcmUgZGV0YWlscy5cJzk0IExvb2tpbmcgYXQgU2Vj dGlvbiA3IHRoZXJlIGlzIG5vIGRlZmluaXRpb24gb2YgXCc5M3B1bnRpbmcgcGFja2V0c1wn OTR9ew0KXHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ0OTE5MzM5 IC59e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTIwNjAwODIg IH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ4MTQ3NDA5IA0K XHBhciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNDkxOTMz OSANClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEz NTAwNDc4IFNlY3Rpb24gNC4xIHBvaW50IDQgc3RhdGVzIH17XHJ0bGNoXGZjczEgXGFmMiBc bHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxMjA2MDA4MiBcJzkzfXtccnRsY2hcZmNzMSBcYWYy IFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEzNTAwNDc4IA0KVGhlIExJU1AgaGVhZGVyIGlz IHN0cmlwcGVkIHNvIHRoYXQgdGhlIHBhY2tldCBjYW4gYmUgZm9yd2FyZGVkIGJ5IHRoZSBy b3V0ZXIgY29udHJvbCBwbGFuZS5cJzk0IFwnODUgZm9yd2FyZGluZyB9e1xydGxjaFxmY3Mx IFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTIwNjAwODIgdHJhZmZpYyBieSB9e1xy dGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMjgyNzQ3OSByb3V0aW5n IH17XHJ0bGNoXGZjczEgXGFmMiANClxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEyMDYwMDgy IGNvbnRyb2wgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDI4 Mjc0NzkgZW5naW5lc317XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3Jz aWQxMjA2MDA4MiAgcmVzdWx0IGluIG1ham9yIGRyYXdiYWNrcyBzdWNoIGFzIGF0dGFja3Ms IGludHJ1c2lvbnMsIGV0Yy59e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgDQpcY2Yx XGluc3JzaWQxMzUwMDQ3OCAgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFc aW5zcnNpZDEyMDYwMDgyIGlmIHRoZSB2YWx1ZSBlbmNvZGVkIGluIHRoZSBkZXN0aW5hdGlv biBFSUQgaXMgb25lIG9mIHRoZSByb3V0ZXJzIGFkZHJlc3Nlcy59e1xydGxjaFxmY3MxIFxh ZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTM1MDA0NzggDQpccGFyIH17XHJ0bGNoXGZj czEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQyODI3NDc5IA0KXHBhciBTZWN0aW9u IDQuMSBwb2ludCA0IHN1cHBvc2VkbHkgaWYgdGhlcmUgdGhlIGRlc3RpbmF0aW9uIEVJRCBp cyBub3QgZm91bmQgaW4gdGhlIEVUUidzIEVJRC10by1STE9DIGRhdGFiYXNlIHRoZSBwYWNr ZXQgZ2UNCnRzIGRyb3BwZWQgPyBPbiB0aGUgb3RoZXIgaGFuZCBob3cgdG8gcHJldmVudCB0 aGF0IGEgTWFwIFJlcGx5IGlzIHNlbnQgaW4gcmVzcG9uc2UgZm9yIEVJRCBwcmVmaXggbm90 IHJlYWNoYWJsZSBidXQgc3RhdGljYWxseSBjb25maWd1cmVkIGluIHRoZSBFVFIncyBFSUQt dG8tUkxPQyBkYXRhYmFzZS59e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxp bnNyc2lkOTY2MzQzNSANCiBUaGUgY2FzZSBvZiBFVFIgcmVzcG9uZGluZyB3aXRoIFwnOTNj b2Fyc2VyIEVJRC1STE9DXCc5NCBtYXBwaW5nIGR1ZSBlLmcuIHRvIHN1Yi1zZWdtZW50YXRp b24gaXMgcGFydGlhbGx5IGFkZHJlc3NlZCBpbiBTZWN0aW9uIDYuMS41LjEgfXtccnRsY2hc ZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDI4Mjc0NzkgDQpccGFyICANClxw YXIgfVxwYXJkIFxsdHJwYXJcczE2XHFqIFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4 MzJcdHgyNzQ4XHR4MzY2NFx0eDQ1ODBcdHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4 OTE2MFx0eDEwMDc2XHR4MTA5OTJcdHgxMTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3 cmFwZGVmYXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGlu MFxpdGFwMFxwYXJhcnNpZDMyMTk2OTUge1xydGxjaFxmY3MxIFxhZjIgDQpcbHRyY2hcZmNz MCBcY2YxXGluc3JzaWQyODI3NDc5IFNlY3Rpb24gNC4xIG9uIFwnOTNnbGVhbmVkIG1hcHBp bmdcJzk0IHN0YXRlcyBcJzkzTW9yZSBjb21wbGV0ZSBpbmZvcm1hdGlvbiBhYm91dCBhZGRp dGlvbmFsIFJMT0NzIFNIT1VMRCBiZSB2ZXJpZmllZCBieSBzZW5kaW5nIGEgTElTUCBNYXAt UmVxdWVzdCBmb3IgdGhhdCBFSUQuXCc5NCBCdXQgdGhlcmUgaXMgbm8gZGV0YWlsIG9uIHdo YXQgaGFwcGVucyBpbiBjYXNlIG9mIG1pDQpzbWF0Y2ggYmV0d2VlbiB0aGUgXCc5M2dsZWFu ZWQgbWFwcGluZ317XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQx ODQzNDMzIFwnOTQgYW5kIHRoZSByZXN1bHQgb2YgTWFwLVJlcXVlc3QgKGZ1cnRoZXIgZGV0 YWlscyBhcmUgcHJvdmlkZWQgaW4gU2VjdGlvbiA2LjIgbGFzdCBidWxsZXQgYnV0IGl0IGRv ZXMgbm90IHJlc3BvbmQgdG8gdGhlIHF1ZXN0aW9uIG9mIG1pc21hdGNoKS59e1xydGxjaFxm Y3MxIFxhZjIgDQpcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQyODI3NDc5IA0KXHBhciB9e1xy dGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkOTY2MzQzNSANClxwYXIg fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDMyODEwMDQgU2Vj dGlvbiA1Og0KXHBhciANClxwYXIgU2VjdGlvbiA1LjMgc2V0cyB0aGUgbm9uY2Ugc3BhY2Ug dG8gMl4yNCBidXQgZG9lcyBub3QgZXhwbGFpbiB0aGUgc3BhY2Ugb2YgYXBwbGljYWJpbGl0 eSBvZiB0aGlzIGZpZWxkIGFzIHJlYWRpbmcgZ29lcyB0aGlzIHZhbHVlIGlzIGxpbWl0aW5n IHRoZSBudW1iZXIgb2YgYmktZGlyZWN0aW9uYWwgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIFRS XHJxdW90ZSBzIHRvIHRoaXMgbnVtYmVyLg0KXHBhciANClxwYXIgfXtccnRsY2hcZmNzMSBc YWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDkzNzQ2NDcgU2VjdGlvbiA2Og0KXHBhciAN ClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE4NDM0 MzMgU2VjdGlvbiA2LjEuMyBkb2VzIG5vdCBleHBsYWluIHRoZSByZXN1bHQgb2YgcmVmcmVz aCBmb3Igd2hpY2ggdGhlIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGlu c3JzaWQzMjE5Njk1IHJlY2VpdmVkfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxj ZjFcaW5zcnNpZDE4NDM0MzMgIEVJRCBibG9jayB9e1xydGxjaFxmY3MxIA0KXGFmMiBcbHRy Y2hcZmNzMCBcY2YxXGluc3JzaWQzMjE5Njk1IHdvdWxkIGJlIGxhcmdlciB0aGFuIHRoZSBy ZXF1ZXN0ZWQgb25lLiBTZWN0aW9uIDYuMS41IGFzc3VtZXMgdGhhdCBhIFwnOTN0aGF0IGEg TWFwLVJlcGx5IG1heSBjb250YWluIGRpZmZlcmVudCBFSUQtcHJlZml4IGdyYW51bGFyaXR5 IChwcmVmaXggKyBsZW5ndGgpIHRoYW4gdGhlIE1hcC1SZXF1ZXN0IHdoaWNoIHRyaWdnZXJz IGl0LlwnOTQgQnV0IGl0IGRvZXNuXHJxdW90ZSANCnQgc2F5IGlmIHRoZSBhc3NvY2lhdGVk fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE1MzQxMTY2ICBS TE9DIHNoYWxsIGJlIGlkZW50aWNhbCBvciBub3QgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJj aFxmY3MwIFxjZjFcaW5zcnNpZDMyMTk2OTUgP317XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hc ZmNzMCBcY2YxXGluc3JzaWQxNTM0MTE2NiAgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxm Y3MwIA0KXGNmMVxpbnNyc2lkMzIxOTY5NSANClxwYXIgfVxwYXJkIFxsdHJwYXJcczE2XHFq IFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4MzJcdHgyNzQ4XHR4MzY2NFx0eDQ1ODBc dHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4OTE2MFx0eDEwMDc2XHR4MTA5OTJcdHgx MTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3cmFwZGVmYXVsdFxhc3BhbHBoYVxhc3Bu dW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDE1MzQxMTY2 IHtccnRsY2hcZmNzMSANClxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTg0MzQzMyAN ClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEwMTIx NjQ3IFNlY3Rpb24gNi4xLjQgc3RhdGVzIFwnOTN9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNo XGZjczAgXGNmMVxpbnNyc2lkMTUzNDExNjYgUjogd2hlbiB0aGlzIGJpdCBpcyBzZXQsIHRo ZSBsb2NhdG9yIGlzIGtub3duIHRvIGJlIHJlYWNoYWJsZSBmcm9tIHRoZSBNYXAtUmVwbHkg c2VuZGVyJ3MgcGVyc3BlY3RpdmUuXCc5NA0KIENhbiBhdXRob3IgZXhwbGFpbiBob3cgYSBy ZWNlaXZlciBjYW4gdGVzdCBpdHMgcmVhY2hhYmlsaXR5IGkuZS4gd2hhdCBpcyB0aGUgZGVj aXNpb24gY3JpdGVyaWEgdG8gc2V0IHRoZSBSIGJpdCA/IA0KXHBhciANClxwYXIgfVxwYXJk IFxsdHJwYXJcczE2XHFqIFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4MzJcdHgyNzQ4 XHR4MzY2NFx0eDQ1ODBcdHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4OTE2MFx0eDEw MDc2XHR4MTA5OTJcdHgxMTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3cmFwZGVmYXVs dFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxw YXJhcnNpZDMyMTk2OTUge1xydGxjaFxmY3MxIFxhZjIgDQpcbHRyY2hcZmNzMCBcY2YxXGlu c3JzaWQ5NjYzNDM1IFNlY3Rpb24gNi4xLjUgd2hlcmUgaXMgdGhlIFwnOTNEYXRhIFByb2Jl IHBhY2tldFwnOTQgZm9ybWF0IGRlZmluZWQgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxm Y3MwIFxjZjFcaW5zcnNpZDE4NDM0MzMgYWN0dWFsbHkgfXtccnRsY2hcZmNzMSBcYWYyIFxs dHJjaFxmY3MwIFxjZjFcaW5zcnNpZDk2NjM0MzUgPw0KXHBhciANClxwYXIgfVxwYXJkIFxs dHJwYXJcczE2XHFqIFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4MzJcdHgyNzQ4XHR4 MzY2NFx0eDQ1ODBcdHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4OTE2MFx0eDEwMDc2 XHR4MTA5OTJcdHgxMTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3cmFwZGVmYXVsdFxh c3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJh cnNpZDE1MzQxMTY2IHtccnRsY2hcZmNzMSANClxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNy c2lkOTY2MzQzNSBTZWN0aW9uIDYuMS41IHN0YXRlcyBcJzkzVGhlIFJMT0NzIGluIHRoZSBN YXAtUmVwbHkgYXJlIHRoZSBnbG9iYWxseS1yb3V0YWJsZSBJUCBhZGRyZXNzZXMgb2YgdGhl IEVUUiBidXQgYXJlIG5vdCBuZWNlc3NhcmlseSByZWFjaGFibGU7IHNlcGFyYXRlIHRlc3Rp bmcgb2YgcmVhY2hhYmlsaXR5IGlzIHJlcXVpcmVkLlwnOTQgfXtccnRsY2hcZmNzMSBcYWYy IFxsdHJjaFxmY3MwIA0KXGNmMVxpbnNyc2lkNDM1MzYzOCBTZWN0aW9uIH17XHJ0bGNoXGZj czEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ5NjYzNDM1IDYuM317XHJ0bGNoXGZj czEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ0MzUzNjM4ICBkb2UNCnMgbm90IGRl ZmluZSBhbnkgcHJvY2VkdXJlIGFjdHVhbGx5IGFuZCBkb2VzIG5vdCBkZWZpbmUgYW55IGNy aXRlcmlhIGZvciBkZWNpZGluZyB3aGVuIHRoZSBSTE9DIGlzIHJlYWNoYWJsZSBvciBub3Qu IFRoZSBrZXkgcXVlc3Rpb24gaXMgaWYgdGhlIElUUiBwZXJzaXN0cyBpbiB0ZXN0aW5nIHJl YWNoYWJpbGl0eSBhbmQgdGhlcmUgaXMgbm8gY3JpdGVyaWEgcHJvY2VzcyBieSB3aGljaCBz dWNoIGRlY2lzaW9uIHdvdWxkIHN0b3AsIHRoZSB0cg0KYWZmaWMgd291bGQgYmUgZm9yd2Fy ZGVkIGJ5IG1lYW5zIG9mIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGlu c3JzaWQxNDk2NzYxNCB0aGUgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFc aW5zcnNpZDQzNTM2MzggXCc5M3NlcGFyYX17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNz MCBcY2YxXGluc3JzaWQzNzY0MTg3IHR9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAg DQpcY2YxXGluc3JzaWQ0MzUzNjM4IGV9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAg XGNmMVxpbnNyc2lkMTQ5Njc2MTQgL2FsdGVybmF0aXZlfXtccnRsY2hcZmNzMSBcYWYyIFxs dHJjaFxmY3MwIFxjZjFcaW5zcnNpZDQzNTM2MzggIHRvcG9sb2d5XCc5NCBmb3JldmVyLn17 XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQyODI3NDc5IA0KXHBh ciB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTUzNDExNjYg DQpccGFyIFNlY3Rpb24gNi4yIGludHJvZHVjZXMgdGhlIHRlcm1zIGNsaWVudC1zaWRlIGFu ZCBzZXJ2ZXItc2lkZSB3aGVyZSBhcmUgdGhlc2UgdGVybXMgZGVmaW5lZCA/fXtccnRsY2hc ZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDkzNzQ2NDcgIHdpdGhvdXQgc3Vj aCBkZWZpbml0aW9uIHJlYWRhYmlsaXR5IG9mIHRoZSBzZWN0aW9uIGlzIGxvdy59e1xydGxj aFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTUzNDExNjYgDQoNClxwYXIg DQpccGFyIFNlY3Rpb24gNi4yIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2Yx XGluc3JzaWQxMDEyMTY0NyBSTE9DIHJlYWNoYWJpbGl0eSBjYW4gZGV0ZXJtaW5lZCBhbmQg c2VsZWN0ZWQgYnV0IHRoZXJlIGlzIG5vIGRlc2NyaXB0aW9uIG9uIGhvdyB0aGUgRUlELXRv LVJMT0Mgc2VsZWN0aW9uIGlzIHBlcmZvcm1lZC59e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNo XGZjczAgXGNmMVxpbnNyc2lkMTUzNDExNjYgDQpccGFyIH17XHJ0bGNoXGZjczEgXGFmMiBc bHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNTAyNzUxOSANClxwYXIgfVxwYXJkIFxsdHJwYXJc czE2XHFqIFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4MzJcdHgyNzQ4XHR4MzY2NFx0 eDQ1ODBcdHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4OTE2MFx0eDEwMDc2XHR4MTA5 OTJcdHgxMTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3cmFwZGVmYXVsdFxhc3BhbHBo YVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDEw MTIxNjQ3IHtccnRsY2hcZmNzMSANClxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTUw Mjc1MTkgU2VjdGlvbiA2LjMgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFc aW5zcnNpZDkzNzQ2NDcgcHJvcG9zZXN9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAg XGNmMVxpbnNyc2lkMTAxMjE2NDcgIFwnOTNlbmNhcHN1bGF0ZWQgdHJhZmZpY317XHJ0bGNo XGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ2MDQwOTkyIFwnOTR9e1xydGxj aFxmY3MxIA0KXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxMDEyMTY0NyAgfXtccnRs Y2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDkzNzQ2NDcgYmFzZWQgfXtc cnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE1MDI3NTE5IHB9e1xy dGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTAxMjE2NDcgcm9jZWR1 cmVzIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCANClxjZjFcaW5zcnNpZDYwNDA5 OTIgdGh1cywgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEw MTIxNjQ3IGlmIHRoZXJlIGlzIG5vIHRyYWZmaWMgdGhlcmUgaXMgbm8gfXtccnRsY2hcZmNz MSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDYwNDA5OTIgUkxPQyByZWFjaGFiaWxp dHkgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEwMTIxNjQ3 IFwnOTN0ZXN0XCc5NCBwb3NzaWJsDQplLiB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZj czAgXGNmMVxpbnNyc2lkOTM3NDY0NyBPbiB0aGUgb3RoZXIgaGFuZCwgdGhhdCBzZWN0aW9u IHN0YXRlcyBjZXJ0YWluIFwnOTNJQ01QIGV4Y2hhbmdlc1wnOTQgYXJlIGRvY3VtZW50ZWQg YnV0IHJlYWNoYWJpbGl0eSBvZiBSTE9DIGRvZXMgbm90IG1lYW4gYXZhaWxhYmlsaXR5IG9m IHRoZSBhc3NvY2lhdGVkIEVJRC4gVGhlcmUgbm8gYWN0dWFsIFwnOTNFSUQtdG8tUkxPQ1wn OTQNCiB0ZXN0aW5nIHByb2NlZHVyZSBiZWluZyBkZWZpbmVkIGluIHRoZSBkb2N1bWVudD8N ClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDQ5ODQ4 NzggDQpccGFyIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQx MDEyMTY0NyBXaGF0IGlzIHN0cnVnZ2xpbmcgaGVyZSBpcyB0aGF0IHRoZSBcJzkzaW50cm9k dWN0b3J5XCc5NCBzZWN0aW9uc317XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2Yx XGluc3JzaWQ5Mzc0NjQ3ICBvZiB0aGUgZG9jdW1lbnR9e1xydGxjaFxmY3MxIFxhZjIgXGx0 cmNoXGZjczAgXGNmMVxpbnNyc2lkMTAxMjE2NDcgIHJlZmVyIHRvIFwnOTMNCmZ1bmN0aW9u YWxcJzk0IHNlcGFyYXRpb25zIGJ1dCBhbGwgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxm Y3MwIFxjZjFcaW5zcnNpZDkzNzQ2NDcgdGhlIHRlY2huaXF1ZXMgZGVzY3JpYmVkIGluIHRo aXMgZG9jdW1lbnQgKGFuZCBmb3IgUkxPQyByZWFjaGFiaWxpdHkgdGVzdGluZyBpbiBwYXJ0 aWN1bGFyKX17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxMDEy MTY0NyAgcmVzdWx0IGluIGEgfXsNClxydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNm MVxpbnNyc2lkOTM3NDY0NyBjb21wbGV4IGludGVyLXR3aW59e1xydGxjaFxmY3MxIFxhZjIg XGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTAxMjE2NDcgIGJldHdlZW4gY29udHJvbCBtZXNz YWdpbmcgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDkzNzQ2 NDcgYXMgcGFydCBvZiB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgDQpcY2YxXGlu c3JzaWQxMDEyMTY0NyB0aGUgZm9yd2FyZGluZyBwbGFuZSBhbmQgZm9yd2FyZGluZyBkYXRl IH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ5Mzc0NjQ3IGFz IHBhcnQgb2Z9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTAx MjE2NDcgIHRoZSBjb250cm9sIHBsYW5lfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3Mw IFxjZjFcaW5zcnNpZDkzNzQ2NDcgDQogb2Ygcm91dGVycy4gVGhlIGxhdHRlciBpcyB0eXBp Y2FsIGZyb20gRGF0YSBQcm9iZXMgcHJvY2Vzc2luZ317XHJ0bGNoXGZjczEgXGFmMiBcbHRy Y2hcZmNzMCBcY2YxXGluc3JzaWQxMDEyMTY0NyAuIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRy Y2hcZmNzMCBcY2YxXGluc3JzaWQ5Mzc0NjQ3IA0KSWYgdGhpcyBpcyB0aGUgZGVzaWduIGNo b2ljZSBvZiBMSVNQIHNvIGxldCBpdCBiZSBidXQgMSkgcGxlYXNlIHByb29mIGl0IG9mZmVy cyBhbnkgYmV0dGVyIGZ1bmN0aW9uYWxpdHkgY29tcGFyZWQgdG8gXCc5M2N1cnJlbnRcJzk0 DQogZGVzaWduIGFuZCAyKSBiZXR0ZXIgY29zdC9wZXJmb3JtYW5jZS4gSXQgaXMgZmFyIGZy b20gb2J2aW91cyB0aGF0IHRoZSBjb21wbGV4aXR5IGNvbmNlbnRyYXRlZCBhdCBUUiB0YWtp bmcgaW50byB0aGUgcHJvcG9zZWQgZGVzaWduIG9mZmVycyBhbnkgcmVhbCBjb21wZWxsaW5n IGFyZ3VtZW50LiBUaGlzIG1heSBhbHNvIGRlZmVhdCB0aGUgYXJndW1lbnQgc3RhdGVkIGlu IHRoZSBpbnRyb2R1Y3Rpb24gdGhhdCBcJzkzbmV0d29yayBkZXBsDQpveW1lbnRcJzk0IGlz IGZhY2lsaXRhdGVkIGJ5IG5ldHdvcmstYmFzZWQgc29sdXRpb25zLg0KXHBhciB9e1xydGxj aFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTAxMjE2NDcgDQpccGFyIH17 XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ5Mzc0NjQ3IFNlY3Rp b24gNi4zIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxMDEy MTY0NyBQfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE1MDI3 NTE5IG9pbnQgMSB3aGF0IGlzIHRoZSB1c2Ugb2YgdGhlIFwnOTNMb2MtU3RhdHVzLUJpdHNc Jzk0DQogaWYgdGhlcmUgaXMgbm8gcmV0dXJuIHRyYWZmaWMgKG9yIG1vcmUgcHJlY2lzZWx5 IG5vIHJldHVybiB0cmFmZmljIHBhc3NpbmcgdmlhIHRoaXMgRVRSIGkuZS4gdGhlIEVUUiBp cyBub3QgYW4gSVRSIGZvciB0aGUgc291cmNlIFJMT0MtRUlEIHBhaXIpLiBUaGUgRVRSIG1h eSBwcm9jZXNzIHRoaXMgaW5mb3JtYXRpb24gYnV0IG5ldmVyIHVzZSBpdC4NClxwYXIgfXtc cnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDI4Mjc0NzkgDQpccGFy IH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxMDEyMTY0NyBT ZWN0aW9uIDYuMyBzdGF0ZXMgXCc5M0VhY2ggSVRSIGNhbiB0aHVzIG9ic2VydmUgdGhlIHBy ZXNlbmNlIG9yIGxhY2sgb2YgYSBkZWZhdWx0IHJvdXRlIG9yaWdpbmF0ZWQgYnkgdGhlIG90 aGVycyB0byBkZXRlcm1pbmUgdGhlIExvY2F0b3IgU3RhdHVzIEJpdHMgaXQgc2V0cyBmb3Ig dGhlbS5cJzk0IFRoaXMgZG9lcyBub3QgdGVsbCB3aGljaCB0ZWNobg0KaXF1ZSB0byB1c2Ug d2hlbiBubyBkZWZhdWx0IHJvdXRlIGFyZSB1c2VkIGF0IGFsbCAodW5kZXIgXCc5M25vbi1u b3JtYWxcJzk0IGNpcmN1bXN0YW5jZXMgXCc4NSB3aGF0IHNob3VsZCBkZWZpbmUgbm9ybWFs aXR5IGluIHRoaXMgY29udGV4dCkuDQpccGFyIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hc ZmNzMCBcY2YxXGluc3JzaWQxNTI4NTU2MSANClxwYXIgfVxwYXJkIFxsdHJwYXJcczE2XHFq IFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4MzJcdHgyNzQ4XHR4MzY2NFx0eDQ1ODBc dHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4OTE2MFx0eDEwMDc2XHR4MTA5OTJcdHgx MTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3cmFwZGVmYXVsdFxhc3BhbHBoYVxhc3Bu dW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDQ5ODQ4Nzgg e1xydGxjaFxmY3MxIFxhZjIgDQpcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQzMjgxMDA0IFNl Y3Rpb24gNi4zLjEgc3RhdGVzIFwnOTNUaGlzIG1lY2hhbmlzbSBkb2VzIG5vdCBjb21wbGV0 ZWx5IHNvbHZlIHRoZSBmb3J3YXJkIHBhdGggcmVhY2hhYmlsaXR5IHByb2JsZW0gYXMgdHJh ZmZpYyBtYXkgYmUgdW5pZGlyZWN0aW9uYWwuXCc5NCBUaGUgZm9yd2FyZGluZyBwYXRoIG1h eSBzaW1wbHkgYmUgYXN5bW1ldHJpYyAodGhlcmUgaXMgbm90aGluZyB0aGF0IGltcG9zfXsN ClxydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNDk4NDg3OCBlcyBy ZXZlcnNlIHBhdGggcmVhY2hpbmcgdGhlIHNvdXJjZSBSTE9DIH17XHJ0bGNoXGZjczEgXGFm MiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQzMjgxMDA0IGluIGNhc2Ugb2YgZHVhbCBhdHRh Y2hlZCBzaXRlcykufXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNp ZDQ5ODQ4NzggDQogVGhpcyBzaG9ydGNvbWluZyBkZWZlYXRzIHRoaXMgbWVjaGFuaXNtIGFz IGFuIElUUiBpcyBub3QgXCc5M2F3YXJlXCc5NCBvZiBpdHMgbmVpZ2hib3JpbmcgSVRSIEVJ RC10by1STE9DIG1hcHBpbmdzIChjb25uZWN0ZWQgdG8gdGhlIHNhbWUgc2l0ZSkuIFRoaXMg bWVjaGFuaXNtIGNhbiBvbmx5IGJlIHNhZmVseSB1c2VkIGlmIHRoZSBSTE9DIHBhaXIgYmV0 d2VlbiB0d28gc2l0ZXMgaXMgdW5pcXVlIGFuZCByZW1haW5zIHVuaXF1ZS59ew0KXHJ0bGNo XGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQzMjgxMDA0IA0KXHBhciB9e1xy dGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNDk4NDg3OCANClxwYXIg fVxwYXJkIFxsdHJwYXJcczE2XHFqIFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4MzJc dHgyNzQ4XHR4MzY2NFx0eDQ1ODBcdHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4OTE2 MFx0eDEwMDc2XHR4MTA5OTJcdHgxMTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3cmFw ZGVmYXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxp dGFwMFxwYXJhcnNpZDEyOTIyNDk5IHtccnRsY2hcZmNzMSANClxhZjIgXGx0cmNoXGZjczAg XGNmMVxpbnNyc2lkNDk4NDg3OCBTZWN0aW9uIDYuMy4yIH17XHJ0bGNoXGZjczEgXGFmMiBc bHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxMjkyMjQ5OSBSTE9DIFByb2JpbmcgYnkgbWVhbnMg b2YgdGhlIFwnOTNjb250cm9sIHBsYW5lXCc5NCB0aGlzIG9wZW5zIHRoZSBxdWVzdGlvbiBv ZiB3aGF0IGlzIGFjdHVhbGx5IHByb2JlZCB0aGUgXCc5M1JMT0NcJzk0IG9yfXtccnRsY2hc ZmNzMSBcYWYyIFxsdHJjaFxmY3MwIA0KXGNmMVxpbnNyc2lkNDk4NDg3OCAgfXtccnRsY2hc ZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEyOTIyNDk5IHRoZSBFSUQtdG8t UkxPQyBlbnRyaWVzIG9mIHRoZSBFVFJccnF1b3RlIHMgZGF0YWJhc2UuIFRoZSBkaWZmZXJl bmNlIHN0ZW1zIGJlY2F1c2UgdGhlIGxhdHRlciBhcmUgc3RhdGljIGVudHJpZXMgdGhlIGxp dmVuZXNzIG9mIHRoZSBmb3JtZXIgYXJlIGRlDQpwZW5kZW50IG9uIHRoZSBpbmNvbWluZyBp bnRlcmZhY2UgbGl2ZW5lc3MuIFRoYXQgaXMgZW50cmllcyBjYW4gYmUgYXZhaWxhYmxlIGlu IHRoZSBkYXRhYmFzZSBidXQgaWYgZGF0YWJhc2UgZW50cmllcyBhcmUgbm90IGluIHN5bmMg d2l0aCB0aGUgYWN0dWFsIFJMT0Mgc3RhdHVzIHRoZXJlIGlzIG5vIHBvc3NpYmlsaXR5IHRv IGRldGVjdCByZWFjaGFiaWxpdHkgb2YgUkxPQ3MgYnkgbWVhbnMgb2YgdGhpcyBtZWNoYW5p c20ufXsNClxydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMzI4MTAw NCANClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEy OTIyNDk5IA0KXHBhciBTZWN0aW9uIDYuMy4yIHN0YXRlcyBcJzkzUkxPQyBQcm9iaW5nIGNh biBhbHNvIHByb3ZpZGUgUlRUIGVzdGltYXRlcyBiZXR3ZWVuIGEgcGFpciBvZiBsb2NhdG9y cyB3aGljaCBjYW4gYmUgdXNlZnVsIGZvciBuZXR3b3JrIG1hbmFnZW1lbnQgcHVycG9zZXMg YXMgd2VsbCBhcyBmb3Igc2VsZWN0aW5nIGxvdyBkZWxheSBwYXRocy5cJzk0DQogSWYgdGhl IGV4Y2hhbmdlcyBhcmUgcGVyZm9ybWVkIGluIHRoZSBjb250cm9sIHBsYW5lIGl0IGlzIG5v dCBjbGVhciBob3cgc3VjaCBSVFQvZGVsYXkgdmFsdWVzIGNhbiBiZSBkZXJpdmVkIGZvciB0 aGUgZm9yd2FyZGluZyBwYXRoID8gQ2FuIGF1dGhvcnMgZXhwbGFpbiA/IEF1dGhvcnMgc2hv dWxkIGFsc28gY2hlY2sgdGhlIGFjY3VyYWN5IG9mIHRoZSBlc3RpbWF0ZSB2cyBvdmVyaGVh ZCBnZW5lcmF0ZWQgYnkgc3VjaCB0ZWNobmlxdWUuICANCg0KXHBhciB9e1xydGxjaFxmY3Mx IFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkOTEyNjkgDQpccGFyIH1ccGFyZCBcbHRy cGFyXHMxNlxxaiBcbGkwXHJpMFx3aWRjdGxwYXJcdHg5MTZcdHgxODMyXHR4Mjc0OFx0eDM2 NjRcdHg0NTgwXHR4NTQ5Nlx0eDY0MTJcdHg3MzI4XHR4ODI0NFx0eDkxNjBcdHgxMDA3Nlx0 eDEwOTkyXHR4MTE5MDhcdHgxMjgyNFx0eDEzNzQwXHR4MTQ2NTZcd3JhcGRlZmF1bHRcYXNw YWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJz aWQxNDM4NDU3MiB7XHJ0bGNoXGZjczEgDQpcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNp ZDg2NTI0OCBTZWN0aW9uIDYuNX17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2Yx XGluc3JzaWQxNDM4NDU3MiAgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFc aW5zcnNpZDEwNTU1MTE4IHRoZSBzZWN0aW9uIGRvZXMgbm90IGFjdHVhbGx5IGV4cGxhaW4g d2hpY2ggbWVzc2FnZXMgYXJlIHVzZWQgdG8gdQ0KcGRhdGUgdGhlIGxpc3Qgb2YgTG9jLVJl YWNoIG9yIExvYy1TdGF0dXMgYml0cy4gSWYgaXQgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJj aFxmY3MwIFxjZjFcaW5zcnNpZDE0OTU5NDAxIGlzIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRy Y2hcZmNzMCBcY2YxXGluc3JzaWQxMDU1NTExOCBkYXRhIHRyYWZmaWN9e1xydGxjaFxmY3Mx IFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTQ5NTk0MDEgLWRyaXZlbn17XHJ0bGNo XGZjczEgXGFmMiANClxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDEwNTU1MTE4ICB0aGVuIHRo ZSBtZWNoYW5pc20gaXMgYWdhaW4gZGVwZW5kZW50IG9uIHRoZSBzeW1tZXRyeSBvZiB0aGUg cmV2ZXJzZSBwYXRoIGFuZCB0aGUgcGFja2V0IHJhdGUgYnV0IGFsc28gcGFja2V0IGRpZmZl cmVudGlhbCBkZWxheXMgYmV0d2VlbiBwYWNrZXRzLiBJbiB0aGUgbGF0dGVyIGNhc2UsIGl0 IGlzIG5vdCBjbA0KZWFyIGhvdyBJVFIgY291bGQgcmV0cmlldmUgdGhlIGNvcnJlY3QgUkxP Q3MgdG8gYmUgdXNlZCBpZiBhIHNlcXVlbmNlIG9mIDggcGFja2V0cyBzZW50IGZyb20gRVRS IHRvIElUUiBpbmRpY2F0ZXMgMCwwLDAsMCwwLDAsMCwxIGZvciBhIGdpdmVuIFJMT0MgKGlu ZGljYXRlZCBhcyBhdmFpbGFibGUgYXQgYXJyaXZhbCBvZiB0aGUgOH17XHJ0bGNoXGZjczEg XGFmMiBcbHRyY2hcZmNzMCANClxjZjFcc3VwZXJcaW5zcnNpZDEwNTU1MTE4XGNoYXJyc2lk MTA1NTUxMTggdGh9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lk MTA1NTUxMTggIHBhY2tldCkgaXMgcmVjZWl2ZWQgYXMgMSwwLDAsMCwwLDAsMCwwLiBUaGUg c2VjdGlvbiBtYWtlcyBhIGxvbg0KZyBkaWdyZXNzaW9uIG9uIG9yZGVyaW5nIGxvY2F0b3Ig c2V0IHRoaXMgaXMgbm90IHRoZSBpc3N1ZSB3aXRob3V0IGEgc2VxdWVuY2UgbnVtYmVyIGl0 IHdpbGwgbmV2ZXIgYmUgcG9zc2libGUgZm9yIHRoZSByZWNlaXZpbmcgSVRSfXtccnRsY2hc ZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE0OTU5NDAxICB0byBkZXRlcm1p bmUgdGhlIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ4NzEz NyANCmFjdHVhbCB9e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lk MTQ5NTk0MDEgc3RhdGUgb2YgdGhlIEVJRC10by1STE9DIG1hcHBpbmdzIGF0IEVUUnMuIH17 XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQ4NzEzNyBUaGlzIGlz IGV2ZW4gaWYgRVRSIGRvIG5vdCBrZWVwIHRyYWNrIG9mIHdobyByZXF1ZXN0ZWQgbQ0KYXBw aW5ncyB1cG9uIGNvbW11bmljYXRpb24gdGhleSBzaG91bGQgdGVsbCB0aGUgc3RhdGUgb2Yg dGhlaXIgbWFwcGluZyBidXQgYWxzbyB0aGVpciB0cmFuc2l0aW9uLn17XHJ0bGNoXGZjczEg XGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNDM4NDU3MiANClxwYXIgfXtccnRsY2hc ZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDg3MTM3IA0KXHBhciBTZWN0aW9u IDYuNS4yfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDkzNzMx NTggIGlzIHRoaXMgdGVjaG5pcXVlIG1hbmRhdG9yeSBvciBub3QgKHRoaXMgaXMgbm90IHNw ZWNpZmllZCBpbiB0aGUgdGV4dCkuIFBvaX17XHJ0bGNoXGZjczEgXGFmMiBcbHRyY2hcZmNz MCBcY2YxXGluc3JzaWQyMzYzMDA1IA0KbnQgNSByZXN1bHRzIGluIG9idmlvdXMgc2l0dWF0 aW9ucyB3aGVyZSB0aGUgRVRSIG1heSBuZXZlciBzdG9wIHNlbmRpbmcgU01SIG1lc3NhZ2Vz LiBBcyB0aGVyZSBpcyBubyBtZWFucyBhIHdheSB0byBwcmV2ZW50IHRoYXQgSVRSIHVzZSBc Jzkzb2xkIG1hcHBpbmdzXCc5NCB0aGlzIHJlc3VsdCBpbiBhIGRlYWR9e1xydGxjaFxmY3Mx IFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTQ4MTM0NDMgDQpsb2NrIHNpdHVhdGlv biAoYSBub24tY29vcGVyYXRpbmcgSVRSIHByZXZlbnRzIEVUUiB0byBzdG9wIHNlbmRpbmcg U01SIG1lc3NhZ2VzKS4NClxwYXIgDQpccGFyIFNlY3Rpb24gNi41LjIgc3RhdGVzIFwnOTNT byBhbiB4VFIgd2lsbCBzb2xpY2l0IE1hcC1SZXF1ZXN0cyBmcm9tIHNpdGVzIGl0IGlzIGN1 cnJlbnRseSBzZW5kaW5nIGVuY2Fwc3VsYXRlZCBkYXRhIHRvLCBhbmQgb25seSBmcm9tIHRo b3NlIHNpdGVzLlwnOTQgVGh1cyBpbnN0ZWFkIG9mIGtlZXBpbmcgdHJhY2sgb2YgSVRSfXtc cnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE2MjE4ODU4ICwgRVRS fXsNClxydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTQ4MTM0NDMg IGtlZXAgdHJhY2sgb2YgdGhlIGVuY2Fwc3VsYXRlZCB0cmFmZmljIH17XHJ0bGNoXGZjczEg XGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNjIxODg1OCBJVFJ9e1xydGxjaFxmY3Mx IFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTQ4MTM0NDMgIHNlbmQuIH17XHJ0bGNo XGZjczEgXGFmMiBcbHRyY2hcZmNzMCANClxjZjFcaW5zcnNpZDE2MjE4ODU4IFRoZSBtZWNo YW5pc20gaXMgb2Z0ZW4gY2l0ZWQgYnV0IG5ldmVyIGV4cGxhaW5lZCBlLmcuIG92ZXIgd2hp Y2ggdGltZSBwZXJpb2QgaXMgdGhlIEVUUiBleHBlY3RlZCB0byBkZXRlcm1pbmUgdGhlIHNl dCBvZiBjb21tdW5pY2F0aW5nIElUUlxycXVvdGUgcyA/IH17XHJ0bGNoXGZjczEgXGFmMiBc bHRyY2hcZmNzMCBcY2YxXGluc3JzaWQxNDgxMzQ0MyANClxwYXIgfXtccnRsY2hcZmNzMSBc YWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE2MjE4ODU4IA0KXHBhciBTZWN0aW9uIDYu NS4yIHN0YXRlcyBcJzkzTWFwIHJlcXVlc3RcJzk0IHNoYWxsIGJlIHJhdGUgbGltaXRlZCBc Jzg1IHJhdGhlciB1bmNsZWFyOiBhc3N1bWUgYSBzaW5nbGUgRVRSIHNlbmRzIG9uZSBTTVIg bWVzc2FnZSB0byAxMCBkaWZmZXJlbnQgSVRScyBob3cgdGhlIDEwIElUUiB3aWxsIGluZGl2 aWR1YWxseSByYXRlIGxpbWl0IGEgc2luZ2xlIE1hcCBSZXF1ZXN0IGluIHJlc3BvbnNlIHRv IHRoaXMgU01SIG1lc3NhZ2UuIH17DQpccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxj ZjFcaW5zcnNpZDE2NTMzOTc0IEl0IGlzIHRodXMgd29ydGggc3BlY2lmeWluZyB0aGUgZmxv dyBjb250cm9sIG9mIFNNUiBhbmQgTWFwLVJlcXVlc3QgbWVzc2FnZXMgaW4gYSBtb3JlIHN5 c3RlbWF0aWMgd2F5IHRvIHByZXZlbnQgRVRSIG92ZXJsb2Fkcy59e1xydGxjaFxmY3MxIFxh ZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkMTYyMTg4NTggDQpccGFyIH17XHJ0bGNoXGZj czEgXGFmMiBcbHRyY2hcZmNzMCBcY2YxXGluc3JzaWQyMzYzMDA1IA0KXHBhciBTZWN0aW9u IDc6fXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFcaW5zcnNpZDE0ODEzNDQz ICB0aGUgZmlyc3QgcGFyYWdyYXBoIGlzIGEgd2lzaCBub3QgYSBmYWN0LiBBcyBzdWNoIGl0 IGlzIGRvdWJ0ZnVsIHdoYXQgc3VjaCBwYXJhZ3JhcGggYWN0dWFsbHkgYnJpbmdzIGluIHRo ZSBjb250ZXh0IG9mIGEgcHJvdG9jb2wgYXJjaGl0ZWN0dXJlL3NwZWNpZmljYXRpb24ufXtc cnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIA0KXGNmMVxpbnNyc2lkMjM2MzAwNSANClxw YXIgfVxwYXJkIFxsdHJwYXJcczE2XHFsIFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4 MzJcdHgyNzQ4XHR4MzY2NFx0eDQ1ODBcdHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4 OTE2MFx0eDEwMDc2XHR4MTA5OTJcdHgxMTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3 cmFwZGVmYXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGlu MFxpdGFwMFxwYXJhcnNpZDEzNTAwNDc4IHtccnRsY2hcZmNzMSANClxhZjIgXGx0cmNoXGZj czAgXGNmMVxpbnNyc2lkMTAxMjE2NDcgDQpccGFyIH17XHJ0bGNoXGZjczEgXGFmMiBcbHRy Y2hcZmNzMCBcY2YxXGluc3JzaWQyODI3NDc5IFNlY3Rpb24gODoNClxwYXIgfVxwYXJkIFxs dHJwYXJcczE2XHFqIFxsaTBccmkwXHdpZGN0bHBhclx0eDkxNlx0eDE4MzJcdHgyNzQ4XHR4 MzY2NFx0eDQ1ODBcdHg1NDk2XHR4NjQxMlx0eDczMjhcdHg4MjQ0XHR4OTE2MFx0eDEwMDc2 XHR4MTA5OTJcdHgxMTkwOFx0eDEyODI0XHR4MTM3NDBcdHgxNDY1Nlx3cmFwZGVmYXVsdFxh c3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJh cnNpZDQ5MTkzMzkge1xydGxjaFxmY3MxIFxhZjIgDQpcbHRyY2hcZmNzMCBcY2YxXGluc3Jz aWQxMzUwMDQ3OCANClxwYXIgfXtccnRsY2hcZmNzMSBcYWYyIFxsdHJjaFxmY3MwIFxjZjFc aW5zcnNpZDQ5MTkzMzkgU2VjdGlvbiA4LjEgZmlyc3QgcGFyYWdyYXBoLCBpdCBpcyBub3Qg dGhlIGxvY2F0aW9uIG9mIHRoZSBzb3VyY2UgdGhhdCBkZXRlcm1pbmVzIHRoZSBcJzkzc2l6 ZVwnOTQgb2YgdGhlIHdvcmtpbmcgc2V0IG9mIHRoZSBFSUQgcHJlZml4LXRvLVJMT0MgY2Fj aGUgYnV0IHRoZSBudW1iZXIgb2YgRUlEIHByZWZpeGVzIHRoaXMgXCc5M3NvdXJjZSBzaXRl DQpcJzk0IGhhcyB0byByZWFjaC59e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNm MVxpbnNyc2lkMzA4ODY5MCAgVGhlIHNhbWUgaXNzdWUgb2NjdXJzIGF0IEVUUiwgc21hbGwg c2l0ZXMgbWF5IGhhdmUgdG8gYmUgY29uZmlndXJlZCB3aXRoIGEgbGFyZ2UgbGlzdCBvZiBF SUQtdG8tUkxPDQpDIG1hcHBpbmcgZW50cmllcy4gTmV4dCB0byB0aGlzIHRoZSBncmFudWxh cml0eSBvZiB0aGUgRUlEIHByZWZpeCBhbGxvY2F0aW9uIGlzIGFsc28gaW1wb3J0YW50LiB9 e1xydGxjaFxmY3MxIFxhZjIgXGx0cmNoXGZjczAgXGNmMVxpbnNyc2lkNDkxOTMzOSANClxw YXIgfVxwYXJkXHBsYWluIFxsdHJwYXJccWwgXGxpMFxyaTBcd2lkY3RscGFyXHdyYXBkZWZh dWx0XGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAw IFxydGxjaFxmY3MxIFxhZjBcYWZzMjRcYWxhbmcxMDI1IFxsdHJjaFxmY3MwIFxmMzdcZnMy MlxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtc cnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIA0KXGYzNlxpbnNyc2lkMTUwOTI5MDhcY2hh cnJzaWQxMjk4NDE2NCANClxwYXIgfX0= --------------000106000107030103000203-- From dino@cisco.com Thu Apr 15 12:11:47 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059B83A6895 for ; Thu, 15 Apr 2010 12:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=-3.098, BAYES_50=0.001, FRT_PROFIT1=3.858, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+qTHrr5c31K for ; Thu, 15 Apr 2010 12:11:42 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D2AC73A681C for ; Thu, 15 Apr 2010 12:11:34 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAKMBx0urR7H+/2dsb2JhbACbHFFxpQ+aJYUOBIMp X-IronPort-AV: E=Sophos;i="4.52,214,1270425600"; d="scan'208";a="183695780" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 15 Apr 2010 19:00:28 +0000 Received: from [192.168.1.7] (sjc-vpn7-1838.cisco.com [10.21.151.46]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3FJ0RgO004433; Thu, 15 Apr 2010 19:00:27 GMT Message-Id: <5357F3F6-25A0-4C3E-AC1B-8840689E0083@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4BC679F8.5080607@joelhalpern.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Apr 2010 12:00:27 -0700 References: <4BC679F8.5080607@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" , PAPADIMITRIOU Dimitri Subject: Re: [lisp] [Fwd: RE: LISP Reviews] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 19:11:47 -0000 > Attached and copied below are the review comments prepared several =20 > weeks ago for us by Dimitri Papadimitriou, based on a request by our =20= > routing ADs. THe comments were held up by the chairs, who apologise =20= > to Dimitri and the working group for the delay. The working group chairs and the co-authors have discussed that we =20 want to put updates in to reflect Dimitri's comments in the -08 =20 revision and not the -07 revision, since the -07 revision has a lot of =20= changes and people may have already started reviewing them. Dimitri, is that okay? Once we publish -07 (end of next week), we can =20= turn around a -08 quickly and definitely before next IETF. Dino/Dave/Vince/Darrel > > Please review and comment. > > Thank you, > Joel (& Terry) > > ------------------- > > Section 2: > > Section 2 states =93greatly improving aggregation and reducing the =20 > number of globally-visible, routable prefixes.=94 If aggregation is =20= > perceived as resolving scalability of routing in terms memory size =20 > then one should also be ready to assume that routing will result in =20= > higher stretch due to the characteristics of the Internet topology. > > Section 2 states =93More cost-effective multi-homing=94 but it is not =20= > stated what is actually meant by this statement and why the Loc/ID =20 > scheme as proposed would make multi-homing cost-effective. > > Section 2 states =93Mobility without address changing=94 but then =93=85= or =20 > acquiring a new address based on the new network location.=94 These =20= > statements are contradicting each other. > > Section 2 states =93This draft describes protocol mechanisms to =20 > achieve the desired functional separation.=94 But separation between =20= > which functions ? If this statement is related to the separation =20 > between forwarding and control/routing, then it is defeated looking =20= > at i) the way RLOC reachability testing inter-twin control as part =20 > of the forwarding plane, and ii) the use of =93Data Probes=94 = forwarding =20 > date as part of the control plane of TR=92s. > > Section 2 the statement =93This draft attempts to not compete or =20 > overlap with such solutions and the proposed protocol changes are =20 > expected to complement a host-based mechanism when Traffic =20 > Engineering functionality is desired.=94 raises the question if these =20= > solutions would still be complementary if TE functionality is not =20 > desired (this is not clearly stated in the document). On the other =20 > hand, the statement =93Building the solution into the network will =20 > facilitate incremental deployment of the technology on the =20 > Internet.=94 should be further developed to explain why =93network =20 > deployment=94 is considered as facilitating incremental deployment ? > > Section 2 states =93Some of the design goals of this proposal = include:=94 > Which are the other goals ? there is only partial match with the =20 > design goals specified at RRG (the term =93design goal=94 seems to = have =20 > a different meaning) and it is unclear what changes are referring =20 > to. The statement =93Minimize required changes to Internet =20 > infrastructure.=94 is vague. The statement =93most customer site =20 > routers=94 under which condition the remaining fraction would have to =20= > change. > > Section 2 states =937. Avoid or minimize packet loss when EID-to-RLOC = =20 > mappings need to be performed.=94 This condition is not addressed by =20= > the present proposal as the ITRs drop the packet(s) for which they =20 > have no EID-to-RLOC mapping for (as long as response to Map Request =20= > is not received and RLOC reachability =93tested=94). > > Section 2 describes LISP variants depending on EID =93routability=94 = it =20 > would be appropriate to state =93routability=94 refers to the core = i.e. =20 > between ITR/ETR (as EID remain routable in =93sites=94 otherwise there = =20 > is no difference with host-based solutions) > > Section 2. LISP 1.5 is assumed to make use of a =93separate topology=94 = =20 > also referred to as =93alternative topology=94. The key question is = what =20 > is this topology ? > > Section 2. LISP 3 assumes the existence of EID-to-RLOC database. How =20= > the existence of the databases is made aware to ITR. This is what =20 > determines the use of Data probes vs Map requests if both modes are =20= > supported. > > Section 3: > > Section 3. The definition of Provider Independent (PI) Addresses =20 > states what a PI is not instead of defining what a PI is. Also the =20 > document refers to EID prefixes and EID =93blocks=94 what is a =93block=94= =20 > and a =93sub-block=94? > > Section 3. Definition of PA =93LISP uses only topologically-assigned =20= > and aggregatable address blocks for RLOCs, eliminating this =20 > demonstrably non-scalable practice=94. Provide a reference of such =20 > demonstration. > > Section 3. ITR/ETR are described as routers while they are actually =20= > functions. Describe them as functions instead of =93routers=94. > > Section 3. Definition of RLOC seems to be limited to ETR. Thus how =20 > ITR set the Source RLOC ? Section 7 (third bullet) makes this =20 > assignment even less understandable (the well-defined concept of VRF =20= > suddenly appears). > > Section 3. Validation of =93EID-to-RLOC mappings=94 in cache is = defined =20 > as time-based only ? not on frequency of usage neither replacement ? > > Section 3. The most important definition =93EID-to-RLOC mapping =20 > lookup=94 is missing. In particular, how a ITR knows that the =20 > =93incoming=94 destination address is part of an EID prefix ? More =20 > generally which event or condition triggers such lookup ? > > Section 4: > > Section 4 states =93End-systems (hosts) only send to addresses which =20= > are EIDs. They don't know addresses are EIDs versus RLOCs but assume =20= > packets get to LISP routers,=85=94 > > Section 4 =93an EID is only routable within the scope of a site=94 = what =20 > is the scope of a site ? > > Section 4 =93This specification mandates that no more than two LISP =20= > headers get prepended to a packet.=94 Is there any mechanism =20 > preventing ITR (or TE ITR) to perform additional prepending ? and at =20= > which cost ? > > Section 4 last paragraph of p13, refers to Section 8 concerning =20 > =93flexible=94 placement of TR=92s but does not respond to the = question is =20 > there a deployment scenario that would not be supported. > > Section 4.1 states =93And the Data Probes are sent on the underlying =20= > topology (the LISP 1.0 variant) but could also be sent over an =20 > alternative topology (the LISP 1.5 variant) as it would in [ALT].=94 =20= > but in Section 2 does refer to [ALT] in LISP 3 context ? > > Section 4.1 point 2 (same remark applies to Section 6) misses an =20 > important aspect how the mapping is performed the first time a new =20 > destination EID is seen at ITR and how subsequent maps are =20 > performed. It seems that a) EID-to-RLOC Cache must be first entirely =20= > scanned for each incoming packet at ITR (not only the first one) and =20= > then if there is no entry i) Data probe i.e. copy the destination =20 > EID value in the destination RLOC field (for LISP 1.5) or ii) =20 > originate a Map Request; otherwise use the corresponding RLOC value =20= > in the retrieved entry as destination RLOC. Needless to say that the =20= > delay is proportional to the number of entries in the cache. Nothing =20= > is being said if the cache is full (which entry should be replaced =20 > i.e. the least frequently used, the least recently used, or the =20 > least recently replaced entry). Nothing is said what happens if a =20 > more accurate EID prefix is being made available when a less EID =20 > prefix is being in use for a set of one or more RLOCs. > > Section 4.1 point 3 states =93The router is configured to "punt" the =20= > packet to the router's processor. See Section 7 for more details.=94 =20= > Looking at Section 7 there is no definition of =93punting packets=94. > > Section 4.1 point 4 states =93The LISP header is stripped so that the =20= > packet can be forwarded by the router control plane.=94 =85 forwarding = =20 > traffic by routing control engines result in major drawbacks such as =20= > attacks, intrusions, etc. if the value encoded in the destination =20 > EID is one of the routers addresses. > > Section 4.1 point 4 supposedly if there the destination EID is not =20 > found in the ETR's EID-to-RLOC database the packet gets dropped ? On =20= > the other hand how to prevent that a Map Reply is sent in response =20 > for EID prefix not reachable but statically configured in the ETR's =20= > EID-to-RLOC database. The case of ETR responding with =93coarser EID-=20= > RLOC=94 mapping due e.g. to sub-segmentation is partially addressed in = =20 > Section 6.1.5.1 > > Section 4.1 on =93gleaned mapping=94 states =93More complete = information =20 > about additional RLOCs SHOULD be verified by sending a LISP Map-=20 > Request for that EID.=94 But there is no detail on what happens in =20 > case of mismatch between the =93gleaned mapping=94 and the result of = Map-=20 > Request (further details are provided in Section 6.2 last bullet but =20= > it does not respond to the question of mismatch). > > Section 5: > > Section 5.3 sets the nonce space to 2^24 but does not explain the =20 > space of applicability of this field as reading goes this value is =20 > limiting the number of bi-directional relationships between TR=92s to =20= > this number. > > Section 6: > > Section 6.1.3 does not explain the result of refresh for which the =20 > received EID block would be larger than the requested one. Section =20 > 6.1.5 assumes that a =93that a Map-Reply may contain different EID-=20 > prefix granularity (prefix + length) than the Map-Request which =20 > triggers it.=94 But it doesn=92t say if the associated RLOC shall be =20= > identical or not ? > > Section 6.1.4 states =93R: when this bit is set, the locator is known =20= > to be reachable from the Map-Reply sender's perspective.=94 Can author = =20 > explain how a receiver can test its reachability i.e. what is the =20 > decision criteria to set the R bit ? > > Section 6.1.5 where is the =93Data Probe packet=94 format defined =20 > actually ? > > Section 6.1.5 states =93The RLOCs in the Map-Reply are the globally-=20= > routable IP addresses of the ETR but are not necessarily reachable; =20= > separate testing of reachability is required.=94 Section 6.3 does not =20= > define any procedure actually and does not define any criteria for =20 > deciding when the RLOC is reachable or not. The key question is if =20 > the ITR persists in testing reachability and there is no criteria =20 > process by which such decision would stop, the traffic would be =20 > forwarded by means of the =93separate/alternative topology=94 forever. > > Section 6.2 introduces the terms client-side and server-side where =20 > are these terms defined ? without such definition readability of the =20= > section is low. > > Section 6.2 RLOC reachability can determined and selected but there =20= > is no description on how the EID-to-RLOC selection is performed. > > Section 6.3 proposes =93encapsulated traffic=94 based procedures thus, = =20 > if there is no traffic there is no RLOC reachability =93test=94 =20 > possible. On the other hand, that section states certain =93ICMP =20 > exchanges=94 are documented but reachability of RLOC does not mean =20 > availability of the associated EID. There no actual =93EID-to-RLOC=94 =20= > testing procedure being defined in the document? > > What is struggling here is that the =93introductory=94 sections of the = =20 > document refer to =93functional=94 separations but all the techniques =20= > described in this document (and for RLOC reachability testing in =20 > particular) result in a complex inter-twin between control messaging =20= > as part of the forwarding plane and forwarding date as part of the =20 > control plane of routers. The latter is typical from Data Probes =20 > processing. If this is the design choice of LISP so let it be but 1) =20= > please proof it offers any better functionality compared to =20 > =93current=94 design and 2) better cost/performance. It is far from =20= > obvious that the complexity concentrated at TR taking into the =20 > proposed design offers any real compelling argument. This may also =20 > defeat the argument stated in the introduction that =93network =20 > deployment=94 is facilitated by network-based solutions. > > Section 6.3 Point 1 what is the use of the =93Loc-Status-Bits=94 if =20= > there is no return traffic (or more precisely no return traffic =20 > passing via this ETR i.e. the ETR is not an ITR for the source RLOC-=20= > EID pair). The ETR may process this information but never use it. > > Section 6.3 states =93Each ITR can thus observe the presence or lack =20= > of a default route originated by the others to determine the Locator =20= > Status Bits it sets for them.=94 This does not tell which technique to = =20 > use when no default route are used at all (under =93non-normal=94 =20 > circumstances =85 what should define normality in this context). > > Section 6.3.1 states =93This mechanism does not completely solve the =20= > forward path reachability problem as traffic may be unidirectional.=94 = =20 > The forwarding path may simply be asymmetric (there is nothing that =20= > imposes reverse path reaching the source RLOC in case of dual =20 > attached sites). This shortcoming defeats this mechanism as an ITR =20 > is not =93aware=94 of its neighboring ITR EID-to-RLOC mappings =20 > (connected to the same site). This mechanism can only be safely used =20= > if the RLOC pair between two sites is unique and remains unique. > > Section 6.3.2 RLOC Probing by means of the =93control plane=94 this =20= > opens the question of what is actually probed the =93RLOC=94 or the = EID-=20 > to-RLOC entries of the ETR=92s database. The difference stems because =20= > the latter are static entries the liveness of the former are =20 > dependent on the incoming interface liveness. That is entries can be =20= > available in the database but if database entries are not in sync =20 > with the actual RLOC status there is no possibility to detect =20 > reachability of RLOCs by means of this mechanism. > > Section 6.3.2 states =93RLOC Probing can also provide RTT estimates =20= > between a pair of locators which can be useful for network =20 > management purposes as well as for selecting low delay paths.=94 If =20= > the exchanges are performed in the control plane it is not clear how =20= > such RTT/delay values can be derived for the forwarding path ? Can =20 > authors explain ? Authors should also check the accuracy of the =20 > estimate vs overhead generated by such technique. > > Section 6.5 the section does not actually explain which messages are =20= > used to update the list of Loc-Reach or Loc-Status bits. If it is =20 > data traffic-driven then the mechanism is again dependent on the =20 > symmetry of the reverse path and the packet rate but also packet =20 > differential delays between packets. In the latter case, it is not =20 > clear how ITR could retrieve the correct RLOCs to be used if a =20 > sequence of 8 packets sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 =20= > for a given RLOC (indicated as available at arrival of the 8th =20 > packet) is received as 1,0,0,0,0,0,0,0. The section makes a long =20 > digression on ordering locator set this is not the issue without a =20 > sequence number it will never be possible for the receiving ITR to =20 > determine the actual state of the EID-to-RLOC mappings at ETRs. This =20= > is even if ETR do not keep track of who requested mappings upon =20 > communication they should tell the state of their mapping but also =20 > their transition. > > Section 6.5.2 is this technique mandatory or not (this is not =20 > specified in the text). Point 5 results in obvious situations where =20= > the ETR may never stop sending SMR messages. As there is no means a =20= > way to prevent that ITR use =93old mappings=94 this result in a = deadlock =20 > situation (a non-cooperating ITR prevents ETR to stop sending SMR =20 > messages). > > Section 6.5.2 states =93So an xTR will solicit Map-Requests from sites = =20 > it is currently sending encapsulated data to, and only from those =20 > sites.=94 Thus instead of keeping track of ITR, ETR keep track of the =20= > encapsulated traffic ITR send. The mechanism is often cited but =20 > never explained e.g. over which time period is the ETR expected to =20 > determine the set of communicating ITR=92s ? > > Section 6.5.2 states =93Map request=94 shall be rate limited =85 = rather =20 > unclear: assume a single ETR sends one SMR message to 10 different =20 > ITRs how the 10 ITR will individually rate limit a single Map =20 > Request in response to this SMR message. It is thus worth specifying =20= > the flow control of SMR and Map-Request messages in a more =20 > systematic way to prevent ETR overloads. > > Section 7: the first paragraph is a wish not a fact. As such it is =20 > doubtful what such paragraph actually brings in the context of a =20 > protocol architecture/specification. > > Section 8: > > Section 8.1 first paragraph, it is not the location of the source =20 > that determines the =93size=94 of the working set of the EID = prefix-to-=20 > RLOC cache but the number of EID prefixes this =93source site=94 has = to =20 > reach. The same issue occurs at ETR, small sites may have to be =20 > configured with a large list of EID-to-RLOC mapping entries. Next to =20= > this the granularity of the EID prefix allocation is also important. > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Thu Apr 15 17:18:05 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0693A690C for ; Thu, 15 Apr 2010 17:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6lnQlzz01qJ for ; Thu, 15 Apr 2010 17:18:05 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 816B53A6923 for ; Thu, 15 Apr 2010 17:18:00 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: lisp-ietf-sna-multicast-draft.ppt, rfcdiff-lisp-multicast-02-to-03.html, draft-ietf-lisp-multicast-03.txt : 79872, 73542, 72136 X-IronPort-AV: E=Sophos;i="4.52,215,1270425600"; d="ppt'32?txt'32?html'32,217?scan'32,217,208,217,32";a="250717074" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2010 00:17:53 +0000 Received: from [192.168.1.7] (sjc-vpn7-1838.cisco.com [10.21.151.46]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3G0HqDV020997 for ; Fri, 16 Apr 2010 00:17:52 GMT Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-12-1012096568 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Apr 2010 17:17:52 -0700 References: X-Mailer: Apple Mail (2.936) Subject: [lisp] Fwd: Proposed changes to draft-ietf-lisp-multicast-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 00:18:06 -0000 --Apple-Mail-12-1012096568 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Just an FYI that I have not received any comments so far on this draft. I will post this draft to the ID directory in 24 hours. Thanks, Dino Begin forwarded message: > From: Dino Farinacci > Date: April 13, 2010 8:41:05 AM PDT > To: lisp@ietf.org > Cc: David Meyer , Stig Venaas , > John Zwiebel > Subject: Proposed changes to draft-ietf-lisp-multicast-03 > > Enclosed you will find: > > (1) Slide-set from Anaheim IETF where I presented proposed changes > to the next revision of the LISP-Multicast draft. > > (2) A 02-to-03 diff file with the proposed changes. > > (3) The -03 draft itself. > > Here are the proposed changes: > > A.1. Changes to draft-ietf-lisp-multicast-03.txt > > o Posted April 2010. > > o Added section 8.1.2 to address Joel Halpern's comment about > receiver sites joining the same source site via 2 different > RLOCs, > each being a separate ITR. > > o Change all occurences of "mPTR" to "mPETR" to become more > consistent with uPITRs and uPETRs described in [INTWORK]. That > is, an mPETR is a LISP multicast router that decapsulates > multicast packets that are encapsulated to it by ITRs in > multicast > source sites. > > o Add clarifications in section 9 about how homogeneous multicast > encapsulation should occur. As well as describing in this > section, how to deal with mixed-locator sets to avoid > heterogeneous encapsulation. > > o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges > of LISP global multicast network. > > ---- > > Since the number of changes are small, We would like to have review > comments back by Friday, close of business PDT. If we receive no > comments, or the comments are resolved to the commentor's > satisfaction, we will post on Friday. > > Thanks, > Dino/Dave/JohnZ/Stig > --Apple-Mail-12-1012096568 Content-Disposition: attachment; filename=lisp-ietf-sna-multicast-draft.ppt Content-Type: application/vnd.ms-powerpoint; x-mac-creator=50505433; x-unix-mode=0644; x-mac-type=534C4438; name="lisp-ietf-sna-multicast-draft.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAlAAAAAAAAAAA EAAAmAAAAAEAAAD+////AAAAAJYAAACVAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A UgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgAFAP//////////AQAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAAAAtjx/QMfK AVAAAABABgAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAAKvsAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEEAAAA//////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRAAAAnCcAAAAAAAAFAEQAbwBjAHUAbQBlAG4A dABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMBQAAAAAAAGYA AAD9////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAs AAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoA AAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAA AEkAAABKAAAASwAAAEwAAABNAAAATgAAAGkAAAD9////ZQAAAFIAAABTAAAAVAAAAFUAAABWAAAA VwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAAD+ ////eQAAAP7////+/////v///2oAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMA AAB0AAAAdQAAAHYAAAB3AAAAeAAAAHoAAABoAAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAADwDo AyAvAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAUAAAAAAAAAAQAAAAABAAEPAPID rgEAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB+QAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAA/78wwwAAEABafEDY/78Ix/+/MMP/v8j1kXyc9gAAAAAAAATgEAC3D0QA AABDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAbgAAAP+/MMMAABAAWnxA2P+/CMf/vzDD/7/I 9ZF8nPYAAAAAAAAE4CAAtw9EAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAUwAAAG4AAAD/vzDD AAAQAFp8QNj/vwjH/78ww/+/yPWRfJz2AAAAAAAABOAAAKQPCgAAAIAAYAAAAP////8AAKUPDAAA AAAAAAguAAAAAgAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAA AABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAA BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEUAYAAA8AAPBIBgAAAAAG8MAD AAAC3AEAdwAAACUAAAAJAAAAAQAAAAkAAAAEAAAABAAAAAgAAAAHAAAABgAAAAgAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAACUAAAAAAAAABAAAAAAAAAAFAAAA AAAAAAQAAAAAAAAABQAAAAAAAAAGAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAYAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAEgAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAA AAYAAAAAAAAACQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAfAAAAAAAAAB0AAAAAAAAA BAAAAAIAAAAJAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAXAAAAAAAAAB0AAAAAAAAAEQAAAAAAAAAc AAAAAAAAABkAAAAAAAAABgAAAAAAAABCAAAAAAAAAAQAAAAAAAAAfQAAAAAAAAAFAAAAAAAAAAgA AAAAAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAACgAA AAAAAAAEAAAAAAAAAFkAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAFAAAA AAAAAAQAAAAAAAAABgAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAHAAAAAAAAAAUAAAAAAAAABAAAAAAA AAAEAAAAAAAAABcAAAAAAAAAHQAAAAAAAAAsAAAAAAAAAC8AAAAAAAAAQwAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAEQAAAAAAAAArAAAAAAAAAAQAAAAAAAAABAAAAAAAAABn AAAABQAAAAQAAAAJAAAABAAAAAAAAAAEAAAAAAAAACsAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAMAAAAEAAAABwAAAAQAAAAjBgvwTAIA AIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAgAAAIgAAAAAAIkAAAAAAL8AAAANAAwB9AAAEA0B AAAAIA4BAAAAIIEBBAAACIMBAAAACL8BEAAQAMABAQAACMEBAAABAMIB////AMMBAAAAIMQBAAAA AMVBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4B AAAAAM/BAAAAANcBAgAAAP8BDgAOAAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQCAAABAAcCAAAA AAgCAAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABEC AAAAAD8CAAABAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAA EIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcC AAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5 /9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoC cJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4B AIUDAAAAAIYDfL4BAIcDAAAAADAAGvEMAAAA/wAAAP//AADWAJMAQAAe8RAAAADWAJMA/wAAAP// ///3AAAQHwDwDzgAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAAAADzAxQAAAApAAAAAAAA AAAAAAABAACAAAAAAA8A0AchHAAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAfQAAAGQAAAB9 AAAAZAAAAADA6AEAAAAAAAAAAFDD/78AAAAAwJ9gfED9//+Q////AQAAAHAA+wMIAAAAAAAAAHAI AABwAPsDCAAAAAEAAABACwAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ACAQ8AAAAAAD9 AzQAAABCAAAAZAAAAEIAAABkAAAAsMP/vykAAACwNVh8AAAAABQAAAAAypo7AAAAAAAAAAAAAAAA HwAUBBwAAAAAABUEFAAAALoddewAypo7Mk7NyQDKmjsAAgABHwAHBDwAAAAAAP0DNAAAACEAAABk AAAAIQAAAGQAAACww/+/KQAAALA1WHwAAAAAuh117ADKmjsAAAAAAAAAAAABAAEfABMEPAAAAAAA /QM0AAAAZAAAAGQAAABkAAAAZAAAALDD/78pAAAAsDVYfAAAAAC6HXXsAMqaOwAAAAAAAAAAAAEA AQ8AiBOeGgAADwCKE5gBAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTeAEAAA8Asw9wAQAA AACvDwgAAAAAAQAABgAAAAAAsQ8gAAAAAAAABAAAAAAAAAAEAQAAAAAAAAQCAAAAAAAABAMAAAAQ AK8PCAAAAAABAAAFAAAAAACxDxgAAAAAAAAEAAAAAAAAAAQBAAAAAAAABAIAAAAQAK8PCAAAAAEB AAABAAAAAACxD3gAAAAAAAAEAAAAAAAAAAQBAAAAAAAABAIAAAAAAAAEAwAAAAAAAAQEAAAAAAAA BAUAAAAAAAAEBgAAAAAAAAQHAAAAAAAABAgAAAAAAAAECQAAAAAAAAQKAAAAAAAABAsAAAAAAAAE DAAAAAAAAAQNAAAAAAAABA4AAAAQAK8PCAAAABgBAAABAAAAAACxD2AAAAAAAAAEAAAAAAAAAAQB AAAAAAAABAIAAAAAAAAEAwAAAAAAAAQEAAAAAAAABAUAAAAAAAAEBgAAAAAAAAQHAAAAAAAABAgA AAAAAAAECQAAAAAAAAQKAAAAAAAABAsAAAAPAIoTpgIAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAA AIsTiAIAAA8Arg+AAgAAAACvDwgAAAAAAQAABgAAAAAArA9AAAAAAAAAAAAAEAAAAAAAAAAAAAAA AAAAABAAAQAAAAAAAAAAAAAAAAAQAAIAAAAAAAAAAAAAAAAAEAADAAAAAAAAABAArw8IAAAAAAEA AAUAAAAAAKwPMAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAA AAAAABAArw8IAAAAAQEAAAEAAAAAAKwP8AAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAA AAAAAAAAAAAAEAACAAAAAAAAAAAAAAAAABAAAwAAAAAAAAAAAAAAAAAQAAQAAAAAAAAAAAAAAAAA EAAFAAAAAAAAAAAAAAAAABAABgAAAAAAAAAAAAAAAAAQAAcAAAAAAAAAAAAAAAAAEAAIAAAAAAAA AAAAAAAAABAACQAAAAAAAAAAAAAAAAAQAAoAAAAAAAAAAAAAAAAAEAALAAAAAAAAAAAAAAAAABAA DAAAAAAAAAAAAAAAAAAQAA0AAAAAAAAAAAAAAAAAEAAOAAAAAAAAABAArw8IAAAAGAEAAAEAAAAA AKwPwAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAA AAAAABAAAwAAAAAAAAAAAAAAAAAQAAQAAAAAAAAAAAAAAAAAEAAFAAAAAAAAAAAAAAAAABAABgAA AAAAAAAAAAAAAAAQAAcAAAAAAAAAAAAAAAAAEAAIAAAAAAAAAAAAAAAAABAACQAAAAAAAAAAAAAA AAAQAAoAAAAAAAAAAAAAAAAAEAALAAAAAAAAAA8AihNoAAAAAAC6DxQAAABfAF8AXwBQAFAAVAAy ADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkXNAAAAAAAAAAAAAAAAAAAAFgCAAAAAQEAAQEAAAEB AQABAAAAAAAAAAjHAAAAAAAAAAAAAIACAeAPAIoT2BUAAAAAug8WAAAAXwBfAF8AUABQAFQATQBh AGMAMQAxAAAAixOyFQAAQAAaEGYFAAAFAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAAB AAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIA AAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAA AAMAAAABAAAECQAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQA eQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAA AAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAA AAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAA AQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAE CQAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABU AHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkA EQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAA AAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAA AAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAECQAAAAoAQQBy AGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcA cgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAECQAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAECQAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAHBAUAQAAAAAACAwBAAAAAAAC AAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEA AAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAA AGhuYW1kAAAAYAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAA AwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAE ABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABDwAbECAPAAAAAK8PCAAAAAABAAAG AAAAAAAZECgBAAAAAAAAAAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAA AAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAAB AwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJ AAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkA YwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQALAAAAAABBwAAAAYAAAAAAAAAAAAE AAAADgAJABEAAAAaAAEAAAAAAAAAABAArw8IAAAAAAEAAAUAAAAAABkQJAEAAAAAAAAAAAAIFAEA AAAAAAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEA AAAAAQAAAAAAAAEBAAAAAQEAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAA AAEFAAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBu AHMAIABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIA cAAuAAAAAAEGAAAABAAgAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAQAK8P CAAAAAEBAAABAAAAAAAZEMwGAAAAAAAAAAAAAAAAAAgUAQAAAAAAAgAAARQAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAAAGgAAAACAAAA BAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAACAAAAAMAAAAB AAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAEABgAAAAAAQcA AAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAA AAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAAB AgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAE AAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEA AAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQAGAAAAAABBwAA AAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIFAEAAAAAAAIAAAEUAAAAAAAAABQAAAAgAAAA AQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAEC AAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAcG5hbWQAAABoAAAAAgAAAAQA AAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAAAAgAAAADAAAAAQAA BAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIAcAAuAAAAAAEGAAAABAAYAAAAAAEHAAAA BgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAAAAAAAAAAAAAAAAgUAQAAAAAAAgAAARQAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAA AGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAA CAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAE ABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAAAAAAAAAAAAAAAAAACBQBAAAA AAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAA AAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAAB BQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBz ACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAA LgAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIFAEAAAAA AAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBuAHMA IABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIAcAAu AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAQAK8PCAAA ABgBAAABAAAAAAAZEKgFAAAAAAAAAAAAAAAAAAAAAAAAAAAACBQBAAAAAAACAAABFAAAAAAAAAAU AAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEA AAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAA AAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAA AwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQAHAAA AAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAAAAAAAAAAAAgUAQAAAAAAAgAAARQA AAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAA AQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFt ZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAA AAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYA AAAEACAAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACBQBAAAAAAACAAABFAAA AAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAAB AQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1k AAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAA AAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAA AAQAIAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIFAEAAAAAAAIAAAEUAAAA AAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEB AAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAcG5hbWQA AABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAA AAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIAcAAuAAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgUAQAAAAAAAgAAARQAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAA AGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAA CAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAE ACAAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAAAD8A2Q8MAAAAAADaDwQAAAAA AC0ATwDZDwwAAAAAANoPBAAAAAAAPQAPAPAP5QkAAAAA8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAA AAAAAJ8PBAAAAAYAAAAAAKgPMAAAAERyYWZ0IFN0YXR1cyBVcGRhdGULZHJhZnQtaWV0Zi1saXNw LW11bHRpY2FzdC0wMgAAoQ8+AAAAMQAAAAAAABAAAIIAFAAAAAAAAAABAAAAAARDABAEAgACACQA GwAAAAAIQwAQCAIAAgAkAAEAAAAADAAAEAwQAJ8PBAAAAAUAAAAAAKgPVwAAAEFuYWhlaW0gSUVU RiAtIExJU1AgV0cNRGF2ZSBNZXllciwgSm9obiBad2llYmVsLCBTdGlnIFZlbmFhcywgRGlubyBG YXJpbmFjY2kNTWFyY2ggMjAxMAAAoQ8uAAAAWAAAAAAAAAAAAA8AAAACAAIAAgAcAAgAAAACBAIA AgQcAEEAAAACCAIAAggUAAAAqg9QAAAAFgAAAAAAAAABAAAAAQAAAAAAEQAAAAAAAAAHAAAAAQAA AAMAAgAAAAAAAAALAAAAAQAAAAMABwAAAAAAAAAKAAAAAQAAAAMACwAAAAAAAAAAAPMDFAAAAAQA AAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABEcmFmdCBIaXN0b3J5EACfDwQA AAABAAAAAACoD4YBAABkcmFmdC1pZXRmLWxpc3AtbXVsdGljYXN0LTAwDVB1Ymxpc2hlZCBpbiBB cHJpbCAyMDA4DVJlbmFtZWQgZnJvbSBkcmFmdC1mYXJpbmFjY2ktbGlzcC1tdWx0aWNhc3QtMDEN ZHJhZnQtaWV0Zi1saXNwLW11bHRpY2FzdC0wMQ1QdWJsaXNoZWQgaW4gTm92ZW1iZXIgMjAwOA1F eHBlcnQgUmV2aWV3IGJ5IExpbWluZyBXZWksIFlpcXVuIENhaSwgVG9tIFB1c2F0ZXJpLCBTdGV2 ZSBDYXNuZXIsIE1hcnNoYWxsIEV1YmFua3MsIERpbWl0cmkgUGFwYWRpbWl0cmlvdSwgUm9uIEJv bmljYSwgYW5kIExlbm55IEd1YXJkaW5vDWRyYWZ0LWlldGYtbGlzcC1tdWx0aWNhc3QtMDINUHVi bGlzaGVkIGluIFNlcHRlbWJlciAyMDA5DUJyaW5nIGluIHN5bmMgd2l0aCBkcmFmdC1pZXRmLWxp c3AtMDYAAKEPAgEAAB0AAAAAAAAAAABHAAAAAQAAAAAAHQAAAAAAAAAAAKcAAAABAAAAAAAdAAAA AAAAAAAAQgAAAAEAAAAAAB0AAAAAAEMAAgACABgAGAAAAAAEAgAABBQADQAAAAAIAgAACBQAIQAA AAAMQwAADAIAAgAUAAEAAAAAEAIAABAUABwAAAAAFEMAABQCAAIAGAABAAAAABgCAAAYGAAbAAAA ABwCAAAcFAARAAAAACACAAAgFAB7AAAAACQCAAAkFAAdAAAAAChDAAAoAgACABgAHAAAAAAsAgAA LBQAEwAAAAAwAgAAMBQAEgAAAAA0QwAANAIAAgAUAAEAAAAAOAIAADgUAAAAqg+YAAAAmwAAAAAA AAABAAAAAQAAAAAAGAAAAAAAAAADAAAAAQAAAAMAAgAAAAAAAAAJAAAAAQAAAAMABgAAAAAAAAAI AAAAAQAAAAMACAAAAAAAAAAGAAAAAQAAAAMAFAAAAAAAAAAIAAAAAQAAAAMAEwAAAAAAAAAGAAAA AQAAAAMADAAAAAAAAAAJAAAAAQAAAAMAXwAAAAAAAAAAAPMDFAAAAHYAAAAAAAAAAgAAABgBAAAA AAAAAACfDwQAAAAAAAAAAACoDw0AAABQbGFucyBmb3IgLTAzEACfDwQAAAABAAAAAACgD+gCAABC AHIAaQBuAGcAIABpAG4AIABzAHkAbgBjACAAdwBpAHQAaAAgAGQAcgBhAGYAdAAtAGkAZQB0AGYA LQBsAGkAcwBwAC0AaQBuAHQAZQByAHcAbwByAGsALQAwADEADQBVAG4AaQBjAGEAcwB0ACAAUABU AFIAcwAgAGEAcgBlACAAYwBhAGwAbABlAGQAIAB1AFAASQBUAFIAcwANAE0AdQBsAHQAaQBjAGEA cwB0ACAAUABUAFIAcwAgAGEAcgBlACAAYwBhAGwAbABlAGQAIABtAFAARQBUAFIAcwANAEoAbwBl AGwAIABjAG8AbQBtAGUAbgB0AA0AKABTAC0ARQBJAEQALAAgAEcAKQAgAGoAbwBpAG4AZQBkACAA dABoAHIAbwB1AGcAaAAgAGQAaQBmAGYAZQByAGUAbgB0ACAAcwBvAHUAcgBjAGUAIABSAEwATwBD AHMAIABkAG8AZQBzACAAbgBvAHQAIABjAGEAdQBzAGUAIABkAHUAcABsAGkAYwBhAHQAZQBzAA0A RABpAG4AbwAgAGYAbwB1AG4AZAAgAGIAdQBnAHMADQBDAGwAYQByAGkAZgB5ACAAaABvAHcAIABt AGkAeABlAGQAIABsAG8AYwBhAHQAbwByAHMAIABzAGgAbwB1AGwAZABuABkgdAAgAGIAZQAgAHUA cwBlAGQAIABmAG8AcgAgAG0AdQBsAHQAaQBjAGEAcwB0ACAADQBDAGwAYQByAGkAZgB5ACAAdwBo AGEAdAAgAG0AUABFAFQAUgBzACAAcwBvACAAdwBoAGUAbgAgAGQAZQBjAGEAcABzAHUAbABhAHQA ZQBkACAAcABhAGMAawBlAHQAIABpAHMAIABkAGkAZgBmAGUAcgBlAG4AdAAgAEEARgAgAHcAaQB0 AGgAIABuAG8AIAByAGUAYwBlAGkAdgBlAHIAcwAgAC0AIABkAHIAbwBwACAAcABhAGMAawBlAHQA DQAAAKEP2gAAADAAAAAAAAAQAABaAEAAAAABAAAQAABaAA0AAAAAAAAQAABaAEsAAAABAAAQAABa ABAAAAAAAAAQAABaAJ0AAAABAAAQAABaABMAAAAAAAIAHAAcAAAAAARDAAAEAgACABQAAQAAAAAI AgAACBQAHwAAAAAMAgAADBgAIQAAAAAQAgAAEBgADQAAAAAUAgAAFBwASwAAAAAYAgAAGBgAEAAA AAAcAgAAHBwAPAAAAAAgAgAAIBgAXwAAAAAkAgAAJBgAAQAAAAAoAgAAKBgAAQAAAAAsAgAALBgA AACqD6IAAAAwAAAAAAAAAA0AAAABAAAAAwAKAAAAAAAAAAEAAAABAAAAAAAHAAAAAQAAAAMACgAA AAAAAAAFAAAAAQAAAAMACwAAAAAAAAAHAAAAAQAAAAMAOAAAAAAAAAAGAAAAAQAAAAMAZAAAAAAA AAACAAAAAQAAAAAADQAAAAAAAAAHAAAAAQAAAAMACAAAAAAAAAANAAAAAQAAAAMAOAAAAAAAAAAv APAPVAAAAAAA8wMUAAAAaQAAAAAAAAAAAAAAAAEAAAAAAAAAAPMDFAAAAGoAAAAAAAAAAAAAAAEB AAAAAAAAAADzAxQAAAB3AAAAAAAAAAAAAAACAQAAAAAAAAAA6gMAAAAADwD4AwsJAAACAO8DGAAA AAEAAAABAgcJCAAAAAAAAAAAAAAAAADHsGAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wA zMz/ALKysgBgAPAHIAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYAYADwByAAAAD/ /8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAAAzMzMAAAAAAN3d 3QCAgIAATU1NAOrq6gBgAPAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwAzADAwMAAYADw ByAAAAD///8AAAAAAICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8AcgAAAA////AAAAAACAgIAA AAAAADOZ/wCZ/8wAzADMALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAAAAAAAAAA AEACAAAAAAIAAAD//+8AEAABAP///////ywAAAAABQAAEACjD3wAAAAFAP/9PwAFACIgAABkAAAA AAUAAGQAFAAAANgAAABAAgAAAAACAAAA///vAAAAAQD///////8gAAAAAAEAAIAFAAATINQBIAEA AAIAHACABQAAIiDQAkACAAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24A AAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///vAAAAAAD///////8M AAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAA ow9SAAAABQAAAAEJAAAEAAEAAAAAAAAAAQABCQAABAABACABAAAAAAIAAQkAAAQAAQBAAgAAAAAD AAEJAAAEAAEAYAMAAAAABAABCQAABAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4A AAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAA AAAAAgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAA AAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwERQUAAA8AAvA9BQAAEAAI8AgAAAAGAAAACAQAAA8AA/DV BAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIA AAASAArwCAAAAAIEAAAACgAAkwAL8DYAAAB/AAEAAQCAAHCAIS+HAAEAAACBAQQAAAiDAQAAAAi/ AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAPAAsAHQFMADDwAR8BAAAAAAAMMLCAAAAAAA AAABAHoADwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRp dGxlIHN0eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAA AwQAAAAKAACDAAvwMAAAAH8AAQABAIAAAEsgHYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACAAAEPAIAAAAgASwAdAUoA4PABHwEAAAAAAAwwsIAAAAAQAAAAIAegAPAA3wngAAAAAA nw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25k IGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAA DQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8MsAAAASAArwCAAA AAQEAAAACgAAgwAL8DAAAAB/AAEAAQCAAFA77ReBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEA CQABAgIAAAgAABDwCAAAAGAPsAGwB4AQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAXoADwAN8FMAAAAA AJ8PBAAAAAQAAAAAAKgPGwAAAExJU1AtTXVsdGljYXN0IERyYWZ0IFN0YXR1cwAAoQ8cAAAAHAAA AAAAAAAAABwAAAARAAcAEQABAAwAAAAABQ8ABPDKAAAAEgAK8AgAAAAFBAAAAAoAAIMAC/AwAAAA fwABAAEAgAAwskQogQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABg D7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAACQJ6AA8ADfBSAAAAAACfDwQAAAAEAAAAAACoDwwA AABBbmFoZWltIElFVEYAAKEPKgAAAA0AAAAAAAAIAAABAAwAAAARAAcAEQABAAwAAAAABQEAAAAA BAIAAAQOAA8ABPAAAQAAEgAK8AgAAAAGBAAAAAoAAIMAC/AwAAAAfwABAAEAgAAQS+spgQEEAAAI gwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgDyAQ0BSAEA8AEfAQAAAAAADD CwgAAAAEAAAACAJ6AA8ADfCIAAAAAACfDwQAAAAEAAAAAACgDw4AAABTAGwAaQBkAGUAIAAqAAAA oQ8wAAAACAAAAAAAAAgAAAIABwAAABEABwARAAEADAAAAAAFAQAAAAAEBwAABAEADgAAAAAFAADY DwQAAAAGAAAAAACqDxoAAAAGAAAAAAAAAAEAAAABAAAAAAABAAAAAAAAAA8ABPBIAAAAEgAK8AgA AAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ AAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyACAAug8cAAAA RABlAGYAYQB1AGwAdAAgAEQAZQBzAGkAZwBuAA8A7gP3BAAAAgDvAxgAAAACAAAAAwQHCQgAAAAA AACAAAAAAAAAx7APAAwEpwQAAA8AAvCfBAAAIAAI8AgAAAAGAAAACKgAAA8AA/A3BAAADwAE8CgA AAABAAnwEAAAAAAQgEAAAAAAAGh/QAAAAAACAArwCAAAAACoAAAFAAAADwAE8NIAAAASAArwCAAA AAKoAAAACgAAkwAL8DYAAAB/AAEAAQCAAIB8GC6HAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEA AAj/AQEACQABAgIAAAgAABDwCAAAAKAFsAHQFHAIDwAR8BAAAAAAAMMLCAAAAAAAAAADAHoADwAN 8FQAAAAAAJ8PBAAAAAYAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxl AACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwzwAAABIACvAIAAAAA6gAAAAKAACD AAvwMAAAAH8AAQABAIAAwMLpF4EBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAAkAlgAyAT4A0PABHwEAAAAAAAwwsIAAAAAQAAAAQAegAPAA3wVwAAAAAAnw8EAAAABQAA AAAAqA8jAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgc3VidGl0bGUgc3R5bGUAAKIPBgAAACQAAAAA AAAAqg8KAAAAJAAAAAEAAAAAAA8ABPCyAAAAEgAK8AgAAAAEqAAAAAoAAIMAC/AwAAAAfwABAAEA gACwujsXgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7ABYAaA EA8AEfAQAAAAAADDCwgAAAACAAAABwF6AA8ADfA6AAAAAACfDwQAAAAEAAAAAAChDxQAAAABAAAA AAAAAAAAAQAAAAAAAgAOAAAAqg8KAAAAAQAAAAEAAAAAAA8ABPDSAAAAEgAK8AgAAAAFqAAAAAoA AIMAC/AwAAAAfwABAAEAgACwSSsugQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAI AAAQ8AgAAABgD7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAACQJ6AA8ADfBaAAAAAACfDwQAAAAE AAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAEAAgAAAAAAAgAOAAAA+g8EAAAAAAAAAAAA qg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE8LoAAAASAArwCAAAAAaoAAAACgAAgwAL8DAAAAB/ AAEAAQCAAMCcKy6BAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAP IBDQFIAQDwAR8BAAAAAAAMMLCAAAAAQAAAAIAnoADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKEPHAAA AAEAAAAAAAAIAAACAAEAAAAAAAcAAQAOAAAAAAUAAKoPCgAAAAEAAAABAAAAAAAPAATwSAAAABIA CvAIAAAAAagAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAPAD GgYAAAEA8QMIAAAAAAAAgAAAwAAPAAwEmgUAAA8AAvCSBQAAYAAI8AgAAAAHAAAABxAAAA8AA/Aq BQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA/////wAAAAACAArwCAAAAAAQAAAFAAAADwAE8NAA AAASAArwCAAAAAIQAAAACgAAgwAL8DAAAAB/AAEAAQCAAADtSjaBAQQAAAiDAQAAAAi/AQEAEQDA AQEAAAj/AQEACQABAgIAAAgAABDwCAAAAAAAAABQByABDwAR8BAAAAAAAMMLCAAAAAAAAAAKAnoA DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAM AAAA+Q8EAAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE8NIAAAASAArwCAAAAAMQ AAAACgAAgwAL8DAAAAB/AAEAAQCAABDySjaBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAB AgIAAAgAABDwCAAAAAAAkAngECABDwAR8BAAAAAAAMMLCAAAAAEAAAAHAHoADwAN8FoAAAAAAJ8P BAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAAD4DwQAAAAA AAAAAACqDxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATwZAAAABIACvAIAAAABBAAAAAKAABjAAvw JAAAAH8ABAAEAIcAAQAAAH8BAAABAL8BEQARAP8BCAAJAD8CAQABAAAAEPAIAAAAsAHQAhAOIAoP ABHwEAAAAAAAwwsIAAAAAgAAAAUAegAPAATwFgEAABIACvAIAAAABRAAAAAKAACDAAvwMAAAAH8A AQABAIAAIPdKNoEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAsApA AqAO0BQPABHwEAAAAAAAwwsIAAAAAwAAAAYCegAPAA3wngAAAAAAnw8EAAAAAgAAAAAAqA9SAAAA Q2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVs DUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMA DAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8NYAAAASAArwCAAAAAYQAAAACgAAkwAL8DYAAAB/ AAEAAQCAAND9SjaHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDw CAAAAGAVAABQB4AWDwAR8BAAAAAAAMMLCAAAAAQAAAAJAnoADwAN8FgAAAAAAJ8PBAAAAAQAAAAA AKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+g8EAAAAAAAAAAAAqg8SAAAA AQAAAAEAAAAAAAEAAAAAAAAADwAE8NgAAAASAArwCAAAAAcQAAAACgAAkwAL8DYAAAB/AAEAAQCA AGADSzaHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAV kAngEIAWDwAR8BAAAAAAAMMLCAAAAAUAAAAIAnoADwAN8FoAAAAAAJ8PBAAAAAQAAAAAAKAPAgAA ACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAADYDwQAAAAAAAAAAACqDxIAAAABAAAA AQAAAAAAAQAAAAAAAAAPAATwSAAAABIACvAIAAAAARAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAA CJMB3r1oAJQBjp+LAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAA AAAAAADMmQAzM8wAzMz/ALKysgAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLExAAAAAAAOsuCAAAAM0TdwAAvowbDwDuA40CAAACAO8DGAAAAAAAAAAPEAAAAAAAAAEA AIAAAQAABwByYA8A2Q8MAAAAAADaDwQAAAAAAC0ADwAMBJQBAAAPAALwjAEAAEAACPAIAAAAAwAA AAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAA BQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/AeAAAABAAAAAAAgABAt4AvvwEAAAEA/wEA AAEAAQMCqAAAAAAQ8AgAAABABQAAgBYQCA8AEfAQAAAAAADDCwgAAAAAAAAADwB6AA8ADfAMAAAA AACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAgAgAAUwAL8B4AAAAEAAAAAACAAFAf9zK/ AQAAAQD/AQAAAQABAwOoAAAAABDwCAAAAPAJEAJwFEAODwAR8BAAAAAAAMMLCAAAAAEAAAAQAHoA DwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAQgAAAAMAACDAAvwMAAAAIEBAAAA CIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAA AACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAIgTjQAAAA8AihOFAAAAAAC6DxAAAABfAF8AXwBQ AFAAVAAxADAAAACLE2UAAAAAAB0QBAAAAAAAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAA AAAAAAMAAAAAAAAAAAAAAAAAAAAA/7oQ/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIr AAAAAA8A7gMhKAAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAQEAAAcAcmAPAAwEwAEAAA8AAvC4 AQAAgAAI8AgAAAADAAAABgwAAA8AA/BQAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA/////wAC AAACAArwCAAAAAAMAAAFAAAADwAE8HIAAAASAArwCAAAAAIMAAAgAgAAUwAL8B4AAAAEAAAAAACA AODlTDa/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAPAAsAHQFMADDwAR8BAAAAAAAMMLCAAAAAAA AAANAHoADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwngAAABIACvAIAAAAAwwAACACAABTAAvwHgAA AAQAAAAAAIAAwKtMNr8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAAIASwAfAVQA4PABHwPAAAAA8A FBAkAAAAAQDxDxwAAAAAAAAHAAAAAAAAAAAAAAAAAgABAAIMAwAAAAA8AADDCwgAAAABAAAADgC8 IA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEMAAAADAAAgwAL8DAAAACBAQAA AAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAA AAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwCIEwkmAAAPAIoTASYAAAAAug8QAAAAXwBfAF8A UABQAFQAMQAwAAAAixPhJQAAAAAdEAQAAAAAAAAAAAAAKwQAAAAheQa8HwBE8YElAAAAACfxIAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAECAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAAHwBE 8TwlAAAAACfxIAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAP////8YAAAADwA98Q0AAABAAULx BQAAAAEEAAAAAABB8RQAAAABAAAAAQAAAAAAAAAAAAAAAwAAAD8AJfEsAAAAAAAo8RAAAAABAAAA CQAAAAAAAAAAAAAADwA88QwAAAAAAAErBAAAAAEAAABPACXxLAAAAAAAKPEQAAAAAQAAAAoAAAAA AAAAAAAAAA8APPEMAAAAAAABKwQAAAABAAAAHwBE8SEMAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMA AAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA//// /x8ARPHJCwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAA HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQEAAACQAELxBQAAAAECAAAA oABC8QUAAAABBAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAA AAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAA ABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBs AGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0 AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMM AAAAAAAAHQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAA AAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAA AQAAADgAAAABAAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAA QvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8A KvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgA AAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAADDAAAAAAAAB0AAAAfAETxGQEAAAAAJ/EgAAAAAAAA AAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAA OAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIA AAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAAD AAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQA XwB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAAAAAAAdAAAAHwBE8csDAAAAACfxIAAA AAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC 8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAA AAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAA AAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2 AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAA QvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAA AgAAAAEAAAADDAAAHQAAADUAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPER AQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8dkA AAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBwAHAA dABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC 8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAAD cABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAB0AAAA1AAAAHwBE8RkBAAAA ACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAAAAAA NPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBwAHAA dABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeQAA ABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvEN AAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAAAdAAAANQAAAB8ARPHL AwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUA AAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAA AAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAA EABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAA HwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwA AAAAAPsqFAAAAAIAAAABAAAAAwwAADUAAABkAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA AAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3x AAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAAQvEP AAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0 AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAA AAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAAA1AAAAZAAA AB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAA DwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcAAAAD MQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBw AHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+ 8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAADDAAANQAA AGQAAAAfAETxIQwAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x AAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8ckLAAAAACfxIAAAAAAAAAAA AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAA AAAAAAAAAAAAAB8ARPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA AA8APfFBAAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAAB AQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAA AAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAA ADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAE AAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBs AGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAGQAAACBAAAAHwAl8RgAAAAAACjx EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAA AAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAA Q/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAA AELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAA AAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAA AQAAAAMMAABkAAAAgQAAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0 AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQA AAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADo AwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAA AAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAA AgAAAAEAAAADDAAAZAAAAIEAAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAA AAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAECAAAAoABC8QUAAAABBAAA ALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA AAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAA AA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAA AAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBp AHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAACBAAAAnAAAAB8A JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAA AAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAA DwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD 8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAA AAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA +yoUAAAAAgAAAAEAAAADDAAAgQAAAJwAAAAfAETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAA AAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/x ZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMA AAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAA M/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwA AAAAAPsqFAAAAAIAAAABAAAAAwwAAIEAAACcAAAAHwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAA AAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAgAAAKAA QvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAA AAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZ AAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABl AAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5 AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAADDAAA nAAAACgBAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAA AAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEA AAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELx AwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrx WQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAA DwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAJwAAAAoAQAAHwBE8RkBAAAAACfxIAAAAAAAAAAA AAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgA AAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAA EABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAA DwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8A eQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAACcAAAAKAEAAB8ARPEhDAAAAAAn8SAAAAAA AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAA AAAAAAAAAAAAAP////8fAETxyQsAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA AAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8csDAAAAACfx IAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAEBAAAA kABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEY AAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMA AAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAA AAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAA AAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoU AAAAAgAAAAEAAAADDAAAKAEAAEUBAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8A RPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr 8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBw AHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAA EABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0A AAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAACgBAABFAQAAHwBE8RkB AAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAA AAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBw AHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8A eQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAA QvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAAAoAQAARQEAAB8A RPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC 8QUAAAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAA AQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAA AAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAAB AAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAA AAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA8 8RwAAAAAAPsqFAAAAAIAAAABAAAAAwwAAEUBAABhAQAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAP AD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAA QvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAA cAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7x FQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAABFAQAA YQEAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEA AAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcA AAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAAD IwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAA HwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAADDAAA RQEAAGEBAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP AD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAECAAAAoABC8QUAAAABBAAAALAAQvEFAAAAAQEA AAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAA J/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA6 8QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAA AAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABp AHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAMMAABhAQAAhwEAAB8AJfEYAAAAAAAo8RAA AAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAA APQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8VwAAAAAAEPx BAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC 8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAA AAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEA AAADDAAAYQEAAIcBAAAfAETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEA ABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAA AAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMA AAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAA AAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwAAAAAAPsqFAAAAAIA AAABAAAAAwwAAGEBAACHAQAADwACKzgAAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAADDAAAAQAA AAEACSsQAAAAAQAAAAEAAAAAAAAAAAAAAA8A7gNSJAAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACA AgEAAAcAcmAPAAwEtAEAAA8AAvCsAQAAMAAI8AgAAAADAAAAA9QBAA8AA/BEAQAADwAE8CgAAAAB AAnwEAAAAAAAAADTwbGhAACxodPBsaECAArwCAAAAADUAQAFAAAADwAE8GwAAAASAArwCAAAAALU AQAgAgAAQwAL8BgAAACAANBF/TK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAJAAsAHQFGADDwAR 8BAAAAAAAMMLCAAAAAAAAAANAHoADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwmAAAABIACvAIAAAA A9QBACACAABDAAvwGAAAAIAAoEX3Mr8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAAwANQASAW4A0P ABHwPAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHAAAAAAAAAAAAAAAAAgABAAIMAwAAAAA8AADDCwgA AAABAAAADgC8IA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAHUAQAADAAAgwAL 8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAH IAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwCIE0YiAAAPAIoTPiIAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAwAAAAixMeIgAAAADrLggAAACpFHcAAFrJGgAAHRAEAAAAAAAAAAAA ACsEAAAAIXkGvB8ARPGuIQAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAABAgAD/////EgAA AA8APfENAAAAQAFC8QUAAAABCQAAAB8ARPFpIQAAAAAn8SAAAAAAAAAAAAAAAAEAAAAAAAAAAAAA AAAAAAD/////GAAAAA8APfENAAAAQAFC8QUAAAABBAAAAAAAQfEUAAAAAQAAAAEAAAAAAAAAAAAA AAMAAAA/ACXxLAAAAAAAKPEQAAAAAQAAAAkAAAAAAAAAAAAAAA8APPEMAAAAAAABKwQAAAABAAAA TwAl8SwAAAAAACjxEAAAAAEAAAAKAAAAAAAAAAAAAAAPADzxDAAAAAAAASsEAAAAAQAAAB8ARPEh DAAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgA AAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETxyQsAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA HwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABA AULxBQAAAAEBAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUA AAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAA AAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAA AAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAA AAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAP ADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAAAAAADAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAA AAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAA AA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAA AABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMA cABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8A PvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAAAA AAAwAAAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA9 8QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELx FwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAA AAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAA AAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPU AQAAAAAAMAAAAB8ARPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA AA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAAB AQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAA AAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAA ADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAE AAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBs AGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBADAAAABPAAAAHwAl8RgAAAAAACjx EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAA AAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAA Q/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAA AELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAA AAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAA AQAAAAPUAQAwAAAATwAAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0 AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQA AAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADo AwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAA AAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAA AgAAAAEAAAAD1AEAMAAAAE8AAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAA AAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAECAAAAoABC8QUAAAABBAAA ALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA AAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAA AA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAA AAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBp AHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQBPAAAAcAAAAB8A JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAA AAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAA DwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD 8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAA AAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA +yoUAAAAAgAAAAEAAAAD1AEATwAAAHAAAAAfAETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAA AAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/x ZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMA AAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAA M/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwA AAAAAPsqFAAAAAIAAAABAAAAA9QBAE8AAABwAAAAHwBE8U4IAAAAACfxIAAAAAAAAAAAAAAAAAAA AAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA /////x8ARPH2BwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEA AAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEC AAAAoABC8QUAAAABBAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAA AAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA AQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkA YgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAAD cwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAA AAPUAQBwAAAAfQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfx IAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEM AAAAAQAAADgAAAABAAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAA ABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMA AA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABf AHgAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAcAAAAH0AAAAfAETxGQEAAAAAJ/EgAAAA AAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAAB AAAAOAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAv ADIAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMA AAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABw AHQAXwB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAHAAAAB9AAAAHwBE8csDAAAAACfx IAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAA kABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEY AAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMA AAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAA AAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAA AAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoU AAAAAgAAAAEAAAAD1AEAfQAAAMgAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8A RPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr 8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBw AHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAA EABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0A AAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAH0AAADIAAAAHwBE8RkB AAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAA AAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBw AHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8A eQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAA QvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQB9AAAAyAAAAB8A RPEhDAAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl 8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETxyQsAAAAAJ/EgAAAAAAAAAAAAAAAAAAAA AwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA AAAAHwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEA AABAAULxBQAAAAEBAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC 8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAA AAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAA AQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAA AAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkA AAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAyAAAANgAAAAfACXxGAAAAAAAKPEQAAAAAAAA AAAAAAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAA GQAAAA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAA AAAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAA AyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAA AB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QB AMgAAADYAAAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAA DwA98QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAA AELxFwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELx DwAAAAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAA AAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAA AAPUAQDIAAAA2AAAAB8ARPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUA AAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4 AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAA AAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAA AAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIA aQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBANgAAAAUAQAAHwAl8RgAAAAA ACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAA AAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAA AAAAQ/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgD AAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAA AAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAAC AAAAAQAAAAPUAQDYAAAAFAEAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAA AAD0AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD 8QQAAAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQA AADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAF AAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoU AAAAAgAAAAEAAAAD1AEA2AAAABQBAAAfAETxywMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAA AAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAECAAAAoABC8QUAAAAB BAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA AAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3x AAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrx bwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4A dgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQAUAQAAdAEA AB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAA AwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAAB AAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAA AABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz 8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAA AAAA+yoUAAAAAgAAAAEAAAAD1AEAFAEAAHQBAAAfAETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAA AwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAP AD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAA AAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAA AAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA8 8RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBABQBAAB0AQAADwACKzgAAAAPAAgrMAAAAAAAAysQAAAA AQAAAAAAAAAD1AEAAQAAAAEACSsQAAAAAQAAAAEAAAAAAAAAAAAAAA8A8APMAQAAAQDxAwgAAAAA AQAABwBAiA8ADASMAQAADwAC8IQBAABQAAjwCAAAAAMAAAADqAEADwAD8BwBAAAPAATwKAAAAAEA CfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAKgBAAUAAAAPAATwWAAAABIACvAIAAAAAqgB ACACAABDAAvwGAAAAH8ABAAEAL8BAQABAP8BAQABAAEDBBAAAAAAEPAIAAAAsAHQAhAOIAoPABHw EAAAAAAAwwsIAAAAAAAAAAsAegAPAATwhAAAABIACvAIAAAAA6gBACACAABTAAvwHgAAAH8AAAAE AIAAoFxLNr8BAQABAP8BAQABAAEDBRAAAAAAEPAIAAAAsApAAqAO0BQPABHwEAAAAAAAwwsIAAAA AQAAAAwAegAPAA3wHgAAAAAAnw8EAAAAAgAAAAAAqg8KAAAAAQAAAAEAAAAAAA8ABPBIAAAAEgAK 8AgAAAABqAEAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A8APM AQAAAQDxAwgAAAABAQAABwBAiA8ADASMAQAADwAC8IQBAACQAAjwCAAAAAMAAAADrAEADwAD8BwB AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAKwBAAUAAAAPAATwWAAA ABIACvAIAAAAAqwBACACAABDAAvwGAAAAH8ABAAEAL8BAQABAP8BAQABAAEDBBAAAAAAEPAIAAAA sAHQAhAOIAoPABHwEAAAAAAAwwsIAAAAAAAAAAsAegAPAATwhAAAABIACvAIAAAAA6wBACACAABT AAvwHgAAAH8AAAAEAIAAwGJLNr8BAQABAP8BAQABAAEDBRAAAAAAEPAIAAAAsApAAqAO0BQPABHw EAAAAAAAwwsIAAAAAQAAAAwAegAPAA3wHgAAAAAAnw8EAAAAAgAAAAAAqg8KAAAAAQAAAAEAAAAA AA8ABPBIAAAAEgAK8AgAAAABrAEAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADM zP8AsrKyAA8A8AP0AQAAAQDxAwgAAAAYAQAABwBAiA8ADAR0AQAADwAC8GwBAABwAAjwCAAAAAMA AAAD2AEADwAD8AQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAANgB AAUAAAAPAATwUgAAABIACvAIAAAAAtgBACACAAAzAAvwEgAAAL8BAQABAP8BAQABAAEDBBAAAAAA EPAIAAAAsAHQAhAOIAoPABHwEAAAAAAAwwsIAAAAAAAAAAsAegAPAATwcgAAABIACvAIAAAAA9gB ACACAAAjAAvwDAAAAIAAQIFMNgEDBRAAAAAAEPAIAAAAsApAAqAO0BQPABHwEAAAAAAAwwsIAAAA AQAAAAwAegAPAA3wHgAAAAAAnw8EAAAAAgAAAAAAqg8KAAAAAQAAAAEAAAAAAA8ABPBIAAAAEgAK 8AgAAAAB2AEAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBM4 AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAArRR3AIB9 IbsQABEQYwAAAAAGAAB4nLtwXvDBwo1SDxnQgB0DM8O//5wMbEhijFAMBgIMQPn//0FMGA0C/0fB kAJ/gfjfQDtiFAwYYAhCz/mkASYGVpQ8j1fxstOsX4+dYvxHSB2JgGj7aQSGsv0A5NrzzQAAchc8 AAAAAQBQAAAAAAAoLwAAXEMAAPFFAAA6PQAAKQAQADs4AABpACAAdJIAAEiUAAB2ADAAGm4AAByW AAAYmAAAAAD1DxwAAAAAAQAAByIAAwAAAACDmAAAAQAAAHgAAAABAMdoDwDoAyIvAAABAOkDKAAA AIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAUAAAAAAAAAAQAAAAABAAEPAPIDrgEAAC8AyA8MAAAA MADSDwQAAAAAAAAADwDVB+QAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBu AAAA/78wwwAAEABafEDY/78Ix/+/MMP/v8j1kXyc9gAAAAAAAATgEAC3D0QAAABDAG8AbQBpAGMA IABTAGEAbgBzACAATQBTAAAAbgAAAP+/MMMAABAAWnxA2P+/CMf/vzDD/7/I9ZF8nPYAAAAAAAAE 4CAAtw9EAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAU4EAAACCAAAAgwAAAIQAAACFAAAAhgAA AIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAAD+//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAA AgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rnQCAAAwAgAAEAAAAAEAAACI AAAAAwAAAJAAAAAPAAAAqAAAAAQAAADMAAAABgAAANQAAAAHAAAA3AAAAAgAAADkAAAACQAAAOwA AAAKAAAA9AAAABcAAAD8AAAACwAAAAQBAAAQAAAADAEAABMAAAAUAQAAFgAAABwBAAANAAAAJAEA AAwAAADOAQAAAgAAABAnAAAeAAAAEAAAAE9uLXNjcmVlbiBTaG93AAAeAAAAHAAAAERlbGwgQ29t cHV0ZXIgQ29ycG9yYXRpb24AAAADAAAAq+wAAAMAAAAXAAAAAwAAAAMAAAADAAAAAwAAAAMAAAAA AAAAAwAAAAAAAAADAAAABQMLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAcA AAAQAAAAVGltZXMgTmV3IFJvbWFuAA4AAABDb21pYyBTYW5zIE1TAAwAAABDb3VyaWVyIE5ldwAP AAAARGVmYXVsdCBEZXNpZ24AMQAAAERyYWZ0IFN0YXR1cyBVcGRhdGUgZHJhZnQtaWV0Zi1saXNw LW11bHRpY2FzdC0wMgAOAAAARHJhZnQgSGlzdG9yeQD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAAB AAAA4IWf8vlPaBCrkQgAKyez2TAAAABsJwAACwAAAAEAAABgAAAAAgAAAGgAAAAEAAAAhAAAAAgA AACcAAAACQAAALQAAAASAAAAwAAAAAoAAADgAAAADAAAAOwAAAANAAAA+AAAAA8AAAAEAQAAEQAA AAwBAAACAAAAECcAAB4AAAAUAAAATVJJQiBEZXNpZ24gUmV2aWV3AAAeAAAAEAAAAERpbm8gRmFy aW5hY2NpAAAeAAAAEAAAAERpbm8gRmFyaW5hY2NpAAAeAAAABAAAADQzNwAeAAAAGAAAAE1pY3Jv c29mdCBQb3dlclBvaW50AAAAAEAAAADgz63bUQEAAEAAAAAAoQfnsdS/AUAAAACAoEn6L8fKAQMA AAB7AAAARwAAAFgmAAD+////UElDVCZQAAAAAACHALQAEQL/DAD//gAAAEgAAABIAAAAAAAAAIcA tAAAAAAAHgABAAoAAAAAAIcAtACaAAAA/4LQAAAAAACHALQAAAAEAAAAAABIAAAASAAAABAAIAAE AAgAAAAgAa5BaBemHgwAAAAAAIcAtAAAAAAAhwC0AAAADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8AZoH/qP8C vaf78P8D3lEz9/b/Avvr8+D/ANr9/wHn5/f/Avdc+6j/AZvH7/8CvTNm9f8C9+v34f8B9979/wHa 9/f/Adp4qP8C+9zz7/8C3czi9f8C+/j+4f8B9vn9/wDw9v8B4eXM/wC4gf+o/wRcMzOU8/L/BjNa q939sq36/wCn/jMEdv//3n/4/wGyrfH/AuMz5/7/AmaE+fj/A9Uz1v78/wL7b/ey/wD3/jMArfL/ B+szgLbi/3je+/8B94f+MwSx//+trfj/AXje8f8IsjP3///7M8X9+P8Cm0/k+/8B43+x/wTvzMzR 7fL/B+nM19rr/NX8+/8B9tP+zAT0///Y8/n/AvzV/PH/B9Xa+///8szw9/8C0Nfu+/8B5eXV/wDy gf+o/wVca5czM9P0/wj3M9Pg8f+Of+38/wvCM7jTwcHk/8wz4vv6/wiOf+3/+/v///v+/wLrwu/+ /wnRM9P7//9Rhebn+f8D1ULd/Pz/A+8z0vmz/wb3M5J9M0Hz9P8I1TPd5vT/M7P3/P8KfzPJ073M 7v+Ofu35/wQzs/f/9/7/APv+/wHjwv3/CZVB3f//8zO27+/5/wKbg9/7/wPMM+X7s/8F78zWz8zV 8/8I3dfd6vj4zOD8/P8KzNXe29jc+P/O2/f6/wj4zOD8//z///7+/wL+8O39/wnQ1Of//+/M3Pf8 +f8C0Nnp+/8C3Nbu1v8BRIH/qP8XUYTk6nEz3tpRlTNR/+NRM1Hnx1wzM1Dj/TMAzP3/BpszzOv8 9/P9MwaN/pszM5vn/TMpzJuN/usz8tVDMzOp+///1TPT/P//UYTdM20zZvf/zDMzQ0/e93gzM8d/ /jMGQ/7jMzNR3rn/GPczuuvZM0D8oX9vM47/xzMzb/+bUTMzh739MwDz/f8GUV7X8Pz23v0zBsz3 eDMzzL39MwfzQ8//wkP+rf4zANr+/w+bQd7///cztsgzbjOV//+h/jMGiefjUTNR6/0zBo7+wjMz Zve5/xjvzNzx28zT/9Xfzszs/9/MzOH+187MzOrY/swBzv7+/wf5zNPj+Pv14/3MBvn10MzQ9tj+ zAjO+sz3/9jf/tr+zADy/v8P0NPp///vzNvczNHM7P/+2P7MBtn06szM1/T9zAXt/93MzNzc/wFQ gf+o/x1RhOj//kCD0DNKtjPEM227M7O5WECcqdzQamq91/P+/wDa/TNFzP/djT+6zI4zsn0/5tBq ar3XYonn0TPTUFnNja3u///VM9D8//9chN0zP5szhekzmro/U99cM79KfduvM63F3jOKwTOJ97r/ HvcztvX/5zO2mzN0mzO+M5qlM9mVM1ycttzFM5LB3fz+/wCn/jNGW+v/0GpqvddOM8NKfejFM5LB 1zO29JVC1zOL02rM+f//mzPe///3M7bMM2OWM8PCM7epM4PdM227M7PajTO6zNUzs60zvv26/x3v zNv9/+PM5dPM2NDR2cze0c3o2MzR1Nrr28zW2t79/wDX/sxF2vz74s3T2dvM1dnM2PHbzNba2czb +9DV4Mza2tDd/v//0NLp///wzNvdzNHSzO/Y0N7TzNfmzNvVzODsz9DY3OLM4NLM5d3/AU6B/6j/ HVyE6P//oVPDM9ffjpIz3dwzuvPNM97u8f6bXuT2/f3/SfbQwWoz7P/TM9vuM63dn1be/pte5PZb hejVM9NQM2Ta6vL//9Uz0/v/+zO03TPQ3pFqmWTd6slAwDPL3WOO5/EzwfLQM6lBM7rpuv8d9zO2 9P//UI2VVt3MoVN73cAz1/yOd+Lu9PxOl+v3/P9J5NC2M1T6/5Ve5NIzzt1ajuf8Tpfr8DO29JtB 1zMzfPTk+v//oUHd///jM9PMM93jQaVZn93yh32ZM93gM73z0zPd9ZhQnDNC0/W6/x3vzNv7//zM 2M/V3d7czNzd19Df/c7X5+749szZ8vj8/0nj29TM1v38z9Tr3czd48zY8/bM2fLqzNv70NPgzM3a +OX+///R0+f//+XO3dzV3ebM2czf3/XN19LX3eLM3Prb0OX20NfSzNPd/N7/AU2B/6j/FVGP6P// f324Qt39/45g3fszxfXRQt3+/wKbQeL8/yHz///77DPQ/dUz0PYzvfCtaOD/m0Hi/4eE6NUz0/Sd WzPc/v8l9zO6/P/jM8noM9f7oVaGfeL/2kK6M9f5b5/q8zOy99UzM5nb3fW6/xb3M730//8zs4mJ 4P/4QZTl4zPd/ZWD5v7/AlGE7f3/Ivf7//37wzPg/5tB4toz2vpmnur/UYTt/zO29JtB3umSPzP5 /v8l1TPX//+tM93TQt3/UY4ztOv/m4KTV937M8X21TPT/5szM7bd3vy6/xzvzNz7//bM28/Z6//u zNjx5NHi/9DZ9P//+8zX9/3/Ifv///z61dLq/9DS7d/Q3f7M2vX7zNf39szc+9HT6erSzNP9/yTf zun//9XU3t3W5/zM18zb9//Q2NDV5vPM3fzfzuP/0czQ4d3l3f8BToH/qP8VUavq/8czr8FC3v// pzPb8zOp+NFC3v7/AptM3v3/I9Ez3P/veDPX+9Uz0/MznPatM+P/m0ze/5Vu4b0zw6v53DOy+P7/ JGU/4vtcWt3uM7LhQ4mwM8Xzb0++M8H9eHru8zO289ozrd3MQ/O6/xb3M8z2/5UzzI6C6P//XGvr 2jPQ/5WC5/7/AlGE6P3/So5D8v/jQ1nd/5tB3tozwf54c+7/UYTo/0OX7YdMtsf6uDPT/v//9zNq +eczkd3VM8bRM7d9P+TjM4mTM9nzM6341TPT/KEzyd29XLn/HO/O3fz70c/dz9n0//zM1PbkzeT/ 0Nn0///7zNf0/f8iztv+/uzM1+j/0NPo4czh+8zW+PvM1/T7zNj3ztPa8/bUzeX+/yTwzNX/7Mzb 5d3R5eTM3M3R+OzM2dLR6/LM2/7fzt//0c/c4drf3f8BQIH/qP8MbzNCMzOH3cYz3v//8/0zBFPx 0TPe/v8CmzPf/f8B9079MwfD3f3VM9P8rP0zBrr/mzPf/9X9MwC5/TMB0PP+/wHrS/4zAtLg8/4z A0LR6Hr+MwJL33T9Mwbf8zO29P+Q/jMCdN78u/8N9zMzQzMzsd2Lguf//9r9MwSN+5WC5/7/AkN+ 6P3/AOP9Mwhk1OD/lTPe/2z9Mwbe/0N+6P+h/jMBQJj+MwJq3fz+/wDU/jMDbd3p1f4zA3Pd6UD+ MwGD3f0zB1Py1TPT/PtW/jMBn+C6/w3wzMzOzMzd38zZ9P//4f3MCtn/ztj0///7zNf0/f8A6f3M B9nd6//O0un7/cwHzvL7zNf0/9P+zAHS0f7MAdff/f8A3/7MA9vd9N/+zALa3fD9zAHX6P3MBtP6 3c3f//X9zAHg6d7/AUWB/6f/CLqXmMXd5/fR3f7/CPjB0NrF4Npz3f7/AvfT3fz/Iv3Owcnd3fb/ /9bd/P/bwd3F2vX3093//+bF0Lbd6r3B2t37/f8j+s7M2t378zPJ0N3e+//TzN3X3//Lyd3B3f3c 2vT//9rM093kuf8J+a2SptDd8efR5/7/COu919DQ6qeZ5/7/AufU5/z/IfjFwczd4vz/99Ld///K xd3B3f3n1Of//9TJycHe273F3eP8/yP1zMzd4//VM9fQ3eT//MnQ3dro+L3Q2sXg/9bd/P/+z8zX 3eu5/wnw1dPX3d358tz0/v8I59nd2t3219nz/v8C8d30/P8h7trZ3N3o///23ej/+9nb3Nri//Hd 9P//3dvY2+jf2Nvd6vz/I+vb293q/93V3Nzd6//12tzc3fTy2dzb2+v7497///jb293d9d7/ASKB /6b/B/Tt7fj///32/f8H/vf7/vj/9uT9/wH9+fr/Avr3+fz/APf+/wf69//4/v/9+f7/CPv4+/T/ /Pb3/vr/CPr6/v/zM9P5+/3/Dfr6//3///j5//f///f+/v8C+/r8t/8I/vLr8Pv///n5/f8H/Pb9 +/v/6+v9/wH5/Pr/Avj3+v3/Af35/v8H+Pj/9///+fz+//75BPf/+vb4+f8I+vr//9Ez3f37/f8M +fv//v/+9vv++P//9/3/Avr6/bf/CPvw6/L+///2/f3/B/r3//j+/+T2/f8B9/77/wP9+Pf8/f8M +fz///73+/35///3/v7/B/j69vv/+fb6+v8J/fr7///d1ef9/P7/Df74/f3///z3/fv7//z5/f8B +vrc/wAdgf+B/9r/A/cz0/yB/9H/AtUz3YH/0P8C39Xow/8AGoH/gf/Z/wL93fyB/9D/AfXdgf/P /wHp6MP/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B /4H/sf8A2oH/u/8B44f0/wXaf4fr/+P3/wHMwvn/AfPv/P8ClYey+/8C43ja/f8Af+P/Asx48/7/ AOP8/wGb6+7/AOP3/wh/b9r//6d/h/vh/wG9rfT/BbJ/lf//5/f/AZXv+f8B5/v9/wPzf4fV+/8C x3jz/v8B847j/wGhh/3/AOf8/wB47f8A5/j/COtvePf/+4d/p+D/Ad3y9P8F3drl//v59/8A2Pj/ APX8/wPw2Nr4+/8B4dz9/wHt7OT/Avza5f7/Afv5/f8B+d/u/wH7+fj/CO3V3f//+NjX7/L/AVWB /7z/A/f/uOb6/wD3/f8Gh/bl5vp4+Pj/Avvv8f7/APP+/wLMwPv+/wTVvejm7vv/Aum39v7/AfPl /v8B9/v9/wD37f8Gx8/8//94+P3/Avfp+v7/APP9/wD3/f8B9/v+/wF4+Pn/CrLV5Wz276frwLD+ 4/8D8/+j7fr/APP+/wf7ju7l6POH+fj/Avfo+/7/APP+/wKH6v7+/wSb6OXm9fv/AsbS/P7/AfDn /v8A8/z/APPt/waf5v//84f5/f8B8+T+/wH79/3/APP9/wDz/v8C84f5+f8Jh/bShv3M0OaS2eL/ A/z73/b6/wD8/v8H8Oro5u7s6vv4/wH75f7/Af78/v8B1/j9/wTY9eXm+vv/Advn/v8C/vLy/v8A +/z/APzu/wf92e7//+zq+/3/Afjp/v8A/Pz/APz9/wD7/v8C7Or7+v8K/trz2d//4fbl0vTz/wGp gf+9/xmhf3eH8KeOh2/r+5Wbf/f/pzOHp//HM4aV9/v/FOd/rP7/+4eVduP7ZmKNx//nXGOG5/r/ E+vJ8///rW/w//+yjoab+39/h3fn/P8w1UNvf1zewqf/h9X//9Hh+f/HM4aV9//Mb9T//+NvlUPv +5Wbf/f/so6Gm//HM4aV9/v/CqHf9a3h//vrvcnx5P8Yf452p+qHoXh//+uHlZP/+39DiMz/lTOH p/r/FMxv2P//53iVfvvnM3uM5//MM32S+/r/E8zh+v/7lX/8//+Om2XR529/jn77/P8vrUN4eFz7 ldXrb/P//63t//+VM4en//+nb/T//8J/hlv/64eVk///jptl0f+VM4en+v8Kh+b+nuj/8/SO3/rl /xn419rW7e3Y4dXi/+3c3On/9tHT1/b/09HX7fr/E+TV+P//7dja4P/szNTd/P/izNPk+f8S5e7/ //bY4/7/+9jf0fns19ja4fv/CdrR19Xc/Nj87dr+/yLl7v//09HX7f/83dr9///f2tXf/+3c3On/ +9jf0fn/09HX7fv/Cvni5vji9P/q+9rm8/8B1YH/vv8b3q3q5Wbm/3fg5uP61bGJ0/3/d93o6/96 3ejo9f54F47///GB7f+ym8W2ZvjQteLo8v/MtOLn8f54BY7//+vI8/7/DpHS/P+np8LF6dCz5eOM 8f54Mo7/ptuA3rD3pOvzufX/0eH6//963ejo/f/HrvX/h/jjy9T71bGJ0/2np8LF6f963ejo9f54 DI7/p+f7m97+/72b8PTl/3+y3uXVgOv2derk5f/DtHXo//aH3ujz94jd6OvjZnhvsv//x7L2/3i+ w46X/pjT5uf5/47T5ujiZnhvsv//zOD6///+buX//3+5v9H0mNnlyrPiZnhvsvO+ure/z/K69dHS /P+t7f//94jd6Ov//4rV/feH8eW54P/DtHXo/3+5vxfR9PeI3ejr42Z4b7L/m+b/f+r//4fM5/zl /z7c+eTa2/Tr2Orj6/vj29fx/+nZ4+f57dvi5/Pp1dfV8v//2OD8/9Ho39Dj/9bd6Oj9/9Td5+3p 1dfV8v//5e7+/1T11O3/+Nnd3+D71+Tl2efp1dfV8u/k0+PW5+3h/d/m///l7v//7dvi5/P//dPm //Dp6ebb6fvj29fx+Nnd3+D77dvi5/Pp1dfV8vjo6/ne8v/81ffm8/8BzoH/vv8T2rft/3jj/73l /f/RrfGp3fr/f+X+/wF45f7/AP3+5A7n//eU5/+9otPf1+PHw/P+/wXVw/P///3+5ATn//PN8/7/ D6He+v/n5Mx09sy18vOb6f3+5BPnveab4M/ysu3rzvP/1eX6//945f3/FtHD8f9/5v//8M6t8and +ufkzHT2/3jl/v8A/f7kCuen0f6b6futsvDp5P8Yp9j375Ln89Tl//+b2u6U5f/3lOj//++U6P7/ Evji5OPu/9HD8v9/v9bb1+uO4vz+/w2b4fz///ji5OPu/9Xo+v7/Jnjk//fv27mV+pXT/NHB8vji 5OPj08fJzObnzvPH6vr/su3//++U6P3/FpXh+/ON5v/775va7pTl9+/buZX675To/v8O+OLk4+54 6f+b5f+H4+bz5P8Y3Of+6uTz8PLu///a9ezd6v/v5vT//+zm9P7/EfDj5OP2/9/n+v/V3O3u4PfY 5v3/Adrm/v8H8OPk4/b/6e7+/yf73+j/+fbj2ej+2Of/4en68OPk4+ry3ufk7e3x+uTu///p7v// 7Ob0/f8W2uX/7eXw//z02vXs3er59uPZ6P7s5vT+/w7w4+Tj8tnx8+vq+dj84/rz/wGzgf+9/xmJ mIdmsZtvjdX/2oiRQ5L8rUOHx///oYyOsvv/FLKOUI7393mckZj473Kgf/fnZmuU9/v/FbKOdpX3 65VcfcX/XJigluTVenl/7On9/zDVZt1b1430h5dcffCbf4Kl//+hjI6y+6F4a6X/0W2nZuPYiJFD kvxcmKCW5P+hjI6y+/8J82iKp+nVM5x/0eT/GvtgqXhlv4d2j+//rZSJM7f7h1CI4///dpl43vv/ E5t4a6D/422mfL360Xyajv/MQ4Om+/8W+5t4iaX/0ZVDhuPzQ6qFwemndYSO9PL9/zCnjM2CzKzz dptDpeiVb4zH//92mXje65VRfMb/n4Kbb/qslIkzt/NDqoXB6f92mXje+/8J1XR42umVXJh17+T/ GvPR4tfV5dfY4P7/3NfVz+f209Tb/P/41d3Y/Pz/FPjf0dTr/+rS4NXw/OHV3On/5M7V7Pv/Fvbf 1djs/+Xcz9f87dPi1uT13NLY5er6/f8w2OXe3+Dm8NfbzOPv3dXY9f/41d3Y/O/dztT1/9Xb2t39 3NfVz+ft0+LW5PX41d3Y/Pv/COHU1fPzztnW2vL/Aa6B/7z/Gdnj5t/x6ePo9f/v2enb6fvt2+Xy ///Y4ufu+/8U7uff6f390+To6f/z0uvl/fni4+n9+/8Q7ufk6f366ODm8v/S2+rp0eb+5QD7/P8w 9eL64Prn/9Tq3eX+6eXm6///2OLn7v7q5OPt/+3S6+L479np2+n/0tvq6f//2OLn7vv/CfzV5+v/ 9d3r5vTk/xr+0e3k4vTm5Oj7/97j59ry+ubY6Pj//9Lo5Pf7/xPp5OPr//jS6uXx/+Xc6ef/897n 6/v/FP7p5Ofr//To3uj4/M3m5vOt6+Xm5/v/MOvn9eb17vXW6tvt+ujj6PL//9Lo5Pf66N/m8v/f 2enj/t7j59ry/M3m5vP//9Lo5Pf7/wnu3uT2/+jg6+T75P8a9uHr4+Xy5Ofq/v/k6uTf+fjh4+n9 //fi6+X9/P8U+ung5vP/7+Pt5Pn/5ufn8P/t3ujy+/8U+enj6PL/7uff6f3y3+zk+uXn5eXu+/8w 5fLp8+r38uXn3fX06OPo+P/34uvl/fTo3uf4/+Ln5uj/5Ork3/ny3+zk+v/34uvl/fv/COfn4/z/ 3ubq5vP/AOqB/7v/A/v9//77/wj9+//+//7//v7+/wH6/fP/Afr9/v8B/fro//77Ao6C3/H/Avr/ /vn/Afr9+f8B/fr+/wf9+//+///7+/3/Afr9+P8A+9v/APr4/wf7/f/+//7//f3/Afr+8/8B+v7+ /wH7/Oj/Bfr953+F+/L/A/37//75/wH6/vn/Afz7/v8H+/3//v//+v39/wH6/vn/Af393P8D/vv/ /vr/Afv+/v/+/v7/Af378/8B/fv9/wH6/en/Bf76/uzY2/H/Afz9+P8B/fv4/wH7/P7/Afv+/v8C /vr+/v8B/fv4/wD77P8AHoH/gf/y/wP+5+b4gf/R/wP55ef+gf/R/wLy5eur/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8AeYH/mf8AAPr/AAD6/wAA+//7AAH///oA8f/9AAD//AD8/wQA//8A//4A mv8AAPr/AAD6/wAA+//7AAH///oA8f/9AAD//AD8/wQA//8A//4Amv8AAPr/AAD6/wAA+//7AAH/ //oA8f/9AAD//AD8/wQA//8A//4Azv8Au4H/mv8FAAD/AP8A/v8CAP8A/f8EAAD//wD9/wIA/wD8 /wIA/wDx/wAA/v8IAP//AP//AP8A/v8GAP8A//8AAJj/BQAA/wD/AP7/AgD/AP3/BAAA//8A/f8C AP8A/P8CAP8A8f8AAP7/CAD//wD//wD/AP7/BgD/AP//AACY/wUAAP8A/wD+/wIA/wD9/wQAAP// AP3/AgD/APz/AgD/APH/AAD+/wgA//8A//8A/wD+/wYA/wD//wAAy/8AnYH/m/8DAP8A//gAAP/5 AP3/AQD//gD+/wEA//4A8/8AAP7/AgD///wA/f/+AAb/AP8A/wAAnP8DAP8A//gAAP/5AP3/AQD/ /gD+/wEA//4A8/8AAP7/AgD///wA/f/+AAb/AP8A/wAAnP8DAP8A//gAAP/5AP3/AQD//gD+/wEA //4A8/8AAP7/AgD///wA/f/+AAb/AP8A/wAAzv8A04H/nP8RAP8AAP8A/wD/AP8A/wD/AAD//gAB /wD9/wIA/wD9/wMA//8A/P8BAAD5/wAA/f8AAP3/AAD7/wkA/wAA/wD/AP8Anf8RAP8AAP8A/wD/ AP8A/wD/AAD//gAB/wD9/wIA/wD9/wMA//8A/P8BAAD5/wAA/f8AAP3/AAD7/wkA/wAA/wD/AP8A nf8RAP8AAP8A/wD/AP8A/wD/AAD//gAB/wD9/wIA/wD9/wMA//8A/P8BAAD5/wAA/f8AAP3/AAD7 /wkA/wAA/wD/AP8Azv8AiIH/mf8DAAD///4A/v8BAP/9AAP/AP8A/v/8AP7/AADv//YA+/8FAP8A AP///gCZ/wMAAP///gD+/wEA//0AA/8A/wD+//wA/v8AAO//9gD7/wUA/wAA///+AJn/AwAA///+ AP7/AQD//QAD/wD/AP7//AD+/wAA7//2APv/BQD/AAD///4Azf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wCygf+y/wAA6f8EAAD//wDz//4A /v8DAP//AP7/AAD3/wQAAP//AP7/AADt/wMA//8A+P/+AP3/AAD5/wAAzP8AAOn/BAAA//8A8//+ AP7/AwD//wD+/wAA9/8EAAD//wD+/wAA7f8DAP//APj//gD9/wAA+f8AAMz/AADp/wQAAP//APP/ /gD+/wMA//8A/v8AAPf/BAAA//8A/v8AAO3/AwD//wD4//4A/f8AAPn/AADn/wEGgf+y//4A+v8C AP8A+f8AAP7/AAD+/wMAAP8A9f8AAP7/CAD//wD/AP//APj/BAD//wAA/f/+AP7/AAD8/wAA+f/+ AAL//wD6/wAA/P8DAP//AP7/AgD/AMv//gD6/wIA/wD5/wAA/v8AAP7/AwAA/wD1/wAA/v8IAP// AP8A//8A+P8EAP//AAD9//4A/v8AAPz/AAD5//4AAv//APr/AAD8/wMA//8A/v8CAP8Ay//+APr/ AgD/APn/AAD+/wAA/v8DAAD/APX/AAD+/wgA//8A/wD//wD4/wQA//8AAP3//gD+/wAA/P8AAPn/ /gAC//8A+v8AAPz/AwD//wD+/wIA/wDm/wCggf+z/wIA///zAAD//QD9//0AAP/+APb/AgD///cA 9v/6AAD/9QD5/wIA///7AP3/AgD///MAzP8CAP//8wAA//0A/f/9AAD//gD2/wIA///3APb/+gAA //UA+f8CAP//+wD9/wIA///zAMz/AgD///MAAP/9AP3//QAA//4A9v8CAP//9wD2//oAAP/1APn/ AgD///sA/f8CAP//8wDm/wEAgf+z//wAAP/8AAL/AP/6AP7/AgAA//4AA/8A/wD3/wEAAP7/AQD/ +gD4//4ACP8A/wAA//8A//4AAP/7APn//gAE/wD/AAD8/wIA///+AAP//wD/+wDL//wAAP/8AAL/ AP/6AP7/AgAA//4AA/8A/wD3/wEAAP7/AQD/+gD4//4ACP8A/wAA//8A//4AAP/7APn//gAE/wD/ AAD8/wIA///+AAP//wD/+wDL//wAAP/8AAL/AP/6AP7/AgAA//4AA/8A/wD3/wEAAP7/AQD/+gD4 //4ACP8A/wAA//8A//4AAP/7APn//gAE/wD/AAD8/wIA///+AAP//wD/+wDl/wBAgf+j/wAA/P8A ANn/AAD3/wAA7f8AAJ3/AAD8/wAA2f8AAPf/AADt/wAAnf8AAPz/AADZ/wAA9/8AAO3/AADH/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8AN4H/gf/2/wAA/v8DAP//AP3/AACB/9r/AAD+/wMA //8A/f8AAIH/2v8AAP7/AwD//wD9/wAAsf8AS4H/gf8D/wD/AP3/AQD//gAB///9AAD//QCB/+T/ AgD/AP3/AQD//gAB///9AAD//QCB/+T/AgD/AP3/AQD//gAB///9AAD//QCx/wA+gf+B//YADP8A /wD/AP8A/wAA/wCB/+X/9gAM/wD/AP8A/wD/AAD/AIH/5f/2AAz/AP8A/wD/AP8AAP8Asf8ATYH/ gf8DAP8A//4AAP/+AAL/AP/8AAD//QCB/+X/AwD/AP/+AAD//gAC/wD//AAA//0Agf/l/wMA/wD/ /gAA//4AAv8A//wAAP/9ALH/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADgAAAFBsYW5zIGZvciAtMDMADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQA AwAAAAMAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0 bGVzAAMAAAADAAAAAAAYAwAAFgAAAAAAAAC4AAAAAQAAAEsCAAACAAAAUwIAAAMAAABbAgAABAAA AGMCAAAFAAAAawIAAAYAAABzAgAABwAAAHsCAAAIAAAAlwIAAAkAAACjAgAACgAAAK8CAAALAAAA twIAAAwAAAC/AgAADQAAAMcCAAAOAAAAzwIAAA8AAADXAgAAEAAAAN8CAAARAAAA5wIAABIAAADv AgAAEwAAAPcCAAAUAAAA/wIAABUAAAAHAwAAFAAAAAIAAAANAAAAVGVtcGxhdGVUeXBlAAMAAAAM AAAAR3JhcGhpY1R5cGUABAAAAAwAAABDb21wcmVzc2lvbgAFAAAACwAAAFNjcmVlblNpemUABgAA AAwAAABTY3JlZW5Vc2FnZQAHAAAADAAAAE1haWxBZGRyZXNzAAgAAAAJAAAASG9tZVBhZ2UACQAA AAYAAABPdGhlcgAKAAAAEQAAAERvd25sb2FkT3JpZ2luYWwACwAAABEAAABEb3dubG9hZElFQnV0 dG9uAAwAAAAQAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABcAAABKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAA AA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAD+////GAAAAP7///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////bgBhAGMAYwBpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABuAAAA/78wwwAAEABafEDY/78Ix/+/MMP/v8j1kXyc9gAAAAAAAATgAACkDwoA AACAAGAAAAD/////AAClDwwAAAAAAAAILgAAAAIAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////xgA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwAL BFAGAAAPAADwSAYAAAAABvDAAwAAAtwBAHcAAAAlAAAACQAAAAEAAAAJAAAABAAAAAQAAAAIAAAA BwAAAAYAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAl AAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABgAAAAAAAAAFAAAAAAAAAAQA AAAAAAAABQAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAA AAAAAAAEAAAAAAAAABIAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAkAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAAHwAAAAAAAAAdAAAAAAAAAAQAAAACAAAACQAAAAAAAAAIAAAAAAAAAAQAAAAAAAAAFwAAAAAA AAAdAAAAAAAAABEAAAAAAAAAHAAAAAAAAAAZAAAAAAAAAAYAAAAAAAAAQgAAAAAAAAAEAAAAAAAA AH0AAAAAAAAABQAAAAAAAAAIAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAFAAAAAAAAAAoAAAAAAAAABAAAAAAAAABZAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAUAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAYA AAAAAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAIAAAAAAAAAAgAAAAAAAAABwAA AAAAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAXAAAAAAAAAB0AAAAAAAAALAAAAAAAAAAvAAAA AAAAAEMAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAABEAAAAAAAAAKwAAAAAA AAAEAAAAAAAAAAQAAAAAAAAAZwAAAAUAAAAEAAAACQAAAAQAAAAAAAAABAAAAAAAAAArAAAAAAAA AAcAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAADAAAA BAAAAAcAAAAEAAAAIwYL8EwCAACBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAIAAACIAAAAAACJ AAAAAAC/AAAADQAMAfQAABANAQAAACAOAQAAACCBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAjBAQAA AQDCAf///wDDAQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAAAADL ATUlAADMAQAACADNAQAAAADOAQAAAADPwQAAAADXAQIAAAD/AQ4ADgAAAgAAAAABAgIAAAgCAsvL ywADAgAAACAEAgAAAQAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAO AgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAQCAAgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAA AACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADE AgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBU iQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCUAADX ArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+ AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAAAwABrxDAAAAP8AAAD//wAA1gCT AEAAHvEQAAAA1gCTAP8AAAD/////9wAAEB8A8A84AAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACA AAAAAAAA8wMUAAAAKQAAAAAAAAAAAAAAAQAAgAAAAAAPANAHIRwAAA8A+gNnAAAAAAD+AwMAAAAA AQAAAP0DNAAAAH0AAABkAAAAfQAAAGQAAAAAwOgBAAAAAAAAAABQw/+/AAAAAMCfYHxA/f//kP// /wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAA AAAAAAIAAAAfAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAALDD/78pAAAAsDVYfAAAAAAU AAAAAMqaOwAAAAAAAAAAAAAAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaOzJOzckAypo7AAIAAR8A BwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAAsMP/vykAAACwNVh8AAAAALoddewAypo7AAAA AAAAAAAAAQABHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAACww/+/KQAAALA1WHwAAAAA uh117ADKmjsAAAAAAAAAAAABAAEPAIgTnhoAAA8AihOYAQAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLE3gBAAAPALMPcAEAAAAArw8IAAAAAAEAAAYAAAAAALEPIAAAAAAAAAQAAAAAAAAABAEA AAAAAAAEAgAAAAAAAAQDAAAAEACvDwgAAAAAAQAABQAAAAAAsQ8YAAAAAAAABAAAAAAAAAAEAQAA AAAAAAQCAAAAEACvDwgAAAABAQAAAQAAAAAAsQ94AAAAAAAABAAAAAAAAAAEAQAAAAAAAAQCAAAA AAAABAMAAAAAAAAEBAAAAAAAAAQFAAAAAAAABAYAAAAAAAAEBwAAAAAAAAQIAAAAAAAABAkAAAAA AAAECgAAAAAAAAQLAAAAAAAABAwAAAAAAAAEDQAAAAAAAAQOAAAAEACvDwgAAAAYAQAAAQAAAAAA sQ9gAAAAAAAABAAAAAAAAAAEAQAAAAAAAAQCAAAAAAAABAMAAAAAAAAEBAAAAAAAAAQFAAAAAAAA BAYAAAAAAAAEBwAAAAAAAAQIAAAAAAAABAkAAAAAAAAECgAAAAAAAAQLAAAADwCKE6YCAAAAALoP DgAAAF8AXwBfAFAAUABUADkAAACLE4gCAAAPAK4PgAIAAAAArw8IAAAAAAEAAAYAAAAAAKwPQAAA AAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAAAAAAABAA AwAAAAAAAAAQAK8PCAAAAAABAAAFAAAAAACsDzAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAB AAAAAAAAAAAAAAAAABAAAgAAAAAAAAAQAK8PCAAAAAEBAAABAAAAAACsD/AAAAAAAAAAAAAQAAAA AAAAAAAAAAAAAAAAEAABAAAAAAAAAAAAAAAAABAAAgAAAAAAAAAAAAAAAAAQAAMAAAAAAAAAAAAA AAAAEAAEAAAAAAAAAAAAAAAAABAABQAAAAAAAAAAAAAAAAAQAAYAAAAAAAAAAAAAAAAAEAAHAAAA AAAAAAAAAAAAABAACAAAAAAAAAAAAAAAAAAQAAkAAAAAAAAAAAAAAAAAEAAKAAAAAAAAAAAAAAAA ABAACwAAAAAAAAAAAAAAAAAQAAwAAAAAAAAAAAAAAAAAEAANAAAAAAAAAAAAAAAAABAADgAAAAAA AAAQAK8PCAAAABgBAAABAAAAAACsD8AAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAABAAAAAAAA AAAAAAAAABAAAgAAAAAAAAAAAAAAAAAQAAMAAAAAAAAAAAAAAAAAEAAEAAAAAAAAAAAAAAAAABAA BQAAAAAAAAAAAAAAAAAQAAYAAAAAAAAAAAAAAAAAEAAHAAAAAAAAAAAAAAAAABAACAAAAAAAAAAA AAAAAAAQAAkAAAAAAAAAAAAAAAAAEAAKAAAAAAAAAAAAAAAAABAACwAAAAAAAAAPAIoTaAAAAAAA ug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsTRAAAAA8AiBc8AAAAAACJFzQAAAAAAAAAAAAA AAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAAAIxwAAAAAAAAAAAACAAgHgDwCKE9gVAAAAALoP FgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsTshUAAEAAGhBmBQAABQAAAAAIDAEAAAAAAAIA AAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAA AAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAA aG5hbWQAAABgAAAAAgAAAAQAAAADAAAAAQAABAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAAD AAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQA GAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAA ABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAA AQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABg AAAAAgAAAAQAAAADAAAAAQAABAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYA TQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAA AAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAA AQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAEC AAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQA AAADAAAAAQAABAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0 AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAA AAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAA AAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAA AAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAADAAAAAQAA BAkAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAA VAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJ ABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgA AAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAA AAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAADAAAAAQAABAkAAAAKAEEA cgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBn AHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEA ABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAA AAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAA AAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAMAAAABAAAECQAAAAoAQQBy AGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcA cgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8A GxAgDwAAAACvDwgAAAAAAQAABgAAAAAAGRAoAQAAAAAAAAAAAAgUAQAAAAAAAgAAARQAAAAAAAAA FAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAAB AAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAAAGgA AAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAACAAA AAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAEACwA AAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAAAAAAAAAQAK8PCAAAAAABAAAFAAAA AAAZECQBAAAAAAAAAAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEA AADwAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEBAAAAAAABAgAAAAEAAAAAAAABAwAA AAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAA GgBDAG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwBy AG8AcwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQAIAAAAAABBwAAAAYAAAAAAAAAAAAEAAAA DgAJABEAAAAaAAEAAAAAEACvDwgAAAABAQAAAQAAAAAAGRDMBgAAAAAAAAAAAAAAAAAIFAEAAAAA AAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAgAFMAYQBuAHMA IABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIAcAAu AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgUAQAAAAAA AgAAARQAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABwbmFtZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBhAG4AcwAg AE0AUwAAAAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4A AAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAACBQBAAAAAAAC AAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQAAAAAAAABAAAAAAEA AAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAA AHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMAIABTAGEAbgBzACAA TQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAA AAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAAAAAAAAAAAAAA AAAIFAEAAAAAAAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAg AFMAYQBuAHMAIABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAA QwBvAHIAcAAuAAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAA AAAAAAAAAAAAAAAAAAgUAQAAAAAAAgAAARQAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA 8AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAAB AAAAAAAAAQQAAAABAAAAAAAAAQUAAABwbmFtZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoA QwBvAG0AaQBjACAAUwBhAG4AcwAgAE0AUwAAAAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBv AHMAbwBmAHQAIABDAG8AcgBwAC4AAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4A CQARAAAAGgABAAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADw AAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEA AAAAAAABBAAAAAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBD AG8AbQBpAGMAIABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8A cwBvAGYAdAAgAEMAbwByAHAALgAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJ ABEAAAAaAAEAAAAAEACvDwgAAAAYAQAAAQAAAAAAGRCoBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAgU AQAAAAAAAgAAARQAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAAAAAA AQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAA AAAAAQUAAABwbmFtZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAAUwBh AG4AcwAgAE0AUwAAAAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8A cgBwAC4AAAAAAQYAAAAEABwAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAAAAAA AAAAAAAIFAEAAAAAAAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAA BAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEE AAAAAQAAAAAAAAEFAAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkA YwAgAFMAYQBuAHMAIABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBVc2VCcm93 c2VyQ29sb3IADQAAAAoAAABCYWNrQ29sb3IADgAAAAoAAABUZXh0Q29sb3IADwAAAAoAAABMaW5r Q29sb3IAEAAAAA0AAABWaXNpdGVkQ29sb3IAEQAAABIAAABUcmFuc3BhcmVudEJ1dHRvbgASAAAA CwAAAEJ1dHRvblR5cGUAEwAAAAoAAABTaG93Tm90ZXMAFAAAAAoAAABOYXZCdG5Qb3MAFQAAAAoA AABPdXRwdXREaXIAAgAAABAnAAADAAAAAQAAAAMAAAABAAAAAwAAAGQAAAADAAAAAgAAAAMAAAAB AAAAHgAAABQAAABkaW5vQHByb2NrZXQuY29tAAAAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAAsA AAAAAAAACwAAAAAAAAALAAAAAQAAAAMAAADm5uYAAwAAAAAAAAADAAAAZgD/AAMAAADMM5kAAwAA AAAAAAADAAAAAwAAAAsAAAAAAAAAAwAAAAEAAAAeAAAACAAAAEM6XFRlbXAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPJgAAABQAAABfwJHj h+wAAA4A9AMDAAACRGlubyBGYXJpbmFjY2kIAAAARABpAG4AbwAgAEYAYQByAGkAAHMAbwBmAHQA IABDAG8AcgBwAC4AAAAAAQYAAAAEACAAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgAB AAAACBQBAAAAAAACAAABFAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADwAAAACAAAAAQA AAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAA AAEAAAAAAAABBQAAAHBuYW1kAAAAaAAAAAIAAAAEAAAAAwAAAAEAAAQJAAAAGgBDAG8AbQBpAGMA IABTAGEAbgBzACAATQBTAAAAAAAIAAAAAwAAAAEAAAQJAAAAHgBNAGkAYwByAG8AcwBvAGYAdAAg AEMAbwByAHAALgAAAAABBgAAAAQAIAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEA AAAIFAEAAAAAAAIAAAEUAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAPAAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAcG5hbWQAAABoAAAAAgAAAAQAAAADAAAAAQAABAkAAAAaAEMAbwBtAGkAYwAg AFMAYQBuAHMAIABNAFMAAAAAAAgAAAADAAAAAQAABAkAAAAeAE0AaQBjAHIAbwBzAG8AZgB0ACAA QwBvAHIAcAAuAAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAA AAgUAQAAAAAAAgAAARQAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA8AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABwbmFtZAAAAGgAAAACAAAABAAAAAMAAAABAAAECQAAABoAQwBvAG0AaQBjACAA UwBhAG4AcwAgAE0AUwAAAAAACAAAAAMAAAABAAAECQAAAB4ATQBpAGMAcgBvAHMAbwBmAHQAIABD AG8AcgBwAC4AAAAAAQYAAAAEACAAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgABAAAA AD8A2Q8MAAAAAADaDwQAAAAAAC0ATwDZDwwAAAAAANoPBAAAAAAAPQAPAPAP5wkAAAAA8wMUAAAA AwAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPMAAAAERyYWZ0IFN0YXR1cyBVcGRh dGULZHJhZnQtaWV0Zi1saXNwLW11bHRpY2FzdC0wMgAAoQ8+AAAAMQAAAAAAABAAAIIAFAAAAAAA AAABAAAAAARDABAEAgACACQAGwAAAAAIQwAQCAIAAgAkAAEAAAAADAAAEAwQAJ8PBAAAAAUAAAAA AKgPVwAAAEFuYWhlaW0gSUVURiAtIExJU1AgV0cNRGF2ZSBNZXllciwgSm9obiBad2llYmVsLCBT dGlnIFZlbmFhcywgRGlubyBGYXJpbmFjY2kNTWFyY2ggMjAxMAAAoQ8uAAAAWAAAAAAAAAAAAA8A AAACAAIAAgAcAAgAAAACBAIAAgQcAEEAAAACCAIAAggUAAAAqg9QAAAAFgAAAAAAAAABAAAAAQAA AAAAEQAAAAAAAAAHAAAAAQAAAAMAAgAAAAAAAAALAAAAAQAAAAMABwAAAAAAAAAKAAAAAQAAAAMA CwAAAAAAAAAAAPMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABE cmFmdCBIaXN0b3J5EACfDwQAAAABAAAAAACoD4YBAABkcmFmdC1pZXRmLWxpc3AtbXVsdGljYXN0 LTAwDVB1Ymxpc2hlZCBpbiBBcHJpbCAyMDA4DVJlbmFtZWQgZnJvbSBkcmFmdC1mYXJpbmFjY2kt bGlzcC1tdWx0aWNhc3QtMDENZHJhZnQtaWV0Zi1saXNwLW11bHRpY2FzdC0wMQ1QdWJsaXNoZWQg aW4gTm92ZW1iZXIgMjAwOA1FeHBlcnQgUmV2aWV3IGJ5IExpbWluZyBXZWksIFlpcXVuIENhaSwg VG9tIFB1c2F0ZXJpLCBTdGV2ZSBDYXNuZXIsIE1hcnNoYWxsIEV1YmFua3MsIERpbWl0cmkgUGFw YWRpbWl0cmlvdSwgUm9uIEJvbmljYSwgYW5kIExlbm55IEd1YXJkaW5vDWRyYWZ0LWlldGYtbGlz cC1tdWx0aWNhc3QtMDINUHVibGlzaGVkIGluIFNlcHRlbWJlciAyMDA5DUJyaW5nIGluIHN5bmMg d2l0aCBkcmFmdC1pZXRmLWxpc3AtMDYAAKEPAgEAAB0AAAAAAAAAAABHAAAAAQAAAAAAHQAAAAAA AAAAAKcAAAABAAAAAAAdAAAAAAAAAAAAQgAAAAEAAAAAAB0AAAAAAEMAAgACABgAGAAAAAAEAgAA BBQADQAAAAAIAgAACBQAIQAAAAAMQwAADAIAAgAUAAEAAAAAEAIAABAUABwAAAAAFEMAABQCAAIA GAABAAAAABgCAAAYGAAbAAAAABwCAAAcFAARAAAAACACAAAgFAB7AAAAACQCAAAkFAAdAAAAAChD AAAoAgACABgAHAAAAAAsAgAALBQAEwAAAAAwAgAAMBQAEgAAAAA0QwAANAIAAgAUAAEAAAAAOAIA ADgUAAAAqg+YAAAAmwAAAAAAAAABAAAAAQAAAAAAGAAAAAAAAAADAAAAAQAAAAMAAgAAAAAAAAAJ AAAAAQAAAAMABgAAAAAAAAAIAAAAAQAAAAMACAAAAAAAAAAGAAAAAQAAAAMAFAAAAAAAAAAIAAAA AQAAAAMAEwAAAAAAAAAGAAAAAQAAAAMADAAAAAAAAAAJAAAAAQAAAAMAXwAAAAAAAAAAAPMDFAAA AHYAAAAAAAAAAgAAABgBAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABQbGFucyBmb3IgLTAzEACf DwQAAAABAAAAAACgD+oCAABCAHIAaQBuAGcAIABpAG4AIABzAHkAbgBjACAAdwBpAHQAaAAgAGQA cgBhAGYAdAAtAGkAZQB0AGYALQBsAGkAcwBwAC0AaQBuAHQAZQByAHcAbwByAGsALQAwADEADQBV AG4AaQBjAGEAcwB0ACAAUABUAFIAcwAgAGEAcgBlACAAYwBhAGwAbABlAGQAIAB1AFAASQBUAFIA cwANAE0AdQBsAHQAaQBjAGEAcwB0ACAAUABUAFIAcwAgAGEAcgBlACAAYwBhAGwAbABlAGQAIABt AFAARQBUAFIAcwANAEoAbwBlAGwAIABjAG8AbQBtAGUAbgB0AA0AKABTAC0ARQBJAEQALAAgAEcA KQAgAGoAbwBpAG4AZQBkACAAdABoAHIAbwB1AGcAaAAgAGQAaQBmAGYAZQByAGUAbgB0ACAAcwBv AHUAcgBjAGUAIABSAEwATwBDAHMAIABkAG8AZQBzACAAbgBvAHQAIABjAGEAdQBzAGUAIABkAHUA cABsAGkAYwBhAHQAZQBzAA0ARABpAG4AbwAgAGYAbwB1AG4AZAAgAGIAdQBnAHMADQBDAGwAYQBy AGkAZgB5ACAAaABvAHcAIABtAGkAeABlAGQAIABsAG8AYwBhAHQAbwByAHMAIABzAGgAbwB1AGwA ZABuABkgdAAgAGIAZQAgAHUAcwBlAGQAIABmAG8AcgAgAG0AdQBsAHQAaQBjAGEAcwB0ACAADQBD AGwAYQByAGkAZgB5ACAAdwBoAGEAdAAgAG0AUABFAFQAUgBzACAAZABvACAAdwBoAGUAbgAgAGQA ZQBjAGEAcABzAHUAbABhAHQAZQBkACAAcABhAGMAawBlAHQAIABoAGEAcwAgAGQAaQBmAGYAZQBy AGUAbgB0ACAAQQBGACAAdwBpAHQAaAAgAG4AbwAgAHIAZQBjAGUAaQB2AGUAcgBzACAALQAgAGQA cgBvAHAAIABwAGEAYwBrAGUAdAANAAAAoQ/aAAAAMAAAAAAAABAAAFoAQAAAAAEAABAAAFoADQAA AAAAABAAAFoASwAAAAEAABAAAFoAEAAAAAAAABAAAFoAngAAAAEAABAAAFoAEwAAAAAAAgAcABwA AAAABEMAAAQCAAIAFAABAAAAAAgCAAAIFAAfAAAAAAwCAAAMGAAhAAAAABACAAAQGAANAAAAABQC AAAUHABLAAAAABgCAAAYGAAQAAAAABwCAAAcHAA8AAAAACACAAAgGABgAAAAACQCAAAkGAABAAAA ACgCAAAoGAABAAAAACwCAAAsGAAAAKoPogAAADAAAAAAAAAADQAAAAEAAAADAAoAAAAAAAAAAQAA AAEAAAAAAAcAAAABAAAAAwAKAAAAAAAAAAUAAAABAAAAAwALAAAAAAAAAAcAAAABAAAAAwA4AAAA AAAAAAYAAAABAAAAAwBkAAAAAAAAAAIAAAABAAAAAAANAAAAAAAAAAcAAAABAAAAAwAIAAAAAAAA AA0AAAABAAAAAwA5AAAAAAAAAC8A8A9UAAAAAADzAxQAAABpAAAAAAAAAAAAAAAAAQAAAAAAAAAA 8wMUAAAAagAAAAAAAAAAAAAAAQEAAAAAAAAAAPMDFAAAAHcAAAAAAAAAAAAAAAIBAAAAAAAAAADq AwAAAAAPAO4DUiQAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAIBAAAHAHJgDwAMBLQBAAAPAALw rAEAADAACPAIAAAAAwAAAAPUAQAPAAPwRAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA08GxoQAAsaHT wbGhAgAK8AgAAAAA1AEABQAAAA8ABPBsAAAAEgAK8AgAAAAC1AEAIAIAAEMAC/AYAAAAgADQRf0y vwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACQALAB0BRgAw8AEfAQAAAAAADDCwgAAAAAAAAADQB6 AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8JgAAAASAArwCAAAAAPUAQAgAgAAQwAL8BgAAACAAKBF 9zK/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAMADIAHwFeANDwAR8DwAAAAPABQQJAAAAAEA8Q8c AAAAAAAABwAAAAAAAAAAAAAAAAIAAQACDAMAAAAAPAAAwwsIAAAAAQAAAA4AvCAPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAAB1AEAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAA AMyZADMzzADMzP8AsrKyAA8AiBNGIgAADwCKEz4iAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA AIsTHiIAAAAA6y4IAAAAqRR3AABayRoAAB0QBAAAAAAAAAAAAAArBAAAACF5BrwfAETxriEAAAAA J/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAQIAA/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkA AAAfAETxaSEAAAAAJ/EgAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAA/////xgAAAAPAD3xDQAA AEABQvEFAAAAAQQAAAAAAEHxFAAAAAEAAAABAAAAAAAAAAAAAAADAAAAPwAl8SwAAAAAACjxEAAA AAEAAAAJAAAAAAAAAAAAAAAPADzxDAAAAAAAASsEAAAAAQAAAE8AJfEsAAAAAAAo8RAAAAABAAAA CgAAAAAAAAAAAAAADwA88QwAAAAAAAErBAAAAAEAAAAfAETxIQwAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAD/////HwBE8ckLAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA9 8QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPHLAwAAAAAn8SAAAAAAAAAA AAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAQAAAJAAQvEFAAAA AQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQ AAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAA AAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMA aQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAA AANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAAB AAAAA9QBAAAAAAAwAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAA J/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA0 8QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4 AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAA AwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0 AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQAAAAAAMAAAAB8ARPEZAQAAAAAn8SAA AAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAA AAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBo AC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELx AwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANw AHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAAAAAADAAAAAfAETxywMAAAAA J/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIA AACQAELxBQAAAAECAAAAoABC8QUAAAABBAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl 8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAA AwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvER AAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvEr AAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7 KhQAAAACAAAAAQAAAAPUAQAwAAAATwAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA HwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAAAAAP ACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAAAAMj AHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHgA AAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELx DQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAMAAAAE8AAAAfAETx GQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/Hh AAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEAKwAj AHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABwAHQA XwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEVAAAA AABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBADAAAABPAAAA HwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABA AULxBQAAAAECAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC8QUA AAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAA AAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAA AAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAA AAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAP ADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEATwAAAHAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAA AAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAA AA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAAAAAA AABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMA cABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8A PvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAE8A AABwAAAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA9 8QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAAAELx FwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAA AAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAA AAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPU AQBPAAAAcAAAAB8ARPFOCAAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA AA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETx9gcAAAAAJ/EgAAAA AAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAA AAAAAAAAAAAAAAAAAAAAHwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAA AAABAAAADwA98UEAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELx BQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE 8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHx oAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPx EAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkA YgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAcAAAAH0AAAAfACXxGAAA AAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAA AAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/Fc AAAAAABD8QQAAAAAAAAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA 6AMAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAA AAAAAAAAAAAAAAAAAB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAA AAIAAAABAAAAA9QBAHAAAAB9AAAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAA AAAAAPQBAAAZAAAADwA98QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAA AEPxBAAAAAAAAAAAAELxFwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPx BAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAA AAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7 KhQAAAACAAAAAQAAAAPUAQBwAAAAfQAAAB8ARPHLAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAA AAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQIAAACgAELxBQAA AAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAA AAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8A PfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8A KvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUA LgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBAH0AAADI AAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEAAAAAJ/EgAAAAAAAAAAAA AAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAAAAA08QwAAAABAAAAOAAA AAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQAXwB4AAAAEABC8QMAAAAD AAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAADwAq8VkAAAAA ADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAA8APPEc AAAAAAD7KhQAAAACAAAAAQAAAAPUAQB9AAAAyAAAAB8ARPEZAQAAAAAn8SAAAAAAAAAAAAAAAAMA AAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTxDAAAAAEAAAA4AAAAAQAA AA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcAAAADMQArACMAcABwAHQAXwBoAC8AMgAAABAAQvED AAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQAELxAwAAAAMAAA8AKvFZ AAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAAAANwAHAAdABfAHkAAAAP ADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAfQAAAMgAAAAfAETxIQwAAAAAJ/EgAAAAAAAAAAAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAA AAAAAAD/////HwBE8ckLAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAA DwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPHLAwAAAAAn8SAAAAAA AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAQAAAJAAQvEF AAAAAQIAAACgAELxBQAAAAEEAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAA KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAA AAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBp AHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELx IwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAIA AAABAAAAA9QBAMgAAADYAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxEQEA AAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8AK/HZAAAA AAA08QwAAAABAAAAOAAAAAEAAAAPAD/xXAAAAAAAQ/EEAAAAAAAAAAAAQvEPAAAAAyMAcABwAHQA XwB4AAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELxDwAAAAMjAHAAcAB0AF8AeAAAABAAQvED AAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAAAAAAAAAfAD7xFQAAAAAAQvENAAAAA3AA cAB0AF8AeAAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAAPUAQDIAAAA2AAAAB8ARPEZAQAAAAAn 8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAAGQAAAA8APfEAAAAADwAr8eEAAAAAADTx DAAAAAEAAAA4AAAAAQAAAA8AP/FkAAAAAABD8QQAAAAAAAAAAABC8RcAAAADMQArACMAcABwAHQA XwBoAC8AMgAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABfAHkAAAAQ AELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAAAELxDQAA AANwAHAAdABfAHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAyAAAANgAAAAfAETxywMA AAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAA AQIAAACQAELxBQAAAAECAAAAoABC8QUAAAABBAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAA HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAAD AAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAA QvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8A PvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAA AAD7KhQAAAACAAAAAQAAAAPUAQDYAAAAFAEAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA AAAAHwBE8REBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAADwA98QAA AAAPACvx2QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8VwAAAAAAEPxBAAAAAAAAAAAAELxDwAA AAMjAHAAcAB0AF8AeAAAABAAQvEDAAAAAwAAAABD8QQAAADoAwAAAABC8Q8AAAADIwBwAHAAdABf AHgAAAAQAELxAwAAAAMAAA8AKvFZAAAAAAAz8RAAAAAFAAAAAAAAAAAAAAAAAAAAHwA+8RUAAAAA AELxDQAAAANwAHAAdABfAHgAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEA2AAAABQBAAAf AETxGQEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAA9AEAABkAAAAPAD3xAAAAAA8A K/HhAAAAAAA08QwAAAABAAAAOAAAAAEAAAAPAD/xZAAAAAAAQ/EEAAAAAAAAAAAAQvEXAAAAAzEA KwAjAHAAcAB0AF8AaAAvADIAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAAAyMAcABw AHQAXwB5AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAAAB8APvEV AAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QBANgAAAAU AQAAHwBE8csDAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEA AABAAULxBQAAAAECAAAAkABC8QUAAAABAgAAAKAAQvEFAAAAAQQAAACwAELxBQAAAAEBAAAAMAFC 8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAA AAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAA AQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAA AAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkA AAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAD1AEAFAEAAHUBAAAfACXxGAAAAAAAKPEQAAAAAAAA AAAAAAAAAAAAAAAAAB8ARPERAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAD0AQAA GQAAAA8APfEAAAAADwAr8dkAAAAAADTxDAAAAAEAAAA4AAAAAQAAAA8AP/FcAAAAAABD8QQAAAAA AAAAAABC8Q8AAAADIwBwAHAAdABfAHgAAAAQAELxAwAAAAMAAAAAQ/EEAAAA6AMAAAAAQvEPAAAA AyMAcABwAHQAXwB4AAAAEABC8QMAAAADAAAPACrxWQAAAAAAM/EQAAAABQAAAAAAAAAAAAAAAAAA AB8APvEVAAAAAABC8Q0AAAADcABwAHQAXwB4AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAA9QB ABQBAAB1AQAAHwBE8RkBAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAPQBAAAZAAAA DwA98QAAAAAPACvx4QAAAAAANPEMAAAAAQAAADgAAAABAAAADwA/8WQAAAAAAEPxBAAAAAAAAAAA AELxFwAAAAMxACsAIwBwAHAAdABfAGgALwAyAAAAEABC8QMAAAADAAAAAEPxBAAAAOgDAAAAAELx DwAAAAMjAHAAcAB0AF8AeQAAABAAQvEDAAAAAwAADwAq8VkAAAAAADPxEAAAAAUAAAAAAAAAAAAA AAAAAAAfAD7xFQAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAA AAPUAQAUAQAAdQEAAA8AAis4AAAADwAIKzAAAAAAAAMrEAAAAAEAAAAAAAAAA9QBAAEAAAABAAkr EAAAAAEAAAABAAAAAAAAAAAAAAAAAHIXEAAAAAEAEADrmAAAdgAQABXIAAAAAPUPHAAAABgBAAAH IgADx5gAAG/sAAABAAAAeAAAAAEAx2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAUA//////////8BAAAAEI2BZJtPzxGG6gCq ALkp6AAAAAAAAAAAAAAAAACKf4ivycoBUAAAAEAGAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAg AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAq+wAAAAAAAAFAFMAdQBt AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFEAAACc JwAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAIwFAAAAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAA igAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAP7///+XAAAA/f////3////+ /////v////7///+ZAAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA ACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAA NQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABD AAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABpAAAA/////2UA AABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAA AGAAAABhAAAAYgAAAGMAAABkAAAA/v///5oAAAD///////////////9qAAAAawAAAGwAAABtAAAA bgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB6AAAA/////3sAAAB8 AAAAfQAAAH4AAAB/AAAAgAAAAEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFwAAAEoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAA AAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAAP7///8YAAAA /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////9uAGEAYwBjAGkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABVc2VCcm93c2VyQ29sb3IADQAAAAoAAABCYWNrQ29sb3IADgAAAAoA AABUZXh0Q29sb3IADwAAAAoAAABMaW5rQ29sb3IAEAAAAA0AAABWaXNpdGVkQ29sb3IAEQAAABIA AABUcmFuc3BhcmVudEJ1dHRvbgASAAAACwAAAEJ1dHRvblR5cGUAEwAAAAoAAABTaG93Tm90ZXMA FAAAAAoAAABOYXZCdG5Qb3MAFQAAAAoAAABPdXRwdXREaXIAAgAAABAnAAADAAAAAQAAAAMAAAAB AAAAAwAAAGQAAAADAAAAAgAAAAMAAAABAAAAHgAAABQAAABkaW5vQHByb2NrZXQuY29tAAAAAB4A AAAEAAAAAAAAAB4AAAAEAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAQAAAAMAAADm5uYAAwAA AAAAAAADAAAAZgD/AAMAAADMM5kAAwAAAAAAAAADAAAAAwAAAAsAAAAAAAAAAwAAAAEAAAAeAAAA CAAAAEM6XFRlbXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAPYPJgAAABQAAABfwJHjh+wAAA4A9AMDAAACRGlubyBGYXJpbmFjY2kIAAAARABp AG4AbwAgAEYAYQByAGkA --Apple-Mail-12-1012096568 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > > > --Apple-Mail-12-1012096568 Content-Disposition: attachment; filename=rfcdiff-lisp-multicast-02-to-03.html Content-Type: text/html; x-unix-mode=0600; name="rfcdiff-lisp-multicast-02-to-03.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-multicast-02.txt draft-ietf-lisp-multicast-03.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                                 J. Zwiebel
Expires: April 2, October 14, 2010                                      S. Venaas
                                                           cisco Systems
                                                      September 29, 2009
                                                          April 12, 2010

                    LISP for Multicast Environments
                    draft-ietf-lisp-multicast-02.txt
                      draft-ietf-lisp-multicast-03

Abstract

   This draft describes how inter-domain multicast routing will function
   in an environment where Locator/ID Separation is deployed using the
   LISP architecture.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 2, October 14, 2010.

Copyright Notice

   Copyright (c) 2009 2010 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 (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   This draft describes how inter-domain multicast routing will function  Code Components extracted from this document must
   include Simplified BSD License text as described in an environment where Locator/ID Separation is deployed using Section 4.e of
   the
   LISP architecture. Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Source Addresses versus Group Addresses  . . . . . . . . . . . 12
   6.  Locator Reachability Implications on LISP-Multicast  . . . . . 13
   7.  Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14
   8.  LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16
     8.1.  ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
       8.1.1.  Multiple RLOCs for an ITR  . . . . . . . . . . . . . . 16
       8.1.2.  Multiple ITRs for a LISP Source Site . . . . . . . . . 17
     8.2.  ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
     8.3.  Replication Locations  . . . . . . . . . . . . . . . . . . 17
   9.  LISP-Multicast Interworking  . . . . . . . . . . . . . . . . . 19
     9.1.  LISP and non-LISP Mixed Sites  . . . . . . . . . . . . . . 19
       9.1.1.  LISP Source Site to non-LISP Receiver Sites  . . . . . 20
       9.1.2.  Non-LISP Source Site to non-LISP Receiver  Sites . . . 21
       9.1.3.  Non-LISP Source Site to Any Receiver Site  . . . . . . 22
       9.1.4.  Unicast LISP Source Site to Any Receiver Sites . . . 22 . 23
       9.1.5.  LISP Source Site to Any Receiver Sites . . . . . . . . 23
     9.2.  LISP Sites with Mixed Address Families . . . . . . . . . . 23 24
     9.3.  Making a Multicast Interworking Decision . . . . . . . . . 25 26
   10. Considerations when RP Addresses are Embedded in Group
       Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . . 26 27
   11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27 28
   12. Mtrace Considerations  . . . . . . . . . . . . . . . . . . . . 28 29
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 29 30
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 30 31
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 32
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 32
     15.2. Informative References . . . . . . . . . . . . . . . . . . 31 32
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 33 34
     A.1.  Changes to draft-ietf-lisp-multicsat-02.txt draft-ietf-lisp-multicast-03.txt  . . . . . . . 33 34
     A.2.  Changes to draft-ietf-lisp-multicsat-01.txt draft-ietf-lisp-multicast-02.txt  . . . . . . . 33 34
     A.3.  Changes to draft-ietf-lisp-multicsat-00.txt draft-ietf-lisp-multicast-01.txt  . . . . . . . 34
     A.4.  Changes to draft-ietf-lisp-multicast-00.txt  . . . . . . . 33 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 36

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   The Locator/ID Separation Architecture [LISP] provides a mechanism to
   separate out Identification and Location semantics from the current
   definition of an IP address.  By creating two namespaces, an EID
   namespace used by sites and a Locator (RLOC) namespace used by core
   routing, the core routing infrastructure can scale by doing
   topological aggregation of routing information.

   Since LISP creates a new namespace, a mapping function must exist to
   map a site's EID prefixes to its associated locators.  For unicast
   packets, both the source address and destination address must be
   mapped.  For multicast packets, only the source address needs to be
   mapped.  The destination group address doesn't need to be mapped
   because the semantics of an IPv4 or IPv6 group address are logical in
   nature and not topology-dependent.  Therefore, this specifications
   focuses on to map a source EID address of a multicast flow during
   distribution tree setup and packet delivery.

   This specification will address the following scenarios:

   1.  How a multicast source host in a LISP site sends multicast
       packets to receivers inside of its site as well as to receivers
       in other sites that are LISP enabled.

   2.  How inter-domain (or between LISP sites) multicast distribution
       trees are built and how forwarding of multicast packets leaving a
       source site toward receivers sites is performed.

   3.  What protocols are affected and what changes are required to such
       multicast protocols.

   4.  How ASM-mode, SSM-mode, and Bidir-mode service models will
       operate.

   5.  How multicast packet flow will occur for multiple combinations of
       LISP and non-LISP capable source and receiver sites, for example:

       A.  How multicast packets from a source host in a LISP site are
           sent to receivers in other sites when they are all non-LISP
           sites.

       B.  How multicast packets from a source host in a LISP site are
           sent to receivers in both LISP-enabled sites and non-LISP
           sites.

       C.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in other sites when they are all LISP-
           enabled sites.

       D.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in both LISP-enabled sites and non-LISP
           sites.

   This specification focuses on what changes are needed to the
   multicast routing protocols to support LISP-Multicast as well as
   other protocols used for inter-domain multicast, such as Multi-
   protocol BGP (MBGP) [RFC4760].  The approach proposed in this
   specification requires no changes to the multicast infrastructure
   inside of a site when all sources and receivers reside in that site,
   even when the site is LISP enabled.  That is, internal operation of
   multicast is unchanged regardless of whether or not the site is LISP
   enabled or whether or not receivers exist in other sites which are
   LISP-enabled.

   Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
   and PIM-SSM [RFC4607].  Bidir-PIM [RFC5015], which typically does not
   run in an inter-domain environment is not addressed in depth in this
   version of the specification.

   Also, the current version of this specification does not describe
   multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
   descriptions in [LISP].

3.  Definition of Terms

   The terminology in this section is consistent with the definitions in
   [LISP] but is extended specifically to deal with the application of
   the terminology to multicast routing.

   LISP-Multicast:   a reference to the design in this specification.
      That is, when any site that is participating in multicast
      communication has been upgraded to be a LISP site, the operation
      of control-plane and data-plane protocols is considered part of
      the LISP-Multicast architecture.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source address field of the first (most inner) LISP
      header of a multicast packet.  The host obtains a destination
      group address the same way it obtains one today, as it would when
      it is a non-LISP site.  The source EID is obtained via existing
      mechanisms used to set a host's "local" IP address.  An EID is
      allocated to a host from an EID prefix block associated with the
      site the host is located in.  An EID can be used by a host to
      refer to another host, as when it joins an SSM (S-EID,G) route
      using IGMP version 3 [RFC4604].  LISP uses Provider Independent
      (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs.
      Note that EID blocks may be assigned in a hierarchical manner,
      independent of the network topology, to facilitate scaling of the
      mapping database.  In addition, an EID block assigned to a site
      may have site-local structure (subnetting) for routing within the
      site; this structure is not visible to the global routing system.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an ingress
      tunnel router (ITR), the router in the multicast source host's
      site that encapsulates multicast packets.  It is the output of a
      EID-to-RLOC mapping lookup.  An EID maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically-aggregatable
      blocks that are assigned to a site at each point to which it
      attaches to the global Internet; where the topology is defined by
      the connectivity of provider networks, RLOCs can be thought of as
      Provider Assigned (PA) addresses.  Multiple RLOCs can be assigned
      to the same ITR device or to multiple ITR devices at a site.

   Ingress Tunnel Router (ITR):   a router which accepts an IP multicast
      packet with a single IP header (more precisely, an IP packet that
      does not contain a LISP header).  The router treats this "inner"
      IP destination multicast address opaquely so it doesn't need to
      perform a map lookup on the group address because it is
      topologically insignificant.  The router then prepends an "outer"
      IP header with one of its globally-routable RLOCs as the source
      address field.  This RLOC is known to other multicast receiver
      sites which have used the mapping database to join a multicast
      tree for which the ITR is the root.  In general, an ITR receives
      IP packets from site end systems on one side and sends LISP-
      encapsulated multicast IP packets out all external interfaces
      which have been joined.

      An ITR would receive a multicast packet from a source inside of
      its site when 1) it is on the path from the multicast source to
      internally joined receivers, or 2) when it is on the path from the
      multicast source to externally joined receivers.

   Egress Tunnel Router (ETR):   a router that is on the path from a
      multicast source host in another site to a multicast receiver in
      its own site.  An ETR accepts a PIM Join/Prune message from a site
      internal PIM router destined for the source's EID in the multicast
      source site.  The ETR maps the source EID in the Join/Prune
      message to an RLOC address based on the EID-to-RLOC mapping.  This
      sets up the ETR to accept multicast encapsulated packets from the
      ITR in the source multicast site.  A multicast ETR decapsulates
      multicast encapsulated packets and replicates them on interfaces
      leading to internal receivers.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality can be at the
      CE router.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP header.  An ITR
      prepends headers and an ETR strips headers.  A LISP encapsulated
      multicast packet will have an "inner" header with the source EID
      in the source field; an "outer" header with the source RLOC in the
      source field: and the same globally unique group address in the
      destination field of both the inner and outer header.

   (S,G) State:   the formal definition is in the PIM Sparse Mode
      [RFC4601] specification.  For this specification, the term is used
      generally to refer to multicast state.  Based on its topological
      location, the (S,G) state resides in routers can be either
      (S-EID,G) state (at a location where the (S,G) state resides) or
      (S-RLOC,G) state (in the Internet core).

   (S-EID,G) State:   refers to multicast state in multicast source and
      receiver sites where S-EID is the IP address of the multicast
      source host (its EID).  An S-EID can appear in an IGMPv3 report,
      an MSDP SA message or a PIM Join/Prune message that travels inside
      of a site.

   (S-RLOC,G) State:   refers to multicast state in the core where S is
      a source locator (the IP address of a multicast ITR) of a site
      with a multicast source.  The (S-RLOC,G) is mapped from (S-EID,G)
      entry by doing a mapping database lookup for the EID prefix that
      S-EID maps to.  An S-RLOC can appear in a PIM Join/Prune message
      when it travels from an ETR to an ITR over the Internet core.

   uLISP Site:   a unicast only LISP site according to [LISP] which has
      not deployed the procedures of this specification and therefore,
      for multicast purposes, follows the procedures from Section 9.

   mPTR:

   mPETR:   this is a multicast PTR proxy-ETR that is responsible for
      advertising a very coarse EID prefix which non-LISP and uLISP
      sites can target their (S-EID,G) PIM Join/Prune message to. mPTRs mPETRs
      are used so LISP source multicast sites can send multicast packets
      using source addresses from the EID namespace. mPTRs mPETRs act as Proxy
      ETRs for supporting multicast routing in a LISP infrastructure.
      It is likely an uPITR and a mPETR will be co-loacted since the
      single device advertises a coarse EID-prefix in the underlying
      unicast routing system.

   Mixed Locator-Sets:   this is a locator-set for a LISP database
      mapping entry where the RLOC addresses in the locator-set are in
      both IPv4 and IPv6 format.

   Unicast Encapsulated PIM Join/Prune Message:   this is a standard PIM
      Join/Prune message (encapsulated in a LISP Encapsulated Control
      Message with destination UDP port 4342) which is sent by ETRs at
      multicast receiver sites to an ITR at a multicast source site.
      This message is sent periodically as long as there are interfaces
      in the oif-list for the (S-EID,G) entry the ETR is joining for.

4.  Basic Overview

   LISP, when used for unicast routing, increases the site's ability to
   control ingress traffic flows.  Egress traffic flows are controlled
   by the IGP in the source site.  For multicast, the IGP coupled with
   PIM can decide which path multicast packets ingress.  By using the
   traffic engineering features of LISP, a multicast source site can
   control the egress of its multicast traffic.  By controlling the
   priorities of locators from a mapping database entry, a source
   multicast site can control which way multicast receiver sites join to
   the source site.

   At this point in time, we don't see a requirement for different
   locator-sets, priority, and weight policies for multicast than we
   have for unicast.

   The fundamental multicast forwarding model is to encapsulate a
   multicast packet into another multicast packet.  An ITR will
   encapsulate multicast packets received from sources that it serves in
   another LISP multicast header.  The destination group address from
   the inner header is copied to the destination address of the outer
   header.  The inner source address is the EID of the multicast source
   host and the outer source address is the RLOC of the encapsulating
   ITR.

   The LISP-Multicast architecture will follow this high-level protocol
   and operational sequence:

   1.  Receiver hosts in multicast sites will join multicast content the
       way they do today, they use IGMP.  When they use IGMPv3 where
       they specify source addresses, they use source EIDs, that is they
       join (S-EID,G).  If the S-EID is a local multicast source host.
       If the multicast source is external to this receiver site, the
       PIM Join/Prune message flows toward the ETRs, finding the
       shortest exit (that is the closest exit for the Join/Prune
       message but it is the closest entrance for the multicast packet
       to the receiver).

   2.  The ETR does a mapping database lookup for S-EID.  If the mapping
       is cached from a previous lookup (from either a previous Join/
       Prune for the source multicast site or a unicast packet that went
       to the site), it will use the RLOC information from the mapping.
       The ETR will use the same priority and weighting mechanism as for
       unicast.  So the source site can decide which way multicast
       packets egress.

   3.  The ETR will build two PIM Join/Prune messages, one that contains
       a (S-EID,G) entry that is unicast to the ITR that matches the
       RLOC the ETR selects, and the other which contains a (S-RLOC,G)
       entry so the core network can create multicast state from this
       ETR to the ITR.

   4.  When the ITR gets the unicast Join/Prune message (see Section 3
       for formal definition), it will process (S-EID,G) entries in the
       message and propagate them inside of the site where it has
       explicit routing information for EIDs via the IGP.  When the ITR
       receives the (S-RLOC,G) PIM Join/Prune message it will process it
       like any other join it would get in today's Internet.  The S-RLOC
       address is the IP address of this ITR.

   5.  At this point there is (S-EID,G) state from the joining host in
       the receiver multicast site to the ETR of the receiver multicast
       site.  There is (S-RLOC,G) state across the core network from the
       ETR of the multicast receiver site to the ITR in the multicast
       source site and (S-EID,G) state in the source multicast site.
       Note, the (S-EID,G) state is the same S-EID in each multicast
       site.  As other ETRs join the same multicast tree, they can join
       through the same ITR (in which case the packet replication is
       done in the core) or a different ITR (in which case the packet
       replication is done at the source site).

   6.  When a packet is originated by the multicast host in the source
       site, it will flow to one or more ITRs which will prepend a LISP
       header by copying the group address to the outer destination
       address field and insert its own locator address in the outer
       source address field.  The ITR will look at its (S-RLOC,G) state,
       where S-RLOC is its own locator address, and replicate the packet
       on each interface a (S-RLOC,G) joined was received on.  The core
       has (S-RLOC,G) so where fanout occurs to multiple sites, a core
       router will do packet replication.

   7.  When either the source site or the core replicates the packet,
       the ETR will receive a LISP packet with a destination group
       address.  It will also decapsulate packets because it has
       receivers for the group.  Otherwise, it would have not received
       the packets because it would not have joined.  The ETR
       decapsulates and does a (S-EID,G) lookup in its multicast FIB to
       forward packets out one or more interfaces to forward the packet
       to internal receivers.

   This architecture is consistent and scalable with the architecture
   presented in [LISP] where multicast state in the core operates on
   locators and multicast state at the sites operates on EIDs.

   Alternatively, [LISP] does present a mechanism where (S-EID,G) state
   can reside in the core through the use of RPF-vectors [RPFV] in PIM
   Join/Prune messages.  However, this will require EID state in core as
   well as the use of RPF-vector formatted Join/Prune messages which are
   not the default implementation choice.  So we choose a design that
   can allow the separation of namespaces as unicast LISP provides.  It
   will be at the expense of creating new (S-RLOC,G) state when ITRs go
   unreachable.  See Section 5 for details.

   However, we have some observations on the algorithm above.  We can
   scale the control plane but at the expense of sending data to sites
   which may have not joined the distribution tree where the
   encapsulated data is being delivered.  For example, one site joins
   (S-EID1,G) and another site joins (S-EID2,G).  Both EIDs are in the
   same multicast source site.  Both multicast receiver sites join to
   the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the
   ITR.  The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the
   site.  The ITR receives (S-RLOC,G) joins and populates the oif-list
   state for it.  Since both (S-EID1,G) and (S-EID2, G) map to the one
   (S-RLOC,G) packets will be delivered by the core to both multicast
   receiver sites even though each have joined a single source-based
   distribution tree.  This behavior is a consequence of the many-to-one
   mapping between S-EIDs and a S-RLOC.

   There is a possible solution to this problem which reduces the number
   of many-to-one occurrences of (S-EID,G) entries aggregating into a
   single (S-RLOC,G) entry.  If a physical ITR can be assigned multiple
   RLOC addresses and these addresses are advertised in mapping database
   entries, then ETRs at receiver sites have more RLOC address options
   and therefore can join different (RLOC,G) entries for each (S-EID,G)
   entry joined at the receiver site.  It would not scale to have a one-
   to-one relationship between the number of S-EID sources at a source
   site and the number of RLOCs assigned to all ITRs at the site, but we
   can reduce the "n" to a smaller number in the "n-to-1" relationship.
   And in turn, reduce the opportunity for data packets to be delivered
   to sites for groups not joined.

5.  Source Addresses versus Group Addresses

   Multicast group addresses don't have to be associated with either the
   EID or RLOC namespace.  They actually are a namespace of their own
   that can be treated as logical with relatively opaque allocation.
   So, by their nature, they don't detract from an incremental
   deployment of LISP-Multicast.

   As for source addresses, as in the unicast LISP scenario, there is a
   decoupling of identification from location.  In a LISP site, packets
   are originated from hosts using their allocated EIDs, those addresses
   are used to identify the host as well as where in the site's topology
   the host resides but not how and where it is attached to the
   Internet.

   Therefore, when multicast distribution tree state is created anywhere
   in the network on the path from any multicast receiver to a multicast
   source, EID state is maintained at the source and receiver multicast
   sites, and RLOC state is maintained in the core.  That is, a
   multicast distribution tree will be represented as a 3-tuple of
   {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the
   3-tuple is the state stored in routers from the source to one or more
   ITRs in the source multicast site, the second element of the 3-tuple
   is the state stored in routers downstream of the ITR, in the core, to
   all LISP receiver multicast sites, and the third element in the
   3-tuple is the state stored in the routers downstream of each ETR, in
   each receiver multicast site, reaching each receiver.  Note that
   (S-EID,G) is the same in both the source and receiver multicast
   sites.

   The concatenation/mapping from the first element to the second
   element of the 3-tuples is done by the ITR and from the second
   element to the third element is done at the ETRs.

6.  Locator Reachability Implications on LISP-Multicast

   Multicast state as it is stored in the core is always (S,G) state as
   it exists today or (S-RLOC,G) state as it will exist when LISP sites
   are deployed.  The core routers cannot distinguish one from the
   other.  They don't need to because it is state that RPFs against the
   core routing tables in the RLOC namespace.  The difference is where
   the root of the distribution tree for a particular source is.  In the
   traditional multicast core, the source S is the source host's IP
   address.  For LISP-Multicast the source S is a single ITR of the
   multicast source site.

   An ITR is selected based on the LISP EID-to-RLOC mapping used when an
   ETR propagates a PIM Join/Prune message out of a receiver multicast
   site.  The selection is based on the same algorithm an ITR would use
   to select an ETR when sending a unicast packet to the site.  In the
   unicast case, the ITR can change on a per-packet basis depending on
   the reachability of the ETR.  So an ITR can change relatively easily
   using local reachability state.  However, in the multicast case, when
   an ITR goes unreachable, new distribution tree state must be built
   because the encapsulating root has changed.  This is more significant
   than an RPF-change event, where any router would typically locally
   change its RPF-interface for its existing tree state.  But when an
   encapsulating LISP-Multicast ITR goes unreachable, new distribution
   state must be rebuilt and reflect the new encapsulator.  Therefore,
   when an ITR goes unreachable, all ETRs that are currently joined to
   that ITR will have to trigger a new Join/Prune message for (S-RLOC,G)
   to the new ITR as well as send a unicast encapsulated Join/Prune
   message telling the new ITR which (S-EID,G) is being joined.

   This issue can be mitigated by using anycast addressing for the ITRs
   so the problem does reduce to an RPF change in the core, but still
   requires a unicast encapsulated Join/Prune message to tell the new
   ITR about (S-EID,G).  The problem with this approach is that the ETR
   really doesn't know when the ITR has changed so the new anycast ITR
   will get the (S-EID,G) state only when the ETR sends it the next time
   during its periodic sending procedures.

7.  Multicast Protocol Changes

   A number of protocols are used today for inter-domain multicast
   routing:

   IGMPv1-v3, MLDv1-v2:   These protocols do not require any changes for
      LISP-Multicast for two reasons.  One being that they are link-
      local and not used over site boundaries and second they advertise
      group addresses that don't need translation.  Where source
      addresses are supplied in IGMPv3 and MLDv2 messages, they are
      semantically regarded as EIDs and don't need to be converted to
      RLOCs until the multicast tree-building protocol, such as PIM, is
      received by the ETR at the site boundary.  Addresses used for IGMP
      and MLD come out of the source site's allocated addresses which
      are therefore from the EID namespace.

   MBGP:   Even though MBGP is not a multicast routing protocol, it is
      used to find multicast sources when the unicast BGP peering
      topology and the multicast MBGP peering topology are not
      congruent.  When MBGP is used in a LISP-Multicast environment, the
      prefixes which are advertised are from the RLOC namespace.  This
      allows receiver multicast sites to find a path to the source
      multicast site's ITRs.  MBGP peering addresses will be from the
      RLOC namespace.

   MSDP:   MSDP is used to announce active multicast sources to other
      routing domains (or LISP sites).  The announcements come from the
      PIM Rendezvous Points (RPs) from sites where there are active
      multicast sources sending to various groups.  In the context of
      LISP-Multicast, the source addresses advertised in MSDP will
      semantically be from the EID namespace since they describe the
      identity of a source multicast host.  It will be true that the
      state stored in MSDP caches from core routers will be from the EID
      namespace.  An RP address inside of site will be from the EID
      namespace so it can be advertised and reached by internal unicast
      routing mechanism.  However, for MSDP peer-RPF checking to work
      properly across sites, the RP addresses must be converted or
      mapped into a routable address that is advertised and maintained
      in the BGP routing tables in the core.  MSDP peering addresses can
      come out of either the EID or a routable address namespace.  And
      the choice can be made unilaterally because the ITR at the site
      will determine which namespace the destination peer address is out
      of by looking in the mapping database service.

   PIM-SSM:   In the simplest form of distribution tree building, when
      PIM operates in SSM mode, a source distribution tree is built and
      maintained across site boundaries.  In this case, there is a small
      modification to the operation of the PIM protocol (but not to any
      message format) to support taking a Join/Prune message originated
      inside of a LISP site with embedded addresses from the EID
      namespace and converting them to addresses from the RLOC namespace
      when the Join/Prune message crosses a site boundary.  This is
      similar to the requirements documented in [MNAT].

   PIM-Bidir:   Bidirectional PIM is typically run inside of a routing
      domain, but if deployed in an inter-domain environment, one would
      have to decide if the RP address of the shared-tree would be from
      the EID namespace or the RLOC namespace.  If the RP resides in a
      site-based router, then the RP address is from the EID namespace.
      If the RP resides in the core where RLOC addresses are routed,
      then the RP address is from the RLOC namespace.  This could be
      easily distinguishable if the EID address were well-known address
      allocation block from the RLOC namespace.  Also, when using
      Embedded-RP for RP determination [RFC3956], the format of the
      group address could indicate the namespace the RP address is from.
      However, refer to Section 10 for considerations core routers need
      to make when using Embedded-RP IPv6 group addresses.  When using
      Bidir-PIM for inter-domain multicast routing, it is recommended to
      use staticly configured RPs so core routers think the Bidir group
      is associated with an ITR's RLOC as the RP address and site
      routers think the Bidir group is associated with the site resident
      RP with an EID address.  With respect to DF-election in Bidir PIM,
      no changes are required since all messaging and addressing is
      link-local.

   PIM-ASM:   The ASM mode of PIM, the most popular form of PIM, is
      deployed in the Internet today is by having shared-trees within a
      site and using source-trees across sites.  By the use of MSDP and
      PIM-SSM techniques described above, we can get multicast
      connectivity across LISP sites.  Having said that, that means
      there are no special actions required for processing (*,G) or
      (S,G,R) Join/Prune messages since they all operate against the
      shared-tree which is site resident.  Just like with ASM, there is
      no (*,G) in the core when LISP-Multicast is in use.  This is also
      true for the RP-mapping mechanisms Auto-RP and BSR.

   Based on the protocol description above, the conclusion is that there
   are no protocol message format changes, just a translation function
   performed at the control-plane.  This will make for an easier and
   faster transition for LISP since fewer components in the network have
   to change.

   It should also be stated just like it is in [LISP] that no host
   changes, whatsoever, are required to have a multicast source host
   send multicast packets and for a multicast receiver host to receive
   multicast packets.

8.  LISP-Multicast Data-Plane Architecture

   The LISP-Multicast data-plane operation conforms to the operation and
   packet formats specified in [LISP].  However, encapsulating a
   multicast packet from an ITR is a much simpler process.  The process
   is simply to copy the inner group address to the outer destination
   address.  And to have the ITR use its own IP address (its RLOC), and
   as the source address.  The process is simpler for multicast because
   there is no EID-to-RLOC mapping lookup performed during packet
   forwarding.

   In the decapsulation case, the ETR simply removes the outer header
   and performs a multicast routing table lookup on the inner header
   (S-EID,G) addresses.  Then the oif-list for the (S-EID,G) entry is
   used to replicate the packet on site-facing interfaces leading to
   multicast receiver hosts.

   There is no Data-Probe logic for ETRs as there can be in the unicast
   forwarding case.

8.1.  ITR Forwarding Procedure

   The following procedure is used by an ITR, when it receives a
   multicast packet from a source inside of its site:

   1.  A multicast data packet sent by a host in a LISP site will have
       the source address equal to the host's EID and the destination
       address equal to the group address of the multicast group.  It is
       assumed the group information is obtained by current methods.
       The same is true for a multicast receiver to obtain the source
       and group address of a multicast flow.

   2.  When the ITR receives a multicast packet, it will have both S-EID
       state and S-RLOC state stored.  Since the packet was received on
       a site-facing interface, the RPF lookup is based on the S-EID
       state.  If the RPF check succeeds, then the oif-list contains
       interfaces that are site-facing and external-facing.  For the
       site-facing interfaces, no LISP header is prepended.  For the
       external-facing interfaces a LISP header is prepended.  When the
       ITR prepends a LISP header, it uses its own RLOC address as the
       source address and copies the group address supplied by the IP
       header the host built as the outer destination address.

8.1.1.  Multiple RLOCs for an ITR

   Typically, an ITR will have a single RLOC address but in some cases
   there could be multiple RLOC addresses assigned from either the same
   or different service providers.  In this case when (S-RLOC,G) Join/
   Prune messages are received for each RLOC, there is a oif-list
   merging action that must take place.  Therefore, when a packet is
   received from a site-facing interface that matches on a (S-EID,G)
   entry, the interfaces of the oif-list from all (RLOC,G) entries
   joined to the ITR as well as the site-facing oif-list joined for
   (S-EID,G) must be part be included in packet replication.  In
   addition to replicating for all types of oif-lists, each oif entry
   must be tagged with the RLOC address, so encapsulation uses the outer
   source address for the RLOC joined.

8.1.2.  Multiple ITRs for a LISP Source Site

   Note when ETRs from different multicast receiver sites receive
   (S-EID,G) joins, they may select a different S-RLOC for a multicast
   source site due to policy (the multicast ITR can return different
   multicast priority and weight values per ETR Map-Request).  In this
   case, the same (S-EID,G) is being realized by different (S-RLOC,G)
   state in the core.  This will not result in duplicate packets because
   each ITR in the multicast source site will choose their own RLOC for
   the source address for encapsulated multicast traffic.  The RLOC
   addresses are the ones joined by remote multicast ETRs.

8.2.  ETR Forwarding Procedure

   The following procedure is used by an ETR, when it receives a
   multicast packet from a source outside of its site:

   1.  When a multicast data packet is received by an ETR on an
       external-facing interface, it will do an RPF lookup on the S-RLOC
       state it has stored.  If the RPF check succeeds, the interfaces
       from the oif-list are used for replication to interfaces that are
       site-facing as well as interfaces that are external-facing (this
       ETR can also be a transit multicast router for receivers outside
       of its site).  When the packet is to be replicated for an
       external-facing interface, the LISP encapsulation header are not
       stripped.  When the packet is replicated for a site-facing
       interface, the encapsulation header is stripped.

   2.  The packet without a LISP header is now forwarded down the
       (S-EID,G) distribution tree in the receiver multicast site.

8.3.  Replication Locations

   Multicast packet replication can happen in the following topological
   locations:

   o  In an IGP multicast router inside a site which operates on S-EIDs.

   o  In a transit multicast router inside of the core which operates on
      S-RLOCs.

   o  At one or more ETR routers depending on the path a Join/Prune
      message exits a receiver multicast site.

   o  At one or more ITR routers in a source multicast site depending on
      what priorities are returned in a Map-Reply to receiver multicast
      sites.

   In the last case the source multicast site can do replication rather
   than having a single exit from the site.  But this only can occur
   when the priorities in the Map-Reply are modified for different
   receiver multicast site so that the PIM Join/Prune messages arrive at
   different ITRs.

   This policy technique, also used in [ALT] for unicast, is useful for
   multicast to mitigate the problems of changing distribution tree
   state as discussed in Section 6.

9.  LISP-Multicast Interworking

   This section will describe the multicast corollary to [INTWORK] which
   describes the interworking of multicast routing among LISP and non-
   LISP sites.

9.1.  LISP and non-LISP Mixed Sites

   Since multicast communication can involve more than two entities to
   communicate together, the combinations of interworking scenarios are
   more involved.  However, the state maintained for distribution trees
   at the sites is the same regardless of whether or not the site is
   LISP enabled or not.  So most of the implications are in the core
   with respect to storing routable EID prefixes from either PA or PI
   blocks.

   Before we enumerate the multicast interworking scenarios, we must
   define 3 deployment states of a site:

   o  A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it
      does today.  The addresses for the site are globally routable.

   o  A site that deploys LISP for unicast routing.  The addresses for
      the site are not globally routable.  Let's define the name for
      this type of site as a uLISP site.

   o  A site that deploys LISP for both unicast and multicast routing.
      The addresses for the site are not globally routable.  Let's
      define the name for this type of site as a LISP-Multicast site.

   We will not consider a LISP site enabled for multicast purposes only
   but do consider a uLISP site as documented in [INTWORK].  In this
   section we don't discuss how a LISP site sends multicast packets when
   all receiver sites are LISP-Multicast enabled; that has been
   discussed in previous sections.

   The following scenarios exist to make LISP-Multicast sites interwork
   with non-LISP-Multicast sites:

   1.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of non-LISP sites and uLISP sites.

   2.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of non-LISP sites and uLISP sites.

   3.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of LISP sites, uLISP sites, and
       non-LISP sites.

   4.  A uLISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

   5.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

9.1.1.  LISP Source Site to non-LISP Receiver Sites

   In the first scenario, a site is LISP capable for both unicast and
   multicast traffic and as such operates on EIDs.  Therefore there is a
   possibility that the EID prefix block is not routable in the core.
   For LISP receiver multicast sites this isn't a problem but for non-
   LISP or uLISP receiver multicast sites, when a PIM Join/Prune message
   is received by the edge router, it has no route to propagate the
   Join/Prune message out of the site.  This is no different than the
   unicast case that LISP-NAT in [INTWORK] solves.

   LISP-NAT allows a unicast packet that exits a LISP site to get its
   source address mapped to a globally routable address before the ITR
   realizes that it should not encapsulate the packet destined to a non-
   LISP site.  For a multicast packet to leave a LISP site, distribution
   tree state needs to be built so the ITR can know where to send the
   packet.  So the receiver multicast sites need to know about the
   multicast source host by its routable address and not its EID
   address.  When this is the case, the routable address is the
   (S-RLOC,G) state that is stored and maintained in the core routers.
   It is important to note that the routable address for the host cannot
   be the same as an RLOC for the site.  Because we want the ITRs to
   process a received PIM Join/Prune message from an external-facing
   interface to be propagated inside of the site so the site-part of the
   distribution tree is built.

   Using a globally routable source address allows non-LISP and uLISP
   multicast receiver to join, create, and maintain a multicast
   distribution tree.  However, the LISP multicast receiver site will
   want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
   Prune message is received on a site-facing interface.  It does this
   because it wants to find a (S-RLOC,G) entry to Join in the core.  So
   we have a conflict of behavior between the two types of sites.

   The solution to this problem is the same as when an ITR wants to send
   a unicast packet to a destination site but needs determine if the
   site is LISP capable or not.  When it is not LISP capable, the ITR
   does not encapsulate the packet.  So for the multicast case, when ETR
   receives a PIM Join/Prune message for (S-EID,G) state, it will do a
   mapping table lookup on S-EID.  In this case, S-EID is not in the
   mapping database because the source multicast site is using a
   routable address and not an EID prefix address.  So the ETR knows to
   simply propagate the PIM Join/Prune message to a external-facing
   interface without converting the (S-EID,G) because it is an (S,G)
   where S is routable and reachable via core routing tables.

   Now that the multicast distribution tree is built and maintained from
   any non-LISP or uLISP receiver multicast site, the way packet
   forwarding model is performed can be explained.

   Since the ITR in the source multicast site has never received a
   unicast encapsulated PIM Join/Prune message from any ETR in a
   receiver multicast site, it knows there are no LISP-Multicast
   receiver sites.  Therefore, there is no need for the ITR to
   encapsulate data.  Since it will know a priori (via configuration)
   that its site's EIDs are not routable, it assumes that the multicast
   packets from the source host are sent by a routable address.  That
   is, it is the responsibility of the multicast source host's system
   administrator to ensure that the source host sends multicast traffic
   using a routable source address.  When this happens, the ITR acts
   simply as a router and forwards the multicast packet like an ordinary
   multicast router.

   There is an alternative to using a LISP-NAT scheme just like there is
   for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
   (PTRs).
   (PxTRs).  This can work the same way for multicast routing as well,
   but the difference is that non-LISP and uLISP sites will send PIM
   Join/Prune messages for (S-EID,G) which make their way in the core to
   PTRs.
   multicast PxTRs.  Let's call this use of a PTR PxTR as a "Multicast PTR"
   Proxy-ETR" (or mPTR). mPETR).  Since the PTRs mPETRs advertise very coarse EID
   prefixes, they draw the PIM Join/Prune control traffic making them
   the target of the distribution tree.  To get multicast packets from
   the LISP source multicast sites, the tree needs to be built on the
   path from the mPTR mPETR to the LISP source multicast site.  To make this
   happen the mPTR mPETR acts as a "Proxy ETR" (where in unicast it acts as a
   "Proxy ITR"). ITR", or an uPITR).

   The existence of mPTRs mPETRs in the core allows LISP source multicast site ITRs
   to encapsulate multicast packets so the according to (S-RLOC,G) state.  The
   (S-RLOC,G) state is built between from the
   ITRs and mPETRs to the mPTRs is (S-RLOC,G) state.  Then the mPTRs can
   decapsulate multicast ITRs.  The
   encapsulated multicast packets are decapsulated by mPETRs and forward natively then
   forwarded according to (S-EID,G) state.  The (S-EID,G) state is built
   from the non-LISP and uLISP receiver multicast sites. sites to the mPETRs.

9.1.2.  Non-LISP Source Site to non-LISP Receiver  Sites

   Clearly non-LISP multicast sites can send multicast packets to non-
   LISP receiver multicast sites.  That is what they do today.  However,
   discussion is required to show how non-LISP multicast sites send
   multicast packets to uLISP receiver multicast sites.

   Since uLISP receiver multicast sites are not targets of any (S,G)
   state, they simply send (S,G) PIM Join/Prune messages toward the non-
   LISP source multicast site.  Since the source multicast site, in this
   case has not been upgraded to LISP, all multicast source host
   addresses are routable.  So this case is simplified to where a uLISP
   receiver multicast site looks to the source multicast site as a non-
   LISP receiver multicast site.

9.1.3.  Non-LISP Source Site to Any Receiver Site

   When a non-LISP source multicast site has receivers in either a non-
   LISP/uLISP site or a LISP site, one needs to decide how the LISP
   receiver multicast site will attach to the distribution tree.  We
   know from Section 9.1.2 that non-LISP and uLISP receiver multicast
   sites can join the distribution tree, but a LISP receiver multicast
   site ETR will need to know if the source address of the multicast
   source host is routable or not.  We showed in Section 9.1.1 that an
   ETR, before it sends a PIM Join/Prune message on an external-facing
   interface, does a EID-to-RLOC mapping lookup to determine if it
   should convert the (S,G) state from a PIM Join/Prune message received
   on a site-facing interface to a (S-RLOC,G).  If the lookup fails, the
   ETR can conclude the source multicast site is a non-LISP site so it
   simply forwards the Join/Prune message (it also doesn't need to send
   a unicast encapsulated Join/Prune message because there is no ITR in
   a non-LISP site and there is namespace continuity between the ETR and
   source).

   For a non-LISP source multicast site, (S-EID,G) state could be
   limited to the edges of the network with the use of multicast proxy-
   ITRs (mPITRs).  The mPITRs can take native, unencapsulated multicast
   packets from non-LISP source multicast and uLISP sites and
   encapsulate them to ETRs in receiver multicast sites or to mPETRs
   that can decapsulate for non-LISP receiver multicast or uLISP sites.
   The mPITRs are responsible for sending (S-EID,G) joins to the non-
   LISP source multicast site.  To connect the distribution trees
   together, multicast ETRs will need to be configured with the mPITR's
   RLOC addresses so they can send both (S-RLOC,G) joins to build a
   distribution tree to the mPITR as well as for sending unicast oins to
   mPITRs so they can propogate (S-EID,G) joins into source multicast
   sites.  The use of mPITRs is undergoing more study and is work in
   progress.

9.1.4.  Unicast LISP Source Site to Any Receiver Sites

   In the last section, it was explained how an ETR in a multicast
   receiver site can determine if a source multicast site is LISP-
   enabled by looking into the mapping database.  When the source
   multicast site is a uLISP site, it is LISP enabled but the ITR, by
   definition is not capable of doing multicast encapsulation.  So for
   the purposes of multicast routing, the uLISP source multicast site is
   treated as non-LISP source multicast site.

   Non-LISP receiver multicast sites can join distribution trees to a
   uLISP source multicast site since the source site behaves, from a
   forwarding perspective, as a non-LISP source site.  This is also the
   case for a uLISP receiver multicast site since the ETR does not have
   multicast functionality built-in or enabled.

   Special considerations are required for LISP receiver multicast sites
   since they think the source multicast site is LISP capable, the ETR
   cannot know if ITR is LISP-Multicast capable.  To solve this problem,
   each mapping database entry will have a multicast 2-tuple (Mpriority,
   Mweight) per RLOC.  When the Mpriority is set to 255, the site is
   considered not multicast capable.  So an ETR in a LISP receiver
   multicast site can distinguish whether a LISP source multicast site
   is LISP-Multicast site from a uLISP site.

9.1.5.  LISP Source Site to Any Receiver Sites

   When a LISP source multicast site has receivers in LISP, non-LISP,
   and uLISP receiver multicast sites, it has a conflict about how it
   sends multicast packets.  The ITR can either encapsulate or natively
   forward multicast packets.  Since the receiver multicast sites are
   heterogeneous in their behavior, one packet forwarding mechanism
   cannot satisfy both.  However, if a LISP receiver multicast site acts
   like a uLISP site then it could receive packets like a non-LISP
   receiver multicast site making all receiver multicast sites have
   homogeneous behavior.  However, this poses the following issues:

   o  LISP-NAT techniques with routable addresses would be required in
      all cases.

   o  Or alternatively, mPTR mPETR deployment would be required forcing
      coarse EID prefix advertisement in the core.

   o  But what is most disturbing is that when all sites that
      participate are LISP-Multicast sites but then a non-LISP or uLISP
      site joins the distribution tree, then the existing joined LISP
      receiver multicast sites would have to change their behavior.
      This would create too much dynamic tree-building churn to be a
      viable alternative.

   So the solution space options are:

   1.  Make the LISP ITR in the source multicast site send two packets,
       one that is encapsulated with (S-RLOC,G) to reach LISP receiver
       multicast sites and another that is not encapsulated with
       (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.

   2.  Make the LISP ITR always encapsulate packets with (S-RLOC,G) to
       reach LISP-Multicast sites and to reach mPTRs mPETRs that can
       decapsulate and forward (S-EID,G) packets to non-LISP and uLISP
       receiver multicast sites.

9.2.  LISP Sites with Mixed Address Families

   A LISP database mapping entry that describes the locator-set,
   Mpriority and Mweight per locator address (RLOC), for an EID prefix
   associated with a site could have RLOC addresses in either IPv4 or
   IPv6 format.  When a mapping entry has a mix of RLOC formatted
   addresses, it is an implicit advertisement by the site that it is a
   dual-stack site.  That is, the site can receive IPv4 or IPv6 unicast
   packets.

   To distinguish if the site can receive dual-stack unicast packets as
   well as dual-stack multicast packets, the Mpriority value setting
   will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format
   details.

   If you consider the combinations of LISP, non-LISP, and uLISP sites
   sharing the same distribution tree and considering the capabilities
   of supporting IPv4, IPv6, or dual-stack, the number of total
   combinations grows beyond comprehension.

   Using some combinatorial math, we have the following profiles of a
   site and the combinations that can occur:

   1.  LISP-Multicast IPv4 Site

   2.  LISP-Multicast IPv6 Site

   3.  LISP-Multicast Dual-Stack Site

   4.  uLISP IPv4 Site

   5.  uLISP IPv6 Site
   6.  uLISP Dual-Stack Site

   7.  non-LISP IPv4 Site

   8.  non-LISP IPv6 Site

   9.  non-LISP Dual-Stack Site

   Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to
   illustrate some combinatorial math below.

   When 1 site talks to another site, the combinatorial is (9 2), when 1
   site talks to another 2 sites, the combinatorial is (9 3).  If sum
   this up to (9 9), we have:

   (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =

     36  +   84  +  126  +  126  +   84  +   36  +   9   +   1

   Which results in the total number of cases to be considered at 502.

   This combinatorial gets even worse when you consider a site using one
   address family inside of the site and the xTRs use the other address
   family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4
   RLOCs).

   To rationalize this combinatorial nightmare, there are some
   guidelines which need to be put in place:

   o  Each distribution tree shared among between sites will either be an IPv4
      distribution tree or an IPv6 distribution tree.  Therefore, we can
      avoid head-end replication by building and sending packets on each
      address family based distribution tree.  Even though there might
      be an urge to do multicast packet translation from one address
      family format to the other, it is a non-viable over-complicated
      urge.  Multicast ITRs will only encapsulate packets where the
      inner and outer headers are from the same address family.

   o  All LISP sites on a multicast distribution tree must share a
      common address family which is determined by the source site's
      locator-set in its LISP database mapping entry.  All receiver
      multicast sites will use the best RLOC priority controlled by the
      source multicast site.  This is true when the source site is
      either LISP-Multicast or uLISP capable.  This means that priority-
      based policy modification is prohibited.  When a receiver
      multicast site ETR receives a (S-EID,G) join, it must select a
      S-RLOC for the same address family as S-EID.

   o  A mixed multicast locator-set with the best multicast priority
      values MUST not be configured on multicast ITRs.  A mixed locator-
      set can exist (for unicast use), but the multicast priorities MUST
      be the set for the same address family locators.

   o  When the source site is not LISP capable, it is up to how
      receivers find the source and group information for a multicast
      flow.  That mechanism decides the address family for the flow.

9.3.  Making a Multicast Interworking Decision

   This Multicast Interworking section has shown all combinations of
   multicast connectivity that could occur.  As you might have already
   concluded, this can be quite complicated and if the design is too
   ambitious, the dynamics of the protocol could cause a lot of
   instability.

   The trade-off decisions are hard to make and we want the same single
   solution to work for both IPv4 and IPv6 multicast.  It is imperative
   to have an incrementally deployable solution for all of IPv4 unicast
   and multicast and IPv6 unicast and multicast while minimizing (or
   eliminating) both unicast and multicast EID namespace state.

   Therefore the design decision to go with PTRs uPITRs for unicast routing
   and
   mPTRs mPETRs for multicast routing seems to be the sweet spot in the
   solution space so we can optimize state requirements and avoid head-
   end data replication at ITRs.

10.  Considerations when RP Addresses are Embedded in Group Addresses

   When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a
   technique exists to embed the unicast address of an RP in a IPv6
   group address [RFC3956].  When routers in end sites process a PIM
   Join/Prune message which contain an embedded-RP group address, they
   extract the RP address from the group address and treat it from the
   EID namespace.  However, core routers do not have state for the EID
   namespace, need to extract an RP address from the RLOC namespace.

   Therefore, it is the responsibility of ETRs in multicast receiver
   sites to map the group address into a group address where the
   embedded-RP address is from the RLOC namespace.  The mapped RP-
   address is obtained from a EID-to-RLOC mapping database lookup.  The
   ETR will also send a unicast (*,G) Join/Prune message to the ITR so
   the branch of the distribution tree from the source site resident RP
   to the ITR is created.

   This technique is no different than the techniques described in this
   specification for translating (S,G) state and propagating Join/Prune
   messages into the core.  The only difference is that the (*,G) state
   in Join/Prune messages are mapped because they contain unicast
   addresses encoded in an Embedded-RP group address.

11.  Taking Advantage of Upgrades in the Core

   If the core routers are upgraded to support [RPFV] and [RFC5496],
   then we can pass EID specific data through the core without,
   possibly, having to store the state in the core.

   By doing this we can eliminate the ETR from unicast encapsulating PIM
   Join/Prune messages to the source site's ITR.

   However, this solution is restricted to a small set of workable cases
   which would not be good for general use of LISP-Multicast.  In
   addition to slow convergence properties, it is not being recommended
   for LISP-Multicast.

12.  Mtrace Considerations

   Mtrace functionality must be consistent with unicast traceroute
   functionality where all hops from multicast receiver to multicast
   source are visible.

   The design for mtrace for use in LISP-Multicast environments is to be
   determined but should build upon the mtrace version 2 specified in
   [MTRACE].

13.  Security Considerations

   Refer to the [LISP] specification.

14.  Acknowledgments

   The authors would like to gratefully acknowledge the people who have
   contributed discussion, ideas, and commentary to the making of this
   proposal and specification.  People who provided expert review were
   Scott Brim, Greg Shepherd, and Dave Oran.  Other commentary from
   discussions at Summer 2008 Dublin IETF were Toerless Eckert and
   Ijsbrand Wijnands.

   We would also like to thank the MBONED working group for constructive
   and civil verbal feedback when this draft was presented at the Fall
   2008 IETF in Minneapolis.  In particular, good commentary came from
   Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
   Ron Bonica, and Lenny Guardino.

   An expert review of this specification was done by Yiqun Cai and
   Liming Wei. We thank them for their detailed comments.

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [MLISP] was converted into this IETF LISP
   working group draft.

15.  References

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

15.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
              Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt draft-ietf-lisp-alt-04.txt (work in
              progress), May 2009. April 2010.

   [INTWORK]  Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
              with IPv4 and IPv6", draft-ietf-lisp-interworking-00.txt draft-ietf-lisp-interworking-01.txt
              (work in progress), May 2009. March 2010.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-05.txt
              draft-ietf-lisp-07.txt (work in progress), September 2009. April 2010.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-farinacci-lisp-multicast-01.txt (work in progress),
              November 2008.

   [MNAT]     Wing, D. and T. Eckert, "Multicast Requirements for a
              Network Address (and  port) Translator (NAT)",
              draft-ietf-behave-multicast-07.txt (work in progress),
              June 2007.

   [MTRACE]   Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
              Version 2: Traceroute Facility for IP Multicast",
              draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
              March 2009.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),
              February 2008.

Appendix A.  Document Change Log

A.1.  Changes to draft-ietf-lisp-multicsat-02.txt draft-ietf-lisp-multicast-03.txt

   o  Posted April 2010.

   o  Added section 8.1.2 to address Joel Halpern's comment about
      receiver sites joining the same source site via 2 different RLOCs,
      each being a separate ITR.

   o  Change all occurences of "mPTR" to "mPETR" to become more
      consistent with uPITRs and uPETRs described in [INTWORK].  That
      is, an mPETR is a LISP multicast router that decapsulates
      multicast packets that are encapsulated to it by ITRs in multicast
      source sites.

   o  Add clarifications in section 9 about how homogeneous multicast
      encapsulation should occur.  As well as describing in this
      section, how to deal with mixed-locator sets to avoid
      heterogeneous encapsulation.

   o  Introduce concept of mPITRs to help reduce (S-EID,G) to the edges
      of LISP global multicast network.

A.2.  Changes to draft-ietf-lisp-multicast-02.txt

   o  Posted September 2009.

   o  Added Document Change Log appendix.

   o  Specify that the LISP Encapsulated Control Message be used for
      unicasting PIM Join/Prune messages from ETRs to ITRs.

A.2.

A.3.  Changes to draft-ietf-lisp-multicsat-01.txt draft-ietf-lisp-multicast-01.txt

   o  Posted November 2008.

   o  Specified that PIM Join/Prune unicast messages that get sent from
      ETRs to ITRs of a source multicast site get LISP encapsulated in
      destination UDP port 4342.

   o  Add multiple RLOCs per ITR per Yiqun's comments.

   o  Indicate how static RPs can be used when LISP is run using Bidir-
      PIM in the core.

   o  Editorial changes per Liming comments.

   o  Add Mttrace Considersations section.

A.3.

A.4.  Changes to draft-ietf-lisp-multicsat-00.txt draft-ietf-lisp-multicast-00.txt

   o  Posted April 2008.

   o  Renamed from draft-farinacci-lisp-multicast-01.txt.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dino@cisco.com

   Dave Meyer
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   John Zwiebel
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: jzwiebel@cisco.com

   Stig Venaas
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: stig@cisco.com
--Apple-Mail-12-1012096568 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > > > --Apple-Mail-12-1012096568 Content-Disposition: attachment; filename=draft-ietf-lisp-multicast-03.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-multicast-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel Expires: October 14, 2010 S. Venaas cisco Systems April 12, 2010 LISP for Multicast Environments draft-ietf-lisp-multicast-03 Abstract This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 14, 2010. Copyright Notice Copyright (c) 2010 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 Farinacci, et al. Expires October 14, 2010 [Page 1] =0C Internet-Draft LISP for Multicast Environments April 2010 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 BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 6. Locator Reachability Implications on LISP-Multicast . . . . . 13 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 17 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 21 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 23 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 24 9.3. Making a Multicast Interworking Decision . . . . . . . . . 26 10. Considerations when RP Addresses are Embedded in Group Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 28 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32 15.2. Informative References . . . . . . . . . . . . . . . . . . 32 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 34 A.1. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 34 A.2. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 34 A.3. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 34 A.4. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Farinacci, et al. Expires October 14, 2010 [Page 2] =0C Internet-Draft LISP for Multicast Environments April 2010 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires October 14, 2010 [Page 3] =0C Internet-Draft LISP for Multicast Environments April 2010 2. Introduction The Locator/ID Separation Architecture [LISP] provides a mechanism to separate out Identification and Location semantics from the current definition of an IP address. By creating two namespaces, an EID namespace used by sites and a Locator (RLOC) namespace used by core routing, the core routing infrastructure can scale by doing topological aggregation of routing information. Since LISP creates a new namespace, a mapping function must exist to map a site's EID prefixes to its associated locators. For unicast packets, both the source address and destination address must be mapped. For multicast packets, only the source address needs to be mapped. The destination group address doesn't need to be mapped because the semantics of an IPv4 or IPv6 group address are logical in nature and not topology-dependent. Therefore, this specifications focuses on to map a source EID address of a multicast flow during distribution tree setup and packet delivery. This specification will address the following scenarios: 1. How a multicast source host in a LISP site sends multicast packets to receivers inside of its site as well as to receivers in other sites that are LISP enabled. 2. How inter-domain (or between LISP sites) multicast distribution trees are built and how forwarding of multicast packets leaving a source site toward receivers sites is performed. 3. What protocols are affected and what changes are required to such multicast protocols. 4. How ASM-mode, SSM-mode, and Bidir-mode service models will operate. 5. How multicast packet flow will occur for multiple combinations of LISP and non-LISP capable source and receiver sites, for example: A. How multicast packets from a source host in a LISP site are sent to receivers in other sites when they are all non-LISP sites. B. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. C. How multicast packets from a source host in a non-LISP site are sent to receivers in other sites when they are all LISP- Farinacci, et al. Expires October 14, 2010 [Page 4] =0C Internet-Draft LISP for Multicast Environments April 2010 enabled sites. D. How multicast packets from a source host in a non-LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multi- protocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled. Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not run in an inter-domain environment is not addressed in depth in this version of the specification. Also, the current version of this specification does not describe multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR descriptions in [LISP]. Farinacci, et al. Expires October 14, 2010 [Page 5] =0C Internet-Draft LISP for Multicast Environments April 2010 3. Definition of Terms The terminology in this section is consistent with the definitions in [LISP] but is extended specifically to deal with the application of the terminology to multicast routing. LISP-Multicast: a reference to the design in this specification. That is, when any site that is participating in multicast communication has been upgraded to be a LISP site, the operation of control-plane and data-plane protocols is considered part of the LISP-Multicast architecture. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source address field of the first (most inner) LISP header of a multicast packet. The host obtains a destination group address the same way it obtains one today, as it would when it is a non-LISP site. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID prefix block associated with the site the host is located in. An EID can be used by a host to refer to another host, as when it joins an SSM (S-EID,G) route using IGMP version 3 [RFC4604]. LISP uses Provider Independent (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress tunnel router (ITR), the router in the multicast source host's site that encapsulates multicast packets. It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ITR device or to multiple ITR devices at a site. Ingress Tunnel Router (ITR): a router which accepts an IP multicast packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination multicast address opaquely so it doesn't need to perform a map lookup on the group address because it is topologically insignificant. The router then prepends an "outer" IP header with one of its globally-routable RLOCs as the source address field. This RLOC is known to other multicast receiver Farinacci, et al. Expires October 14, 2010 [Page 6] =0C Internet-Draft LISP for Multicast Environments April 2010 sites which have used the mapping database to join a multicast tree for which the ITR is the root. In general, an ITR receives IP packets from site end systems on one side and sends LISP- encapsulated multicast IP packets out all external interfaces which have been joined. An ITR would receive a multicast packet from a source inside of its site when 1) it is on the path from the multicast source to internally joined receivers, or 2) when it is on the path from the multicast source to externally joined receivers. Egress Tunnel Router (ETR): a router that is on the path from a multicast source host in another site to a multicast receiver in its own site. An ETR accepts a PIM Join/Prune message from a site internal PIM router destined for the source's EID in the multicast source site. The ETR maps the source EID in the Join/Prune message to an RLOC address based on the EID-to-RLOC mapping. This sets up the ETR to accept multicast encapsulated packets from the ITR in the source multicast site. A multicast ETR decapsulates multicast encapsulated packets and replicates them on interfaces leading to internal receivers. xTR: is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality can be at the CE router. LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR prepends headers and an ETR strips headers. A LISP encapsulated multicast packet will have an "inner" header with the source EID in the source field; an "outer" header with the source RLOC in the source field: and the same globally unique group address in the destination field of both the inner and outer header. (S,G) State: the formal definition is in the PIM Sparse Mode [RFC4601] specification. For this specification, the term is used generally to refer to multicast state. Based on its topological location, the (S,G) state resides in routers can be either (S-EID,G) state (at a location where the (S,G) state resides) or (S-RLOC,G) state (in the Internet core). (S-EID,G) State: refers to multicast state in multicast source and receiver sites where S-EID is the IP address of the multicast source host (its EID). An S-EID can appear in an IGMPv3 report, an MSDP SA message or a PIM Join/Prune message that travels inside Farinacci, et al. Expires October 14, 2010 [Page 7] =0C Internet-Draft LISP for Multicast Environments April 2010 of a site. (S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) entry by doing a mapping database lookup for the EID prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message when it travels from an ETR to an ITR over the Internet core. uLISP Site: a unicast only LISP site according to [LISP] which has not deployed the procedures of this specification and therefore, for multicast purposes, follows the procedures from Section 9. mPETR: this is a multicast proxy-ETR that is responsible for advertising a very coarse EID prefix which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPETRs act as Proxy ETRs for supporting multicast routing in a LISP infrastructure. It is likely an uPITR and a mPETR will be co-loacted since the single device advertises a coarse EID-prefix in the underlying unicast routing system. Mixed Locator-Sets: this is a locator-set for a LISP database mapping entry where the RLOC addresses in the locator-set are in both IPv4 and IPv6 format. Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (encapsulated in a LISP Encapsulated Control Message with destination UDP port 4342) which is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces in the oif-list for the (S-EID,G) entry the ETR is joining for. Farinacci, et al. Expires October 14, 2010 [Page 8] =0C Internet-Draft LISP for Multicast Environments April 2010 4. Basic Overview LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the traffic engineering features of LISP, a multicast source site can control the egress of its multicast traffic. By controlling the priorities of locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site. At this point in time, we don't see a requirement for different locator-sets, priority, and weight policies for multicast than we have for unicast. The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet. An ITR will encapsulate multicast packets received from sources that it serves in another LISP multicast header. The destination group address from the inner header is copied to the destination address of the outer header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR. The LISP-Multicast architecture will follow this high-level protocol and operational sequence: 1. Receiver hosts in multicast sites will join multicast content the way they do today, they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs, that is they join (S-EID,G). If the S-EID is a local multicast source host. If the multicast source is external to this receiver site, the PIM Join/Prune message flows toward the ETRs, finding the shortest exit (that is the closest exit for the Join/Prune message but it is the closest entrance for the multicast packet to the receiver). 2. The ETR does a mapping database lookup for S-EID. If the mapping is cached from a previous lookup (from either a previous Join/ Prune for the source multicast site or a unicast packet that went to the site), it will use the RLOC information from the mapping. The ETR will use the same priority and weighting mechanism as for unicast. So the source site can decide which way multicast packets egress. Farinacci, et al. Expires October 14, 2010 [Page 9] =0C Internet-Draft LISP for Multicast Environments April 2010 3. The ETR will build two PIM Join/Prune messages, one that contains a (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects, and the other which contains a (S-RLOC,G) entry so the core network can create multicast state from this ETR to the ITR. 4. When the ITR gets the unicast Join/Prune message (see Section 3 for formal definition), it will process (S-EID,G) entries in the message and propagate them inside of the site where it has explicit routing information for EIDs via the IGP. When the ITR receives the (S-RLOC,G) PIM Join/Prune message it will process it like any other join it would get in today's Internet. The S-RLOC address is the IP address of this ITR. 5. At this point there is (S-EID,G) state from the joining host in the receiver multicast site to the ETR of the receiver multicast site. There is (S-RLOC,G) state across the core network from the ETR of the multicast receiver site to the ITR in the multicast source site and (S-EID,G) state in the source multicast site. Note, the (S-EID,G) state is the same S-EID in each multicast site. As other ETRs join the same multicast tree, they can join through the same ITR (in which case the packet replication is done in the core) or a different ITR (in which case the packet replication is done at the source site). 6. When a packet is originated by the multicast host in the source site, it will flow to one or more ITRs which will prepend a LISP header by copying the group address to the outer destination address field and insert its own locator address in the outer source address field. The ITR will look at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicate the packet on each interface a (S-RLOC,G) joined was received on. The core has (S-RLOC,G) so where fanout occurs to multiple sites, a core router will do packet replication. 7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group address. It will also decapsulate packets because it has receivers for the group. Otherwise, it would have not received the packets because it would not have joined. The ETR decapsulates and does a (S-EID,G) lookup in its multicast FIB to forward packets out one or more interfaces to forward the packet to internal receivers. This architecture is consistent and scalable with the architecture presented in [LISP] where multicast state in the core operates on locators and multicast state at the sites operates on EIDs. Farinacci, et al. Expires October 14, 2010 [Page 10] =0C Internet-Draft LISP for Multicast Environments April 2010 Alternatively, [LISP] does present a mechanism where (S-EID,G) state can reside in the core through the use of RPF-vectors [RPFV] in PIM Join/Prune messages. However, this will require EID state in core as well as the use of RPF-vector formatted Join/Prune messages which are not the default implementation choice. So we choose a design that can allow the separation of namespaces as unicast LISP provides. It will be at the expense of creating new (S-RLOC,G) state when ITRs go unreachable. See Section 5 for details. However, we have some observations on the algorithm above. We can scale the control plane but at the expense of sending data to sites which may have not joined the distribution tree where the encapsulated data is being delivered. For example, one site joins (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the same multicast source site. Both multicast receiver sites join to the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the site. The ITR receives (S-RLOC,G) joins and populates the oif-list state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one (S-RLOC,G) packets will be delivered by the core to both multicast receiver sites even though each have joined a single source-based distribution tree. This behavior is a consequence of the many-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution to this problem which reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one- to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but we can reduce the "n" to a smaller number in the "n-to-1" relationship. And in turn, reduce the opportunity for data packets to be delivered to sites for groups not joined. Farinacci, et al. Expires October 14, 2010 [Page 11] =0C Internet-Draft LISP for Multicast Environments April 2010 5. Source Addresses versus Group Addresses Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental deployment of LISP-Multicast. As for source addresses, as in the unicast LISP scenario, there is a decoupling of identification from location. In a LISP site, packets are originated from hosts using their allocated EIDs, those addresses are used to identify the host as well as where in the site's topology the host resides but not how and where it is attached to the Internet. Therefore, when multicast distribution tree state is created anywhere in the network on the path from any multicast receiver to a multicast source, EID state is maintained at the source and receiver multicast sites, and RLOC state is maintained in the core. That is, a multicast distribution tree will be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 3-tuple is the state stored in routers from the source to one or more ITRs in the source multicast site, the second element of the 3-tuple is the state stored in routers downstream of the ITR, in the core, to all LISP receiver multicast sites, and the third element in the 3-tuple is the state stored in the routers downstream of each ETR, in each receiver multicast site, reaching each receiver. Note that (S-EID,G) is the same in both the source and receiver multicast sites. The concatenation/mapping from the first element to the second element of the 3-tuples is done by the ITR and from the second element to the third element is done at the ETRs. Farinacci, et al. Expires October 14, 2010 [Page 12] =0C Internet-Draft LISP for Multicast Environments April 2010 6. Locator Reachability Implications on LISP-Multicast Multicast state as it is stored in the core is always (S,G) state as it exists today or (S-RLOC,G) state as it will exist when LISP sites are deployed. The core routers cannot distinguish one from the other. They don't need to because it is state that RPFs against the core routing tables in the RLOC namespace. The difference is where the root of the distribution tree for a particular source is. In the traditional multicast core, the source S is the source host's IP address. For LISP-Multicast the source S is a single ITR of the multicast source site. An ITR is selected based on the LISP EID-to-RLOC mapping used when an ETR propagates a PIM Join/Prune message out of a receiver multicast site. The selection is based on the same algorithm an ITR would use to select an ETR when sending a unicast packet to the site. In the unicast case, the ITR can change on a per-packet basis depending on the reachability of the ETR. So an ITR can change relatively easily using local reachability state. However, in the multicast case, when an ITR goes unreachable, new distribution tree state must be built because the encapsulating root has changed. This is more significant than an RPF-change event, where any router would typically locally change its RPF-interface for its existing tree state. But when an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be rebuilt and reflect the new encapsulator. Therefore, when an ITR goes unreachable, all ETRs that are currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) to the new ITR as well as send a unicast encapsulated Join/Prune message telling the new ITR which (S-EID,G) is being joined. This issue can be mitigated by using anycast addressing for the ITRs so the problem does reduce to an RPF change in the core, but still requires a unicast encapsulated Join/Prune message to tell the new ITR about (S-EID,G). The problem with this approach is that the ETR really doesn't know when the ITR has changed so the new anycast ITR will get the (S-EID,G) state only when the ETR sends it the next time during its periodic sending procedures. Farinacci, et al. Expires October 14, 2010 [Page 13] =0C Internet-Draft LISP for Multicast Environments April 2010 7. Multicast Protocol Changes A number of protocols are used today for inter-domain multicast routing: IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for LISP-Multicast for two reasons. One being that they are link- local and not used over site boundaries and second they advertise group addresses that don't need translation. Where source addresses are supplied in IGMPv3 and MLDv2 messages, they are semantically regarded as EIDs and don't need to be converted to RLOCs until the multicast tree-building protocol, such as PIM, is received by the ETR at the site boundary. Addresses used for IGMP and MLD come out of the source site's allocated addresses which are therefore from the EID namespace. MBGP: Even though MBGP is not a multicast routing protocol, it is used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology are not congruent. When MBGP is used in a LISP-Multicast environment, the prefixes which are advertised are from the RLOC namespace. This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace. MSDP: MSDP is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of site will be from the EID namespace so it can be advertised and reached by internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. And the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. PIM-SSM: In the simplest form of distribution tree building, when PIM operates in SSM mode, a source distribution tree is built and maintained across site boundaries. In this case, there is a small modification to the operation of the PIM protocol (but not to any Farinacci, et al. Expires October 14, 2010 [Page 14] =0C Internet-Draft LISP for Multicast Environments April 2010 message format) to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [MNAT]. PIM-Bidir: Bidirectional PIM is typically run inside of a routing domain, but if deployed in an inter-domain environment, one would have to decide if the RP address of the shared-tree would be from the EID namespace or the RLOC namespace. If the RP resides in a site-based router, then the RP address is from the EID namespace. If the RP resides in the core where RLOC addresses are routed, then the RP address is from the RLOC namespace. This could be easily distinguishable if the EID address were well-known address allocation block from the RLOC namespace. Also, when using Embedded-RP for RP determination [RFC3956], the format of the group address could indicate the namespace the RP address is from. However, refer to Section 10 for considerations core routers need to make when using Embedded-RP IPv6 group addresses. When using Bidir-PIM for inter-domain multicast routing, it is recommended to use staticly configured RPs so core routers think the Bidir group is associated with an ITR's RLOC as the RP address and site routers think the Bidir group is associated with the site resident RP with an EID address. With respect to DF-election in Bidir PIM, no changes are required since all messaging and addressing is link-local. PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is deployed in the Internet today is by having shared-trees within a site and using source-trees across sites. By the use of MSDP and PIM-SSM techniques described above, we can get multicast connectivity across LISP sites. Having said that, that means there are no special actions required for processing (*,G) or (S,G,R) Join/Prune messages since they all operate against the shared-tree which is site resident. Just like with ASM, there is no (*,G) in the core when LISP-Multicast is in use. This is also true for the RP-mapping mechanisms Auto-RP and BSR. Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control-plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change. It should also be stated just like it is in [LISP] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive multicast packets. Farinacci, et al. Expires October 14, 2010 [Page 15] =0C Internet-Draft LISP for Multicast Environments April 2010 8. LISP-Multicast Data-Plane Architecture The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in [LISP]. However, encapsulating a multicast packet from an ITR is a much simpler process. The process is simply to copy the inner group address to the outer destination address. And to have the ITR use its own IP address (its RLOC), and as the source address. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding. In the decapsulation case, the ETR simply removes the outer header and performs a multicast routing table lookup on the inner header (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is used to replicate the packet on site-facing interfaces leading to multicast receiver hosts. There is no Data-Probe logic for ETRs as there can be in the unicast forwarding case. 8.1. ITR Forwarding Procedure The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site: 1. A multicast data packet sent by a host in a LISP site will have the source address equal to the host's EID and the destination address equal to the group address of the multicast group. It is assumed the group information is obtained by current methods. The same is true for a multicast receiver to obtain the source and group address of a multicast flow. 2. When the ITR receives a multicast packet, it will have both S-EID state and S-RLOC state stored. Since the packet was received on a site-facing interface, the RPF lookup is based on the S-EID state. If the RPF check succeeds, then the oif-list contains interfaces that are site-facing and external-facing. For the site-facing interfaces, no LISP header is prepended. For the external-facing interfaces a LISP header is prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address and copies the group address supplied by the IP header the host built as the outer destination address. 8.1.1. Multiple RLOCs for an ITR Typically, an ITR will have a single RLOC address but in some cases there could be multiple RLOC addresses assigned from either the same or different service providers. In this case when (S-RLOC,G) Join/ Farinacci, et al. Expires October 14, 2010 [Page 16] =0C Internet-Draft LISP for Multicast Environments April 2010 Prune messages are received for each RLOC, there is a oif-list merging action that must take place. Therefore, when a packet is received from a site-facing interface that matches on a (S-EID,G) entry, the interfaces of the oif-list from all (RLOC,G) entries joined to the ITR as well as the site-facing oif-list joined for (S-EID,G) must be part be included in packet replication. In addition to replicating for all types of oif-lists, each oif entry must be tagged with the RLOC address, so encapsulation uses the outer source address for the RLOC joined. 8.1.2. Multiple ITRs for a LISP Source Site Note when ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site due to policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In this case, the same (S-EID,G) is being realized by different (S-RLOC,G) state in the core. This will not result in duplicate packets because each ITR in the multicast source site will choose their own RLOC for the source address for encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs. 8.2. ETR Forwarding Procedure The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site: 1. When a multicast data packet is received by an ETR on an external-facing interface, it will do an RPF lookup on the S-RLOC state it has stored. If the RPF check succeeds, the interfaces from the oif-list are used for replication to interfaces that are site-facing as well as interfaces that are external-facing (this ETR can also be a transit multicast router for receivers outside of its site). When the packet is to be replicated for an external-facing interface, the LISP encapsulation header are not stripped. When the packet is replicated for a site-facing interface, the encapsulation header is stripped. 2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site. 8.3. Replication Locations Multicast packet replication can happen in the following topological locations: Farinacci, et al. Expires October 14, 2010 [Page 17] =0C Internet-Draft LISP for Multicast Environments April 2010 o In an IGP multicast router inside a site which operates on S-EIDs. o In a transit multicast router inside of the core which operates on S-RLOCs. o At one or more ETR routers depending on the path a Join/Prune message exits a receiver multicast site. o At one or more ITR routers in a source multicast site depending on what priorities are returned in a Map-Reply to receiver multicast sites. In the last case the source multicast site can do replication rather than having a single exit from the site. But this only can occur when the priorities in the Map-Reply are modified for different receiver multicast site so that the PIM Join/Prune messages arrive at different ITRs. This policy technique, also used in [ALT] for unicast, is useful for multicast to mitigate the problems of changing distribution tree state as discussed in Section 6. Farinacci, et al. Expires October 14, 2010 [Page 18] =0C Internet-Draft LISP for Multicast Environments April 2010 9. LISP-Multicast Interworking This section will describe the multicast corollary to [INTWORK] which describes the interworking of multicast routing among LISP and non- LISP sites. 9.1. LISP and non-LISP Mixed Sites Since multicast communication can involve more than two entities to communicate together, the combinations of interworking scenarios are more involved. However, the state maintained for distribution trees at the sites is the same regardless of whether or not the site is LISP enabled or not. So most of the implications are in the core with respect to storing routable EID prefixes from either PA or PI blocks. Before we enumerate the multicast interworking scenarios, we must define 3 deployment states of a site: o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it does today. The addresses for the site are globally routable. o A site that deploys LISP for unicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a uLISP site. o A site that deploys LISP for both unicast and multicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a LISP-Multicast site. We will not consider a LISP site enabled for multicast purposes only but do consider a uLISP site as documented in [INTWORK]. In this section we don't discuss how a LISP site sends multicast packets when all receiver sites are LISP-Multicast enabled; that has been discussed in previous sections. The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites: 1. A LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 2. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 3. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. Farinacci, et al. Expires October 14, 2010 [Page 19] =0C Internet-Draft LISP for Multicast Environments April 2010 4. A uLISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 5. A LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 9.1.1. LISP Source Site to non-LISP Receiver Sites In the first scenario, a site is LISP capable for both unicast and multicast traffic and as such operates on EIDs. Therefore there is a possibility that the EID prefix block is not routable in the core. For LISP receiver multicast sites this isn't a problem but for non- LISP or uLISP receiver multicast sites, when a PIM Join/Prune message is received by the edge router, it has no route to propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP-NAT in [INTWORK] solves. LISP-NAT allows a unicast packet that exits a LISP site to get its source address mapped to a globally routable address before the ITR realizes that it should not encapsulate the packet destined to a non- LISP site. For a multicast packet to leave a LISP site, distribution tree state needs to be built so the ITR can know where to send the packet. So the receiver multicast sites need to know about the multicast source host by its routable address and not its EID address. When this is the case, the routable address is the (S-RLOC,G) state that is stored and maintained in the core routers. It is important to note that the routable address for the host cannot be the same as an RLOC for the site. Because we want the ITRs to process a received PIM Join/Prune message from an external-facing interface to be propagated inside of the site so the site-part of the distribution tree is built. Using a globally routable source address allows non-LISP and uLISP multicast receiver to join, create, and maintain a multicast distribution tree. However, the LISP multicast receiver site will want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ Prune message is received on a site-facing interface. It does this because it wants to find a (S-RLOC,G) entry to Join in the core. So we have a conflict of behavior between the two types of sites. The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the Farinacci, et al. Expires October 14, 2010 [Page 20] =0C Internet-Draft LISP for Multicast Environments April 2010 mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. Now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, the way packet forwarding model is performed can be explained. Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) that its site's EIDs are not routable, it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a router and forwards the multicast packet like an ordinary multicast router. There is an alternative to using a LISP-NAT scheme just like there is for unicast [INTWORK] forwarding by using Proxy Tunnel Routers (PxTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) which make their way in the core to multicast PxTRs. Let's call this use of a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree needs to be built on the path from the mPETR to the LISP source multicast site. To make this happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a "Proxy ITR", or an uPITR). The existence of mPETRs in the core allows source multicast site ITRs to encapsulate multicast packets according to (S-RLOC,G) state. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The encapsulated multicast packets are decapsulated by mPETRs and then forwarded according to (S-EID,G) state. The (S-EID,G) state is built from the non-LISP and uLISP receiver multicast sites to the mPETRs. 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites Clearly non-LISP multicast sites can send multicast packets to non- LISP receiver multicast sites. That is what they do today. However, Farinacci, et al. Expires October 14, 2010 [Page 21] =0C Internet-Draft LISP for Multicast Environments April 2010 discussion is required to show how non-LISP multicast sites send multicast packets to uLISP receiver multicast sites. Since uLISP receiver multicast sites are not targets of any (S,G) state, they simply send (S,G) PIM Join/Prune messages toward the non- LISP source multicast site. Since the source multicast site, in this case has not been upgraded to LISP, all multicast source host addresses are routable. So this case is simplified to where a uLISP receiver multicast site looks to the source multicast site as a non- LISP receiver multicast site. 9.1.3. Non-LISP Source Site to Any Receiver Site When a non-LISP source multicast site has receivers in either a non- LISP/uLISP site or a LISP site, one needs to decide how the LISP receiver multicast site will attach to the distribution tree. We know from Section 9.1.2 that non-LISP and uLISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast site ETR will need to know if the source address of the multicast source host is routable or not. We showed in Section 9.1.1 that an ETR, before it sends a PIM Join/Prune message on an external-facing interface, does a EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to a (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site so it simply forwards the Join/Prune message (it also doesn't need to send a unicast encapsulated Join/Prune message because there is no ITR in a non-LISP site and there is namespace continuity between the ETR and source). For a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network with the use of multicast proxy- ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast packets from non-LISP source multicast and uLISP sites and encapsulate them to ETRs in receiver multicast sites or to mPETRs that can decapsulate for non-LISP receiver multicast or uLISP sites. The mPITRs are responsible for sending (S-EID,G) joins to the non- LISP source multicast site. To connect the distribution trees together, multicast ETRs will need to be configured with the mPITR's RLOC addresses so they can send both (S-RLOC,G) joins to build a distribution tree to the mPITR as well as for sending unicast oins to mPITRs so they can propogate (S-EID,G) joins into source multicast sites. The use of mPITRs is undergoing more study and is work in progress. Farinacci, et al. Expires October 14, 2010 [Page 22] =0C Internet-Draft LISP for Multicast Environments April 2010 9.1.4. Unicast LISP Source Site to Any Receiver Sites In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP- enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled but the ITR, by definition is not capable of doing multicast encapsulation. So for the purposes of multicast routing, the uLISP source multicast site is treated as non-LISP source multicast site. Non-LISP receiver multicast sites can join distribution trees to a uLISP source multicast site since the source site behaves, from a forwarding perspective, as a non-LISP source site. This is also the case for a uLISP receiver multicast site since the ETR does not have multicast functionality built-in or enabled. Special considerations are required for LISP receiver multicast sites since they think the source multicast site is LISP capable, the ETR cannot know if ITR is LISP-Multicast capable. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC. When the Mpriority is set to 255, the site is considered not multicast capable. So an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is LISP-Multicast site from a uLISP site. 9.1.5. LISP Source Site to Any Receiver Sites When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site then it could receive packets like a non-LISP receiver multicast site making all receiver multicast sites have homogeneous behavior. However, this poses the following issues: o LISP-NAT techniques with routable addresses would be required in all cases. o Or alternatively, mPETR deployment would be required forcing coarse EID prefix advertisement in the core. o But what is most disturbing is that when all sites that participate are LISP-Multicast sites but then a non-LISP or uLISP site joins the distribution tree, then the existing joined LISP receiver multicast sites would have to change their behavior. This would create too much dynamic tree-building churn to be a Farinacci, et al. Expires October 14, 2010 [Page 23] =0C Internet-Draft LISP for Multicast Environments April 2010 viable alternative. So the solution space options are: 1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to reach LISP-Multicast sites and to reach mPETRs that can decapsulate and forward (S-EID,G) packets to non-LISP and uLISP receiver multicast sites. 9.2. LISP Sites with Mixed Address Families A LISP database mapping entry that describes the locator-set, Mpriority and Mweight per locator address (RLOC), for an EID prefix associated with a site could have RLOC addresses in either IPv4 or IPv6 format. When a mapping entry has a mix of RLOC formatted addresses, it is an implicit advertisement by the site that it is a dual-stack site. That is, the site can receive IPv4 or IPv6 unicast packets. To distinguish if the site can receive dual-stack unicast packets as well as dual-stack multicast packets, the Mpriority value setting will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format details. If you consider the combinations of LISP, non-LISP, and uLISP sites sharing the same distribution tree and considering the capabilities of supporting IPv4, IPv6, or dual-stack, the number of total combinations grows beyond comprehension. Using some combinatorial math, we have the following profiles of a site and the combinations that can occur: 1. LISP-Multicast IPv4 Site 2. LISP-Multicast IPv6 Site 3. LISP-Multicast Dual-Stack Site 4. uLISP IPv4 Site 5. uLISP IPv6 Site Farinacci, et al. Expires October 14, 2010 [Page 24] =0C Internet-Draft LISP for Multicast Environments April 2010 6. uLISP Dual-Stack Site 7. non-LISP IPv4 Site 8. non-LISP IPv6 Site 9. non-LISP Dual-Stack Site Lets define (m n) =3D m!/(n!*(m-n)!), pronounced "m choose n" to illustrate some combinatorial math below. When 1 site talks to another site, the combinatorial is (9 2), when 1 site talks to another 2 sites, the combinatorial is (9 3). If sum this up to (9 9), we have: (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =3D 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 Which results in the total number of cases to be considered at 502. This combinatorial gets even worse when you consider a site using one address family inside of the site and the xTRs use the other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 RLOCs). To rationalize this combinatorial nightmare, there are some guidelines which need to be put in place: o Each distribution tree shared between sites will either be an IPv4 distribution tree or an IPv6 distribution tree. Therefore, we can avoid head-end replication by building and sending packets on each address family based distribution tree. Even though there might be an urge to do multicast packet translation from one address family format to the other, it is a non-viable over-complicated urge. Multicast ITRs will only encapsulate packets where the inner and outer headers are from the same address family. o All LISP sites on a multicast distribution tree must share a common address family which is determined by the source site's locator-set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP capable. This means that priority- based policy modification is prohibited. When a receiver multicast site ETR receives a (S-EID,G) join, it must select a S-RLOC for the same address family as S-EID. Farinacci, et al. Expires October 14, 2010 [Page 25] =0C Internet-Draft LISP for Multicast Environments April 2010 o A mixed multicast locator-set with the best multicast priority values MUST not be configured on multicast ITRs. A mixed locator- set can exist (for unicast use), but the multicast priorities MUST be the set for the same address family locators. o When the source site is not LISP capable, it is up to how receivers find the source and group information for a multicast flow. That mechanism decides the address family for the flow. 9.3. Making a Multicast Interworking Decision This Multicast Interworking section has shown all combinations of multicast connectivity that could occur. As you might have already concluded, this can be quite complicated and if the design is too ambitious, the dynamics of the protocol could cause a lot of instability. The trade-off decisions are hard to make and we want the same single solution to work for both IPv4 and IPv6 multicast. It is imperative to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state. Therefore the design decision to go with uPITRs for unicast routing and mPETRs for multicast routing seems to be the sweet spot in the solution space so we can optimize state requirements and avoid head- end data replication at ITRs. Farinacci, et al. Expires October 14, 2010 [Page 26] =0C Internet-Draft LISP for Multicast Environments April 2010 10. Considerations when RP Addresses are Embedded in Group Addresses When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in a IPv6 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message which contain an embedded-RP group address, they extract the RP address from the group address and treat it from the EID namespace. However, core routers do not have state for the EID namespace, need to extract an RP address from the RLOC namespace. Therefore, it is the responsibility of ETRs in multicast receiver sites to map the group address into a group address where the embedded-RP address is from the RLOC namespace. The mapped RP- address is obtained from a EID-to-RLOC mapping database lookup. The ETR will also send a unicast (*,G) Join/Prune message to the ITR so the branch of the distribution tree from the source site resident RP to the ITR is created. This technique is no different than the techniques described in this specification for translating (S,G) state and propagating Join/Prune messages into the core. The only difference is that the (*,G) state in Join/Prune messages are mapped because they contain unicast addresses encoded in an Embedded-RP group address. Farinacci, et al. Expires October 14, 2010 [Page 27] =0C Internet-Draft LISP for Multicast Environments April 2010 11. Taking Advantage of Upgrades in the Core If the core routers are upgraded to support [RPFV] and [RFC5496], then we can pass EID specific data through the core without, possibly, having to store the state in the core. By doing this we can eliminate the ETR from unicast encapsulating PIM Join/Prune messages to the source site's ITR. However, this solution is restricted to a small set of workable cases which would not be good for general use of LISP-Multicast. In addition to slow convergence properties, it is not being recommended for LISP-Multicast. Farinacci, et al. Expires October 14, 2010 [Page 28] =0C Internet-Draft LISP for Multicast Environments April 2010 12. Mtrace Considerations Mtrace functionality must be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible. The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon the mtrace version 2 specified in [MTRACE]. Farinacci, et al. Expires October 14, 2010 [Page 29] =0C Internet-Draft LISP for Multicast Environments April 2010 13. Security Considerations Refer to the [LISP] specification. Farinacci, et al. Expires October 14, 2010 [Page 30] =0C Internet-Draft LISP for Multicast Environments April 2010 14. Acknowledgments The authors would like to gratefully acknowledge the people who have contributed discussion, ideas, and commentary to the making of this proposal and specification. People who provided expert review were Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from discussions at Summer 2008 Dublin IETF were Toerless Eckert and Ijsbrand Wijnands. We would also like to thank the MBONED working group for constructive and civil verbal feedback when this draft was presented at the Fall 2008 IETF in Minneapolis. In particular, good commentary came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Ron Bonica, and Lenny Guardino. An expert review of this specification was done by Yiqun Cai and Liming Wei. We thank them for their detailed comments. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [MLISP] was converted into this IETF LISP working group draft. Farinacci, et al. Expires October 14, 2010 [Page 31] =0C Internet-Draft LISP for Multicast Environments April 2010 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 15.2. Informative References [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-04.txt (work in progress), April 2010. [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt (work in progress), March 2010. [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, et al. Expires October 14, 2010 [Page 32] =0C Internet-Draft LISP for Multicast Environments April 2010 "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-07.txt (work in progress), April 2010. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress), November 2008. [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a Network Address (and port) Translator (NAT)", draft-ietf-behave-multicast-07.txt (work in progress), June 2007. [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-03.txt (work in progress), March 2009. [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), February 2008. Farinacci, et al. Expires October 14, 2010 [Page 33] =0C Internet-Draft LISP for Multicast Environments April 2010 Appendix A. Document Change Log A.1. Changes to draft-ietf-lisp-multicast-03.txt o Posted April 2010. o Added section 8.1.2 to address Joel Halpern's comment about receiver sites joining the same source site via 2 different RLOCs, each being a separate ITR. o Change all occurences of "mPTR" to "mPETR" to become more consistent with uPITRs and uPETRs described in [INTWORK]. That is, an mPETR is a LISP multicast router that decapsulates multicast packets that are encapsulated to it by ITRs in multicast source sites. o Add clarifications in section 9 about how homogeneous multicast encapsulation should occur. As well as describing in this section, how to deal with mixed-locator sets to avoid heterogeneous encapsulation. o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges of LISP global multicast network. A.2. Changes to draft-ietf-lisp-multicast-02.txt o Posted September 2009. o Added Document Change Log appendix. o Specify that the LISP Encapsulated Control Message be used for unicasting PIM Join/Prune messages from ETRs to ITRs. A.3. Changes to draft-ietf-lisp-multicast-01.txt o Posted November 2008. o Specified that PIM Join/Prune unicast messages that get sent from ETRs to ITRs of a source multicast site get LISP encapsulated in destination UDP port 4342. o Add multiple RLOCs per ITR per Yiqun's comments. o Indicate how static RPs can be used when LISP is run using Bidir- PIM in the core. o Editorial changes per Liming comments. Farinacci, et al. Expires October 14, 2010 [Page 34] =0C Internet-Draft LISP for Multicast Environments April 2010 o Add Mttrace Considersations section. A.4. Changes to draft-ietf-lisp-multicast-00.txt o Posted April 2008. o Renamed from draft-farinacci-lisp-multicast-01.txt. Farinacci, et al. Expires October 14, 2010 [Page 35] =0C Internet-Draft LISP for Multicast Environments April 2010 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA USA Email: dino@cisco.com Dave Meyer cisco Systems Tasman Drive San Jose, CA USA Email: dmm@cisco.com John Zwiebel cisco Systems Tasman Drive San Jose, CA USA Email: jzwiebel@cisco.com Stig Venaas cisco Systems Tasman Drive San Jose, CA USA Email: stig@cisco.com Farinacci, et al. Expires October 14, 2010 [Page 36] =0C --Apple-Mail-12-1012096568 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > > > > --Apple-Mail-12-1012096568-- From darlewis@cisco.com Thu Apr 15 23:29:40 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E3428C113 for ; Thu, 15 Apr 2010 23:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqO-m9ACmxMB for ; Thu, 15 Apr 2010 23:29:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A18DE3A67E5 for ; Thu, 15 Apr 2010 23:29:39 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: rfcdiff-lisp-06-to-07.html, draft-ietf-lisp-07.txt : 197517, 182713 X-IronPort-AV: E=Sophos;i="4.52,218,1270425600"; d="txt'?html'217?scan'217,208,217";a="317721232" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 16 Apr 2010 06:29:32 +0000 Received: from sjc-vpn4-1058.cisco.com (sjc-vpn4-1058.cisco.com [10.21.84.33]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3G6TVP5023449; Fri, 16 Apr 2010 06:29:31 GMT From: Darrel Lewis Content-Type: multipart/mixed; boundary=Apple-Mail-10-1034602901 Date: Thu, 15 Apr 2010 23:32:58 -0700 Message-Id: <6F1FB986-E13A-4B2C-AE6A-66B3F0F7F5CE@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [lisp] Update to the proposed changes to -07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 06:29:40 -0000 --Apple-Mail-10-1034602901 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, We've received some (mostly editorial) comments on the proposed changes = to draft-ietf-lisp-07. I've attached an updated diff and text with the = changes so people planning to review the document over the next week = have the most recent version to work with. To review, the three main substantive changes are: (1) Changing the data-header format to add V-bit for Versioning and = I-bit for Instance IDs. (2) Adding a list ITR-RLOCs in the Map-Request to deal with = heterogeneous address-families in different sites. (3) Using Map-Versioning (and not Version-Hashing) as the mapping update = solution. Below is a up to date change log for -07, including the comments = received since the original email to the list on april 13th (they are = the last three change log items). Changes to draft-ietf-lisp-07.txt: o Posted April 2010. o Added I-bit to data header so LSB field can also be used as an Instance ID field. When this occurs, the LSB field is reduced to 8-bits (from 32-bits). o Added V-bit to the data header so the 24-bit nonce field can also be used for source and destination version numbers. o Added Map-Version 12-bit value to the EID-record to be used in all of Map-Request, Map-Reply, and Map-Register messages. o Added multiple ITR-RLOC fields to the Map-Request packet so an ETR can decide what address to select for the destination of a Map- Reply. o Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to the Locator-Set record of an EID-record for a Map-Reply message. The L-bit indicates which RLOCs in the locator-set are local to the sender of the message. The P-bit indicates which RLOC is the source of a RLOC-probe Reply (Map-Reply) message. o Add reference to the LISP Canonical Address Format [LCAF] draft. o Made editorial and clarification changes based on comments from Dhirendra Trivedi. o Added wordsmithing comments from Joel Halpern on DF=3D1 setting. o Add John Zwiebel clarification to Echo Nonce Algorithm section 6.3.1. o Add John Zwiebel comment about expanding on proxy-map-reply bit for Map-Register messages. o Add NAT section per Ron Bonica comments. o Fix IDnits issues per Ron Bonica. o Added section on Virtualization and Segmentation to explain the use if the Instance ID field in the data header. o There are too many P-bits, keep their scope to the packet format description and refer to them by name every where else in the spec. o Scanned all occurrences of "should", "should not", "must" and "must not" and uppercased them. o John Zwiebel offered text for section 4.1 to modernize the example. Thanks Z! New diff file and draft are enclosed. --Apple-Mail-10-1034602901 Content-Disposition: attachment; filename=rfcdiff-lisp-06-to-07.html Content-Type: text/html; name="rfcdiff-lisp-06-to-07.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-06.txt draft-ietf-lisp-07.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: July 24, October 17, 2010                                       D. Lewis
                                                           cisco Systems
                                                        January 20,
                                                          April 15, 2010

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-06.txt
                           draft-ietf-lisp-07

Abstract

   This draft describes a simple, incremental, network-based protocol to
   implement separation of Internet addresses into Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  This mechanism requires no
   changes to host stacks and no major changes to existing database
   infrastructures.  The proposed protocol can be implemented in a
   relatively small number of routers.

   This proposal was stimulated by the problem statement effort at the
   Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
   place in October 2006.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 24, October 17, 2010.

Copyright Notice
   Copyright (c) 2010 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 BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  Tunneling Details  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 18
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 21 22
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 22
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 22 23
     5.5.  Using Virtualization and Segmentation with LISP  . . . . . 24
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 24 25
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 24 25
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 26 27
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 26 27
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 28 29
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 30 31
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 33 34
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 35 37
       6.1.7.  Encapsualted  Encapsulated Control Message Format  . . . . . . . . . 37 38
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 39 40
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 40 41
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 43 44
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 44 45
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 45 46
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 46 47
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 46 47
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 47 48
       6.5.3.  Database Map Versioning  . . . . . . . . . . . . . . . 49
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 49 51
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 50 52
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 51 53
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 51 53
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 52 54
     8.4.  LISP Functionality with Conventional NATs  . . . . . . . . 54
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 53 55
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 54 56
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 54 56
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 54 56
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 56 58
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 56 58
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 56 58
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 56 58
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 58 60
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 58 60
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 60 62
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 61 63
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 64
   14. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 62
   14. 65
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
     14.1. 68
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 65
     14.2. 68
     15.2. Informative References . . . . . . . . . . . . . . . . . . 66 69
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 69 73
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 70 74
     B.1.  Changes to draft-ietf-lisp-06.txt draft-ietf-lisp-07.txt  . . . . . . . . . . . . 70 74
     B.2.  Changes to draft-ietf-lisp-05.txt draft-ietf-lisp-06.txt  . . . . . . . . . . . . 71 75
     B.3.  Changes to draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt  . . . . . . . . . . . . 71 76
     B.4.  Changes to draft-ietf-lisp-03.txt draft-ietf-lisp-04.txt  . . . . . . . . . . . . 73 77
     B.5.  Changes to draft-ietf-lisp-02.txt draft-ietf-lisp-03.txt  . . . . . . . . . . . . 74 78
     B.6.  Changes to draft-ietf-lisp-01.txt draft-ietf-lisp-02.txt  . . . . . . . . . . . . 74 79
     B.7.  Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 79
     B.8.  Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 74 79
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 80

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Many years of discussion about the current IP routing and addressing
   architecture have noted that its use of a single numbering space (the
   "IP address") for both host transport session identification and
   network routing creates scaling issues (see [CHIAPPA] and [RFC1498]).
   A number of scaling benefits would be realized by separating the
   current IP address into separate spaces for Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs); among them are:

   1.  Reduction of routing table size in the "default-free zone" (DFZ).
       Use of a separate numbering space for RLOCs will allow them to be
       assigned topologically (in today's Internet, RLOCs would be
       assigned by providers at client network attachment points),
       greatly improving aggregation and reducing the number of
       globally-visible, routable prefixes.

   2.  More cost-effective multihoming for sites that connect to
       different service providers where they can control their own
       policies for packet flow into the site without using extra
       routing table resources of core routers.

   3.  Easing of renumbering burden when clients change providers.
       Because host EIDs are numbered from a separate, non-provider-
       assigned and non-topologically-bound space, they do not need to
       be renumbered when a client site changes its attachment points to
       the network.

   4.  Traffic engineering capabilities that can be performed by network
       elements and do not depend on injecting additional state into the
       routing system.  This will fall out of the mechanism that is used
       to implement the EID/RLOC split (see Section 4).

   5.  Mobility without address changing.  Existing mobility mechanisms
       will be able to work in a locator/ID separation scenario.  It
       will be possible for a host (or a collection of hosts) to move to
       a different point in the network topology either retaining its
       home-based address or acquiring a new address based on the new
       network location.  A new network location could be a physically
       different point in the network topology or the same physical
       point of the topology with a different provider.

   This draft describes protocol mechanisms to achieve the desired
   functional separation.  For flexibility, the mechanism used for
   forwarding packets is decoupled from that used to determine EID to
   RLOC mappings.  This document covers the former.  For the later, latter, see
   [CONS], [ALT], [EMACS], [RPMD], and [NERD].  This work is in response
   to and intended to address the problem statement that came out of the
   RAWS effort [RFC4984].

   The Routing and Addressing problem statement can be found in [RADIR].

   This draft focuses on a router-based solution.  Building the solution
   into the network will facilitate incremental deployment of the
   technology on the Internet.  Note that while the detailed protocol
   specification and examples in this document assume IP version 4
   (IPv4), there is nothing in the design that precludes use of the same
   techniques and mechanisms for IPv6.  It should be possible for IPv4
   packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4
   RLOCs.

   Related work on host-based solutions is described in Shim6 [SHIM6] [RFC5533]
   and HIP [RFC4423].  Related work on a router-based solution is
   described in [GSE].  This draft attempts to not compete or overlap
   with such solutions and the proposed protocol changes are expected to
   complement a host-based mechanism when Traffic Engineering
   functionality is desired.

   Some of the design goals of this proposal include:

   1.  Require no hardware or software changes to end-systems (hosts).

   2.  Minimize required changes to Internet infrastructure.

   3.  Be incrementally deployable.

   4.  Require no router hardware changes.

   5.  Minimize the number of routers which have to be modified.  In
       particular, most customer site routers and no core routers
       require changes.

   6.  Minimize router software changes in those routers which are
       affected.

   7.  Avoid or minimize packet loss when EID-to-RLOC mappings need to
       be performed.

   There are 4 variants of LISP, which differ along a spectrum of strong
   to weak dependence on the topological nature and possible need for
   routability of EIDs.  The variants are:

   LISP 1:  uses EIDs that are routable through the RLOC topology for
      bootstrapping EID-to-RLOC mappings.  [LISP1] This was intended as
      a prototyping mechanism for early protocol implementation.  It is
      now deprecated and should not SHOULD NOT be deployed.

   LISP 1.5:  uses EIDs that are routable for bootstrapping EID-to-RLOC
      mappings; such routing is via a separate topology.

   LISP 2:  uses EIDS that are not routable and EID-to-RLOC mappings are
      implemented within the DNS.  [LISP2]

   LISP 3:  uses non-routable EIDs that are used as lookup keys for a
      new EID-to-RLOC mapping database.  Use of Distributed Hash Tables
      [DHTs] [LISPDHT] to implement such a database would be an area to
      explore.  Other examples of new mapping database services are
      [CONS], [ALT], [RPMD], [NERD], and [APT].

   This document on LISP 1.5, and LISP 3 variants, both of which rely on
   a router-based distributed cache and database for EID-to-RLOC
   mappings.  The LISP 1.0 mechanism works but does not allow reduction
   of routing information in the default-free-zone of the Internet.  The
   LISP 2 mechanisms are put on hold and may never come to fruition
   since it is not architecturally pure to have routing depend on
   directory and directory depend on routing.  The LISP 3 mechanisms
   will be documented elsewhere but may use the control-plane options
   specified in this specification.

3.  Definition of Terms

   Provider Independent (PI) Addresses:   an address block assigned from
      a pool where blocks are not associated with any particular
      location in the network (e.g. from a particular service provider),
      and is therefore not topologically aggregatable in the routing
      system.

   Provider Assigned (PA) Addresses:   a block of IP addresses that are
      assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider CIDR block and is aggregated into the larger block before
      being advertised into the global Internet.  Traditionally, IP
      multihoming has been implemented by each multi-homed site
      acquiring its own, globally-visible prefix.  LISP uses only
      topologically-assigned and aggregatable address blocks for RLOCs,
      eliminating this demonstrably non-scalable practice.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
      tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
      lookup.  An EID maps to one or more RLOCs.  Typically, RLOCs are
      numbered from topologically-aggregatable blocks that are assigned
      to a site at each point to which it attaches to the global
      Internet; where the topology is defined by the connectivity of
      provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains an destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.  When used in
      discussions with other Locator/ID separation proposals, a LISP EID
      will be called a "LEID".  Throughout this document, any references
      to "EID" refers to an LEID.

   EID-prefix:   A power-of-2 block of EIDs which are allocated to a
      site by an address allocation authority.  EID-prefixes are
      associated with a set of RLOC addresses which make up a "database
      mapping".  EID-prefix allocations can be broken up into smaller
      blocks when an RLOC set is to be associated with the smaller EID-
      prefix.  A globally routed address block (whether PI or PA) is not
      an EID-prefix.  However, a globally routed address block may be
      removed from global routing and reused as an EID-prefix.  A site
      that receives an explicitly allocated EID-prefix may not use that
      EID-prefix as a globally routed prefix assigned to RLOCs.

   End-system:   is an IPv4 or IPv6 device that originates packets with
      a single IPv4 or IPv6 header.  The end-system supplies an EID
      value for the destination address field of the IP header when
      communicating globally (i.e. outside of its routing domain).  An
      end-system can be a host computer, a switch or router device, or
      any network appliance.

   Ingress Tunnel Router (ITR):   a router which accepts an IP packet
      with a single IP header (more precisely, an IP packet that does
      not contain a LISP header).  The router treats this "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally-routable RLOCs in the source address field and the
      result of the mapping lookup in the destination address field.
      Note that this destination RLOC may be an intermediate, proxy
      device that has better knowledge of the EID-to-RLOC mapping closer
      to the destination EID.  In general, an ITR receives IP packets
      from site end-systems on one side and sends LISP-encapsulated IP
      packets toward the Internet on the other side.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating hosts
      supplied EID).

   TE-ITR:   is an ITR that is deployed in a service provider network
      that prepends an additional LISP header for Traffic Engineering
      purposes.

   Egress Tunnel Router (ETR):   a router that accepts an IP packet
      where the destination address in the "outer" IP header is one of
      its own RLOCs.  The router strips the "outer" header and forwards
      the packet based on the next IP header found.  In general, an ETR
      receives LISP-encapsulated IP packets from the Internet on one
      side and sends decapsulated IP packets to site end-systems on the
      other side.  ETR functionality does not have to be limited to a
      router device.  A server host can be the endpoint of a LISP tunnel
      as well.

   TE-ETR:   is an ETR that is deployed in a service provider network
      that strips an outer LISP header for Traffic Engineering purposes.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality is at the CE
      router.

   EID-to-RLOC Cache:   a short-lived, on-demand table in an ITR that
      stores, tracks, and is responsible for timing-out and otherwise
      validating EID-to-RLOC mappings.  This cache is distinct from the
      full "database" of EID-to-RLOC mappings, it is dynamic, local to
      the ITR(s), and relatively small while the database is
      distributed, relatively static, and much more global in scope.

   EID-to-RLOC Database:   a global distributed database that contains
      all known EID-prefix to RLOC mappings.  Each potential ETR
      typically contains a small piece of the database: the EID-to-RLOC
      mappings for the EID prefixes "behind" the router.  These map to
      one of the router's own, globally-visible, IP addresses.

   Recursive Tunneling:   when a packet has more than one LISP IP
      header.  Additional layers of tunneling may be employed to
      implement traffic engineering or other re-routing as needed.  When
      this is done, an additional "outer" LISP header is added and the
      original RLOCs are preserved in the "inner" header.  Any
      references to tunnels in this specification refers to dynamic
      encapsulating tunnels and never are they statically configured.

   Reencapsulating Tunnels:   when a packet has no more than one LISP IP
      header (two IP headers total) and when it needs to be diverted to
      new RLOC, an ETR can decapsulate the packet (remove the LISP
      header) and prepends a new tunnel header, with new RLOC, on to the
      packet.  Doing this allows a packet to be re-routed by the re-
      encapsulating router without adding the overhead of additional
      tunnel headers.  Any references to tunnels in this specification
      refers to dynamic encapsulating tunnels and never are they
      statically configured.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
      header that follows the UDP header, an ITR prepends or an ETR
      strips.

   Address Family Indicator Identifier (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI] and [RFC1700] for details.  An
      AFI value of 0 used in this specification indicates an unspecified
      encoded address where the the length of the address is 0 bytes
      following the 16-bit AFI value of 0.  Also, refer to [LCAF] for
      LISP specific AFI encodings.

   Negative Mapping Entry:   also known as a negative cache entry, is an
      EID-to-RLOC entry where an EID-prefix is advertised or stored with
      no RLOCs.  That is, the locator-set for the EID-to-RLOC entry is
      empty or has an encoded locator count of 0.  This type of entry
      could be used to describe a prefix from a non-LISP site, which is
      explicitly not in the mapping database.  There are a set of well
      defined actions that are encoded in a Negative Map-Reply.

   Data Probe:   a LISP-encapsulated data packet where the inner header
      destination address equals the outer header destination address
      used to trigger a Map-Reply by a decapsulating ETR.  In addition,
      the original packet is decapsulated and delivered to the
      destination host.  A Data Probe is used in some of the mapping
      database designs to "probe" or request a Map-Reply from an ETR; in
      other cases, Map-Requests are used.  See each mapping database
      design for details.

   Proxy ITR (PITR):   also known as a PTR is defined and described in
      [INTERWORK], a PITR acts like an ITR but does so on behalf of non-
      LISP sites which send packets to destinations at LISP sites.

   Proxy ETR (PETR):   is defined and described in [INTERWORK], a PETR
      acts like an ETR but does so on behalf of LISP sites which send
      packets to destinations at non-LISP sites.

4.  Basic Overview

   One key concept of LISP is that end-systems (hosts) operate the same
   way they do today.  The IP addresses that hosts use for tracking
   sockets, connections, and for sending and receiving packets do not
   change.  In LISP terminology, these IP addresses are called Endpoint
   Identifiers (EIDs).

   Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC.

   This design introduces "Tunnel Routers", which prepends LISP headers
   on host-originated packets and strip them prior to final delivery to
   their destination.  The IP addresses in this "outer header" are
   RLOCs.  During end-to-end packet exchange between two Internet hosts,
   an ITR prepends a new LISP header to each packet and an egress tunnel
   router strips the new header.  The ITR performs EID-to-RLOC lookups
   to determine the routing path to the the ETR, which has the RLOC as
   one of its IP addresses.

   Some basic rules governing LISP are:

   o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.

   o  EIDs are always IP addresses assigned to hosts.

   o  LISP routers mostly deal with Routing Locator addresses.  See
      details later in Section 4.1 to clarify what is meant by "mostly".

   o  RLOCs are always IP addresses assigned to routers; preferably,
      topologically-oriented addresses from provider CIDR blocks.

   o  When a router originates packets it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g. when
      terminating a transport session such as SSH, TELNET, or SNMP), it
      may use an EID that is explicitly assigned for that purpose.  An
      EID that identifies the router as a host MUST NOT be used as an
      RLOC; an EID is only routable within the scope of a site.  A
      typical BGP configuration might demonstrate this "hybrid" EID/RLOC
      usage where a router could use its "host-like" EID to terminate
      iBGP sessions to other routers in a site while at the same time
      using RLOCs to terminate eBGP sessions to routers outside the
      site.

   o  EIDs are not expected to be usable for global end-to-end
      communication in the absence of an EID-to-RLOC mapping operation.
      They are expected to be used locally for intra-site communication.

   o  EID prefixes are likely to be hierarchically assigned in a manner
      which is optimized for administrative convenience and to
      facilitate scaling of the EID-to-RLOC mapping database.  The
      hierarchy is based on a address allocation hierarchy which is not
      dependent on the network topology.

   o  EIDs may also be structured (subnetted) in a manner suitable for
      local routing within an autonomous system.

   An additional LISP header may be prepended to packets by a transit
   router (i.e.  TE-ITR) when re-routing of the path for a packet is
   desired.  An obvious instance of this would be an ISP router that
   needs to perform traffic engineering for packets in flow flowing through its
   network.  In such a situation, termed Recursive Tunneling, an ISP
   transit acts as an additional ingress tunnel router and the RLOC it
   uses for the new prepended header would be either a TE-ETR within the
   ISP (along intra-ISP traffic engineered path) or a TE-ETR within
   another ISP (an inter-ISP traffic engineered path, where an agreement
   to build such a path exists).

   This specification mandates that no more than two LISP headers get
   prepended to a packet.  This avoids excessive packet overhead as well
   as possible encapsulation loops.  It is believed two headers is
   sufficient, where the first prepended header is used at a site for
   Location/Identity separation and second prepended header is used
   inside a service provider for Traffic Engineering purposes.

   Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
   For example, the ITR for a particular end-to-end packet exchange
   might be the first-hop or default router within a site for the source
   host.  Similarly, the egress tunnel router might be the last-hop
   router directly-connected to the destination host.  Another example,
   perhaps for a VPN service out-sourced to an ISP by a site, the ITR
   could be the site's border router at the service provider attachment
   point.  Mixing and matching of site-operated, ISP-operated, and other
   tunnel routers is allowed for maximum flexibility.  See Section 8 for
   more details.

4.1.  Packet Flow Sequence

   This section provides an example of the unicast packet flow with the
   following conditions:

   o  Source host "host1.abc.com" is sending a packet to
      "host2.xyz.com", exactly what host1 would do if the site was not
      using LISP.

   o  Each site is multi-homed, so each tunnel router has an address
      (RLOC) assigned from the service provider address block for each
      provider to which that particular tunnel router is attached.

   o  The ITR(s) and ETR(s) are directly connected to the source and
      destination, respectively.

   o  Data Probes are used to solicit Map-Replies versus using Map-
      Requests.  And respectively, but the source and destination can be
      located anywhere in LISP site.

   o  Map-Requests or Data Probes are can be sent on the underlying routing
      system topology
      (the LISP 1.0 variant) but could also be sent (LISP 1.0) or over an alternative topology (the LISP 1.5 variant) as it would in (LISP
      1.5) [ALT].

   o  Map-Replies are sent on the underlying routing system topology.

   Client host1.abc.com wants to communicate with server host2.xyz.com:

   1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
       It does a DNS lookup on host2.xyz.com.  An A/AAAA record is
       returned.  This address is used as the destination EID and the
       locally-assigned EID.  The locally-
       assigned address of host1.abc.com is used as the source EID.  An
       IPv4 or IPv6 packet is built using the EIDs in the IPv4
       or IPv6 header and sent to forwarded through the default router.

   2.  The default router is configured LISP site
       as an a normal IP packet until it reaches a LISP ITR.

   2.  The LISP ITR must be able to map the EID destination to an RLOC
       of one of the ETR ETRs at the destination site.  The specific method
       used to do this is not described in this example.  See [ALT] or
       [CONS] for possible solutions.

   3.  The ITR prepends will either send a LISP header to the packet,
       with one of its RLOCs as the source IPv4 Data-Probe or IPv6 address.  The
       destination EID a LISP Map-Request.
       If the ITR sends a Data-Probe all data packets from the original packet header source
       are encapsulated until a Map-Reply is used as received.  If the
       destination IPv4 ITR sends
       a Map-Request, data packets are either queued or IPv6 in the prepended LISP header.
       Subsequent packets, where the outer destination address is the
       destination EID will be sent dropped until EID-to-RLOC mapping a
       Map-Reply is
       learned.

   3. received.  Map-Requests MAY be rate-limited.

   4.  In LISP 1, 1.0, the Data-Probe or Map-Request packet is routed
       through the Internet as it is
       today. underlying routing system.  In LISP 1.5, the Data-
       Probe or Map-Request packet is routed on a different topology
       which may have EID prefixes distributed and advertised in an
       aggregatable fashion. alternate logical
       topology.  In either case, when the packet Probe/Request arrives at one
       of the
       ETR.  The router is configured to "punt" the packet to the
       router's processor.  See Section 7 for more details.  For LISP
       2.0 and 3.0, ETRs at the behavior is not fully defined yet.

   4.  The LISP header is stripped so that destination site, it will process the packet can be forwarded
       by the router
       as a control plane. message.

   5.  The router ETR looks up at the destination EID in of either the router's EID-to-RLOC database (not Data-Probe or
       Map-Request and matches it against the cache, but prefixes in the ETR's
       configured data structure of RLOCs).  An EID-to-RLOC Map-Reply
       message mapping database.  This is originated by the list of
       EID-prefixes the ETR and is addressed to supporting for the source
       RLOC in site it resides in.
       If there is no match, the packet is dropped.  Otherwise, if the
       packet is a Data-Probe the LISP header of is stripped and the original data
       packet (this is forwarded to the ITR).
       The source RLOC of destination host.  In either the Data-
       Probe or Map-Request case, a LISP Map-Reply is one of returned to the ETR's RLOCs.

   5.
       ITR.

   6.  The ITR receives the Map-Reply message, parses the message (to
       check for format validity) and stores the mapping information
       from the packet.  This information is put in the ITR's EID-to-
       RLOC mapping cache (this is the on-demand cache, the cache where
       entries time out due to inactivity).

   6.

   7.  Subsequent packets from host1.abc.com to host2.xyz.com will have
       a LISP header prepended by the ITR using the appropriate RLOC as
       the LISP header destination address learned from the ETR.  Note,
       the packet may be sent to a different ETR than the one which
       returned the Map-Reply due to the source site's hashing policy or
       the destination site's locator-set policy.

   7.

   8.  The ETR receives these packets directly (since the destination
       address is one of its assigned IP addresses), strips the LISP
       header and forwards the packets to the attached destination host.

   In order to eliminate the need for a mapping lookup in the reverse
   direction, an ETR MAY create a cache entry that maps the source EID
   (inner header source IP address) to the source RLOC (outer header
   source IP address) in a received LISP packet.  Such a cache entry is
   termed a "gleaned" mapping and only contains a single RLOC for the
   EID in question.  More complete information about additional RLOCs
   SHOULD be verified by sending a LISP Map-Request for that EID.  Both
   ITR and the ETR may also influence the decision the other makes in
   selecting an RLOC.  See Section 6 for more details.

5.  Tunneling Details

   This section describes the LISP Data Message which defines the
   tunneling header used to encapsulate IPv4 and IPv6 packets which
   contain EID addresses.  Even though the following formats illustrate
   IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2
   combinations are supported as well.

   Since additional tunnel headers are prepended, the packet becomes
   larger and in theory can exceed the MTU of any link traversed from
   the ITR to the ETR.  It is recommended, in IPv4 that packets do not
   get fragmented as they are encapsulated by the ITR.  Instead, the
   packet is dropped and an ICMP Too Big message is returned to the
   source.

   Based on informal surveys of large ISP traffic patterns, it appears
   that most transit paths can accommodate a path MTU of at least 4470
   bytes.  The exceptions, in terms of data rate, number of hosts
   affected, or any other metric are expected to be vanishingly small.

   To address MTU concerns, mainly raised on the RRG mailing list, the
   LISP deployment process will include collecting data during its pilot
   phase to either verify or refute the assumption about minimum
   available MTU.  If the assumption proves true and transit networks
   with links limited to 1500 byte MTUs are corner cases, it would seem
   more cost-effective to either upgrade or modify the equipment in
   those transit networks to support larger MTUs or to use existing
   mechanisms for accommodating packets that are too large.

   For this reason, there is currently no plan for LISP to add any new
   additional, complex mechanism for implementing fragmentation and
   reassembly in the face of limited-MTU transit links.  If analysis
   during LISP pilot deployment reveals that the assumption of
   essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect,
   then LISP can be modified prior to protocol standardization to add
   support for one of the proposed fragmentation and reassembly schemes.
   Note that two simple existing schemes are detailed in Section 5.4.

5.1.  LISP IPv4-in-IPv4 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|  rflags |                 Nonce   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       Locator                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  LISP IPv6-in-IPv6 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Payload Length        | Next Header=17|   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|  rflags |                 Nonce   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       Locator                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Tunnel Header Field Descriptions

   Inner Header:  is the inner header, preserved from the datagram
      received from the originating host.  The source and destination IP
      addresses are EIDs.

   Outer Header:  is the outer header prepended by an ITR.  The address
      fields contain RLOCs obtained from the ingress router's EID-to-
      RLOC cache.  The IP protocol number is "UDP (17)" from [RFC0768].
      The DF bit of the Flags field is set to 0 when the method in
      Section 5.4.1 is used and set to 1 when the method in
      Section 5.4.2 is used.

   UDP Header:  contains a ITR selected source port when encapsulating a
      packet.  See Section 6.4 for details on the hash algorithm used to
      select a source port based on the 5-tuple of the inner header.
      The destination port MUST be set to the well-known IANA assigned
      port value 4341.

   UDP Checksum:  this field SHOULD be transmitted as zero by an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is received by an ETR, the ETR
      MUST accept the packet for decapsulation.  When an ITR transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes will
      be made to align LISP with the outcome of the broader discussion.

   UDP Length:  for an IPv4 encapsulated packet, the inner header Total
      Length plus the UDP and LISP header lengths are used.  For an IPv6
      encapsulated packet, the inner header Payload Length plus the size
      of the IPv6 header (40 bytes) plus the size of the UDP and LISP
      headers are used.  The UDP header length is 8 bytes.

   N: this is the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.  Both N and V bits MUST
      NOT be set in the same packet.  If they are, a decapsulating ETR
      MUST treat the "Nonce/Map-Version" field as having a Nonce value
      present.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

     x 1 x x 0 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Locator Status Bits                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must MUST be 1.  This bit should SHOULD be ignored and has no
      meaning when the N bit is set to 0.  See section Section 6.3.1 for
      details.

   rflags:

   V: this is the Map-Version present bit.  When this bit is set to 1,
      the N bit MUST be 0.  Refer to Section 6.5.3 for more details.
      This bit indicates that the first 4 bytes of the LISP header is
      encoded as:

     0 x 0 1 x x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator Status Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I: this is the Instance ID bit.  See Section 5.5 for more details.
      When this bit is set to 1, the Locator Status Bits field is
      reduced to 8-bits and the high-order 24-bits are used as an
      Instance ID.  If the L-bit is set to 0, then the low-order 8 bits
      are transmitted as zero and ignored on receipt.  The format of the
      last 4 bytes of the LISP header would look like:

     x x x x 1 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID                   |     LSBs      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   flags:  this 5-bit 3-bit field is reserved for future flag use.  It is set
      to 0 on transmit and ignored on receipt.

   LISP Nonce:  is a 24-bit value that is randomly generated by an ITR
      when the N-bit is set to 1.  The nonce is also used when the E-bit
      is set to request the nonce value to be echoed by the other side
      when packets are returned.  When the E-bit is clear but the N-bit
      is set, a remote ITR is either echoing a previously requested
      echo-nonce or providing a random nonce.  See section Section 6.3.1 for
      more details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the least
      significant bit of the 32-bit field.  The field is 32-bits when the I-bit is
      set to 0 and is 8 bits when the I-bit is set to 1.  When a bit Locator
      Status Bit is set to 1, the ITR is indicating to the ETR the RLOC
      associated with the bit ordinal has up status.  See Section 6.3
      for details on how an ITR can determine the status of other ITRs
      at the site are reachable. same site.  When a site has multiple EID-prefixes which
      result in multiple mappings (where each could have a different
      locator-set), the Locator Status Bits setting in an encapsulated
      packet MUST reflect the mapping for the EID-prefix that the inner-header inner-
      header source EID address matches.

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

   o  The outer header Type of Service field (or the Traffic Class
      field, in the case of IPv6) SHOULD be copied from the inner header
      Type of Service field (with one caveat, see below).

   When doing Re-encapsulated Tunneling:

   o  The new outer header Time to Live field SHOULD be copied from the
      stripped outer header Time to Live field.

   o  The new outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below).

   Copying the TTL serves two purposes: first, it preserves the distance
   the host intended the packet to travel; second, and more importantly,
   it provides for suppression of looping packets in the event there is
   a loop of concatenated tunnels due to misconfiguration.

   The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
   field and the IPv6 Traffic Class field [RFC3168].  The ECN field
   requires special treatment in order to avoid discarding indications
   of congestion [RFC3168].  ITR encapsulation MUST copy the 2-bit ECN
   field from the inner header to the outer header.  Re-encapsulation
   MUST copy the 2-bit ECN field from the stripped outer header to the
   new outer header.  If the ECN field contains a congestion indication
   codepoint (the value is '11', the Congestion Experienced (CE)
   codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
   the stripped outer header to the surviving inner header that is used
   to forward the packet beyond the ETR.  These requirements preserve
   Congestion Experienced (CE) indications when a packet that uses ECN
   traverses a LISP tunnel and becomes marked with a CE indication due
   to congestion between the tunnel endpoints.

5.4.  Dealing with Large Encapsulated Packets

   In the event that the MTU issues mentioned above prove to be more
   serious than expected, this section proposes 2 simple mechanisms to
   deal with large packets.  One is stateless using IP fragmentation and
   the other is stateful using Path MTU Discovery [RFC1191].

   It is left to the implementor to decide if the stateless or stateful
   mechanism should SHOULD be implemented.  Both or neither can be decided as
   well since it is a local decision in the ITR regarding how to deal
   with MTU issues.  Sites can interoperate with differing mechanisms.

   Both stateless and stateful mechanisms also apply to Reencapsulating
   and Recursive Tunneling.  So any actions reference below referring to an ITR
   also apply to an TE-ITR.

5.4.1.  A Stateless Solution to MTU Handling

   An ITR stateless solution to handle MTU issues is described as
   follows:

   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would receive from a source inside of
       its site.

   2.  Define L to be the maximum size, in bytes, a packet of size S
       would be after the ITR prepends the LISP header, UDP header, and
       outer network layer header of size H.

   3.  Calculate: S + H = L.

   When an ITR receives a packet from a site-facing interface and adds H
   bytes worth of encapsulation to yield a packet size greater than L
   bytes, it resolves the MTU issue by first splitting the original
   packet into 2 equal-sized fragments.  A LISP header is then prepended
   to each fragment.  This will ensure that the new, encapsulated
   packets are of size (S/2 + H), which is always below the effective
   tunnel MTU.

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

   This behavior is performed by the ITR when the source host originates
   a packet with the DF field of the IP header is set to 0.  When the DF
   field of the IP header is set to 1, or the packet is an IPv6 packet
   originated by the source host, the ITR will drop the packet when the
   size is greater than L, and sends an ICMP Too Big message to the
   source with a value of S, where S is (L - H).

   When the outer header encapsulation uses an IPv4 header, an
   implementation should consider a default behavior of setting SHOULD set the DF bit to 1 so ETR fragment reassembly
   can be avoided.  An implementation MAY set the DF bit in such headers
   to 0 if it has good reason to believe there are unresolvable path MTU
   issues between the sending ITR and the receiving ETR.

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

   An ITR stateful solution to handle MTU issues is described as follows
   and was first introduced in [OPENLISP]:

   1.  The ITR will keep state of the effective MTU for each locator per
       mapping cache entry.  The effective MTU is what the core network
       can deliver along the path between ITR and ETR.

   2.  When an IPv6 encapsulated packet or an IPv4 encapsulated packet
       with DF bit set to 1, exceeds what the core network can deliver,
       one of the intermediate routers on the path will send an ICMP Too
       Big message to the ITR.  The ITR will parse the ICMP message to
       determine which locator is affected by the effective MTU change
       and then record the new effective MTU value in the mapping cache
       entry.

   3.  When a packet is received by the ITR from a source inside of the
       site and the size of the packet is greater than the effective MTU
       stored with the mapping cache entry associated with the
       destination EID the packet is for, the ITR will send an ICMP Too
       Big message back to the source.  The packet size advertised by
       the ITR in the ICMP Too Big message is the effective MTU minus
       the LISP encapsulation length.

   Even though this mechanism is stateful, it has advantages over the
   stateless IP fragmentation mechanism, by not involving the
   destination host with reassembly of ITR fragmented packets.

5.5.  Using Virtualization and Segmentation with LISP

   When multiple organizations inside of a LISP site are using private
   addresses [RFC1918] as EID-prefixes, their address spaces MUST remain
   segregated due to possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.  See [LCAF] for details on address encodings.

   An Instance ID can be carried in a LISP encapsulated packet.  An ITR
   that prepends a LISP header, will copy a 24-bit value, used by the
   LISP router to uniquely identify the address space.  The value is
   copied to the Instance ID field of the LISP header and the I-bit is
   set to 1.

   When an ETR decapsulate a packet, the Instance ID from the LISP
   header is used as a table identifier to locate the forwarding table
   to use for the inner destination EID lookup.

   Some examples of the 24-bit value to copy or map into the Instance ID
   field could be a 802.1Q VLAN tag or a configured VRF-ID value.

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

   The following new UDP packet types are used to retrieve EID-to-RLOC
   mappings:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|  IHL  |Type of Service|          Total Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identification        |Flags|      Fragment Offset    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time to Live | Protocol = 17 |         Header Checksum       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Source Routing Locator                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Traffic Class |           Flow Label                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        | Next Header=17|   Hop Limit   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                     Source Routing Locator                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                  Destination Routing Locator                  +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LISP UDP-based messages are the Map-Request and Map-Reply
   messages.  When a UDP Map-Request is sent, the UDP source port is
   chosen by the sender and the destination UDP port number is set to
   4342.  When a UDP Map-Reply is sent, the source UDP port number is
   set to 4342 and the destination UDP port number is copied from the
   source port of either the Map-Request or the invoking data packet.

   The UDP Length field will reflect the length of the UDP header and
   the LISP Message payload.

   The UDP Checksum is computed and set to non-zero for Map-Request,
   Map-Reply, Map-Register and ECM control messages.  It MUST be checked
   on receipt and if the checksum fails, the packet MUST be dropped.

   LISP-CONS [CONS] use TCP to send LISP control messages.  The format
   of control messages includes the UDP header so the checksum and
   length fields can be used to protect and delimit message boundaries.

   This main LISP specification is the authoritative source for message
   format definitions for the Map-Request and Map-Reply messages.

6.1.1.  LISP Packet Type Allocations

   This section will be the authoritative source for allocating LISP
   Type values.  Current allocations are:

       Reserved:                          0    b'0000'
       LISP Map-Request:                  1    b'0001'
       LISP Map-Reply:                    2    b'0010'
       LISP Map-Register:                 3    b'0011'
       LISP Encapsulated Control Message: 8    b'1000'

6.1.2.  Map-Request Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|       Reserved      |   IRC   | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |            ITR-AFI   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Source EID         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Originating ITR RLOC                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.

   M: When set, it indicates a Map-Reply Record segment is included in
      the Map-Request.

   P: Indicates Map-Request.

   P: This is the probe-bit which indicates that a Map-Request should SHOULD be
      treated as a "piggyback" locator reachability probe.  The receiver should SHOULD
      respond with a Map-Reply with the P bit set and probe-bit set, indicating the
      Map-Reply is a locator reachability probe reply, with the nonce
      copied from the Map-
      Request. Map-Request.  See section Section 6.3.2 for more details.

   S: This is the SMR bit.  See Section 6.5.2 for details.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   IRC:  This 5-bit field is the ITR-RLOC Count which encodes the number
      of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this
      message.  Multiple ITR-RLOC Address fields are used so a Map-
      Replier can select which destination address to use for a Map-
      Reply.  The IRC value ranges from 0 to 31, where IRC value 0 means
      an ITR-RLOC address count of 1, an IRC value of 1 means an ITR-
      RLOC address count of 2, and so on up to an IRC value of 31, which
      means an ITR-RLOC address count of 32.

   Record Count:  The number of records in this Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   Source-EID-AFI:  Address family of the "Source EID Address" field.

   ITR-AFI:  Address family of the "Originating ITR RLOC Address" field.

   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, the value 0 is used.

   Originating ITR RLOC

   ITR-RLOC-AFI:  Address family of the "ITR-RLOC Address" field that
      follows this field.

   ITR-RLOC Address:  Used to give the ETR the option of
      returning a Map-Reply in selecting the address-family of this locator.
      destination address from any address family for the Map-Reply
      message.  This address MUST be a routable RLOC address.

   EID mask-len:  Mask length for EID prefix.

   EID-AFI:

   EID-prefix-AFI:  Address family of EID-prefix according to [RFC2434] [RFC5226]

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.  When a Map-Request is sent by an ITR because a
      data packet is received for a destination where there is no
      mapping entry, the EID-prefix is set to the destination IP address
      of the data packet.  And the 'EID mask-len' is set to 32 or 128
      for IPv4 or IPv6, respectively.  When an xTR wants to query a site
      about the status of a mapping it already has cached, the EID-
      prefix used in the Map-Request has the same mask-length as the
      EID-prefix returned from the site when it sent a Map-Reply
      message.

   Map-Reply Record:  When the M bit is set, this field is the size of
      the "Record" field in the Map-Reply format.  This Map-Reply record
      contains the EID-to-RLOC mapping entry associated with the Source
      EID.  This allows the ETR which will receive this Map-Request to
      cache the data if it chooses to do so.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.3.  EID-to-RLOC UDP Map-Request Message

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the later latter 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.

   In all cases, the UDP source port number for the Map-Request message
   is a randomly allocated 16-bit value and the UDP destination port
   number is set to the well-known destination port number 4342.  A
   successful Map-Reply updates the cached set of RLOCs associated with
   the EID prefix range.

   One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
   be filled in by the ITR.  The number of fields (minus 1) encoded MUST
   be placed in the IRC field.  The ITR MAY include all locally
   configured locators in this list or just provide one locator address
   from each address family it supports.  If the ITR erroneously
   provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
   Request.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4342 with a LISP type value set to "Encapsulated Control Message",
   when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
   LISP encapsulated the same way from a Map-Server to an ETR.  Details
   on encapsulated Map-Requests and Map-Resolvers can be found in
   [LISP-MS].

   Map-Requests MUST be rate-limited.  It is recommended that a Map-
   Request for the same EID-prefix be sent no more than once per second.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request and it does
   not have this mapping in the map-cache, it may originate a "verifying
   Map-Request", addressed to the map-requesting ITR.  If the ETR has a
   map-cache entry that matches the "piggybacked" EID and the RLOC is in
   the locator-set for the entry, then it may send the "verifying Map-
   Request" directly to the originating Map-Request source.  If the RLOC
   is not in the locator-set, then the ETR MUST send the "verifying Map-
   Request" to the "piggybacked" EID.  Doing this forces the "verifying
   Map-Request" to go through the mapping database system to reach the
   authoritative source of information about that EID, guarding against
   RLOC-spoofing in in the "piggybacked" mapping data.

6.1.4.  Map-Reply Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=2 |P|E|            Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved Rsvd  |  Map-Version Number   |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags      |R|     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   2 (Map-Reply)

   P: Indicates This is the probe-bit which indicates that the Map-Reply is in
      response to a "piggyback" locator reachability probe Map-Request.  The nonce
      field should MUST contain a copy of the nonce value from the original
      Map-Request.  See
      section Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site is enabled for the Echo-Nonce locator
      reachability algorithm.  See Section 6.3.1 for more details.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   Record Count:  The number of records in this reply message.  A record
      is comprised of that portion of the packet labeled 'Record' above
      and occurs the number of times equal to Record count.

   Nonce:  A 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of the Map-
      Reply.

   Record TTL:  The time in minutes the recipient of the Map-Reply will
      store the mapping.  If the TTL is 0, the entry should SHOULD be removed
      from the cache immediately.  If the value is 0xffffffff, the
      recipient can decide locally how long to store the mapping.

   Locator Count:  The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc'.  The locator count can
      be 0 indicating there are no locators for the EID-prefix.

   EID mask-len:  Mask length for EID prefix.

   ACT:  This 3-bit field describes negative Map-Reply actions.  These
      bits are used only when the 'Locator Count' field is set to 0.
      The action bits are encoded only in Map-Reply messages.  The
      actions defined are used by an ITR or PTR when a destination EID
      matches a negative mapping cache entry.  Unassigned values should
      cause a map-cache entry to be created and, when packets match this
      negative cache entry, they will be dropped.  The current assigned
      values are:

      (0) Drop:  The packet is dropped silently.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
         but natively forwarded.

      (2) Send-Map-Request:  The packet invokes sending a Map-Request.

   A: The Authoritative bit, when sent by a UDP-based message UDP-based message is always
      set to 1 by an ETR.  See [CONS] for TCP-based Map-Replies.  When a
      Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the
      Authoritative bit is set to 0.  This indicates to requesting ITRs
      that the Map-Reply was not originated by a LISP node managed at
      the site that owns the EID-prefix.

   Map-Version Number:  When this 12-bit value is always
      set by non-zero the ETR. Map-Reply
      sender is informing the ITR what the version number is for the
      EID-record contained in the Map-Reply.  The ETR can allocate this
      number internally but MUST coordinate this value with other ETRs
      for the site.  When this value is 0, there is no versioning
      information conveyed.  The Map-Version Number can be included in
      Map-Request and Map-Register messages.  See [CONS] Section 6.5.3 for TCP-based Map-Replies. more
      details.

   EID-AFI:  Address family of EID-prefix according to [RFC2434]. [RFC5226].

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

   Priority:  each RLOC is assigned a unicast priority.  Lower values
      are more preferable.  When multiple RLOCs have the same priority,
      they may be used in a load-split fashion.  A value of 255 means
      the RLOC MUST NOT be used for unicast forwarding.

   Weight:  when priorities are the same for multiple RLOCs, the weight
      indicates how to balance unicast traffic between them.  Weight is
      encoded as a percentage of total unicast packets that match the
      mapping entry.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must MUST use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to load-split traffic.  See
      Section 6.4 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.  When
      a single RLOC exists in a mapping entry, the weight value MUST be
      set to 100 and ignored on receipt.

   M Priority:  each RLOC is assigned a multicast priority used by an
      ETR in a receiver multicast site to select an ITR in a source
      multicast site for building multicast distribution trees.  A value
      of 255 means the RLOC MUST NOT be used for joining a multicast
      distribution tree.

   M Weight:  when priorities are the same for multiple RLOCs, the
      weight indicates how to balance building multicast distribution
      trees across multiple ITRs.  The weight is encoded as a percentage
      of total number of trees build to the source site identified by
      the EID-prefix.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must MUST use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to distribute multicast state across
      ITRs.

   Unused Flags:  set to 0 when sending and ignored on receipt.

   L: when this bit is set, the locator is flagged as a local locator to
      the ETR that is sending the Map-Reply.  When a Map-Server is doing
      proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to
      0 for all locators in this locator-set.

   p: when this bit is set, an ETR informs the RLOC-probing ITR that the
      locator address, for which this bit is set, is the one being RLOC-
      probed and may be different from the source address of the Map-
      Reply.  An ITR that RLOC-probes a particular locator, MUST use
      this locator for retrieving the data structure used to store the
      fact that the locator is reachable.  The "p" bit is set for a
      single locator in the same locator set.  If an implementation sets
      more than one "p" bit erroneously, the receiver of the Map-Reply
      MUST select the first locator.  The "p" bit MUST NOT be set for
      locator-set records sent in Map-Request and Map-Register messages.

   R: when this bit is set, the locator is known to be reachable from
      the Map-Reply sender's perspective.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR or router acting as a proxy replier for the
      EID-prefix.  Note that the destination RLOC address MAY be an
      anycast address.  A source RLOC can be an anycast address as well.
      The source or destination RLOC MUST NOT be the broadcast address
      (255.255.255.255 or any subnet broadcast address known to the
      router), and MUST NOT be a link-local multicast address.  The
      source RLOC MUST NOT be a multicast address.  The destination RLOC
      SHOULD be a multicast address if it is being mapped from a
      multicast destination EID.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.5.  EID-to-RLOC UDP Map-Reply Message

   When a Data Probe packet or a Map-Request triggers a Map-Reply to be
   sent, the RLOCs associated with the EID-prefix matched by the EID in
   the original packet destination IP address field will be returned.
   The RLOCs in the Map-Reply are the globally-routable IP addresses of
   the ETR but are not necessarily reachable; separate testing of
   reachability is required.

   Note that a Map-Reply may contain different EID-prefix granularity
   (prefix + length) than the Map-Request which triggers it.  This might
   occur if a Map-Request were for a prefix that had been returned by an
   earlier Map-Reply.  In such a case, the requester updates its cache
   with the new prefix information and granularity.  For example, a
   requester with two cached EID-prefixes that are covered by a Map-
   Reply containing one, less-specific prefix, replaces the entry with
   the less-specific EID-prefix.  Note that the reverse, replacement of
   one less-specific prefix with multiple more-specific prefixes, can
   also occur but not by removing the less-specific prefix rather by
   adding the more-specific prefixes which during a lookup will override
   the less-specific prefix.

   When an ETR is configured with overlapping EID-prefixes, a Map-
   Request with an EID that longest matches any EID-prefix MUST be
   returned in a single Map-Reply message.  For instance, if an ETR had
   database mapping entries for EID-prefixes:

     10.0.0.0/8
     10.1.0.0/16
     10.1.1.0/24
     10.1.2.0/24

   A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
   count of 1 to be returned with a mapping record EID-prefix of
   10.1.1.0/24.

   A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record
   count of 3 to be returned with mapping records for EID-prefixes
   10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.

   Note that not all overlapping EID-prefixes need to be returned, only
   the more specifics (note in the second example above 10.0.0.0/8 was
   not returned for requesting EID 10.1.5.5) entries for the matching
   EID-prefix of the requesting EID.  When more than one EID-prefix is
   returned, all SHOULD use the same Time-to-Live value so they can all
   time out at the same time.  When a more specific EID-prefix is
   received later, its Time-to-Live value in the Map-Reply record can be
   stored even when other less specifics exist.  When a a less specific
   EID-prefix is received later, its map-cache expiration time should SHOULD be
   set to the minimum expiration time of any more specific EID-prefix in
   the map-cache.

   Map-Replies SHOULD be sent for an EID-prefix no more often than once
   per second to the same requesting router.  For scalability, it is
   expected that aggregation of EID addresses into EID-prefixes will
   allow one Map-Reply to satisfy a mapping for the EID addresses in the
   prefix range thereby reducing the number of Map-Request messages.

   Map-Reply records can have an empty locator-set.  This type of a Map-
   Reply is called a Negative Map-Reply.  Negative Map-Replies convey
   special actions by the sender to the ITR or PTR which have solicited
   the Map-Reply.  There are two primary applications for Negative Map-
   Replies.  The first is for a Map-Resolver to instruct an ITR or PTR
   when a destination is for a LISP site versus a non-LISP site.  And
   the other is to source quench Map-Requests which are sent for non-
   allocated EIDs.

   For each Map-Reply record, the list of locators in a locator-set MUST
   appear in the same order for each ETR that originates a Map-Reply
   message.  The locator-set MUST be sorted in order of ascending IP
   address where an IPv4 locator address is considered numerically 'less
   than' an IPv6 locator address.

   When sending a Map-Reply message, Map-Reply message, the destination address is copied
   from the one of the ITR-RLOC fields from the Map-Request.  The ETR
   can choose a locator address from one of the address families it
   supports.  For Data-Probes, the destination address of the Map-Reply
   is copied from the source address of the Map-Request or Data-Probe message which is
   invoking the reply.  The source address of the Map-Reply is one of
   the local locator addresses listed in the locator-set of any mapping
   record in the message. message and SHOULD be chosen to allow uRPF checks to
   succeed in the upstream service provider.  The destination port of a
   Map-Reply message is copied from the source port of the Map-Request
   or Data-
   Probe Data-Probe and the source port of the Map-Reply message is set to
   the well-known UDP port 4342.

6.1.5.1.  Traffic Redirection with Coarse EID-Prefixes

   When an ETR is misconfigured or compromised, it could return coarse
   EID-prefixes in Map-Reply messages it sends.  The EID-prefix could
   cover EID-prefixes which are allocated to other sites redirecting
   their traffic to the locators of the compromised site.

   To solve this problem, there are two basic solutions that could be
   used.  The first is to have Map-Servers proxy-reply proxy-map-reply on behalf of
   ETRs so their registered EID-prefixes are the ones returned in Map-
   Replies.  Since the interaction between an ETR and Map-Server is
   secured with shared-keys, it is more difficult for an ETR to
   misbehave.  The second solution is to have ITRs and PTRs cache EID-
   prefixes with mask-lengths that are greater than or equal to a
   configured prefix length.  This limits the damage to a specific width
   of any EID-prefix advertised, but needs to be coordinated with the
   allocation of site prefixes.  These solutions can be used
   independently or at the same time.

   At the time of this writing, other approaches are being considered
   and researched.

6.1.6.  Map-Register Message Format

   The usage details of the Map-Register message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent in UDP with a destination UDP port of 4342 and a
   randomly selected UDP source port number.

   The Map-Register message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3 |P|            Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved Rsvd  |  Map-Version Number   |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags      |R|     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   3 (Map-Register)

   P: Set This is the proxy-map-reply bit, when set to 1 by an ETR which sends a Map-Register Map-
      Register message requesting for the Map-Server to proxy Map-Reply.
      The Map-Server will send non-authoritative Map-Replies on behalf
      of the ETR.  Details on this usage will be provided in a future
      version of this draft.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   Record Count:  The number of records in this Map-Register message.  A
      record is comprised of that portion of the packet labeled 'Record'
      above and occurs the number of times equal to Record count.

   Nonce:  This 8-byte Nonce field is set to 0 in Map-Register messages.

   Key ID:  A configured ID to find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The length in bytes of the
      Authentication Data field that follows this field.  The length of
      the the Authentication Data field is dependent on the Message
      Authentication Code (MAC) algorithm used.  The length field allows
      a device that doesn't know the MAC algorithm to correctly parse
      the packet.

   Authentication Data:  The message digest used from the output of the
      Message Authentication Code (MAC) algorithm.  The entire Map-
      Register payload is authenticated with this field preset to 0.
      After the MAC is computed, it is placed in this field.
      Implementations of this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   The definition of the rest of the Map-Register can be found in the
   Map-Reply section.  However, the record TTL field is not used and set
   to 0.

6.1.7.  Encapsualted  Encapsulated Control Message Format

   An Encapsulated Control Message is used to encapsulate control
   packets sent between xTRs and the mapping database system described
   in [LISP-MS].

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=8 |                   Reserved                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   IH  |                  (uses RLOC or EID addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The outer IPv4 or IPv6 header which uses RLOC addresses in the
      source and destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source
      port is randomly allocated.  The checksum field MUST be non-zero.

   LH:   Type 8 is defined to be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or IPv6 header as encoded by
      the first 4 bits after the reserved field.

   IH:   The inner IPv4 or IPv6 header which can use either RLOC or EID
      addresses in the header address fields.  When a Map-Request is
      encapsulated in this packet format the destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on the
      control packet being encapsulated.  When the control packet is a
      Map-Request or Map-Register, the source port is randomly assigned
      and the destination port is 4342.  When the control packet is a
      Map-Reply, the source port is 4342 and the destination port is
      assigned from the source port of the invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be non-zero.

   LCM:   The format is one of the control message formats described in
      this section.  At this time, only Map-Request messages and PIM
      Join-Prune messages [MLISP] are allowed to be encapsulated.
      Encapsulating other types of LISP control messages are for further
      study.  When Map-Requests are sent for RLOC-probing purposes (i.e
      the P-bit probe-bit is set), they MUST not NOT be sent inside Encapsulated
      Control Messages.

6.2.  Routing Locator Selection

   Both client-side and server-side may need control over the selection
   of RLOCs for conversations between them.  This control is achieved by
   manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information may be gleaned from
   received tunneled packets or EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for choosing RLOCs and
   the controls that are available:

   o  Server-side returns one RLOC.  Client-side can only use one RLOC.
      Server-side has complete control of the selection.

   o  Server-side returns a list of RLOC where a subset of the list has
      the same best priority.  Client can only use the subset list
      according to the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing of control exists: the server-side determines the
      destination RLOC list and load distribution while the client-side
      has the option of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight of 0 for the RLOC subset list.  In this
      case, the client-side can choose how the traffic load is spread
      across the subset list.  Control is shared by the server-side
      determining the list and the client determining load distribution.
      Again, the client can use alternative RLOCs if the server-provided
      list of RLOCs are unreachable.

   o  Either side (more likely on the server-side ETR) decides not to
      send a Map-Request.  For example, if the server-side ETR does not
      send Map-Requests, it gleans RLOCs from the client-side ITR,
      giving the client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR RLOC is done by caching the inner header source
      EID and the outer header source RLOC of received packets.  The
      client-side ITR controls how traffic is returned and can alternate
      using an outer header source RLOC, which then can be added to the
      list the server-side ETR uses to return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR must MUST assume each client-side ITR RLOC uses the same best
      Priority with a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed in data packets, the EID-to-RLOC cache
      on tunnel routers can grow to be very large.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the Routing Locator Reachability Algorithms described in the
   next section.

6.3.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the LISP header of an
       encapsulated data packet received from an ITR.  If the ETR is
       also acting as an ITR and has traffic to return to the original
       ITR site, it can use this status information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  An ITR which participates in the global routing system can
       determine that an RLOC is down if no BGP RIB route exists that
       matches the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts to use
       interworking [INTERWORK] and LISP-encapsulated data is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR, the
       source RLOC from the outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at the site.  CE-based ITRs at the source
   site can determine reachability relative to each other using the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP.

   o  If an ITR fails or if the upstream link to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack of a default route
   originated by the others to determine the Locator Status Bits it sets
   for them.

   RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit.  For example, if an RLOC
   listed in the 3rd position of the Map-Reply goes down (ordinal value
   2), then all ITRs at the site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to an RLOC that is indicated as
   down.  It will only resume using that RLOC if the corresponding Loc-
   Status-Bit returns to a value of 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the Loc-Status-Bit that corresponds to that locator's
   position in the list returned by the last Map-Reply will be set to
   zero for that particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can
   still be used to determine the reachability of Locators provided they
   are injected into the IGP.  This is typically done when a /32 address
   is configured on a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as a
   method to determine unreachability, they will refrain from using
   Locators which are described in Locator lists of Map-Replies.
   However, using this approach is unreliable because many network
   operators turn off generation of ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or Host Unreachable message,
   it MAY originate its own ICMP Unreachable message destined for the
   host that originated the data packet the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if
   a locator address from a locator-set in a mapping entry matches a
   prefix.  If it does not find one and BGP is running in the Default
   Free Zone (DFZ), it can decide to not use the locator even though the
   Loc-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can send a Map-Request to a Locator and if a Map-
   Reply is returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages originated by tunnel routers for active flows, so Locators
   are assumed to be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the receipt of ICMP Host Unreachable messages.  When an
   Locator has been determined to be unreachable, it is not used for
   active traffic; this is the same as if it were listed in a Map-Reply
   with priority 255.

   The ITR can test the reachability of the unreachable Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the risk of packet loss for end-to-end
   sessions.

   When an ETR decapsulates a packet, it knows that it is reachable from
   the encapsulating ITR because that is how the packet arrived.  In
   most cases, the ETR can also reach the ITR but cannot assume this to
   be true due to the possibility of path asymmetry.  In the presence of
   unidirectional traffic flow from an ITR to an ETR, the ITR should not SHOULD NOT
   use the lack of return traffic as an indication that the ETR is
   unreachable.  Instead, it must MUST use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there is bidirectional data flow flows bidirectionally between a pair of locators, locators from different
   sites, a simple mechanism called "nonce echoing" can be used to
   determine reachability between an ITR and ETR.  When an ITR wants to
   solicit a nonce echo, it sets the N and E bits and places a 24-bit
   nonce in the LISP header of the next encapsulated data packet.

   When this packet is received by the ETR, the encapsulated packet is
   forwarded as normal.  When the ETR next sends a data packet to the
   ITR, it includes the nonce received earlier with the N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path to
   and from the ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is unreachable is variable
   and a choice left for the implementation.

   If the ITR is receiving packets from the ETR but does not see the
   nonce echoed while being in echo-nonce-request state, then the path
   to the ETR is unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the ETR is down it can switch to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices must MUST
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the same
   time.  The number of packets sent or the time during which echo nonce
   requests are sent is an implementation specific setting.  However,
   when an ITR is in echo-nonce-request state, it can echo the ETR's
   nonce in the next set of packets that it encapsulates and then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve the forward path
   reachability problem as traffic may be unidirectional.  That is, the
   ETR receiving traffic at a site may not may not be the same device as an ITR
   which transmits traffic from that site or the site to site traffic is
   unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the nonce does not occur and the requesting side may
   regard the locator unreachable erroneously.  An ITR should SHOULD only set
   the E-bit in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the Map-
   Reply message.

   Note that other locator reachability mechanisms are being researched
   and can be used to compliment or even override the Echo Nonce
   Algorithm.  See next section for an example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR can use to determine the
   reachability status of one or more locators that it has cached in a
   map-cache entry.  The P-bit (Probe Bit) probe-bit of the Map-Request and Map-
   Reply Map-Reply
   messages are used for RLOC Probing.

   RLOC probing is done in the control-plane on a timer basis where an
   ITR or PTR will originate a Map-Request destined to a locator address
   from one of its own locator addresses.  A Map-Request used as an
   RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the Map-Request is the EID-prefix of the map-cache entry
   cached by the ITR or PTR.  The ITR or PTR may include a mapping data
   record for its own database mapping information.

   When an ETR receives a Map-Request message with the P-bit probe-bit set, it
   returns a Map-Reply with the P-bit probe-bit set.  The source address of
   the Map-Reply is set from the destination address of the Map-Request
   and the destination address of the Map-Reply is set from the source
   address of the Map-Request.  The Map-Reply should SHOULD contain mapping
   data for the EID-prefix contained in the Map-Request.  This provides
   the opportunity for the ITR or PTR, which sent the RLOC-probe to get
   mapping updates if there were changes to the ETR's database mapping
   entries.

   There are advantages and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing is that it can handle many failure scenarios
   allowing the ITR to determine when the path to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator from the cached
   locator.  RLOC Probing can also provide RTT estimates between a pair
   of locators which can be useful for network management purposes as
   well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in the number of control messages required and the
   amount of bandwidth used to obtain those benefits, especially if the
   requirement for failure detection times are very small.

   Continued research and testing will attempt to characterize the
   tradeoffs of failure detection times versus message overhead.

6.4.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
   a requesting ITR, the locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best priority locator exists, the ITR can decide how to load
   share traffic against the corresponding locators.

   The following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash can be used or the
       traditional 5-tuple hash which includes the source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only from the header are used to
       compute the hash.

   2.  Take the hash value and divide it by the number of locators
       stored in the locator-set for the EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the remainder to select the locator in the
       locator-set.

   Note that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs to be set.  Selecting a random value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links of
   such LAGs.  Otherwise, core routers would see a single flow, since
   packets have a source address of the ITR, for packets which are
   originated by different EIDs at the source site.  A suggested setting
   for the source port number computed by an ITR is a 5-tuple hash
   function on the inner header, as described above.

   Many core router implementations use a 5-tuple hash to decide how to
   balance packet load across members of a LAG.  The 5-tuple hash
   includes the source and destination addresses of the packet and the
   source and destination ports when the protocol number in the packet
   is TCP or UDP.  For this reason, UDP encoding is used for LISP
   encapsulation.

6.5.  Changing the Contents of EID-to-RLOC Mappings

   Since the LISP architecture uses a caching scheme to retrieve and
   store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, the ITRs do not
   know when the mappings change and the ETRs do not keep track of who
   requested its mappings.  For scalability reasons, we want to maintain
   this approach but need to provide a way for ETRs change their
   mappings and inform the sites that are currently communicating with
   the ETR site using such mappings.

   When a locator record is added to the end of a locator-set, it is
   easy to update mappings.  We assume new mappings will maintain the
   same locator ordering as the old mapping but just have new locators
   appended to the end of the list.  So some ITRs can have a new mapping
   while other ITRs have only an old mapping that is used until they
   time out.  When an ITR has only an old mapping but detects bits set
   in the loc-status-bits that correspond to locators beyond the list it
   has cached, it simply ignores them.  However, this can only happen
   for locator addresses that are lexicographically greater than the
   locator addresses in the existing locator-set.

   When a locator record is removed from a locator-set, ITRs that have
   the mapping cached will not use the removed locator because the xTRs
   will set the loc-status-bit to 0.  So even if the locator is in the
   list, it will not be used.  For new mapping requests, the xTRs can
   set the locator AFI to 0 (indicating an unspecified address), as well
   as setting the corresponding loc-status-bit to 0.  This forces ITRs
   with old or new mappings to avoid using the removed locator.

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the locator-set and new
   records appended to the locator-set.  At some point, it would be
   useful to compact the locator-set so the loc-status-bit settings can
   be efficiently packed.

   We propose here two three approaches for locator-set compaction, one
   operational and the other a two protocol mechanism. mechanisms.  The operational approach
   uses a clock sweep method.  The protocol approach uses approaches use the concept
   of Solicit-Map-Requests. Solicit-Map-Requests and Map-Versioning.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning in advance and the use of
   count-down TTLs to time out mappings that have already been cached.
   The default setting for an EID-to-RLOC mapping TTL is 24 hours.  So
   there is a 24 hour window to time out old mappings.  The following
   clock sweep procedure is used:

   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the ETRs at a site to start the clock
       sweep window.

   2.  During the clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have timed out,
       and any active cache entries will time out within 1 hour.  During
       this 1 hour window the ETRs continue to send Map-Reply messages
       with the current (unchanged) mapping records with the TTL set to
       1 minute.

   4.  At the end of the 1 hour window, the ETRs will send Map-Reply
       messages with the new (changed) mapping records.  So any active
       caches can get the new mapping contents right away if not cached,
       or in 1 minute if they had the mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for xTRs, at the site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to tell remote ITRs to update
   the mappings they have cached.

   Since the xTRs don't keep track of remote ITRs that have cached their
   mappings, they can not tell exactly who needs the new mapping
   entries.  So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to, and only from those sites.
   The xTRs can locally decide the algorithm for how often and to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in a Map-Request message.  An ITR
   or PTR will send a Map-Request when they receive an SMR message.
   Both the SMR sender and the Map-Request responder must MUST rate-limited
   these messages.

   The following procedure shows how a SMR exchange occurs when a site
   is doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the database mappings in an ETR change, the ETRs at the site
       begin to send Map-Requests with the SMR bit set for each locator
       in each map-cache entry the ETR caches.

   2.  A remote xTR which receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message.  A newly allocated random nonce is selected and the EID-
       prefix uses used is the one copied from the SMR message.

   3.  The remote xTR retransmits MUST rate-limit the Map-Request slowly until it gets a
       Map-Reply while continuing to use the cached mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message provided the Map-Request
       nonce matches the nonce from the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the site with the changed mapping, records record the fact
       that the site that sent the Map-Request has received the new
       mapping data in the mapping cache entry for the remote site so
       the loc-status-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending SMR
       messages.

   For security reasons an ITR MUST NOT process unsolicited Map-Replies.
   The nonce MUST be carried from SMR packet, into the resultant Map-
   Request, and then into Map-Reply to reduce spoofing attacks.

   To avoid map-cache entry corruption by a third-party, a sender of an
   SMR-based Map-Request must MUST be verified.  If an ITR receives an SMR-
   based Map-Request SMR-
   based Map-Request and the source is not in the locator-set for the
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to the mapping database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it will deliver the Map-Request to the authoritative source of the
   mapping data.

6.5.3.  Database Map Versioning

   When there is unidirectional packet flow between an ITR and ETR, and
   the EID-to-RLOC mappings change on the ETR, it needs to inform the
   ITR so encapsulation can stop to a removed locator and start to a new
   locator in the locator-set.

   An ETR, when it sends Map-Reply messages, conveys its own Map-Version
   number.  This is known as the Destination Map-Version Number.  ITRs
   include the Destination Map-Version Number in packets they
   encapsulate to the site.  When an ETR decapsulates a packet and
   detects the Destination Map-Version Number is less than the current
   version for its mapping, the SMR procedure described in Section 6.5.2
   occurs.

   An ITR, when it encapsulates packets to ETRs, can convey its own Map-
   Version number.  This is known as the Source Map-Version Number.

   When an ETR decapsulates a packet and detects the source Source Map-Version
   Number is not in greater than the locator-set for last Map-Version Number sent in a Map-
   Reply from the
   stored map-cache entry, then ITR's site, the responding ETR will send a Map-Request MUST be sent
   with an EID destination to one of
   the mapping database system.  Since ETRs for the
   mapping database system source site.

   A Map-Version Number is more secure used as a sequence number per EID-prefix.  So
   values that are greater, are considered to reach be more recent.  A value
   of 0 for the Source Map-Version Number or the Destination Map-Version
   Number conveys no versioning information and an authoritative ETR,
   it will deliver xTR does no
   comparison with previously received Map-Version Numbers.

   A Map-Version Number can be included in Map-Register messages as
   well.  This is a good way for the Map-Request Map-Server can assure that all ETRs
   for a site registering to the authoritative source it will be Map-Version number synchronized.

   See [VERSIONING] for a more detailed analysis and description of the
   mapping data.
   Database Map Versioning.

7.  Router Performance Considerations

   LISP is designed to be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] and stripping instead of re-
   writing addresses, existing hardware can support the forwarding model
   with little or no modification.  Where modifications are required,
   they should be limited to re-programming existing hardware rather
   than requiring expensive design changes to hard-coded algorithms in
   silicon.

   A few implementation techniques can be used to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special FIB entries
      for the EID-prefixes of EIDs served by the ETR (those for which
      the router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be performed.  The forwarding logic of testing for particular IP
      protocol number value is not necessary.  No changes to existing,
      deployed hardware should be needed to support this.

   o  On an ITR, prepending a new IP header is as simple as adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this action.

   o  When a received packet's outer destination address contains an EID
      which is not intended to be forwarded on the routable topology
      (i.e.  LISP 1.5), the source address of a data packet or the
      router interface with which the source is associated (the
      interface from which it was received) can be associated with a VRF
      (Virtual Routing/Forwarding), in which a different (i.e. non-
      congruent) topology can be used to find EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and will discuss the pros and cons of each deployment scenario.
   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or re-encapsulating
   tunneling.

   When deciding on centralized versus distributed caching, the
   following issues should be considered:

   o  Are the tunnel routers spread out so that the caches are spread
      across all the memories of each router?

   o  Should management "touch points" be minimized by choosing few
      tunnel routers, just enough for redundancy?

   o  In general, using more ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, the
   following issues should be considered:

   o  Flat tunneling implements a single tunnel between source site and
      destination site.  This generally offers better paths between
      sources and destinations with a single tunnel path.

   o  Recursive tunneling is when tunneled traffic is again further
      encapsulated in another tunnel, either to implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the
      site has some control since the site is prepending a new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is prepending a new tunnel header, but if the site's
      ISP is doing the TE, then the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at the
      benefit of steering traffic to resource available parts of the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated with
      a new tunnel header using a new RLOC.

   The next sub-sections will describe where tunnel routers can reside
   in the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to hosts, the EID-prefix set is at
   the granularity of an IP subnet.  So at the expense of more EID-
   prefix-to-RLOC sets for the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on the number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Map-Replies are traveling between more routers.

   The advantage of placing the caches and databases at these stub
   routers is that the products deployed in this part of the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in these devices and fewer routes
   are stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and routing state.

   LISP functionality can also be deployed in edge switches.  These
   devices generally have layer-2 ports facing hosts and layer-3 ports
   facing the Internet.  Spare capacity is also often available in these
   devices as well.

8.2.  Border/Edge Tunnel Routers

   Using customer-edge (CE) routers for tunnel endpoints allows the EID
   space associated with a site to be reachable via a small set of RLOCs
   assigned to the CE routers for that site.

   This offers the opposite benefit of the first-hop/last-hop tunnel
   router scenario: the number of mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage is that less of the network's resources are used to
   reach host endpoints thereby centralizing the point-of-failure domain
   and creating network choke points at the CE router.

   Note that more than one CE router at a site can be configured with
   the same IP address.  In this case an RLOC is an anycast address.
   This allows resilience between the CE routers.  That is, if a CE
   router fails, traffic is automatically routed to the other routers
   using the same anycast address.  However, this comes with the
   disadvantage where the site cannot control the entrance point when
   the anycast route is advertised out from all border routers.

8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers gives an ISP control
   over the location of the egress tunnel endpoints.  That is, the ISP
   can decide if the tunnel endpoints are in the destination site (in
   either CE routers or last-hop routers within a site) or at other PE
   edges.  The advantage of this case is that two or more tunnel headers
   can be avoided.  By having the PE be the first router on the path to
   encapsulate, it can choose a TE path first, and the ETR can
   decapsulate and re-encapsulate for a tunnel to the destination end
   site.

   An obvious disadvantage is that the end site has no control over
   where its packets flow or the RLOCs used.

   As mentioned in earlier sections a combination of these scenarios is
   possible at the expense of extra packet header overhead, if both site
   and provider want control, then recursive or re-encapsulating tunnels
   are used. provider want control, then recursive or re-encapsulating tunnels
   are used.

8.4.  LISP Functionality with Conventional NATs

   LISP routers can be deployed behind Network Address Translator (NAT)
   devices to provide the same set of packet services hosts have today
   when they are addressed out of private address space.

   It is important to note that a locator address in any LISP control
   message MUST be a globally routable address and therefore SHOULD NOT
   contain [RFC1918] addresses.  If a LISP router is configured with
   private addresses, they MUST be used only in the outer IP header so
   the NAT device can translate properly.  Otherwise, EID addresses MUST
   be translated before encapsulation is performed.  Both NAT
   translation and LISP encapsulation functions could be co-located in
   the same device.

   More details on LISP address translation can be found in [INTERWORK].

9.  Traceroute Considerations

   When a source host in a LISP site initiates a traceroute to a
   destination host in another LISP site, it is highly desirable for it
   to see the entire path.  Since packets are encapsulated from ITR to
   ETR, the hop across the tunnel could be viewed as a single hop.
   However, LISP traceroute will provide the entire path so the user can
   see 3 distinct segments of the path from a source LISP host to a
   destination LISP host:

      Segment 1 (in source LISP site based on EIDs):

          source-host ---> first-hop ... next-hop ---> ITR

      Segment 2 (in the core network based on RLOCs):

          ITR ---> next-hop ... next-hop ---> ETR

      Segment 3 (in the destination LISP site based on EIDs):

          ETR ---> next-hop ... last-hop ---> destination-host

   For segment 1 of the path, ICMP Time Exceeded messages are returned
   in the normal matter as they are today.  The ITR performs a TTL
   decrement and test for 0 before encapsulating.  So the ITR hop is
   seen by the traceroute source has an EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are returned
   to the ITR because the TTL decrement to 0 is done on the outer
   header, so the destination of the ICMP messages are to the ITR RLOC
   address, the source source RLOC address of the encapsulated traceroute
   packet.  The ITR looks inside of the ICMP payload to inspect the
   traceroute source so it can return the ICMP message to the address of
   the traceroute client as well as retaining the core router IP address
   in the ICMP message.  This is so the traceroute client can display
   the core router address (the RLOC address) in the traceroute output.
   The ETR returns its RLOC address and responds to the TTL decrement to
   0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will be
   decrementing the TTL for the packet that was encapsulated, sent into
   the core, decapsulated by the ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the destination of the traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the traceroute client.  The ICMP message will be
   encapsulated by the local ITR and sent back to the ETR in the
   originated traceroute source site, where the packet will be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs to pay special
   attention for forwarding ICMP messages back to the traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the above procedure since IPv4
   ICMP Time Exceeded messages only include the invoking IP header and 8
   bytes that follow the IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP
   payload is the encapsulated header it prepended followed by a UDP
   header.  The original invoking IP header, and therefore the identity
   of the traceroute source is lost.

   The solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the ETR.  The
   ITR will use a circular buffer for caching the IPv4 and UDP headers
   of traceroute packets.  It will select a 16-bit number as a key to
   find them later when the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as the UDP source port in the encapsulating header.
   When the ICMP Time Exceeded message is returned to the ITR, the UDP
   header of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload
   and sends the ICMP Time Exceeded message to the traceroute source
   retaining the source address of the original ICMP Time Exceeded
   message (a core router or the ETR of the site of the traceroute
   destination).

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is originated and
   the ITR encapsulates it in the other address family header, you
   cannot get all 3 segments of the traceroute.  Segment 2 of the
   traceroute can not be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the tunnel look like one hop.  All the ITR has to
   do to make this work is to not copy the inner TTL to the outer,
   encapsulating header's TTL when a traceroute packet is encapsulated
   using an RLOC from a different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the ITR and ETR.

10.  Mobility Considerations

   There are several kinds of mobility of which only some might be of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in EID-RLOC mappings for sites are expected to be
   handled by configuration, outside of the LISP protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering is involved.  LISP can
   help with the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a site from the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves relatively
   rapidly, changing its IP layer network attachment point.  Maintenance
   of session continuity is a goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to be explored.

   The problem is that as an endpoint moves, it may require changes to
   the mapping between its EID and a set of RLOCs for its new network
   location.  When this is added to the overhead of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint is away from home, packets to it
   are encapsulated and forwarded via a home agent which resides in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the endpoint or to
   a foreign agent which resides where the endpoint has moved to.
   Packets from the endpoint may be sent directly to the correspondent
   node, may be sent via the foreign agent, or may be reverse-tunneled
   back to the home agent for delivery to the mobile node.  As the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between the mobile node and
   the home agent, whether via foreign agent or not.  As a mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an old location to a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one of the new visited network's ITRs, which needs a EID-RLOC
      mapping for the home agent.

   o  The home agent might not have the EID-RLOC mappings for the mobile
      node's "care-of" address or its foreign agent in the new visited
      network, in which case it will need to acquire them.

   o  When packets are sent directly to the correspondent node, it may
      be that no traffic has been sent from the new visited network to
      the correspondent node's network, and the new visited network's
      ITR will need to obtain an EID-RLOC mapping for the correspondent
      node's site.

   In addition, if the IPv4 endpoint is sending packets from the new
   visited network using its original EID, then LISP will need to
   perform a route-returnability check on the new EID-RLOC mapping for
   that EID.

   In IPv6 mobility, packets can flow directly between the mobile node
   and the correspondent node in either direction.  The mobile node uses
   its "care-of" address (EID).  In this case, the route-returnability
   check would not be needed but one more LISP mapping lookup may be
   required instead:

   o  As above, three mapping changes may be needed for the mobile node
      to communicate with its home agent and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order for the correspondent node to send packets to
      the mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the number of potential mapping
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the mobile node, correspondent node, and home agent, but also state
   changes in the ITRs and ETRs for at least some EID-prefixes.

   The goal is to support rapid adaptation, with little delay or packet
   loss for the entire system.  Heuristics can be added to LISP to
   reduce the number of mapping changes required and to reduce the delay
   per mapping change.  Also IP mobility can be modified to require
   fewer mapping changes.  In order to increase overall system
   performance, there may be a need to reduce the optimization of one
   area in order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It can do this after
   performing a route-returnability check, to ensure that the new
   network location does have a internal route to that endpoint.
   However, this does not cover the case where an ITR (the node assigned
   the RLOC) at the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment in which all
   routing information is disseminated before packets can be forwarded.
   In order to allow the Internet to grow to support expected future
   use, we are moving to an environment where some information may have
   to be obtained after packets are in flight.  Modifications to IP
   mobility should be considered in order to optimize the behavior of
   the overall system.  Anything which decreases the number of new EID-
   RLOC mappings needed when a node moves, or maintains the validity of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network" can be as small as a single router and as large as
   a whole site.  This is different from site mobility in that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any endpoint will return a binding for the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   to revisit the design of the mapping service and allow for dynamic
   updates of the database.

   The issue of interactions between mobility and LISP needs to be
   explored further.  Specific improvements to the entire system will
   depend on the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   A mobile device can use the LISP infrastructure to achieve mobility
   by implementing the LISP encapsulation and decapsulation functions
   and acting as a simple ITR/ETR.  By doing this, such a "LISP mobile
   node" can use topologically-independent EID IP addresses that are not
   advertised into and do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
   only the correspondents of the LISP mobile node.

   Refer to the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined in the original Internet
   architecture is an identifier of a grouping of topologically
   independent receiver host locations.  The address encoding itself
   does not determine the location of the receiver(s).  The multicast
   routing protocol, and the network-based state the protocol creates,
   determines where the receivers are located.

   In the context of LISP, a multicast group address is both an EID and
   a Routing Locator.  Therefore, no specific semantic or action needs
   to be taken for a destination address, as it would appear in an IP
   header.  Therefore, a group address that appears in an inner IP
   header built by a source host will be used as the destination EID.
   The outer IP header (the destination Routing Locator address),
   prepended by a LISP router, will use the same group address as the
   destination Routing Locator.

   Having said that, only the source EID and source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address in the source Routing Locator field when prepending
   the outer IP header.  This source Routing Locator address, like any
   other Routing Locator address MUST be globally routable.

   Therefore, an EID-to-RLOC mapping does not need to be performed by an
   ITR when a received data packet is a multicast data packet or when
   processing a source-specific Join (either by IGMPv3 or PIM).  But the
   source Routing Locator is decided by the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach is to have the ITR not encapsulate a multicast
   packet and allow the the host built packet to flow into the core even
   if the source address is allocated out of the EID namespace.  If the
   RPF-Vector TLV [RPFV] [RFC5496] is used by PIM in the core, then core
   routers can RPF to the ITR (the Locator address which is injected
   into core routing) rather than the host source address (the EID
   address which is not injected into core routing).

   To avoid any EID-based multicast state in the network core, the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and Interworking with non-LISP sites is described in specification
   [MLISP].

12.  Security Considerations

   It is believed that most of the security mechanisms will be part of
   the mapping database service when using control plane procedures for
   obtaining EID-to-RLOC mappings.  For data plane triggered mappings,
   as described in this specification, protection is provided against
   ETR spoofing by using Return- Routability mechanisms evidenced by the
   use of a 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  The nonce, coupled
   with the ITR accepting only solicited Map-Replies goes a long way
   toward providing decent authentication.

   LISP does not rely on a PKI infrastructure or a more heavy weight
   authentication system.  These systems challenge the scalability of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies to the control plane as well as rate-
   limiting the number of data-triggered Map-Replies.

   To deal with map-cache exhaustion attempts in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list for special or frequently accessed
   sites.  This should be a configuration policy control set by the
   network administrator who manages ITRs and PTRs.

13.  IANA Considerations

   Refer to LISP Canonical Address Format specification [LCAF] for IANA
   considerations.

14.  Prototype Plans and Status

   The operator community has requested that the IETF take a practical
   approach to solving the scaling problems associated with global
   routing state growth.  This document offers a simple solution which
   is intended for use in a pilot program to gain experience in working
   on this problem.

   The authors hope that publishing this specification will allow the
   rapid implementation of multiple vendor prototypes and deployment on
   a small scale.  Doing this will help the community:

   o  Decide whether a new EID-to-RLOC mapping database infrastructure
      is needed or if a simple, UDP-based, data-triggered approach is
      flexible and robust enough.

   o  Experiment with provider-independent assignment of EIDs while at
      the same time decreasing the size of DFZ routing tables through
      the use of topologically-aligned, provider-based RLOCs.

   o  Determine whether multiple levels of tunneling can be used by ISPs
      to achieve their Traffic Engineering goals while simultaneously
      removing the more specific routes currently injected into the
      global routing system for this purpose.

   o  Experiment with mobility to determine if both acceptable
      convergence and session continuity properties can be scalably
      implemented to support both individual device roaming and site
      service provider changes.

   Here is a rough set of milestones:

   1.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   2.  Continue pilot deployment using LISP-ALT as the database mapping
       mechanism.

   3.  Continue prototyping and studying other database lookup schemes,
       be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms.

   4.  Implement the LISP Multicast draft [MLISP].

   5.  Implement the LISP Mobile Node draft [LISP-MN].

   6.  Research more on how policy affects what gets returned in a Map-
       Reply from an ETR.

   7.  Continue to experiment with mixed locator-sets to understand how
       LISP can help the IPv4 to IPv6 transition.

   8.  Add more robustness to locator reachability between LISP sites.

   9.  Continue the deployment of Proxy-ETRs (PETRs) for uses like uRPF
       avoidance, IPv6 connectivity, and LISP-MN.

   As of this writing the following accomplishments have been achieved:

   1.   A unit- and system-tested software switching implementation has
        been completed on cisco NX-OS for this draft for both IPv4 and
        IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators.

   2.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [ALT].

   3.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [INTERWORK].  Support
        for IPv4 translation is provided and PTR support for IPv4 and
        IPv6 is provided.

   4.   The cisco NX-OS implementation supports an experimental
        mechanism for slow mobility.

   5.   There are 5 LISP implementations that exist and the first 4
        below have gone through interoperability testing at IETF
        Hiroshima, based on the draft-ietf-lisp-05.txt spec:

        1.  cisco NX-OS

        2.  OpenLISP

        3.  LISP-Click

        4.  ZLisp

        5.  cisco IOS

   6.   Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and Gregg Schudel, Andrew
        Partan and the rest of the lisp-beta team continue to test all
        the features described above on a dual-stack infrastructure.

   7.   Darrel Lewis and Dave Meyer have deployed both LISP translation
        and LISP PTR support in the pilot network.  Point your browser
        to http://www.lisp4.net to see translation happening in action
        so your non-LISP site can access a web server in a LISP site.

   8.   Soon http://www.lisp6.net will work where your IPv6 LISP site
        can talk to a IPv6 web server in a LISP site by using mixed
        address-family based locators.

   9.   An public domain implementation of LISP is underway. available.  See
        [OPENLISP] for details.

   10.  We have deployed Map-Resolvers and Map-Servers on the LISP pilot
        network to gather experience with [LISP-MS].  The first layer of
        the architecture are the xTRs which use Map-Servers for EID-
        prefix registration and Map-Resolvers for EID-to-RLOC mapping
        resolution.  The second layer are the Map-Resolvers and Map-
        Servers which connect to the ALT BGP peering infrastructure.
        And the third layer are ALT-routers which aggregate EID-prefixes
        and forward Map-Requests.

   11.  A cisco IOS implementation is underway available which currently supports
        IPv4 and IPv6 encapsulation and decapsulation features.

   12.  A LISP router based LIG implementation is supported, deployed,
        and used daily to debug and test the LISP pilot network.  See
        [LIG] for details.

   13.  A Linux implementation of LIG has been made available and
        supported by Dave Meyer.  It can be run on any Linux system
        which resides in either a LISP site or non-LISP site.  See [LIG]
        for details.  Public domain code can be downloaded from
        http://github.com/davidmeyer/lig/tree/master.

   14.  An experimental implementation has been written for three
        locator reachability algorithms.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented in this
        specification.  The third is called TCP-counts which will be
        documented in future drafts.

   15.  The LISP pilot network has been converted from using MD5 HMAC
        authentication for Map-Register messages to SHA-1 HMAC
        authentication.  ETRs send with SHA-1 but Map-Servers can
        received from either for compatibility purposes.

   16.  The LISP pilot network is in its 3rd generation.  Current
        experiments are being performed to test EID-prefix aggregation
        at multiple service boundaries as well as deploying models for
        the existence of multiple Mapping Service Providers (MSPs).

   If interested in writing a LISP implementation, testing any of the
   LISP implementations, or want to be part of the LISP pilot program,
   please contact lisp@ietf.org.

14.

15.  References

14.1.

15.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1498]  Saltzer, J., "On the Naming and Binding of Network
              Destinations", RFC 1498, August 1993.

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

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

   [RFC1955]  Hinden, R., "New Scheme for Internet Routing and
              Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 2006.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

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

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009.

   [UDP-TUNNELS]
              Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
              Packets"", draft-eubanks-chimento-6man-00.txt (work in
              progress), February 2009.

14.2.

15.2.  Informative References

   [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-02.txt
              draft-ietf-lisp-alt-04.txt (work in progress),
              January April 2010.

   [APT]      Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01.txt (work in progress), November 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network  Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [DHTs]     Ratnasamy, S., Shenker, S., and I. Stoica, "Routing
              Algorithms for DHTs: Some Open Questions", PDF
              file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.

   [EMACS]    Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              draft-curran-lisp-emacs-00.txt (work in progress),
              November 2007.

   [GSE]      "GSE - An Alternate Addressing Architecture for  IPv6",
              draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-01.txt (work in progress),
              January
              March 2010.

   [LCAF]     Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format", draft-farinacci-lisp-lcaf-01.txt (work in
              progress), April 2010.

   [LIG]      Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-01.txt
              draft-ietf-lisp-lig-00.txt (work in progress),
              May 2009. April 2010.

   [LISA96]   Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
              "Renumbering: Threat or Menace?", Usenix , September 1996.

   [LISP-MAIN]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress),
              March 2009.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), July 2009.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-03.txt
              draft-ietf-lisp-ms-05.txt (work in progress),
              September 2009. April 2010.

   [LISP1]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP1) [Routable  ID
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
              October 2006.

   [LISP2]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP2) [DNS-based
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
              November 2006.

   [LISPDHT]  Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT:
              Towards a DHT to map identifiers onto locators",
              draft-mathy-lisp-dht-00.txt (work in progress),
              February 2008.

   [LOC-ID-ARCH]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID  Separation",
              draft-meyer-loc-id-implications-01.txt (work in progress),
              Januaryr 2009.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-ietf-lisp-multicast-02.txt
              draft-ietf-lisp-multicast-03.txt (work in progress),
              September 2009.
              April 2010.

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

   [OPENLISP]
              Iannone, L. and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-08.txt (work in progress),
              January 2009.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.txt (work in
              progress), July 2007.

   [SHIM6]    Nordmark, E.

   [VERSIONING]
              Iannone, L., Saucez, D., and M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt O. Bonaventure, "LISP Mapping
              Versioning", draft-iannone-lisp-mapping-versioning-01.txt
              (work in progress), October 2006. March 2010.

Appendix A.  Acknowledgments

   An initial thank you goes to Dave Oran for planting the seeds for the
   initial ideas for LISP.  His consultation continues to provide value
   to the LISP authors.

   A special and appreciative thank you goes to Noel Chiappa for
   providing architectural impetus over the past decades on separation
   of location and identity, as well as detailed review of the LISP
   architecture and documents, coupled with enthusiasm for making LISP a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
   Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
   Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
   Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
   Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko,
   Gregg Schudel, Srinivas Subramanian, Amit Jain, and Xu Xiaohu. Xiaohu, and
   Dhirendra Trivedi.

   In particular, we would like to thank Dave Meyer for his clever
   suggestion for the name "LISP". ;-)

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-07.txt

   o  Posted April 2010.

   o  Added I-bit to data header so LSB field can also be used as an
      Instance ID field.  When this occurs, the LSB field is reduced to
      8-bits (from 32-bits).

   o  Added V-bit to the data header so the 24-bit nonce field can also
      be used for source and destination version numbers.

   o  Added Map-Version 12-bit value to the EID-record to be used in all
      of Map-Request, Map-Reply, and Map-Register messages.

   o  Added multiple ITR-RLOC fields to the Map-Request packet so an ETR
      can decide what address to select for the destination of a Map-
      Reply.

   o  Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to
      the Locator-Set record of an EID-record for a Map-Reply message.
      The L-bit indicates which RLOCs in the locator-set are local to
      the sender of the message.  The P-bit indicates which RLOC is the
      source of a RLOC-probe Reply (Map-Reply) message.

   o  Add reference to the LISP Canonical Address Format [LCAF] draft.

   o  Made editorial and clarification changes based on comments from
      Dhirendra Trivedi.

   o  Added wordsmithing comments from Joel Halpern on DF=1 setting.

   o  Add John Zwiebel clarification to Echo Nonce Algorithm section
      6.3.1.

   o  Add John Zwiebel comment about expanding on proxy-map-reply bit
      for Map-Register messages.

   o  Add NAT section per Ron Bonica comments.

   o  Fix IDnits issues per Ron Bonica.

   o  Added section on Virtualization and Segmentation to explain the
      use if the Instance ID field in the data header.

   o  There are too many P-bits, keep their scope to the packet format
      description and refer to them by name every where else in the
      spec.

   o  Scanned all occurrences of "should", "should not", "must" and
      "must not" and uppercased them.

   o  John Zwiebel offered text for section 4.1 to modernize the
      example.  Thanks Z!

B.2.  Changes to draft-ietf-lisp-06.txt

   Editorial based changes:

   o  Posted December 2009.

   o  Fix typo for rflags flags in LISP data header.  Changed from "4" to "5".

   o  Add text to indicate that Map-Register messages must contain a
      computed UDP checksum.

   o  Add definitions for PITR and PETR.

   o  Indicate an AFI value of 0 is an unspecified address.

   o  Indicate that the TTL field of a Map-Register is not used and set
      to 0 by the sender.  This change makes this spec consistent with
      [LISP-MS].

   o  Change "... yield a packet size of L bytes" to "... yield a packet
      size greater than L bytes".

   o  Clarify section 6.1.5 on what addresses and ports are used in Map-
      Reply messages.

   o  Clarify that LSBs that go beyond the number of locators do not to
      be SMRed when the locator addresses are greater lexicographically
      than the locator in the existing locator-set.

   o  Add Gregg, Srini, and Amit to acknowledgment section.

   o  Clarify in the definition of a LISP header what is following the
      UDP header.

   o  Clarify "verifying Map-Request" text in section 6.1.3.

   o  Add Xu Xiaohu to the acknowledgment section for introducing the
      problem of overlapping EID-prefixes among multiple sites in an RRG
      email message.

   Design based changes:

   o  Use stronger language to have the outer IPv4 header set DF=1 so we
      can avoid fragment reassembly in an ETR or PETR.  This will also
      make IPv4 and IPv6 encapsulation have consistent behavior.

   o  Map-Requests should not be sent in ECM with the Probe bit is set.
      These type of Map-Requests are used as RLOC-probes and are sent
      directly to locator addresses in the underlying network.

   o  Add text in section 6.1.5 about returning all EID-prefixes in a
      Map-Reply sent by an ETR when there are overlapping EID-prefixes
      configure.

   o  Add text in a new subsection of section 6.1.5 about dealing with
      Map-Replies with coarse EID-prefixes.

B.2.

B.3.  Changes to draft-ietf-lisp-05.txt

   o  Posted September 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in Map-Registers.  Put key-id, auth-length, and auth-
      data in Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.

   o  Make more clear what source-RLOC should be for a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

   o  Removed nonce from Map-Register message, it wasn't used so no need
      for it.

   o  Clarify what to do for unspecified Action bits for negative Map-
      Replies.  Since No Action is a drop, make value 0 Drop.

B.3.

B.4.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  How do deal with record count greater than 1 for a Map-Request.
      Damien and Joel comment.  Joel suggests: 1) Specify that senders
      compliant with the current document will always set the count to
      1, and note that the count is included for future extensibility.
      2) Specify what a receiver compliant with the draft should do if
      it receives a request with a count greater than 1.  Presumably, it
      should send some error back?

   o  Add Fred Templin in acknowledgment section.

   o  Add Margaret and Sam to the acknowledgment section for their great
      comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums on
      ETR.  From the mailing list: "You'd need to word it as an ITR MAY
      send a zero checksum, an ETR MUST accept a 0 checksum and MAY
      ignore the checksum completely.  And of course we'd need to
      confirm that can actually be implemented.  In particular, hardware
      that verifies UDP checksums on receive needs to be checked to make
      sure it permits 0 checksums."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      for MNs but often enough to get mapping updates.

   o  Indicate SHA1 can be used as well for Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about spec'ing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

   o  Margaret's comment on gleaning: "The current specification does
      not make it clear how long gleaned map entries should be retained
      in the cache, nor does it make it clear how/ when they will be
      validated.  The LISP spec should, at the very least, include a
      (short) default lifetime for gleaned entries, require that they be
      validated within a short period of time, and state that a new
      gleaned entry should never overwrite an entry that was obtained
      from the mapping system.  The security implications of storing
      "gleaned" entries should also be explored in detail."

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

   o  Change LISP header to allow a "Research Bit" so the Nonce and LSB
      fields can be turned off and used for another future purpose.  For
      Luigi et al versioning convergence.

   o  Add a N-bit to the data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

   o  Indicate when doing data-gleaning that a verifying Map-Request is
      sent to the source-EID of the gleaned data packet so we can avoid
      map-cache corruption by a 3rd party.  Comment from Pedro.

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro and Dino.

   o  Jesper made a comment to loosen the language about requiring the
      copy of inner TTL to outer TTL since the text to get mixed-AF
      traceroute to work would violate the "MUST" clause.  Changed from
      MUST to SHOULD in section 5.3.

B.4.

B.5.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from John Zwiebel in Echo-Nonce section.

B.5.

B.6.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.

B.6.

B.7.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.

   o  Added Proxy-Map-Reply bit to Map-Register.

B.7.

B.8.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com
--Apple-Mail-10-1034602901 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail-10-1034602901 Content-Disposition: attachment; filename=draft-ietf-lisp-07.txt Content-Type: text/plain; name="draft-ietf-lisp-07.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: October 17, 2010 D. Lewis cisco Systems April 15, 2010 Locator/ID Separation Protocol (LISP) draft-ietf-lisp-07 Abstract This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 17, 2010. Copyright Notice Farinacci, et al. Expires October 17, 2010 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Copyright (c) 2010 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 BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 22 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 23 5.5. Using Virtualization and Segmentation with LISP . . . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 25 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 25 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 27 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 27 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 29 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 31 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 34 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 37 6.1.7. Encapsulated Control Message Format . . . . . . . . . 38 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 40 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 41 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 44 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 45 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 46 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 47 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 47 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 48 6.5.3. Database Map Versioning . . . . . . . . . . . . . . . 49 7. Router Performance Considerations . . . . . . . . . . . . . . 51 Farinacci, et al. Expires October 17, 2010 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 52 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 53 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 53 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 54 8.4. LISP Functionality with Conventional NATs . . . . . . . . 54 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 55 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 56 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 56 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 56 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 58 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 58 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 58 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 58 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 60 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 60 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 62 12. Security Considerations . . . . . . . . . . . . . . . . . . . 63 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 14. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 65 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 15.1. Normative References . . . . . . . . . . . . . . . . . . . 68 15.2. Informative References . . . . . . . . . . . . . . . . . . 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 73 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 74 B.1. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 74 B.2. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 75 B.3. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 76 B.4. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 77 B.5. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 78 B.6. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 79 B.7. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 79 B.8. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80 Farinacci, et al. Expires October 17, 2010 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires October 17, 2010 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 2. Introduction Many years of discussion about the current IP routing and addressing architecture have noted that its use of a single numbering space (the "IP address") for both host transport session identification and network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). A number of scaling benefits would be realized by separating the current IP address into separate spaces for Endpoint Identifiers (EIDs) and Routing Locators (RLOCs); among them are: 1. Reduction of routing table size in the "default-free zone" (DFZ). Use of a separate numbering space for RLOCs will allow them to be assigned topologically (in today's Internet, RLOCs would be assigned by providers at client network attachment points), greatly improving aggregation and reducing the number of globally-visible, routable prefixes. 2. More cost-effective multihoming for sites that connect to different service providers where they can control their own policies for packet flow into the site without using extra routing table resources of core routers. 3. Easing of renumbering burden when clients change providers. Because host EIDs are numbered from a separate, non-provider- assigned and non-topologically-bound space, they do not need to be renumbered when a client site changes its attachment points to the network. 4. Traffic engineering capabilities that can be performed by network elements and do not depend on injecting additional state into the routing system. This will fall out of the mechanism that is used to implement the EID/RLOC split (see Section 4). 5. Mobility without address changing. Existing mobility mechanisms will be able to work in a locator/ID separation scenario. It will be possible for a host (or a collection of hosts) to move to a different point in the network topology either retaining its home-based address or acquiring a new address based on the new network location. A new network location could be a physically different point in the network topology or the same physical point of the topology with a different provider. This draft describes protocol mechanisms to achieve the desired functional separation. For flexibility, the mechanism used for forwarding packets is decoupled from that used to determine EID to RLOC mappings. This document covers the former. For the latter, see [CONS], [ALT], [EMACS], [RPMD], and [NERD]. This work is in response to and intended to address the problem statement that came out of the Farinacci, et al. Expires October 17, 2010 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 RAWS effort [RFC4984]. The Routing and Addressing problem statement can be found in [RADIR]. This draft focuses on a router-based solution. Building the solution into the network will facilitate incremental deployment of the technology on the Internet. Note that while the detailed protocol specification and examples in this document assume IP version 4 (IPv4), there is nothing in the design that precludes use of the same techniques and mechanisms for IPv6. It should be possible for IPv4 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 RLOCs. Related work on host-based solutions is described in Shim6 [RFC5533] and HIP [RFC4423]. Related work on a router-based solution is described in [GSE]. This draft attempts to not compete or overlap with such solutions and the proposed protocol changes are expected to complement a host-based mechanism when Traffic Engineering functionality is desired. Some of the design goals of this proposal include: 1. Require no hardware or software changes to end-systems (hosts). 2. Minimize required changes to Internet infrastructure. 3. Be incrementally deployable. 4. Require no router hardware changes. 5. Minimize the number of routers which have to be modified. In particular, most customer site routers and no core routers require changes. 6. Minimize router software changes in those routers which are affected. 7. Avoid or minimize packet loss when EID-to-RLOC mappings need to be performed. There are 4 variants of LISP, which differ along a spectrum of strong to weak dependence on the topological nature and possible need for routability of EIDs. The variants are: Farinacci, et al. Expires October 17, 2010 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 LISP 1: uses EIDs that are routable through the RLOC topology for bootstrapping EID-to-RLOC mappings. [LISP1] This was intended as a prototyping mechanism for early protocol implementation. It is now deprecated and SHOULD NOT be deployed. LISP 1.5: uses EIDs that are routable for bootstrapping EID-to-RLOC mappings; such routing is via a separate topology. LISP 2: uses EIDS that are not routable and EID-to-RLOC mappings are implemented within the DNS. [LISP2] LISP 3: uses non-routable EIDs that are used as lookup keys for a new EID-to-RLOC mapping database. Use of Distributed Hash Tables [DHTs] [LISPDHT] to implement such a database would be an area to explore. Other examples of new mapping database services are [CONS], [ALT], [RPMD], [NERD], and [APT]. This document on LISP 1.5, and LISP 3 variants, both of which rely on a router-based distributed cache and database for EID-to-RLOC mappings. The LISP 1.0 mechanism works but does not allow reduction of routing information in the default-free-zone of the Internet. The LISP 2 mechanisms are put on hold and may never come to fruition since it is not architecturally pure to have routing depend on directory and directory depend on routing. The LISP 3 mechanisms will be documented elsewhere but may use the control-plane options specified in this specification. Farinacci, et al. Expires October 17, 2010 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 3. Definition of Terms Provider Independent (PI) Addresses: an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g. from a particular service provider), and is therefore not topologically aggregatable in the routing system. Provider Assigned (PA) Addresses: a block of IP addresses that are assigned to a site by each service provider to which a site connects. Typically, each block is sub-block of a service provider CIDR block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multi-homed site acquiring its own, globally-visible prefix. LISP uses only topologically-assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called a "LEID". Throughout this document, any references to "EID" refers to an LEID. Farinacci, et al. Expires October 17, 2010 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 EID-prefix: A power-of-2 block of EIDs which are allocated to a site by an address allocation authority. EID-prefixes are associated with a set of RLOC addresses which make up a "database mapping". EID-prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the smaller EID- prefix. A globally routed address block (whether PI or PA) is not an EID-prefix. However, a globally routed address block may be removed from global routing and reused as an EID-prefix. A site that receives an explicitly allocated EID-prefix may not use that EID-prefix as a globally routed prefix assigned to RLOCs. End-system: is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e. outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. Ingress Tunnel Router (ITR): a router which accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating hosts supplied EID). TE-ITR: is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. Egress Tunnel Router (ETR): a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the Farinacci, et al. Expires October 17, 2010 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. TE-ETR: is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. xTR: is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality is at the CE router. EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings, it is dynamic, local to the ITR(s), and relatively small while the database is distributed, relatively static, and much more global in scope. EID-to-RLOC Database: a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. Recursive Tunneling: when a packet has more than one LISP IP header. Additional layers of tunneling may be employed to implement traffic engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added and the original RLOCs are preserved in the "inner" header. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. Reencapsulating Tunnels: when a packet has no more than one LISP IP header (two IP headers total) and when it needs to be diverted to new RLOC, an ETR can decapsulate the packet (remove the LISP header) and prepends a new tunnel header, with new RLOC, on to the packet. Doing this allows a packet to be re-routed by the re- encapsulating router without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. Farinacci, et al. Expires October 17, 2010 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte header that follows the UDP header, an ITR prepends or an ETR strips. Address Family Identifier (AFI): a term used to describe an address encoding in a packet. An address family currently pertains to an IPv4 or IPv6 address. See [AFI] and [RFC1700] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the the length of the address is 0 bytes following the 16-bit AFI value of 0. Also, refer to [LCAF] for LISP specific AFI encodings. Negative Mapping Entry: also known as a negative cache entry, is an EID-to-RLOC entry where an EID-prefix is advertised or stored with no RLOCs. That is, the locator-set for the EID-to-RLOC entry is empty or has an encoded locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well defined actions that are encoded in a Negative Map-Reply. Data Probe: a LISP-encapsulated data packet where the inner header destination address equals the outer header destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host. A Data Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design for details. Proxy ITR (PITR): also known as a PTR is defined and described in [INTERWORK], a PITR acts like an ITR but does so on behalf of non- LISP sites which send packets to destinations at LISP sites. Proxy ETR (PETR): is defined and described in [INTERWORK], a PETR acts like an ETR but does so on behalf of LISP sites which send packets to destinations at non-LISP sites. Farinacci, et al. Expires October 17, 2010 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 4. Basic Overview One key concept of LISP is that end-systems (hosts) operate the same way they do today. The IP addresses that hosts use for tracking sockets, connections, and for sending and receiving packets do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. This design introduces "Tunnel Routers", which prepends LISP headers on host-originated packets and strip them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet and an egress tunnel router strips the new header. The ITR performs EID-to-RLOC lookups to determine the routing path to the the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems (hosts) only send to addresses which are EIDs. They don't know addresses are EIDs versus RLOCs but assume packets get to LISP routers, which in turn, deliver packets to the destination the end-system has specified. o EIDs are always IP addresses assigned to hosts. o LISP routers mostly deal with Routing Locator addresses. See details later in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers; preferably, topologically-oriented addresses from provider CIDR blocks. o When a router originates packets it may use as a source address either an EID or RLOC. When acting as a host (e.g. when terminating a transport session such as SSH, TELNET, or SNMP), it may use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC Farinacci, et al. Expires October 17, 2010 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. o EIDs are not expected to be usable for global end-to-end communication in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication. o EID prefixes are likely to be hierarchically assigned in a manner which is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The hierarchy is based on a address allocation hierarchy which is not dependent on the network topology. o EIDs may also be structured (subnetted) in a manner suitable for local routing within an autonomous system. An additional LISP header may be prepended to packets by a transit router (i.e. TE-ITR) when re-routing of the path for a packet is desired. An obvious instance of this would be an ISP router that needs to perform traffic engineering for packets flowing through its network. In such a situation, termed Recursive Tunneling, an ISP transit acts as an additional ingress tunnel router and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). This specification mandates that no more than two LISP headers get prepended to a packet. This avoids excessive packet overhead as well as possible encapsulation loops. It is believed two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the egress tunnel router might be the last-hop router directly-connected to the destination host. Another example, perhaps for a VPN service out-sourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other tunnel routers is allowed for maximum flexibility. See Section 8 for more details. Farinacci, et al. Expires October 17, 2010 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow with the following conditions: o Source host "host1.abc.com" is sending a packet to "host2.xyz.com", exactly what host1 would do if the site was not using LISP. o Each site is multi-homed, so each tunnel router has an address (RLOC) assigned from the service provider address block for each provider to which that particular tunnel router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in LISP site. o Map-Requests or Data Probes can be sent on the underlying routing system topology (LISP 1.0) or over an alternative topology (LISP 1.5) [ALT]. o Map-Replies are sent on the underlying routing system topology. Client host1.abc.com wants to communicate with server host2.xyz.com: 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. It does a DNS lookup on host2.xyz.com. An A/AAAA record is returned. This address is the destination EID. The locally- assigned address of host1.abc.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the EID destination to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [ALT] or [CONS] for possible solutions. 3. The ITR will either send a LISP Data-Probe or a LISP Map-Request. If the ITR sends a Data-Probe all data packets from the source are encapsulated until a Map-Reply is received. If the ITR sends a Map-Request, data packets are either queued or dropped until a Map-Reply is received. Map-Requests MAY be rate-limited. 4. In LISP 1.0, the Data-Probe or Map-Request packet is routed through the underlying routing system. In LISP 1.5, the Data- Probe or Map-Request packet is routed on an alternate logical topology. In either case, when the Probe/Request arrives at one of the ETRs at the destination site, it will process the packet Farinacci, et al. Expires October 17, 2010 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 as a control message. 5. The ETR looks at the destination EID of either the Data-Probe or Map-Request and matches it against the prefixes in the ETR's configured EID-to-RLOC mapping database. This is the list of EID-prefixes the ETR is supporting for the site it resides in. If there is no match, the packet is dropped. Otherwise, if the packet is a Data-Probe the LISP header is stripped and the data packet forwarded to the destination host. In either the Data- Probe or Map-Request case, a LISP Map-Reply is returned to the ITR. 6. The ITR receives the Map-Reply message, parses the message (to check for format validity) and stores the mapping information from the packet. This information is put in the ITR's EID-to- RLOC mapping cache (this is the on-demand cache, the cache where entries time out due to inactivity). 7. Subsequent packets from host1.abc.com to host2.xyz.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note, the packet may be sent to a different ETR than the one which returned the Map-Reply due to the source site's hashing policy or the destination site's locator-set policy. 8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), strips the LISP header and forwards the packets to the attached destination host. In order to eliminate the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner header source IP address) to the source RLOC (outer header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both ITR and the ETR may also influence the decision the other makes in selecting an RLOC. See Section 6 for more details. Farinacci, et al. Expires October 17, 2010 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 5. Tunneling Details This section describes the LISP Data Message which defines the tunneling header used to encapsulate IPv4 and IPv6 packets which contain EID addresses. Even though the following formats illustrate IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2 combinations are supported as well. Since additional tunnel headers are prepended, the packet becomes larger and in theory can exceed the MTU of any link traversed from the ITR to the ETR. It is recommended, in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source. Based on informal surveys of large ISP traffic patterns, it appears that most transit paths can accommodate a path MTU of at least 4470 bytes. The exceptions, in terms of data rate, number of hosts affected, or any other metric are expected to be vanishingly small. To address MTU concerns, mainly raised on the RRG mailing list, the LISP deployment process will include collecting data during its pilot phase to either verify or refute the assumption about minimum available MTU. If the assumption proves true and transit networks with links limited to 1500 byte MTUs are corner cases, it would seem more cost-effective to either upgrade or modify the equipment in those transit networks to support larger MTUs or to use existing mechanisms for accommodating packets that are too large. For this reason, there is currently no plan for LISP to add any new additional, complex mechanism for implementing fragmentation and reassembly in the face of limited-MTU transit links. If analysis during LISP pilot deployment reveals that the assumption of essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect, then LISP can be modified prior to protocol standardization to add support for one of the proposed fragmentation and reassembly schemes. Note that two simple existing schemes are detailed in Section 5.4. Farinacci, et al. Expires October 17, 2010 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 5.1. LISP IPv4-in-IPv4 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires October 17, 2010 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 5.2. LISP IPv6-in-IPv6 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload Length | Next Header=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | Farinacci, et al. Expires October 17, 2010 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer Header: is the outer header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to- RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used. UDP Header: contains a ITR selected source port when encapsulating a packet. See Section 6.4 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA assigned port value 4341. UDP Checksum: this field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. UDP Length: for an IPv4 encapsulated packet, the inner header Total Length plus the UDP and LISP header lengths are used. For an IPv6 encapsulated packet, the inner header Payload Length plus the size of the IPv6 header (40 bytes) plus the size of the UDP and LISP Farinacci, et al. Expires October 17, 2010 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 headers are used. The UDP header length is 8 bytes. N: this is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See Section 6.3.1 for details. Both N and V bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the "Nonce/Map-Version" field as having a Nonce value present. L: this is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: this is the echo-nonce-request bit. When this bit is set to 1, the N bit MUST be 1. This bit SHOULD be ignored and has no meaning when the N bit is set to 0. See Section 6.3.1 for details. V: this is the Map-Version present bit. When this bit is set to 1, the N bit MUST be 0. Refer to Section 6.5.3 for more details. This bit indicates that the first 4 bytes of the LISP header is encoded as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: this is the Instance ID bit. See Section 5.5 for more details. When this bit is set to 1, the Locator Status Bits field is reduced to 8-bits and the high-order 24-bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the last 4 bytes of the LISP header would look like: Farinacci, et al. Expires October 17, 2010 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags: this 3-bit field is reserved for future flag use. It is set to 0 on transmit and ignored on receipt. LISP Nonce: is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 6.3.1 for more details. LISP Locator Status Bits: in the LISP header are set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least significant bit of field. The field is 32-bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator Status Bit is set to 1, the ITR is indicating to the ETR the RLOC associated with the bit ordinal has up status. See Section 6.3 for details on how an ITR can determine the status of other ITRs at the same site. When a site has multiple EID-prefixes which result in multiple mappings (where each could have a different locator-set), the Locator Status Bits setting in an encapsulated packet MUST reflect the mapping for the EID-prefix that the inner- header source EID address matches. When doing Recursive Tunneling or ITR/PTR encapsulation: o The outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). When doing Re-encapsulated Tunneling: Farinacci, et al. Expires October 17, 2010 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 o The new outer header Time to Live field SHOULD be copied from the stripped outer header Time to Live field. o The new outer header Type of Service field SHOULD be copied from the stripped OH header Type of Service field (with one caveat, see below). Copying the TTL serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service field and the IPv6 Traffic Class field [RFC3168]. The ECN field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit ECN field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit ECN field from the stripped outer header to the new outer header. If the ECN field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve Congestion Experienced (CE) indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. 5.4. Dealing with Large Encapsulated Packets In the event that the MTU issues mentioned above prove to be more serious than expected, this section proposes 2 simple mechanisms to deal with large packets. One is stateless using IP fragmentation and the other is stateful using Path MTU Discovery [RFC1191]. It is left to the implementor to decide if the stateless or stateful mechanism SHOULD be implemented. Both or neither can be decided as well since it is a local decision in the ITR regarding how to deal with MTU issues. Sites can interoperate with differing mechanisms. Both stateless and stateful mechanisms also apply to Reencapsulating and Recursive Tunneling. So any actions below referring to an ITR also apply to an TE-ITR. 5.4.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: Farinacci, et al. Expires October 17, 2010 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 1. Define an architectural constant S for the maximum size of a packet, in bytes, an ITR would receive from a source inside of its site. 2. Define L to be the maximum size, in bytes, a packet of size S would be after the ITR prepends the LISP header, UDP header, and outer network layer header of size H. 3. Calculate: S + H =3D L. When an ITR receives a packet from a site-facing interface and adds H bytes worth of encapsulation to yield a packet size greater than L bytes, it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. This will ensure that the new, encapsulated packets are of size (S/2 + H), which is always below the effective tunnel MTU. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. This behavior is performed by the ITR when the source host originates a packet with the DF field of the IP header is set to 0. When the DF field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L, and sends an ICMP Too Big message to the source with a value of S, where S is (L - H). When the outer header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification recommends that L be defined as 1500. 5.4.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each locator per mapping cache entry. The effective MTU is what the core network can deliver along the path between ITR and ETR. Farinacci, et al. Expires October 17, 2010 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Too Big message to the ITR. The ITR will parse the ICMP message to determine which locator is affected by the effective MTU change and then record the new effective MTU value in the mapping cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the mapping cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Too Big message back to the source. The packet size advertised by the ITR in the ICMP Too Big message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 5.5. Using Virtualization and Segmentation with LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces MUST remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. See [LCAF] for details on address encodings. An Instance ID can be carried in a LISP encapsulated packet. An ITR that prepends a LISP header, will copy a 24-bit value, used by the LISP router to uniquely identify the address space. The value is copied to the Instance ID field of the LISP header and the I-bit is set to 1. When an ETR decapsulate a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. Some examples of the 24-bit value to copy or map into the Instance ID field could be a 802.1Q VLAN tag or a configured VRF-ID value. Farinacci, et al. Expires October 17, 2010 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6. EID-to-RLOC Mapping 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats The following new UDP packet types are used to retrieve EID-to-RLOC mappings: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol =3D 17 | Header Checksum = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + Farinacci, et al. Expires October 17, 2010 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 | | + Destination Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. The UDP Length field will reflect the length of the UDP header and the LISP Message payload. The UDP Checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register and ECM control messages. It MUST be checked on receipt and if the checksum fails, the packet MUST be dropped. LISP-CONS [CONS] use TCP to send LISP control messages. The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries. This main LISP specification is the authoritative source for message format definitions for the Map-Request and Map-Reply messages. Farinacci, et al. Expires October 17, 2010 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6.1.1. LISP Packet Type Allocations This section will be the authoritative source for allocating LISP Type values. Current allocations are: Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Encapsulated Control Message: 8 b'1000' 6.1.2. Map-Request Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D1 |A|M|P|S| Reserved | IRC | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-EID-AFI | Source EID Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI n | ITR-RLOC Address n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Reserved | EID mask-len | EID-prefix-AFI | Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | EID-prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Map-Reply Record ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Farinacci, et al. Expires October 17, 2010 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Type: 1 (Map-Request) A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. M: When set, it indicates a Map-Reply Record segment is included in the Map-Request. P: This is the probe-bit which indicates that a Map-Request SHOULD be treated as a locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating the Map-Reply is a locator reachability probe reply, with the nonce copied from the Map-Request. See Section 6.3.2 for more details. S: This is the SMR bit. See Section 6.5.2 for details. Reserved: Set to 0 on transmission and ignored on receipt. IRC: This 5-bit field is the ITR-RLOC Count which encodes the number of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this message. Multiple ITR-RLOC Address fields are used so a Map- Replier can select which destination address to use for a Map- Reply. The IRC value ranges from 0 to 31, where IRC value 0 means an ITR-RLOC address count of 1, an IRC value of 1 means an ITR- RLOC address count of 2, and so on up to an IRC value of 31, which means an ITR-RLOC address count of 32. Record Count: The number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. Source-EID-AFI: Address family of the "Source EID Address" field. Farinacci, et al. Expires October 17, 2010 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Source EID Address: This is the EID of the source host which originated the packet which is invoking this Map-Request. When Map-Requests are used for refreshing a map-cache entry or for RLOC-probing, the value 0 is used. ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that follows this field. ITR-RLOC Address: Used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address. EID mask-len: Mask length for EID prefix. EID-prefix-AFI: Address family of EID-prefix according to [RFC5226] EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-prefix is set to the destination IP address of the data packet. And the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID- prefix used in the Map-Request has the same mask-length as the EID-prefix returned from the site when it sent a Map-Reply message. Map-Reply Record: When the M bit is set, this field is the size of the "Record" field in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the Source EID. This allows the ETR which will receive this Map-Request to cache the data if it chooses to do so. Mapping Protocol Data: See [CONS] or [ALT] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. 6.1.3. EID-to-RLOC UDP Map-Request Message A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map-Request is the destination-EID from the packet which had a mapping cache lookup failure. For the latter 2 cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the locator-set of the map cache entry. The source address is either an IPv4 or IPv6 RLOC address depending if the Map-Request is using an IPv4 versus IPv6 header, respectively. Farinacci, et al. Expires October 17, 2010 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 In all cases, the UDP source port number for the Map-Request message is a randomly allocated 16-bit value and the UDP destination port number is set to the well-known destination port number 4342. A successful Map-Reply updates the cached set of RLOCs associated with the EID prefix range. One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST be placed in the IRC field. The ITR MAY include all locally configured locators in this list or just provide one locator address from each address family it supports. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- Request. Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on encapsulated Map-Requests and Map-Resolvers can be found in [LISP-MS]. Map-Requests MUST be rate-limited. It is recommended that a Map- Request for the same EID-prefix be sent no more than once per second. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the map-cache, it may originate a "verifying Map-Request", addressed to the map-requesting ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map- Request" directly to the originating Map-Request source. If the RLOC is not in the locator-set, then the ETR MUST send the "verifying Map- Request" to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" mapping data. Farinacci, et al. Expires October 17, 2010 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6.1.4. Map-Reply Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D2 |P|E| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 2 (Map-Reply) P: This is the probe-bit which indicates that the Map-Reply is in response to a locator reachability probe Map-Request. The nonce field MUST contain a copy of the nonce value from the original Map-Request. See Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce locator reachability algorithm. See Section 6.3.1 for more details. Reserved: Set to 0 on transmission and ignored on receipt. Farinacci, et al. Expires October 17, 2010 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Record Count: The number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of the Map- Reply. Record TTL: The time in minutes the recipient of the Map-Reply will store the mapping. If the TTL is 0, the entry SHOULD be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping. Locator Count: The number of Locator entries. A locator entry comprises what is labeled above as 'Loc'. The locator count can be 0 indicating there are no locators for the EID-prefix. EID mask-len: Mask length for EID prefix. ACT: This 3-bit field describes negative Map-Reply actions. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. The actions defined are used by an ITR or PTR when a destination EID matches a negative mapping cache entry. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned values are: (0) Drop: The packet is dropped silently. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. A: The Authoritative bit, when sent by a UDP-based message is always set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-prefix. Map-Version Number: When this 12-bit value is non-zero the Map-Reply sender is informing the ITR what the version number is for the EID-record contained in the Map-Reply. The ETR can allocate this number internally but MUST coordinate this value with other ETRs Farinacci, et al. Expires October 17, 2010 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 for the site. When this value is 0, there is no versioning information conveyed. The Map-Version Number can be included in Map-Request and Map-Register messages. See Section 6.5.3 for more details. EID-AFI: Address family of EID-prefix according to [RFC5226]. EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. Priority: each RLOC is assigned a unicast priority. Lower values are more preferable. When multiple RLOCs have the same priority, they may be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding. Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance unicast traffic between them. Weight is encoded as a percentage of total unicast packets that match the mapping entry. If a non-zero weight value is used for any RLOC, then all RLOCs MUST use a non-zero weight value and then the sum of all weight values MUST equal 100. If a zero value is used for any RLOC weight, then all weights MUST be zero and the receiver of the Map-Reply will decide how to load-split traffic. See Section 6.4 for a suggested hash algorithm to distribute load across locators with same priority and equal weight values. When a single RLOC exists in a mapping entry, the weight value MUST be set to 100 and ignored on receipt. M Priority: each RLOC is assigned a multicast priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. M Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance building multicast distribution trees across multiple ITRs. The weight is encoded as a percentage of total number of trees build to the source site identified by the EID-prefix. If a non-zero weight value is used for any RLOC, then all RLOCs MUST use a non-zero weight value and then the sum of all weight values MUST equal 100. If a zero value is used for any RLOC weight, then all weights MUST be zero and the receiver of the Map-Reply will decide how to distribute multicast state across ITRs. Farinacci, et al. Expires October 17, 2010 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Unused Flags: set to 0 when sending and ignored on receipt. L: when this bit is set, the locator is flagged as a local locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to 0 for all locators in this locator-set. p: when this bit is set, an ETR informs the RLOC-probing ITR that the locator address, for which this bit is set, is the one being RLOC- probed and may be different from the source address of the Map- Reply. An ITR that RLOC-probes a particular locator, MUST use this locator for retrieving the data structure used to store the fact that the locator is reachable. The "p" bit is set for a single locator in the same locator set. If an implementation sets more than one "p" bit erroneously, the receiver of the Map-Reply MUST select the first locator. The "p" bit MUST NOT be set for locator-set records sent in Map-Request and Map-Register messages. R: when this bit is set, the locator is known to be reachable from the Map-Reply sender's perspective. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR or router acting as a proxy replier for the EID-prefix. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router), and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID. Mapping Protocol Data: See [CONS] or [ALT] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. 6.1.5. EID-to-RLOC UDP Map-Reply Message When a Data Probe packet or a Map-Request triggers a Map-Reply to be sent, the RLOCs associated with the EID-prefix matched by the EID in the original packet destination IP address field will be returned. The RLOCs in the Map-Reply are the globally-routable IP addresses of the ETR but are not necessarily reachable; separate testing of reachability is required. Note that a Map-Reply may contain different EID-prefix granularity (prefix + length) than the Map-Request which triggers it. This might occur if a Map-Request were for a prefix that had been returned by an Farinacci, et al. Expires October 17, 2010 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-prefixes that are covered by a Map- Reply containing one, less-specific prefix, replaces the entry with the less-specific EID-prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur but not by removing the less-specific prefix rather by adding the more-specific prefixes which during a lookup will override the less-specific prefix. When an ETR is configured with overlapping EID-prefixes, a Map- Request with an EID that longest matches any EID-prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-prefixes: 10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24 A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-prefix of 10.1.1.0/24. A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. Note that not all overlapping EID-prefixes need to be returned, only the more specifics (note in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) entries for the matching EID-prefix of the requesting EID. When more than one EID-prefix is returned, all SHOULD use the same Time-to-Live value so they can all time out at the same time. When a more specific EID-prefix is received later, its Time-to-Live value in the Map-Reply record can be stored even when other less specifics exist. When a a less specific EID-prefix is received later, its map-cache expiration time SHOULD be set to the minimum expiration time of any more specific EID-prefix in the map-cache. Map-Replies SHOULD be sent for an EID-prefix no more often than once per second to the same requesting router. For scalability, it is expected that aggregation of EID addresses into EID-prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range thereby reducing the number of Map-Request messages. Map-Reply records can have an empty locator-set. This type of a Map- Reply is called a Negative Map-Reply. Negative Map-Replies convey Farinacci, et al. Expires October 17, 2010 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 special actions by the sender to the ITR or PTR which have solicited the Map-Reply. There are two primary applications for Negative Map- Replies. The first is for a Map-Resolver to instruct an ITR or PTR when a destination is for a LISP site versus a non-LISP site. And the other is to source quench Map-Requests which are sent for non- allocated EIDs. For each Map-Reply record, the list of locators in a locator-set MUST appear in the same order for each ETR that originates a Map-Reply message. The locator-set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address. When sending a Map-Reply message, the destination address is copied from the one of the ITR-RLOC fields from the Map-Request. The ETR can choose a locator address from one of the address families it supports. For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local locator addresses listed in the locator-set of any mapping record in the message and SHOULD be chosen to allow uRPF checks to succeed in the upstream service provider. The destination port of a Map-Reply message is copied from the source port of the Map-Request or Data-Probe and the source port of the Map-Reply message is set to the well-known UDP port 4342. 6.1.5.1. Traffic Redirection with Coarse EID-Prefixes When an ETR is misconfigured or compromised, it could return coarse EID-prefixes in Map-Reply messages it sends. The EID-prefix could cover EID-prefixes which are allocated to other sites redirecting their traffic to the locators of the compromised site. To solve this problem, there are two basic solutions that could be used. The first is to have Map-Servers proxy-map-reply on behalf of ETRs so their registered EID-prefixes are the ones returned in Map- Replies. Since the interaction between an ETR and Map-Server is secured with shared-keys, it is more difficult for an ETR to misbehave. The second solution is to have ITRs and PTRs cache EID- prefixes with mask-lengths that are greater than or equal to a configured prefix length. This limits the damage to a specific width of any EID-prefix advertised, but needs to be coordinated with the allocation of site prefixes. These solutions can be used independently or at the same time. At the time of this writing, other approaches are being considered and researched. Farinacci, et al. Expires October 17, 2010 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6.1.6. Map-Register Message Format The usage details of the Map-Register message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. The Map-Register message format is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D3 |P| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Farinacci, et al. Expires October 17, 2010 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Type: 3 (Map-Register) P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map- Register message requesting for the Map-Server to proxy Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR. Details on this usage will be provided in a future version of this draft. Reserved: Set to 0 on transmission and ignored on receipt. Record Count: The number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] is recommended. The definition of the rest of the Map-Register can be found in the Map-Reply section. However, the record TTL field is not used and set to 0. 6.1.7. Encapsulated Control Message Format An Encapsulated Control Message is used to encapsulate control packets sent between xTRs and the mapping database system described in [LISP-MS]. Farinacci, et al. Expires October 17, 2010 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 | Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is randomly assigned and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum Farinacci, et al. Expires October 17, 2010 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 field MUST be non-zero. LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages and PIM Join-Prune messages [MLISP] are allowed to be encapsulated. Encapsulating other types of LISP control messages are for further study. When Map-Requests are sent for RLOC-probing purposes (i.e the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. 6.2. Routing Locator Selection Both client-side and server-side may need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply messages. Alternatively, RLOC information may be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following enumerates different scenarios for choosing RLOCs and the controls that are available: o Server-side returns one RLOC. Client-side can only use one RLOC. Server-side has complete control of the selection. o Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o Server-side sets weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs are unreachable. o Either side (more likely on the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the Farinacci, et al. Expires October 17, 2010 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 client-side ITR RLOC is done by caching the inner header source EID and the outer header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server- side ETR MUST assume each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-prefix encoding cannot be conveyed in data packets, the EID-to-RLOC cache on tunnel routers can grow to be very large. o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. Neither the information contained in a Map-Reply or that stored in the mapping database system provide reachability information for RLOCs. Such reachability needs to be determined separately, using one or more of the Routing Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that Farinacci, et al. Expires October 17, 2010 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated Farinacci, et al. Expires October 17, 2010 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the Loc-Status-Bit that corresponds to that locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-prefix. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. When ITRs receive ICMP Network or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators which are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Unreachable messages. If an ITR does receive an ICMP Network or Host Unreachable message, it MAY originate its own ICMP Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if a locator address from a locator-set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default Free Zone (DFZ), it can decide to not use the locator even though the Loc-Status-Bits indicate the locator is up. In this case, the path from the ITR to the ETR that is assigned the locator is not available. More details are in [LOC-ID-ARCH]. Optionally, an ITR can send a Map-Request to a Locator and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by tunnel routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When an Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with priority 255. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In Farinacci, et al. Expires October 17, 2010 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 most cases, the ETR can also reach the ITR but cannot assume this to be true due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanisms to determine reachability. 6.3.1. Echo Nonce Algorithm When data flows bidirectionally between locators from different sites, a simple mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N and E bits and places a 24-bit nonce in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N bit set and E bit cleared. The ITR sees this "echoed nonce" and knows the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in echo-nonce-request state, then the path to the ETR is unreachable. This decision may be overridden by other locator reachability algorithms. Once the ITR determines the path to the ETR is down it can switch to another locator for that EID-prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR may both go into echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation specific setting. However, when an ITR is in echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and then subsequently, continue sending echo-nonce-request packets. This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional. That is, the ETR receiving traffic at a site may not be the same device as an ITR which transmits traffic from that site or the site to site traffic is unidirectional so there is no ITR returning traffic. Farinacci, et al. Expires October 17, 2010 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may regard the locator unreachable erroneously. An ITR SHOULD only set the E-bit in a encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the Map- Reply message. Note that other locator reachability mechanisms are being researched and can be used to compliment or even override the Echo Nonce Algorithm. See next section for an example of control-plane probing. 6.3.2. RLOC Probing Algorithm RLOC Probing is a method that an ITR or PTR can use to determine the reachability status of one or more locators that it has cached in a map-cache entry. The probe-bit of the Map-Request and Map-Reply messages are used for RLOC Probing. RLOC probing is done in the control-plane on a timer basis where an ITR or PTR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the ALT like one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-prefix of the map-cache entry cached by the ITR or PTR. The ITR or PTR may include a mapping data record for its own database mapping information. When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set from the destination address of the Map-Request and the destination address of the Map-Reply is set from the source address of the Map-Request. The Map-Reply SHOULD contain mapping data for the EID-prefix contained in the Map-Request. This provides the opportunity for the ITR or PTR, which sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC Probing. The greatest benefit of RLOC Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another locator from the cached locator. RLOC Probing can also provide RTT estimates between a pair of locators which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the Farinacci, et al. Expires October 17, 2010 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 requirement for failure detection times are very small. Continued research and testing will attempt to characterize the tradeoffs of failure detection times versus message overhead. 6.4. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to a requesting ITR, the locator-set for the EID-prefix may contain different priority values for each locator address. When more than one best priority locator exists, the ITR can decide how to load share traffic against the corresponding locators. The following hash algorithm may be used by an ITR to select a locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash can be used or the traditional 5-tuple hash which includes the source and destination addresses, source and destination TCP, UDP, or SCTP port numbers and the IP protocol number field or IPv6 next- protocol fields of a packet a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of locators stored in the locator-set for the EID-to-RLOC mapping. 3. The remainder will be yield a value of 0 to "number of locators minus 1". Use the remainder to select the locator in the locator-set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a random value allows core routers which are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets which are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. Farinacci, et al. Expires October 17, 2010 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 6.5. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change and the ETRs do not keep track of who requested its mappings. For scalability reasons, we want to maintain this approach but need to provide a way for ETRs change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. When a locator record is added to the end of a locator-set, it is easy to update mappings. We assume new mappings will maintain the same locator ordering as the old mapping but just have new locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the loc-status-bits that correspond to locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing locator-set. When a locator record is removed from a locator-set, ITRs that have the mapping cached will not use the removed locator because the xTRs will set the loc-status-bit to 0. So even if the locator is in the list, it will not be used. For new mapping requests, the xTRs can set the locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding loc-status-bit to 0. This forces ITRs with old or new mappings to avoid using the removed locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the locator-set and new records appended to the locator-set. At some point, it would be useful to compact the locator-set so the loc-status-bit settings can be efficiently packed. We propose here three approaches for locator-set compaction, one operational and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning. 6.5.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So there is a 24 hour window to time out old mappings. The following clock sweep procedure is used: Farinacci, et al. Expires October 17, 2010 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window. 2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour. 3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1 hour window the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. 4. At the end of the 1 hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. 6.5.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for xTRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the xTRs don't keep track of remote ITRs that have cached their mappings, they can not tell exactly who needs the new mapping entries. So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites. The xTRs can locally decide the algorithm for how often and to how many sites it sends SMR messages. An SMR message is simply a bit set in a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limited these messages. The following procedure shows how a SMR exchange occurs when a site is doing locator-set compaction for an EID-to-RLOC mapping: 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote xTR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message. A newly allocated random nonce is selected and the EID- Farinacci, et al. Expires October 17, 2010 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 prefix used is the one copied from the SMR message. 3. The remote xTR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message provided the Map-Request nonce matches the nonce from the SMR. The Map-Reply messages SHOULD be rate limited. This is important to avoid Map-Reply implosion. 5. The ETRs, at the site with the changed mapping, record the fact that the site that sent the Map-Request has received the new mapping data in the mapping cache entry for the remote site so the loc-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. For security reasons an ITR MUST NOT process unsolicited Map-Replies. The nonce MUST be carried from SMR packet, into the resultant Map- Request, and then into Map-Reply to reduce spoofing attacks. To avoid map-cache entry corruption by a third-party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR- based Map-Request and the source is not in the locator-set for the stored map-cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. 6.5.3. Database Map Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation can stop to a removed locator and start to a new locator in the locator-set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 6.5.2 occurs. An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version number. This is known as the Source Map-Version Number. Farinacci, et al. Expires October 17, 2010 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 When an ETR decapsulates a packet and detects the Source Map-Version Number is greater than the last Map-Version Number sent in a Map- Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-prefix. So values that are greater, are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information and an xTR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server can assure that all ETRs for a site registering to it will be Map-Version number synchronized. See [VERSIONING] for a more detailed analysis and description of Database Map Versioning. Farinacci, et al. Expires October 17, 2010 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 7. Router Performance Considerations LISP is designed to be very hardware-based forwarding friendly. By doing tunnel header prepending [RFC1955] and stripping instead of re- writing addresses, existing hardware can support the forwarding model with little or no modification. Where modifications are required, they should be limited to re-programming existing hardware rather than requiring expensive design changes to hard-coded algorithms in silicon. A few implementation techniques can be used to incrementally implement LISP: o When a tunnel encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special FIB entries for the EID-prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing should be performed. The forwarding logic of testing for particular IP protocol number value is not necessary. No changes to existing, deployed hardware should be needed to support this. o On an ITR, prepending a new IP header is as simple as adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Many routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already support this action. o When a received packet's outer destination address contains an EID which is not intended to be forwarded on the routable topology (i.e. LISP 1.5), the source address of a data packet or the router interface with which the source is associated (the interface from which it was received) can be associated with a VRF (Virtual Routing/Forwarding), in which a different (i.e. non- congruent) topology can be used to find EID-to-RLOC mappings. Farinacci, et al. Expires October 17, 2010 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8. Deployment Scenarios This section will explore how and where ITRs and ETRs can be deployed and will discuss the pros and cons of each deployment scenario. There are two basic deployment trade-offs to consider: centralized versus distributed caches and flat, recursive, or re-encapsulating tunneling. When deciding on centralized versus distributed caching, the following issues should be considered: o Are the tunnel routers spread out so that the caches are spread across all the memories of each router? o Should management "touch points" be minimized by choosing few tunnel routers, just enough for redundancy? o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, more ETRs does require more management since EID-prefix-to-RLOC mappings need to be explicitly configured. When deciding on flat, recursive, or re-encapsulation tunneling, the following issues should be considered: o Flat tunneling implements a single tunnel between source site and destination site. This generally offers better paths between sources and destinations with a single tunnel path. o Recursive tunneling is when tunneled traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control since the site is prepending a new tunnel header. In the case of TE-based tunneling, the site may have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. o The technique of re-encapsulation ensures that packets only require one tunnel header. So if a packet needs to be rerouted, it is first decapsulated by the ETR and then re-encapsulated with a new tunnel header using a new RLOC. The next sub-sections will describe where tunnel routers can reside in the network. Farinacci, et al. Expires October 17, 2010 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8.1. First-hop/Last-hop Tunnel Routers By locating tunnel routers close to hosts, the EID-prefix set is at the granularity of an IP subnet. So at the expense of more EID- prefix-to-RLOC sets for the site, the caches in each tunnel router can remain relatively small. But caches always depend on the number of non-aggregated EID destination flows active through these tunnel routers. With more tunnel routers doing encapsulation, the increase in control traffic grows as well: since the EID-granularity is greater, more Map-Requests and Map-Replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios then their core router counterparts. Memory is typically less expensive in these devices and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing state. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices as well. 8.2. Border/Edge Tunnel Routers Using customer-edge (CE) routers for tunnel endpoints allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE routers for that site. This offers the opposite benefit of the first-hop/last-hop tunnel router scenario: the number of mapping entries and network management touch points are reduced, allowing better scaling. One disadvantage is that less of the network's resources are used to reach host endpoints thereby centralizing the point-of-failure domain and creating network choke points at the CE router. Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Farinacci, et al. Expires October 17, 2010 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8.3. ISP Provider-Edge (PE) Tunnel Routers Use of ISP PE routers as tunnel endpoint routers gives an ISP control over the location of the egress tunnel endpoints. That is, the ISP can decide if the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. The advantage of this case is that two or more tunnel headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. An obvious disadvantage is that the end site has no control over where its packets flow or the RLOCs used. As mentioned in earlier sections a combination of these scenarios is possible at the expense of extra packet header overhead, if both site and provider want control, then recursive or re-encapsulating tunnels are used. 8.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator address in any LISP control message MUST be a globally routable address and therefore SHOULD NOT contain [RFC1918] addresses. If a LISP router is configured with private addresses, they MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed. Both NAT translation and LISP encapsulation functions could be co-located in the same device. More details on LISP address translation can be found in [INTERWORK]. Farinacci, et al. Expires October 17, 2010 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 9. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from ITR to ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: Segment 1 (in source LISP site based on EIDs): source-host ---> first-hop ... next-hop ---> ITR Segment 2 (in the core network based on RLOCs): ITR ---> next-hop ... next-hop ---> ETR Segment 3 (in the destination LISP site based on EIDs): ETR ---> next-hop ... last-hop ---> destination-host For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal matter as they are today. The ITR performs a TTL decrement and test for 0 before encapsulating. So the ITR hop is seen by the traceroute source has an EID address (the address of site-facing interface). For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destination of the ICMP messages are to the ITR RLOC address, the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client as well as retaining the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0 like the previous core routers did. For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be Farinacci, et al. Expires October 17, 2010 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host. 9.1. IPv6 Traceroute IPv6 traceroute follows the procedure described above since the entire traceroute data packet is included in ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention for forwarding ICMP messages back to the traceroute source. 9.2. IPv4 Traceroute For IPv4 traceroute, we cannot follow the above procedure since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 bytes that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source is lost. The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination). 9.3. Traceroute using Mixed Locators When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, you cannot get all 3 segments of the traceroute. Segment 2 of the traceroute can not be conveyed to the traceroute source since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, Farinacci, et al. Expires October 17, 2010 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. Farinacci, et al. Expires October 17, 2010 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 10. Mobility Considerations There are several kinds of mobility of which only some might be of concern to LISP. Essentially they are as follows. 10.1. Site Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-RLOC mappings for sites are expected to be handled by configuration, outside of the LISP protocol. 10.2. Slow Endpoint Mobility An individual endpoint wishes to move, but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs. [RFC4984] 10.3. Fast Endpoint Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, and primarily where interactions with LISP need to be explored. The problem is that as an endpoint moves, it may require changes to the mapping between its EID and a set of RLOCs for its new network location. When this is added to the overhead of mobile IP binding updates, some packets might be delayed or dropped. In IPv4 mobility, when an endpoint is away from home, packets to it are encapsulated and forwarded via a home agent which resides in the home area the endpoint's address belongs to. The home agent will encapsulate and forward packets either directly to the endpoint or to a foreign agent which resides where the endpoint has moved to. Packets from the endpoint may be sent directly to the correspondent node, may be sent via the foreign agent, or may be reverse-tunneled back to the home agent for delivery to the mobile node. As the mobile node's EID or available RLOC changes, LISP EID-to-RLOC mappings are required for communication between the mobile node and the home agent, whether via foreign agent or not. As a mobile endpoint changes networks, up to three LISP mapping changes may be required: Farinacci, et al. Expires October 17, 2010 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 o The mobile node moves from an old location to a new visited network location and notifies its home agent that it has done so. The Mobile IPv4 control packets the mobile node sends pass through one of the new visited network's ITRs, which needs a EID-RLOC mapping for the home agent. o The home agent might not have the EID-RLOC mappings for the mobile node's "care-of" address or its foreign agent in the new visited network, in which case it will need to acquire them. o When packets are sent directly to the correspondent node, it may be that no traffic has been sent from the new visited network to the correspondent node's network, and the new visited network's ITR will need to obtain an EID-RLOC mapping for the correspondent node's site. In addition, if the IPv4 endpoint is sending packets from the new visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-RLOC mapping for that EID. In IPv6 mobility, packets can flow directly between the mobile node and the correspondent node in either direction. The mobile node uses its "care-of" address (EID). In this case, the route-returnability check would not be needed but one more LISP mapping lookup may be required instead: o As above, three mapping changes may be needed for the mobile node to communicate with its home agent and to send packets to the correspondent node. o In addition, another mapping will be needed in the correspondent node's ITR, in order for the correspondent node to send packets to the mobile node's "care-of" address (EID) at the new network location. When both endpoints are mobile the number of potential mapping lookups increases accordingly. As a mobile node moves there are not only mobility state changes in the mobile node, correspondent node, and home agent, but also state changes in the ITRs and ETRs for at least some EID-prefixes. The goal is to support rapid adaptation, with little delay or packet loss for the entire system. Heuristics can be added to LISP to reduce the number of mapping changes required and to reduce the delay per mapping change. Also IP mobility can be modified to require fewer mapping changes. In order to increase overall system Farinacci, et al. Expires October 17, 2010 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 performance, there may be a need to reduce the optimization of one area in order to place fewer demands on another. In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have a internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything which decreases the number of new EID- RLOC mappings needed when a node moves, or maintains the validity of an EID-RLOC mapping for a longer time, is useful. 10.4. Fast Network Mobility In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix. If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes. 10.5. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically-independent EID IP addresses that are not advertised into and do not impose a cost on the global routing Farinacci, et al. Expires October 17, 2010 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 system. These EIDs are maintained at the edges of the mapping system (in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. Refer to the LISP Mobility Architecture specification [LISP-MN] for more details. Farinacci, et al. Expires October 17, 2010 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 11. Multicast Considerations A multicast group address, as defined in the original Internet architecture is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determines where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, will use the same group address as the destination Routing Locator. Having said that, only the source EID and source Routing Locator needs to be dealt with. Therefore, an ITR merely needs to put its own IP address in the source Routing Locator field when prepending the outer IP header. This source Routing Locator address, like any other Routing Locator address MUST be globally routable. Therefore, an EID-to-RLOC mapping does not need to be performed by an ITR when a received data packet is a multicast data packet or when processing a source-specific Join (either by IGMPv3 or PIM). But the source Routing Locator is decided by the multicast routing protocol in a receiver site. That is, an EID to Routing Locator translation is done at control-time. Another approach is to have the ITR not encapsulate a multicast packet and allow the the host built packet to flow into the core even if the source address is allocated out of the EID namespace. If the RPF-Vector TLV [RFC5496] is used by PIM in the core, then core routers can RPF to the ITR (the Locator address which is injected into core routing) rather than the host source address (the EID address which is not injected into core routing). To avoid any EID-based multicast state in the network core, the first approach is chosen for LISP-Multicast. Details for LISP-Multicast and Interworking with non-LISP sites is described in specification [MLISP]. Farinacci, et al. Expires October 17, 2010 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 12. Security Considerations It is believed that most of the security mechanisms will be part of the mapping database service when using control plane procedures for obtaining EID-to-RLOC mappings. For data plane triggered mappings, as described in this specification, protection is provided against ETR spoofing by using Return- Routability mechanisms evidenced by the use of a 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. The nonce, coupled with the ITR accepting only solicited Map-Replies goes a long way toward providing decent authentication. LISP does not rely on a PKI infrastructure or a more heavy weight authentication system. These systems challenge the scalability of LISP which was a primary design goal. DoS attack prevention will depend on implementations rate-limiting Map-Requests and Map-Replies to the control plane as well as rate- limiting the number of data-triggered Map-Replies. To deal with map-cache exhaustion attempts in an ITR/PTR, the implementation should consider putting a maximum cap on the number of entries stored with a reserve list for special or frequently accessed sites. This should be a configuration policy control set by the network administrator who manages ITRs and PTRs. Farinacci, et al. Expires October 17, 2010 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 13. IANA Considerations Refer to LISP Canonical Address Format specification [LCAF] for IANA considerations. Farinacci, et al. Expires October 17, 2010 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 14. Prototype Plans and Status The operator community has requested that the IETF take a practical approach to solving the scaling problems associated with global routing state growth. This document offers a simple solution which is intended for use in a pilot program to gain experience in working on this problem. The authors hope that publishing this specification will allow the rapid implementation of multiple vendor prototypes and deployment on a small scale. Doing this will help the community: o Decide whether a new EID-to-RLOC mapping database infrastructure is needed or if a simple, UDP-based, data-triggered approach is flexible and robust enough. o Experiment with provider-independent assignment of EIDs while at the same time decreasing the size of DFZ routing tables through the use of topologically-aligned, provider-based RLOCs. o Determine whether multiple levels of tunneling can be used by ISPs to achieve their Traffic Engineering goals while simultaneously removing the more specific routes currently injected into the global routing system for this purpose. o Experiment with mobility to determine if both acceptable convergence and session continuity properties can be scalably implemented to support both individual device roaming and site service provider changes. Here is a rough set of milestones: 1. Interoperable implementations have been available since the beginning of 2009. 2. Continue pilot deployment using LISP-ALT as the database mapping mechanism. 3. Continue prototyping and studying other database lookup schemes, be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms. 4. Implement the LISP Multicast draft [MLISP]. 5. Implement the LISP Mobile Node draft [LISP-MN]. 6. Research more on how policy affects what gets returned in a Map- Reply from an ETR. Farinacci, et al. Expires October 17, 2010 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 7. Continue to experiment with mixed locator-sets to understand how LISP can help the IPv4 to IPv6 transition. 8. Add more robustness to locator reachability between LISP sites. 9. Continue the deployment of Proxy-ETRs (PETRs) for uses like uRPF avoidance, IPv6 connectivity, and LISP-MN. As of this writing the following accomplishments have been achieved: 1. A unit- and system-tested software switching implementation has been completed on cisco NX-OS for this draft for both IPv4 and IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators. 2. A unit- and system-tested software switching implementation on cisco NX-OS has been completed for draft [ALT]. 3. A unit- and system-tested software switching implementation on cisco NX-OS has been completed for draft [INTERWORK]. Support for IPv4 translation is provided and PTR support for IPv4 and IPv6 is provided. 4. The cisco NX-OS implementation supports an experimental mechanism for slow mobility. 5. There are 5 LISP implementations that exist and the first 4 below have gone through interoperability testing at IETF Hiroshima, based on the draft-ietf-lisp-05.txt spec: 1. cisco NX-OS 2. OpenLISP 3. LISP-Click 4. ZLisp 5. cisco IOS 6. Dave Meyer, Vince Fuller, Darrel Lewis, Gregg Schudel, Andrew Partan and the rest of the lisp-beta team continue to test all the features described above on a dual-stack infrastructure. 7. Darrel Lewis and Dave Meyer have deployed both LISP translation and LISP PTR support in the pilot network. Point your browser to http://www.lisp4.net to see translation happening in action so your non-LISP site can access a web server in a LISP site. Farinacci, et al. Expires October 17, 2010 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 8. Soon http://www.lisp6.net will work where your IPv6 LISP site can talk to a IPv6 web server in a LISP site by using mixed address-family based locators. 9. An public domain implementation of LISP is available. See [OPENLISP] for details. 10. We have deployed Map-Resolvers and Map-Servers on the LISP pilot network to gather experience with [LISP-MS]. The first layer of the architecture are the xTRs which use Map-Servers for EID- prefix registration and Map-Resolvers for EID-to-RLOC mapping resolution. The second layer are the Map-Resolvers and Map- Servers which connect to the ALT BGP peering infrastructure. And the third layer are ALT-routers which aggregate EID-prefixes and forward Map-Requests. 11. A cisco IOS implementation is available which currently supports IPv4 and IPv6 encapsulation and decapsulation features. 12. A LISP router based LIG implementation is supported, deployed, and used daily to debug and test the LISP pilot network. See [LIG] for details. 13. A Linux implementation of LIG has been made available and supported by Dave Meyer. It can be run on any Linux system which resides in either a LISP site or non-LISP site. See [LIG] for details. Public domain code can be downloaded from http://github.com/davidmeyer/lig/tree/master. 14. An experimental implementation has been written for three locator reachability algorithms. Two are the Echo-Noncing and RLOC-Probing algorithms which are documented in this specification. The third is called TCP-counts which will be documented in future drafts. 15. The LISP pilot network has been converted from using MD5 HMAC authentication for Map-Register messages to SHA-1 HMAC authentication. ETRs send with SHA-1 but Map-Servers can received from either for compatibility purposes. 16. The LISP pilot network is in its 3rd generation. Current experiments are being performed to test EID-prefix aggregation at multiple service boundaries as well as deploying models for the existence of multiple Mapping Service Providers (MSPs). If interested in writing a LISP implementation, testing any of the LISP implementations, or want to be part of the LISP pilot program, please contact lisp@ietf.org. Farinacci, et al. Expires October 17, 2010 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 15. References 15.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. Farinacci, et al. Expires October 17, 2010 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. 15.2. Informative References [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-04.txt (work in progress), April 2010. [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and L. Zhang, "APT: A Practical Transit Mapping Service", draft-jen-apt-01.txt (work in progress), November 2007. [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", Internet- Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-03.txt (work in progress), November 2007. Farinacci, et al. Expires October 17, 2010 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing Algorithms for DHTs: Some Open Questions", PDF file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", draft-curran-lisp-emacs-00.txt (work in progress), November 2007. [GSE] "GSE - An Alternate Addressing Architecture for IPv6", draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. [INTERWORK] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt (work in progress), March 2010. [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-farinacci-lisp-lcaf-01.txt (work in progress), April 2010. [LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-ietf-lisp-lig-00.txt (work in progress), April 2010. [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, "Renumbering: Threat or Menace?", Usenix , September 1996. [LISP-MAIN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-12.txt (work in progress), March 2009. [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP Mobility Architecture", draft-meyer-lisp-mn-00.txt (work in progress), July 2009. [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-05.txt (work in progress), April 2010. [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, "Locator/ID Separation Protocol (LISP1) [Routable ID Version]", Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, October 2006. [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, Farinacci, et al. Expires October 17, 2010 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 "Locator/ID Separation Protocol (LISP2) [DNS-based Version]", Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, November 2006. [LISPDHT] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt (work in progress), February 2008. [LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01.txt (work in progress), Januaryr 2009. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-ietf-lisp-multicast-03.txt (work in progress), April 2010. [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08.txt (work in progress), March 2010. [OPENLISP] Iannone, L. and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01.txt (work in progress), July 2008. [RADIR] Narten, T., "Routing and Addressing Problem Statement", draft-narten-radir-problem-statement-00.txt (work in progress), July 2007. [RFC3344bis] Perkins, C., "IP Mobility Support for IPv4, revised", draft-ietf-mip4-rfc3344bis-05 (work in progress), July 2007. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol for Routing Protocol Meta-data Dissemination", draft-handley-p2ppush-unpublished-2007726.txt (work in progress), July 2007. Farinacci, et al. Expires October 17, 2010 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 [VERSIONING] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Versioning", draft-iannone-lisp-mapping-versioning-01.txt (work in progress), March 2010. Farinacci, et al. Expires October 17, 2010 [Page 72] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed review of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussion and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, and Dhirendra Trivedi. In particular, we would like to thank Dave Meyer for his clever suggestion for the name "LISP". ;-) This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [LISP-MAIN] was converted into this IETF LISP working group draft. Farinacci, et al. Expires October 17, 2010 [Page 73] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-07.txt o Posted April 2010. o Added I-bit to data header so LSB field can also be used as an Instance ID field. When this occurs, the LSB field is reduced to 8-bits (from 32-bits). o Added V-bit to the data header so the 24-bit nonce field can also be used for source and destination version numbers. o Added Map-Version 12-bit value to the EID-record to be used in all of Map-Request, Map-Reply, and Map-Register messages. o Added multiple ITR-RLOC fields to the Map-Request packet so an ETR can decide what address to select for the destination of a Map- Reply. o Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to the Locator-Set record of an EID-record for a Map-Reply message. The L-bit indicates which RLOCs in the locator-set are local to the sender of the message. The P-bit indicates which RLOC is the source of a RLOC-probe Reply (Map-Reply) message. o Add reference to the LISP Canonical Address Format [LCAF] draft. o Made editorial and clarification changes based on comments from Dhirendra Trivedi. o Added wordsmithing comments from Joel Halpern on DF=3D1 setting. o Add John Zwiebel clarification to Echo Nonce Algorithm section 6.3.1. o Add John Zwiebel comment about expanding on proxy-map-reply bit for Map-Register messages. o Add NAT section per Ron Bonica comments. o Fix IDnits issues per Ron Bonica. o Added section on Virtualization and Segmentation to explain the use if the Instance ID field in the data header. o There are too many P-bits, keep their scope to the packet format description and refer to them by name every where else in the Farinacci, et al. Expires October 17, 2010 [Page 74] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 spec. o Scanned all occurrences of "should", "should not", "must" and "must not" and uppercased them. o John Zwiebel offered text for section 4.1 to modernize the example. Thanks Z! B.2. Changes to draft-ietf-lisp-06.txt Editorial based changes: o Posted December 2009. o Fix typo for flags in LISP data header. Changed from "4" to "5". o Add text to indicate that Map-Register messages must contain a computed UDP checksum. o Add definitions for PITR and PETR. o Indicate an AFI value of 0 is an unspecified address. o Indicate that the TTL field of a Map-Register is not used and set to 0 by the sender. This change makes this spec consistent with [LISP-MS]. o Change "... yield a packet size of L bytes" to "... yield a packet size greater than L bytes". o Clarify section 6.1.5 on what addresses and ports are used in Map- Reply messages. o Clarify that LSBs that go beyond the number of locators do not to be SMRed when the locator addresses are greater lexicographically than the locator in the existing locator-set. o Add Gregg, Srini, and Amit to acknowledgment section. o Clarify in the definition of a LISP header what is following the UDP header. o Clarify "verifying Map-Request" text in section 6.1.3. o Add Xu Xiaohu to the acknowledgment section for introducing the problem of overlapping EID-prefixes among multiple sites in an RRG email message. Farinacci, et al. Expires October 17, 2010 [Page 75] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Design based changes: o Use stronger language to have the outer IPv4 header set DF=3D1 so = we can avoid fragment reassembly in an ETR or PETR. This will also make IPv4 and IPv6 encapsulation have consistent behavior. o Map-Requests should not be sent in ECM with the Probe bit is set. These type of Map-Requests are used as RLOC-probes and are sent directly to locator addresses in the underlying network. o Add text in section 6.1.5 about returning all EID-prefixes in a Map-Reply sent by an ETR when there are overlapping EID-prefixes configure. o Add text in a new subsection of section 6.1.5 about dealing with Map-Replies with coarse EID-prefixes. B.3. Changes to draft-ietf-lisp-05.txt o Posted September 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. o Removed nonce from Map-Register message, it wasn't used so no need for it. o Clarify what to do for unspecified Action bits for negative Map- Replies. Since No Action is a drop, make value 0 Drop. Farinacci, et al. Expires October 17, 2010 [Page 76] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 B.4. Changes to draft-ietf-lisp-04.txt o Posted September 2009. o How do deal with record count greater than 1 for a Map-Request. Damien and Joel comment. Joel suggests: 1) Specify that senders compliant with the current document will always set the count to 1, and note that the count is included for future extensibility. 2) Specify what a receiver compliant with the draft should do if it receives a request with a count greater than 1. Presumably, it should send some error back? o Add Fred Templin in acknowledgment section. o Add Margaret and Sam to the acknowledgment section for their great comments. o Say more about LAGs in the UDP section per Sam Hartman's comment. o Sam wants to use MAY instead of SHOULD for ignoring checksums on ETR. =46rom the mailing list: "You'd need to word it as an ITR = MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. And of course we'd need to confirm that can actually be implemented. In particular, hardware that verifies UDP checksums on receive needs to be checked to make sure it permits 0 checksums." o Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. o Fix description in Map-Request section. Where we describe Map- Reply Record, change "R-bit" to "M-bit". o Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. o Indicate SHA1 can be used as well for Map-Registers. o More Fred comments on MTU handling. o Isidor comment about spec'ing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. o Margaret's comment on gleaning: "The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be Farinacci, et al. Expires October 17, 2010 [Page 77] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail." o Add section on RLOC-probing per working group feedback. o Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. o Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. o Change LISP header to allow a "Research Bit" so the Nonce and LSB fields can be turned off and used for another future purpose. For Luigi et al versioning convergence. o Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. o Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. o Indicate when doing data-gleaning that a verifying Map-Request is sent to the source-EID of the gleaned data packet so we can avoid map-cache corruption by a 3rd party. Comment from Pedro. o Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the the ALT (or to the EID). o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. o Jesper made a comment to loosen the language about requiring the copy of inner TTL to outer TTL since the text to get mixed-AF traceroute to work would violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3. B.5. Changes to draft-ietf-lisp-03.txt o Posted July 2009. o Removed loc-reach-bits longword from control packets per Damien comment. Farinacci, et al. Expires October 17, 2010 [Page 78] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 o Clarifications in MTU text from Roque. o Added text to indicate that the locator-set be sorted by locator address from Isidor. o Clarification text from John Zwiebel in Echo-Nonce section. B.6. Changes to draft-ietf-lisp-02.txt o Posted July 2009. o Encapsulation packet format change to add E-bit and make loc- reach-bits 32-bits in length. o Added Echo-Nonce Algorithm section. o Clarification how ECN bits are copied. o Moved S-bit in Map-Request. o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference draft-meyer-lisp-mn-00.txt. B.7. Changes to draft-ietf-lisp-01.txt o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Defined LEID to be a "LISP EID". o Indicate encapsulation use IPv4 DF=3D0. o Added negative Map-Reply messages with drop, native-forward, and send-map-request actions. o Added Proxy-Map-Reply bit to Map-Register. B.8. Changes to draft-ietf-lisp-00.txt o Posted May 2009. o Rename of draft-farinacci-lisp-12.txt. o Acknowledgment to RRG. Farinacci, et al. Expires October 17, 2010 [Page 79] =0C Internet-Draft Locator/ID Separation Protocol (LISP) April 2010 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Dave Meyer cisco Systems 170 Tasman Drive San Jose, CA USA Email: dmm@cisco.com Darrel Lewis cisco Systems 170 Tasman Drive San Jose, CA USA Email: darlewis@cisco.com Farinacci, et al. Expires October 17, 2010 [Page 80] =0C --Apple-Mail-10-1034602901 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We're still targeting April 23 to post -07, and will immediately start = reviewing and responding to the detailed comments from Mr. Papadimitriou = for -08. Thanks, Darrel/Dino/Dave/Vince= --Apple-Mail-10-1034602901-- From root@core3.amsl.com Fri Apr 16 17:45:03 2010 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5B7D53A6AB4; Fri, 16 Apr 2010 17:45:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100417004503.5B7D53A6AB4@core3.amsl.com> Date: Fri, 16 Apr 2010 17:45:03 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-multicast-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 00:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP for Multicast Environments Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-multicast-03.txt Pages : 36 Date : 2010-04-16 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-multicast-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-16173347.I-D@ietf.org> --NextPart-- From yakov@juniper.net Mon Apr 19 13:50:01 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFCFA3A69E6 for ; Mon, 19 Apr 2010 13:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.563 X-Spam-Level: X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKBXNdARZVDg for ; Mon, 19 Apr 2010 13:50:00 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id D4FBB3A691D for ; Mon, 19 Apr 2010 13:49:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS8zB67q5s1HmamjaGOaVBnPFJ1RpdwWM@postini.com; Mon, 19 Apr 2010 13:49:51 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Mon, 19 Apr 2010 13:48:36 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Apr 2010 13:48:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Apr 2010 13:48:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Apr 2010 13:48:35 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3JKmZD69911; Mon, 19 Apr 2010 13:48:35 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201004192048.o3JKmZD69911@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2300.1271710114.1@juniper.net> Date: Mon, 19 Apr 2010 13:48:34 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 19 Apr 2010 20:48:35.0820 (UTC) FILETIME=[AE59F2C0:01CAE001] Cc: jdrake@juniper.net Subject: [lisp] comments on draft-ietf-lisp-06.txt (part 1) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 20:50:01 -0000 Folks, John Scudder, John Drake, and myself produced a list of comments on draft-ietf-lisp-06.txt. The comments are split into two parts: (1) comments that are not specific to a particular section, and (2) comments that are specific to a particular section. This e-mail contains (1). Yakov. ----------------------------------------------------------------- Comment 1: Does the target audience for LISP include those who already are using PI addresses for multihoming ? If yes, then what does it offer to this audience above and beyond of what they have now ? Does the target audience for LISP include those who already are using NAT ? If yes, then what does it offer to this audience above and beyond of what they have now ? -------------------------------------------------------------------- Comment 2: There is no discussion of cache thrashing by hosts within a site which (either for some legitimate reason, or because of infection by a virus or worm) send packets to a large span of addresses. In addition to cache thrashing, this would create huge amounts of LISP control plane traffic. Even if rate limiting on the ITR helped prevent this, the rate limiting would have to be quite sophisticated (per host) to prevent a badly-behaved host from hurting other hosts at its site. Also, it assumes that sending packets to a large span of addresses is bad behavior. This should be documented as a limitation compared to the current routing model. -------------------------------------------------------------------- Comment 3: The draft leaves a number of important aspects of the Map-Reply open, or only implied rather than clearly stated. These should be stated in one place, clearly. Ambiguous areas include: - Is there a requirement that all entities that return Map-Replies for a given EID return the same contents? - If yes, then what are the consequences if two entities do return Map-Replies with different contents? - If no, then - What content is allowed to vary? (Locator Status Bits?) - What content must be invariant? (locator-set?) - If for a given EID its locator-set returned is required to be invariant, how is this achieved ? - Must the locator-set be manually configured on every entity that returns Map-Replies for that EID? - Some other way? - Under what circumstances might an EID-to-RLOC mapping change? - Can it change only as a result of provisioning/configuration ? - Or might it change as a reaction to the network's operational state? (E.g. temporary loss of reachability from a given ETR to a given EID.) -------------------------------------------------------------------- Comment 4: Suppose a certain EID's mapping entry returned at some point in the past in the Map-Reply by ETR2 lists the RLOCs of two ETRs, ETR1 and ETR2. Suppose that later on due to connectivity issues within the site, ETR1 is able to reach the EID, but ETR2 is not. Is there some means by which traffic is expected to reliably reach the EID in this case? What is it? (Keep in mind that the same RLOC of ETR2 may also be used to reach some other EID2, and ETR2 may have fine connectivity to EID2.) -------------------------------------------------------------------- Comment 5: Consider the following example: ETR1 ITR ETR2 Originally both ETR1 and ETR2 claim to be RLOCs for EIDs 10.1.1/24 and 10.1/16. So, when ITR sends Map-Request to ETR1 for 10.1.5.1, ETR1 returns both 10.1/16 and 10.1.1/24 as EID prefixes, with ETR1 and ETR2 as RLOCs for these EIDs. Assume that at some later point ETR1 is no longer an RLOC for 10.1.1/24, but still is an RLOC for 10.1/16, while ETR2 still is an RLOC for both 10.1.1/24 and 10.1/16. Would ETR1 be required to inform ITR that it is no longer an RLOC for 10.1.1/24 ? If not then assume that later on a site behind the ITR originates a packet for 10.1.1.1. Assume that the ITR selects ETR1 as the best RLOC for 10.1.1/24. So, the ITR sends the packet to ETR1. How would ITR ultimately decide to stop sending the packets destined to 10.1.1.1 to ETR1 and instead switch to ETR2 ? If ETR1 be required to inform ITR that it is no longer an RLOC for 10.1.1/24, then what mechanisms, other than the Solicited-Map-Request, ETR1 could use ? If the only mechanism available is the Solicited-Map-Request, then this introduces its own set of problems, as follows. Since according to 6.5.2 the ETR "will solicit Map-Request from sites it is currently sending encapsulated data to, and only from those sites", how would that help to update the mapping if the ITR that has the old (incorrect) mapping is not the xTR to which the ETR sends the encapsulated data ? Withdraw of a single EID prefix on the ETR may require this ETR to send a whole bunch of SMRs messages, in response receive a bunch of Map-Requests, and then send Map-Replies. And while doing this all the data traffic for that EID prefix is dropped on the floor. This has negative implications on the connectivity restoration time. Moreover, while the stated goal of Solicit-Map-Request is to control the rate an ETR receives Map-Requests messages, in the above scenario in order to reduce the connectivity restoration time the ETR has to send all these Solicit-Map-Requests messages as soon as ETR1 determines that it is no longer an RLOC for 10.1.1/24, which in turn would mean that it would receive a burst of Map-Requests causing potential congestion in the control plane, which could result in some of these Map-Requests being dropped. Would the ETR be required to re-send Solicit-Map-Request if it does not receive a corresponding Map-Request from the ETR to which it sent Solicit-Map-Request before ? And even if Map-Request is not dropped, the corresponding Map-Reply could get dropped in transit. What would happen in this case ? ------------------------------------------------------------------------ Comment 6: ITR failure and its implications on connectivity restoration time Consider a scenario where a failure (e.g., ITR failure) would result in shifting a large fraction or all the flows that used to go through one ITR to another ITR. Note that in this scenario the arrival rate of the flows at the new ITR is determined by the total number of flows being shifted (e.g., in the case of an ITR failure it is the number of flows that used to go through the old ITR), and not by the steady state arrival rate of flows. Therefore, in this scenario the rate with which the new ITR has to resolve EID-RLOC mapping is determined not by the arrival rate of flows in the steady state, but by the total number of flows being moved to the new ITR, and the latter may be significantly higher than the former. Even if we assume that all flows are TCP-based (no UDP-based flows at all), then while the arrival rate of the first few packets at the beginning of such flows is determined by the SYN retransmission time (and thus could be fairly low), this is not the case for the arrival rate of the packets in the middle of such flows, which could be Mb/sec, or even Gb/sec. Thus the amount of dropped packets (if ITR drops packets while resolving EID-RLOC mapping) or buffered packets (if ITR buffers packets while resolving EID-RLOC mapping) in a situation where a failure results in a whole bunch of existing flows being rerouted to a new ITR is going to me much higher than in the steady state. Note than none of this occurs with today's routing. That means that in the presence of ITR failure LISP would negatively impact connectivity restoration time relative to what we have today, as well as the service availability. An approach, where instead of dropping packets, an implementation would queue packets would require additional memory on the router, which at the minimum would increase the cost (and therefore the price) of the router. Moreover, in the scenario where a failure of one ITR would result in shifting all the flows that used to go through that ITR to another ITR, if the number of flows is large and/or flows are of high bandwidth it may be unfeasible to queue all these packets on the new ITR. One can not claim that the problem of how to handle data while resolving EID-RLOC mapping is a local problem for which there are local incremental fixes, as there are no practical solutions to this problem on the table at all, and thus one can not claim that such problem could be solved by local incremental fixes. Since this problem is likely to manifest itself most visibly at large scale deployment, it would be inappropriate to wait with solving this problem until large scale deployment - this problem needs to be solved before any large scale deployment of LISP, or any large scale deployment of LISP should be put on hold until a practical solution to this problem is developed. ------------------------------------------------------------------------ Comment 7: ETR failure and its implications on connectivity restoration time Note that in today's routing global BGP convergence is NOT required for connectivity restoration. In other words, IP connectivity restoration takes less time that what it takes to propagate fault information throughout the Internet (or for that matter even throughout a site). With LISP connectivity restoration requires to propagate fault all the way to the ITRs. In addition, if one relies on Loc-Status-Bits to determine that a particular RLOC is down, connectivity restoration would also require to propagate fault information from one ITR to another. In some case this may not be feasible (e.g., ETRs are PEs). And even in the cases where it is feasible, that is likely to increase connectivity restoration time. From yakov@juniper.net Mon Apr 19 13:51:44 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A49F3A6937 for ; Mon, 19 Apr 2010 13:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.122 X-Spam-Level: X-Spam-Status: No, score=-4.122 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_50=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEtewQ+hEwC9 for ; Mon, 19 Apr 2010 13:51:40 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 6CE563A67FA for ; Mon, 19 Apr 2010 13:51:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS8zCTyE/eREJcza4CHIyTQRdxIr5NMhT@postini.com; Mon, 19 Apr 2010 13:51:28 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Mon, 19 Apr 2010 13:49:51 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Apr 2010 13:49:51 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Apr 2010 13:49:50 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Apr 2010 13:49:50 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3JKnoD70621; Mon, 19 Apr 2010 13:49:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201004192049.o3JKnoD70621@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2337.1271710189.1@juniper.net> Date: Mon, 19 Apr 2010 13:49:49 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 19 Apr 2010 20:49:50.0554 (UTC) FILETIME=[DAE573A0:01CAE001] Cc: jdrake@juniper.net Subject: [lisp] comments on draft-ietf-lisp-06.txt (part 2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 20:51:44 -0000 Folks, John Scudder, John Drake, and myself produced a list of comments on draft-ietf-lisp-06.txt. The comments are split into two parts: (1) comments that are not specific to a particular section, and (2) comments that are specific to a particular section. This e-mail contains (2). Yakov. ------------------------------------------------------------------ Comment 8: Abstract: The first sentence says LISP is "simple". Yet such components of LISP as the additional aspects of MTU and fragmentation, cache management and reachability management add considerable complexity, not to mention the operational expense of learning to operate and debug an entirely new infrastructure. (As a proxy for complexity of the proposal, compare the page count, 75, to the page count of RFC 791, 45.) The proposed protocol can be implemented in a relatively small number of routers. "small" relative to what? If the Internet were to fully transition to LISP, the entire edge of the Internet would have to implement LISP. This encompasses a large number of routers, greater than the number of core routers. -------------------------------------------------------------------- Comment 9: Introduction: 3. Easing of renumbering burden when clients change providers. Because host EIDs are numbered from a separate, non-provider- assigned and non-topologically-bound space, they do not need to be renumbered when a client site changes its attachment points to the network. At least with respect to LISP+ALT, this statement is incorrect. Sites are simply locked in to their EID provider instead of being locked in to their ISP as they are now. The lock-in would appear to be more severe than it is today, since unless strong aggregation is preserved, LISP's entire value proposition is lost. 5. Mobility without address changing. Existing mobility mechanisms will be able to work in a locator/ID separation scenario. It appears from section 10, Mobility Considerations, that this claim is overstated or at least premature. For evidence of this, consider that section 10 suggests that mobility requirements should be relaxed in order to accommodate LISP's other requirements. This strongly suggests that mobility is not an important LISP design goal. -------------------------------------------------------------------- Comment 10: Section 2 Some of the design goals of this proposal include: 1. Require no hardware or software changes to end-systems (hosts). 2. Minimize required changes to Internet infrastructure. 3. Be incrementally deployable. 4. Require no router hardware changes. 5. Minimize the number of routers which have to be modified. In particular, most customer site routers and no core routers require changes. 6. Minimize router software changes in those routers which are affected. 7. Avoid or minimize packet loss when EID-to-RLOC mappings need to be performed. Wrt (2), (5), and (6) above, how could one determine whether this proposal really minimizes required changes? Wrt (4), if this statement means existing routers could be software upgraded to be LISP routers, this statement is questionable, for a number of reasons, covered elsewhere in this critique. These include control plane bandwidth (existing routers typically have much lower "punt" processing bandwidth than hardware switching bandwidth) and the complex LISP forwarding plane, which may not be implementable in microcoded forwarding engines, especially those that are older (but still widely deployed). Wrt claim in (5) that "no core routers require changes", that is incorrect, as section 5 (p.16) states that If the assumption proves true and transit networks with links limited to 1500 byte MTUs are corner cases, it would seem more cost-effective to either upgrade or modify the equipment in those transit networks to support larger MTUs or to use existing mechanisms for accommodating packets that are too large. Also, the notion that "no core routers require change(s)" is questionable unless one defines the proxies in [INTERWORK] as being non-core routers. Wrt (7) above, how could one determine whether this proposal really minimizes packet loss? What needs to be documented is how LISP compares with the current routing model in terms of minimizing packet loss. -------------------------------------------------------------------- Comment 11: Section 3 A globally routed address block (whether PI or PA) is not an EID-prefix. However, a globally routed address block may be removed from global routing and reused as an EID-prefix. A site that receives an explicitly allocated EID-prefix may not use that EID-prefix as a globally routed prefix assigned to RLOCs. The above implies that if an existing site has IPv4 addresses that are used for global connectivity, and thus act as RLOCs, the site can not use these addresses as EIDs, unless the site removes them from global routing, and thus stops using them as RLOCs. Does the spec assume that IPv4 sites that want to use LISP would need to get another block of IPv4 addresses for the EID prefix ? If yes, then where would these IPv4 addresses come from ? If a site that has IPv4 addresses and uses them for global connectivity (these addresses act as RLOCs) wants to transition to LISP, but can not get another block of IPv4 address for the EID-prefix, then how would that site transition to LISP, and what are the implications on that site's connectivity during the transition? E.g., could some, but not all, of the border routers of the site during the transition be xTRs ? If yes, then how would an ITR attract traffic from a site if the site also has a default route to a non-ITR router ? Does the EID space need to be aggregatable, as if yes, then how would one accomplish this in the context of IPv4 addresses ? -------------------------------------------------------------------- Comment 12: Section 3 Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. Is there any description of such "proxy device", and of its operation? Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. Is LISP redefining the name of the header of the encapsulated packet from "IP header" to "LISP header"? Reencapsulating Tunnels: when a packet has no more than one LISP IP header (two IP headers total) and when it needs to be diverted to new RLOC, an ETR can decapsulate the packet (remove the LISP header) and prepend a new tunnel header, with new RLOC, on to the packet. Why re-encapsulation is restricted to packets that only have a single level of LISP encapsulation ? Data Probe: a LISP-encapsulated data packet where the inner header destination address equals the outer header destination address These are discouraged by [ALT] due to scalability concerns. Perhaps this should be noted, or Data Probes should be moved to an appendix. -------------------------------------------------------------------- Comment 13: Section 4: An additional LISP header may be prepended to packets by a transit router (i.e. TE-ITR) when re-routing of the path for a packet is desired. An obvious instance of this would be an ISP router that needs to perform traffic engineering for packets in flow through its network. In such a situation, termed Recursive Tunneling, an ISP transit acts as an additional ingress tunnel router and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). This specification mandates that no more than two LISP headers get prepended to a packet. This avoids excessive packet overhead as well as possible encapsulation loops. It is believed two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and second prepended header is used inside a service provider for Traffic Engineering purposes. The restriction on the number of encapsulations seems impossible to enforce, and therefore somewhat pointless. Worse, it seems harmful; in order to foil ISP TE, all one needs to do is place an extra header in the LISP packets. If the spec is obeyed, re-encapsulation will be prevented. The restriction on the number of headers would also seem to preclude host-based implementations of LISP being located behind site-based LISP routers. -------------------------------------------------------------------- Comment 14: Section 4 Another example, perhaps for a VPN service out-sourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Since VPN is outside the scope of the LISP WG charter, the above should be deleted (as it is outside the scope). -------------------------------------------------------------------- Comment 15: Section 4.1 In LISP 1.5, the packet is routed on a different topology which may have EID prefixes distributed and advertised in an aggregatable fashion. In either case, the packet arrives at the ETR. The router is configured to "punt" the packet to the router's processor. Note that the packet is a data plane packet. That means that on ETR the control plane is used for data plane packet forwarding. What are the implications of this on control plane performance? In order to eliminate the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner header source IP address) to the source RLOC (outer header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. The last sentence in the quote contradicts the first sentence. The mapping lookup is not eliminated, but merely deferred. -------------------------------------------------------------------- Comment 16: Section 5: Based on informal surveys of large ISP traffic patterns, it appears that most transit paths can accommodate a path MTU of at least 4470 bytes. The exceptions, in terms of data rate, number of hosts affected, or any other metric are expected to be vanishingly small. An informal survey is not sufficient to provide confidence that the exception will be vanishingly small. It seems likely that the informal survey may have suffered from sampling bias, as most such surveys do. For example, did the survey consider wireless carriers? To address MTU concerns, mainly raised on the RRG mailing list, the LISP deployment process will include collecting data during its pilot phase to either verify or refute the assumption about minimum available MTU. Even if this is true, the LISP architecture is supposedly not restricted to transit networks. The document discusses location of ITRs within sites rather than at site edges. Is there evidence that 1500 byte MTUs are corner cases within sites? -------------------------------------------------------------------- Comment 17: Section 5.3 LISP Nonce: is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. The LISP Nonce does not seem to have a security usage. The choice of the term "nonce" might lead the reader to think that it does. -------------------------------------------------------------------- Comment 18: Section 5.4.1 As written, this section seems broken. Perhaps the fix would be to define S as the maximum size of a packet, in bytes, an ITR would LIKE TO receive from a source inside of its site. Without knowing what the authors intended, it's hard to be sure. Regarding the "stateless" and "stateful" MTU handling solutions, there are really two orthogonal parameters at work: whether max MTU is configured (5.4.1) or learned (5.4.2) and whether the ITR does (5.4.1) or does not (5.4.2) perform fragmentation. So, there are actually room for two more solutions in the matrix, a configured MTU + ITR that does not do fragmentation, and a learned MTU + ITR that does do fragmentation. -------------------------------------------------------------------- Comment 19: Section 5.4.2 How would this work if the ITR is behind the firewall, and the firewall filters ICMP messages? Also, in the case where a large volume of traffic has to be moved from one ITR to another (e.g., due to ITR failure), it will take time for the ITR to which the traffic is moved to discover the effective MTU for each locator mapping, and until this occurs, the traffic will be dropped. Moreover, this ITR could also get overloaded with ICMP Too Big messages, which could further increase the time required to discover the effective MTU for each locator mapping. -------------------------------------------------------------------- Comment 20: Section 6.1.2 Originating ITR RLOC Address: Used to give the ETR the option of returning a Map-Reply in the address-family of this locator. This does not seem correct. Mapping Protocol Data: See [CONS] or [ALT] for details. There are no details in [ALT]. -------------------------------------------------------------------- Comment 21: Section 6.1.3 General questions on this section include what is the expected behavior when an ETR is slashdotted (i.e., is subjected to an unexpected, very high, continuous load of legitimate queries), a comparison of the failure mode in this scenario to the behavior of a non-LISP network in the same scenario, and the related question of what is considered to be a reasonable Map-Request rate to support. -------------------------------------------------------------------- Comment 22: Section 6.1.4 ACT: This 3-bit field describes negative Map-Reply actions. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. The actions defined are used by an ITR or PTR when a destination EID matches a negative mapping cache entry. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned Why is this default chosen for unassigned actions? (This assumes that Create map-cache drop state is what is meant by "treat unassigned actions like action 0".) Since a three bit field was chosen, presumably the authors expect that up to eight different actions may be needed, but only three are defined. How would the proposed default behavior affect whether such new flags can actually be deployed? (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. Presumably "natively forwarded" means "forwarded without LISP encapsulation on the regular Internet topology"? (2) Send-Map-Request: The packet invokes sending a Map-Request. What does this mean? Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance unicast traffic between them. Weight is encoded as a percentage of total unicast packets that match the mapping entry. If a non-zero weight value is used for any RLOC, then all RLOCs must use a non-zero weight value and then the sum of all weight values MUST equal 100. The document does not specify how it is to be handled if the sum is not 100. The same criticism applies to M Weight. R: when this bit is set, the locator is known to be reachable from the Map-Reply sender's perspective. The utility of this bit is never explained and it's not clear how one would make good use of it. I.e., 1 means the sender thinks the given locator is reachable, but 0 is just a question mark. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR or router acting as a proxy replier for the EID-prefix. "Proxy replier" is never defined. Mapping Protocol Data: See [CONS] or [ALT] for details. There are no details in [ALT]. -------------------------------------------------------------------- Comment 23: Section 6.1.5 EID-to-RLOC UDP Map-Reply message A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. Why would those three prefixes be returned? A more general comment is that what a Map-Reply must return in response to a given Map-Request is underspecified (or the specification is not comprehensible). To address this perhaps insert something like the following: When an ETR replies to a Map-Request, it must reply with its EID-prefix that is the best match for the Map-Request. In addition, if it is configured with any EID-prefixes which are more-specifics of the best match EID-prefix that it returns in its Map-Reply, it must return all of those more-specific EID-prefixe s in the same Map-Reply. -------------------------------------------------------------------- Comment 24: Section 6.1.5 EID-to-RLOC UDP Map-Reply message There are several problems with the following paragraph: Note that not all overlapping EID-prefixes need to be returned, only the more specifics (note in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) entries for the matching EID-prefix of the requesting EID. When more than one EID-prefix is returned, all SHOULD use the same Time-to-Live value so they can all time out at the same time. When a more specific EID-prefix is received later, its Time-to-Live value in the Map-Reply record can be stored even when other less specifics exist. When a a less specific EID-prefix is received later, its map-cache expiration time should be set to the minimum expiration time of any more specific EID-prefix in the map-cache. First, it assumes that the ITR will exactly obey the TTLs given in the Map-Reply. Most caching systems allow caches to manage timeouts on their own, especially allowing early timeouts (for example to create space in the cache if it fills). If this is NOT allowed in LISP (and it seems not to be), that needs to be spelled out. What are the bad consequences of timing entries out at different times, which are not equal to the TTLs given? The following sentence is confusing: When a more specific EID-prefix is received later, its Time-to-Live value in the Map-Reply record can be stored even when other less specifics exist. And this sentence: When a a less specific EID-prefix is received later, its map-cache expiration time should be set to the minimum expiration time of any more specific EID-prefix in the map-cache. isn't clear as to what it's mandating. Is this a requirement for ITR behavior? When sending a Map-Reply message, the destination address is copied from the source address of the Map-Request or Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local locator addresses listed in the locator-set of any mapping record in the message. What is the source address for a negative reply, which has a zero length locator-set? -------------------------------------------------------------------- Comment 25: Section 6.1.5.1 This section correctly identifies an attack where an ETR overclaims, saying that it owns a larger span of prefixes than it really does. The proposed solutions seem inadequate; in particular, the limiting the mask-length that you'll accept from a given ETR seems weak. I.e., how could an ITR determine a "configured prefix length" for a given EID prefix? This is a serious deficiency. It is somewhat analogous to the weakness of the BGP routing system, except that it is much less amenable to auditing than BGP (since the mapping data is only presented on demand, an auditor can't simply get a feed) and there are many more machines playing than in the BGP system. -------------------------------------------------------------------- Comment 26: Section 6.2 This section uses "client-side" and "server-side" extensively without defining the terms. They seem to be the same as "ITR" and "ETR" in the rest of the document. Terminology should be defined or harmonized with the rest of the document. Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. If the client can gain some advantage (or thinks it can) by ignoring the server's weighting, it will. There should be some consideration of whether this is a problem, and if so, how to address it. Either side (more likely on the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Would not this be of great use to native LISP hosts? The document doesn't consider native LISP hosts much, but for example, a large server might speak LISP natively (consider a large search company or CDN for instance). A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. This means that "gleaning" does not reduce control traffic, it only defers it (and allows packet exchanges to go a little faster). That would seem to be a mistake for certain classes of server for which no transaction lasts longer than a few packets. As an aside, LISP requires bidirectional connectivity beween ITR and ETR. This is not a limitation in normal IP. -------------------------------------------------------------------- Comment 27: Section 6.3 Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. For the first mechanism to work it is not sufficient for the ETR to have traffic "to return to the original ITR site" - the ETR has to have traffic to return to the original ITR. And if the ETR has no traffic to return to the original ITR (even if the ETR has traffic to return to some other ITR of the site), then the first mechanism is useless. Moreover, the first mechanism is predicated on the assumption that the Loc-Status-Bits contain up to date information about reachability of all ETRs at the site. The document describes how the ITR obtains this information only for the case of CE-based or intra-site based ITRs. Thus it does not cover the case where the ITR is the PE. Moreover, for the case of CE-based ITR the scheme does not work if the site runs RIP as its IGP. Furthermore it assumes that just because the correspondent ITR can reach the given RLOC, the ETR also will. Since IP connectivity is not always transitive in this way, the fact that the corresponding ITR can reach the given RLOC does not mean that the ETR also can. The second mechanism depends on ICMP Unreachable. As such it may result in sustained traffic blackholing due to ICMP Unreachable being dropped along the path. Also, how would that mechanism handle DoS attacks caused by spoofed ICMP Unreachables ? Finally, if ITR is within a site, and behind a firewall, would the firewall pass ICMP Unreachables in the first place ? The third mechanism is likely to be of very limited use, as an ETR going down is unlikely to cause the route that covers the RLOC of that ETR to be withdrawn (unless this is /32 route). The fourth mechanism is applicable only for LISP interworking between a LISP and a non-LISP site. The fifth and the sixth mechanisms do provide the indication that the ETR is up, but do not provide the information when the ETR is down. As such they are not applicable for determining unreachability, as unreachability requires the ability to determine that the ETR is down. That leaves us with the seventh mechanism. This mechanism offers two options: Echo Nonce (section 6.3.1) and RLOC Probing (section 6.3.2). The Echo Nonce mechanism is applicable only when there is a bidirectional flow between a pair of RLOCs. The RLOC Probing mechanism has scaling limitations - quoting from 6.3.2: The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times are very small. Given the above, what are the mechanisms that are available when xTRs are PEs (as described in 8.3), and what are their scaling characteristics ? Consider an example of site A with two xTRs A1 and A2, and site B with two xTRs, B1 and B2. Now imagine that outbound traffic from A to B is using the ITR component of A1, and talking to the ETR component B1 of B. But the traffic from B back to A uses the ITR component of B2 and is sending to the ETR component of A2. So each ITR->ETR flow is unidirectional, even though all four devices are fully capable of bidirectional communication. What are the options for the RLOC reachability in this scenario ? -------------------------------------------------------------------- Comment 28: Section 6.3 The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. How would one use data packets for testing locator reachability ? -------------------------------------------------------------------- Comment 29: Section 6.3.1 When there is bidirectional data flow between a pair of locators, a simple mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N and E bits and places a 24-bit nonce in the LISP header of the next encapsulated data packet. What would it mean if N were clear and E were set? As a general comment about this section, it seems to require significant new forwarding plane functionality and as such, should be considered when thinking about whether LISP can be implemented in hardware. -------------------------------------------------------------------- Comment 30: Section 6.3.2 cached by the ITR or PTR. The ITR or PTR may include a mapping data record for its own database mapping information. What exactly is "its own database mapping information" ? -------------------------------------------------------------------- Comment 31: Section 6.4 Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a random value allows core routers which are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets which are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. "Random" in the second sentence is contradicted by the last sentence. Also, it is not clear why the paragraph restricts itself to talking about LAGs. Load balancing is used plenty of other places. -------------------------------------------------------------------- Comment 32: Section 6.5 As a general comment, this section is in need of some editing to make the prose more readable. When a locator record is added to the end of a locator-set, it is easy to update mappings. We assume new mappings will maintain the same locator ordering as the old mapping but just have new locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. This identifies a real problem; i.e., the locator status bits are contextually dependent on the locator set that was advertised, but there is no explicit binding between them and the particular locator set to which they relate. Thus, any version skew between ITR and ETR will result in misinterpretation of the locator status bits. This seems like it could be a serious problem (though section 6.3 is so underspecified and hard to follow that this is difficult to pin down) and needs to be understood better. The fixes proposed in this section seem complex and incomplete. When an ITR has only an old mapping but detects bits set in the loc-status-bits that correspond to locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing locator-set. It is previously stated that locators in the locator-set must be sorted; this would seem to indicate that you cannot add a locator to the locator-set on demand, and that a process such as defined in 6.5.1 must be used to try to ensure sync between ITR and ETR There would seem to be a need to either get rid of locator-sets, or come up with a better system for synchronizing them. The consequences of out-of-sync locator-sets should also be spelled out. -------------------------------------------------------------------- Comment 33: Section 6.5.1 The default setting for an EID-to-RLOC mapping TTL is 24 hours. This is the only place in the document where the default is specified! There is a missing step in the procedure, which is to restore the TTL to 24 hours. In general, this procedure would seem to lead to increased operational complexity, and thus contradict the claims of reduced opex. -------------------------------------------------------------------- Comment 34: Section 6.5.2 Solicited-Map-Request Since the xTRs don't keep track of remote ITRs that have cached their mappings, they can not tell exactly who needs the new mapping entries. So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites. "currently" needs to be quantified. E.g., if the local xTR detected change in the mapping at time T1, and sends the encapsulated data to a particlar remote xTR at time T2, what is the max allowable (T2-T1) ? Is it 1 sec, 1 min, 1 hour, 1 day ? What is the meaning of "solicit Map-Requests from sites" ? Does it mean soliciting it from all the xTRs of a given site ? If yes, then how would it determine all such xTRs ? And if no, and it means just one xTR of a given site, then how would Solicited-Map-Request work in the scenario where an xTR-A sends encapsulated data to xTR-B of a given (remote) site, but that site uses some other xTR, xTR-C, to send the data to xTR-A, and it is xTR-C that needs the new mapping ? The remote xTR retransmits the Map-Request slowly until it gets a "slowly" needs to be quantified. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message provided the Map-Request nonce matches the nonce from the SMR. The Map-Reply messages SHOULD be rate limited. This is important to avoid Map-Reply implosion. Is the implication that during this procedure, normal new Map-Requests will not be replied to in the usual way, since they won't have the nonce? with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, What is the justification for this assumption about the mapping database's security? -------------------------------------------------------------------- Comment 35: Section 7 Router Performance Considerations: LISP is designed to be very hardware-based forwarding friendly. By doing tunnel header prepending [RFC1955] and stripping instead of re- writing addresses, existing hardware can support the forwarding model with little or no modification. Where modifications are required, they should be limited to re-programming existing hardware rather than requiring expensive design changes to hard-coded algorithms in silicon. This is simply an Assertion. When a tunnel encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special FIB entries for the EID-prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing should be performed. The forwarding logic of testing for particular IP protocol number value is not necessary. No changes to existing, deployed hardware should be needed to support this. The above explanation of why no changes to existing deployed hardware should be needed is fairly confusing. On an ITR, prepending a new IP header is as simple as adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Many routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already support this action. This looks like another Assertion. When a received packet's outer destination address contains an EID which is not intended to be forwarded on the routable topology (i.e. LISP 1.5), the source address of a data packet or the router interface with which the source is associated (the interface from which it was received) can be associated with a VRF (Virtual Routing/Forwarding), in which a different (i.e. non- congruent) topology can be used to find EID-to-RLOC mappings. What does the part about "When a received packet's ... to be forwarded on the routable topology" have to do with the part about "the source address of a data packet ... can be associated with a VRF" ? How does one determine whether the outer destination address "contains an EID which is not intended to be forwarded on the routable topology" ? Please answer this question both for IPv6 and for IPv4. -------------------------------------------------------------------- Comment 36: Section 8 This section doesn't discuss host based LISP implementations, which seems a possibility as it is discussed under mobility. What are the implications be of host based LISP on the control plane load and does two headers restriction create a problem for host based LISP? In general, the more ITRs there are (with host based being the limiting case), the greater the load on distant ETRs, which have no control of the number of ITRs. This would seem to be a case of costs and benefits not being aligned. ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. What exactly does "suboptimal" mean here? -------------------------------------------------------------------- Comment 37: Section 8.1 If ITR/ETR are first/last hop routers, then these routers need to be routable within each site RLOC. This means that if a site changes providers, the RLOC of these routers would need to change. Therefore, any ACLs within each site would need to be modified to allow routing on these RLOCs. -------------------------------------------------------------------- Comment 38: Section 8.2 Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. The above means that at the minimum the price of resilience between the CE routers is the inability to support traffic engineering? Specifically, the ISP loses any influence over the choice of which ETR should be used to reach the multi-homed enterprise. Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are anycast addresses as well, and thus can not be topologically significant. Thus if an enterprise is multi-homed to two (or more) ISPs, then use of anycast addresses for CEs would require to route such addresses as /32 throughout the whole Internet. Also, if anycast addresses are used as RLOCs, then how would one deal with a situation where initially both ETR1 and ETR2 advertise 10.1.1/24 and 10.1.2/24, ITR1 routes traffic for 10.1.1.1 to ETR1, but then ETR1, while still being up, loses connectivity to 10.1.1/24? ------------------------------------------------------------------ Comment 39: Section 8.3 Use of ISP PE routers as tunnel endpoint routers gives an ISP control over the location of the egress tunnel endpoints. That is, the ISP can decide if the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. How is this done, as the CE router (probably) and last-hop within a site (surely) is under control of the customer, not the ISP. The advantage of this case is that two or more tunnel headers can be avoided. Only if the extra header in question would be imposed by the first-hop ISP. Any other ISP would still need to impose their own header in order to do TE. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. This is hard to understand. -------------------------------------------------------------------- Comment 40: Section 9 This section would benefit from being rewritten to increase clarity. In the IPv4 case, more router complexity is introduced, analogous to what a NAT has to do. This feature appears to be intrinsically unscalable, as an ETR serving a large enough set hosts doing traceroute will eventually start breaking traceroute when its buffer is exhausted. But worse than just breaking it, it will return bogus traceroutes. This could happen if a large percentage of hosts were running traceroute, or if the ETR were very large and serving many hosts, only a small fraction of which was running traceroute. Plus, how is the router supposed to identify a "traceroute packet"? -------------------------------------------------------------------- Comment 41: Section 9.3 segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no Earlier it was claimed that copying the TTL is important for correctness reasons. Why is it not important in this case, but is important in all other cases? -------------------------------------------------------------------- Comment 42: Section 10.3 visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-RLOC mapping for that EID. What is a "route-returnability check"? loss for the entire system. Heuristics can be added to LISP to reduce the number of mapping changes required and to reduce the delay This sounds like an assertion. per mapping change. Also IP mobility can be modified to require fewer mapping changes. In order to increase overall system performance, there may be a need to reduce the optimization of one area in order to place fewer demands on another. This would appear to be a tacit admission that LISP has a problem with IP mobility (and would therefore like IP mobility to go away). More of the same a few paragraphs down: Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything which decreases the number of new EID- RLOC mappings needed when a node moves, or maintains the validity of an EID-RLOC mapping for a longer time, is useful. -------------------------------------------------------------------- Comment 43: Section 12 There are many comments above that relate to security. Grep for "security" or "attack". Other possible issues that come to mind that should be explored here are whether LISP breaks RPF, and whether the ubiquitous tunneling infrastructure could be reused as a botnet anonymization service. -------------------------------------------------------------------- Comment 44: Section 12 To deal with map-cache exhaustion attempts in an ITR/PTR, the implementation should consider putting a maximum cap on the number of entries stored with a reserve list for special or frequently accessed sites. This should be a configuration policy control set by the network administrator who manages ITRs and PTRs. Yet more complexity, both in implementation and operation (where is the reduced opex?). All this contradicts the claim in the Abstract about LISP being "simple". -------------------------------------------------------------------- Comment 45: 14.1. Normative References: Why is HIP a normative reference? From jnc@mercury.lcs.mit.edu Mon Apr 19 15:43:34 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5223A67AF for ; Mon, 19 Apr 2010 15:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.166 X-Spam-Level: X-Spam-Status: No, score=-4.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMx9n82+bqex for ; Mon, 19 Apr 2010 15:43:33 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3A7EC3A67A3 for ; Mon, 19 Apr 2010 15:43:33 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 749E96BE5C8; Mon, 19 Apr 2010 18:43:21 -0400 (EDT) To: lisp@ietf.org, yakov@juniper.net Message-Id: <20100419224323.749E96BE5C8@mercury.lcs.mit.edu> Date: Mon, 19 Apr 2010 18:43:21 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jdrake@juniper.net, jnc@mercury.lcs.mit.edu Subject: Re: [lisp] comments on draft-ietf-lisp-06.txt (part 1) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:43:34 -0000 > From: Yakov Rekhter > John Scudder, John Drake, and myself produced a list of comments on > draft-ietf-lisp-06.txt. The comments are split into two parts: (1) > comments that are not specific to a particular section Thanks for that interesting list. By and large, each merits a thread in itself, so I won't attempt to answer them all in detail in a single message - such a message would be a paper, not an email message that normal list participants could hope to peruse. (Perhaps the WG chairs or someone could open an issue for each?) Also, this message represents only my own person opinion: other people working on LISP may have differing views, so please do not take this as anything more than just my personal thoughts. One general comment I will make is that many of these points have actually previously been identified as issues (e.g. the 'connectivity between an ETR and an end-host', Comment 4). The reasons why they remain open, even after having been identified, vary from case to case. In general, though, in part it's because this is an effort conducted with limited personnel and resources, and with such limits, it's inevitable that some less-critical issues have to have detailed resolutions deferred until later, and many of these fall into that category. Since it is an _experimental_ deployment, the focus of those limited resources (properly, IMO) is on getting to a point where one can get an experimental deployment that one can learn some useful lessons from. If I may mention the context briefly, the RRG does seem to have a rough consensus that the Internet does need to separate location and identity at an architectural level. However, there is neither large-scale experience with the costs and problems such a step is likely to bring, nor a plan that is guaranteed to be a _feasible_ deployment plan for such a major architectural upheaval to a massive operational system - and as we have learned from experience, a new design _without_ a viable deployment plan is not of any use at all. LISP promises to bring us valuable information on both counts, which highlights the utility of the experiment, and therefore the desirability of pressing forward with a deployment before every last engineering t is crossed. In any event, no engineering solution is 'perfect' out of the box; inevitably problems get resolved, and additional capabilities added, over the operational lifetime, a process you will no doubt be familiar with from experience with BGP. Of course, the more things that can be done up front, the better. If you all are able to add some additional resources to LISP, that would be really great - it would allow us to look at some of these issues that have either been put to one side as less important, or not really identified until now. I'll try and respond in detail in a bit to some of the points you have raised, in a separate message(s). Noel From terry.manderson@icann.org Mon Apr 19 16:20:59 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4103A67E3 for ; Mon, 19 Apr 2010 16:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.37 X-Spam-Level: X-Spam-Status: No, score=-4.37 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51KV9Xb9LaKw for ; Mon, 19 Apr 2010 16:20:53 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id CC4E23A698B for ; Mon, 19 Apr 2010 16:20:38 -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, 19 Apr 2010 16:20:30 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 19 Apr 2010 16:20:28 -0700 Thread-Topic: draft minutes from ietf77 Thread-Index: AcrgFuWiGHyo89Tc2UujLx1lruTVxw== 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] draft minutes from ietf77 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 23:20:59 -0000 Folks, The following are the draft minutes from IETF 77 for the two sessions. Thanks to Luigi and Wassim for preparing them. If everyone could review them, and email me ASAP with any required alterations that would be great. I intend to upload them tomorrow evening. Cheers Terry WG: Locator/Identifier Seperation Protocol =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Chairs: =3D=3D=3D=3D Joel Halpern Terry Manderson Secretaries: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Wassim Haddad Luigi Iannone Joel starting the meeting: ------------------------------ Agenda bashing: --> Darrel Lewis: wise to collapse the draft updates into one agenda item? --> Joel Halpern: Any objection in the room No objection! Agenda is now open for updates (30 min for all the WG drafts) Darrel Lewis presenting: ---------------------------- - draft-iet-lisp-06 - draft-ietf-lisp-alt-03 - draft-ietf-lisp-interworking-01 (ready too late for cut-off date, will be submitted later) --> Fred Templin (on fragmentation issue): what you will do if ICMP message= s get lost? --> Darrel Lewis: It breaks --> Sam Hartman: this is one big issue in IPsec deployment (break if you rely on ICMP messages to avoid reassembly). I have done an analysis to see what to do and I am not aware of any work on path MTU discovery that works. --> Fred Templin: If you blackhole messages, SEAL can help obviously: need to consider a stateless version (?). It does not reassemble on the ETR --> Joel Halpern (after update on draft-ietf-lisp-06): Any general comment? --> Joel Halpern: Dimitri Papadimitriou has reviewed draft-ietf-lisp-06. Th= e comments will be sent on the mailinglist. 2nd draft: draft-ietf-lisp-alt (Darrel Lewis presenting) --> Vince Fueller: what this means is that a box doing aggregation EIDs prefixes across a hole has to understand LISP protocol and cannot be only a= n off the shelf BGP box. 3rd draft: draft-ietf-lisp-interworking (still Darrel Lewis) Done! --> Sriram Kotikapaludi (NIST): when you send exceptions for EID prefix coverage, do they all go in one message or in separate message? --> Darrel Lewis: yes one message. map reply contains all locator records i= n one message (i.e., all negative replies). --> Sriram Kotikapaludi: any performance penalty in this case? --> Dino Farinacci: It is a trade-off between mapping and storing (map request load vs. memory on the ITR) --> Sriram Kotikapaludi: just wondering if it makes sense to split them in multiple messages after the first packet is dealt with. --> Darrel Lewis: There will be a problem with implementation if you do that: if we split the replies and the nonce is cleared after the first packet is validated then it won=B9t be able to check the validity of subsequent replies. --> Joel Halpern: the other obvious implementation risk is if the 2nd packe= t is lost then how do we recover? If the process takes too long we can fix it later. Dino Farinacci presenting: draft-ietf-lisp-multicast-02 --------------------------------------------------------------- Done for today! Move to the next session agenda: --> Joel Halpern: concerning the security analysis: --> Luigi Iannone: started to work on one draft: what we should do? --> Joel Halpern: get several drafts, then we can figure out whether we should address them in the main document or we need other drafts to address them --> Sam Hartman: we seemed to be working on different parts of the problem but we=B9ll need to merge at some point in time. I am more interested in having the info written down first. --> Joel Halpern: none of the security issue will be swept under the carpet= . Every problem will be written down but not all will be solved (to be figure= d out) --> Joel Halpern: Someone will/should write a deployment document because I received many questions on how to deploy LISP (confusion) --> Dave Meyer: amend charter to make space for such document (i.e., become a WG)? --> Joel Halpern: It depends on the progress and the document. Jari and the WG will decide --> Sam Hartman: It is in the charter! There is already material available from the last meeting. --> Joel Halpern: OK then we can use it as a hook --> Jari Arkko: document will be beneficial and if it is not in the charter then we can fix it. I=B9d like to see it. --> Jari Arkko: the other thing is about addressing security issues and not others. We should see what things are threats that need to be addressed. Material for the 2nd session: Dino Farinacci presenting: How to send Map-Replies: --> Isidor Kouvelas: The problem is when ITR is v6 only while ETR ETR has both v4 and v6 and does not know that it does not have to reply using v4. --> Sam Hartman: I raised this issue before! --> Joel Halpern: v6 map reply can only happen on the 3rd alternative --> Wes George: question from Jabber: can someone post the slides? --> Joel Halpern: I won=B9t get them posted during this session unfortunate= ly. Just got them an hour ago --> Sam Hartman: This is an issue that comes back to Joel's comment during the last meeting on whether map-requests should be encapsulated or not. Do we really need packet changes? That question is still an open issue. Better not to do this change and later on choose to not encapsulate. --> Dino Farinacci: the two issues are orthogonal --> Sam Hartman: does not agree. This problem can arise in the core architecture when 2 (v4 and v6) addresses are in the map-request and you have only v6 addresses. You cannot solve the problem. --> Dino Farinacci: This is explained in the next slide and has nothing to do with packet encapsulation. --> Sam Hartman: Changes to the packet are no orthogonal. --> Joel Halpern: couple of comments: there are similarities in the change that are proposed. On the issue of arch change: I can't push for change while sitting here! Otherwise, there were two of us (or three) who want it. If people think there is an issue we should solve then we'll start a discussion on it but I can't keep pushing it... --> Sam Hartman: It seems to me that people ignored the message you sent on the list. --> Joel Halpern: I am not asking you to do more. People that think this is an issue should speak by themselves. Let's take it back to the list. But conceptional, these are still different problems. --> Dino Farinacci: bringing Joel architecture thing is orthogonal --> Hannu Flink: want to check my understanding: Map-replies relays information from ETR to ITR avoiding the mapping system, isn't an issue? --> Dino Farinacci: no back to the slides (Dino speaking again) --> Sam Hartman (on the proposed changes to Map-Replies): why do you need more than two bits? Why not only two possible addresses? --> Dino Farinacci: possibibly don=B9t but we want to anticipate more than = two address families. --> Sam Hartman: reducing the number of variable fields is an issue. Allowing only two addresses should be enough and make the implementation simpler. Unless, we have a compelling reason I think we don=B9t need more t= han two. I don't really care! --> Luigi Iannone: I don't see the implementation issue here. Looks clean i= n my opinion Hannu Flink presenting: Membership test to complement the mapping system: --> Joel Halpern: step 4 on the left: is it important to send the first packet to the RLOC? --> Hannu Flink: NoS Just to circumvent drop and buffering --> Joel Halpern: for the 1000 EIDs site, use 4K response? --> Hannu Flink: Yes --> Dino Farinacci: run the BF across the 1000 EID values? --> Hannu Flink: Yes, this is the flat case. --> Dino Farinacci: Don't know about performance --> Joel Halpern: can you elaborate why the false positive is similar to stale mapping? --> Hannu Flink: you=B9re right. But if you look at the sequence of message= s exchange =3D> it is the same protocol sequence. --> Joel Halpern: any other topics to raise today? Session 2 Wednesday 24th March (135 Min) Administration - Jabber Scribe(s): Darell Lewis - Blue Sheets Agenda Bashing Presentation and Note well 5 presentations scheduled: Dino Farinacci: LISP Instance IDs Dino Farinacci Presenting: Version Hashing Luigi Iannone: LISP Mapping Versioning Sriram Kotikapaludi Presenting: Enhanced Efficiency of Mapping Fangwei Hu presenting: LISP with MPLS Dino Farinacci Presenting: LISP Instance IDs -------------------------------------------- --> Joel Halpern: Could you use the same or different ALT instances with different I-bit instances? --> Dino Farinacci: This is possible, I am not sure whether we can use the same one. However this bit is very useful in Data Centers. --> Joel Halpern: We need to add text with the procedural description of ho= w this bit is exactly used. --> Luigi Iannone: If the I-bit is set does it goes in every single packet? --> Dino Farinacci: Yes. Dino Farinacci Presenting: Version Hashing ------------------------------------------ --> Luigi Iannone: The problem of synchronization goes beyond the version number. My opinion is that it should be documented somewhere (i.e., what happens when there is a lack of sync). --> Dino Farinacci: We think that synchronization is decoupled from this proposal and should be addressed separately. --> Margaret Wasserman: In the first slide you said that this applies only to proxy ITR. --> Dino Farinacci: It is more important there but it is not the only case. You can use it in ITR and ETR as well. --> Margaret Wasserman: This includes the square case, the one with two unidirectional flows between two sites, as well. --> Dino Farinacci: Yes. --> Darell Lewis: This also includes when ITR and ETR functionalities are split on different boxes. --> Dino Farinacci: Agreed. Luigi Iannone: LISP Mapping Versioning --------------------------------------- (draft-iannone-lisp-mapping-versioning-01.txt) --> Joel Halpern: There are many situations where one side or the other is waiting for the other to communicate. You need other mechanisms to solve this issue. --> Luigi Iannone: I never claimed this is solving all the problems. --> Dino Farinacci: Joel, you mean that this solution should fix the proble= m as well or it is another solution? --> Joel Halpern: Mobility is out of scope if we want to solve this problem= . --> Luigi Iannone: Mobility is not in the charter but this model works better than hashing. --> Joel Halpern: Is this the only case of mismatching? --> Luigi Iannone: Not necessarily this one. There are several scenarios where you can imagine this desynchronization. --> Srini Subramanian: It could happen that the new version number is wrong= , how to deal with that case? --> Luigi Iannone: You can either ask the ETR directly or go through the mapping system. When you have a new version number, you can go through the mapping system and if the mapping system is broken then you better unplug your computer. --> Joel Halpern: We can do nothing, version hashing or version numbering. --> Joel Halpern: Do you have any preferences about this? --> Dimitri Papadimitrou: I prefer Luigi's versioning solution. --> Dino Farinacci: I prefer Luigi's solution too. --> Joel Halpern: Interesting! --> Dino Farinacci: Let me explain. There is one disadvantage in version numbering, which is the configuration, but the corset is worth it. --> Joel Halpern: So we need to propose text on the mailing list. Luigi, yo= u seem to be the most adequate person to do it. --> Luigi Iannone: Sure. I can do that. Sriram Kotikapaludi Presenting: Enhanced Efficiency of Mapping Distribution Protocols --------------------------------------------------------------- --> Darell Lewis: There is an action bit in the Map-Reply. --> Joel Halpern: (concerning slide 3) Why we need to advertise all of the de-aggregated prefixes? --> Sriram Kotikapaludi: This is a Patricia Tree so you need to de-aggregat= e and announce everything. --> Dino Farinacci: (concerning slide 3) This is not a nasty situation, you don't need to de-aggregate but the problem has merit. --> Jesper Skriver: (concerning slide 3) You expand only if you do not allo= w overlapping, but the problem is what ETR of AS10886 doesn't know of the other. --> Joel Halpern: What's the difference between a /20 and a /24, why not send back directly the /24 instead of the /20 with the holes? --> Dino Farinacci: In that case the ETR should not reply with the /20 --> Joel Halpern: This is the same behavior like replying with /24 directly --> Dino Farinacci: It depends on what you advertise in the ALT. --> Joel Halpern: I don't see the difference, better to let's go to the list. --> Darell Lewis: The only difference that I see is that it may take longer= . --> Sriram Kotikapaludi: In this way you cover more prefixes. --> Dino Farinacci: So you store the mapping but count for more specific. --> Joel Halpern: How to know whether or not to send the request? --> Dino Farinacci: We can get away encapsulating to that locator set, the mask tells you what to store. --> Sriram Kotikapaludi: Version can help in detecting the change that triggers a new Map-request. --> Dimitri papadimitriou: How does this works with 20% holes, 30% holes, etc.? You are driven by the traffic to discover the holes. This can be non efficient. --> Sriram Kotikapaludi: 90% is not used to discover the hole. The percentage does not matter. --> Dino Farinacci: We have a tradeoff between the information you put in replies and latency. --> Joel Halpern: let's take it to the list. --> Damien Saucez (jabber): What's the gain? It depends on the distribution of the traffic. What will we have in reality? --> Sriram Kotikapaludi: I agree that there is overhead. Fangwei Hu presenting: LISP with MPLS -------------------------------------- (draft-hu-lisp-mpls-trans-00.txt) --> Dave Meyer: The ingress TE and Provider Lockin issues are back with thi= s solution. --> Dino Farinacci: In your case the ITR and the PE is in the same box? --> Fangwei Hu: In scenario of slide 5, yes. --> Dino Farinacci: What if site 2 is in a different MPLS domain? --> Fangwei Hu: We do not consider this case in this scenario. --> Dino Farinacci: You say that LISP encapsulation plus MPLS encapsulation is not a good thing. In my opinion it is good because it is deployable. --> Darell Lewis: (from the jabber) In slide 6, what about the checksum? --> Joel Halpern: This argument has a lot more people involved and I am not asking the presenter. Other questions? Nothing from the room. --> Joel Halpern: This concludes the session, see you in Maastricht. From dino@cisco.com Mon Apr 19 19:09:00 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB04D3A6892 for ; Mon, 19 Apr 2010 19:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.738 X-Spam-Level: X-Spam-Status: No, score=-8.738 tagged_above=-999 required=5 tests=[AWL=1.861, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1RIQ85nJXRb for ; Mon, 19 Apr 2010 19:09:00 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 942003A68AF for ; Mon, 19 Apr 2010 19:08:59 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJupzEurR7H+/2dsb2JhbACbf3GjI5lYhQ4EgzI X-IronPort-AV: E=Sophos;i="4.52,239,1270425600"; d="scan'208";a="318598122" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 20 Apr 2010 02:08:51 +0000 Received: from [192.168.1.3] (sjc-vpn6-1755.cisco.com [10.21.126.219]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3K28oo3004889; Tue, 20 Apr 2010 02:08:51 GMT Message-Id: From: Dino Farinacci To: Terry Manderson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Apr 2010 19:08:50 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] draft minutes from ietf77 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 02:09:00 -0000 > --> Dino Farinacci: Let me explain. There is one disadvantage in > version > numbering, which is the configuration, but the corset is worth it. I actually said there was one advantage and one disadvantage of version numbering over version hashing. And the advantage is beneficial if we can bear the cost of the disadvantage. And my gut feel was we *could* bear the cost of the disadvantage. The advantage was that you get version ordering or sequencing so you could tell which mapping was more current. The disadvantage is that you have to configure the version number for each database-mapping for each xTR at a site. I thought the disadvantage was a reasonable cost to get the advantage. But the implementation could screw this up so we need to provide suggestions in the map-versioning draft. Dino From terry.manderson@icann.org Mon Apr 19 19:14:57 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1683A6821 for ; Mon, 19 Apr 2010 19:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.484 X-Spam-Level: X-Spam-Status: No, score=-5.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieNeqSFNpq6W for ; Mon, 19 Apr 2010 19:14:57 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 054243A67AD for ; Mon, 19 Apr 2010 19:14:57 -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, 19 Apr 2010 19:14:48 -0700 From: Terry Manderson To: Dino Farinacci Date: Mon, 19 Apr 2010 19:14:47 -0700 Thread-Topic: [lisp] draft minutes from ietf77 Thread-Index: AcrgLnk5/fZ/9gHBTmW78aUL5ELL1wAAMZ21 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 Cc: "lisp@ietf.org" Subject: Re: [lisp] draft minutes from ietf77 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 02:14:57 -0000 Thanks Dino! Noted and amended. Terry On 20/04/10 12:08 PM, "Dino Farinacci" wrote: >> --> Dino Farinacci: Let me explain. There is one disadvantage in >> version >> numbering, which is the configuration, but the corset is worth it. >=20 > I actually said there was one advantage and one disadvantage of > version numbering over version hashing. And the advantage is > beneficial if we can bear the cost of the disadvantage. And my gut > feel was we *could* bear the cost of the disadvantage. >=20 > The advantage was that you get version ordering or sequencing so you > could tell which mapping was more current. The disadvantage is that > you have to configure the version number for each database-mapping for > each xTR at a site. >=20 > I thought the disadvantage was a reasonable cost to get the advantage. > But the implementation could screw this up so we need to provide > suggestions in the map-versioning draft. >=20 > Dino >=20 From trac@tools.ietf.org Tue Apr 20 00:26:37 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C9C28C0F3 for ; Tue, 20 Apr 2010 00:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.357 X-Spam-Level: X-Spam-Status: No, score=-101.357 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_40=-0.185, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8YRDv+iA1Zh for ; Tue, 20 Apr 2010 00:26:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AEAA23A6B3F for ; Tue, 20 Apr 2010 00:24:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O47oL-0000yU-73; Tue, 20 Apr 2010 00:23:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:23:57 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/29 Message-ID: <068.a9eaa4362d5427dc5c63414ba7e32171@tools.ietf.org> X-Trac-Ticket-ID: 29 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #29: Editorial Issues Section 2 raised by Dimitri Papadimitriou reviewing draft-ietf-lisp-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:26:38 -0000 #29: Editorial Issues Section 2 raised by Dimitri Papadimitriou reviewing draft- ietf-lisp-06.txt ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 2 states “More cost-effective multi-homing†but it is not stated what is actually meant by this statement and why the Loc/ID scheme as proposed would make multi-homing cost-effective. Section 2 states “Mobility without address changing†but then “… or acquiring a new address based on the new network location.†These statements are contradicting each other. Section 2 states “This draft describes protocol mechanisms to achieve the desired functional separation.†But separation between which functions ? If this statement is related to the separation between forwarding and control/routing, then it is defeated looking at i) the way RLOC reachability testing inter-twin control as part of the forwarding plane, and ii) the use of “Data Probes†forwarding date as part of the control plane of TR’s. Section 2 the statement “This draft attempts to not compete or overlap with such solutions and the proposed protocol changes are expected to complement a host-based mechanism when Traffic Engineering functionality is desired.†raises the question if these solutions would still be complementary if TE functionality is not desired (this is not clearly stated in the document). On the other hand, the statement “Building the solution into the network will facilitate incremental deployment of the technology on the Internet.†should be further developed to explain why “network deployment†is considered as facilitating incremental deployment ? Section 2 states “Some of the design goals of this proposal include:†Which are the other goals ? there is only partial match with the design goals specified at RRG (the term “design goal†seems to have a different meaning) and it is unclear what changes are referring to. The statement “Minimize required changes to Internet infrastructure.†is vague. The statement “most customer site routers†under which condition the remaining fraction would have to change. Section 2 describes LISP variants depending on EID “routability†it would be appropriate to state “routability†refers to the core i.e. between ITR/ETR (as EID remain routable in “sites†otherwise there is no difference with host-based solutions) Section 2. LISP 1.5 is assumed to make use of a “separate topology†also referred to as “alternative topologyâ€. The key question is what is this topology ? Section 2. LISP 3 assumes the existence of EID-to-RLOC database. How the existence of the databases is made aware to ITR. This is what determines the use of Data probes vs Map requests if both modes are supported. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:28:22 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9263A6966 for ; Tue, 20 Apr 2010 00:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwpNhKS0sylH for ; Tue, 20 Apr 2010 00:28:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6BE1C3A6989 for ; Tue, 20 Apr 2010 00:27:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O47rq-0005p5-2Q; Tue, 20 Apr 2010 00:27:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:27:34 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/29#comment:1 Message-ID: <077.dd3e380dfb82ed7a230cc96548d91b0b@tools.ietf.org> References: <068.a9eaa4362d5427dc5c63414ba7e32171@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <068.a9eaa4362d5427dc5c63414ba7e32171@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #29: Editorial Issues Section 2 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review (was: Editorial Issues Section 2 raised by Dimitri Papadimitriou reviewing draft-ietf-lisp-06.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:28:22 -0000 #29: Editorial Issues Section 2 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 2 states “More cost-effective multi-homing†but it is not > stated what is actually meant by this statement and why the Loc/ID > scheme as proposed would make multi-homing cost-effective. > > Section 2 states “Mobility without address changing†but then “… or > acquiring a new address based on the new network location.†These > statements are contradicting each other. > > Section 2 states “This draft describes protocol mechanisms to achieve > the desired functional separation.†But separation between which > functions ? If this statement is related to the separation between > forwarding and control/routing, then it is defeated looking at i) the > way RLOC reachability testing inter-twin control as part of the > forwarding plane, and ii) the use of “Data Probes†forwarding date as > part of the control plane of TR’s. > > Section 2 the statement “This draft attempts to not compete or overlap > with such solutions and the proposed protocol changes are expected to > complement a host-based mechanism when Traffic Engineering > functionality is desired.†raises the question if these solutions > would still be complementary if TE functionality is not desired (this > is not clearly stated in the document). On the other hand, the > statement “Building the solution into the network will facilitate > incremental deployment of the technology on the Internet.†should be > further developed to explain why “network deployment†is considered as > facilitating incremental deployment ? > > Section 2 states “Some of the design goals of this proposal include:†> Which are the other goals ? there is only partial match with the > design goals specified at RRG (the term “design goal†seems to have a > different meaning) and it is unclear what changes are referring > to. The statement “Minimize required changes to Internet > infrastructure.†is vague. The statement “most customer site routers†> under which condition the remaining fraction would have to change. > > Section 2 describes LISP variants depending on EID “routability†it > would be appropriate to state “routability†refers to the core > i.e. between ITR/ETR (as EID remain routable in “sites†otherwise > there is no difference with host-based solutions) > > Section 2. LISP 1.5 is assumed to make use of a “separate topology†> also referred to as “alternative topologyâ€. The key question is what > is this topology ? > > Section 2. LISP 3 assumes the existence of EID-to-RLOC database. How > the existence of the databases is made aware to ITR. This is what > determines the use of Data probes vs Map requests if both modes are > supported. New description: Section 2 states “More cost-effective multi-homing†but it is not stated what is actually meant by this statement and why the Loc/ID scheme as proposed would make multi-homing cost-effective. Section 2 states “Mobility without address changing†but then “… or acquiring a new address based on the new network location.†These statements are contradicting each other. Section 2 states “This draft describes protocol mechanisms to achieve the desired functional separation.†But separation between which functions ? If this statement is related to the separation between forwarding and control/routing, then it is defeated looking at i) the way RLOC reachability testing inter-twin control as part of the forwarding plane, and ii) the use of “Data Probes†forwarding date as part of the control plane of TR’s. Section 2 the statement “This draft attempts to not compete or overlap with such solutions and the proposed protocol changes are expected to complement a host-based mechanism when Traffic Engineering functionality is desired.†raises the question if these solutions would still be complementary if TE functionality is not desired (this is not clearly stated in the document). On the other hand, the statement “Building the solution into the network will facilitate incremental deployment of the technology on the Internet.†should be further developed to explain why “network deployment†is considered as facilitating incremental deployment ? Section 2 states “Some of the design goals of this proposal include:†Which are the other goals ? there is only partial match with the design goals specified at RRG (the term “design goal†seems to have a different meaning) and it is unclear what changes are referring to. The statement “Minimize required changes to Internet infrastructure.†is vague. The statement “most customer site routers†under which condition the remaining fraction would have to change. Section 2 describes LISP variants depending on EID “routability†it would be appropriate to state “routability†refers to the core i.e. between ITR/ETR (as EID remain routable in “sites†otherwise there is no difference with host-based solutions) Section 2. LISP 1.5 is assumed to make use of a “separate topology†also referred to as “alternative topologyâ€. The key question is what is this topology ? Section 2. LISP 3 assumes the existence of EID-to-RLOC database. How the existence of the databases is made aware to ITR. This is what determines the use of Data probes vs Map requests if both modes are supported. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:32:06 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379683A6A18 for ; Tue, 20 Apr 2010 00:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wPrndD7s22U for ; Tue, 20 Apr 2010 00:32:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8C0F93A6AB1 for ; Tue, 20 Apr 2010 00:31:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O47vz-0007w2-6j; Tue, 20 Apr 2010 00:31:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:31:51 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/30 Message-ID: <068.4f04af5743fd47e6fd9db1056dddf420@tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #30: Editorial Issues Section 3 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:32:06 -0000 #30: Editorial Issues Section 3 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 3. The definition of Provider Independent (PI) Addresses states what a PI is not instead of defining what a PI is. Also the document refers to EID prefixes and EID “blocks†what is a “block†and a “sub-blockâ€? Section 3. Definition of PA “LISP uses only topologically-assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non- scalable practiceâ€. Provide a reference of such demonstration. Section 3. ITR/ETR are described as routers while they are actually functions. Describe them as functions instead of “routersâ€. Section 3. Definition of RLOC seems to be limited to ETR. Thus how ITR set the Source RLOC ? Section 7 (third bullet) makes this assignment even less understandable (the well-defined concept of VRF suddenly appears). Section 3. The most important definition “EID-to-RLOC mapping lookup†is missing. In particular, how a ITR knows that the “incoming†destination address is part of an EID prefix ? More generally which event or condition triggers such lookup ? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:33:12 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B52128C108 for ; Tue, 20 Apr 2010 00:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIVtDSGA12J1 for ; Tue, 20 Apr 2010 00:33:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 400C228C103 for ; Tue, 20 Apr 2010 00:33:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O47x8-00080E-S1; Tue, 20 Apr 2010 00:33:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:33:02 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/30#comment:1 Message-ID: <077.68b3749387e39dc4d185554e86fcce70@tools.ietf.org> References: <068.4f04af5743fd47e6fd9db1056dddf420@tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <068.4f04af5743fd47e6fd9db1056dddf420@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #30: Editorial Issues Section 3 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:33:12 -0000 #30: Editorial Issues Section 3 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Changes (by luigi@…): * priority: minor => trivial -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:33:57 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1296028C0FA for ; Tue, 20 Apr 2010 00:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JkZK1DYadYe for ; Tue, 20 Apr 2010 00:33:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 38DD828C0F8 for ; Tue, 20 Apr 2010 00:33:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O47xr-00081S-SF; Tue, 20 Apr 2010 00:33:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:33:47 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/29#comment:2 Message-ID: <077.6a633e896f7a69b57deae396f16216c3@tools.ietf.org> References: <068.a9eaa4362d5427dc5c63414ba7e32171@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <068.a9eaa4362d5427dc5c63414ba7e32171@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #29: Editorial Issues Section 2 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:33:57 -0000 #29: Editorial Issues Section 2 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Changes (by luigi@…): * priority: minor => trivial -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:36:10 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076F13A68EE for ; Tue, 20 Apr 2010 00:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg5ACgKnjkkg for ; Tue, 20 Apr 2010 00:36:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4C6E53A679C for ; Tue, 20 Apr 2010 00:36:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O47zx-00086z-UA; Tue, 20 Apr 2010 00:35:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:35:57 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/31 Message-ID: <068.cc47b61ab5b472a78045ace30b57ee5b@tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #31: Editorial Issues Section 4 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:36:10 -0000 #31: Editorial Issues Section 4 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 4 “an EID is only routable within the scope of a site†what is the scope of a site ? Section 4 last paragraph of p13, refers to Section 8 concerning “flexible†placement of TR’s but does not respond to the question is there a deployment scenario that would not be supported. Section 4.1 states “And the Data Probes are sent on the underlying topology (the LISP 1.0 variant) but could also be sent over an alternative topology (the LISP 1.5 variant) as it would in [ALT].†but in Section 2 does refer to [ALT] in LISP 3 context ? Section 4.1 point 3 states “The router is configured to "punt" the packet to the router's processor. See Section 7 for more details.†Looking at Section 7 there is no definition of “punting packetsâ€. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:38:46 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1483A692D for ; Tue, 20 Apr 2010 00:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-nZ8bSOwIwP for ; Tue, 20 Apr 2010 00:38:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 158E53A6358 for ; Tue, 20 Apr 2010 00:38:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O482U-00089t-Mx; Tue, 20 Apr 2010 00:38:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:38:34 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/32 Message-ID: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:38:46 -0000 #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.2 introduces the terms client-side and server-side where are these terms defined ? without such definition readability of the section is low. Section 6.2 RLOC reachability can determined and selected but there is no description on how the EID-to-RLOC selection is performed. Section 6.3.2 states “RLOC Probing can also provide RTT estimates between a pair of locators which can be useful for network management purposes as well as for selecting low delay paths.†If the exchanges are performed in the control plane it is not clear how such RTT/delay values can be derived for the forwarding path ? Can authors explain ? Authors should also check the accuracy of the estimate vs overhead generated by such technique. Section 6.5 the section does not actually explain which messages are used to update the list of Loc-Reach or Loc-Status bits. If it is data traffic-driven then the mechanism is again dependent on the symmetry of the reverse path and the packet rate but also packet differential delays between packets. In the latter case, it is not clear how ITR could retrieve the correct RLOCs to be used if a sequence of 8 packets sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC (indicated as available at arrival of the 8th packet) is received as 1,0,0,0,0,0,0,0. The section makes a long digression on ordering locator set this is not the issue without a sequence number it will never be possible for the receiving ITR to determine the actual state of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep track of who requested mappings upon communication they should tell the state of their mapping but also their transition. -- Ticket URL: lisp LISP WG document issues From dino@cisco.com Tue Apr 20 00:40:36 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB463A6AB1 for ; Tue, 20 Apr 2010 00:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDioi-wDFOBx for ; Tue, 20 Apr 2010 00:40:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 25B943A6978 for ; Tue, 20 Apr 2010 00:40:30 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0BAGr3zEuQ/uCWiWdsb2JhbACcARUBAQEKCxERBhyiY5oChQ8EgzM X-IronPort-AV: E=Sophos;i="4.52,241,1270425600"; d="scan'208";a="59680773" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2010 07:40:21 +0000 Received: from [192.168.1.3] (sjc-vpn3-676.cisco.com [10.21.66.164]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3K7eJaR014903; Tue, 20 Apr 2010 07:40:19 GMT Message-Id: <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201004192048.o3JKmZD69911@magenta.juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Apr 2010 00:39:11 -0700 References: <201004192048.o3JKmZD69911@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: jdrake@juniper.net, lisp@ietf.org Subject: Re: [lisp] comments on draft-ietf-lisp-06.txt (part 1) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 07:40:36 -0000 > Folks, > > John Scudder, John Drake, and myself produced a list of comments > on draft-ietf-lisp-06.txt. The comments are split into two parts: > (1) comments that are not specific to a particular section, and > (2) comments that are specific to a particular section. This > e-mail contains (1). Yakov/John/John, thanks for your comments. I am glad that Juniper is getting involved with LISP. Other equipment vendors like Ericsson, Hua- Wei, Arista, and XKL, to name a few, have been involved as well. We are in the process of making changes to -07 and have to make a call on how many changes we put in. But what we cannot put into -07, we will definitely put into -08, which should be published before the next IETF. Ditto for the lengthy comments Dimitri sent last week. We are just trying to treat high priority changes with expediency and others that may require more data or additional testing come next. So don't take us not reflecting a comment as discounting it. But please verify in -08 that we have addressed your comments. See responses to your comments inline. > ----------------------------------------------------------------- > Comment 1: > > Does the target audience for LISP include those who already are > using PI addresses for multihoming ? If yes, then what does it > offer to this audience above and beyond of what they have now ? Yes, it does include these sites. What is offered is ingress control at the site. And the user does not have to run a more complicated BGP protocol on their CPE routers. Outsourcing costs to manage routers is soaring and isn't cost justified by branch offices who want to become multi-homed. > Does the target audience for LISP include those who already are > using NAT ? If yes, then what does it offer to this audience above Yes, it does. It is very difficult today to do multi-homing with ingress traffic engineering when you have NATs. We have been validated by customers that it is desirable to use global addresses for better policy and identification of users. > and beyond of what they have now ? > > -------------------------------------------------------------------- > Comment 2: > > There is no discussion of cache thrashing by hosts within a site which > (either for some legitimate reason, or because of infection by a virus > or worm) send packets to a large span of addresses. In addition to We have text indicating how do to cache management. We are testing implementations on how to aggressively delete entries not being used and how to damp and rate-limit map-requests. We do have a lot of experience with this because the 65 node network we have deployed has a half-of-dozen PITRs deployed. The Internet has a common pulse of address scans 24x7, so we see how the cache is being maintained on those PITRs. It has been useful to tune the implementation so we can put text in the drafts to describe how to deal with this. It really hasn't been a problem. > cache thrashing, this would create huge amounts of LISP control plane > traffic. Even if rate limiting on the ITR helped prevent this, the > rate > limiting would have to be quite sophisticated (per host) to prevent a It's not sophisticated, it is granular, if it needs to be. > badly-behaved host from hurting other hosts at its site. Also, it On the contrary, the ITR is the one that can block a malicious host at a LISP site to reduce the traffic load further on the path. And the state is local to the sources on at the site, rather than a much larger set. With ETR to ITR feedback, we can actually source-quench rogue sources. > assumes that sending packets to a large span of addresses is bad > behavior. This should be documented as a limitation compared to the > current routing model. > > -------------------------------------------------------------------- > Comment 3: > > The draft leaves a number of important aspects of the Map-Reply > open, or only implied rather than clearly stated. These should be > stated in one place, clearly. Ambiguous areas include: > > - Is there a requirement that all entities that return Map-Replies > for a given EID return the same contents? Yes, it is stated, the ETRs should return the same contents. When I say "contents" here, I mean the locator-set has the same list of locator addresses. See below for changing priority/weight values per locator address. > - If yes, then what are the consequences if two entities do return > Map-Replies with different contents? Not very severe, the ITRs that cache one versus the other just get different answers and use what they have cached. If the LSBs are inconsistent, then one just avoids using some of the locators. It just means that traffic is not load balanced even if the destination site might want it to be. But since the configuration error is the fault of their own, they are the ones that are affected. > - If no, then > - What content is allowed to vary? (Locator Status Bits?) > - What content must be invariant? (locator-set?) We envision for policy reasons that the Map-Reply contents (not the locator-set itself but the priorities and weights associated with each locator) may vary based on the source of the Map-Request or the destination address the Map-Request is for, that priorities/weights may differ. But we encourage that the same policy be configured consistently among all ETRs that would be answering a Map-Request. > - If for a given EID its locator-set returned is required to be > invariant, > how is this achieved ? It is not required but desirable for network management reasons. > - Must the locator-set be manually configured on every entity that > returns Map-Replies for that EID? Yes, we recommend each ETR either is connected directly to the ALT or registers to a Map-Server, but if they do not they won't get Map- Requests so they don't or can't send Map-Replies. We encourage all ETRs to accept Map-Requests so the control-plane load can be balanced across all the CPUs of the various ETRs. > - Some other way? > > - Under what circumstances might an EID-to-RLOC mapping change? > - Can it change only as a result of provisioning/configuration ? Yes. Usually this case. > - Or might it change as a reaction to the network's operational > state? > (E.g. temporary loss of reachability from a given ETR to a given > EID.) No, as discussed in the spec, we keep locator reachability out of the mapping database system. Thereby if a locator goes down or out of service, *it is not removed* from the locator-set. > -------------------------------------------------------------------- > Comment 4: > > Suppose a certain EID's mapping entry returned at some point in the > past in the Map-Reply by ETR2 lists the RLOCs of two ETRs, ETR1 and > ETR2. Suppose that later on due to connectivity issues within the > site, ETR1 is able to reach the EID, but ETR2 is not. Is there some > means by which traffic is expected to reliably reach the EID in > this case? What is it? (Keep in mind that the same RLOC of ETR2 > may also be used to reach some other EID2, and ETR2 may have fine > connectivity to EID2.) Yes, ETR1 can tell remote sites by setting its own LSB to 0. ETR2 can do the same for ETR1's LSB. > -------------------------------------------------------------------- > Comment 5: > > Consider the following example: > > ETR1 > ITR > ETR2 > > Originally both ETR1 and ETR2 claim to be RLOCs for EIDs 10.1.1/24 > and 10.1/16. So, when ITR sends Map-Request to ETR1 for 10.1.5.1, > ETR1 returns both 10.1/16 and 10.1.1/24 as EID prefixes, with ETR1 > and ETR2 as RLOCs for these EIDs. Right. > Assume that at some later point ETR1 is no longer an RLOC for > 10.1.1/24, but still is an RLOC for 10.1/16, while ETR2 still is > an RLOC for both 10.1.1/24 and 10.1/16. Would ETR1 be required to > inform ITR that it is no longer an RLOC for 10.1.1/24 ? Either ETR1 or ETR2 can use versioning numbering (new in -07) or SMRs (Solicit Map-Requests) to tell cachers that the locator-set is changing for either EID-prefix. In this case, both ETR1 and ETR2 have been reconfigured to have a locator-set for 10.1.1.0/24 to be only ETR2. > If not then assume that later on a site behind the ITR originates > a packet for 10.1.1.1. Assume that the ITR selects ETR1 as the best > RLOC for 10.1.1/24. So, the ITR sends the packet to ETR1. How would > ITR ultimately decide to stop sending the packets destined to > 10.1.1.1 to ETR1 and instead switch to ETR2 ? > > If ETR1 be required to inform ITR that it is no longer an RLOC for > 10.1.1/24, then what mechanisms, other than the Solicited-Map-Request, > ETR1 could use ? If the only mechanism available is the > Solicited-Map-Request, then this introduces its own set of problems, > as follows. > > Since according to 6.5.2 the ETR "will solicit Map-Request from > sites it is currently sending encapsulated data to, and only from > those sites", how would that help to update the mapping if the ITR > that has the old (incorrect) mapping is not the xTR to which the ETR > sends the encapsulated data ? If RLOC-probing is in use from the ITRs that have enabled it, they will get Map-Replies with the new locator-set. If no RLOC-probe reply comes back, then the ITR stops encapsulating to that locator. But when using SMRs, the other xTRs will inform the cachers. > Withdraw of a single EID prefix on the ETR may require this ETR to > send a whole bunch of SMRs messages, in response receive a bunch > of Map-Requests, and then send Map-Replies. And while doing this A bunch is rate-limited to the top talkers, the ones that need updating sooner rather than later. > all the data traffic for that EID prefix is dropped on the floor. > This has negative implications on the connectivity restoration time. There is also a method to set the LSB bit for a removed locator. That can be done in the data-plane so the restoration is equal to the amount of time the data-plane processor in the xTR can tell the control-plane processor. We are talking 10 to 100s of microseocnds versus network latency time (10s of milliseconds) or protocol timeout ranges. > Moreover, while the stated goal of Solicit-Map-Request is to control > the rate an ETR receives Map-Requests messages, in the above scenario > in order to reduce the connectivity restoration time the ETR has > to send all these Solicit-Map-Requests messages as soon as ETR1 > determines that it is no longer an RLOC for 10.1.1/24, which in > turn would mean that it would receive a burst of Map-Requests causing > potential congestion in the control plane, which could result in Map-Requests will be sent by multiple ITRs on the ALT that has multiple paths to the Map-Servers that are advertising the EID-prefix. So the load is distributed across the ALT. Also, the Map-Servers distribute the load across the ETRs registering. That makes use of all the resources of the mapping database system. Plus any implementation that blasts out packets can expect to overload its output queue first and foremost, so it needs to clock its output. And that will help the network as well. > some of these Map-Requests being dropped. Would the ETR be required > to re-send Solicit-Map-Request if it does not receive a corresponding > Map-Request from the ETR to which it sent Solicit-Map-Request before ? > And even if Map-Request is not dropped, the corresponding Map-Reply > could get dropped in transit. What would happen in this case ? Have a look at the map-versioning specification. This can help the situation especially in the case of unidirectional traffic (i.e. PITR to ETR flows). > ------------------------------------------------------------------------ > Comment 6: > > ITR failure and its implications on connectivity restoration time > > Consider a scenario where a failure (e.g., ITR failure) would result > in shifting a large fraction or all the flows that used to go through > one ITR to another ITR. Note that in this scenario the arrival rate > of the flows at the new ITR is determined by the total number of > flows being shifted (e.g., in the case of an ITR failure it is the > number of flows that used to go through the old ITR), and not by > the steady state arrival rate of flows. Therefore, in this scenario > the rate with which the new ITR has to resolve EID-RLOC mapping is > determined not by the arrival rate of flows in the steady state, > but by the total number of flows being moved to the new ITR, and > the latter may be significantly higher than the former. Just like when a new ITR comes up. It's the same case. > Even if we assume that all flows are TCP-based (no UDP-based flows > at all), then while the arrival rate of the first few packets at > the beginning of such flows is determined by the SYN retransmission > time (and thus could be fairly low), this is not the case for the > arrival rate of the packets in the middle of such flows, which could > be Mb/sec, or even Gb/sec. Thus the amount of dropped packets (if > ITR drops packets while resolving EID-RLOC mapping) or buffered > packets (if ITR buffers packets while resolving EID-RLOC mapping) > in a situation where a failure results in a whole bunch of existing > flows being rerouted to a new ITR is going to me much higher than > in the steady state. Note than none of this occurs with today's > routing. That means that in the presence of ITR failure LISP would > negatively impact connectivity restoration time relative to what > we have today, as well as the service availability. If you are really worried about this case, there are couple solutions we have not documented: (1) we can pre-populate map-cache entries for popular sites. This is similar to how browsers ship with factory-installed Certificates. (2) The Map-Request/Map-Reply packet format is flexible enough for an ITR to ask another ITR at its own site for what it has cached. It *could* store those entries before the flows come to it. This is a memory/state tradeoff. > An approach, where instead of dropping packets, an implementation > would queue packets would require additional memory on the router, Many customers have said dropping is better than queuing, because predictable latency is more important. We do not suggest additional queuing in routers to support LISP. > which at the minimum would increase the cost (and therefore the > price) of the router. Moreover, in the scenario where a failure of > one ITR would result in shifting all the flows that used to go > through that ITR to another ITR, if the number of flows is large > and/or flows are of high bandwidth it may be unfeasible to queue > all these packets on the new ITR. We have implemented aLISP in an existing production router with simply a software upgrade change. It sits at the CPE since we believe that is the sweet-spot for site control. No new memory or bandwidth requirements. > One can not claim that the problem of how to handle data while > resolving EID-RLOC mapping is a local problem for which there are > local incremental fixes, as there are no practical solutions to > this problem on the table at all, and thus one can not claim that > such problem could be solved by local incremental fixes. Since this Well, we have to leave some creativity for the manufacturer. ;-) > problem is likely to manifest itself most visibly at large scale > deployment, it would be inappropriate to wait with solving this > problem until large scale deployment - this problem needs to be You don't need large scale deployment. You can prove it with 2 LISP sites, each storing /32 EID-prefixes for the other. We don't encourage this but we can get good data points by this example. The fact that the scan attacks are constant on the Internet and the boxes are being held together is saying the problem isn't as bad you may think by just reading documents. > solved before any large scale deployment of LISP, or any large scale > deployment of LISP should be put on hold until a practical solution > to this problem is developed. And that is what we are doing. > ------------------------------------------------------------------------ > Comment 7: > > ETR failure and its implications on connectivity restoration time > > Note that in today's routing global BGP convergence is NOT required > for connectivity restoration. In other words, IP connectivity > restoration takes less time that what it takes to propagate fault > information throughout the Internet (or for that matter even > throughout a site). With LISP connectivity restoration requires to > propagate fault all the way to the ITRs. In addition, if one relies > on Loc-Status-Bits to determine that a particular RLOC is down, > connectivity restoration would also require to propagate fault > information from one ITR to another. In some case this may not be > feasible (e.g., ETRs are PEs). And even in the cases where it is > feasible, that is likely to increase connectivity restoration time. Since there isn't very good aggregation of prefixes in BGP, route- updates tend to go farther than one would desire (especially when there are PI prefixes all over the place and just increasing). There is also queuing delays, processing delays, and TCP delays in each node that has to process the route change. In the LISP case, the ITR hardware is programmed with the new LSB settings and every router on the path is hardware switching this data packet to the ETR. So the cost in processing is *only* at the ETR. So it is much faster than in the BGP case. And in the LISP case, the source site gets the granularity it needs versus a BGP aggregate that doesn't tell the source site anything about the *real* reachability of the destination. Please note, just because you have a BGP route in your routing table does not mean you can reach the destination. We will get you responses to your part 2 comments by end of week. Thanks again, Dino/Dave/Vince/Darrel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From trac@tools.ietf.org Tue Apr 20 00:42:59 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D173A6A0E for ; Tue, 20 Apr 2010 00:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBIvmwgLziqq for ; Tue, 20 Apr 2010 00:42:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7CC543A69E7 for ; Tue, 20 Apr 2010 00:42:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O486X-0008LI-3n; Tue, 20 Apr 2010 00:42:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:42:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/33 Message-ID: <068.55f561e469bb5634357c136824b60322@tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:43:00 -0000 #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 7: the first paragraph is a wish not a fact. As such it is doubtful what such paragraph actually brings in the context of a protocol architecture/specification. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:45:33 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBFBC3A6AF3 for ; Tue, 20 Apr 2010 00:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpKDLmXLVIwy for ; Tue, 20 Apr 2010 00:45:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2ED583A6AE8 for ; Tue, 20 Apr 2010 00:45:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4895-0008SI-Po; Tue, 20 Apr 2010 00:45:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:45:23 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/34 Message-ID: <068.8aebdfd098dad3558af27ffd1331ae4e@tools.ietf.org> X-Trac-Ticket-ID: 34 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:45:34 -0000 #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 8.1 first paragraph, it is not the location of the source that determines the “size†of the working set of the EID prefix-to-RLOC cache but the number of EID prefixes this “source site†has to reach. The same issue occurs at ETR, small sites may have to be configured with a large list of EID-to-RLOC mapping entries. Next to this the granularity of the EID prefix allocation is also important. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:50:39 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B19A3A68EE for ; Tue, 20 Apr 2010 00:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shwphpXSRvqd for ; Tue, 20 Apr 2010 00:50:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B0AAF3A6B3F for ; Tue, 20 Apr 2010 00:50:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48De-00022u-Ax; Tue, 20 Apr 2010 00:50:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:50:06 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/35 Message-ID: <068.086ab03f7d697b0b88a899d2cbfbd7b8@tools.ietf.org> X-Trac-Ticket-ID: 35 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #35: Limited Nonce space limits bi-directional relationships between xTRs (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:50:39 -0000 #35: Limited Nonce space limits bi-directional relationships between xTRs (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 5.3 sets the nonce space to 2^24 but does not explain the space of applicability of this field as reading goes this value is limiting the number of bi-directional relationships between TR’s to this number. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:53:35 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2903A679C for ; Tue, 20 Apr 2010 00:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh0kSUP-XzbK for ; Tue, 20 Apr 2010 00:53:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D47253A68F2 for ; Tue, 20 Apr 2010 00:53:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48Gs-0002Aw-G9; Tue, 20 Apr 2010 00:53:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:53:26 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/35#comment:1 Message-ID: <077.f6dcf25e412765ae052a3ac53ae8afd9@tools.ietf.org> References: <068.086ab03f7d697b0b88a899d2cbfbd7b8@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <068.086ab03f7d697b0b88a899d2cbfbd7b8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #35: Limited Nonce space limits bi-directional relationships between xTRs (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:53:36 -0000 #35: Limited Nonce space limits bi-directional relationships between xTRs (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 5.3 sets the nonce space to 2^24 but does not explain the > space of applicability of this field as reading goes this value is > limiting the number of bi-directional relationships between TR’s to > this number. New description: Section 5.3 sets the nonce space to 2^24^ but does not explain the space of applicability of this field as reading goes this value is limiting the number of bi-directional relationships between TR’s to this number. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:55:31 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F1A3A679C for ; Tue, 20 Apr 2010 00:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESCKoFCtYvUQ for ; Tue, 20 Apr 2010 00:55:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F0F463A6B32 for ; Tue, 20 Apr 2010 00:55:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48If-0002F3-Jt; Tue, 20 Apr 2010 00:55:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:55:17 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/36 Message-ID: <068.632a2ff78449828b0bcb9725ae27c0dc@tools.ietf.org> X-Trac-Ticket-ID: 36 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #36: On the validation of EID-to-RLOC mappings (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:55:31 -0000 #36: On the validation of EID-to-RLOC mappings (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 3. Validation of “EID-to-RLOC mappings†in cache is defined as time-based only ? not on frequency of usage neither replacement ? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 00:58:47 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67DC3A6B23 for ; Tue, 20 Apr 2010 00:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fMMqrUEQSOW for ; Tue, 20 Apr 2010 00:58:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 76CA73A6861 for ; Tue, 20 Apr 2010 00:58:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48Lm-0002Kv-Bv; Tue, 20 Apr 2010 00:58:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 07:58:30 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/37 Message-ID: <068.b91f1e75a7679cf9586affc219ad36c7@tools.ietf.org> X-Trac-Ticket-ID: 37 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #37: On the minimization of packet loss (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 07:58:47 -0000 #37: On the minimization of packet loss (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 2 states “7. Avoid or minimize packet loss when EID-to-RLOC mappings need to be performed.†This condition is not addressed by the present proposal as the ITRs drop the packet(s) for which they have no EID-to-RLOC mapping for (as long as response to Map Request is not received and RLOC reachability “testedâ€). -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 01:01:19 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36D03A6944 for ; Tue, 20 Apr 2010 01:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNGvLrokzkl2 for ; Tue, 20 Apr 2010 01:01:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C1C7F3A6767 for ; Tue, 20 Apr 2010 01:01:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48OJ-0002Qt-DT; Tue, 20 Apr 2010 01:01:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 08:01:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/38 Message-ID: <068.d78898c7d3942fc16603b8eb00cf99bf@tools.ietf.org> X-Trac-Ticket-ID: 38 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #38: On the limitation of LISP recursive encapsulation (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 08:01:19 -0000 #38: On the limitation of LISP recursive encapsulation (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 4 “This specification mandates that no more than two LISP headers get prepended to a packet.†Is there any mechanism preventing ITR (or TE ITR) to perform additional prepending ? and at which cost ? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 01:03:27 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9243A6835 for ; Tue, 20 Apr 2010 01:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3Iw2vO1jxdT for ; Tue, 20 Apr 2010 01:03:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 67D3F3A6B3D for ; Tue, 20 Apr 2010 01:03:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48QN-0002Uo-1A; Tue, 20 Apr 2010 01:03:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 08:03:15 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/39 Message-ID: <068.12293221f19f6fe467bf28e060516dd4@tools.ietf.org> X-Trac-Ticket-ID: 39 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #39: On the performance of cache lookup (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 08:03:27 -0000 #39: On the performance of cache lookup (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 4.1 point 2 (same remark applies to Section 6) misses an important aspect how the mapping is performed the first time a new destination EID is seen at ITR and how subsequent maps are performed. It seems that a) EID-to-RLOC Cache must be first entirely scanned for each incoming packet at ITR (not only the first one) and then if there is no entry i) Data probe i.e. copy the destination EID value in the destination RLOC field (for LISP 1.5) or ii) originate a Map Request; otherwise use the corresponding RLOC value in the retrieved entry as destination RLOC. Needless to say that the delay is proportional to the number of entries in the cache. Nothing is being said if the cache is full (which entry should be replaced i.e. the least frequently used, the least recently used, or the least recently replaced entry). -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 01:07:19 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319483A6B45 for ; Tue, 20 Apr 2010 01:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYpkit+jpA2V for ; Tue, 20 Apr 2010 01:07:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D4A463A684C for ; Tue, 20 Apr 2010 01:07:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48U6-0002fA-E3; Tue, 20 Apr 2010 01:07:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 08:07:06 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/26#comment:1 Message-ID: <069.f8a59f49234f2319b7bf738dbead3aa8@tools.ietf.org> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #26: Overlapping Map prefixes in EID map cache X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 08:07:19 -0000 #26: Overlapping Map prefixes in EID map cache ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): '''Dimitri Papadimitriou raises a related question in his review of draft- ietf-lisp-06.txt:''' Nothing is said what happens if a more accurate EID prefix is being made available when a less EID prefix is being in use for a set of one or more RLOCs. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 01:11:13 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73463A69FA for ; Tue, 20 Apr 2010 01:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Fwa4rOWswJm for ; Tue, 20 Apr 2010 01:11:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6D3A63A6B49 for ; Tue, 20 Apr 2010 01:11:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48Xu-0003p3-0d; Tue, 20 Apr 2010 01:11:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 08:11:01 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/40 Message-ID: <068.6be121a4e79e460e226dc9e12c9b0b5a@tools.ietf.org> X-Trac-Ticket-ID: 40 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #40: On the handling of decapsulated packets (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 08:11:13 -0000 #40: On the handling of decapsulated packets (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 4.1 point 4 states “The LISP header is stripped so that the packet can be forwarded by the router control plane.†… forwarding traffic by routing control engines result in major drawbacks such as attacks, intrusions, etc. if the value encoded in the destination EID is one of the routers addresses. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 01:13:19 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF5A3A6B59 for ; Tue, 20 Apr 2010 01:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5JFc8eqv0Ij for ; Tue, 20 Apr 2010 01:13:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 381633A6B50 for ; Tue, 20 Apr 2010 01:13:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48Zx-0000aZ-PX; Tue, 20 Apr 2010 01:13:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 08:13:09 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/41 Message-ID: <068.c98233242421fa02404e78eeae2303e2@tools.ietf.org> X-Trac-Ticket-ID: 41 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #41: Map-Reply sent for not reachable EID (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 08:13:19 -0000 #41: Map-Reply sent for not reachable EID (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 4.1 point 4 supposedly if there the destination EID is not found in the ETR's EID-to-RLOC database the packet gets dropped ? On the other hand how to prevent that a Map Reply is sent in response for EID prefix not reachable but statically configured in the ETR's EID-to-RLOC database. The case of ETR responding with “coarser EID-RLOC†mapping due e.g. to sub-segmentation is partially addressed in Section 6.1.5.1 -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 01:27:36 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380213A694A for ; Tue, 20 Apr 2010 01:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLK1zNcZlFSh for ; Tue, 20 Apr 2010 01:27:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1A2AC3A677D for ; Tue, 20 Apr 2010 01:27:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48nh-0003UO-G5; Tue, 20 Apr 2010 01:27:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 08:27:21 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/26#comment:2 Message-ID: <069.017aca85b54d20bf6c374fc418e52693@tools.ietf.org> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #26: Overlapping Map prefixes in EID map cache X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 08:27:36 -0000 #26: Overlapping Map prefixes in EID map cache ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): '''Dimitri Papadimitriou raises a related question in his review of draft- ietf-lisp-06.txt:''' Section 6.1.3 does not explain the result of refresh for which the received EID block would be larger than the requested one. Section 6.1.5 assumes that a “that a Map-Reply may contain different EID-prefix granularity (prefix + length) than the Map-Request which triggers it.†But it doesn’t say if the associated RLOC shall be identical or not ? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 01:32:23 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447373A6899 for ; Tue, 20 Apr 2010 01:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnS1Rw8A0-Al for ; Tue, 20 Apr 2010 01:32:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EB40C3A6804 for ; Tue, 20 Apr 2010 01:32:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48sP-0005i0-IE; Tue, 20 Apr 2010 01:32:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 08:32:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/42 Message-ID: <068.949be01828216d93bdf1e485048b2d40@tools.ietf.org> X-Trac-Ticket-ID: 42 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #42: On the SMR mechanism (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 08:32:23 -0000 #42: On the SMR mechanism (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.5.2 is this technique mandatory or not (this is not specified in the text). Point 5 results in obvious situations where the ETR may never stop sending SMR messages. As there is no means a way to prevent that ITR use “old mappings†this result in a deadlock situation (a non-cooperating ITR prevents ETR to stop sending SMR messages). Section 6.5.2 states “So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites.†Thus instead of keeping track of ITR, ETR keep track of the encapsulated traffic ITR send. The mechanism is often cited but never explained e.g. over which time period is the ETR expected to determine the set of communicating ITR’s ? Section 6.5.2 states “Map request†shall be rate limited … rather unclear: assume a single ETR sends one SMR message to 10 different ITRs how the 10 ITR will individually rate limit a single Map Request in response to this SMR message. It is thus worth specifying the flow control of SMR and Map-Request messages in a more systematic way to prevent ETR overloads. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 01:39:16 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE9728C0FC for ; Tue, 20 Apr 2010 01:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.632 X-Spam-Level: X-Spam-Status: No, score=-100.632 tagged_above=-999 required=5 tests=[AWL=-1.890, BAYES_00=-2.599, FRT_PROFIT1=3.858, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZNaHx73gudy for ; Tue, 20 Apr 2010 01:39:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8418228C0F8 for ; Tue, 20 Apr 2010 01:39:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O48z2-0005rm-3s; Tue, 20 Apr 2010 01:39:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 20 Apr 2010 08:39:04 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/43 Message-ID: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@tools.ietf.org> X-Trac-Ticket-ID: 43 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #43: Issues related to RLOC rechability (definition and mechanism) raised by D. Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 08:39:16 -0000 #43: Issues related to RLOC rechability (definition and mechanism) raised by D. Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.1.5 where is the “Data Probe packet†format defined actually ? Section 6.1.5 states “The RLOCs in the Map-Reply are the globally-routable IP addresses of the ETR but are not necessarily reachable; separate testing of reachability is required.†Section 6.3 does not define any procedure actually and does not define any criteria for deciding when the RLOC is reachable or not. The key question is if the ITR persists in testing reachability and there is no criteria process by which such decision would stop, the traffic would be forwarded by means of the “separate/alternative topology†forever. Section 6.3 proposes “encapsulated traffic†based procedures thus, if there is no traffic there is no RLOC reachability “test†possible. On the other hand, that section states certain “ICMP exchanges†are documented but reachability of RLOC does not mean availability of the associated EID. There no actual “EID-to-RLOC†testing procedure being defined in the document? What is struggling here is that the “introductory†sections of the document refer to “functional†separations but all the techniques described in this document (and for RLOC reachability testing in particular) result in a complex inter-twin between control messaging as part of the forwarding plane and forwarding date as part of the control plane of routers. The latter is typical from Data Probes processing. If this is the design choice of LISP so let it be but 1) please proof it offers any better functionality compared to “current†design and 2) better cost/performance. It is far from obvious that the complexity concentrated at TR taking into the proposed design offers any real compelling argument. This may also defeat the argument stated in the introduction that “network deployment†is facilitated by network-based solutions. Section 6.3 Point 1 what is the use of the “Loc-Status-Bits†if there is no return traffic (or more precisely no return traffic passing via this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The ETR may process this information but never use it. Section 6.3 states “Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them.†This does not tell which technique to use when no default route are used at all (under “non-normal†circumstances … what should define normality in this context). Section 6.3.1 states “This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional.†The forwarding path may simply be asymmetric (there is nothing that imposes reverse path reaching the source RLOC in case of dual attached sites). This shortcoming defeats this mechanism as an ITR is not “aware†of its neighboring ITR EID-to-RLOC mappings (connected to the same site). This mechanism can only be safely used if the RLOC pair between two sites is unique and remains unique. Section 6.3.2 RLOC Probing by means of the “control plane†this opens the question of what is actually probed the “RLOC†or the EID-to-RLOC entries of the ETR’s database. The difference stems because the latter are static entries the liveness of the former are dependent on the incoming interface liveness. That is entries can be available in the database but if database entries are not in sync with the actual RLOC status there is no possibility to detect reachability of RLOCs by means of this mechanism. -- Ticket URL: lisp LISP WG document issues From jgs@juniper.net Tue Apr 20 10:05:38 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585D33A684F for ; Tue, 20 Apr 2010 10:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXwbbBK3hPOu for ; Tue, 20 Apr 2010 10:05:37 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 04BF728C1B2 for ; Tue, 20 Apr 2010 10:04:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS83er0LjVl3h6ar2zBBrSAzUvoFpM+0F@postini.com; Tue, 20 Apr 2010 10:04:49 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Tue, 20 Apr 2010 10:04:29 -0700 From: John Scudder To: Dino Farinacci Date: Tue, 20 Apr 2010 10:04:27 -0700 Thread-Topic: Discussion of comment 3 (Map-Replies) [was: Re: [lisp] comments on draft-ietf-lisp-06.txt (part 1)] Thread-Index: Acrgq4lux8xiSLZzSnKMv1ahCZm2IQ== Message-ID: References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com> In-Reply-To: <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" , John E Drake Subject: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 17:05:38 -0000 Hi Dino, Just replying to one point here. Other replies as time allows. On Apr 20, 2010, at 3:39 AM, Dino Farinacci wrote: [...] >> Comment 3: >>=20 >> The draft leaves a number of important aspects of the Map-Reply >> open, or only implied rather than clearly stated. These should be >> stated in one place, clearly. Ambiguous areas include: >>=20 >> - Is there a requirement that all entities that return Map-Replies >> for a given EID return the same contents? >=20 > Yes, it is stated, the ETRs should return the same contents. When I I've only read the spec a few times so I may have missed where this is spel= led out. Would you mind citing where this is stated in the spec? >> - Must the locator-set be manually configured on every entity that >> returns Map-Replies for that EID? >=20 > Yes, Is that "yes" to the "must be manually configured" question? I would have = assumed so but you go on to talk about connecting to the ALT and such, whic= h would appear to be an unrelated (or tangentially related) topic. >> - Or might it change as a reaction to the network's operational >> state? >> (E.g. temporary loss of reachability from a given ETR to a given >> EID.) >=20 > No, OK... > as discussed in the spec, we keep locator reachability out of the > mapping database system. Thereby if a locator goes down or out of > service, *it is not removed* from the locator-set. ... but note that the parenthetical question had to do with *EID* reachabil= ity, not locator reachability. --John= From lear@cisco.com Tue Apr 20 10:15:05 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C9F28C18C for ; Tue, 20 Apr 2010 10:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.379 X-Spam-Level: X-Spam-Status: No, score=-4.379 tagged_above=-999 required=5 tests=[AWL=-1.780, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFrXYew8Rw8r for ; Tue, 20 Apr 2010 10:15:03 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 4410C3A6851 for ; Tue, 20 Apr 2010 10:14:34 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,244,1270425600"; d="scan'208";a="5868868" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 20 Apr 2010 16:38:05 +0000 Received: from dhcp-10-55-94-155.cisco.com (dhcp-10-55-94-155.cisco.com [10.55.94.155]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3KHEOEi017903; Tue, 20 Apr 2010 17:14:24 GMT Message-ID: <4BCDE0ED.9020307@cisco.com> Date: Tue, 20 Apr 2010 19:14:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100418 Lanikai/3.1b2pre MIME-Version: 1.0 To: John Scudder References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John E Drake , "lisp@ietf.org" Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 17:15:05 -0000 On 4/20/10 7:04 PM, John Scudder wrote: >> as discussed in the spec, we keep locator reachability out of the >> mapping database system. Thereby if a locator goes down or out of >> service, *it is not removed* from the locator-set. > ... but note that the parenthetical question had to do with *EID* reachability, not locator reachability. > > I'm going to hazard a guess that is what Dino meant, as locator reachability occurs as it does today. From darlewis@cisco.com Tue Apr 20 10:59:30 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C27128C1A9 for ; Tue, 20 Apr 2010 10:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATbxS71i3cVu for ; Tue, 20 Apr 2010 10:59:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D879B28C19B for ; Tue, 20 Apr 2010 10:59:29 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,244,1270425600"; d="scan'208";a="185835770" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Apr 2010 17:59:21 +0000 Received: from [10.21.78.205] ([10.21.78.205]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3KHxJjO018211; Tue, 20 Apr 2010 17:59:20 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Darrel Lewis In-Reply-To: <068.6be121a4e79e460e226dc9e12c9b0b5a@tools.ietf.org> Date: Tue, 20 Apr 2010 10:59:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <919483D8-FE34-4E1E-B3B9-8A40E55F60DD@cisco.com> References: <068.6be121a4e79e460e226dc9e12c9b0b5a@tools.ietf.org> To: lisp@ietf.org X-Mailer: Apple Mail (2.1078) Subject: Re: [lisp] #40: On the handling of decapsulated packets (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 17:59:30 -0000 On Apr 20, 2010, at 1:11 AM, lisp issue tracker wrote: > #40: On the handling of decapsulated packets (from D. Papadimitriou's = review) > = ------------------------------------------+-------------------------------= -- > Reporter: luigi@=85 | Owner: = =20 > Type: technical | Status: new = =20 > Priority: major | Component: = draft-ietf-lisp > Severity: - | Keywords: = =20 > = ------------------------------------------+-------------------------------= -- > Section 4.1 point 4 states =93The LISP header is stripped so that the > packet can be forwarded by the router control plane.=94 =85 forwarding > traffic by routing control engines result in major drawbacks such as > attacks, intrusions, etc. if the value encoded in the destination EID > is one of the routers addresses. >=20 > --=20 The point that Mr Papadimitriou raises in section 4.1 point 4 is just = one of the drawbacks of DataProbes. We've been actively deprecating = them for some time, though leaving in the _option_ for them so we can = continue experimenting. I believe the draft would be best served by altering this example to = show the current packet flow with and without a map cache entry for the = destination EID in the ITR. If the WG agrees with this I'll propose = some text. -Darrel From trac@tools.ietf.org Tue Apr 20 14:26:07 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AEC628C23C for ; Tue, 20 Apr 2010 14:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVSdmleZLmk4 for ; Tue, 20 Apr 2010 14:26:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 51E3728C241 for ; Tue, 20 Apr 2010 14:23:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4KuA-0005M5-Ty; Tue, 20 Apr 2010 14:22:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:22:50 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/44 Message-ID: <057.598d71d19cb14b43d07dda5b5aaa388e@tools.ietf.org> X-Trac-Ticket-ID: 44 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #44: LISP vs existing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:26:07 -0000 #44: LISP vs existing -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Yakov Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- What LISP offers to audiences which are already using PI? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:26:50 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4056528C20A for ; Tue, 20 Apr 2010 14:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTvz83+uLhRQ for ; Tue, 20 Apr 2010 14:26:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B4F8628C22D for ; Tue, 20 Apr 2010 14:24:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4KvP-00013e-3C; Tue, 20 Apr 2010 14:24:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:24:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/44#comment:1 Message-ID: <066.861f467932f5426f9db0ab0502e7e6d9@tools.ietf.org> References: <057.598d71d19cb14b43d07dda5b5aaa388e@tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.598d71d19cb14b43d07dda5b5aaa388e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #44: LISP vs existing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:26:50 -0000 #44: LISP vs existing -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: wmhaddad@… Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Changes (by wmhaddad@…): * owner: Yakov => wmhaddad@… -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:30:10 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B711A3A6BC9 for ; Tue, 20 Apr 2010 14:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw3NKmaXHIfj for ; Tue, 20 Apr 2010 14:30:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 655F93A68DB for ; Tue, 20 Apr 2010 14:29:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4L0m-0005fg-K7; Tue, 20 Apr 2010 14:29:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:29:40 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/44#comment:2 Message-ID: <066.f830f4e1bf4fff2638bf8b7e0382d731@tools.ietf.org> References: <057.598d71d19cb14b43d07dda5b5aaa388e@tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.598d71d19cb14b43d07dda5b5aaa388e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #44: LISP vs existing (reported by Yakov Rekhter) (was: LISP vs existing) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:30:11 -0000 #44: LISP vs existing (reported by Yakov Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Changes (by wmhaddad@…): * owner: wmhaddad@… => -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:31:49 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395BB28C0EB for ; Tue, 20 Apr 2010 14:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDhLqIBverPS for ; Tue, 20 Apr 2010 14:31:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7A7FB3A68D9 for ; Tue, 20 Apr 2010 14:31:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4L2T-0005ku-S9; Tue, 20 Apr 2010 14:31:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:31:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/45 Message-ID: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@tools.ietf.org> X-Trac-Ticket-ID: 45 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #45: LISP vs. Existing (from Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:31:49 -0000 #45: LISP vs. Existing (from Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- What LISP offers to audiences which are already using NAT? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:34:29 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1533A6977 for ; Tue, 20 Apr 2010 14:34:29 -0700 (PDT) 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.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzAXV+bGBnnT for ; Tue, 20 Apr 2010 14:34:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9D4573A68DB for ; Tue, 20 Apr 2010 14:34:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4L5G-0005pA-QS; Tue, 20 Apr 2010 14:34:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:34:18 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/46 Message-ID: <057.078f7daa8dd3209507b0e7d5bc7da39a@tools.ietf.org> X-Trac-Ticket-ID: 46 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #46: Cache Thrashing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:34:29 -0000 #46: Cache Thrashing -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Cache thrashing by hosts within a site results in sending packets to a large span of addresses and create a huge amount of LISP control traffic. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:37:01 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D242F3A69E6 for ; Tue, 20 Apr 2010 14:37:01 -0700 (PDT) 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.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmvidz4x3zLK for ; Tue, 20 Apr 2010 14:37:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 074D43A6970 for ; Tue, 20 Apr 2010 14:36:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4L7c-0005uB-Bm; Tue, 20 Apr 2010 14:36:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:36:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/47 Message-ID: <057.d106700ac7dd9e5181d1df51e88b5585@tools.ietf.org> X-Trac-Ticket-ID: 47 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #47: Ambiguity on "MAP-replies" requirements X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:37:01 -0000 #47: Ambiguity on "MAP-replies" requirements -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Ambiguity related to the existence (or not) of a clear requirements that all entities that return MAP-Replies for a given EID return the same content? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:38:35 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9185C3A6B2C for ; Tue, 20 Apr 2010 14:38:35 -0700 (PDT) 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.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC1+e7XOERW7 for ; Tue, 20 Apr 2010 14:38:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 22CDA3A696C for ; Tue, 20 Apr 2010 14:38:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4L9F-0005v4-Db; Tue, 20 Apr 2010 14:38:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:38:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/48 Message-ID: <057.8523523dc5d63eadc78f4c87ce8cf0b1@tools.ietf.org> X-Trac-Ticket-ID: 48 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #48: MAP-Replies returning different contents for a given EID X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:38:35 -0000 #48: MAP-Replies returning different contents for a given EID -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- What are the consequences if two entities do return MAP-replies with different contents for a given EID? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:39:18 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A713A6BB4 for ; Tue, 20 Apr 2010 14:39:18 -0700 (PDT) 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.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEKmC2A1wXzw for ; Tue, 20 Apr 2010 14:39:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 294513A69E6 for ; Tue, 20 Apr 2010 14:39:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4L9x-0005vo-Gm; Tue, 20 Apr 2010 14:39:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:39:09 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/48#comment:1 Message-ID: <066.e19edb3e693a8a15d0dc6dff299c96d1@tools.ietf.org> References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.8523523dc5d63eadc78f4c87ce8cf0b1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) (was: MAP-Replies returning different contents for a given EID) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:39:18 -0000 #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:42:21 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101623A688A for ; Tue, 20 Apr 2010 14:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJs5ougmnHqy for ; Tue, 20 Apr 2010 14:42:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 347293A683A for ; Tue, 20 Apr 2010 14:42:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4LCt-00063l-EK; Tue, 20 Apr 2010 14:42:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:42:11 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/49 Message-ID: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@tools.ietf.org> X-Trac-Ticket-ID: 49 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #49: "MAP-Replies" content that is allowed to change (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:42:21 -0000 #49: "MAP-Replies" content that is allowed to change (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- If MAP-Replies content for a given EID are not supposed to change then what is the content that is allowed to vary (Locator status bits?) -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:57:29 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28943A69C2 for ; Tue, 20 Apr 2010 14:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL1x6+N4RZgq for ; Tue, 20 Apr 2010 14:57:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5B4AB3A696C for ; Tue, 20 Apr 2010 14:57:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4LRW-0008Js-LJ; Tue, 20 Apr 2010 14:57:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:57:18 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/50 Message-ID: <057.6fdc264209fe6bed0510ab4c5ab17307@tools.ietf.org> X-Trac-Ticket-ID: 50 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #50: MAP-Replies content that MUST be invariant (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:57:29 -0000 #50: MAP-Replies content that MUST be invariant (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- If MAP-Replies content for a given EID are not supposed to change then what is the content that MUST be invariant? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 14:59:45 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9752C3A69FB for ; Tue, 20 Apr 2010 14:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTAuiajqlG09 for ; Tue, 20 Apr 2010 14:59:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1287C3A6B30 for ; Tue, 20 Apr 2010 14:59:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4LTj-0008LS-DO; Tue, 20 Apr 2010 14:59:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 21:59:35 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/51 Message-ID: <057.afb9a72f6ee9de02e699ffa4cc31fd68@tools.ietf.org> X-Trac-Ticket-ID: 51 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #51: Returning same locator-set for a given EID (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 21:59:45 -0000 #51: Returning same locator-set for a given EID (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- How to achieve returning the same locator-set for a given EID (when required)? Is it via manual configuration of each entity that returns MAP- Replies for that EID or some other way? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 15:05:06 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82CF3A681D for ; Tue, 20 Apr 2010 15:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB4PZScpPY9y for ; Tue, 20 Apr 2010 15:05:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9CDF03A6765 for ; Tue, 20 Apr 2010 15:05:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4LYs-0008UZ-PN; Tue, 20 Apr 2010 15:04:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 22:04:54 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/52 Message-ID: <057.30e7849be4822f54ea2e1c1dc2858937@tools.ietf.org> X-Trac-Ticket-ID: 52 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #52: Changing the EID-to-RLOC Mapping (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 22:05:06 -0000 #52: Changing the EID-to-RLOC Mapping (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Under what circumstances an EID-to-RLOC mapping might change? Can the change result only from provisioning/configuration or as a reaction to the network's operational state (e.g., temporary loss of reachability from a given ETR to a given EID)? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 15:06:27 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CDF3A6864 for ; Tue, 20 Apr 2010 15:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z5NLdkCgn1e for ; Tue, 20 Apr 2010 15:06:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3C9F03A6765 for ; Tue, 20 Apr 2010 15:06:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4LaC-00007f-E5; Tue, 20 Apr 2010 15:06:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 22:06:16 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/46#comment:1 Message-ID: <066.3b68e19e4d871093ac29321771743048@tools.ietf.org> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <057.078f7daa8dd3209507b0e7d5bc7da39a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter) (was: Cache Thrashing) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 22:06:27 -0000 #46: Cache Thrashing (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 15:07:23 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC1F3A6950 for ; Tue, 20 Apr 2010 15:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhcsxIyWLh1W for ; Tue, 20 Apr 2010 15:07:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5ADE83A68E8 for ; Tue, 20 Apr 2010 15:07:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Lb7-0000Ia-LE; Tue, 20 Apr 2010 15:07:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 22:07:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/47#comment:1 Message-ID: <066.7c3b3b156e38ed5ed638e6fe55f95ce8@tools.ietf.org> References: <057.d106700ac7dd9e5181d1df51e88b5585@tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <057.d106700ac7dd9e5181d1df51e88b5585@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #47: Ambiguity on "MAP-replies" requirements (review by Y. Rekhter) (was: Ambiguity on "MAP-replies" requirements) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 22:07:23 -0000 #47: Ambiguity on "MAP-replies" requirements (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 15:12:52 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A13D3A69A5 for ; Tue, 20 Apr 2010 15:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tdP3iniaYmh for ; Tue, 20 Apr 2010 15:12:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EEBB43A67FA for ; Tue, 20 Apr 2010 15:12:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4LgP-0005fR-MP; Tue, 20 Apr 2010 15:12:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 22:12:41 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/53 Message-ID: <057.cd86d557ebd472d3854de590d8c2facd@tools.ietf.org> X-Trac-Ticket-ID: 53 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #53: Reachability between ETR and EID (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 22:12:52 -0000 #53: Reachability between ETR and EID (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Suppose a certain EID's mapping entry -returned at some point in the past in the MAP-Reply by ETR2- lists the RLOCs of two ETRs (ETR1 and ETR2). Suppose that later on, due to connectivity issues with the site, ETR1 is able to reach the EID but ETR2 is not. Is there some means by which traffic is expected to reliably reach the EID in this case? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 15:17:42 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1450E3A6B3A for ; Tue, 20 Apr 2010 15:17:42 -0700 (PDT) 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.046, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxQ3VAbuQ4TQ for ; Tue, 20 Apr 2010 15:17:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8A1173A6A8C for ; Tue, 20 Apr 2010 15:17:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Lkw-0002r2-Sx; Tue, 20 Apr 2010 15:17:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 22:17:22 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/54 Message-ID: <057.093d2c7c4ec1aa4a073e2bbc71fa8fba@tools.ietf.org> X-Trac-Ticket-ID: 54 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #54: ITR failures and implications on connectivity restoration time (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 22:17:42 -0000 #54: ITR failures and implications on connectivity restoration time (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- A scenario where an ITR fails would result in shifting a large fraction or all the flows that used to go through one ITR to another ITR. Note that in this scenario the arrival rate of the flows at the new ITR is determined by the total number of flows being shifted (e.g., in the case of an ITR failure it is the number of flows that used to go through the old ITR), and not by the steady state arrival rate of flows. Therefore, in this scenario the rate with which the new ITR has to resolve EID-RLOC mapping is determined not by the arrival rate of flows in the steady state, but by the total number of flows being moved to the new ITR, and the latter may be significantly higher than the former. Even if we assume that all flows are TCP-based (no UDP-based flows at all), then while the arrival rate of the first few packets at the beginning of such flows is determined by the SYN retransmission time (and thus could be fairly low), this is not the case for the arrival rate of the packets in the middle of such flows, which could be Mb/sec, or even Gb/sec. Thus the amount of dropped packets (if ITR drops packets while resolving EID-RLOC mapping) or buffered packets (if ITR buffers packets while resolving EID-RLOC mapping) in a situation where a failure results in a whole bunch of existing flows being rerouted to a new ITR is going to me much higher than in the steady state. Note than none of this occurs with today's routing. That means that in the presence of ITR failure LISP would negatively impact connectivity restoration time relative to what we have today, as well as the service availability. An approach, where instead of dropping packets, an implementation would queue packets would require additional memory on the router, which at the minimum would increase the cost (and therefore the price) of the router. Moreover, in the scenario where a failure of one ITR would result in shifting all the flows that used to go through that ITR to another ITR, if the number of flows is large and/or flows are of high bandwidth it may be unfeasible to queue all these packets on the new ITR. One can not claim that the problem of how to handle data while resolving EID-RLOC mapping is a local problem for which there are local incremental fixes, as there are no practical solutions to this problem on the table at all, and thus one can not claim that such problem could be solved by local incremental fixes. Since this problem is likely to manifest itself most visibly at large scale deployment, it would be inappropriate to wait with solving this problem until large scale deployment - this problem needs to be solved before any large scale deployment of LISP, or any large scale deployment of LISP should be put on hold until a practical solution to this problem is developed. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 15:20:49 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8013A6937 for ; Tue, 20 Apr 2010 15:20:49 -0700 (PDT) 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.046, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBaD7vFU9PGb for ; Tue, 20 Apr 2010 15:20:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7656A3A6B20 for ; Tue, 20 Apr 2010 15:19:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4LnI-000819-7g; Tue, 20 Apr 2010 15:19:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 22:19:48 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/55 Message-ID: <057.cfd7e4056637dce0c518d9d74eaa3c20@tools.ietf.org> X-Trac-Ticket-ID: 55 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #55: ETR failure and its implications on connectivity restoration time (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 22:20:49 -0000 #55: ETR failure and its implications on connectivity restoration time (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- In today's routing global BGP convergence is NOT required for connectivity restoration. In other words, IP connectivity restoration takes less time than what it takes to propagate fault information throughout the Internet (or for that matter even throughout a site). With LISP connectivity, restoration requires to propagate fault all the way to the ITRs. In addition, if one relies on Loc-Status-Bits to determine that a particular RLOC is down, connectivity restoration would also require to propagate fault information from one ITR to another. In some case this may not be feasible (e.g., ETRs are PEs). And even in the cases where it is feasible, that is likely to increase connectivity restoration time. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Tue Apr 20 15:50:22 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760D73A6AFB for ; Tue, 20 Apr 2010 15:50:22 -0700 (PDT) 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.046, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz2S5fPWa5lw for ; Tue, 20 Apr 2010 15:50:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 717323A6953 for ; Tue, 20 Apr 2010 15:50:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4MGh-0005V9-DD; Tue, 20 Apr 2010 15:50:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wmhaddad@gmail.com X-Trac-Project: lisp Date: Tue, 20 Apr 2010 22:50:11 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/56 Message-ID: <057.1115c19bef2f95ed5ab5761e0cecbaec@tools.ietf.org> X-Trac-Ticket-ID: 56 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #56: ETR unreachability (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Apr 2010 22:50:22 -0000 #56: ETR unreachability (review by Y. Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Consider the following example: ETR1 ITR ETR2 Originally both ETR1 and ETR2 claim to be RLOCs for EIDs 10.1.1/24 and 10.1/16. So, when ITR sends Map-Request to ETR1 for 10.1.5.1, ETR1 returns both 10.1/16 and 10.1.1/24 as EID prefixes, with ETR1 and ETR2 as RLOCs for these EIDs. Assume that at some later point ETR1 is no longer an RLOC for 10.1.1/24, but still is an RLOC for 10.1/16, while ETR2 still is an RLOC for both 10.1.1/24 and 10.1/16. Would ETR1 be required to inform ITR that it is no longer an RLOC for 10.1.1/24 ? If not then assume that later on a site behind the ITR originates a packet for 10.1.1.1. Assume that the ITR selects ETR1 as the best RLOC for 10.1.1/24. So, the ITR sends the packet to ETR1. How would ITR ultimately decide to stop sending the packets destined to 10.1.1.1 to ETR1 and instead switch to ETR2 ? If ETR1 be required to inform ITR that it is no longer an RLOC for 10.1.1/24, then what mechanisms, other than the Solicited-Map-Request, ETR1 could use? If the only mechanism available is the Solicited-Map-Request, then this introduces its own set of problems, as follows. Since according to 6.5.2 the ETR "will solicit Map-Request from sites it is currently sending encapsulated data to, and only from those sites", how would that help to update the mapping if the ITR that has the old (incorrect) mapping is not the xTR to which the ETR sends the encapsulated data? Withdraw of a single EID prefix on the ETR may require this ETR to send a whole bunch of SMRs messages, in response receive a bunch of Map-Requests, and then send Map-Replies. And while doing this all the data traffic for that EID prefix is dropped on the floor. This has negative implications on the connectivity restoration time. Moreover, while the stated goal of Solicit-Map-Request is to control the rate an ETR receives Map-Requests messages, in the above scenario in order to reduce the connectivity restoration time the ETR has to send all these Solicit-Map-Requests messages as soon as ETR1 determines that it is no longer an RLOC for 10.1.1/24, which in turn would mean that it would receive a burst of Map-Requests causing potential congestion in the control plane, which could result in some of these Map-Requests being dropped. Would the ETR be required to re-send Solicit-Map-Request if it does not receive a corresponding Map-Request from the ETR to which it sent Solicit-Map-Request before? And even if Map-Request is not dropped, the corresponding Map-Reply could get dropped in transit. What would happen in this case? -- Ticket URL: lisp LISP WG document issues From menth@informatik.uni-wuerzburg.de Tue Apr 20 22:36:51 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A093A6A16 for ; Tue, 20 Apr 2010 22:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8feU8riwlcjS for ; Tue, 20 Apr 2010 22:36:50 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 0CE013A689D for ; Tue, 20 Apr 2010 22:36:49 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8E93D5AD08; Wed, 21 Apr 2010 07:36:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8C45F5ACB6; Wed, 21 Apr 2010 07:36:35 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [192.168.8.143] (unknown [91.112.99.214]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 2EBAC5CCA4; Wed, 21 Apr 2010 07:36:35 +0200 (CEST) Message-ID: <4BCE8EDC.8060505@informatik.uni-wuerzburg.de> Date: Wed, 21 Apr 2010 07:36:28 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: wmhaddad@gmail.com References: <057.093d2c7c4ec1aa4a073e2bbc71fa8fba@tools.ietf.org> In-Reply-To: <057.093d2c7c4ec1aa4a073e2bbc71fa8fba@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] #54: ITR failures and implications on connectivity restoration time (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 05:36:52 -0000 Hi, this issue is possibly a good reason why "data probing" is still useful. However, it requires that the performance of the mapping system is not impacted too much even by large amounts of deviated traffic. Best wishes, Michael lisp issue tracker schrieb: > #54: ITR failures and implications on connectivity restoration time (review by > Y. Rekhter) > -------------------------------+-------------------------------------------- > Reporter: wmhaddad@… | Owner: > Type: technical | Status: new > Priority: major | Component: draft-ietf-lisp > Severity: - | Keywords: > -------------------------------+-------------------------------------------- > A scenario where an ITR fails would result in shifting a large fraction or > all the flows that used to go through one ITR to another ITR. Note that in > this scenario the arrival rate > of the flows at the new ITR is determined by the total number of > flows being shifted (e.g., in the case of an ITR failure it is the > number of flows that used to go through the old ITR), and not by > the steady state arrival rate of flows. Therefore, in this scenario > the rate with which the new ITR has to resolve EID-RLOC mapping is > determined not by the arrival rate of flows in the steady state, > but by the total number of flows being moved to the new ITR, and > the latter may be significantly higher than the former. > > Even if we assume that all flows are TCP-based (no UDP-based flows > at all), then while the arrival rate of the first few packets at > the beginning of such flows is determined by the SYN retransmission > time (and thus could be fairly low), this is not the case for the > arrival rate of the packets in the middle of such flows, which could > be Mb/sec, or even Gb/sec. Thus the amount of dropped packets (if > ITR drops packets while resolving EID-RLOC mapping) or buffered > packets (if ITR buffers packets while resolving EID-RLOC mapping) > in a situation where a failure results in a whole bunch of existing > flows being rerouted to a new ITR is going to me much higher than > in the steady state. Note than none of this occurs with today's > routing. That means that in the presence of ITR failure LISP would > negatively impact connectivity restoration time relative to what > we have today, as well as the service availability. > > An approach, where instead of dropping packets, an implementation > would queue packets would require additional memory on the router, > which at the minimum would increase the cost (and therefore the > price) of the router. Moreover, in the scenario where a failure of > one ITR would result in shifting all the flows that used to go > through that ITR to another ITR, if the number of flows is large > and/or flows are of high bandwidth it may be unfeasible to queue > all these packets on the new ITR. > > One can not claim that the problem of how to handle data while > resolving EID-RLOC mapping is a local problem for which there are > local incremental fixes, as there are no practical solutions to > this problem on the table at all, and thus one can not claim that > such problem could be solved by local incremental fixes. Since this > problem is likely to manifest itself most visibly at large scale > deployment, it would be inappropriate to wait with solving this > problem until large scale deployment - this problem needs to be > solved before any large scale deployment of LISP, or any large scale > deployment of LISP should be put on hold until a practical solution > to this problem is developed. > > -- PD Dr. habil. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From trac@tools.ietf.org Wed Apr 21 00:22:44 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761043A69FF for ; Wed, 21 Apr 2010 00:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gomH9RW1j9nY for ; Wed, 21 Apr 2010 00:22:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E9AF43A68AD for ; Wed, 21 Apr 2010 00:22:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4UGI-0006mh-Fv; Wed, 21 Apr 2010 00:22:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 07:22:18 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/26#comment:3 Message-ID: <069.304a2ff8fe9322d944b072aaa2060387@tools.ietf.org> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #26: Overlapping Map prefixes in EID map cache X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:22:45 -0000 #26: Overlapping Map prefixes in EID map cache ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): '''Yakov Rekhter raises a related question in his review of draft-ietf- lisp-06.txt (part 2):''' Section 6.1.5 EID-to-RLOC UDP Map-Reply message A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. Why would those three prefixes be returned? A more general comment is that what a Map-Reply must return in response to a given Map-Request is underspecified (or the specification is not comprehensible). To address this perhaps insert something like the following: When an ETR replies to a Map-Request, it must reply with its EID-prefix that is the best match for the Map-Request. In addition, if it is configured with any EID-prefixes which are more-specifics of the best match EID-prefix that it returns in its Map-Reply, it must return all of those more-specific EID-prefixe s in the same Map-Reply. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 00:37:37 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFCA33A688D for ; Wed, 21 Apr 2010 00:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArW1Wo-ijVgm for ; Wed, 21 Apr 2010 00:37:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D9F4A3A6A6F for ; Wed, 21 Apr 2010 00:37:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4UUw-0003Z0-QH; Wed, 21 Apr 2010 00:37:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 07:37:24 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/32#comment:1 Message-ID: <077.693673ec0f5bf65a905d7b9a2d272fbd@tools.ietf.org> References: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:37:37 -0000 #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Comment(by luigi@…): '''Yakov Rekhter raises a related question in his review of draft-ietf- lisp-06.txt (part 2):''' Section 6.2 This section uses "client-side" and "server-side" extensively without defining the terms. They seem to be the same as "ITR" and "ETR" in the rest of the document. Terminology should be defined or harmonized with the rest of the document. -- Ticket URL: lisp LISP WG document issues From Dimitri.Papadimitriou@alcatel-lucent.com Wed Apr 21 00:39:19 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D353A6A84 for ; Wed, 21 Apr 2010 00:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfqF412dVjX0 for ; Wed, 21 Apr 2010 00:39:18 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 21AEC3A6405 for ; Wed, 21 Apr 2010 00:39:17 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3L7bM3k007791; Wed, 21 Apr 2010 09:39:03 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 09:39:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 09:38:45 +0200 Message-ID: <00275A5B436CA441900CB10936742A380434E365@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <068.4f04af5743fd47e6fd9db1056dddf420@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #30: Editorial Issues Section 3 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review Thread-Index: AcrgW56FN9nwQ5fMSdGLMVu0X7TygwAxRoLQ References: <068.4f04af5743fd47e6fd9db1056dddf420@tools.ietf.org> From: "PAPADIMITRIOU Dimitri" To: , X-OriginalArrivalTime: 21 Apr 2010 07:39:01.0004 (UTC) FILETIME=[B59634C0:01CAE125] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: lisp@ietf.org Subject: Re: [lisp] #30: Editorial Issues Section 3 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:39:19 -0000 > Section 3. The most important definition "EID-to-RLOC mapping lookup" > is missing. In particular, how a ITR knows that the "incoming" > destination address is part of an EID prefix ? More generally which > event or condition triggers such lookup ? I will clarify with an example: assume that routers hosting ITR and ETR function are connected directly (up), or by means of a path through reachable RLOC (RLOC_2). --------------------------- | | --- --- EID_1>---|ITR|-----------------------|ETR|--->EID_2 --- RLOC_1 RLOC_2 --- which path to follow (in such hybrid configuration) ? what triggers EID-to-RLOC mapping lookup to make packets flowing to EID_2 via RLOC_2 ? is it the source EID (but then how to distinguish local traffic) ? =20 Remember that LISP1.5 uses EIDs that are routable for bootstrapping EID-to-RLOC mappings. The more general question is thus EID are routable before being "mappable" hence which conditions ensure they become mappable. Nothing is stated. Thanks, -dimitri. =20 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of lisp issue tracker > Sent: Tuesday, April 20, 2010 9:32 AM > To: luigi@net.t-labs.tu-berlin.de > Cc: lisp@ietf.org > Subject: [lisp] #30: Editorial Issues Section 3 of=20 > draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review >=20 > #30: Editorial Issues Section 3 of draft-ietf-lisp-06.txt=20 > raised by Dimitri > Papadimitriou in his review > ------------------------------------------+------------------- > -------------- > Reporter: luigi@... | Owner: =20 > =20 > Type: editorial | Status: new=20 > =20 > Priority: minor | Component: =20 > draft-ietf-lisp > Severity: - | Keywords: =20 > =20 > ------------------------------------------+------------------- > -------------- > Section 3. The definition of Provider Independent (PI) Addresses > states what a PI is not instead of defining what a PI is. Also the > document refers to EID prefixes and EID "blocks" what is a=20 > "block" and > a "sub-block"? >=20 > Section 3. Definition of PA "LISP uses only=20 > topologically-assigned and > aggregatable address blocks for RLOCs, eliminating this=20 > demonstrably non- > scalable practice". Provide a reference of such demonstration. >=20 > Section 3. ITR/ETR are described as routers while they are actually > functions. Describe them as functions instead of "routers". >=20 > Section 3. Definition of RLOC seems to be limited to ETR.=20 > Thus how ITR > set the Source RLOC ? Section 7 (third bullet) makes this assignment > even less understandable (the well-defined concept of VRF suddenly > appears). >=20 > Section 3. The most important definition "EID-to-RLOC mapping lookup" > is missing. In particular, how a ITR knows that the "incoming" > destination address is part of an EID prefix ? More generally which > event or condition triggers such lookup ? >=20 > --=20 > Ticket URL: > lisp > LISP WG document issues > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 From trac@tools.ietf.org Wed Apr 21 00:59:49 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED20B3A69A2 for ; Wed, 21 Apr 2010 00:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.626 X-Spam-Level: X-Spam-Status: No, score=-100.626 tagged_above=-999 required=5 tests=[AWL=-1.884, BAYES_00=-2.599, FRT_PROFIT1=3.858, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6LV6Yd9yZaT for ; Wed, 21 Apr 2010 00:59:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1C2A23A6960 for ; Wed, 21 Apr 2010 00:59:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4UqR-0006HP-8L; Wed, 21 Apr 2010 00:59:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 07:59:39 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/43#comment:1 Message-ID: <077.61d6b555ec9b30ae9eddb5ff8471eb45@tools.ietf.org> References: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #43: Issues related to RLOC rechability (definition and mechanism) (was: Issues related to RLOC rechability (definition and mechanism) raised by D. Papadimitriou in his review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:59:50 -0000 #43: Issues related to RLOC rechability (definition and mechanism) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 6.1.5 where is the “Data Probe packet†format defined actually ? > > Section 6.1.5 states “The RLOCs in the Map-Reply are the > globally-routable IP addresses of the ETR but are not necessarily > reachable; separate testing of reachability is required.†Section 6.3 > does not define any procedure actually and does not define any > criteria for deciding when the RLOC is reachable or not. The key > question is if the ITR persists in testing reachability and there is > no criteria process by which such decision would stop, the traffic > would be forwarded by means of the “separate/alternative topology†> forever. > > Section 6.3 proposes “encapsulated traffic†based procedures thus, if > there is no traffic there is no RLOC reachability “test†possible. On > the other hand, that section states certain “ICMP exchanges†are > documented but reachability of RLOC does not mean availability of the > associated EID. There no actual “EID-to-RLOC†testing procedure being > defined in the document? > > What is struggling here is that the “introductory†sections of the > document refer to “functional†separations but all the techniques > described in this document (and for RLOC reachability testing in > particular) result in a complex inter-twin between control messaging > as part of the forwarding plane and forwarding date as part of the > control plane of routers. The latter is typical from Data Probes > processing. If this is the design choice of LISP so let it be but 1) > please proof it offers any better functionality compared to “current†> design and 2) better cost/performance. It is far from obvious that the > complexity concentrated at TR taking into the proposed design offers > any real compelling argument. This may also defeat the argument stated > in the introduction that “network deployment†is facilitated by > network-based solutions. > > Section 6.3 Point 1 what is the use of the “Loc-Status-Bits†if there > is no return traffic (or more precisely no return traffic passing via > this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The > ETR may process this information but never use it. > > Section 6.3 states “Each ITR can thus observe the presence or lack of > a default route originated by the others to determine the Locator > Status Bits it sets for them.†This does not tell which technique to > use when no default route are used at all (under “non-normal†> circumstances … what should define normality in this context). > > Section 6.3.1 states “This mechanism does not completely solve the > forward path reachability problem as traffic may be unidirectional.†> The forwarding path may simply be asymmetric (there is nothing that > imposes reverse path reaching the source RLOC in case of dual attached > sites). This shortcoming defeats this mechanism as an ITR is not > “aware†of its neighboring ITR EID-to-RLOC mappings (connected to the > same site). This mechanism can only be safely used if the RLOC pair > between two sites is unique and remains unique. > > Section 6.3.2 RLOC Probing by means of the “control plane†this opens > the question of what is actually probed the “RLOC†or the EID-to-RLOC > entries of the ETR’s database. The difference stems because the latter > are static entries the liveness of the former are dependent on the > incoming interface liveness. That is entries can be available in the > database but if database entries are not in sync with the actual RLOC > status there is no possibility to detect reachability of RLOCs by > means of this mechanism. New description: '''This ticket groups together several inter-related issues concerning RLOC reachability raised by both D. Papadimitriou and Y. Rekhter in their respective review. (''If people identify specific and isolated issues that would like to see in different tickets please let me know'').''' '''From P. Papadimitriou's Review:''' Section 6.1.5 where is the “Data Probe packet†format defined actually ? Section 6.1.5 states “The RLOCs in the Map-Reply are the globally-routable IP addresses of the ETR but are not necessarily reachable; separate testing of reachability is required.†Section 6.3 does not define any procedure actually and does not define any criteria for deciding when the RLOC is reachable or not. The key question is if the ITR persists in testing reachability and there is no criteria process by which such decision would stop, the traffic would be forwarded by means of the “separate/alternative topology†forever. Section 6.3 proposes “encapsulated traffic†based procedures thus, if there is no traffic there is no RLOC reachability “test†possible. On the other hand, that section states certain “ICMP exchanges†are documented but reachability of RLOC does not mean availability of the associated EID. There no actual “EID-to-RLOC†testing procedure being defined in the document? What is struggling here is that the “introductory†sections of the document refer to “functional†separations but all the techniques described in this document (and for RLOC reachability testing in particular) result in a complex inter-twin between control messaging as part of the forwarding plane and forwarding date as part of the control plane of routers. The latter is typical from Data Probes processing. If this is the design choice of LISP so let it be but 1) please proof it offers any better functionality compared to “current†design and 2) better cost/performance. It is far from obvious that the complexity concentrated at TR taking into the proposed design offers any real compelling argument. This may also defeat the argument stated in the introduction that “network deployment†is facilitated by network-based solutions. Section 6.3 Point 1 what is the use of the “Loc-Status-Bits†if there is no return traffic (or more precisely no return traffic passing via this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The ETR may process this information but never use it. Section 6.3 states “Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them.†This does not tell which technique to use when no default route are used at all (under “non-normal†circumstances … what should define normality in this context). Section 6.3.1 states “This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional.†The forwarding path may simply be asymmetric (there is nothing that imposes reverse path reaching the source RLOC in case of dual attached sites). This shortcoming defeats this mechanism as an ITR is not “aware†of its neighboring ITR EID-to-RLOC mappings (connected to the same site). This mechanism can only be safely used if the RLOC pair between two sites is unique and remains unique. Section 6.3.2 RLOC Probing by means of the “control plane†this opens the question of what is actually probed the “RLOC†or the EID-to-RLOC entries of the ETR’s database. The difference stems because the latter are static entries the liveness of the former are dependent on the incoming interface liveness. That is entries can be available in the database but if database entries are not in sync with the actual RLOC status there is no possibility to detect reachability of RLOCs by means of this mechanism. ''' From Y. Rekhter's Review:''' Section 6.3 Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. For the first mechanism to work it is not sufficient for the ETR to have traffic "to return to the original ITR site" - the ETR has to have traffic to return to the original ITR. And if the ETR has no traffic to return to the original ITR (even if the ETR has traffic to return to some other ITR of the site), then the first mechanism is useless. Moreover, the first mechanism is predicated on the assumption that the Loc-Status-Bits contain up to date information about reachability of all ETRs at the site. The document describes how the ITR obtains this information only for the case of CE-based or intra-site based ITRs. Thus it does not cover the case where the ITR is the PE. Moreover, for the case of CE-based ITR the scheme does not work if the site runs RIP as its IGP. Furthermore it assumes that just because the correspondent ITR can reach the given RLOC, the ETR also will. Since IP connectivity is not always transitive in this way, the fact that the corresponding ITR can reach the given RLOC does not mean that the ETR also can. The second mechanism depends on ICMP Unreachable. As such it may result in sustained traffic blackholing due to ICMP Unreachable being dropped along the path. Also, how would that mechanism handle DoS attacks caused by spoofed ICMP Unreachables ? Finally, if ITR is within a site, and behind a firewall, would the firewall pass ICMP Unreachables in the first place ? The third mechanism is likely to be of very limited use, as an ETR going down is unlikely to cause the route that covers the RLOC of that ETR to be withdrawn (unless this is /32 route). The fourth mechanism is applicable only for LISP interworking between a LISP and a non-LISP site. The fifth and the sixth mechanisms do provide the indication that the ETR is up, but do not provide the information when the ETR is down. As such they are not applicable for determining unreachability, as unreachability requires the ability to determine that the ETR is down. That leaves us with the seventh mechanism. This mechanism offers two options: Echo Nonce (section 6.3.1) and RLOC Probing (section 6.3.2). The Echo Nonce mechanism is applicable only when there is a bidirectional flow between a pair of RLOCs. The RLOC Probing mechanism has scaling limitations - quoting from 6.3.2: The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times are very small. Given the above, what are the mechanisms that are available when xTRs are PEs (as described in 8.3), and what are their scaling characteristics ? Consider an example of site A with two xTRs A1 and A2, and site B with two xTRs, B1 and B2. Now imagine that outbound traffic from A to B is using the ITR component of A1, and talking to the ETR component B1 of B. But the traffic from B back to A uses the ITR component of B2 and is sending to the ETR component of A2. So each ITR->ETR flow is unidirectional, even though all four devices are fully capable of bidirectional communication. What are the options for the RLOC reachability in this scenario ? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 01:02:57 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA7D28C0DE for ; Wed, 21 Apr 2010 01:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.615 X-Spam-Level: X-Spam-Status: No, score=-100.615 tagged_above=-999 required=5 tests=[AWL=-1.873, BAYES_00=-2.599, FRT_PROFIT1=3.858, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p97hYFsB8uP for ; Wed, 21 Apr 2010 01:02:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B9E4D3A6A89 for ; Wed, 21 Apr 2010 01:02:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4UtN-0006Pt-Ss; Wed, 21 Apr 2010 01:02:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 08:02:41 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/43#comment:2 Message-ID: <077.5d062d890c0e06415b2a571c1a5ca987@tools.ietf.org> References: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #43: Issues related to RLOC rechability (definition and mechanism) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:02:58 -0000 #43: Issues related to RLOC rechability (definition and mechanism) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > '''This ticket groups together several inter-related issues concerning > RLOC reachability raised by both D. Papadimitriou and Y. Rekhter in their > respective review. (''If people identify specific and isolated issues > that would like to see in different tickets please let me know'').''' > > '''From P. Papadimitriou's Review:''' > > Section 6.1.5 where is the “Data Probe packet†format defined actually ? > > Section 6.1.5 states “The RLOCs in the Map-Reply are the > globally-routable IP addresses of the ETR but are not necessarily > reachable; separate testing of reachability is required.†Section 6.3 > does not define any procedure actually and does not define any > criteria for deciding when the RLOC is reachable or not. The key > question is if the ITR persists in testing reachability and there is > no criteria process by which such decision would stop, the traffic > would be forwarded by means of the “separate/alternative topology†> forever. > > Section 6.3 proposes “encapsulated traffic†based procedures thus, if > there is no traffic there is no RLOC reachability “test†possible. On > the other hand, that section states certain “ICMP exchanges†are > documented but reachability of RLOC does not mean availability of the > associated EID. There no actual “EID-to-RLOC†testing procedure being > defined in the document? > > What is struggling here is that the “introductory†sections of the > document refer to “functional†separations but all the techniques > described in this document (and for RLOC reachability testing in > particular) result in a complex inter-twin between control messaging > as part of the forwarding plane and forwarding date as part of the > control plane of routers. The latter is typical from Data Probes > processing. If this is the design choice of LISP so let it be but 1) > please proof it offers any better functionality compared to “current†> design and 2) better cost/performance. It is far from obvious that the > complexity concentrated at TR taking into the proposed design offers > any real compelling argument. This may also defeat the argument stated > in the introduction that “network deployment†is facilitated by > network-based solutions. > > Section 6.3 Point 1 what is the use of the “Loc-Status-Bits†if there > is no return traffic (or more precisely no return traffic passing via > this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The > ETR may process this information but never use it. > > Section 6.3 states “Each ITR can thus observe the presence or lack of > a default route originated by the others to determine the Locator > Status Bits it sets for them.†This does not tell which technique to > use when no default route are used at all (under “non-normal†> circumstances … what should define normality in this context). > > Section 6.3.1 states “This mechanism does not completely solve the > forward path reachability problem as traffic may be unidirectional.†> The forwarding path may simply be asymmetric (there is nothing that > imposes reverse path reaching the source RLOC in case of dual attached > sites). This shortcoming defeats this mechanism as an ITR is not > “aware†of its neighboring ITR EID-to-RLOC mappings (connected to the > same site). This mechanism can only be safely used if the RLOC pair > between two sites is unique and remains unique. > > Section 6.3.2 RLOC Probing by means of the “control plane†this opens > the question of what is actually probed the “RLOC†or the EID-to-RLOC > entries of the ETR’s database. The difference stems because the latter > are static entries the liveness of the former are dependent on the > incoming interface liveness. That is entries can be available in the > database but if database entries are not in sync with the actual RLOC > status there is no possibility to detect reachability of RLOCs by > means of this mechanism. > > > ''' From Y. Rekhter's Review:''' > > Section 6.3 > Several mechanisms for determining RLOC reachability are currently > defined: > > 1. An ETR may examine the Loc-Status-Bits in the LISP header of an > encapsulated data packet received from an ITR. If the ETR is also acting > as an ITR and has traffic to return to the original ITR site, it can use > this status information to help select an > RLOC. > > 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message > for an RLOC it is using. This indicates that the RLOC is likely down. > > 3. An ITR which participates in the global routing system can > determine that an RLOC is down if no BGP RIB route exists that matches > the RLOC IP address. > > 4. An ITR may receive an ICMP Port Unreachable message from a > destination host. This occurs if an ITR attempts to use interworking > [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable > site. > > 5. An ITR may receive a Map-Reply from a ETR in response to a > previously sent Map-Request. The RLOC source of the Map-Reply is > likely up since the ETR was able to send the Map-Reply to the ITR. > > 6. When an ETR receives an encapsulated packet from an ITR, the source > RLOC from the outer header of the packet is likely up. > > 7. An ITR/ETR pair can use the Locator Reachability Algorithms > described in this section, namely Echo-Noncing or RLOC-Probing. > > For the first mechanism to work it is not sufficient for the ETR to > have traffic "to return to the original ITR site" - the ETR has to > have traffic to return to the original ITR. And if the ETR has no > traffic to return to the original ITR (even if the ETR has traffic to > return to some other ITR of the site), then the first mechanism is > useless. > > Moreover, the first mechanism is predicated on the assumption that the > Loc-Status-Bits contain up to date information about reachability > of all ETRs at the site. The document describes how the ITR obtains > this information only for the case of CE-based or intra-site based > ITRs. Thus it does not cover the case where the ITR is the > PE. Moreover, for the case of CE-based ITR the scheme does not work if > the site runs RIP as its IGP. Furthermore it assumes that just because > the correspondent ITR can reach the given RLOC, the ETR also > will. Since IP connectivity is not always transitive in this > way, the fact that the corresponding ITR can reach the given RLOC does > not mean that the ETR also can. > > The second mechanism depends on ICMP Unreachable. As such it may > result in sustained traffic blackholing due to ICMP Unreachable being > dropped along the path. Also, how would that mechanism handle DoS > attacks caused by spoofed ICMP Unreachables ? Finally, if ITR > is within a site, and behind a firewall, would the firewall pass ICMP > Unreachables in the first place ? > > The third mechanism is likely to be of very limited use, as an ETR > going down is unlikely to cause the route that covers the RLOC of that > ETR to be withdrawn (unless this is /32 route). > > The fourth mechanism is applicable only for LISP interworking between > a LISP and a non-LISP site. > > The fifth and the sixth mechanisms do provide the indication that the > ETR is up, but do not provide the information when the ETR is down. As > such they are not applicable for determining unreachability, as > unreachability requires the ability to determine that the ETR is down. > > That leaves us with the seventh mechanism. This mechanism offers two > options: Echo Nonce (section 6.3.1) and RLOC Probing (section > 6.3.2). The Echo Nonce mechanism is applicable only when there is a > bidirectional flow between a pair of RLOCs. The RLOC Probing mechanism > has scaling limitations - quoting from 6.3.2: > > The major disadvantage of RLOC Probing is in the number of control > messages required and the amount of bandwidth used to obtain those > benefits, especially if the requirement for failure detection times > are very small. > > Given the above, what are the mechanisms that are available when xTRs > are PEs (as described in 8.3), and what are their scaling > characteristics ? > > Consider an example of site A with two xTRs A1 and A2, and site B with > two xTRs, B1 and B2. Now imagine that outbound traffic from A to B is > using the ITR component of A1, and talking to the ETR component B1 of > B. But the traffic from B back to A uses the ITR component of B2 and > is sending to the ETR component of A2. So each ITR->ETR flow is > unidirectional, even though all four devices are > fully capable of bidirectional communication. What are the options for > the RLOC reachability in this scenario ? New description: '''This ticket groups together several inter-related issues concerning RLOC reachability raised by both D. Papadimitriou and Y. Rekhter in their respective review. (''If people identify specific and isolated issues that would like to see in different tickets please let me know'').''' '''From P. Papadimitriou's Review:''' Section 6.1.5 where is the “Data Probe packet†format defined actually ? Section 6.1.5 states “The RLOCs in the Map-Reply are the globally-routable IP addresses of the ETR but are not necessarily reachable; separate testing of reachability is required.†Section 6.3 does not define any procedure actually and does not define any criteria for deciding when the RLOC is reachable or not. The key question is if the ITR persists in testing reachability and there is no criteria process by which such decision would stop, the traffic would be forwarded by means of the “separate/alternative topology†forever. Section 6.3 proposes “encapsulated traffic†based procedures thus, if there is no traffic there is no RLOC reachability “test†possible. On the other hand, that section states certain “ICMP exchanges†are documented but reachability of RLOC does not mean availability of the associated EID. There no actual “EID-to-RLOC†testing procedure being defined in the document? What is struggling here is that the “introductory†sections of the document refer to “functional†separations but all the techniques described in this document (and for RLOC reachability testing in particular) result in a complex inter-twin between control messaging as part of the forwarding plane and forwarding date as part of the control plane of routers. The latter is typical from Data Probes processing. If this is the design choice of LISP so let it be but 1) please proof it offers any better functionality compared to “current†design and 2) better cost/performance. It is far from obvious that the complexity concentrated at TR taking into the proposed design offers any real compelling argument. This may also defeat the argument stated in the introduction that “network deployment†is facilitated by network-based solutions. Section 6.3 Point 1 what is the use of the “Loc-Status-Bits†if there is no return traffic (or more precisely no return traffic passing via this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The ETR may process this information but never use it. Section 6.3 states “Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them.†This does not tell which technique to use when no default route are used at all (under “non-normal†circumstances … what should define normality in this context). Section 6.3.1 states “This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional.†The forwarding path may simply be asymmetric (there is nothing that imposes reverse path reaching the source RLOC in case of dual attached sites). This shortcoming defeats this mechanism as an ITR is not “aware†of its neighboring ITR EID-to-RLOC mappings (connected to the same site). This mechanism can only be safely used if the RLOC pair between two sites is unique and remains unique. Section 6.3.2 RLOC Probing by means of the “control plane†this opens the question of what is actually probed the “RLOC†or the EID-to-RLOC entries of the ETR’s database. The difference stems because the latter are static entries the liveness of the former are dependent on the incoming interface liveness. That is entries can be available in the database but if database entries are not in sync with the actual RLOC status there is no possibility to detect reachability of RLOCs by means of this mechanism. ''' From Y. Rekhter's Review:''' Section 6.3 Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. For the first mechanism to work it is not sufficient for the ETR to have traffic "to return to the original ITR site" - the ETR has to have traffic to return to the original ITR. And if the ETR has no traffic to return to the original ITR (even if the ETR has traffic to return to some other ITR of the site), then the first mechanism is useless. Moreover, the first mechanism is predicated on the assumption that the Loc-Status-Bits contain up to date information about reachability of all ETRs at the site. The document describes how the ITR obtains this information only for the case of CE-based or intra-site based ITRs. Thus it does not cover the case where the ITR is the PE. Moreover, for the case of CE-based ITR the scheme does not work if the site runs RIP as its IGP. Furthermore it assumes that just because the correspondent ITR can reach the given RLOC, the ETR also will. Since IP connectivity is not always transitive in this way, the fact that the corresponding ITR can reach the given RLOC does not mean that the ETR also can. The second mechanism depends on ICMP Unreachable. As such it may result in sustained traffic blackholing due to ICMP Unreachable being dropped along the path. Also, how would that mechanism handle DoS attacks caused by spoofed ICMP Unreachables ? Finally, if ITR is within a site, and behind a firewall, would the firewall pass ICMP Unreachables in the first place ? The third mechanism is likely to be of very limited use, as an ETR going down is unlikely to cause the route that covers the RLOC of that ETR to be withdrawn (unless this is /32 route). The fourth mechanism is applicable only for LISP interworking between a LISP and a non-LISP site. The fifth and the sixth mechanisms do provide the indication that the ETR is up, but do not provide the information when the ETR is down. As such they are not applicable for determining unreachability, as unreachability requires the ability to determine that the ETR is down. That leaves us with the seventh mechanism. This mechanism offers two options: Echo Nonce (section 6.3.1) and RLOC Probing (section 6.3.2). The Echo Nonce mechanism is applicable only when there is a bidirectional flow between a pair of RLOCs. The RLOC Probing mechanism has scaling limitations - quoting from 6.3.2: The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times are very small. Given the above, what are the mechanisms that are available when xTRs are PEs (as described in 8.3), and what are their scaling characteristics ? Consider an example of site A with two xTRs A1 and A2, and site B with two xTRs, B1 and B2. Now imagine that outbound traffic from A to B is using the ITR component of A1, and talking to the ETR component B1 of B. But the traffic from B back to A uses the ITR component of B2 and is sending to the ETR component of A2. So each ITR->ETR flow is unidirectional, even though all four devices are fully capable of bidirectional communication. What are the options for the RLOC reachability in this scenario ? The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. How would one use data packets for testing locator reachability ? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 01:18:18 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94EF3A6A72 for ; Wed, 21 Apr 2010 01:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E20POCD4Nn0 for ; Wed, 21 Apr 2010 01:18:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AD7623A6822 for ; Wed, 21 Apr 2010 01:18:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4V8K-0008II-05; Wed, 21 Apr 2010 01:18:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 08:18:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/33#comment:1 Message-ID: <077.a90e1d2c7e2769478555c338ee7ef6c0@tools.ietf.org> References: <068.55f561e469bb5634357c136824b60322@tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <068.55f561e469bb5634357c136824b60322@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt (was: Editorial Issues Section 7 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:18:19 -0000 #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 7: the first paragraph is a wish not a fact. As such it is > doubtful what such paragraph actually brings in the context of a > protocol architecture/specification. New description: '''This ticket groups together editorial issues raised by D. Papadimitriou and Y. Rekhter in their respective reviews.''' '''From D. Papadimitriou's review:''' Section 7: the first paragraph is a wish not a fact. As such it is doubtful what such paragraph actually brings in the context of a protocol architecture/specification. '''From Y. Rekhter's review:''' Section 7 Router Performance Considerations: LISP is designed to be very hardware-based forwarding friendly. By doing tunnel header prepending [RFC1955] and stripping instead of re- writing addresses, existing hardware can support the forwarding model with little or no modification. Where modifications are required, they should be limited to re-programming existing hardware rather than requiring expensive design changes to hard-coded algorithms in silicon. This is simply an Assertion. When a tunnel encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special FIB entries for the EID-prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing should be performed. The forwarding logic of testing for particular IP protocol number value is not necessary. No changes to existing, deployed hardware should be needed to support this. The above explanation of why no changes to existing deployed hardware should be needed is fairly confusing. On an ITR, prepending a new IP header is as simple as adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Many routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already support this action. This looks like another Assertion. When a received packet's outer destination address contains an EID which is not intended to be forwarded on the routable topology (i.e. LISP 1.5), the source address of a data packet or the router interface with which the source is associated (the interface from which it was received) can be associated with a VRF (Virtual Routing/Forwarding), in which a different (i.e. non-congruent) topology can be used to find EID-to-RLOC mappings. What does the part about "When a received packet's ... to be forwarded on the routable topology" have to do with the part about "the source address of a data packet ... can be associated with a VRF" ? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 01:27:11 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23C83A692D for ; Wed, 21 Apr 2010 01:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ1gw2klMte6 for ; Wed, 21 Apr 2010 01:27:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 315E73A6358 for ; Wed, 21 Apr 2010 01:27:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4VGw-0004GO-5C; Wed, 21 Apr 2010 01:27:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 08:27:02 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/57 Message-ID: <068.ce085df57fc97c68212636551555c56c@tools.ietf.org> X-Trac-Ticket-ID: 57 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:27:11 -0000 #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- From section 7: How does one determine whether the outer destination address "contains an EID which is not intended to be forwarded on the routable topology" ? Please answer this question both for IPv6 and for IPv4. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 01:31:19 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F96F3A6861 for ; Wed, 21 Apr 2010 01:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FcJHzS4TfkO for ; Wed, 21 Apr 2010 01:31:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EB0AE3A6835 for ; Wed, 21 Apr 2010 01:31:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4VKu-0001Rw-SU; Wed, 21 Apr 2010 01:31:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 08:31:08 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/15#comment:1 Message-ID: <069.2180d4e51f40026d3fbf185fde3883fd@tools.ietf.org> References: <060.b4b15d03f6ba3bc357ace2e39ad3d053@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <060.b4b15d03f6ba3bc357ace2e39ad3d053@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #15: chairs to review normative and informative references X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:31:19 -0000 #15: chairs to review normative and informative references ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: editorial | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): ''' From Y. Rekhter's review:''' 14.1. Normative References: Why is HIP a normative reference? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 01:38:07 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6223A6405 for ; Wed, 21 Apr 2010 01:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6rgZujEwj4w for ; Wed, 21 Apr 2010 01:38:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A4A9D3A6A9F for ; Wed, 21 Apr 2010 01:38:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4VRU-0001b6-Nq; Wed, 21 Apr 2010 01:37:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 08:37:56 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/58 Message-ID: <068.b86df5c81bd78f6f83a111888ad19f8f@tools.ietf.org> X-Trac-Ticket-ID: 58 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #58: LISP breaking RPF and used as anonymization service (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:38:07 -0000 #58: LISP breaking RPF and used as anonymization service (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 12 There are many comments above that relate to security. Grep for "security" or "attack". Other possible issues that come to mind that should be explored here are whether LISP breaks RPF, and whether the ubiquitous tunneling infrastructure could be reused as a botnet anonymization service. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 01:44:37 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872583A6AC9 for ; Wed, 21 Apr 2010 01:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1AkLt3eD1VB for ; Wed, 21 Apr 2010 01:44:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DC4E33A6AC7 for ; Wed, 21 Apr 2010 01:44:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4VXn-0001mD-Vt; Wed, 21 Apr 2010 01:44:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 08:44:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/59 Message-ID: <068.8be36db734249d6330520777c0081326@tools.ietf.org> X-Trac-Ticket-ID: 59 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #59: Editorial Issues Section 10 of draft-ietf-lisp-06.txt (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:44:37 -0000 #59: Editorial Issues Section 10 of draft-ietf-lisp-06.txt (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 10.3 visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-RLOC mapping for that EID. What is a "route-returnability check"? loss for the entire system. Heuristics can be added to LISP to reduce the number of mapping changes required and to reduce the delay This sounds like an assertion. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 01:55:31 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5073A6989 for ; Wed, 21 Apr 2010 01:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaF9M5EAfEU5 for ; Wed, 21 Apr 2010 01:55:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 405C73A6868 for ; Wed, 21 Apr 2010 01:55:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4ViK-0003v6-OV; Wed, 21 Apr 2010 01:55:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 08:55:20 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/60 Message-ID: <068.014b509d360317eccabd46fa4543c185@tools.ietf.org> X-Trac-Ticket-ID: 60 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #60: Editorial Issues Section 9 of draft-ietf-lisp-06.txt (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:55:31 -0000 #60: Editorial Issues Section 9 of draft-ietf-lisp-06.txt (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 9 This section would benefit from being rewritten to increase clarity. Section 9.3 segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no Earlier it was claimed that copying the TTL is important for correctness reasons. Why is it not important in this case, but is important in all other cases? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 01:57:08 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976333A67D2 for ; Wed, 21 Apr 2010 01:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWykrd5DYpiq for ; Wed, 21 Apr 2010 01:57:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 974DC3A6358 for ; Wed, 21 Apr 2010 01:57:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Vju-0003xL-NP; Wed, 21 Apr 2010 01:56:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 08:56:58 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/61 Message-ID: <068.a267fbeedcada1f2d4dbd5370a8d6278@tools.ietf.org> X-Trac-Ticket-ID: 61 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #61: How to identify "traceroute packet" (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:57:08 -0000 #61: How to identify "traceroute packet" (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Plus, how is the router supposed to identify a "traceroute packet"? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 02:13:55 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED1A28C0E7 for ; Wed, 21 Apr 2010 02:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAG58NeVw7HX for ; Wed, 21 Apr 2010 02:13:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3D30428C0D0 for ; Wed, 21 Apr 2010 02:13:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4W09-0003FM-5h; Wed, 21 Apr 2010 02:13:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 09:13:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/34#comment:1 Message-ID: <077.09ee6590184af373ad8cc5377034fae7@tools.ietf.org> References: <068.8aebdfd098dad3558af27ffd1331ae4e@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <068.8aebdfd098dad3558af27ffd1331ae4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt (was: Editorial Issues Section 8 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:13:55 -0000 #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 8.1 first paragraph, it is not the location of the source that > determines the “size†of the working set of the EID prefix-to-RLOC cache > but the number of EID prefixes this “source site†has to reach. The same > issue occurs at ETR, small sites may have to be configured with a large > list of EID-to-RLOC mapping entries. Next to this the granularity of the > EID prefix allocation is also important. New description: '''This ticket groups together editorial issues raised by D. Papadimitriou and Y. Rekhter in their respective reviews.''' '''From D. Papadimitriou's review:''' Section 8.1 first paragraph, it is not the location of the source that determines the “size†of the working set of the EID prefix-to-RLOC cache but the number of EID prefixes this “source site†has to reach. The same issue occurs at ETR, small sites may have to be configured with a large list of EID-to-RLOC mapping entries. Next to this the granularity of the EID prefix allocation is also important. '''From Y. Rekhter's review:''' By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. This is hard to understand. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 02:16:10 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1123A67AB for ; Wed, 21 Apr 2010 02:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBej0Jmkttuu for ; Wed, 21 Apr 2010 02:16:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9B5C228C134 for ; Wed, 21 Apr 2010 02:15:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4W22-0008DE-0v; Wed, 21 Apr 2010 02:15:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 09:15:41 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/62 Message-ID: <068.c19b6b03372bec851b0b2115d49938f0@tools.ietf.org> X-Trac-Ticket-ID: 62 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #62: Control of the egress tunnel endpoints by the provider ISP (from Y. Rekhter Review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:16:10 -0000 #62: Control of the egress tunnel endpoints by the provider ISP (from Y. Rekhter Review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: alt Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 8.3 Use of ISP PE routers as tunnel endpoint routers gives an ISP control over the location of the egress tunnel endpoints. That is, the ISP can decide if the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. How is this done, as the CE router (probably) and last-hop within a site (surely) is under control of the customer, not the ISP. The advantage of this case is that two or more tunnel headers can be avoided. Only if the extra header in question would be imposed by the first-hop ISP. Any other ISP would still need to impose their own header in order to do TE. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 02:19:49 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6123A6968 for ; Wed, 21 Apr 2010 02:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DImlzVw-F78M for ; Wed, 21 Apr 2010 02:19:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 611BD3A67AB for ; Wed, 21 Apr 2010 02:19:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4W5q-0008Jp-DU; Wed, 21 Apr 2010 02:19:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 09:19:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/63 Message-ID: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> X-Trac-Ticket-ID: 63 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:19:49 -0000 #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: alt Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 8.2 Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. The above means that at the minimum the price of resilience between the CE routers is the inability to support traffic engineering? Specifically, the ISP loses any influence over the choice of which ETR should be used to reach the multi-homed enterprise. Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are anycast addresses as well, and thus can not be topologically significant. Thus if an enterprise is multi-homed to two (or more) ISPs, then use of anycast addresses for CEs would require to route such addresses as /32 throughout the whole Internet. Also, if anycast addresses are used as RLOCs, then how would one deal with a situation where initially both ETR1 and ETR2 advertise 10.1.1/24 and 10.1.2/24, ITR1 routes traffic for 10.1.1.1 to ETR1, but then ETR1, while still being up, loses connectivity to 10.1.1/24? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 02:21:00 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B10628C0E7 for ; Wed, 21 Apr 2010 02:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz3DEvO+tSFl for ; Wed, 21 Apr 2010 02:20:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1281128C132 for ; Wed, 21 Apr 2010 02:20:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4W6Z-0001kF-5E; Wed, 21 Apr 2010 02:20:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 09:20:21 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/63#comment:1 Message-ID: <077.cb003900de53f60bdfb5c34fd0af9b7e@tools.ietf.org> References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:21:00 -0000 #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Changes (by luigi@…): * component: alt => draft-ietf-lisp -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 02:21:34 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3917D3A6804 for ; Wed, 21 Apr 2010 02:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS6oJLtR0PPx for ; Wed, 21 Apr 2010 02:21:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E1F8A28C0F2 for ; Wed, 21 Apr 2010 02:20:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4W6z-0002vC-0x; Wed, 21 Apr 2010 02:20:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 09:20:48 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/62#comment:1 Message-ID: <077.aae2326ec3826d93629d43479dc6456e@tools.ietf.org> References: <068.c19b6b03372bec851b0b2115d49938f0@tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <068.c19b6b03372bec851b0b2115d49938f0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #62: Control of the egress tunnel endpoints by the provider ISP (from Y. Rekhter Review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:21:34 -0000 #62: Control of the egress tunnel endpoints by the provider ISP (from Y. Rekhter Review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Changes (by luigi@…): * component: alt => draft-ietf-lisp -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 04:29:03 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661673A6B79 for ; Wed, 21 Apr 2010 04:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34RPFPwTAJoj for ; Wed, 21 Apr 2010 04:29:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D32433A6803 for ; Wed, 21 Apr 2010 04:28:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Y6r-0008UA-6C; Wed, 21 Apr 2010 04:28:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 11:28:49 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/34#comment:2 Message-ID: <077.3ffff8cbb71b7593bfb5a61da96d3600@tools.ietf.org> References: <068.8aebdfd098dad3558af27ffd1331ae4e@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <068.8aebdfd098dad3558af27ffd1331ae4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:29:03 -0000 #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > '''This ticket groups together editorial issues raised by D. > Papadimitriou and Y. Rekhter in their respective reviews.''' > > '''From D. Papadimitriou's review:''' > > Section 8.1 first paragraph, it is not the location of the source that > determines the “size†of the working set of the EID prefix-to-RLOC cache > but the number of EID prefixes this “source site†has to reach. The same > issue occurs at ETR, small sites may have to be configured with a large > list of EID-to-RLOC mapping entries. Next to this the granularity of the > EID prefix allocation is also important. > > '''From Y. Rekhter's review:''' > > By having the PE be the first router on the path to encapsulate, it > can choose a TE path first, and the ETR can decapsulate and > re-encapsulate for a tunnel to the destination end site. > > This is hard to understand. New description: '''This ticket groups together editorial issues raised by D. Papadimitriou and Y. Rekhter in their respective reviews.''' '''From D. Papadimitriou's review:''' Section 8.1 first paragraph, it is not the location of the source that determines the “size†of the working set of the EID prefix-to-RLOC cache but the number of EID prefixes this “source site†has to reach. The same issue occurs at ETR, small sites may have to be configured with a large list of EID-to-RLOC mapping entries. Next to this the granularity of the EID prefix allocation is also important. '''From Y. Rekhter's review:''' By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. This is hard to understand. ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. What exactly does "suboptimal" mean here? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 04:33:14 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCB528C0EA for ; Wed, 21 Apr 2010 04:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-Xmf9BsjDPi for ; Wed, 21 Apr 2010 04:33:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8AEEF3A69AC for ; Wed, 21 Apr 2010 04:33:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4YAy-0000BX-Iz; Wed, 21 Apr 2010 04:33:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 11:33:04 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/64 Message-ID: <068.200921803b020f7b2e6fe117ab763621@tools.ietf.org> X-Trac-Ticket-ID: 64 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #64: Host based LISP implementations (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:33:14 -0000 #64: Host based LISP implementations (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 8 This section doesn't discuss host based LISP implementations, which seems a possibility as it is discussed under mobility. What are the implications be of host based LISP on the control plane load and does two headers restriction create a problem for host based LISP? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 04:47:05 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F01A3A695A for ; Wed, 21 Apr 2010 04:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpO9D8O-eiQD for ; Wed, 21 Apr 2010 04:47:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0BFCF3A67D1 for ; Wed, 21 Apr 2010 04:47:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4YON-0002KJ-3L; Wed, 21 Apr 2010 04:46:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 11:46:55 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/42#comment:1 Message-ID: <077.2f533ec3eaf314cf1dd929de7f8fd6e7@tools.ietf.org> References: <068.949be01828216d93bdf1e485048b2d40@tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <068.949be01828216d93bdf1e485048b2d40@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #42: On the SMR mechanism (was: On the SMR mechanism (from D. Papadimitriou's review)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:47:05 -0000 #42: On the SMR mechanism ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 6.5.2 is this technique mandatory or not (this is not > specified in the text). Point 5 results in obvious situations where > the ETR may never stop sending SMR messages. As there is no means a > way to prevent that ITR use “old mappings†this result in a deadlock > situation (a non-cooperating ITR prevents ETR to stop sending SMR > messages). > > Section 6.5.2 states “So an xTR will solicit Map-Requests from sites > it is currently sending encapsulated data to, and only from those > sites.†Thus instead of keeping track of ITR, ETR keep track of the > encapsulated traffic ITR send. The mechanism is often cited but never > explained e.g. over which time period is the ETR expected to determine > the set of communicating ITR’s ? > > Section 6.5.2 states “Map request†shall be rate limited … rather > unclear: assume a single ETR sends one SMR message to 10 different > ITRs how the 10 ITR will individually rate limit a single Map Request > in response to this SMR message. It is thus worth specifying the flow > control of SMR and Map-Request messages in a more systematic way to > prevent ETR overloads. New description: '''This ticket groups together co-related issues concerning the SMR mechanism raised by D. Papadimitriou and Y. Rekhter in their respective reviews .''' '''From D. Papadimitriou's review:''' Section 6.5.2 is this technique mandatory or not (this is not specified in the text). Point 5 results in obvious situations where the ETR may never stop sending SMR messages. As there is no means a way to prevent that ITR use “old mappings†this result in a deadlock situation (a non-cooperating ITR prevents ETR to stop sending SMR messages). Section 6.5.2 states “So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites.†Thus instead of keeping track of ITR, ETR keep track of the encapsulated traffic ITR send. The mechanism is often cited but never explained e.g. over which time period is the ETR expected to determine the set of communicating ITR’s ? Section 6.5.2 states “Map request†shall be rate limited … rather unclear: assume a single ETR sends one SMR message to 10 different ITRs how the 10 ITR will individually rate limit a single Map Request in response to this SMR message. It is thus worth specifying the flow control of SMR and Map-Request messages in a more systematic way to prevent ETR overloads. '''From Y. Rekhter's review:''' Section 6.5.2 Solicited-Map-Request Since the xTRs don't keep track of remote ITRs that have cached their mappings, they can not tell exactly who needs the new mapping entries. So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites. "currently" needs to be quantified. E.g., if the local xTR detected change in the mapping at time T1, and sends the encapsulated data to a particlar remote xTR at time T2, what is the max allowable (T2-T1) ? Is it 1 sec, 1 min, 1 hour, 1 day ? What is the meaning of "solicit Map-Requests from sites" ? Does it mean soliciting it from all the xTRs of a given site ? If yes, then how would it determine all such xTRs ? And if no, and it means just one xTR of a given site, then how would Solicited-Map-Request work in the scenario where an xTR-A sends encapsulated data to xTR-B of a given (remote) site, but that site uses some other xTR, xTR-C, to send the data to xTR-A, and it is xTR-C that needs the new mapping ? The remote xTR retransmits the Map-Request slowly until it gets a "slowly" needs to be quantified. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message provided the Map-Request nonce matches the nonce from the SMR. The Map-Reply messages SHOULD be rate limited. This is important to avoid Map-Reply implosion. Is the implication that during this procedure, normal new Map-Requests will not be replied to in the usual way, since they won't have the nonce? with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, What is the justification for this assumption about the mapping database's security? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 04:51:49 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCCB3A6807 for ; Wed, 21 Apr 2010 04:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9WMIJlOX16a for ; Wed, 21 Apr 2010 04:51:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 02D773A6B88 for ; Wed, 21 Apr 2010 04:51:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4YSt-0002o6-2d; Wed, 21 Apr 2010 04:51:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 11:51:35 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/65 Message-ID: <068.afb88086d11db1572bdade525c19eeeb@tools.ietf.org> X-Trac-Ticket-ID: 65 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #65: Missing step to restore 24h TTL in clock-sweep mechanism (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:51:49 -0000 #65: Missing step to restore 24h TTL in clock-sweep mechanism (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.5.1 The default setting for an EID-to-RLOC mapping TTL is 24 hours. This is the only place in the document where the default is specified! There is a missing step in the procedure, which is to restore the TTL to 24 hours. In general, this procedure would seem to lead to increased operational complexity, and thus contradict the claims of reduced opex. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 04:59:45 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA83128C14A for ; Wed, 21 Apr 2010 04:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV-c76quSd01 for ; Wed, 21 Apr 2010 04:59:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2063728C141 for ; Wed, 21 Apr 2010 04:59:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4YaY-00034w-6A; Wed, 21 Apr 2010 04:59:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 11:59:30 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/66 Message-ID: <068.3a3b43d90cb0ced8925103b20f872430@tools.ietf.org> X-Trac-Ticket-ID: 66 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #66: Strict RLOC ordering causing problems on mapping changes (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:59:45 -0000 #66: Strict RLOC ordering causing problems on mapping changes (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.5 When a locator record is added to the end of a locator-set, it is easy to update mappings. We assume new mappings will maintain the same locator ordering as the old mapping but just have new locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. This identifies a real problem; i.e., the locator status bits are contextually dependent on the locator set that was advertised, but there is no explicit binding between them and the particular locator set to which they relate. Thus, any version skew between ITR and ETR will result in misinterpretation of the locator status bits. This seems like it could be a serious problem (though section 6.3 is so underspecified and hard to follow that this is difficult to pin down) and needs to be understood better. The fixes proposed in this section seem complex and incomplete. When an ITR has only an old mapping but detects bits set in the loc-status-bits that correspond to locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing locator-set. It is previously stated that locators in the locator-set must be sorted; this would seem to indicate that you cannot add a locator to the locator-set on demand, and that a process such as defined in 6.5.1 must be used to try to ensure sync between ITR and ETR There would seem to be a need to either get rid of locator-sets, or come up with a better system for synchronizing them. The consequences of out-of-sync locator-sets should also be spelled out. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:05:19 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF18B28C155 for ; Wed, 21 Apr 2010 05:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD6qGUgCUIVW for ; Wed, 21 Apr 2010 05:05:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5ADA03A69EE for ; Wed, 21 Apr 2010 05:05:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Yfs-0003Fg-Dh; Wed, 21 Apr 2010 05:05:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:05:00 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/67 Message-ID: <068.8083d532ca92cd4b01bf3baf5f1d037a@tools.ietf.org> X-Trac-Ticket-ID: 67 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #67: What would it mean if N were clear and E were set? (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:05:20 -0000 #67: What would it mean if N were clear and E were set? (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.3.1 When there is bidirectional data flow between a pair of locators, a simple mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N and E bits and places a 24-bit nonce in the LISP header of the next encapsulated data packet. What would it mean if N were clear and E were set? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:15:54 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3503A6BB5 for ; Wed, 21 Apr 2010 05:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boRdgnUIt75Q for ; Wed, 21 Apr 2010 05:15:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D82F53A6B8B for ; Wed, 21 Apr 2010 05:13:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Yo1-0001WX-ED; Wed, 21 Apr 2010 05:13:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:13:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/26#comment:4 Message-ID: <069.91785bd7742d447b8c41141e04d4408f@tools.ietf.org> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #26: Overlapping Map prefixes in EID map cache X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:15:54 -0000 #26: Overlapping Map prefixes in EID map cache ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): '''Yakov Rekhter raises a related question in his review of draft-ietf- lisp-06.txt (part 2):''' Section 6.1.5 EID-to-RLOC UDP Map-Reply message There are several problems with the following paragraph: Note that not all overlapping EID-prefixes need to be returned, only the more specifics (note in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) entries for the matching EID-prefix of the requesting EID. When more than one EID-prefix is returned, all SHOULD use the same Time-to-Live value so they can all time out at the same time. When a more specific EID-prefix is received later, its Time-to-Live value in the Map-Reply record can be stored even when other less specifics exist. When a a less specific EID-prefix is received later, its map-cache expiration time should be set to the minimum expiration time of any more specific EID-prefix in the map-cache. First, it assumes that the ITR will exactly obey the TTLs given in the Map-Reply. Most caching systems allow caches to manage timeouts on their own, especially allowing early timeouts (for example to create space in the cache if it fills). If this is NOT allowed in LISP (and it seems not to be), that needs to be spelled out. What are the bad consequences of timing entries out at different times, which are not equal to the TTLs given? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:19:50 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5834628C230 for ; Wed, 21 Apr 2010 05:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUHZ0+NG6idU for ; Wed, 21 Apr 2010 05:19:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 55B353A6C5F for ; Wed, 21 Apr 2010 05:16:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Yqq-0000d5-Lg; Wed, 21 Apr 2010 05:16:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:16:20 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/26#comment:5 Message-ID: <069.79711051f8bc52e462406d86d5f25354@tools.ietf.org> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #26: Overlapping Map prefixes in EID map cache X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:19:50 -0000 #26: Overlapping Map prefixes in EID map cache ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): '''Yakov Rekhter raises a related question in his review of draft-ietf- lisp-06.txt (part 2):''' Section 6.1.5 EID-to-RLOC UDP Map-Reply message The following sentence is confusing: When a more specific EID-prefix is received later, its Time-to-Live value in the Map-Reply record can be stored even when other less specifics exist. And this sentence: When a a less specific EID-prefix is received later, its map-cache expiration time should be set to the minimum expiration time of any more specific EID-prefix in the map-cache. isn't clear as to what it's mandating. Is this a requirement for ITR behavior ? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:25:38 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF1328C222 for ; Wed, 21 Apr 2010 05:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRGnIDU+qMWj for ; Wed, 21 Apr 2010 05:25:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DFE4F28C220 for ; Wed, 21 Apr 2010 05:19:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Ytr-0007aP-UR; Wed, 21 Apr 2010 05:19:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:19:27 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/68 Message-ID: <068.f483118418ff0a04689ef79494e01869@tools.ietf.org> X-Trac-Ticket-ID: 68 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:25:38 -0000 #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.1.5 EID-to-RLOC UDP Map-Reply message When sending a Map-Reply message, the destination address is copied from the source address of the Map-Request or Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local locator addresses listed in the locator-set of any mapping record in the message. What is the source address for a negative reply, which has a zero length locator -set ? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:27:38 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E6B3A6916 for ; Wed, 21 Apr 2010 05:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN10fuoa7rUK for ; Wed, 21 Apr 2010 05:27:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 24A2D3A6816 for ; Wed, 21 Apr 2010 05:22:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4YwS-0007FB-6f; Wed, 21 Apr 2010 05:22:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:22:08 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/69 Message-ID: <068.062591f9c2a73c88a94091fd86bb2c73@tools.ietf.org> X-Trac-Ticket-ID: 69 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #69: Inadequate solution for ETR overclaims (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:27:38 -0000 #69: Inadequate solution for ETR overclaims (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.1.5.1 This section correctly identifies an attack where an ETR overclaims, saying that it owns a larger span of prefixes than it really does. The proposed solutions seem inadequate; in particular, the limiting the mask-length that you'll accept from a given ETR seems weak. I.e., how could an ITR determine a "configured prefix length" for a given EID prefix? This is a serious deficiency. It is somewhat analogous to the weakness of the BGP routing system, except that it is much less amenable to auditing than BGP (since the mapping data is only presented on demand, an auditor can't simply get a feed) and there are many more machines playing than in the BGP system. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:27:54 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2613A6C50 for ; Wed, 21 Apr 2010 05:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0G6CZ-pT1HF for ; Wed, 21 Apr 2010 05:27:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2E7F128C188 for ; Wed, 21 Apr 2010 05:22:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Ywr-0000a1-4c; Wed, 21 Apr 2010 05:22:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:22:33 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/69#comment:1 Message-ID: <077.85db257669b80bf186900ea9f3fbade1@tools.ietf.org> References: <068.062591f9c2a73c88a94091fd86bb2c73@tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <068.062591f9c2a73c88a94091fd86bb2c73@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #69: Inadequate solution for ETR overclaims (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:27:54 -0000 #69: Inadequate solution for ETR overclaims (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Changes (by luigi@…): * priority: minor => major -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:35:48 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BBD928C23A for ; Wed, 21 Apr 2010 05:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5VoXb8Zmt7Y for ; Wed, 21 Apr 2010 05:35:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D9C9A28C26E for ; Wed, 21 Apr 2010 05:31:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Z57-0006U4-RG; Wed, 21 Apr 2010 05:31:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:31:05 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/70 Message-ID: <068.7ad8426e5defed8efc75a91b3b935546@tools.ietf.org> X-Trac-Ticket-ID: 70 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #70: Client not respecting RLOC weights (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:35:48 -0000 #70: Client not respecting RLOC weights (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.2 Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. If the client can gain some advantage (or thinks it can) by ignoring the server's weighting, it will. There should be some consideration of whether this is a problem, and if so, how to address it. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:48:27 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50DD028C2DC for ; Wed, 21 Apr 2010 05:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuMldpWbofP2 for ; Wed, 21 Apr 2010 05:48:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6087428C23F for ; Wed, 21 Apr 2010 05:43:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4ZGd-0006qF-6z; Wed, 21 Apr 2010 05:42:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:42:59 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/32#comment:2 Message-ID: <077.622f168dfeafecb0e2b0cf0e92ba9739@tools.ietf.org> References: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:48:27 -0000 #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Old description: > Section 6.2 introduces the terms client-side and server-side where are > these terms defined ? without such definition readability of the > section is low. > > Section 6.2 RLOC reachability can determined and selected but there is > no description on how the EID-to-RLOC selection is performed. > > Section 6.3.2 states “RLOC Probing can also provide RTT estimates > between a pair of locators which can be useful for network management > purposes as well as for selecting low delay paths.†If the exchanges > are performed in the control plane it is not clear how such RTT/delay > values can be derived for the forwarding path ? Can authors explain ? > Authors should also check the accuracy of the estimate vs overhead > generated by such technique. > > Section 6.5 the section does not actually explain which messages are > used to update the list of Loc-Reach or Loc-Status bits. If it is data > traffic-driven then the mechanism is again dependent on the symmetry > of the reverse path and the packet rate but also packet differential > delays between packets. In the latter case, it is not clear how ITR > could retrieve the correct RLOCs to be used if a sequence of 8 packets > sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC > (indicated as available at arrival of the 8th packet) is received as > 1,0,0,0,0,0,0,0. The section makes a long digression on ordering > locator set this is not the issue without a sequence number it will > never be possible for the receiving ITR to determine the actual state > of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep > track of who requested mappings upon communication they should tell > the state of their mapping but also their transition. New description: Section 6.2 introduces the terms client-side and server-side where are these terms defined ? without such definition readability of the section is low. -- Comment(by luigi@…): '''Yakov Rekhter raises related editorial issues in his review of draft- ietf-lisp-06.txt (part 2):''' Section 6.3.2 cached by the ITR or PTR. The ITR or PTR may include a mapping data record for its own database mapping information. What exactly is "its own database mapping information" ? Section 6.4 Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a random value allows core routers which are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets which are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. "Random" in the second sentence is contradicted by the last sentence. Also, it is not clear why the paragraph restricts itself to talking about LAGs. Load balancing is used plenty of other places. Section 6.5 As a general comment, this section is in need of some editing to make the prose more readable. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:52:12 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C4A28C20E for ; Wed, 21 Apr 2010 05:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUGYq5sdN+cD for ; Wed, 21 Apr 2010 05:52:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C9A9628C1FF for ; Wed, 21 Apr 2010 05:46:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4ZKD-0008OK-SS; Wed, 21 Apr 2010 05:46:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:46:41 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/71 Message-ID: <068.671f82f82e7522e3783ce3ca2c9b02bf@tools.ietf.org> X-Trac-Ticket-ID: 71 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #71: Missing description mechanism to make EID-to-RLOC (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:52:12 -0000 #71: Missing description mechanism to make EID-to-RLOC (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.2 RLOC reachability can determined and selected but there is no description on how the EID-to-RLOC selection is performed. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:53:33 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37AD28C2C1 for ; Wed, 21 Apr 2010 05:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTdEVAtyE5cA for ; Wed, 21 Apr 2010 05:53:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 42DA53A68CC for ; Wed, 21 Apr 2010 05:48:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4ZLM-0000Sy-AM; Wed, 21 Apr 2010 05:47:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:47:52 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/72 Message-ID: <068.4034f36e3bda570cd7f0c7e177229d0c@tools.ietf.org> X-Trac-Ticket-ID: 72 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #72: RTT estimation for the forwarding path (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:53:33 -0000 #72: RTT estimation for the forwarding path (from D. Papadimitriou's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Section 6.3.2 states “RLOC Probing can also provide RTT estimates between a pair of locators which can be useful for network management purposes as well as for selecting low delay paths.†If the exchanges are performed in the control plane it is not clear how such RTT/delay values can be derived for the forwarding path ? Can authors explain ? Authors should also check the accuracy of the estimate vs overhead generated by such technique. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 05:58:52 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0A828C29E for ; Wed, 21 Apr 2010 05:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZwI3d3MYqnK for ; Wed, 21 Apr 2010 05:58:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 251D128C1FF for ; Wed, 21 Apr 2010 05:52:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4ZPw-0000Zb-6V; Wed, 21 Apr 2010 05:52:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 21 Apr 2010 12:52:36 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:1 Message-ID: <077.449d0462237f8ada3f1934f2a18b2fb0@tools.ietf.org> References: <068.3a3b43d90cb0ced8925103b20f872430@tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <068.3a3b43d90cb0ced8925103b20f872430@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #66: Strict RLOC ordering causing problems on mapping changes (was: Strict RLOC ordering causing problems on mapping changes (from Y. Rekhter's review)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:58:52 -0000 #66: Strict RLOC ordering causing problems on mapping changes ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 6.5 > > When a locator record is added to the end of a locator-set, it is > easy to update mappings. We assume new mappings will maintain the > same locator ordering as the old mapping but just have new locators > appended to the end of the list. So some ITRs can have a new mapping > while other ITRs have only an old mapping that is used until they > time out. > > This identifies a real problem; i.e., the locator status bits are > contextually dependent on the locator set that was advertised, but > there is no explicit binding between them and the particular locator > set to which they relate. Thus, any version skew between ITR and ETR > will result in misinterpretation of the locator status bits. > > This seems like it could be a serious problem (though section 6.3 is > so underspecified and hard to follow that this is difficult to pin > down) and needs to be understood better. The fixes proposed in this > section seem complex and incomplete. > > When an ITR has only an old mapping but detects bits set in the > loc-status-bits that correspond to locators beyond the list it has > cached, it simply ignores them. However, this can only happen for > locator addresses that are lexicographically greater than the locator > addresses in the existing locator-set. > > It is previously stated that locators in the locator-set must be > sorted; this would seem to indicate that you cannot add a locator to > the locator-set on demand, and that a process such as defined in 6.5.1 > must be used to try to ensure sync between ITR and ETR > > There would seem to be a need to either get rid of locator-sets, or > come up with a better system for synchronizing them. The consequences > of out-of-sync locator-sets should also be spelled out. New description: '''This ticket groups together co-related issues concerning RLOC ordering raised by D. Papadimitriou and Y. Rekhter in their respective reviews.''' '''From D. Papadimitriou's review:''' Section 6.5 the section does not actually explain which messages are used to update the list of Loc-Reach or Loc-Status bits. If it is data traffic-driven then the mechanism is again dependent on the symmetry of the reverse path and the packet rate but also packet differential delays between packets. In the latter case, it is not clear how ITR could retrieve the correct RLOCs to be used if a sequence of 8 packets sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC (indicated as available at arrival of the 8th packet) is received as 1,0,0,0,0,0,0,0. The section makes a long digression on ordering locator set this is not the issue without a sequence number it will never be possible for the receiving ITR to determine the actual state of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep track of who requested mappings upon communication they should tell the state of their mapping but also their transition. '''From Y. Rekhter's review:''' Section 6.5 When a locator record is added to the end of a locator-set, it is easy to update mappings. We assume new mappings will maintain the same locator ordering as the old mapping but just have new locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. This identifies a real problem; i.e., the locator status bits are contextually dependent on the locator set that was advertised, but there is no explicit binding between them and the particular locator set to which they relate. Thus, any version skew between ITR and ETR will result in misinterpretation of the locator status bits. This seems like it could be a serious problem (though section 6.3 is so underspecified and hard to follow that this is difficult to pin down) and needs to be understood better. The fixes proposed in this section seem complex and incomplete. When an ITR has only an old mapping but detects bits set in the loc-status-bits that correspond to locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing locator-set. It is previously stated that locators in the locator-set must be sorted; this would seem to indicate that you cannot add a locator to the locator-set on demand, and that a process such as defined in 6.5.1 must be used to try to ensure sync between ITR and ETR There would seem to be a need to either get rid of locator-sets, or come up with a better system for synchronizing them. The consequences of out-of-sync locator-sets should also be spelled out. -- -- Ticket URL: lisp LISP WG document issues From jgs@juniper.net Wed Apr 21 09:08:01 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4D828C1CD for ; Wed, 21 Apr 2010 09:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPZ1PeWE0lvQ for ; Wed, 21 Apr 2010 09:08:00 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id D4F5B28C310 for ; Wed, 21 Apr 2010 08:44:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKS88dQV7yBajD0nBpS5rgzjBxiVU6W6ZY@postini.com; Wed, 21 Apr 2010 08:44:03 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, 21 Apr 2010 08:39:28 -0700 From: John Scudder To: Eliot Lear Date: Wed, 21 Apr 2010 08:39:27 -0700 Thread-Topic: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] Thread-Index: AcrhaNPp1M18dr4RQZ6RDrcR4J71hg== Message-ID: <7A9790F3-0068-44BF-A312-A5BC3F91D044@juniper.net> References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com> <4BCDE0ED.9020307@cisco.com> In-Reply-To: <4BCDE0ED.9020307@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Drake , John, "lisp@ietf.org" Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 16:08:01 -0000 Eliot, On Apr 20, 2010, at 1:14 PM, Eliot Lear wrote: > On 4/20/10 7:04 PM, John Scudder wrote: >>> as discussed in the spec, we keep locator reachability out of the >>> mapping database system. Thereby if a locator goes down or out of >>> service, *it is not removed* from the locator-set. >> ... but note that the parenthetical question had to do with *EID* reacha= bility, not locator reachability. >>=20 > I'm going to hazard a guess that is what Dino meant, as locator=20 > reachability occurs as it does today. I started to write a reply to this based on your guess that Dino actually m= eant "EID reachability" but quickly got mired down because you can't really= take Dino's (quoted above) sentence and have it make sense if you s/locato= r/EID/g. (For example, EIDs aren't part of locator-sets.) So I guess I'll wait for Dino to clarify if he wants to. --John= From Dimitri.Papadimitriou@alcatel-lucent.com Wed Apr 21 13:59:35 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466283A69F4 for ; Wed, 21 Apr 2010 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjQoHyfvFmeg for ; Wed, 21 Apr 2010 13:59:34 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id BFD133A694A for ; Wed, 21 Apr 2010 13:59:33 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3LKxLM7006832; Wed, 21 Apr 2010 22:59:21 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 22:59:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 22:59:06 +0200 Message-ID: <00275A5B436CA441900CB10936742A380439DEC0@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <077.693673ec0f5bf65a905d7b9a2d272fbd@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review Thread-Index: AcrhJYK84/XGj9TZRwS7jwrvm5q91gAADA6w References: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> <077.693673ec0f5bf65a905d7b9a2d272fbd@tools.ietf.org> From: "PAPADIMITRIOU Dimitri" To: , X-OriginalArrivalTime: 21 Apr 2010 20:59:21.0258 (UTC) FILETIME=[83E378A0:01CAE195] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: lisp@ietf.org Subject: Re: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 20:59:35 -0000 Hi Luigi, Some comments classified as "editorial" often translate under-specification (or specification that is difficult to understand); so, conservative approach consisted in asking clarification(s). An example: in Section 6.5 clearly states that mappings maintenance and processing is traffic driven (whereas EID processing is configuration driven and RLOC reachability is topology driven). EID and RLOC follows traffic between TR that "hosts" them. Synchronizing EID and RLOC based on traffic leads to selection of mappings that are invalid in case of change in EID and RLOC as long as source ITR are not made not aware of these changes by means of arrival of traffic (thus, such changes may never be received by source ITR due to either unidirectional or asymmetric path) or solicited cached entries replacement/time-out.=20 Hence, the question related to Section 6.2/6.3 concerning the association of the RLOC to the RLOC part of the mapping (and the association of the EID to the EID part of the mapping in Section 6.1) knowing the strong condition imposed by Section 6.5: RLOC reachability is driven by topology and controlled by ITR and EID-to-RLOC mapping is driven by traffic and controlled by ETR -> how the association between received EID-to-RLOC mapping and RLOC local information is performed, maintained over time at the ITR and how selection is actually performed among multiple locators ? Thanks, -dimitri. =20 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of lisp issue tracker > Sent: Wednesday, April 21, 2010 9:37 AM > To: luigi@net.t-labs.tu-berlin.de > Cc: lisp@ietf.org > Subject: Re: [lisp] #32: Editorial Issues Section 6 of=20 > draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review >=20 > #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt=20 > raised by Dimitri > Papadimitriou in his review > ------------------------------------------+------------------- > -------------- > Reporter: luigi@... | Owner: =20 > =20 > Type: editorial | Status: new=20 > =20 > Priority: trivial | Component: =20 > draft-ietf-lisp > Severity: - | Keywords: =20 > =20 > ------------------------------------------+------------------- > -------------- >=20 > Comment(by luigi@...): >=20 > '''Yakov Rekhter raises a related question in his review of=20 > draft-ietf- > lisp-06.txt (part 2):''' >=20 > Section 6.2 >=20 > This section uses "client-side" and "server-side" extensively without > defining the terms. They seem to be the same as "ITR" and=20 > "ETR" in the > rest of the document. Terminology should be defined or=20 > harmonized with > the rest of the document. >=20 > --=20 > Ticket URL:=20 > > lisp > LISP WG document issues > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 From dino@cisco.com Wed Apr 21 14:45:50 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF2228C0F5 for ; Wed, 21 Apr 2010 14:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh2l9OP1znTv for ; Wed, 21 Apr 2010 14:45:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B09A43A69E6 for ; Wed, 21 Apr 2010 14:45:49 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcOz0tAZnwM/2dsb2JhbACcGnGjXJo5hQ4EgzQ X-IronPort-AV: E=Sophos;i="4.52,252,1270425600"; d="scan'208";a="103804911" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Apr 2010 21:45:39 +0000 Received: from [10.10.10.86] (rtp-vpn3-583.cisco.com [10.82.218.74]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3LLjcBS009579; Wed, 21 Apr 2010 21:45:39 GMT Message-Id: <6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com> From: Dino Farinacci To: John Scudder In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Apr 2010 14:45:38 -0700 References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" , John E Drake Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 21:45:50 -0000 > Hi Dino, > > Just replying to one point here. Other replies as time allows. Sure. > On Apr 20, 2010, at 3:39 AM, Dino Farinacci wrote: > [...] >>> Comment 3: >>> >>> The draft leaves a number of important aspects of the Map-Reply >>> open, or only implied rather than clearly stated. These should be >>> stated in one place, clearly. Ambiguous areas include: >>> >>> - Is there a requirement that all entities that return Map-Replies >>> for a given EID return the same contents? >> >> Yes, it is stated, the ETRs should return the same contents. When I > > I've only read the spec a few times so I may have missed where this > is spelled out. Would you mind citing where this is stated in the > spec? It is a bit implied in the following text but I will make it more clear in the -07 update. EID-to-RLOC Database: a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. >>> - Must the locator-set be manually configured on every entity that >>> returns Map-Replies for that EID? >> >> Yes, > > Is that "yes" to the "must be manually configured" question? I > would have assumed so but you go on to talk about connecting to the > ALT and such, which would appear to be an unrelated (or tangentially > related) topic. Yes, the database mapping must be consistently configured on all ETRs for a given LISP site. Can you refer to my text that refers to the ALT? Thanks. >>> - Or might it change as a reaction to the network's operational >>> state? >>> (E.g. temporary loss of reachability from a given ETR to a given >>> EID.) >> >> No, > > OK... > >> as discussed in the spec, we keep locator reachability out of the >> mapping database system. Thereby if a locator goes down or out of >> service, *it is not removed* from the locator-set. > > ... but note that the parenthetical question had to do with *EID* > reachability, not locator reachability. If an ETR cannot connect to the site, it can set its LSB bit to 0. That is if all its site-facing interfaces go down, then it should do this. Other failure cases are more complicated but typically you won't find a site completely partitioning. We have heard though that customers *may* want to deploy VRRP/HSRP between their xTRs at a site to detect site partitioning. We believe we don't need to add LISP mechanisms to solve this. Sorry for the delayed response, Dino From jnc@mercury.lcs.mit.edu Wed Apr 21 14:48:19 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A433A69CD for ; Wed, 21 Apr 2010 14:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3aWBVf2YiFr for ; Wed, 21 Apr 2010 14:48:19 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1F31E3A695B for ; Wed, 21 Apr 2010 14:48:19 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D52E86BE62C; Wed, 21 Apr 2010 17:48:08 -0400 (EDT) To: lisp@ietf.org Message-Id: <20100421214808.D52E86BE62C@mercury.lcs.mit.edu> Date: Wed, 21 Apr 2010 17:48:08 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 21:48:20 -0000 > From: "PAPADIMITRIOU Dimitri" > EID processing is configuration driven Sorry, what is "EID processing"? > EID and RLOC follows traffic between TR that "hosts" them. Do you mean 'EID->RLOC mappings'? EIDs and RLOCs by themselves don't move anywhere, so they can't "follow" anything to anywhere. > Synchronizing EID and RLOC based on traffic Sorry, I simply do not understand what you mean here. > in case of change in EID and RLOC Do you mean 'a change in EID->RLOC mappings'? > as long as source ITR are not made not aware of these changes by means > of arrival of traffic (thus, such changes may never be received by > source ITR due to either unidirectional or asymmetric path) If you mean what I am guessing you mean, that's why user data packets carry the 'mapping version number' (of the mapping being used by the source ITR for that destination EID) in the header (in some packets), so that the destination ETR can detect that the source ITR is using an old mapping. The destination ETR can then notify the source ITR that it needs to update its mapping. > how the association between received EID-to-RLOC mapping and RLOC local > information is performed, maintained over time at the ITR and how > selection is actually performed among multiple locators ? Again, I am having a hard time understanding clearly what you mean here, which makes it hard for me to answer. Noel From vaf@cisco.com Wed Apr 21 15:22:39 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264D33A6970 for ; Wed, 21 Apr 2010 15:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn2EUb9mJevG for ; Wed, 21 Apr 2010 15:22:35 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5F32B3A694C for ; Wed, 21 Apr 2010 15:22:34 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,252,1270425600"; d="scan'208";a="118726526" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Apr 2010 22:22:25 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3LMMPhf022283; Wed, 21 Apr 2010 22:22:25 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 7D2701DE160; Wed, 21 Apr 2010 15:22:24 -0700 (PDT) Date: Wed, 21 Apr 2010 15:22:24 -0700 From: Vince Fuller To: John Scudder Message-ID: <20100421222223.GA40895@vaf-mac1.cisco.com> References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 22:22:39 -0000 > > as discussed in the spec, we keep locator reachability out of the > > mapping database system. Thereby if a locator goes down or out of > > service, *it is not removed* from the locator-set. > > ... but note that the parenthetical question had to do with *EID* > reachability, not locator reachability. Can you please re-phrase the question and describe the context? Except within the very limited scope of the ALT database mapping system, the term "EID reachability" is something of an oxymoron. Focusing only on use of LISP on the Internet (ignoring enterprise use cases), an ETR may publish the set of RLOCs associated with an EID in the global mapping database. It typically does so by registering that mapping with one or more Map-Servers. In exceptional circumstances, an ETR may instead connect to the ALT virtual overlay network and advertise an EID-prefix that covers the EID using BGP on the ALT. An ITR determines the RLOCs for a specific EID by querying the global mapping system, typically by sending a Map-Request to a Map-Resolver and awaiting a matching Map-Reply. Again, in exception circumstances, an ITR may connect to the ALT and send a Map-Request for an EID on to the ALT which then routes it toward the Map-Server or ETR that advertised the covering EID prefix on to the ALT. But this is all orthogonal to the issue of RLOC reachability (and is mostly outside of the scope of draft-ietf-lisp anyway), so I'm not sure how to interpret your comment/question above. Thanks, --Vince From Dimitri.Papadimitriou@alcatel-lucent.com Wed Apr 21 15:36:52 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683993A6972 for ; Wed, 21 Apr 2010 15:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDG0rrP0n3-N for ; Wed, 21 Apr 2010 15:36:51 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 4EC423A696E for ; Wed, 21 Apr 2010 15:36:50 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3LMaagS008555; Thu, 22 Apr 2010 00:36:37 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 00:36:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 00:35:50 +0200 Message-ID: <00275A5B436CA441900CB10936742A380439DEC7@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20100421214808.D52E86BE62C@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #32: Editorial Issues Section 6 ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review Thread-Index: AcrhnFhGD60Fk5SZRNWHSbvrfXlSUgAAKeBw References: <20100421214808.D52E86BE62C@mercury.lcs.mit.edu> From: "PAPADIMITRIOU Dimitri" To: "Noel Chiappa" , X-OriginalArrivalTime: 21 Apr 2010 22:36:36.0156 (UTC) FILETIME=[19C23FC0:01CAE1A3] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [lisp] #32: Editorial Issues Section 6 ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 22:36:52 -0000 =20 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of Noel Chiappa > Sent: Wednesday, April 21, 2010 11:48 PM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] #32: Editorial Issues Section 6=20 > ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review >=20 >=20 > > From: "PAPADIMITRIOU Dimitri"=20 > >=20 > > EID processing is configuration driven >=20 > Sorry, what is "EID processing"? EID allocation. =20 > > EID and RLOC follows traffic between TR that "hosts" them. >=20 > Do you mean 'EID->RLOC mappings'? EIDs and RLOCs by=20 > themselves don't move > anywhere, so they can't "follow" anything to anywhere. "follows" means here that traffic flows drive information received by ITR about changes in EID(-to-RLOC) and RLOC values. > > Synchronizing EID and RLOC based on traffic >=20 > Sorry, I simply do not understand what you mean here.=20 >=20 > > in case of change in EID and RLOC >=20 > Do you mean 'a change in EID->RLOC mappings'? "Synchronizing EID(-to-RLOC) and RLOC based on traffic leads to selection of mappings..." > > as long as source ITR are not made not aware of these=20 > changes by means > > of arrival of traffic (thus, such changes may never be=20 > received by > > source ITR due to either unidirectional or asymmetric path) >=20 > If you mean what I am guessing you mean, that's why user data=20 > packets carry > the 'mapping version number' (of the mapping being used by=20 > the source ITR for > that destination EID) in the header (in some packets), so that the > destination ETR can detect that the source ITR is using an=20 > old mapping. The > destination ETR can then notify the source ITR that it needs=20 > to update its > mapping. If and only if, the source ITR receives traffic back from the ETR to which this ITR sends traffic. Secondly, any selection of an alternate ETR may bring a "older version" of the mapping (as "ETRs do not keep track of who requested its mappings"). > > how the association between received EID-to-RLOC=20 > mapping and RLOC local > > information is performed, maintained over time at the=20 > ITR and how > > selection is actually performed among multiple locators ? >=20 > Again, I am having a hard time understanding clearly what you=20 > mean here, > which makes it hard for me to answer. Even if RLOC reachability can be maintained by means of a set of existing mechanisms it is still does not tell anything about the associated EID-to-RLOC. The only updated information about EID-to-RLOC is the one driven by traffic flows. Reconciling both remains unadressed in this document. > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 From trac@tools.ietf.org Wed Apr 21 15:48:09 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886653A686A for ; Wed, 21 Apr 2010 15:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPGz2FT7+Bj1 for ; Wed, 21 Apr 2010 15:48:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9742B3A6AE3 for ; Wed, 21 Apr 2010 15:48:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4ii4-0003yB-RB; Wed, 21 Apr 2010 15:47:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: dino@cisco.com, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 21 Apr 2010 22:47:56 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/48#comment:2 Message-ID: <066.939c0ce8ab5838afbee05e111da0fa58@tools.ietf.org> References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.8523523dc5d63eadc78f4c87ce8cf0b1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dino@cisco.com, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 22:48:09 -0000 #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Changes (by dino@…): * status: new => closed * resolution: => fixed Comment: The ETRs at a site must be configured consistently. Adding this to the EID-to-RLOC Database Mapping definition: EID-to-RLOC Database: a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. Database mapping entries MUST be configured on all ETRs for a given site. That is, the EID-prefixes for the site and locator-set for each EID-prefix MUST be the same on all ETRs so they consistently send Map-Reply messages with the same database mapping contents. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Wed Apr 21 17:43:40 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525F53A692B for ; Wed, 21 Apr 2010 17:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM+Ur6GuMyC6 for ; Wed, 21 Apr 2010 17:43:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 597153A687F for ; Wed, 21 Apr 2010 17:43:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4kVp-00052G-TC; Wed, 21 Apr 2010 17:43:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: dino@cisco.com, wmhaddad@gmail.com X-Trac-Project: lisp Date: Thu, 22 Apr 2010 00:43:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/48#comment:3 Message-ID: <066.f159392533758f6a47360154fc603d07@tools.ietf.org> References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.8523523dc5d63eadc78f4c87ce8cf0b1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dino@cisco.com, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 00:43:40 -0000 #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Changes (by dino@…): * status: closed => reopened * resolution: fixed => Comment: Changing status from closed to open per Joel. -- Ticket URL: lisp LISP WG document issues From jgs@juniper.net Wed Apr 21 19:23:07 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE1A3A69CA for ; Wed, 21 Apr 2010 19:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwi+MtdMzyQm for ; Wed, 21 Apr 2010 19:23:03 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id A89EE3A692C for ; Wed, 21 Apr 2010 19:22:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS8+y9Q8bUHVGf/xh2hQa3baHh6LnxVrN@postini.com; Wed, 21 Apr 2010 19:22:47 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Wed, 21 Apr 2010 19:18:09 -0700 From: John Scudder To: Vince Fuller Date: Wed, 21 Apr 2010 19:18:08 -0700 Thread-Topic: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] Thread-Index: Acrhwg00AAY64mQiTUuJtnargZR7CQ== Message-ID: <1680AD4C-DDD8-4663-BBDE-DA49002B6D99@juniper.net> References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com> <20100421222223.GA40895@vaf-mac1.cisco.com> In-Reply-To: <20100421222223.GA40895@vaf-mac1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 02:23:07 -0000 On Apr 21, 2010, at 6:22 PM, Vince Fuller wrote: >>> as discussed in the spec, we keep locator reachability out of the >>> mapping database system. Thereby if a locator goes down or out of >>> service, *it is not removed* from the locator-set. >>=20 >> ... but note that the parenthetical question had to do with *EID* >> reachability, not locator reachability. >=20 > Can you please re-phrase the question and describe the context? This was covered in Comment 4 of the message Yakov sent to the list: -------------------------------------------------------------------- Comment 4: Suppose a certain EID's mapping entry returned at some point in the past in the Map-Reply by ETR2 lists the RLOCs of two ETRs, ETR1 and ETR2. Suppose that later on due to connectivity issues within the site, ETR1 is able to reach the EID, but ETR2 is not. Is there some means by which traffic is expected to reliably reach the EID in this case? What is it? (Keep in mind that the same RLOC of ETR2 may also be used to reach some other EID2, and ETR2 may have fine connectivity to EID2.) -------------------------------------------------------------------- > Except within the very limited scope of the ALT database mapping system, = the > term "EID reachability" is something of an oxymoron. I guess the answer to comment 4 may shed some light on why it's an "oxymoro= n"? > Focusing only on use of LISP on the Internet (ignoring enterprise use cas= es), > an ETR may publish the set of RLOCs associated with an EID in the global > mapping database. It typically does so by registering that mapping with o= ne > or more Map-Servers. In exceptional circumstances, an ETR may instead con= nect > to the ALT virtual overlay network and advertise an EID-prefix that cover= s > the EID using BGP on the ALT. Understood. > An ITR determines the RLOCs for a specific EID by querying the global > mapping system, typically by sending a Map-Request to a Map-Resolver and > awaiting a matching Map-Reply. Again, in exception circumstances, an ITR > may connect to the ALT and send a Map-Request for an EID on to the ALT wh= ich > then routes it toward the Map-Server or ETR that advertised the covering > EID prefix on to the ALT. Understood. > But this is all orthogonal to the issue of RLOC reachability (and is most= ly > outside of the scope of draft-ietf-lisp anyway), so I'm not sure how to > interpret your comment/question above. If it's still unclear, please let me know. --John= From jzwiebel@cisco.com Wed Apr 21 19:50:30 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCEA13A68BE for ; Wed, 21 Apr 2010 19:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HD0RAEU9ryh for ; Wed, 21 Apr 2010 19:50:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E32EF3A693F for ; Wed, 21 Apr 2010 19:50:28 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,253,1270425600"; d="scan'208";a="186628042" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2010 02:50:19 +0000 Received: from sjc-vpn2-320.cisco.com (sjc-vpn2-320.cisco.com [10.21.113.64]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3M2oI1c006041; Thu, 22 Apr 2010 02:50:19 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: John Zwiebel In-Reply-To: <1680AD4C-DDD8-4663-BBDE-DA49002B6D99@juniper.net> Date: Wed, 21 Apr 2010 16:50:18 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1B80A0F9-26F0-441F-90D2-7F2A14BBA93C@cisco.com> References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com> <20100421222223.GA40895@vaf-mac1.cisco.com> <1680AD4C-DDD8-4663-BBDE-DA49002B6D99@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1078) Cc: "lisp@ietf.org" Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 02:50:30 -0000 On Apr 21, 2010, at 4:18 PM, John Scudder wrote: > On Apr 21, 2010, at 6:22 PM, Vince Fuller wrote: >>>> as discussed in the spec, we keep locator reachability out of the >>>> mapping database system. Thereby if a locator goes down or out of >>>> service, *it is not removed* from the locator-set. >>>=20 >>> ... but note that the parenthetical question had to do with *EID* >>> reachability, not locator reachability. >>=20 >> Can you please re-phrase the question and describe the context? >=20 > This was covered in Comment 4 of the message Yakov sent to the list: >=20 > -------------------------------------------------------------------- > Comment 4: >=20 > Suppose a certain EID's mapping entry returned at some point in the > past in the Map-Reply by ETR2 lists the RLOCs of two ETRs, ETR1 and > ETR2. Suppose that later on due to connectivity issues within the > site, ETR1 is able to reach the EID, but ETR2 is not. Is there some > means by which traffic is expected to reliably reach the EID in > this case? What is it? (Keep in mind that the same RLOC of ETR2 > may also be used to reach some other EID2, and ETR2 may have fine > connectivity to EID2.) >=20 > -------------------------------------------------------------------- Why isn't there redundancy for the internal network? Let me ask what would happen if a packet were to be received by a CE router running BGP under the same conditions? If the CE router advertises a more specific prefix, then the ETR1 and ETR2 can also advertise a more specific prefix so the packet in question will only go to the edge router with a route (reachability) to the EID in = question. So, assuming all edge routers (LISP or regular) advertise the same = prefix, no there isn't "some means" of fixing this problem using LISP -- yet. >=20 >> Except within the very limited scope of the ALT database mapping = system, the >> term "EID reachability" is something of an oxymoron. >=20 > I guess the answer to comment 4 may shed some light on why it's an = "oxymoron"? >=20 >> Focusing only on use of LISP on the Internet (ignoring enterprise use = cases), >> an ETR may publish the set of RLOCs associated with an EID in the = global >> mapping database. It typically does so by registering that mapping = with one >> or more Map-Servers. In exceptional circumstances, an ETR may instead = connect >> to the ALT virtual overlay network and advertise an EID-prefix that = covers >> the EID using BGP on the ALT. >=20 > Understood. >=20 >> An ITR determines the RLOCs for a specific EID by querying the global >> mapping system, typically by sending a Map-Request to a Map-Resolver = and >> awaiting a matching Map-Reply. Again, in exception circumstances, an = ITR >> may connect to the ALT and send a Map-Request for an EID on to the = ALT which >> then routes it toward the Map-Server or ETR that advertised the = covering >> EID prefix on to the ALT. >=20 > Understood. >=20 >> But this is all orthogonal to the issue of RLOC reachability (and is = mostly >> outside of the scope of draft-ietf-lisp anyway), so I'm not sure how = to >> interpret your comment/question above. >=20 > If it's still unclear, please let me know. >=20 > --John > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Wed Apr 21 20:28:35 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C0E3A6998 for ; Wed, 21 Apr 2010 20:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJrg4YT29ePU for ; Wed, 21 Apr 2010 20:28:34 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 65E8A3A6912 for ; Wed, 21 Apr 2010 20:28:34 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ECEA06BE5FC; Wed, 21 Apr 2010 23:28:23 -0400 (EDT) To: jgs@juniper.net, lisp@ietf.org Message-Id: <20100422032823.ECEA06BE5FC@mercury.lcs.mit.edu> Date: Wed, 21 Apr 2010 23:28:23 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 03:28:35 -0000 > From: John Scudder > This was covered in Comment 4 of the message Yakov sent to the list: >> Suppose a certain EID's mapping entry ... lists the RLOCs of two ETRs, >> ETR1 and ETR2. Suppose that later on due to connectivity issues within >> the site, ETR1 is able to reach the EID, but ETR2 is not. Is there >> some means by which traffic is expected to reliably reach the EID in >> this case? I was trying to get caught up enough in my email to answer this the first time it was asked, but I guess this time will do... :-) Those on the LISP design team will recognize this as the issue "EID reachability as opposed to RLOC reachability" from the LISP 'Outstanding Issues' list. (I should explain here that I have a long list of 'Outstanding issues' with LISP; I have not bothered to mention them to the WG, because they almost all have the characteristic that the best fix does not require any _protocol_ changes, so the fix can be deployed at leisure - and, more importantly, the fix can usually be deployed incrementally, with no need to co-ordinate the deployment of the fix. I.e. we can change the spec, to add algorithms to deal with the issue, and it can be deployed in each LISP device independently. Since there are higher-priority things the WG needs to focus on, I have therefore placed those items in a 'look at later' status.) Anyway, as some other posts have sort of pointed out, this issue of endpoint reachability is something that the existing routing/etc architecturs doesn't really handle, and that's the main reason it has not been addressed. In general, an external router, RE1, which is advertising an address range into the core has not verified that all the addresses covered by that block are _actually reachable_, i.e. that it can successfully exchange packets with every addresss in that range. (Which is the meaning of "reachable" we are talking about here, I assume. I should mention here that to many LISP people, 'reachability' has come to mean 'we actually tried it to make sure it _really_ works', not just 'some table entry somewhere says it _should_ work'.). Indeed, with a stub AS which has a static config of what to advertize, a router may be advertizing an address range which it knows, from IGP information, it cannot reach. Or if it has a static internal route, it may advertize that externally without knowing if those destinations are reachable; some intermediate internal router may have failed. And even if the IGP tells RE1 it can get to a particular address range, that may still be incorrect. E.g. if an internal router, RI1, is telling RE1 that RI1 can reach a particular range, but there is some sort of defect which prevents RI1 from reaching a particular address in that range (perhaps a bad port on a hub, or something like that), RE1 has no way of knowing that. Since this limitation seems to already be generally acceptable today, we did not think it desirable to add the extra complexity/overhead which would be needed in order to 'solve' a problem that apparently the world is not clamouring to have solved. Perhaps you had in mind a weaker version of 'EID reachability'? (Bearing in mind that the term means different things in different communities.) Did you simply mean 'an ETR should not advertize an address range in a mapping unless it has indications, from the IGP, that it can actually reach that address range'? I'm not sure that's really a 'LISP protocol' issue, any more than the analogous BGP behaviour is a BGP issue; yes, it is an issue for how the interface between BGP and the rest of the router is specified (i.e. does one even allow static routes to be configured, or does one only allow BGP to adversize address blocks which it has live internal dynamic routes to)? Similarly, if you'd simply like the interface between the ETR and the internal routing to be more dynamic, so that the mappings are less likely to contain incorrect information, that's fine, but it's more of a 'LISP interfacing/usage specification' thing. If on the other hand you really did mean 'an ETR should not advertize a mapping for an EID X unless that EID is reachable from the ETR' (using the strong meaning of "reachable"), that's something I can discuss at some length. (I have thought that through, in some detail, but examining the problem at an architectural level - i.e. not specific to LISP, the same tradeoffs/constraints would apply to any packet-switching system trying to implement this functionality.) But I won't launch into that until I'm sure that's what you're really trying to do. Noel From jnc@mercury.lcs.mit.edu Wed Apr 21 21:17:51 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7C93A6922 for ; Wed, 21 Apr 2010 21:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.484 X-Spam-Level: X-Spam-Status: No, score=-4.484 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1X+SIUQnv8n for ; Wed, 21 Apr 2010 21:17:49 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 4B2293A6AD5 for ; Wed, 21 Apr 2010 21:17:47 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 18F446BE5FC; Thu, 22 Apr 2010 00:17:36 -0400 (EDT) To: Dimitri.Papadimitriou@alcatel-lucent.com, lisp@ietf.org Message-Id: <20100422041736.18F446BE5FC@mercury.lcs.mit.edu> Date: Thu, 22 Apr 2010 00:17:36 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #32: Editorial Issues Section 6 ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:17:51 -0000 > From: "PAPADIMITRIOU Dimitri" >>> as long as source ITR are not made not aware of these changes by >>> means of arrival of traffic (thus, such changes may never be received >>> by source ITR due to either unidirectional or asymmetric path) >> that's why user data packets carry the 'mapping version number' (of >> the mapping being used by the source ITR for that destination EID) in >> the header (in some packets), so that the destination ETR can detect >> that the source ITR is using an old mapping. The destination ETR can >> then notify the source ITR that it needs to update its mapping. > If and only if, the source ITR receives traffic back from the ETR to > which this ITR sends traffic. Ah, no. (Some of this, such as the 'mapping version number' in the user data headers, may not be in draft-ietf-lisp-06.txt, but only in the forthcoming draft-ietf-lisp-07.txt, which should be out shortly; a later draft-ietf-lisp-08.txt will include changes based on the current discussions on the mailing list.) The notification from the destination ETR to the source ITR is a _control plane_ message, and it is sent as a control message (roughly) as soon as the destination ETR notices that the source ITR is using an old mapping. No user traffic back to the source ITR (acting as an ETR, of course) is needed. The reason for the difference, with the 'mapping vesion number' carried piggy-backed on user data traffic, and the notification that a mapping is outdated being carried in a control message, is the differing requirements of the two functios. _Detecting_ that an ITR is using an outdated mapping is something that needs to be done both quickly, and extremely efficiently. Efficiently, because this is a function that happens all the time - the ITR and ETR must be continually checking to make sure that they are in synchronization, as far as the mapping goes. That is why this information is carried 'piggybacked' on user data traffic from the ITR to the ETR. This mode of carrying the data has the additional advantage that _if there is no traffic from the ITR to the ETR_, there is no need to check to see if the ITR's mapping is up to date. Conversely, if there is traffic (and thus a need to check the mapping), the traffic provides a means to efficiently check the currency of the mapping. _Updating_ the mapping is something, howeever, that likely happens very rarely. Thus, the overhead of performing this operation via a control message is acceptable. In fact, it's more than acceptable, it is necessary - were one to try and piggyback _that_ on user data traffic, one would have the problem which you point out (that if there was no return traffic from the destination xTR to the source xTR, or the return traffic to the site of the source xTR from the destination xTR goes to a different xTR at the source, there would be no way to get the updated mapping there). > Secondly, any selection of an alternate ETR may bring a "older version" > of the mapping (as "ETRs do not keep track of who requested its mappings"). Sorry, this I did not understand. If a source ITR gets a mapping for a destination EID-range, that mapping should list _all_ the ETRs which are valid for that particular destination EID-range. It should not matter which particular ETR for a given destination EID-range it gets the mapping from, they _should_ all be identical. (This is an issue that the Juniper guys have also raised.) > Even if RLOC reachability can be maintained by means of a set of > existing mechanisms it is still does not tell anything about the > associated EID-to-RLOC. By "the associated EID-to-RLOC", do you mean the {EID->RLOC} mapping? As I mentioned above, there is a new mechanism in draft-ietf-lisp-07.txt (although I believe it has been discussed on the list, see for instance: http://www.ietf.org/mail-archive/web/lisp/current/msg02035.html and I guess also at the WG meeting at the last IETF: http://www.ietf.org/mail-archive/web/lisp/current/msg02045.html as well), the purpose of which is specifically to quickly and efficiently detect out-of-date mappings at ITRs. > The only updated information about EID-to-RLOC is the one driven by > traffic flows. Right, but I think I have explained above how this works. > Reconciling both remains unadressed in this document. Sorry, I'm not sure I understand this? Did you mean 'making sure the ITR has the latest {EID->RLOC} mapping remains unadressed in this document'? Noel From Dimitri.Papadimitriou@alcatel-lucent.com Thu Apr 22 02:14:44 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77573A6A2A for ; Thu, 22 Apr 2010 02:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.674 X-Spam-Level: X-Spam-Status: No, score=-3.674 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsUASAb4PXOo for ; Thu, 22 Apr 2010 02:14:42 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 06EC43A69B2 for ; Thu, 22 Apr 2010 02:14:41 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3M9EHrH028277; Thu, 22 Apr 2010 11:14:29 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 11:14:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 11:14:15 +0200 Message-ID: <00275A5B436CA441900CB10936742A380439DFE0@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20100422041736.18F446BE5FC@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #32: Editorial Issues Section 6 ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review Thread-Index: Acrh0sDAFp3if7h9SlyabhQSlwKRFQAIrYig References: <20100422041736.18F446BE5FC@mercury.lcs.mit.edu> From: "PAPADIMITRIOU Dimitri" To: "Noel Chiappa" , X-OriginalArrivalTime: 22 Apr 2010 09:14:16.0725 (UTC) FILETIME=[2ED5C450:01CAE1FC] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [lisp] #32: Editorial Issues Section 6 ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:14:45 -0000 =20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Thursday, April 22, 2010 6:18 AM > To: PAPADIMITRIOU Dimitri; lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [lisp] #32: Editorial Issues Section 6=20 > ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review >=20 >=20 > > From: "PAPADIMITRIOU Dimitri"=20 > >=20 > >>> as long as source ITR are not made not aware of these=20 > changes by > >>> means of arrival of traffic (thus, such changes may=20 > never be received > >>> by source ITR due to either unidirectional or asymmetric path) >=20 > >> that's why user data packets carry the 'mapping=20 > version number' (of > >> the mapping being used by the source ITR for that=20 > destination EID) in > >> the header (in some packets), so that the destination=20 > ETR can detect > >> that the source ITR is using an old mapping. The=20 > destination ETR can > >> then notify the source ITR that it needs to update its mapping. >=20 > > If and only if, the source ITR receives traffic back=20 > from the ETR to > > which this ITR sends traffic. >=20 > Ah, no. The spec./lisp-06 states Section 6.5.2 "So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites." Thus, the ITR will actually update its mapping iff this ITR is also the xTR to which the ETR sends traffic (re-inforced by the statement after the comma). Btw, this statement of Section 6.5.2 is probably the best example showing that control exchanges are driven by the directionality of the traffic flows (not the other way around as it is the case today). > (Some of this, such as the 'mapping version number' in the=20 > user data headers, > may not be in draft-ietf-lisp-06.txt, but only in the forthcoming > draft-ietf-lisp-07.txt, which should be out shortly; a later > draft-ietf-lisp-08.txt will include changes based on the=20 > current discussions > on the mailing list.) >=20 > The notification from the destination ETR to the source ITR=20 > is a _control > plane_ message, and it is sent as a control message (roughly)=20 > as soon as the > destination ETR notices that the source ITR is using an old=20 > mapping. No user > traffic back to the source ITR (acting as an ETR, of course)=20 > is needed. >=20 > The reason for the difference, with the 'mapping vesion=20 > number' carried > piggy-backed on user data traffic, and the notification that=20 > a mapping is > outdated being carried in a control message, is the differing=20 > requirements > of the two functios. >=20 > _Detecting_ that an ITR is using an outdated mapping is=20 > something that needs > to be done both quickly, and extremely efficiently.=20 > Efficiently, because this > is a function that happens all the time - the ITR and ETR=20 > must be continually > checking to make sure that they are in synchronization, as=20 > far as the mapping > goes. That is why this information is carried 'piggybacked'=20 > on user data > traffic from the ITR to the ETR. This mode of carrying the=20 > data has the > additional advantage that _if there is no traffic from the=20 > ITR to the ETR_, > there is no need to check to see if the ITR's mapping is up to date. > Conversely, if there is traffic (and thus a need to check the=20 > mapping), the > traffic provides a means to efficiently check the currency of=20 > the mapping. >=20 > _Updating_ the mapping is something, howeever, that likely=20 > happens very > rarely. Thus, the overhead of performing this operation via a=20 > control message > is acceptable. In fact, it's more than acceptable, it is=20 > necessary - were one > to try and piggyback _that_ on user data traffic, one would=20 > have the problem > which you point out (that if there was no return traffic from=20 > the destination > xTR to the source xTR, or the return traffic to the site of=20 > the source xTR > from the destination xTR goes to a different xTR at the=20 > source, there would > be no way to get the updated mapping there). >=20 >=20 > > Secondly, any selection of an alternate ETR may bring a=20 > "older version" > > of the mapping (as "ETRs do not keep track of who=20 > requested its mappings"). >=20 > Sorry, this I did not understand. If a source ITR gets a mapping for a > destination EID-range, that mapping should list _all_ the=20 > ETRs which are > valid for that particular destination EID-range. It should=20 > not matter which > particular ETR for a given destination EID-range it gets the=20 > mapping from, > they _should_ all be identical. (This is an issue that the=20 > Juniper guys have > also raised.) Indeed, but it does not enable the ITR to keep track of mapping changes at that ETR as long as the ITR does not send traffic to that ETR. We are back to the same problem. =20 > > Even if RLOC reachability can be maintained by means of a set of > > existing mechanisms it is still does not tell anything about the > > associated EID-to-RLOC. >=20 > By "the associated EID-to-RLOC", do you mean the {EID->RLOC} mapping? > As I mentioned above, there is a new mechanism in=20 > draft-ietf-lisp-07.txt > (although I believe it has been discussed on the list, see=20 > for instance: >=20 > http://www.ietf.org/mail-archive/web/lisp/current/msg02035.html >=20 > and I guess also at the WG meeting at the last IETF: >=20 > http://www.ietf.org/mail-archive/web/lisp/current/msg02045.html >=20 > as well), the purpose of which is specifically to quickly and=20 > efficiently > detect out-of-date mappings at ITRs. >=20 > > The only updated information about EID-to-RLOC is the=20 > one driven by > > traffic flows. >=20 > Right, but I think I have explained above how this works. Even if the "mapping should list _all_ the ETRs which are valid for that particular destination EID-range." and if the ITR determines RLOC reachability by means of the mechanisms descibed in Section 6.3, the ITR can not be made aware of the changes in EID-to-RLOC mappings. > > Reconciling both remains unadressed in this document. >=20 > Sorry, I'm not sure I understand this? Did you mean 'making=20 > sure the ITR > has the latest {EID->RLOC} mapping remains unadressed in this=20 > document'? I mean even if the ITR receives all ETR for which it can determine RLOC reachability, it can not derive from RLOC reachability the "version" of the EID-to-RLOC mapping containing that RLOC if it does not send traffic towards that RLOC.=20 The problem is a consequence from my initial statement, EID-to-RLOC synchronization is triggered by traffic (only) following the statement in Section 6.5=20 "However, the ITRs do not know when the mappings change and the ETRs do not keep track of who requested its mappings. For scalability reasons, we want to maintain this approach but need to provide a way for ETRs change their mappings and inform the sites that are currently communicating with the ETR site using such mappings." It is also an architectural problem in the sense that "mapping version" can not be derived from either from RLOC (or from EID) alone. So whatever the ITR would perform as action to determine reachability of RLOC it can not determine the version of the mapping from this RLOC reachability. In fact the same happens concerning the EID. > Noel >=20 From luigi@net.t-labs.tu-berlin.de Thu Apr 22 04:30:26 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C143A6900 for ; Thu, 22 Apr 2010 04:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3tlAt5xJhJs for ; Thu, 22 Apr 2010 04:30:25 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 5B0A93A68CD for ; Thu, 22 Apr 2010 04:30:24 -0700 (PDT) Received: from dyn116.net.t-labs.tu-berlin.de (dyn116.net.t-labs.tu-berlin.de [130.149.220.116]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 53332700038E; Thu, 22 Apr 2010 13:30:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: <00275A5B436CA441900CB10936742A380439DEC0@FRVELSMBS22.ad2.ad.alcatel.com> Date: Thu, 22 Apr 2010 13:30:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <906A5DA4-BB06-4297-B889-0CC7D053175B@net.t-labs.tu-berlin.de> References: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> <077.693673ec0f5bf65a905d7b9a2d272fbd@tools.ietf.org> <00275A5B436CA441900CB10936742A380439DEC0@FRVELSMBS22.ad2.ad.alcatel.com> To: PAPADIMITRIOU Dimitri X-Mailer: Apple Mail (2.1078) Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 11:30:26 -0000 Hi Dimitri, Issue #32 has been modified yesterday and split in several technical = issues, so that each one can be discussed separately. Ciao Luigi On Apr 21, 2010, at 22:59 , PAPADIMITRIOU Dimitri wrote: > Hi Luigi, >=20 > Some comments classified as "editorial" often translate > under-specification (or specification that is difficult to = understand); > so, conservative approach consisted in asking clarification(s). >=20 > An example: in Section 6.5 clearly states that mappings maintenance = and > processing is traffic driven (whereas EID processing is configuration > driven and RLOC reachability is topology driven). EID and RLOC follows > traffic between TR that "hosts" them. Synchronizing EID and RLOC based > on traffic leads to selection of mappings that are invalid in case of > change in EID and RLOC as long as source ITR are not made not aware of > these changes by means of arrival of traffic (thus, such changes may > never be received by source ITR due to either unidirectional or > asymmetric path) or solicited cached entries replacement/time-out.=20 >=20 > Hence, the question related to Section 6.2/6.3 concerning the > association of the RLOC to the RLOC part of the mapping (and the > association of the EID to the EID part of the mapping in Section 6.1) > knowing the strong condition imposed by Section 6.5: RLOC reachability > is driven by topology and controlled by ITR and EID-to-RLOC mapping is > driven by traffic and controlled by ETR -> how the association = between > received EID-to-RLOC mapping and RLOC local information is performed, > maintained over time at the ITR and how selection is actually = performed > among multiple locators ? >=20 > Thanks, > -dimitri. >=20 >=20 >=20 >> -----Original Message----- >> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 >> Behalf Of lisp issue tracker >> Sent: Wednesday, April 21, 2010 9:37 AM >> To: luigi@net.t-labs.tu-berlin.de >> Cc: lisp@ietf.org >> Subject: Re: [lisp] #32: Editorial Issues Section 6 of=20 >> draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review >>=20 >> #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt=20 >> raised by Dimitri >> Papadimitriou in his review >> ------------------------------------------+------------------- >> -------------- >> Reporter: luigi@... | Owner: =20 >>=20 >> Type: editorial | Status: new=20 >>=20 >> Priority: trivial | Component: =20 >> draft-ietf-lisp >> Severity: - | Keywords: =20 >>=20 >> ------------------------------------------+------------------- >> -------------- >>=20 >> Comment(by luigi@...): >>=20 >> '''Yakov Rekhter raises a related question in his review of=20 >> draft-ietf- >> lisp-06.txt (part 2):''' >>=20 >> Section 6.2 >>=20 >> This section uses "client-side" and "server-side" extensively without >> defining the terms. They seem to be the same as "ITR" and=20 >> "ETR" in the >> rest of the document. Terminology should be defined or=20 >> harmonized with >> the rest of the document. >>=20 >> --=20 >> Ticket URL:=20 >> >> lisp >> LISP WG document issues >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 From trac@tools.ietf.org Thu Apr 22 04:38:00 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D35D28C0D8 for ; Thu, 22 Apr 2010 04:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liOkLn+p3107 for ; Thu, 22 Apr 2010 04:37:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8090E28C10A for ; Thu, 22 Apr 2010 04:37:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4uj4-0007fz-2O; Thu, 22 Apr 2010 04:37:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 11:37:46 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/73 Message-ID: <068.11139862467bb967cdc8cf5e6cf8c426@tools.ietf.org> X-Trac-Ticket-ID: 73 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #73: Tunnel liveness (from R. Bonica review for the RTG directorate) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 11:38:00 -0000 #73: Tunnel liveness (from R. Bonica review for the RTG directorate) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- In http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01379.html the following issue concerning tunnel liveness is raised: - Tunnel Liveness - The document says little about what happens when a tunnel connecting iTR to eTR fails? Does temporary black-holing result? What is the restoration mechanism? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 04:42:41 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE103A6868 for ; Thu, 22 Apr 2010 04:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU-lD1ADYIzj for ; Thu, 22 Apr 2010 04:42:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CE1ED3A69BE for ; Thu, 22 Apr 2010 04:42:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4unO-0007r0-Dj; Thu, 22 Apr 2010 04:42:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 11:42:14 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/74 Message-ID: <068.db5abe2159ac4ec249bc5681aa7f49ef@tools.ietf.org> X-Trac-Ticket-ID: 74 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #74: Deployment Scenarios (from R. Bonica review for the RTG directorate) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 11:42:41 -0000 #74: Deployment Scenarios (from R. Bonica review for the RTG directorate) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- In http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01379.html the following issue concerning LISP's deployment is raised: - During the migration period, when an ITR receives a packet, it must determine whether that packet's destination address is an EID or an RLOC. The document isn't clear about how the ITR does this. One possibility is to encode that information in the IP address. Another is to query the network to find out. While the first solution may work for IPv6, it won't work well for IPv4. The second solution presents performance problems regardless of IP version. - LISP's goals are best achieved when the entire Internet is surrounded by xTRs (i.e., at the end of migration). However, it is impossible to know when that state has been achieved. The document should say something about when an operator has completed its migration effort and what benefit it can expect to reap at that time. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 04:48:36 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B9C3A68CD for ; Thu, 22 Apr 2010 04:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2veB3DGzMsu for ; Thu, 22 Apr 2010 04:48:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 77FDC3A68A5 for ; Thu, 22 Apr 2010 04:48:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4utO-0001t8-1Y; Thu, 22 Apr 2010 04:48:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 11:48:26 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/26#comment:6 Message-ID: <069.adc37efefae932c2e50c1bd6d3429a05@tools.ietf.org> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #26: Overlapping Map prefixes in EID map cache X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 11:48:36 -0000 #26: Overlapping Map prefixes in EID map cache ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): Replying to [comment:3 luigi@…]: This is Comment 23 of Rekhter's review. > '''Yakov Rekhter raises a related question in his review of draft-ietf- lisp-06.txt (part 2):''' > > Section 6.1.5 EID-to-RLOC UDP Map-Reply message > > A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record > count of 3 to be returned with mapping records for EID-prefixes > 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. > > Why would those three prefixes be returned? A more general comment is > that what a Map-Reply must return in response to a given Map-Request > is underspecified (or the specification is not comprehensible). To > address this perhaps insert something like the following: > > When an ETR replies to a Map-Request, it must reply with its > EID-prefix that is the best match for the Map-Request. In addition, if > it is configured with any EID-prefixes which are more-specifics of the > best match EID-prefix that it returns in its Map-Reply, it must return > all of those more-specific EID-prefixe s in the same Map-Reply. -- Ticket URL: lisp LISP WG document issues From luigi@net.t-labs.tu-berlin.de Thu Apr 22 04:53:39 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C283A6A86 for ; Thu, 22 Apr 2010 04:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jklun4rp-UtL for ; Thu, 22 Apr 2010 04:53:36 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 016553A6A14 for ; Thu, 22 Apr 2010 04:53:30 -0700 (PDT) Received: from dyn116.net.t-labs.tu-berlin.de (dyn116.net.t-labs.tu-berlin.de [130.149.220.116]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id C87C9700038B for ; Thu, 22 Apr 2010 13:53:18 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Luigi Iannone In-Reply-To: <069.adc37efefae932c2e50c1bd6d3429a05@tools.ietf.org> Date: Thu, 22 Apr 2010 13:53:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DC770AE-77A2-497D-AD41-64F323D0CC5F@net.t-labs.tu-berlin.de> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> <069.adc37efefae932c2e50c1bd6d3429a05@tools.ietf.org> To: lisp@ietf.org X-Mailer: Apple Mail (2.1078) Subject: [lisp] Issue tracker: bunch of updates ahead X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 11:53:39 -0000 Hi All, Yakov asked to clearly add his comments number to the tickets that his = review has generated (this may facilitate the tracking from the original = review). I will proceed to the update, which translates in a number of mails from = the issue tracker. Unless you are really interested in the comment number you can safely = discard the forthcoming emails, since I will not change the content. Luigi =20= From trac@tools.ietf.org Thu Apr 22 04:55:18 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECA43A6A14 for ; Thu, 22 Apr 2010 04:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ1fpJjO2joG for ; Thu, 22 Apr 2010 04:55:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3F3333A692E for ; Thu, 22 Apr 2010 04:55:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4uzr-00026K-R0; Thu, 22 Apr 2010 04:55:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 11:55:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/26#comment:7 Message-ID: <069.84551887e7e83d17776321097f222a4b@tools.ietf.org> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #26: Overlapping Map prefixes in EID map cache X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 11:55:18 -0000 #26: Overlapping Map prefixes in EID map cache ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): Replying to [comment:4 luigi@…]: '''This is Comment 24 of Rekhter's review''' > '''Yakov Rekhter raises a related question in his review of draft-ietf- lisp-06.txt (part 2):''' > > Section 6.1.5 EID-to-RLOC UDP Map-Reply message > > There are several problems with the following paragraph: > > Note that not all overlapping EID-prefixes need to be returned, only > the more specifics (note in the second example above 10.0.0.0/8 was > not returned for requesting EID 10.1.5.5) entries for the matching > EID-prefix of the requesting EID. When more than one EID-prefix is > returned, all SHOULD use the same Time-to-Live value so they can all > time out at the same time. When a more specific EID-prefix is received > later, its Time-to-Live value in the Map-Reply record can be stored > even when other less specifics exist. When a a less specific > EID-prefix is received later, its map-cache expiration time should be > set to the minimum expiration time of any more specific EID-prefix in > the map-cache. > > First, it assumes that the ITR will exactly obey the TTLs given in the > Map-Reply. Most caching systems allow caches to manage timeouts on > their own, especially allowing early timeouts (for example to create > space in the cache if it fills). If this is NOT allowed in LISP (and > it seems not to be), that needs to be spelled out. What are the bad > consequences of timing entries out at different times, which are not > equal to the TTLs given? -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 04:56:52 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198113A6A62 for ; Thu, 22 Apr 2010 04:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbRRpZ70rdkR for ; Thu, 22 Apr 2010 04:56:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 52FDB3A6976 for ; Thu, 22 Apr 2010 04:56:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4v1I-0002BY-Ty; Thu, 22 Apr 2010 04:56:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 11:56:36 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/26#comment:8 Message-ID: <069.721b130e0ef815b34d7cf5b6e3fe973b@tools.ietf.org> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #26: Overlapping Map prefixes in EID map cache X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 11:56:52 -0000 #26: Overlapping Map prefixes in EID map cache ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): Replying to [comment:5 luigi@…]: '''This is Comment 24 of Rekhter's review:''' > '''Yakov Rekhter raises a related question in his review of draft-ietf- lisp-06.txt (part 2):''' > > Section 6.1.5 EID-to-RLOC UDP Map-Reply message > > The following sentence is confusing: > > When a more specific EID-prefix is received later, its Time-to-Live > value in the Map-Reply record can be stored even when other less > specifics exist. > > And this sentence: > > When a a less specific EID-prefix is received later, its map-cache > expiration time should be set to the minimum expiration time of > any more specific EID-prefix in the map-cache. > > isn't clear as to what it's mandating. Is this a requirement for ITR > behavior ? > -- Ticket URL: lisp LISP WG document issues From lear@cisco.com Thu Apr 22 04:57:51 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F6E3A6AB1 for ; Thu, 22 Apr 2010 04:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.251 X-Spam-Level: X-Spam-Status: No, score=-8.251 tagged_above=-999 required=5 tests=[AWL=2.347, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ojz-goBKFfG for ; Thu, 22 Apr 2010 04:57:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B94E83A6AA0 for ; Thu, 22 Apr 2010 04:57:49 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkBAGrWz0uQ/uCWiWdsb2JhbACDFpkNFQEBAQoLEREGHKM2iGeRa4QibQQ X-IronPort-AV: E=Sophos;i="4.52,256,1270425600"; d="scan'208,217";a="59869007" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2010 11:57:38 +0000 Received: from ams3-vpn-dhcp6001.cisco.com (ams3-vpn-dhcp6001.cisco.com [10.61.87.112]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MBvcee005700; Thu, 22 Apr 2010 11:57:38 GMT Message-ID: <4BD039A1.3070205@cisco.com> Date: Thu, 22 Apr 2010 13:57:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100421 Lanikai/3.1b2pre MIME-Version: 1.0 To: Luigi Iannone References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> <069.adc37efefae932c2e50c1bd6d3429a05@tools.ietf.org> <3DC770AE-77A2-497D-AD41-64F323D0CC5F@net.t-labs.tu-berlin.de> In-Reply-To: <3DC770AE-77A2-497D-AD41-64F323D0CC5F@net.t-labs.tu-berlin.de> Content-Type: multipart/alternative; boundary="------------070605000504070801090402" Cc: lisp@ietf.org Subject: Re: [lisp] Issue tracker: bunch of updates ahead X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 11:57:51 -0000 This is a multi-part message in MIME format. --------------070605000504070801090402 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Luigi, Are these all new issues? Are there overlapping comments? And can we get a summary of all the open issues once you are finished? Thanks, Eliot On 4/22/10 1:53 PM, Luigi Iannone wrote: > Hi All, > > Yakov asked to clearly add his comments number to the tickets that his review has generated (this may facilitate the tracking from the original review). > > I will proceed to the update, which translates in a number of mails from the issue tracker. > > Unless you are really interested in the comment number you can safely discard the forthcoming emails, since I will not change the content. > > Luigi > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --------------070605000504070801090402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Luigi,

Are these all new issues?  Are there overlapping comments?  And can we get a summary of all the open issues once you are finished?

Thanks,

Eliot

On 4/22/10 1:53 PM, Luigi Iannone wrote: 
Hi All,

Yakov asked to clearly add his comments number to the tickets that his review has generated (this may facilitate the tracking from the original review).

I will proceed to the update, which translates in a number of mails from the issue tracker.

Unless you are really interested in the comment number you can safely discard the forthcoming emails, since I will not change the content.

Luigi  
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--------------070605000504070801090402-- From trac@tools.ietf.org Thu Apr 22 04:58:45 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B5A3A6927 for ; Thu, 22 Apr 2010 04:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DyP0Ec6WGNE for ; Thu, 22 Apr 2010 04:58:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F315E3A688E for ; Thu, 22 Apr 2010 04:58:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4v3D-0002Dp-Ih; Thu, 22 Apr 2010 04:58:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 11:58:35 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/68#comment:1 Message-ID: <077.994204e0a6376c341a78729a71a7612c@tools.ietf.org> References: <068.f483118418ff0a04689ef79494e01869@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <068.f483118418ff0a04689ef79494e01869@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 11:58:45 -0000 #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 6.1.5 EID-to-RLOC UDP Map-Reply message > > When sending a Map-Reply message, the destination address is copied > from the source address of the Map-Request or Data-Probe message > which is invoking the reply. The source address of the Map-Reply is > one of the local locator addresses listed in the locator-set of any > mapping record in the message. > > What is the source address for a negative reply, which has a zero > length locator -set ? New description: '''This is part of Comment 24 of Rekhter's review''' Section 6.1.5 EID-to-RLOC UDP Map-Reply message When sending a Map-Reply message, the destination address is copied from the source address of the Map-Request or Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local locator addresses listed in the locator-set of any mapping record in the message. What is the source address for a negative reply, which has a zero length locator -set ? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:01:29 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178093A6973 for ; Thu, 22 Apr 2010 05:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsJ1CJlo2L7S for ; Thu, 22 Apr 2010 05:01:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 652EB3A6907 for ; Thu, 22 Apr 2010 05:01:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4v5r-0002Lj-0M; Thu, 22 Apr 2010 05:01:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:01:18 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/69#comment:2 Message-ID: <077.4882400e72c2971f21584b95cd730030@tools.ietf.org> References: <068.062591f9c2a73c88a94091fd86bb2c73@tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <068.062591f9c2a73c88a94091fd86bb2c73@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #69: Inadequate solution for ETR overclaims (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:01:29 -0000 #69: Inadequate solution for ETR overclaims (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 6.1.5.1 > > This section correctly identifies an attack where an ETR overclaims, > saying that it owns a larger span of prefixes than it really does. The > proposed solutions seem inadequate; in particular, the limiting the > mask-length that you'll accept from a given ETR seems weak. I.e., how > could an ITR determine a "configured prefix length" for a given EID > prefix? > > This is a serious deficiency. It is somewhat analogous to the weakness > of the BGP routing system, except that it is much less amenable to > auditing than BGP (since the mapping data is only presented on demand, > an auditor can't simply get a feed) and there are many more machines > playing than in the BGP system. New description: '''This is Comment 25 of Rekhter's review''' Section 6.1.5.1 This section correctly identifies an attack where an ETR overclaims, saying that it owns a larger span of prefixes than it really does. The proposed solutions seem inadequate; in particular, the limiting the mask-length that you'll accept from a given ETR seems weak. I.e., how could an ITR determine a "configured prefix length" for a given EID prefix? This is a serious deficiency. It is somewhat analogous to the weakness of the BGP routing system, except that it is much less amenable to auditing than BGP (since the mapping data is only presented on demand, an auditor can't simply get a feed) and there are many more machines playing than in the BGP system. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:05:51 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B46B3A69F5 for ; Thu, 22 Apr 2010 05:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gICuW6xSv9d for ; Thu, 22 Apr 2010 05:05:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 954DC3A6899 for ; Thu, 22 Apr 2010 05:05:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vA5-0002U1-6k; Thu, 22 Apr 2010 05:05:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:05:41 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/32#comment:3 Message-ID: <077.2e8b6acb61e4bc068721ae48781cd0b6@tools.ietf.org> References: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:05:51 -0000 #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Comment(by luigi@…): Replying to [comment:1 luigi@…]: '''This is part of Comment 26 of Rekhter's review''' > '''Yakov Rekhter raises a related question in his review of draft-ietf- lisp-06.txt (part 2):''' > > Section 6.2 > > This section uses "client-side" and "server-side" extensively without > defining the terms. They seem to be the same as "ITR" and "ETR" in the > rest of the document. Terminology should be defined or harmonized with > the rest of the document. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:08:33 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72533A6899 for ; Thu, 22 Apr 2010 05:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X37KIRq5KE7i for ; Thu, 22 Apr 2010 05:08:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 35D903A688E for ; Thu, 22 Apr 2010 05:08:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vCh-0002vO-II; Thu, 22 Apr 2010 05:08:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:08:23 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/70#comment:1 Message-ID: <077.e3ea59a4979b57fafa451e06e3fb1e50@tools.ietf.org> References: <068.7ad8426e5defed8efc75a91b3b935546@tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <068.7ad8426e5defed8efc75a91b3b935546@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #70: Client not respecting RLOC weights (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:08:33 -0000 #70: Client not respecting RLOC weights (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 6.2 > > Server-side returns a list of RLOC where a subset of the list has the > same best priority. Client can only use the subset list according to > the weighting assigned by the server-side. > > If the client can gain some advantage (or thinks it can) by ignoring > the server's weighting, it will. There should be some consideration of > whether this is a problem, and if so, how to address it. New description: '''This is part of Comment 26 of Rekhter's review''' Section 6.2 Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. If the client can gain some advantage (or thinks it can) by ignoring the server's weighting, it will. There should be some consideration of whether this is a problem, and if so, how to address it. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:10:16 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0A03A68DD for ; Thu, 22 Apr 2010 05:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.612 X-Spam-Level: X-Spam-Status: No, score=-100.612 tagged_above=-999 required=5 tests=[AWL=-1.870, BAYES_00=-2.599, FRT_PROFIT1=3.858, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5yeUnawA8cB for ; Thu, 22 Apr 2010 05:10:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 932143A688E for ; Thu, 22 Apr 2010 05:10:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vEK-00031R-F8; Thu, 22 Apr 2010 05:10:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:10:04 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/43#comment:3 Message-ID: <077.5a509a420db0e46f95ba9942f84b8696@tools.ietf.org> References: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #43: Issues related to RLOC rechability (definition and mechanism) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:10:16 -0000 #43: Issues related to RLOC rechability (definition and mechanism) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > '''This ticket groups together several inter-related issues concerning > RLOC reachability raised by both D. Papadimitriou and Y. Rekhter in their > respective review. (''If people identify specific and isolated issues > that would like to see in different tickets please let me know'').''' > > '''From P. Papadimitriou's Review:''' > > Section 6.1.5 where is the “Data Probe packet†format defined actually ? > > Section 6.1.5 states “The RLOCs in the Map-Reply are the > globally-routable IP addresses of the ETR but are not necessarily > reachable; separate testing of reachability is required.†Section 6.3 > does not define any procedure actually and does not define any > criteria for deciding when the RLOC is reachable or not. The key > question is if the ITR persists in testing reachability and there is > no criteria process by which such decision would stop, the traffic > would be forwarded by means of the “separate/alternative topology†> forever. > > Section 6.3 proposes “encapsulated traffic†based procedures thus, if > there is no traffic there is no RLOC reachability “test†possible. On > the other hand, that section states certain “ICMP exchanges†are > documented but reachability of RLOC does not mean availability of the > associated EID. There no actual “EID-to-RLOC†testing procedure being > defined in the document? > > What is struggling here is that the “introductory†sections of the > document refer to “functional†separations but all the techniques > described in this document (and for RLOC reachability testing in > particular) result in a complex inter-twin between control messaging > as part of the forwarding plane and forwarding date as part of the > control plane of routers. The latter is typical from Data Probes > processing. If this is the design choice of LISP so let it be but 1) > please proof it offers any better functionality compared to “current†> design and 2) better cost/performance. It is far from obvious that the > complexity concentrated at TR taking into the proposed design offers > any real compelling argument. This may also defeat the argument stated > in the introduction that “network deployment†is facilitated by > network-based solutions. > > Section 6.3 Point 1 what is the use of the “Loc-Status-Bits†if there > is no return traffic (or more precisely no return traffic passing via > this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The > ETR may process this information but never use it. > > Section 6.3 states “Each ITR can thus observe the presence or lack of > a default route originated by the others to determine the Locator > Status Bits it sets for them.†This does not tell which technique to > use when no default route are used at all (under “non-normal†> circumstances … what should define normality in this context). > > Section 6.3.1 states “This mechanism does not completely solve the > forward path reachability problem as traffic may be unidirectional.†> The forwarding path may simply be asymmetric (there is nothing that > imposes reverse path reaching the source RLOC in case of dual attached > sites). This shortcoming defeats this mechanism as an ITR is not > “aware†of its neighboring ITR EID-to-RLOC mappings (connected to the > same site). This mechanism can only be safely used if the RLOC pair > between two sites is unique and remains unique. > > Section 6.3.2 RLOC Probing by means of the “control plane†this opens > the question of what is actually probed the “RLOC†or the EID-to-RLOC > entries of the ETR’s database. The difference stems because the latter > are static entries the liveness of the former are dependent on the > incoming interface liveness. That is entries can be available in the > database but if database entries are not in sync with the actual RLOC > status there is no possibility to detect reachability of RLOCs by > means of this mechanism. > > > ''' From Y. Rekhter's Review:''' > > Section 6.3 > Several mechanisms for determining RLOC reachability are currently > defined: > > 1. An ETR may examine the Loc-Status-Bits in the LISP header of an > encapsulated data packet received from an ITR. If the ETR is also acting > as an ITR and has traffic to return to the original ITR site, it can use > this status information to help select an > RLOC. > > 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message > for an RLOC it is using. This indicates that the RLOC is likely down. > > 3. An ITR which participates in the global routing system can > determine that an RLOC is down if no BGP RIB route exists that matches > the RLOC IP address. > > 4. An ITR may receive an ICMP Port Unreachable message from a > destination host. This occurs if an ITR attempts to use interworking > [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable > site. > > 5. An ITR may receive a Map-Reply from a ETR in response to a > previously sent Map-Request. The RLOC source of the Map-Reply is > likely up since the ETR was able to send the Map-Reply to the ITR. > > 6. When an ETR receives an encapsulated packet from an ITR, the source > RLOC from the outer header of the packet is likely up. > > 7. An ITR/ETR pair can use the Locator Reachability Algorithms > described in this section, namely Echo-Noncing or RLOC-Probing. > > For the first mechanism to work it is not sufficient for the ETR to > have traffic "to return to the original ITR site" - the ETR has to > have traffic to return to the original ITR. And if the ETR has no > traffic to return to the original ITR (even if the ETR has traffic to > return to some other ITR of the site), then the first mechanism is > useless. > > Moreover, the first mechanism is predicated on the assumption that the > Loc-Status-Bits contain up to date information about reachability > of all ETRs at the site. The document describes how the ITR obtains > this information only for the case of CE-based or intra-site based > ITRs. Thus it does not cover the case where the ITR is the > PE. Moreover, for the case of CE-based ITR the scheme does not work if > the site runs RIP as its IGP. Furthermore it assumes that just because > the correspondent ITR can reach the given RLOC, the ETR also > will. Since IP connectivity is not always transitive in this > way, the fact that the corresponding ITR can reach the given RLOC does > not mean that the ETR also can. > > The second mechanism depends on ICMP Unreachable. As such it may > result in sustained traffic blackholing due to ICMP Unreachable being > dropped along the path. Also, how would that mechanism handle DoS > attacks caused by spoofed ICMP Unreachables ? Finally, if ITR > is within a site, and behind a firewall, would the firewall pass ICMP > Unreachables in the first place ? > > The third mechanism is likely to be of very limited use, as an ETR > going down is unlikely to cause the route that covers the RLOC of that > ETR to be withdrawn (unless this is /32 route). > > The fourth mechanism is applicable only for LISP interworking between > a LISP and a non-LISP site. > > The fifth and the sixth mechanisms do provide the indication that the > ETR is up, but do not provide the information when the ETR is down. As > such they are not applicable for determining unreachability, as > unreachability requires the ability to determine that the ETR is down. > > That leaves us with the seventh mechanism. This mechanism offers two > options: Echo Nonce (section 6.3.1) and RLOC Probing (section > 6.3.2). The Echo Nonce mechanism is applicable only when there is a > bidirectional flow between a pair of RLOCs. The RLOC Probing mechanism > has scaling limitations - quoting from 6.3.2: > > The major disadvantage of RLOC Probing is in the number of control > messages required and the amount of bandwidth used to obtain those > benefits, especially if the requirement for failure detection times > are very small. > > Given the above, what are the mechanisms that are available when xTRs > are PEs (as described in 8.3), and what are their scaling > characteristics ? > > Consider an example of site A with two xTRs A1 and A2, and site B with > two xTRs, B1 and B2. Now imagine that outbound traffic from A to B is > using the ITR component of A1, and talking to the ETR component B1 of > B. But the traffic from B back to A uses the ITR component of B2 and > is sending to the ETR component of A2. So each ITR->ETR flow is > unidirectional, even though all four devices are > fully capable of bidirectional communication. What are the options for > the RLOC reachability in this scenario ? > > The ITR can test the reachability of the unreachable Locator by > sending periodic Requests. Both Requests and Replies MUST be rate- > limited. Locator reachability testing is never done with data packets > since that increases the risk of packet loss for end-to-end sessions. > > How would one use data packets for testing locator reachability ? New description: '''This ticket groups together several inter-related issues concerning RLOC reachability raised by both D. Papadimitriou and Y. Rekhter in their respective review. (''If people identify specific and isolated issues that would like to see in different tickets please let me know'').''' '''From P. Papadimitriou's Review:''' Section 6.1.5 where is the “Data Probe packet†format defined actually ? Section 6.1.5 states “The RLOCs in the Map-Reply are the globally-routable IP addresses of the ETR but are not necessarily reachable; separate testing of reachability is required.†Section 6.3 does not define any procedure actually and does not define any criteria for deciding when the RLOC is reachable or not. The key question is if the ITR persists in testing reachability and there is no criteria process by which such decision would stop, the traffic would be forwarded by means of the “separate/alternative topology†forever. Section 6.3 proposes “encapsulated traffic†based procedures thus, if there is no traffic there is no RLOC reachability “test†possible. On the other hand, that section states certain “ICMP exchanges†are documented but reachability of RLOC does not mean availability of the associated EID. There no actual “EID-to-RLOC†testing procedure being defined in the document? What is struggling here is that the “introductory†sections of the document refer to “functional†separations but all the techniques described in this document (and for RLOC reachability testing in particular) result in a complex inter-twin between control messaging as part of the forwarding plane and forwarding date as part of the control plane of routers. The latter is typical from Data Probes processing. If this is the design choice of LISP so let it be but 1) please proof it offers any better functionality compared to “current†design and 2) better cost/performance. It is far from obvious that the complexity concentrated at TR taking into the proposed design offers any real compelling argument. This may also defeat the argument stated in the introduction that “network deployment†is facilitated by network-based solutions. Section 6.3 Point 1 what is the use of the “Loc-Status-Bits†if there is no return traffic (or more precisely no return traffic passing via this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The ETR may process this information but never use it. Section 6.3 states “Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them.†This does not tell which technique to use when no default route are used at all (under “non-normal†circumstances … what should define normality in this context). Section 6.3.1 states “This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional.†The forwarding path may simply be asymmetric (there is nothing that imposes reverse path reaching the source RLOC in case of dual attached sites). This shortcoming defeats this mechanism as an ITR is not “aware†of its neighboring ITR EID-to-RLOC mappings (connected to the same site). This mechanism can only be safely used if the RLOC pair between two sites is unique and remains unique. Section 6.3.2 RLOC Probing by means of the “control plane†this opens the question of what is actually probed the “RLOC†or the EID-to-RLOC entries of the ETR’s database. The difference stems because the latter are static entries the liveness of the former are dependent on the incoming interface liveness. That is entries can be available in the database but if database entries are not in sync with the actual RLOC status there is no possibility to detect reachability of RLOCs by means of this mechanism. ''' From Y. Rekhter's Review:''' '''This is Comment 27''' Section 6.3 Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. For the first mechanism to work it is not sufficient for the ETR to have traffic "to return to the original ITR site" - the ETR has to have traffic to return to the original ITR. And if the ETR has no traffic to return to the original ITR (even if the ETR has traffic to return to some other ITR of the site), then the first mechanism is useless. Moreover, the first mechanism is predicated on the assumption that the Loc-Status-Bits contain up to date information about reachability of all ETRs at the site. The document describes how the ITR obtains this information only for the case of CE-based or intra-site based ITRs. Thus it does not cover the case where the ITR is the PE. Moreover, for the case of CE-based ITR the scheme does not work if the site runs RIP as its IGP. Furthermore it assumes that just because the correspondent ITR can reach the given RLOC, the ETR also will. Since IP connectivity is not always transitive in this way, the fact that the corresponding ITR can reach the given RLOC does not mean that the ETR also can. The second mechanism depends on ICMP Unreachable. As such it may result in sustained traffic blackholing due to ICMP Unreachable being dropped along the path. Also, how would that mechanism handle DoS attacks caused by spoofed ICMP Unreachables ? Finally, if ITR is within a site, and behind a firewall, would the firewall pass ICMP Unreachables in the first place ? The third mechanism is likely to be of very limited use, as an ETR going down is unlikely to cause the route that covers the RLOC of that ETR to be withdrawn (unless this is /32 route). The fourth mechanism is applicable only for LISP interworking between a LISP and a non-LISP site. The fifth and the sixth mechanisms do provide the indication that the ETR is up, but do not provide the information when the ETR is down. As such they are not applicable for determining unreachability, as unreachability requires the ability to determine that the ETR is down. That leaves us with the seventh mechanism. This mechanism offers two options: Echo Nonce (section 6.3.1) and RLOC Probing (section 6.3.2). The Echo Nonce mechanism is applicable only when there is a bidirectional flow between a pair of RLOCs. The RLOC Probing mechanism has scaling limitations - quoting from 6.3.2: The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times are very small. Given the above, what are the mechanisms that are available when xTRs are PEs (as described in 8.3), and what are their scaling characteristics ? Consider an example of site A with two xTRs A1 and A2, and site B with two xTRs, B1 and B2. Now imagine that outbound traffic from A to B is using the ITR component of A1, and talking to the ETR component B1 of B. But the traffic from B back to A uses the ITR component of B2 and is sending to the ETR component of A2. So each ITR->ETR flow is unidirectional, even though all four devices are fully capable of bidirectional communication. What are the options for the RLOC reachability in this scenario ? The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. How would one use data packets for testing locator reachability ? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:12:27 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118183A68EC for ; Thu, 22 Apr 2010 05:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.604 X-Spam-Level: X-Spam-Status: No, score=-100.604 tagged_above=-999 required=5 tests=[AWL=-1.862, BAYES_00=-2.599, FRT_PROFIT1=3.858, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKM17v465J7C for ; Thu, 22 Apr 2010 05:12:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4C5673A68A5 for ; Thu, 22 Apr 2010 05:12:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vGM-0005nH-SL; Thu, 22 Apr 2010 05:12:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:12:10 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/43#comment:4 Message-ID: <077.65551c775d432299a84c2bb3153b2c4a@tools.ietf.org> References: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #43: Issues related to RLOC rechability (definition and mechanism) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:12:27 -0000 #43: Issues related to RLOC rechability (definition and mechanism) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > '''This ticket groups together several inter-related issues concerning > RLOC reachability raised by both D. Papadimitriou and Y. Rekhter in their > respective review. (''If people identify specific and isolated issues > that would like to see in different tickets please let me know'').''' > > '''From P. Papadimitriou's Review:''' > > Section 6.1.5 where is the “Data Probe packet†format defined actually ? > > Section 6.1.5 states “The RLOCs in the Map-Reply are the > globally-routable IP addresses of the ETR but are not necessarily > reachable; separate testing of reachability is required.†Section 6.3 > does not define any procedure actually and does not define any > criteria for deciding when the RLOC is reachable or not. The key > question is if the ITR persists in testing reachability and there is > no criteria process by which such decision would stop, the traffic > would be forwarded by means of the “separate/alternative topology†> forever. > > Section 6.3 proposes “encapsulated traffic†based procedures thus, if > there is no traffic there is no RLOC reachability “test†possible. On > the other hand, that section states certain “ICMP exchanges†are > documented but reachability of RLOC does not mean availability of the > associated EID. There no actual “EID-to-RLOC†testing procedure being > defined in the document? > > What is struggling here is that the “introductory†sections of the > document refer to “functional†separations but all the techniques > described in this document (and for RLOC reachability testing in > particular) result in a complex inter-twin between control messaging > as part of the forwarding plane and forwarding date as part of the > control plane of routers. The latter is typical from Data Probes > processing. If this is the design choice of LISP so let it be but 1) > please proof it offers any better functionality compared to “current†> design and 2) better cost/performance. It is far from obvious that the > complexity concentrated at TR taking into the proposed design offers > any real compelling argument. This may also defeat the argument stated > in the introduction that “network deployment†is facilitated by > network-based solutions. > > Section 6.3 Point 1 what is the use of the “Loc-Status-Bits†if there > is no return traffic (or more precisely no return traffic passing via > this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The > ETR may process this information but never use it. > > Section 6.3 states “Each ITR can thus observe the presence or lack of > a default route originated by the others to determine the Locator > Status Bits it sets for them.†This does not tell which technique to > use when no default route are used at all (under “non-normal†> circumstances … what should define normality in this context). > > Section 6.3.1 states “This mechanism does not completely solve the > forward path reachability problem as traffic may be unidirectional.†> The forwarding path may simply be asymmetric (there is nothing that > imposes reverse path reaching the source RLOC in case of dual attached > sites). This shortcoming defeats this mechanism as an ITR is not > “aware†of its neighboring ITR EID-to-RLOC mappings (connected to the > same site). This mechanism can only be safely used if the RLOC pair > between two sites is unique and remains unique. > > Section 6.3.2 RLOC Probing by means of the “control plane†this opens > the question of what is actually probed the “RLOC†or the EID-to-RLOC > entries of the ETR’s database. The difference stems because the latter > are static entries the liveness of the former are dependent on the > incoming interface liveness. That is entries can be available in the > database but if database entries are not in sync with the actual RLOC > status there is no possibility to detect reachability of RLOCs by > means of this mechanism. > > > ''' From Y. Rekhter's Review:''' > '''This is Comment 27''' > > Section 6.3 > Several mechanisms for determining RLOC reachability are currently > defined: > > 1. An ETR may examine the Loc-Status-Bits in the LISP header of an > encapsulated data packet received from an ITR. If the ETR is also acting > as an ITR and has traffic to return to the original ITR site, it can use > this status information to help select an > RLOC. > > 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message > for an RLOC it is using. This indicates that the RLOC is likely down. > > 3. An ITR which participates in the global routing system can > determine that an RLOC is down if no BGP RIB route exists that matches > the RLOC IP address. > > 4. An ITR may receive an ICMP Port Unreachable message from a > destination host. This occurs if an ITR attempts to use interworking > [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable > site. > > 5. An ITR may receive a Map-Reply from a ETR in response to a > previously sent Map-Request. The RLOC source of the Map-Reply is > likely up since the ETR was able to send the Map-Reply to the ITR. > > 6. When an ETR receives an encapsulated packet from an ITR, the source > RLOC from the outer header of the packet is likely up. > > 7. An ITR/ETR pair can use the Locator Reachability Algorithms > described in this section, namely Echo-Noncing or RLOC-Probing. > > For the first mechanism to work it is not sufficient for the ETR to > have traffic "to return to the original ITR site" - the ETR has to > have traffic to return to the original ITR. And if the ETR has no > traffic to return to the original ITR (even if the ETR has traffic to > return to some other ITR of the site), then the first mechanism is > useless. > > Moreover, the first mechanism is predicated on the assumption that the > Loc-Status-Bits contain up to date information about reachability > of all ETRs at the site. The document describes how the ITR obtains > this information only for the case of CE-based or intra-site based > ITRs. Thus it does not cover the case where the ITR is the > PE. Moreover, for the case of CE-based ITR the scheme does not work if > the site runs RIP as its IGP. Furthermore it assumes that just because > the correspondent ITR can reach the given RLOC, the ETR also > will. Since IP connectivity is not always transitive in this > way, the fact that the corresponding ITR can reach the given RLOC does > not mean that the ETR also can. > > The second mechanism depends on ICMP Unreachable. As such it may > result in sustained traffic blackholing due to ICMP Unreachable being > dropped along the path. Also, how would that mechanism handle DoS > attacks caused by spoofed ICMP Unreachables ? Finally, if ITR > is within a site, and behind a firewall, would the firewall pass ICMP > Unreachables in the first place ? > > The third mechanism is likely to be of very limited use, as an ETR > going down is unlikely to cause the route that covers the RLOC of that > ETR to be withdrawn (unless this is /32 route). > > The fourth mechanism is applicable only for LISP interworking between > a LISP and a non-LISP site. > > The fifth and the sixth mechanisms do provide the indication that the > ETR is up, but do not provide the information when the ETR is down. As > such they are not applicable for determining unreachability, as > unreachability requires the ability to determine that the ETR is down. > > That leaves us with the seventh mechanism. This mechanism offers two > options: Echo Nonce (section 6.3.1) and RLOC Probing (section > 6.3.2). The Echo Nonce mechanism is applicable only when there is a > bidirectional flow between a pair of RLOCs. The RLOC Probing mechanism > has scaling limitations - quoting from 6.3.2: > > The major disadvantage of RLOC Probing is in the number of control > messages required and the amount of bandwidth used to obtain those > benefits, especially if the requirement for failure detection times > are very small. > > Given the above, what are the mechanisms that are available when xTRs > are PEs (as described in 8.3), and what are their scaling > characteristics ? > > Consider an example of site A with two xTRs A1 and A2, and site B with > two xTRs, B1 and B2. Now imagine that outbound traffic from A to B is > using the ITR component of A1, and talking to the ETR component B1 of > B. But the traffic from B back to A uses the ITR component of B2 and > is sending to the ETR component of A2. So each ITR->ETR flow is > unidirectional, even though all four devices are > fully capable of bidirectional communication. What are the options for > the RLOC reachability in this scenario ? > > The ITR can test the reachability of the unreachable Locator by > sending periodic Requests. Both Requests and Replies MUST be rate- > limited. Locator reachability testing is never done with data packets > since that increases the risk of packet loss for end-to-end sessions. > > How would one use data packets for testing locator reachability ? New description: '''This ticket groups together several inter-related issues concerning RLOC reachability raised by both D. Papadimitriou and Y. Rekhter in their respective review. (''If people identify specific and isolated issues that would like to see in different tickets please let me know'').''' '''From P. Papadimitriou's Review:''' Section 6.1.5 where is the “Data Probe packet†format defined actually ? Section 6.1.5 states “The RLOCs in the Map-Reply are the globally-routable IP addresses of the ETR but are not necessarily reachable; separate testing of reachability is required.†Section 6.3 does not define any procedure actually and does not define any criteria for deciding when the RLOC is reachable or not. The key question is if the ITR persists in testing reachability and there is no criteria process by which such decision would stop, the traffic would be forwarded by means of the “separate/alternative topology†forever. Section 6.3 proposes “encapsulated traffic†based procedures thus, if there is no traffic there is no RLOC reachability “test†possible. On the other hand, that section states certain “ICMP exchanges†are documented but reachability of RLOC does not mean availability of the associated EID. There no actual “EID-to-RLOC†testing procedure being defined in the document? What is struggling here is that the “introductory†sections of the document refer to “functional†separations but all the techniques described in this document (and for RLOC reachability testing in particular) result in a complex inter-twin between control messaging as part of the forwarding plane and forwarding date as part of the control plane of routers. The latter is typical from Data Probes processing. If this is the design choice of LISP so let it be but 1) please proof it offers any better functionality compared to “current†design and 2) better cost/performance. It is far from obvious that the complexity concentrated at TR taking into the proposed design offers any real compelling argument. This may also defeat the argument stated in the introduction that “network deployment†is facilitated by network-based solutions. Section 6.3 Point 1 what is the use of the “Loc-Status-Bits†if there is no return traffic (or more precisely no return traffic passing via this ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The ETR may process this information but never use it. Section 6.3 states “Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them.†This does not tell which technique to use when no default route are used at all (under “non-normal†circumstances … what should define normality in this context). Section 6.3.1 states “This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional.†The forwarding path may simply be asymmetric (there is nothing that imposes reverse path reaching the source RLOC in case of dual attached sites). This shortcoming defeats this mechanism as an ITR is not “aware†of its neighboring ITR EID-to-RLOC mappings (connected to the same site). This mechanism can only be safely used if the RLOC pair between two sites is unique and remains unique. Section 6.3.2 RLOC Probing by means of the “control plane†this opens the question of what is actually probed the “RLOC†or the EID-to-RLOC entries of the ETR’s database. The difference stems because the latter are static entries the liveness of the former are dependent on the incoming interface liveness. That is entries can be available in the database but if database entries are not in sync with the actual RLOC status there is no possibility to detect reachability of RLOCs by means of this mechanism. ''' From Y. Rekhter's Review:''' '''This is Comment 27''' Section 6.3 Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. For the first mechanism to work it is not sufficient for the ETR to have traffic "to return to the original ITR site" - the ETR has to have traffic to return to the original ITR. And if the ETR has no traffic to return to the original ITR (even if the ETR has traffic to return to some other ITR of the site), then the first mechanism is useless. Moreover, the first mechanism is predicated on the assumption that the Loc-Status-Bits contain up to date information about reachability of all ETRs at the site. The document describes how the ITR obtains this information only for the case of CE-based or intra-site based ITRs. Thus it does not cover the case where the ITR is the PE. Moreover, for the case of CE-based ITR the scheme does not work if the site runs RIP as its IGP. Furthermore it assumes that just because the correspondent ITR can reach the given RLOC, the ETR also will. Since IP connectivity is not always transitive in this way, the fact that the corresponding ITR can reach the given RLOC does not mean that the ETR also can. The second mechanism depends on ICMP Unreachable. As such it may result in sustained traffic blackholing due to ICMP Unreachable being dropped along the path. Also, how would that mechanism handle DoS attacks caused by spoofed ICMP Unreachables ? Finally, if ITR is within a site, and behind a firewall, would the firewall pass ICMP Unreachables in the first place ? The third mechanism is likely to be of very limited use, as an ETR going down is unlikely to cause the route that covers the RLOC of that ETR to be withdrawn (unless this is /32 route). The fourth mechanism is applicable only for LISP interworking between a LISP and a non-LISP site. The fifth and the sixth mechanisms do provide the indication that the ETR is up, but do not provide the information when the ETR is down. As such they are not applicable for determining unreachability, as unreachability requires the ability to determine that the ETR is down. That leaves us with the seventh mechanism. This mechanism offers two options: Echo Nonce (section 6.3.1) and RLOC Probing (section 6.3.2). The Echo Nonce mechanism is applicable only when there is a bidirectional flow between a pair of RLOCs. The RLOC Probing mechanism has scaling limitations - quoting from 6.3.2: The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times are very small. Given the above, what are the mechanisms that are available when xTRs are PEs (as described in 8.3), and what are their scaling characteristics ? Consider an example of site A with two xTRs A1 and A2, and site B with two xTRs, B1 and B2. Now imagine that outbound traffic from A to B is using the ITR component of A1, and talking to the ETR component B1 of B. But the traffic from B back to A uses the ITR component of B2 and is sending to the ETR component of A2. So each ITR->ETR flow is unidirectional, even though all four devices are fully capable of bidirectional communication. What are the options for the RLOC reachability in this scenario ? '''This is Comment 28''' Section 6.3 The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. How would one use data packets for testing locator reachability ? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:14:06 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE733A69B8 for ; Thu, 22 Apr 2010 05:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eegOHys0VCFE for ; Thu, 22 Apr 2010 05:14:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E030E3A68A5 for ; Thu, 22 Apr 2010 05:13:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vHx-0001LQ-Fc; Thu, 22 Apr 2010 05:13:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:13:49 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/67#comment:1 Message-ID: <077.49d4bbebf9ed94492f766475b4bb1a61@tools.ietf.org> References: <068.8083d532ca92cd4b01bf3baf5f1d037a@tools.ietf.org> X-Trac-Ticket-ID: 67 In-Reply-To: <068.8083d532ca92cd4b01bf3baf5f1d037a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #67: What would it mean if N were clear and E were set? (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:14:06 -0000 #67: What would it mean if N were clear and E were set? (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 6.3.1 > > When there is bidirectional data flow between a pair of locators, a > simple mechanism called "nonce echoing" can be used to determine > reachability between an ITR and ETR. When an ITR wants to solicit a > nonce echo, it sets the N and E bits and places a 24-bit nonce in the > LISP header of the next encapsulated data packet. > > What would it mean if N were clear and E were set? New description: '''This is Comment 29''' Section 6.3.1 When there is bidirectional data flow between a pair of locators, a simple mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N and E bits and places a 24-bit nonce in the LISP header of the next encapsulated data packet. What would it mean if N were clear and E were set? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:15:58 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94D33A692E for ; Thu, 22 Apr 2010 05:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdMPZaPaLXzB for ; Thu, 22 Apr 2010 05:15:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 09A3C3A68A5 for ; Thu, 22 Apr 2010 05:15:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vJs-0006lW-5x; Thu, 22 Apr 2010 05:15:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:15:48 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/32#comment:4 Message-ID: <077.35233d5e15e4b2f13710e5ecbb283aaf@tools.ietf.org> References: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:15:59 -0000 #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Comment(by luigi@…): Replying to [comment:2 luigi@…]: ''' This is Comment 30 of Rekhter's review''' > > Section 6.3.2 > > cached by the ITR or PTR. The ITR or PTR may include a mapping data > record for its own database mapping information. > > What exactly is "its own database mapping information" ? > -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:17:18 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F433A69A2 for ; Thu, 22 Apr 2010 05:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szjQnfR-o8Xn for ; Thu, 22 Apr 2010 05:17:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A2B663A690C for ; Thu, 22 Apr 2010 05:17:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vL9-0001h6-VG; Thu, 22 Apr 2010 05:17:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:17:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/32#comment:5 Message-ID: <077.5c1510f69f8fda75e57edf24f2acc5cc@tools.ietf.org> References: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:17:18 -0000 #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Comment(by luigi@…): Replying to [comment:2 luigi@…]: '''This is Comment 31 of Rekhter's review''' > Section 6.4 > > Note that when a packet is LISP encapsulated, the source port number > in the outer UDP header needs to be set. Selecting a random value > allows core routers which are attached to Link Aggregation Groups > (LAGs) to load-split the encapsulated packets across member links of > such LAGs. Otherwise, core routers would see a single flow, since > packets have a source address of the ITR, for packets which are > originated by different EIDs at the source site. A suggested setting > for the source port number computed by an ITR is a 5-tuple hash > function on the inner header, as described above. > > "Random" in the second sentence is contradicted by the last sentence. > > Also, it is not clear why the paragraph restricts itself to talking > about LAGs. Load balancing is used plenty of other places. > -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:18:51 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A603A6907 for ; Thu, 22 Apr 2010 05:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egjklANW5v-Y for ; Thu, 22 Apr 2010 05:18:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D64103A68DC for ; Thu, 22 Apr 2010 05:18:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vMe-0004sQ-Ce; Thu, 22 Apr 2010 05:18:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:18:40 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/32#comment:6 Message-ID: <077.7dcd27b1638ed959574cc3c884a155d7@tools.ietf.org> References: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <068.c01a60e906e8781d614001acda898837@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:18:51 -0000 #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Comment(by luigi@…): Replying to [comment:2 luigi@…]: '''This is part of Comment 32 of Rekhter's review''' > Section 6.5 > > As a general comment, this section is in need of some editing to make > the prose more readable. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:21:27 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395823A69EC for ; Thu, 22 Apr 2010 05:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9Op22hggCLJ for ; Thu, 22 Apr 2010 05:21:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A77D03A6A86 for ; Thu, 22 Apr 2010 05:21:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vOp-000142-8V; Thu, 22 Apr 2010 05:20:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:20:54 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:2 Message-ID: <077.8639db9526fc22405c33d05840a8252b@tools.ietf.org> References: <068.3a3b43d90cb0ced8925103b20f872430@tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <068.3a3b43d90cb0ced8925103b20f872430@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #66: Strict RLOC ordering causing problems on mapping changes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:21:27 -0000 #66: Strict RLOC ordering causing problems on mapping changes ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > '''This ticket groups together co-related issues concerning RLOC ordering > raised by D. Papadimitriou and Y. Rekhter in their respective reviews.''' > > '''From D. Papadimitriou's review:''' > > Section 6.5 the section does not actually explain which messages are > used to update the list of Loc-Reach or Loc-Status bits. If it is data > traffic-driven then the mechanism is again dependent on the symmetry > of the reverse path and the packet rate but also packet differential > delays between packets. In the latter case, it is not clear how ITR > could retrieve the correct RLOCs to be used if a sequence of 8 packets > sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC > (indicated as available at arrival of the 8th packet) is received as > 1,0,0,0,0,0,0,0. The section makes a long digression on ordering > locator set this is not the issue without a sequence number it will > never be possible for the receiving ITR to determine the actual state > of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep > track of who requested mappings upon communication they should tell > the state of their mapping but also their transition. > > '''From Y. Rekhter's review:''' > > Section 6.5 > > When a locator record is added to the end of a locator-set, it is > easy to update mappings. We assume new mappings will maintain the > same locator ordering as the old mapping but just have new locators > appended to the end of the list. So some ITRs can have a new mapping > while other ITRs have only an old mapping that is used until they > time out. > > This identifies a real problem; i.e., the locator status bits are > contextually dependent on the locator set that was advertised, but > there is no explicit binding between them and the particular locator > set to which they relate. Thus, any version skew between ITR and ETR > will result in misinterpretation of the locator status bits. > > This seems like it could be a serious problem (though section 6.3 is > so underspecified and hard to follow that this is difficult to pin > down) and needs to be understood better. The fixes proposed in this > section seem complex and incomplete. > > When an ITR has only an old mapping but detects bits set in the > loc-status-bits that correspond to locators beyond the list it has > cached, it simply ignores them. However, this can only happen for > locator addresses that are lexicographically greater than the locator > addresses in the existing locator-set. > > It is previously stated that locators in the locator-set must be > sorted; this would seem to indicate that you cannot add a locator to > the locator-set on demand, and that a process such as defined in 6.5.1 > must be used to try to ensure sync between ITR and ETR > > There would seem to be a need to either get rid of locator-sets, or > come up with a better system for synchronizing them. The consequences > of out-of-sync locator-sets should also be spelled out. New description: '''This ticket groups together co-related issues concerning RLOC ordering raised by D. Papadimitriou and Y. Rekhter in their respective reviews.''' '''From D. Papadimitriou's review:''' Section 6.5 the section does not actually explain which messages are used to update the list of Loc-Reach or Loc-Status bits. If it is data traffic-driven then the mechanism is again dependent on the symmetry of the reverse path and the packet rate but also packet differential delays between packets. In the latter case, it is not clear how ITR could retrieve the correct RLOCs to be used if a sequence of 8 packets sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC (indicated as available at arrival of the 8th packet) is received as 1,0,0,0,0,0,0,0. The section makes a long digression on ordering locator set this is not the issue without a sequence number it will never be possible for the receiving ITR to determine the actual state of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep track of who requested mappings upon communication they should tell the state of their mapping but also their transition. '''From Y. Rekhter's review:''' '''This is part of Comment 32''' Section 6.5 When a locator record is added to the end of a locator-set, it is easy to update mappings. We assume new mappings will maintain the same locator ordering as the old mapping but just have new locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. This identifies a real problem; i.e., the locator status bits are contextually dependent on the locator set that was advertised, but there is no explicit binding between them and the particular locator set to which they relate. Thus, any version skew between ITR and ETR will result in misinterpretation of the locator status bits. This seems like it could be a serious problem (though section 6.3 is so underspecified and hard to follow that this is difficult to pin down) and needs to be understood better. The fixes proposed in this section seem complex and incomplete. When an ITR has only an old mapping but detects bits set in the loc-status-bits that correspond to locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing locator-set. It is previously stated that locators in the locator-set must be sorted; this would seem to indicate that you cannot add a locator to the locator-set on demand, and that a process such as defined in 6.5.1 must be used to try to ensure sync between ITR and ETR There would seem to be a need to either get rid of locator-sets, or come up with a better system for synchronizing them. The consequences of out-of-sync locator-sets should also be spelled out. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:24:28 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2153A692E for ; Thu, 22 Apr 2010 05:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+CQgUBU7RWV for ; Thu, 22 Apr 2010 05:24:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F18E63A691C for ; Thu, 22 Apr 2010 05:24:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vRx-00037a-Hb; Thu, 22 Apr 2010 05:24:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:24:09 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/65#comment:1 Message-ID: <077.5bfdbaa77ff37409ea05fdd360ce1bce@tools.ietf.org> References: <068.afb88086d11db1572bdade525c19eeeb@tools.ietf.org> X-Trac-Ticket-ID: 65 In-Reply-To: <068.afb88086d11db1572bdade525c19eeeb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #65: Missing step to restore 24h TTL in clock-sweep mechanism (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:24:29 -0000 #65: Missing step to restore 24h TTL in clock-sweep mechanism (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 6.5.1 > > The default setting for an EID-to-RLOC mapping TTL is 24 hours. > > This is the only place in the document where the default is specified! > > There is a missing step in the procedure, which is to restore the TTL > to 24 hours. > > In general, this procedure would seem to lead to increased operational > complexity, and thus contradict the claims of reduced opex. New description: '''This is Comment 33''' Section 6.5.1 The default setting for an EID-to-RLOC mapping TTL is 24 hours. This is the only place in the document where the default is specified! There is a missing step in the procedure, which is to restore the TTL to 24 hours. In general, this procedure would seem to lead to increased operational complexity, and thus contradict the claims of reduced opex. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:26:24 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD243A68E7 for ; Thu, 22 Apr 2010 05:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdZkhe3Cttey for ; Thu, 22 Apr 2010 05:26:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8EECC3A69EC for ; Thu, 22 Apr 2010 05:26:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vTk-0003t4-3x; Thu, 22 Apr 2010 05:26:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:26:00 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/42#comment:2 Message-ID: <077.4f059ba5e0ed00e9327bf8286e9e38d0@tools.ietf.org> References: <068.949be01828216d93bdf1e485048b2d40@tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <068.949be01828216d93bdf1e485048b2d40@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #42: On the SMR mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:26:25 -0000 #42: On the SMR mechanism ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > '''This ticket groups together co-related issues concerning the SMR > mechanism raised by D. Papadimitriou and Y. Rekhter in their respective > reviews .''' > > '''From D. Papadimitriou's review:''' > > Section 6.5.2 is this technique mandatory or not (this is not > specified in the text). Point 5 results in obvious situations where > the ETR may never stop sending SMR messages. As there is no means a > way to prevent that ITR use “old mappings†this result in a deadlock > situation (a non-cooperating ITR prevents ETR to stop sending SMR > messages). > > Section 6.5.2 states “So an xTR will solicit Map-Requests from sites > it is currently sending encapsulated data to, and only from those > sites.†Thus instead of keeping track of ITR, ETR keep track of the > encapsulated traffic ITR send. The mechanism is often cited but never > explained e.g. over which time period is the ETR expected to determine > the set of communicating ITR’s ? > > Section 6.5.2 states “Map request†shall be rate limited … rather > unclear: assume a single ETR sends one SMR message to 10 different > ITRs how the 10 ITR will individually rate limit a single Map Request > in response to this SMR message. It is thus worth specifying the flow > control of SMR and Map-Request messages in a more systematic way to > prevent ETR overloads. > > '''From Y. Rekhter's review:''' > > Section 6.5.2 Solicited-Map-Request > > Since the xTRs don't keep track of remote ITRs that have cached their > mappings, they can not tell exactly who needs the new mapping > entries. So an xTR will solicit Map-Requests from sites it is > currently sending encapsulated data to, and only from those sites. > > "currently" needs to be quantified. E.g., if the local xTR detected > change in the mapping at time T1, and sends the encapsulated data to a > particlar remote xTR at time T2, what is the max allowable (T2-T1) ? > Is it 1 sec, 1 min, 1 hour, 1 day ? > > What is the meaning of "solicit Map-Requests from sites" ? Does it > mean soliciting it from all the xTRs of a given site ? If yes, then > how would it determine all such xTRs ? And if no, and it means just > one xTR of a given site, then how would Solicited-Map-Request work in > the scenario where an xTR-A sends encapsulated data to xTR-B of a > given (remote) site, but that site uses some other xTR, xTR-C, to send > the data to xTR-A, and it is xTR-C that needs the new mapping ? > > The remote xTR retransmits the Map-Request slowly until it gets a > > "slowly" needs to be quantified. > > The ETRs at the site with the changed mapping will reply to the > Map-Request with a Map-Reply message provided the Map-Request nonce > matches the nonce from the SMR. The Map-Reply messages SHOULD be rate > limited. This is important to avoid Map-Reply implosion. > > Is the implication that during this procedure, normal new Map-Requests > will not be replied to in the usual way, since they won't have the > nonce? > > with an EID destination to the mapping database system. Since the > mapping database system is more secure to reach an authoritative ETR, > > What is the justification for this assumption about the mapping > database's security? New description: '''This ticket groups together co-related issues concerning the SMR mechanism raised by D. Papadimitriou and Y. Rekhter in their respective reviews .''' '''From D. Papadimitriou's review:''' Section 6.5.2 is this technique mandatory or not (this is not specified in the text). Point 5 results in obvious situations where the ETR may never stop sending SMR messages. As there is no means a way to prevent that ITR use “old mappings†this result in a deadlock situation (a non-cooperating ITR prevents ETR to stop sending SMR messages). Section 6.5.2 states “So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites.†Thus instead of keeping track of ITR, ETR keep track of the encapsulated traffic ITR send. The mechanism is often cited but never explained e.g. over which time period is the ETR expected to determine the set of communicating ITR’s ? Section 6.5.2 states “Map request†shall be rate limited … rather unclear: assume a single ETR sends one SMR message to 10 different ITRs how the 10 ITR will individually rate limit a single Map Request in response to this SMR message. It is thus worth specifying the flow control of SMR and Map-Request messages in a more systematic way to prevent ETR overloads. '''From Y. Rekhter's review:''' '''This is Comment 34''' Section 6.5.2 Solicited-Map-Request Since the xTRs don't keep track of remote ITRs that have cached their mappings, they can not tell exactly who needs the new mapping entries. So an xTR will solicit Map-Requests from sites it is currently sending encapsulated data to, and only from those sites. "currently" needs to be quantified. E.g., if the local xTR detected change in the mapping at time T1, and sends the encapsulated data to a particlar remote xTR at time T2, what is the max allowable (T2-T1) ? Is it 1 sec, 1 min, 1 hour, 1 day ? What is the meaning of "solicit Map-Requests from sites" ? Does it mean soliciting it from all the xTRs of a given site ? If yes, then how would it determine all such xTRs ? And if no, and it means just one xTR of a given site, then how would Solicited-Map-Request work in the scenario where an xTR-A sends encapsulated data to xTR-B of a given (remote) site, but that site uses some other xTR, xTR-C, to send the data to xTR-A, and it is xTR-C that needs the new mapping ? The remote xTR retransmits the Map-Request slowly until it gets a "slowly" needs to be quantified. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message provided the Map-Request nonce matches the nonce from the SMR. The Map-Reply messages SHOULD be rate limited. This is important to avoid Map-Reply implosion. Is the implication that during this procedure, normal new Map-Requests will not be replied to in the usual way, since they won't have the nonce? with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, What is the justification for this assumption about the mapping database's security? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:27:38 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1930A3A691C for ; Thu, 22 Apr 2010 05:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCCXZJHixUF5 for ; Thu, 22 Apr 2010 05:27:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D67823A6807 for ; Thu, 22 Apr 2010 05:27:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vV9-00007I-ER; Thu, 22 Apr 2010 05:27:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:27:27 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/33#comment:2 Message-ID: <077.466dbef36fe313c933cddff38d108c66@tools.ietf.org> References: <068.55f561e469bb5634357c136824b60322@tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <068.55f561e469bb5634357c136824b60322@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:27:38 -0000 #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > '''This ticket groups together editorial issues raised by D. > Papadimitriou and Y. Rekhter in their respective reviews.''' > > '''From D. Papadimitriou's review:''' > > Section 7: the first paragraph is a wish not a fact. As such it is > doubtful what such paragraph actually brings in the context of a > protocol architecture/specification. > > '''From Y. Rekhter's review:''' > > Section 7 Router Performance Considerations: > > LISP is designed to be very hardware-based forwarding friendly. By > doing tunnel header prepending [RFC1955] and stripping instead of re- > writing addresses, existing hardware can support the forwarding model > with little or no modification. Where modifications are required, > they should be limited to re-programming existing hardware rather > than requiring expensive design changes to hard-coded algorithms in > silicon. > > This is simply an Assertion. > > When a tunnel encapsulated packet is received by an ETR, the outer > destination address may not be the address of the router. This makes > it challenging for the control plane to get packets from the > hardware. This may be mitigated by creating special FIB entries for > the EID-prefixes of EIDs served by the ETR (those for which the > router provides an RLOC translation). These FIB entries are marked > with a flag indicating that control plane processing should be > performed. The forwarding logic of testing for particular IP protocol > number value is not necessary. No changes to existing, deployed > hardware should be needed to support this. > > The above explanation of why no changes to existing deployed hardware > should be needed is fairly confusing. > > On an ITR, prepending a new IP header is as simple as adding more > bytes to a MAC rewrite string and prepending the string as part of > the outgoing encapsulation procedure. Many routers that support GRE > tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already support > this action. > > This looks like another Assertion. > > When a received packet's outer destination address contains an EID > which is not intended to be forwarded on the routable topology > (i.e. LISP 1.5), the source address of a data packet or the router > interface with which the source is associated (the interface from > which it was received) can be associated with a VRF (Virtual > Routing/Forwarding), in which a different (i.e. non-congruent) > topology can be used to find EID-to-RLOC mappings. > > What does the part about "When a received packet's ... to be forwarded > on the routable topology" have to do with the part about "the source > address of a data packet ... can be associated with a VRF" ? New description: '''This ticket groups together editorial issues raised by D. Papadimitriou and Y. Rekhter in their respective reviews.''' '''From D. Papadimitriou's review:''' Section 7: the first paragraph is a wish not a fact. As such it is doubtful what such paragraph actually brings in the context of a protocol architecture/specification. '''From Y. Rekhter's review:''' ''' This is part of Comment 35''' Section 7 Router Performance Considerations: LISP is designed to be very hardware-based forwarding friendly. By doing tunnel header prepending [RFC1955] and stripping instead of re- writing addresses, existing hardware can support the forwarding model with little or no modification. Where modifications are required, they should be limited to re-programming existing hardware rather than requiring expensive design changes to hard-coded algorithms in silicon. This is simply an Assertion. When a tunnel encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special FIB entries for the EID-prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing should be performed. The forwarding logic of testing for particular IP protocol number value is not necessary. No changes to existing, deployed hardware should be needed to support this. The above explanation of why no changes to existing deployed hardware should be needed is fairly confusing. On an ITR, prepending a new IP header is as simple as adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Many routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already support this action. This looks like another Assertion. When a received packet's outer destination address contains an EID which is not intended to be forwarded on the routable topology (i.e. LISP 1.5), the source address of a data packet or the router interface with which the source is associated (the interface from which it was received) can be associated with a VRF (Virtual Routing/Forwarding), in which a different (i.e. non-congruent) topology can be used to find EID-to-RLOC mappings. What does the part about "When a received packet's ... to be forwarded on the routable topology" have to do with the part about "the source address of a data packet ... can be associated with a VRF" ? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:28:58 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E913A68DD for ; Thu, 22 Apr 2010 05:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2qmI8YzC3Q9 for ; Thu, 22 Apr 2010 05:28:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AA48D3A68B5 for ; Thu, 22 Apr 2010 05:28:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vWS-0004Vi-8d; Thu, 22 Apr 2010 05:28:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:28:48 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/57#comment:1 Message-ID: <077.40405e587a387d1ea2d126bbd5240094@tools.ietf.org> References: <068.ce085df57fc97c68212636551555c56c@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <068.ce085df57fc97c68212636551555c56c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:28:58 -0000 #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > From section 7: > > How does one determine whether the outer destination address "contains > an EID which is not intended to be forwarded on the routable topology" > ? Please answer this question both for IPv6 and for IPv4. New description: ''' This is part of Comment 35''' From section 7: How does one determine whether the outer destination address "contains an EID which is not intended to be forwarded on the routable topology" ? Please answer this question both for IPv6 and for IPv4. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:31:34 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7CC93A6829 for ; Thu, 22 Apr 2010 05:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e8UZ9ZPh8cS for ; Thu, 22 Apr 2010 05:31:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ACAC93A63EC for ; Thu, 22 Apr 2010 05:31:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vYy-0005pK-9M; Thu, 22 Apr 2010 05:31:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:31:24 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/64#comment:1 Message-ID: <077.3a26777bda5769476a57136b4d4682fb@tools.ietf.org> References: <068.200921803b020f7b2e6fe117ab763621@tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <068.200921803b020f7b2e6fe117ab763621@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #64: Host based LISP implementations (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:31:34 -0000 #64: Host based LISP implementations (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 8 > > This section doesn't discuss host based LISP implementations, which > seems a possibility as it is discussed under mobility. What are the > implications be of host based LISP on the control plane load and does > two headers restriction create a problem for host based LISP? New description: '''This is part of Comment 36''' Section 8 This section doesn't discuss host based LISP implementations, which seems a possibility as it is discussed under mobility. What are the implications be of host based LISP on the control plane load and does two headers restriction create a problem for host based LISP? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:34:59 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDC63A6A4C for ; Thu, 22 Apr 2010 05:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKTD09i3Q9Ls for ; Thu, 22 Apr 2010 05:34:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0B3FE3A6A11 for ; Thu, 22 Apr 2010 05:34:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vc6-0005te-JQ; Thu, 22 Apr 2010 05:34:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:34:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/34#comment:3 Message-ID: <077.886edfa253675f410b613495cf2afb6e@tools.ietf.org> References: <068.8aebdfd098dad3558af27ffd1331ae4e@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <068.8aebdfd098dad3558af27ffd1331ae4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:34:59 -0000 #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > '''This ticket groups together editorial issues raised by D. > Papadimitriou and Y. Rekhter in their respective reviews.''' > > '''From D. Papadimitriou's review:''' > > Section 8.1 first paragraph, it is not the location of the source that > determines the “size†of the working set of the EID prefix-to-RLOC cache > but the number of EID prefixes this “source site†has to reach. The same > issue occurs at ETR, small sites may have to be configured with a large > list of EID-to-RLOC mapping entries. Next to this the granularity of the > EID prefix allocation is also important. > > '''From Y. Rekhter's review:''' > > By having the PE be the first router on the path to encapsulate, it > can choose a TE path first, and the ETR can decapsulate and > re-encapsulate for a tunnel to the destination end site. > > This is hard to understand. > > ISP is doing the TE, then the site has no control. Recursive tunneling > generally will result in suboptimal paths but at the benefit of > steering traffic to resource available parts of the network. > > What exactly does "suboptimal" mean here? New description: '''This ticket groups together editorial issues raised by D. Papadimitriou and Y. Rekhter in their respective reviews.''' '''From D. Papadimitriou's review:''' Section 8.1 first paragraph, it is not the location of the source that determines the “size†of the working set of the EID prefix-to-RLOC cache but the number of EID prefixes this “source site†has to reach. The same issue occurs at ETR, small sites may have to be configured with a large list of EID-to-RLOC mapping entries. Next to this the granularity of the EID prefix allocation is also important. '''From Y. Rekhter's review:''' '''This is part of Comment 36''' By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. This is hard to understand. ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. What exactly does "suboptimal" mean here? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:36:43 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF4728C0CE for ; Thu, 22 Apr 2010 05:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGdJ5fS6e3M5 for ; Thu, 22 Apr 2010 05:36:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C7C323A69FA for ; Thu, 22 Apr 2010 05:36:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vdj-0005xz-7i; Thu, 22 Apr 2010 05:36:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:36:19 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/63#comment:2 Message-ID: <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:36:43 -0000 #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 8.2 > > Note that more than one CE router at a site can be configured with > the same IP address. In this case an RLOC is an anycast address. This > allows resilience between the CE routers. That is, if a CE router > fails, traffic is automatically routed to the other routers using the > same anycast address. However, this comes with the disadvantage where > the site cannot control the entrance point when the anycast route is > advertised out from all border routers. > > The above means that at the minimum the price of resilience between > the CE routers is the inability to support traffic engineering? > Specifically, the ISP loses any influence over the choice of which ETR > should be used to reach the multi-homed enterprise. > > Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are > anycast addresses as well, and thus can not be topologically > significant. Thus if an enterprise is multi-homed to two (or more) > ISPs, then use of anycast addresses for CEs would require to route > such addresses as /32 throughout the whole Internet. > > Also, if anycast addresses are used as RLOCs, then how would one > deal with a situation where initially both ETR1 and ETR2 advertise > 10.1.1/24 and 10.1.2/24, ITR1 routes traffic for 10.1.1.1 to ETR1, but > then ETR1, while still being up, loses connectivity to 10.1.1/24? New description: '''This is Comment 38''' Section 8.2 Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. The above means that at the minimum the price of resilience between the CE routers is the inability to support traffic engineering? Specifically, the ISP loses any influence over the choice of which ETR should be used to reach the multi-homed enterprise. Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are anycast addresses as well, and thus can not be topologically significant. Thus if an enterprise is multi-homed to two (or more) ISPs, then use of anycast addresses for CEs would require to route such addresses as /32 throughout the whole Internet. Also, if anycast addresses are used as RLOCs, then how would one deal with a situation where initially both ETR1 and ETR2 advertise 10.1.1/24 and 10.1.2/24, ITR1 routes traffic for 10.1.1.1 to ETR1, but then ETR1, while still being up, loses connectivity to 10.1.1/24? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:38:29 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F2693A6A88 for ; Thu, 22 Apr 2010 05:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtX86RVdENaZ for ; Thu, 22 Apr 2010 05:38:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 140C43A6A39 for ; Thu, 22 Apr 2010 05:38:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vfV-0005zD-Fi; Thu, 22 Apr 2010 05:38:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:38:09 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/62#comment:2 Message-ID: <077.9eef44cf66fc56aa9a494bbe1eaaeffb@tools.ietf.org> References: <068.c19b6b03372bec851b0b2115d49938f0@tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <068.c19b6b03372bec851b0b2115d49938f0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #62: Control of the egress tunnel endpoints by the provider ISP (from Y. Rekhter Review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:38:29 -0000 #62: Control of the egress tunnel endpoints by the provider ISP (from Y. Rekhter Review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 8.3 > > Use of ISP PE routers as tunnel endpoint routers gives an ISP control > over the location of the egress tunnel endpoints. That is, the ISP can > decide if the tunnel endpoints are in the destination site (in either > CE routers or last-hop routers within a site) or at other PE edges. > > How is this done, as the CE router (probably) and last-hop within a > site (surely) is under control of the customer, not the ISP. > > The advantage of this case is that two or more tunnel headers can be > avoided. > > Only if the extra header in question would be imposed by the first-hop > ISP. Any other ISP would still need to impose their own header in > order to do TE. New description: '''This is part of Comment 39''' Section 8.3 Use of ISP PE routers as tunnel endpoint routers gives an ISP control over the location of the egress tunnel endpoints. That is, the ISP can decide if the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. How is this done, as the CE router (probably) and last-hop within a site (surely) is under control of the customer, not the ISP. The advantage of this case is that two or more tunnel headers can be avoided. Only if the extra header in question would be imposed by the first-hop ISP. Any other ISP would still need to impose their own header in order to do TE. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:40:06 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981B83A691C for ; Thu, 22 Apr 2010 05:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKI2ZaLlRFAr for ; Thu, 22 Apr 2010 05:40:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9B49A3A6A39 for ; Thu, 22 Apr 2010 05:40:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vhD-00060i-3p; Thu, 22 Apr 2010 05:39:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:39:55 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/34#comment:4 Message-ID: <077.206b22d59f896ec027756b3ae96fd14a@tools.ietf.org> References: <068.8aebdfd098dad3558af27ffd1331ae4e@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <068.8aebdfd098dad3558af27ffd1331ae4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:40:06 -0000 #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > '''This ticket groups together editorial issues raised by D. > Papadimitriou and Y. Rekhter in their respective reviews.''' > > '''From D. Papadimitriou's review:''' > > Section 8.1 first paragraph, it is not the location of the source that > determines the “size†of the working set of the EID prefix-to-RLOC cache > but the number of EID prefixes this “source site†has to reach. The same > issue occurs at ETR, small sites may have to be configured with a large > list of EID-to-RLOC mapping entries. Next to this the granularity of the > EID prefix allocation is also important. > > '''From Y. Rekhter's review:''' > '''This is part of Comment 36''' > > By having the PE be the first router on the path to encapsulate, it > can choose a TE path first, and the ETR can decapsulate and > re-encapsulate for a tunnel to the destination end site. > > This is hard to understand. > > ISP is doing the TE, then the site has no control. Recursive tunneling > generally will result in suboptimal paths but at the benefit of > steering traffic to resource available parts of the network. > > What exactly does "suboptimal" mean here? New description: '''This ticket groups together editorial issues raised by D. Papadimitriou and Y. Rekhter in their respective reviews.''' '''From D. Papadimitriou's review:''' Section 8.1 first paragraph, it is not the location of the source that determines the “size†of the working set of the EID prefix-to-RLOC cache but the number of EID prefixes this “source site†has to reach. The same issue occurs at ETR, small sites may have to be configured with a large list of EID-to-RLOC mapping entries. Next to this the granularity of the EID prefix allocation is also important. '''From Y. Rekhter's review:''' '''This is part of Comment 39''' By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. This is hard to understand. '''This is part of Comment 36''' ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. What exactly does "suboptimal" mean here? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:41:47 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB653A6A59 for ; Thu, 22 Apr 2010 05:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpHVRME4jVVP for ; Thu, 22 Apr 2010 05:41:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3CB063A6807 for ; Thu, 22 Apr 2010 05:41:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4viq-00067I-QZ; Thu, 22 Apr 2010 05:41:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:41:36 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/60#comment:1 Message-ID: <077.825b05cec03f9acae0f01c0ce001e680@tools.ietf.org> References: <068.014b509d360317eccabd46fa4543c185@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <068.014b509d360317eccabd46fa4543c185@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #60: Editorial Issues Section 9 of draft-ietf-lisp-06.txt (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:41:47 -0000 #60: Editorial Issues Section 9 of draft-ietf-lisp-06.txt (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 9 > > This section would benefit from being rewritten to increase clarity. > > Section 9.3 > > segment 2 will make the tunnel look like one hop. All the ITR has to > do to make this work is to not copy the inner TTL to the outer, > encapsulating header's TTL when a traceroute packet is encapsulated > using an RLOC from a different address family. This will cause no > > Earlier it was claimed that copying the TTL is important for > correctness reasons. Why is it not important in this case, but is > important in all other cases? New description: '''This is part of Comment 40''' Section 9 This section would benefit from being rewritten to increase clarity. '''This is Comment 41''' Section 9.3 segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no Earlier it was claimed that copying the TTL is important for correctness reasons. Why is it not important in this case, but is important in all other cases? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:43:02 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806123A69F7 for ; Thu, 22 Apr 2010 05:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYftHDdyjgLm for ; Thu, 22 Apr 2010 05:43:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 51F1928C0E4 for ; Thu, 22 Apr 2010 05:43:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vk3-000695-TF; Thu, 22 Apr 2010 05:42:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:42:51 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/61#comment:1 Message-ID: <077.3b25482eef3da58e051c7c931fc6ed00@tools.ietf.org> References: <068.a267fbeedcada1f2d4dbd5370a8d6278@tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <068.a267fbeedcada1f2d4dbd5370a8d6278@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #61: How to identify "traceroute packet" (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:43:02 -0000 #61: How to identify "traceroute packet" (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Plus, how is the router supposed to identify a "traceroute packet"? New description: '''This is part of Comment 40''' Section 9 Plus, how is the router supposed to identify a "traceroute packet"? -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:44:16 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8029A3A6A6C for ; Thu, 22 Apr 2010 05:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uOE9ICQ+bbG for ; Thu, 22 Apr 2010 05:44:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0DC253A69F7 for ; Thu, 22 Apr 2010 05:44:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vlF-0006Ac-KU; Thu, 22 Apr 2010 05:44:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:44:05 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/59#comment:1 Message-ID: <077.d5a9e45ec61184e0d2884c4315b9be96@tools.ietf.org> References: <068.8be36db734249d6330520777c0081326@tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <068.8be36db734249d6330520777c0081326@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #59: Editorial Issues Section 10 of draft-ietf-lisp-06.txt (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:44:16 -0000 #59: Editorial Issues Section 10 of draft-ietf-lisp-06.txt (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 10.3 > > visited network using its original EID, then LISP will need to perform a > route-returnability check on the new EID-RLOC mapping for that EID. > What is a "route-returnability check"? > > loss for the entire system. Heuristics can be added to LISP to reduce the > number of mapping changes required and to reduce the delay > This sounds like an assertion. New description: '''This is Comment 42''' Section 10.3 visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-RLOC mapping for that EID. What is a "route-returnability check"? loss for the entire system. Heuristics can be added to LISP to reduce the number of mapping changes required and to reduce the delay This sounds like an assertion. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:45:45 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32F728C0FA for ; Thu, 22 Apr 2010 05:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cy0AhUcisD21 for ; Thu, 22 Apr 2010 05:45:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D63C928C0F9 for ; Thu, 22 Apr 2010 05:45:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vmg-0006Fu-EW; Thu, 22 Apr 2010 05:45:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:45:34 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/58#comment:1 Message-ID: <077.a29e1e90a2bd93a06aa4ae7334525a5f@tools.ietf.org> References: <068.b86df5c81bd78f6f83a111888ad19f8f@tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <068.b86df5c81bd78f6f83a111888ad19f8f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #58: LISP breaking RPF and used as anonymization service (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:45:45 -0000 #58: LISP breaking RPF and used as anonymization service (from Y. Rekhter's review) ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Description changed by luigi@…: Old description: > Section 12 > > There are many comments above that relate to security. Grep for > "security" or "attack". Other possible issues that come to mind that > should be explored here are whether LISP breaks RPF, and whether the > ubiquitous tunneling infrastructure could be reused as a botnet > anonymization service. New description: '''This is Comment 43''' Section 12 There are many comments above that relate to security. Grep for "security" or "attack". Other possible issues that come to mind that should be explored here are whether LISP breaks RPF, and whether the ubiquitous tunneling infrastructure could be reused as a botnet anonymization service. -- -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Apr 22 05:47:00 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C7A28C0FD for ; Thu, 22 Apr 2010 05:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPEzFiowotJL for ; Thu, 22 Apr 2010 05:46:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D52133A6A48 for ; Thu, 22 Apr 2010 05:46:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vnq-0007n4-Dn; Thu, 22 Apr 2010 05:46:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Thu, 22 Apr 2010 12:46:46 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/15#comment:2 Message-ID: <069.60e42b8adce52066923af1fcc8b4eb58@tools.ietf.org> References: <060.b4b15d03f6ba3bc357ace2e39ad3d053@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <060.b4b15d03f6ba3bc357ace2e39ad3d053@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #15: chairs to review normative and informative references X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 22 Apr 2010 12:47:01 -0000 #15: chairs to review normative and informative references ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: editorial | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Comment(by luigi@…): Replying to [comment:1 luigi@…]: '''This is Comment 45''' > ''' From Y. Rekhter's review:''' > > 14.1. Normative References: > > Why is HIP a normative reference? -- Ticket URL: lisp LISP WG document issues From luigi@net.t-labs.tu-berlin.de Thu Apr 22 05:49:51 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719DE3A6A86 for ; Thu, 22 Apr 2010 05:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_05=-1.11, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw2DPy06LKTC for ; Thu, 22 Apr 2010 05:49:50 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id C5C1928C0FB for ; Thu, 22 Apr 2010 05:49:47 -0700 (PDT) Received: from dyn116.net.t-labs.tu-berlin.de (dyn116.net.t-labs.tu-berlin.de [130.149.220.116]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 80D3B70015A8; Thu, 22 Apr 2010 14:49:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-16--571882487 From: Luigi Iannone In-Reply-To: <4BD039A1.3070205@cisco.com> Date: Thu, 22 Apr 2010 14:49:37 +0200 Message-Id: <3181AC11-9910-4B77-97E1-E1E916D40F76@net.t-labs.tu-berlin.de> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> <069.adc37efefae932c2e50c1bd6d3429a05@tools.ietf.org> <3DC770AE-77A2-497D-AD41-64F323D0CC5F@net.t-labs.tu-berlin.de> <4BD039A1.3070205@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1078) Cc: lisp@ietf.org Subject: Re: [lisp] Issue tracker: bunch of updates ahead X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 12:49:51 -0000 --Apple-Mail-16--571882487 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Eliot On Apr 22, 2010, at 13:57 , Eliot Lear wrote: > Luigi, >=20 > Are these all new issues?=20 No > Are there overlapping comments?=20 > And can we get a summary of all the open issues once you are finished? >=20 I did not change any issue. What I did is just add the comment number as = provided in the original review of Yakov. Luigi > Thanks, >=20 > Eliot >=20 > On 4/22/10 1:53 PM, Luigi Iannone wrote: >>=20 >> Hi All, >>=20 >> Yakov asked to clearly add his comments number to the tickets that = his review has generated (this may facilitate the tracking from the = original review). >>=20 >> I will proceed to the update, which translates in a number of mails = from the issue tracker. >>=20 >> Unless you are really interested in the comment number you can safely = discard the forthcoming emails, since I will not change the content. >>=20 >> Luigi =20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 --Apple-Mail-16--571882487 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Eliot

On Apr 22, 2010, at 13:57 , Eliot Lear wrote:

Luigi,

Are these all new issues? 

No

Are there overlapping comments? 
And can we get a summary of all the open issues once you are finished?


I did not change any issue. What I did is just add the comment number as provided in the original review of Yakov.

Luigi


Thanks,

Eliot

On 4/22/10 1:53 PM, Luigi Iannone wrote: 
Hi All,

Yakov asked to clearly add his comments number to the tickets that his review has generated (this may facilitate the tracking from the original review).

I will proceed to the update, which translates in a number of mails from the issue tracker.

Unless you are really interested in the comment number you can safely discard the forthcoming emails, since I will not change the content.

Luigi  
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

--Apple-Mail-16--571882487-- From luigi@net.t-labs.tu-berlin.de Thu Apr 22 05:51:59 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE94A28C10D for ; Thu, 22 Apr 2010 05:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ2rULn53eC8 for ; Thu, 22 Apr 2010 05:51:59 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 2008028C10A for ; Thu, 22 Apr 2010 05:51:59 -0700 (PDT) Received: from dyn116.net.t-labs.tu-berlin.de (dyn116.net.t-labs.tu-berlin.de [130.149.220.116]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 0307F70015A8; Thu, 22 Apr 2010 14:51:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: <3DC770AE-77A2-497D-AD41-64F323D0CC5F@net.t-labs.tu-berlin.de> Date: Thu, 22 Apr 2010 14:51:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5157CDCB-4F38-4B15-B5C8-764560825DA6@net.t-labs.tu-berlin.de> References: <060.311181004828b22591bdfaabb255e082@tools.ietf.org> <069.adc37efefae932c2e50c1bd6d3429a05@tools.ietf.org> <3DC770AE-77A2-497D-AD41-64F323D0CC5F@net.t-labs.tu-berlin.de> To: Luigi Iannone X-Mailer: Apple Mail (2.1078) Cc: lisp@ietf.org Subject: Re: [lisp] Issue tracker: bunch of updates ahead X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 12:52:00 -0000 Hi All, (Sorry for the spam.) all updates are done, so please consider reading mail from the tracker = from now on. Luigi On Apr 22, 2010, at 13:53 , Luigi Iannone wrote: > Hi All, >=20 > Yakov asked to clearly add his comments number to the tickets that his = review has generated (this may facilitate the tracking from the original = review). >=20 > I will proceed to the update, which translates in a number of mails = from the issue tracker. >=20 > Unless you are really interested in the comment number you can safely = discard the forthcoming emails, since I will not change the content. >=20 > Luigi =20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From lear@cisco.com Thu Apr 22 06:06:42 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4F03A67EB for ; Thu, 22 Apr 2010 06:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.408 X-Spam-Level: X-Spam-Status: No, score=-4.408 tagged_above=-999 required=5 tests=[AWL=-1.809, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF028ZNYnMvW for ; Thu, 22 Apr 2010 06:06:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A3F213A69EE for ; Thu, 22 Apr 2010 06:06:26 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkICANLmz0uQ/uCWiWdsb2JhbACDFo0MjAEVAQEBCgsREQYco0SIZ5FrgSqCeG0E X-IronPort-AV: E=Sophos;i="4.52,256,1270425600"; d="scan'208";a="6010510" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 22 Apr 2010 12:29:48 +0000 Received: from ams3-vpn-dhcp6001.cisco.com (ams3-vpn-dhcp6001.cisco.com [10.61.87.112]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MD6FT3024211; Thu, 22 Apr 2010 13:06:15 GMT Message-ID: <4BD049B8.70408@cisco.com> Date: Thu, 22 Apr 2010 15:06:00 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100421 Lanikai/3.1b2pre MIME-Version: 1.0 To: trac@localhost.amsl.com References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> In-Reply-To: <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 13:06:42 -0000 On 4/22/10 2:36 PM, lisp issue tracker wrote: > The above means that at the minimum the price of resilience between > the CE routers is the inability to support traffic engineering? > Specifically, the ISP loses any influence over the choice of which ETR > should be used to reach the multi-homed enterprise. First of all, this is one of several means to provide resiliency, and so to say this is a minimum price is overstating it. It's one of the tools in the toolbox. SPs have great say over their traffic because they continue to control any and all BGP announcements they make, and they continue to control their own IGP, as well as whatever load splitting they wish to do based on a destination address (LISP or otherwise). > Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are > anycast addresses as well, and thus can not be topologically > significant. Thus if an enterprise is multi-homed to two (or more) > ISPs, then use of anycast addresses for CEs would require to route > such addresses as /32 throughout the whole Internet. Wow. No. Anycast has a scope based on who routes it. If it's routed within an ISP it has a scope within an ISP. If it is only routed within the enterprise it has an even narrower scope. It could be routed between two ISPs. Mix and match. > Also, if anycast addresses are used as RLOCs, then how would one > deal with a situation where initially both ETR1 and ETR2 advertise > 10.1.1/24 and 10.1.2/24, ITR1 routes traffic for 10.1.1.1 to ETR1, but > then ETR1, while still being up, loses connectivity to 10.1.1/24? We call this a black hole. That's not a LISP issue, by the way. The same issue has to be addressed with L3 routing. A smart box might notice that it has lost internal connectivity, and act accordingly. Eliot From yakov@juniper.net Thu Apr 22 12:46:22 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC4C3A6A9B for ; Thu, 22 Apr 2010 12:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0KdxSij1Rxp for ; Thu, 22 Apr 2010 12:46:21 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id C00223A6861 for ; Thu, 22 Apr 2010 12:37:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKS9CliWBLNy0/h2+ciyb3ltV3hougg/R9@postini.com; Thu, 22 Apr 2010 12:37:51 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 22 Apr 2010 12:35:50 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 12:35:50 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 12:35:50 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 12:35:49 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3MJZnD90060; Thu, 22 Apr 2010 12:35:49 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201004221935.o3MJZnD90060@magenta.juniper.net> To: Eliot Lear In-Reply-To: <4BD049B8.70408@cisco.com> References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> X-MH-In-Reply-To: Eliot Lear message dated "Thu, 22 Apr 2010 15:06:00 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <81403.1271964949.1@juniper.net> Date: Thu, 22 Apr 2010 12:35:49 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 22 Apr 2010 19:35:49.0907 (UTC) FILETIME=[034DBE30:01CAE253] Cc: lisp issue tracker , trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:46:22 -0000 Eliot, > On 4/22/10 2:36 PM, lisp issue tracker wrote: >> The above means that at the minimum the price of resilience between >> the CE routers is the inability to support traffic engineering? >> Specifically, the ISP loses any influence over the choice of which ETR >> should be used to reach the multi-homed enterprise. > > First of all, this is one of several means to provide resiliency, and so > to say this is a minimum price is overstating it. It's one of the tools > in the toolbox. > > SPs have great say over their traffic because they continue to control > any and all BGP announcements they make, and they continue to control > their own IGP, as well as whatever load splitting they wish to do based > on a destination address (LISP or otherwise). Sure, but these are the mechanisms provided by the current routing system, not by LISP. To reflect this in the spec please add the following to section 8.2: Use of anycast addresses for resiliency in LISP results in inability to use LISP for traffic engineering, and specifically in inability to use LISP to influence the choice of whith ETR should be used to reach a multi-homed enterprise. In other words, when anycast addresses are used as RLOCs, LISP by itself does not provide any traffic engineering capabilities. >> Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are >> anycast addresses as well, and thus can not be topologically >> significant. Thus if an enterprise is multi-homed to two (or more) >> ISPs, then use of anycast addresses for CEs would require to route >> such addresses as /32 throughout the whole Internet. > > Wow. No. Anycast has a scope based on who routes it. If it's routed > within an ISP it has a scope within an ISP. If it is only routed within > the enterprise it has an even narrower scope. It could be routed > between two ISPs. Mix and match. The observation specifically cites the case of an enterprise "multi-homed to two (or more) ISPs". With this in mind please consider the case of site A attached to ISPs X, Y, site B attached to ISPs Y and Z, and site C attached to ISPs X, Y, and Z. Both site A, site B, and site C use anycast addresses as their RLOCs. What are the procedures for allocating these anycast addresses ? What are the rules for advertisting routes to these anycast addresses ? >> Also, if anycast addresses are used as RLOCs, then how would one >> deal with a situation where initially both ETR1 and ETR2 advertise >> 10.1.1/24 and 10.1.2/24, ITR1 routes traffic for 10.1.1.1 to ETR1, but >> then ETR1, while still being up, loses connectivity to 10.1.1/24? > > We call this a black hole. That's not a LISP issue, by the way. The > same issue has to be addressed with L3 routing. A smart box might > notice that it has lost internal connectivity, and act accordingly. This is a LISP issue, as LISP proposes to use anycast addresses as RLOCs. Thus LISP specs have to document how xTRs should deal with that issue. "A smart box might notice that it has lost internal connectivity, and act accordingly" is *not* an adequate documentation. Yakov. From lear@cisco.com Thu Apr 22 12:58:14 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18AC3A6844 for ; Thu, 22 Apr 2010 12:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.294 X-Spam-Level: X-Spam-Status: No, score=-8.294 tagged_above=-999 required=5 tests=[AWL=2.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YC8AOcAnjwK for ; Thu, 22 Apr 2010 12:58:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 812983A6953 for ; Thu, 22 Apr 2010 12:56:57 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8BAO9G0EuQ/uCWiWdsb2JhbACDFpkTFQEBAQoLEREGHKZ1iGeRVIQibQSDUQ X-IronPort-AV: E=Sophos;i="4.52,258,1270425600"; d="scan'208,217";a="59896597" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2010 19:56:46 +0000 Received: from ams3-vpn-dhcp6001.cisco.com (ams3-vpn-dhcp6001.cisco.com [10.61.87.112]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MJujju001124; Thu, 22 Apr 2010 19:56:46 GMT Message-ID: <4BD0A9EF.3060808@cisco.com> Date: Thu, 22 Apr 2010 21:56:31 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100421 Lanikai/3.1b2pre MIME-Version: 1.0 To: Yakov Rekhter References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> In-Reply-To: <201004221935.o3MJZnD90060@magenta.juniper.net> Content-Type: multipart/alternative; boundary="------------020204040808010204090206" Cc: lisp issue tracker , trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:58:14 -0000 This is a multi-part message in MIME format. --------------020204040808010204090206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Yakov, On 4/22/10 9:35 PM, Yakov Rekhter wrote: > Eliot, > >> On 4/22/10 2:36 PM, lisp issue tracker wrote: >>> The above means that at the minimum the price of resilience between >>> the CE routers is the inability to support traffic engineering? >>> Specifically, the ISP loses any influence over the choice of which ETR >>> should be used to reach the multi-homed enterprise. >> First of all, this is one of several means to provide resiliency, and so >> to say this is a minimum price is overstating it. It's one of the tools >> in the toolbox. >> >> SPs have great say over their traffic because they continue to control >> any and all BGP announcements they make, and they continue to control >> their own IGP, as well as whatever load splitting they wish to do based >> on a destination address (LISP or otherwise). > > Sure, but these are the mechanisms provided by the current routing > system, not by LISP. > > To reflect this in the spec please add the following to section 8.2: > > Use of anycast addresses for resiliency in LISP results in > inability to use LISP for traffic engineering, and specifically > in inability to use LISP to influence the choice of whith ETR > should be used to reach a multi-homed enterprise. In other > words, when anycast addresses are used as RLOCs, LISP by itself > does not provide any traffic engineering capabilities. I guess I think the text adequately addresses the issue, and see below. >>> Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are >>> anycast addresses as well, and thus can not be topologically >>> significant. Thus if an enterprise is multi-homed to two (or more) >>> ISPs, then use of anycast addresses for CEs would require to route >>> such addresses as /32 throughout the whole Internet. >> Wow. No. Anycast has a scope based on who routes it. If it's routed >> within an ISP it has a scope within an ISP. If it is only routed within >> the enterprise it has an even narrower scope. It could be routed >> between two ISPs. Mix and match. > > The observation specifically cites the case of an enterprise > "multi-homed to two (or more) ISPs". With this in mind please > consider the case of site A attached to ISPs X, Y, site B attached > to ISPs Y and Z, and site C attached to ISPs X, Y, and Z. Both > site A, site B, and site C use anycast addresses as their RLOCs. > What are the procedures for allocating these anycast addresses ? First, why is this limited to LISP? Wouldn't this be an issue for any anycast service? Second, there is an implicit assumption in what you write that this would be a globally scoped anycast- that is, people would be announcing anycast willy nilly. I think that unlikely since it would in effect replace one routing entry of an end system for another. On the other hand, a more localized use of anycast seems to carry very limited impact on the routing system. > What are the rules for advertisting routes to these anycast addresses ? Again, why is this a LISP issue? What are the rules for announcing any anycast route? > This is a LISP issue, as LISP proposes to use anycast addresses > as RLOCs. Thus LISP specs have to document how xTRs should deal > with that issue. "A smart box might notice that it has lost > internal connectivity, and act accordingly" is *not* an adequate > documentation. Yakov- how do you handle a case where you have a router originating a BGP announcement for a network that it is no longer connected to? Why would this situation be any different? --------------020204040808010204090206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Yakov,

On 4/22/10 9:35 PM, Yakov Rekhter wrote: 
Eliot,


On 4/22/10 2:36 PM, lisp issue tracker wrote:

 The above means that at the minimum the price of resilience between
 the CE routers is the inability to support traffic engineering?
 Specifically, the ISP loses any influence over the choice of which ETR
 should be used to reach the multi-homed enterprise.

First of all, this is one of several means to provide resiliency, and so 
to say this is a minimum price is overstating it.  It's one of the tools 
in the toolbox.

SPs have great say over their traffic because they continue to control 
any and all BGP announcements they make, and they continue to control 
their own IGP, as well as whatever load splitting they wish to do based 
on a destination address (LISP or otherwise).

 
Sure, but these are the mechanisms provided by the current routing
system, not by LISP.

To reflect this in the spec please add the following to section 8.2:
 
   Use of anycast addresses for resiliency in LISP results in
   inability to use LISP for traffic engineering, and specifically
   in inability to use LISP to influence the choice of whith ETR
   should be used to reach a multi-homed enterprise. In other
   words, when anycast addresses are used as RLOCs, LISP by itself
   does not provide any traffic engineering capabilities.

I guess I think the text adequately addresses the issue, and see below.


      

        

          
 Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are
 anycast addresses as well, and thus can not be topologically
 significant. Thus if an enterprise is multi-homed to two (or more)
 ISPs, then use of anycast addresses for CEs would require to route
 such addresses as /32 throughout the whole Internet.


        

        
Wow.  No.  Anycast has a scope based on who routes it.  If it's routed 
within an ISP it has a scope within an ISP.  If it is only routed within 
the enterprise it has an even narrower scope.  It could be routed 
between two ISPs.  Mix and match.


      

      
 
The observation specifically cites the case of an enterprise
"multi-homed to two (or more) ISPs". With this in mind please
consider the case of site A attached to ISPs X, Y, site B attached
to ISPs Y and Z, and site C attached to ISPs X, Y, and Z.  Both
site A, site B, and site C use anycast addresses as their RLOCs.
What are the procedures for allocating these anycast addresses ?


    

    

    First, why is this limited to LISP?  Wouldn't this be an issue for
    any anycast service?  Second, there is an implicit assumption in
    what you write that this would be a globally scoped anycast- that
    is, people would be announcing anycast willy nilly.  I think that
    unlikely since it would in effect replace one routing entry of an
    end system for another.

    

    On the other hand, a more localized use of anycast seems to carry
    very limited impact on the routing system.

    

    

    

      
What are the rules for advertisting routes to these anycast addresses ?


    

    

    Again, why is this a LISP issue?  What are the rules for announcing
    any anycast route?

    

    

      
This is a LISP issue, as LISP proposes to use anycast addresses
as RLOCs. Thus LISP specs have to document how xTRs should deal
with that issue. "A smart box might notice that it has lost
internal connectivity, and act accordingly" is *not* an adequate
documentation.


    

    

    Yakov- how do you handle a case where you have a router originating
    a BGP announcement for a network that it is no longer connected to? 
    Why would this situation be any different?

  


--------------020204040808010204090206--

From yakov@juniper.net  Thu Apr 22 13:03:13 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1883C3A68C7 for ; Thu, 22 Apr 2010 13:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.748
X-Spam-Level: 
X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=0.851,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eoIHM0uhdbU for ; Thu, 22 Apr 2010 13:03:11 -0700 (PDT)
Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 874C43A6858 for ; Thu, 22 Apr 2010 13:03:11 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKS9CrcxdjQEHwgzBidYfWMz5YQfSvDwFq@postini.com; Thu, 22 Apr 2010 13:03:02 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 22 Apr 2010 13:01:17 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 13:01:17 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 13:01:17 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 13:01:17 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3MK1FD01947; Thu, 22 Apr 2010 13:01:15 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <201004222001.o3MK1FD01947@magenta.juniper.net>
To: Noel Chiappa 
In-Reply-To: <20100422032823.ECEA06BE5FC@mercury.lcs.mit.edu> 
References: <20100422032823.ECEA06BE5FC@mercury.lcs.mit.edu>
X-MH-In-Reply-To: jnc@mercury.lcs.mit.edu (Noel Chiappa) message dated "Wed, 21 Apr 2010 23:28:23 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <82775.1271966475.1@juniper.net>
Date: Thu, 22 Apr 2010 13:01:15 -0700
From: Yakov Rekhter 
X-OriginalArrivalTime: 22 Apr 2010 20:01:17.0012 (UTC) FILETIME=[91877940:01CAE256]
Cc: lisp@ietf.org
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 20:03:13 -0000

Noel,

>>> This was covered in Comment 4 of the message Yakov sent to the list:
>>> Suppose a certain EID's mapping entry ... lists the RLOCs of two ETRs,
>>> ETR1 and ETR2. Suppose that later on due to connectivity issues within
>>> the site, ETR1 is able to reach the EID, but ETR2 is not. Is there
>>> some means by which traffic is expected to reliably reach the EID in
>>> this case?
> 
> I was trying to get caught up enough in my email to answer this the first
> time it was asked, but I guess this time will do... :-)
> 
> 
> Those on the LISP design team will recognize this as the issue "EID
> reachability as opposed to RLOC reachability" from the LISP 'Outstanding
> Issues' list.
> 
> (I should explain here that I have a long list of 'Outstanding issues' with
> LISP; I have not bothered to mention them to the WG, because they almost all
> have the characteristic that the best fix does not require any _protocol_
> changes, so the fix can be deployed at leisure - and, more importantly, the
> fix can usually be deployed incrementally, with no need to co-ordinate the
> deployment of the fix. I.e. we can change the spec, to add algorithms to deal
> with the issue, and it can be deployed in each LISP device independently.
> Since there are higher-priority things the WG needs to focus on, I have
> therefore placed those items in a 'look at later' status.)

Do you have detailed solutions to all of the outstanding issues in
your list ? As if not, then your claims about "the best fix does
not require any _protocol_ changes", "can usually be deployed
incrementally", and "with no need to co-ordinate the deployment of
the fix" are nothing more than a collection of (unsubstantiated)
assertions.
  
> Anyway, as some other posts have sort of pointed out, this issue of endpoint
> reachability is something that the existing routing/etc architecturs doesn't
> really handle, and that's the main reason it has not been addressed.
> 
> In general, an external router, RE1, which is advertising an address range
> into the core has not verified that all the addresses covered by that block
> are _actually reachable_, i.e. that it can successfully exchange packets with
> every addresss in that range. (Which is the meaning of "reachable" we are
> talking about here, I assume. I should mention here that to many LISP people,
> 'reachability' has come to mean 'we actually tried it to make sure it
> _really_ works', not just 'some table entry somewhere says it _should_
> work'.).
> 
> Indeed, with a stub AS which has a static config of what to advertize, a
> router may be advertizing an address range which it knows, from IGP
> information, it cannot reach. Or if it has a static internal route, it may
> advertize that externally without knowing if those destinations are
> reachable; some intermediate internal router may have failed.
> 
> And even if the IGP tells RE1 it can get to a particular address range, that
> may still be incorrect. E.g. if an internal router, RI1, is telling RE1 that
> RI1 can reach a particular range, but there is some sort of defect which
> prevents RI1 from reaching a particular address in that range (perhaps a bad
> port on a hub, or something like that), RE1 has no way of knowing that.
> 
> Since this limitation seems to already be generally acceptable today, we did
> not think it desirable to add the extra complexity/overhead which would be
> needed in order to 'solve' a problem that apparently the world is not
> clamouring to have solved.
> 
> Perhaps you had in mind a weaker version of 'EID reachability'? (Bearing in
> mind that the term means different things in different communities.) Did you
> simply mean 'an ETR should not advertize an address range in a mapping unless
> it has indications, from the IGP, that it can actually reach that address
> range'?
> 
> I'm not sure that's really a 'LISP protocol' issue, any more than the
> analogous BGP behaviour is a BGP issue; yes, it is an issue for how the
> interface between BGP and the rest of the router is specified (i.e. does one
> even allow static routes to be configured, or does one only allow BGP to
> adversize address blocks which it has live internal dynamic routes to)?
> 
> Similarly, if you'd simply like the interface between the ETR and the
> internal routing to be more dynamic, so that the mappings are less likely to
> contain incorrect information, that's fine, but it's more of a 'LISP
> interfacing/usage specification' thing.
 
As Dino told us, the mapping information has nothing to do
with the reachability between a given ETR and a given EID.
  
> If on the other hand you really did mean 'an ETR should not advertize a
> mapping for an EID X unless that EID is reachable from the ETR' (using the
> strong meaning of "reachable"), that's something I can discuss at some
> length. (I have thought that through, in some detail, but examining the
> problem at an architectural level - i.e. not specific to LISP, the same
> tradeoffs/constraints would apply to any packet-switching system trying to
> implement this functionality.)
> 
> But I won't launch into that until I'm sure that's what you're really trying
> to do.
 
We want the LISP spec explicitly spell out the semantics of {RLOG,
EID} information carried in Map-Replies, and specifically whether
this information carries any indication of whether a particular EID
is reachable from a particular RLOC.  

If this information does carry the indication of whether a particular
EID is reachable from a particular RLOC, then we want the LISP spec
to explicitly spell out (a) how the xTR that sends this acquires
it (as the information may be for RLOCs that are different from the
xTR), and (b) how can one invalidate this information when (at some
later point) the EID is no longer reachable from the RLOC.

If this information does not carry the indication of whether a
particular EID is reachable from a particular RLOC, then we want
the LISP spec to explicitly spell out the procedures to determine
whether the EID is reachable from the RLOC (in the presence of
multiple RLOCs for the same EID).

Yakov.


From yakov@juniper.net  Thu Apr 22 13:19:15 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6623A6953 for ; Thu, 22 Apr 2010 13:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.869
X-Spam-Level: 
X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=0.730,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfszRCErhizH for ; Thu, 22 Apr 2010 13:19:12 -0700 (PDT)
Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 1D21F3A685B for ; Thu, 22 Apr 2010 13:19:05 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS9CvIepZ+J8KhWENFFFVmsHspigHJKrR@postini.com; Thu, 22 Apr 2010 13:18:57 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 22 Apr 2010 13:16:29 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 13:16:29 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 13:16:29 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 13:16:28 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3MKGSD09743; Thu, 22 Apr 2010 13:16:28 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <201004222016.o3MKGSD09743@magenta.juniper.net>
To: Eliot Lear 
In-Reply-To: <4BD0A9EF.3060808@cisco.com> 
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0A9EF.3060808@cisco.com>
X-MH-In-Reply-To: Eliot Lear  message dated "Thu, 22 Apr 2010 21:56:31 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <83661.1271967388.1@juniper.net>
Date: Thu, 22 Apr 2010 13:16:28 -0700
From: Yakov Rekhter 
X-OriginalArrivalTime: 22 Apr 2010 20:16:28.0844 (UTC) FILETIME=[B105FEC0:01CAE258]
Cc: trac@localhost.amsl.com, lisp@ietf.org, lisp issue tracker 
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 20:19:15 -0000

Eliot,

> >> On 4/22/10 2:36 PM, lisp issue tracker wrote:
> >>>   The above means that at the minimum the price of resilience between
> >>>   the CE routers is the inability to support traffic engineering?
> >>>   Specifically, the ISP loses any influence over the choice of which ETR
> >>>   should be used to reach the multi-homed enterprise.
> >> First of all, this is one of several means to provide resiliency, and so
> >> to say this is a minimum price is overstating it.  It's one of the tools
> >> in the toolbox.
> >>
> >> SPs have great say over their traffic because they continue to control
> >> any and all BGP announcements they make, and they continue to control
> >> their own IGP, as well as whatever load splitting they wish to do based
> >> on a destination address (LISP or otherwise).
> >
> > Sure, but these are the mechanisms provided by the current routing
> > system, not by LISP.
> >
> > To reflect this in the spec please add the following to section 8.2:
> >
> >     Use of anycast addresses for resiliency in LISP results in
> >     inability to use LISP for traffic engineering, and specifically
> >     in inability to use LISP to influence the choice of whith ETR
> >     should be used to reach a multi-homed enterprise. In other
> >     words, when anycast addresses are used as RLOCs, LISP by itself
> >     does not provide any traffic engineering capabilities.
> 
> I guess I think the text adequately addresses the issue, and see below.
> 
> >>>   Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are
> >>>   anycast addresses as well, and thus can not be topologically
> >>>   significant. Thus if an enterprise is multi-homed to two (or more)
> >>>   ISPs, then use of anycast addresses for CEs would require to route
> >>>   such addresses as /32 throughout the whole Internet.
> >> Wow.  No.  Anycast has a scope based on who routes it.  If it's routed
> >> within an ISP it has a scope within an ISP.  If it is only routed within
> >> the enterprise it has an even narrower scope.  It could be routed
> >> between two ISPs.  Mix and match.
> >
> > The observation specifically cites the case of an enterprise
> > "multi-homed to two (or more) ISPs". With this in mind please
> > consider the case of site A attached to ISPs X, Y, site B attached
> > to ISPs Y and Z, and site C attached to ISPs X, Y, and Z.  Both
> > site A, site B, and site C use anycast addresses as their RLOCs.
> > What are the procedures for allocating these anycast addresses ?
> 
> First, why is this limited to LISP?  

Because we are discussing LISP.

> Wouldn't this be an issue for any 
> anycast service?  Second, there is an implicit assumption in what you 
> write that this would be a globally scoped anycast- that is, people 
> would be announcing anycast willy nilly.  I think that unlikely since it 
> would in effect replace one routing entry of an end system for another.
> 
> On the other hand, a more localized use of anycast seems to carry very 
> limited impact on the routing system.

Please answer the questions I asked you.
  
> > What are the rules for advertisting routes to these anycast addresses ?
> 
> Again, why is this a LISP issue?  

Because we are discussing LISP.

> What are the rules for announcing any 
> anycast route?

That does not answer the questions I asked above.

> > This is a LISP issue, as LISP proposes to use anycast addresses
> > as RLOCs. Thus LISP specs have to document how xTRs should deal
> > with that issue. "A smart box might notice that it has lost
> > internal connectivity, and act accordingly" is *not* an adequate
> > documentation.
> 
> Yakov- how do you handle a case where you have a router originating a 
> BGP announcement for a network that it is no longer connected to?  Why 
> would this situation be any different?

That is not an acceptable answer.

Yakov.

From jnc@mercury.lcs.mit.edu  Thu Apr 22 13:37:08 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D433A68DF for ; Thu, 22 Apr 2010 13:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.572
X-Spam-Level: 
X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=1.027,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7nlVNbUsQci for ; Thu, 22 Apr 2010 13:37:06 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 9DC0F3A6949 for ; Thu, 22 Apr 2010 13:36:55 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BC8DE6BE59A; Thu, 22 Apr 2010 16:36:44 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20100422203644.BC8DE6BE59A@mercury.lcs.mit.edu>
Date: Thu, 22 Apr 2010 16:36:44 -0400 (EDT)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 20:37:08 -0000

    > From: Yakov Rekhter 

    > Do you have detailed solutions to all of the outstanding issues in your
    > list?

I have reviewed the list, and all except one (listed below) have more than
one possible solution listed.

For instance, for "Packets received when the cache has no mapping", I have no
less than four possible remediations listed - plus there's now a new one
since I last updated the list (which is to send the packet to a PITR which is
advertizing the destination).

BTW, that example illustrates something else about the list: many of them are
performance issues, not 'failure' issues - i.e. the design as currently
promulgated works, but it could be faster. The question of course in each
case is whether the extra performance is worth the extra complexity.

    > your claims about ... "can usually be deployed incrementally", and
    > "with no need to co-ordinate the deployment of the fix" are nothing
    > more than a collection of (unsubstantiated) assertions.

I also checked to see if, for each issue (with the exception noted above), at
least one potential solution does not require a protocol change and/or
co-ordinated deployment. With one exception ("Mappings take a while to
arrive" - i.e. at least one RTT) this is also true.

Speeding up the arrival of mappings would require some significant work - but
this is hardly news to anyone, I expect!


The only issue for which I do not have a solution is "EID reachability",
which we are currently discussing here. (Well, I have a 'solution' listed,
but it's not very useful: it says "Ignore it". :-)

That is for the reasons previously discussed here:

    >> Since this limitation seems to already be generally acceptable today,
    >> we did not think it desirable to add the extra complexity/overhead
    >> which would be needed in order to 'solve' a problem that apparently
    >> the world is not clamouring to have solved.

But let me read the rest of your post, on this specific issue, and comment.

	Noel

From jmh@joelhalpern.com  Thu Apr 22 13:48:28 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC54D3A68C3 for ; Thu, 22 Apr 2010 13:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.169
X-Spam-Level: 
X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.430,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhDzOf-pVDdN for ; Thu, 22 Apr 2010 13:48:27 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7E55E3A685B for ; Thu, 22 Apr 2010 13:48:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id EF73D3235875; Thu, 22 Apr 2010 13:48:17 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.10.10.102] (pool-71-161-51-173.clppva.btas.verizon.net [71.161.51.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 2977832284C6; Thu, 22 Apr 2010 13:48:17 -0700 (PDT)
Message-ID: <4BD0B610.6050103@joelhalpern.com>
Date: Thu, 22 Apr 2010 16:48:16 -0400
From: "Joel M. Halpern" 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Noel Chiappa 
References: <20100422203644.BC8DE6BE59A@mercury.lcs.mit.edu>
In-Reply-To: <20100422203644.BC8DE6BE59A@mercury.lcs.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lisp@ietf.org
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 20:48:28 -0000

I think that there is a slight miscommunication.
It is true today that routing can give misinformation, and packets will 
be black-holed for a time.
But whether that is true or false today for our current system, the 
question being asked is:

Do we have a problem with information inconsistency and potential 
block-holes in LISP.
Yakov provided a clean disassembly of the questions.
The LISP document has to answer the questions for LISP.

The answer may be that the semantics are such that there is no problem. 
  If so, we need to clearly describe the semantics, and how they are 
achieved.
rather more likely, the semantics are such that there is are corner 
cases where bad things happen.
We don't have to solve all such corner cases.  We have to document what 
the behavior (and semantics is).  We can then say "This does result in 
the following failures... in the following circumstances ..."  And then 
we can say whether and why that is okay for this experiment.  (That last 
bit might include references to experience with existing systems.  But 
until we have stated the behavior, the existing behavior of the current 
system is not the quesiton.)

yours,
Joel

Noel Chiappa wrote:
>     > From: Yakov Rekhter 
> 
>     > Do you have detailed solutions to all of the outstanding issues in your
>     > list?
> 
> I have reviewed the list, and all except one (listed below) have more than
> one possible solution listed.
> 
> For instance, for "Packets received when the cache has no mapping", I have no
> less than four possible remediations listed - plus there's now a new one
> since I last updated the list (which is to send the packet to a PITR which is
> advertizing the destination).
> 
> BTW, that example illustrates something else about the list: many of them are
> performance issues, not 'failure' issues - i.e. the design as currently
> promulgated works, but it could be faster. The question of course in each
> case is whether the extra performance is worth the extra complexity.
> 
>     > your claims about ... "can usually be deployed incrementally", and
>     > "with no need to co-ordinate the deployment of the fix" are nothing
>     > more than a collection of (unsubstantiated) assertions.
> 
> I also checked to see if, for each issue (with the exception noted above), at
> least one potential solution does not require a protocol change and/or
> co-ordinated deployment. With one exception ("Mappings take a while to
> arrive" - i.e. at least one RTT) this is also true.
> 
> Speeding up the arrival of mappings would require some significant work - but
> this is hardly news to anyone, I expect!
> 
> 
> The only issue for which I do not have a solution is "EID reachability",
> which we are currently discussing here. (Well, I have a 'solution' listed,
> but it's not very useful: it says "Ignore it". :-)
> 
> That is for the reasons previously discussed here:
> 
>     >> Since this limitation seems to already be generally acceptable today,
>     >> we did not think it desirable to add the extra complexity/overhead
>     >> which would be needed in order to 'solve' a problem that apparently
>     >> the world is not clamouring to have solved.
> 
> But let me read the rest of your post, on this specific issue, and comment.
> 
> 	Noel
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
> 

From robert@raszuk.net  Thu Apr 22 13:56:21 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0AD3A695D for ; Thu, 22 Apr 2010 13:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.489
X-Spam-Level: 
X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=1.109,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAxVjGpZqltI for ; Thu, 22 Apr 2010 13:56:20 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E5D4D28C0FC for ; Thu, 22 Apr 2010 13:56:16 -0700 (PDT)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEFV0EurR7Ht/2dsb2JhbACcKnGnFpo2hQ8E
X-IronPort-AV: E=Sophos;i="4.52,258,1270425600"; d="scan'208";a="220065813"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2010 20:56:07 +0000
Received: from [192.168.1.61] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MKu56n017276; Thu, 22 Apr 2010 20:56:06 GMT
Message-ID: <4BD0B7E4.8050608@raszuk.net>
Date: Thu, 22 Apr 2010 22:56:04 +0200
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Yakov Rekhter 
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org>	<077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org>	<4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net>
In-Reply-To: <201004221935.o3MJZnD90060@magenta.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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: Thu, 22 Apr 2010 20:56:21 -0000

Yakov,

> Sure, but these are the mechanisms provided by the current routing
> system, not by LISP.
>
> To reflect this in the spec please add the following to section 8.2:
>
>    Use of anycast addresses for resiliency in LISP results in
>    inability to use LISP for traffic engineering, and specifically
>    in inability to use LISP to influence the choice of whith ETR
>    should be used to reach a multi-homed enterprise. In other
>    words, when anycast addresses are used as RLOCs, LISP by itself
>    does not provide any traffic engineering capabilities.

That is not correct. No one says that LISP site may not have 4 ETRs with 
each pair using anycast address as RLOCs yet provide for traffic 
engineering between such pairs to a LISP site.

> The observation specifically cites the case of an enterprise
> "multi-homed to two (or more) ISPs". With this in mind please
> consider the case of site A attached to ISPs X, Y, site B attached
> to ISPs Y and Z, and site C attached to ISPs X, Y, and Z.  Both
> site A, site B, and site C use anycast addresses as their RLOCs.
> What are the procedures for allocating these anycast addresses ?
> What are the rules for advertisting routes to these anycast addresses ?

Again no one says from what I know that a site is attached with single 
ETR to a given ISP. So with this in mind if site uses redundancy with 
it's attachments each anycast address may come from each ISP pool of PI 
addresses which would be fully able to be aggregated in the Internat 
without _any_ need to advertise /32s beyond area spanning given set of ETRs.

R.

From lear@cisco.com  Thu Apr 22 14:05:10 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14BD3A6978 for ; Thu, 22 Apr 2010 14:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.431
X-Spam-Level: 
X-Spam-Status: No, score=-8.431 tagged_above=-999 required=5 tests=[AWL=2.169,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJqnjWZczPWk for ; Thu, 22 Apr 2010 14:05:07 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 91BBE3A6858 for ; Thu, 22 Apr 2010 14:05:04 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq8BAFNX0EuQ/uCWiWdsb2JhbACDFpkUFQEBAQoLEREGHKcZiGeRT4EqgnhtBINR
X-IronPort-AV: E=Sophos;i="4.52,258,1270425600"; d="scan'208";a="59899412"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2010 21:04:52 +0000
Received: from ams3-vpn-dhcp6001.cisco.com (ams3-vpn-dhcp6001.cisco.com [10.61.87.112]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3ML4qN8010629; Thu, 22 Apr 2010 21:04:52 GMT
Message-ID: <4BD0B9E6.50707@cisco.com>
Date: Thu, 22 Apr 2010 23:04:38 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100421 Lanikai/3.1b2pre
MIME-Version: 1.0
To: Yakov Rekhter 
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0A9EF.3060808@cisco.com> <201004222016.o3MKGSD09743@magenta.juniper.net>
In-Reply-To: <201004222016.o3MKGSD09743@magenta.juniper.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lisp issue tracker , trac@localhost.amsl.com, lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 21:05:10 -0000

On 4/22/10 10:16 PM, Yakov Rekhter wrote:
> Eliot,
>
>>>> On 4/22/10 2:36 PM, lisp issue tracker wrote:
>>>>>    The above means that at the minimum the price of resilience between
>>>>>    the CE routers is the inability to support traffic engineering?
>>>>>    Specifically, the ISP loses any influence over the choice of which ETR
>>>>>    should be used to reach the multi-homed enterprise.
>>>> First of all, this is one of several means to provide resiliency, and so
>>>> to say this is a minimum price is overstating it.  It's one of the tools
>>>> in the toolbox.
>>>>
>>>> SPs have great say over their traffic because they continue to control
>>>> any and all BGP announcements they make, and they continue to control
>>>> their own IGP, as well as whatever load splitting they wish to do based
>>>> on a destination address (LISP or otherwise).
>>> Sure, but these are the mechanisms provided by the current routing
>>> system, not by LISP.
>>>
>>> To reflect this in the spec please add the following to section 8.2:
>>>
>>>      Use of anycast addresses for resiliency in LISP results in
>>>      inability to use LISP for traffic engineering, and specifically
>>>      in inability to use LISP to influence the choice of whith ETR
>>>      should be used to reach a multi-homed enterprise. In other
>>>      words, when anycast addresses are used as RLOCs, LISP by itself
>>>      does not provide any traffic engineering capabilities.
>> I guess I think the text adequately addresses the issue, and see below.
>>
>>>>>    Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are
>>>>>    anycast addresses as well, and thus can not be topologically
>>>>>    significant. Thus if an enterprise is multi-homed to two (or more)
>>>>>    ISPs, then use of anycast addresses for CEs would require to route
>>>>>    such addresses as /32 throughout the whole Internet.
>>>> Wow.  No.  Anycast has a scope based on who routes it.  If it's routed
>>>> within an ISP it has a scope within an ISP.  If it is only routed within
>>>> the enterprise it has an even narrower scope.  It could be routed
>>>> between two ISPs.  Mix and match.
>>> The observation specifically cites the case of an enterprise
>>> "multi-homed to two (or more) ISPs". With this in mind please
>>> consider the case of site A attached to ISPs X, Y, site B attached
>>> to ISPs Y and Z, and site C attached to ISPs X, Y, and Z.  Both
>>> site A, site B, and site C use anycast addresses as their RLOCs.
>>> What are the procedures for allocating these anycast addresses ?
>> First, why is this limited to LISP?
> Because we are discussing LISP.

The general principles of anycast (both benefits and limitations) are 
well understood.
>> Wouldn't this be an issue for any
>> anycast service?

Please answer this question.  Because absent an answer we do not lead to 
changes to a document.


>> Second, there is an implicit assumption in what you
>> write that this would be a globally scoped anycast- that is, people
>> would be announcing anycast willy nilly.  I think that unlikely since it
>> would in effect replace one routing entry of an end system for another.
>>
>> On the other hand, a more localized use of anycast seems to carry very
>> limited impact on the routing system.
> Please answer the questions I asked you.

Absent a desire to implement a global anycast, existing allocation 
mechanisms within a service provider will suffice, and when two SPs are 
involved, a bilateral (or multilateral) agreement allows for an 
announcement of a specific address or block.

>
>>> What are the rules for advertisting routes to these anycast addresses ?
>> Again, why is this a LISP issue?
> Because we are discussing LISP.

No, we're not.  We're discussing basic L3 routing at this point.

>> What are the rules for announcing any
>> anycast route?
> That does not answer the questions I asked above.

Yes it does because you can make use of those very same rules.

>>> This is a LISP issue, as LISP proposes to use anycast addresses
>>> as RLOCs. Thus LISP specs have to document how xTRs should deal
>>> with that issue. "A smart box might notice that it has lost
>>> internal connectivity, and act accordingly" is *not* an adequate
>>> documentation.
>> Yakov- how do you handle a case where you have a router originating a
>> BGP announcement for a network that it is no longer connected to?  Why
>> would this situation be any different?
> That is not an acceptable answer.

Thank you for your opinion.  A cornerstone of LISP and engineering in 
general is to build on what has come before.  This principle applies 
here as well.  Sad you seem not to understand such things.

Eliot


From dino@cisco.com  Thu Apr 22 14:05:59 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775793A6957 for ; Thu, 22 Apr 2010 14:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.203
X-Spam-Level: 
X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[AWL=1.396,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-Sr+pBR0eVI for ; Thu, 22 Apr 2010 14:05:54 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 799803A68DF for ; Thu, 22 Apr 2010 14:05:54 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,258,1270425600"; d="scan'208";a="319649309"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 22 Apr 2010 21:05:40 +0000
Received: from [10.10.10.86] (sjc-vpn7-331.cisco.com [10.21.145.75]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3ML5d5s026403; Thu, 22 Apr 2010 21:05:39 GMT
Message-Id: 
From: Dino Farinacci 
To: Yakov Rekhter 
In-Reply-To: <201004221935.o3MJZnD90060@magenta.juniper.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 22 Apr 2010 14:05:39 -0700
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net>
X-Mailer: Apple Mail (2.936)
Cc: trac@localhost.amsl.com, lisp issue tracker , lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 21:05:59 -0000

> To reflect this in the spec please add the following to section 8.2:
>
>   Use of anycast addresses for resiliency in LISP results in
>   inability to use LISP for traffic engineering, and specifically
>   in inability to use LISP to influence the choice of whith ETR
>   should be used to reach a multi-homed enterprise. In other
>   words, when anycast addresses are used as RLOCs, LISP by itself
>   does not provide any traffic engineering capabilities.

I don't think it's all or nothing here. You could have this situation:

o A multi-national company with locators in the US and Europe.
o There are 4 connections to the Internet to reach the site.
o Two connections are in the US. Two connections are in Europe.
o The locator-set has 2 RLOCs, each with priority 1.
o RLOC 1 is an anycast address assigned to both US connections.
o RLOC 2 is an anycast address assigned to both European connections.

This is an active/active policy for the site where they wouldn't have  
to run any locator reachability algorithm. The underlying network  
would route packets to 1 of the connection points within a RLOC.

So this model is active/active at a hierarchical level:

	    RLOC1        RLOC2       active/active
            US1 US2     Euro1 Euro2   active/active/active/active

The LISP ITR selects either RLOC1 or RLOC2 based on the 5-tuple hash  
of the inner header. And underlying routing selects the physical path  
to the ITR selected RLOC.

Dino


From yakov@juniper.net  Thu Apr 22 14:09:22 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13933A6893 for ; Thu, 22 Apr 2010 14:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.96
X-Spam-Level: 
X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.639,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLO2dhzb75Mu for ; Thu, 22 Apr 2010 14:09:21 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id A4AA03A684B for ; Thu, 22 Apr 2010 14:09:21 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKS9C69gaK7ZzLjSmtFILhBp2EnBPnoxs9@postini.com; Thu, 22 Apr 2010 14:09:12 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 22 Apr 2010 14:06:16 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 14:06:16 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 14:06:15 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 14:06:15 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3ML6ED35682; Thu, 22 Apr 2010 14:06:14 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <201004222106.o3ML6ED35682@magenta.juniper.net>
To: 
In-Reply-To: <4BD0B7E4.8050608@raszuk.net> 
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0B7E4.8050608@raszuk.net>
X-MH-In-Reply-To: Robert Raszuk  message dated "Thu, 22 Apr 2010 22:56:04 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <86798.1271970374.1@juniper.net>
Date: Thu, 22 Apr 2010 14:06:14 -0700
From: Yakov Rekhter 
X-OriginalArrivalTime: 22 Apr 2010 21:06:15.0384 (UTC) FILETIME=[A523D580:01CAE25F]
Cc: lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 21:09:23 -0000

Robert,

> > Sure, but these are the mechanisms provided by the current routing
> > system, not by LISP.
> >
> > To reflect this in the spec please add the following to section 8.2:
> >
> >    Use of anycast addresses for resiliency in LISP results in
> >    inability to use LISP for traffic engineering, and specifically
> >    in inability to use LISP to influence the choice of whith ETR
> >    should be used to reach a multi-homed enterprise. In other
> >    words, when anycast addresses are used as RLOCs, LISP by itself
> >    does not provide any traffic engineering capabilities.
> 
> That is not correct. No one says that LISP site may not have 4 ETRs with 
> each pair using anycast address as RLOCs yet provide for traffic 
> engineering between such pairs to a LISP site.

Ok. Let me modify the text I proposed to reflect this, as follows:

    Use of anycast addresses for resiliency in LISP results in
    inability to use LISP for traffic engineering among the xTRs
    that use the same anycast address, and specifically in inability
    to use LISP to influence the choice of which ETR should be used
    to reach a multi-homed enterprise if these ETRs use the same
    anycast address. In other words, when anycast addresses are
    used as RLOCs, LISP by itself does not provide any traffic
    engineering capabilities among the xTRs that use the same anycast
    address.

> > The observation specifically cites the case of an enterprise
> > "multi-homed to two (or more) ISPs". With this in mind please
> > consider the case of site A attached to ISPs X, Y, site B attached
> > to ISPs Y and Z, and site C attached to ISPs X, Y, and Z.  Both
> > site A, site B, and site C use anycast addresses as their RLOCs.
> > What are the procedures for allocating these anycast addresses ?
> > What are the rules for advertisting routes to these anycast addresses ?
> 
> Again no one says from what I know that a site is attached with single 
> ETR to a given ISP. So with this in mind if site uses redundancy with 
> it's attachments each anycast address may come from each ISP pool of PI 
> addresses which would be fully able to be aggregated in the Internat 
> without _any_ need to advertise /32s beyond area spanning given set of ETRs.

Please describe how this would be applied in the scenario I presented
above. For the purpose of the example, assume that ISP X has 10.1/16
pool, ISP Y has 20.2/16 pool, and ISP Z has 30.3/16 pool.

Yakov.

From robert@raszuk.net  Thu Apr 22 14:28:39 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816773A692C for ; Thu, 22 Apr 2010 14:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.711
X-Spam-Level: 
X-Spam-Status: No, score=-9.711 tagged_above=-999 required=5 tests=[AWL=0.888,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdTVkWcOTRQr for ; Thu, 22 Apr 2010 14:28:38 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 868713A68E4 for ; Thu, 22 Apr 2010 14:28:38 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAD5c0EurR7Ht/2dsb2JhbACcKnGnIJo2hQ8E
X-IronPort-AV: E=Sophos;i="4.52,258,1270425600"; d="scan'208";a="187083051"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2010 21:28:28 +0000
Received: from [192.168.1.61] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MLSREN018914; Thu, 22 Apr 2010 21:28:27 GMT
Message-ID: <4BD0BF7B.8050409@raszuk.net>
Date: Thu, 22 Apr 2010 23:28:27 +0200
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Yakov Rekhter 
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0B7E4.8050608@raszuk.net> <201004222106.o3ML6ED35682@magenta.juniper.net>
In-Reply-To: <201004222106.o3ML6ED35682@magenta.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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: Thu, 22 Apr 2010 21:28:39 -0000

Hi Yakov,

> Ok. Let me modify the text I proposed to reflect this, as follows:
>
>      Use of anycast addresses for resiliency in LISP results in
>      inability to use LISP for traffic engineering among the xTRs
>      that use the same anycast address, and specifically in inability
>      to use LISP to influence the choice of which ETR should be used
>      to reach a multi-homed enterprise if these ETRs use the same
>      anycast address. In other words, when anycast addresses are
>      used as RLOCs, LISP by itself does not provide any traffic
>      engineering capabilities among the xTRs that use the same anycast
>      address.

I think I could come up with much shorter paragraph still reflecting all 
from the above:

"If packets are encapsulated to a given destination address (in 
particular anycast address) one should not expect that they would end up 
in a different destination then the one listed in the destination 
address of the packet's header."

>>> The observation specifically cites the case of an enterprise
>>> "multi-homed to two (or more) ISPs". With this in mind please
>>> consider the case of site A attached to ISPs X, Y, site B attached
>>> to ISPs Y and Z, and site C attached to ISPs X, Y, and Z.  Both
>>> site A, site B, and site C use anycast addresses as their RLOCs.
>>> What are the procedures for allocating these anycast addresses ?
>>> What are the rules for advertisting routes to these anycast addresses ?
>>
>> Again no one says from what I know that a site is attached with single
>> ETR to a given ISP. So with this in mind if site uses redundancy with
>> it's attachments each anycast address may come from each ISP pool of PI
>> addresses which would be fully able to be aggregated in the Internat
>> without _any_ need to advertise /32s beyond area spanning given set of ETRs.
>
> Please describe how this would be applied in the scenario I presented
> above. For the purpose of the example, assume that ISP X has 10.1/16
> pool, ISP Y has 20.2/16 pool, and ISP Z has 30.3/16 pool.

This is similar example as just provided by Dino, but let me explain 
based on your exact data points provided:

Site A would be attached to ISP X with ETR1 and ETR1' - 10.1.1.1
Site A would be attached to ISP Y with ETR2 and ETR2' - 20.2.1.1

Site B would be attached to ISP Y with ETR3 and ETR3' - 20.2.1.2
Site B would be attached to ISP Z with ETR4 and ETR4' - 30.3.1.1

Site C would be attached to ISP X with ETR5 and ETR5' - 10.1.1.2
Site C would be attached to ISP Y with ETR6 and ETR6' - 20.2.1.3
Site C would be attached to ISP Z with ETR7 and ETR7' - 30.3.1.2

It is clearly an example of an enterprise multi-homed to two (or more) ISPs.

R.

From jnc@mercury.lcs.mit.edu  Thu Apr 22 14:38:55 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201E73A6845 for ; Thu, 22 Apr 2010 14:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.065
X-Spam-Level: 
X-Spam-Status: No, score=-4.065 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_50=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0veXDmnmqe6C for ; Thu, 22 Apr 2010 14:38:54 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id CC35D3A6783 for ; Thu, 22 Apr 2010 14:38:53 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A74076BE57D; Thu, 22 Apr 2010 17:38:42 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20100422213842.A74076BE57D@mercury.lcs.mit.edu>
Date: Thu, 22 Apr 2010 17:38:42 -0400 (EDT)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 21:38:55 -0000

    >> if you'd simply like the interface between the ETR and the internal
    >> routing to be more dynamic, so that the mappings are less likely to
    >> contain incorrect information

    > the mapping information has nothing to do with the reachability between
    > a given ETR and a given EID.

Your query does raise an interesting architetural question, which is: 'what
channels are available in LISP, architecturally, to convey information about
reachability of EIDs from an ETR'. The thing is that mappings are not
supposed to contain very dynamic information - which may have been your
point?

However... it ETR E1 is up, but temporarily cannot reach some of the address
ranges it is advertizing, it currently has no semantic channel, _other than
issuing an updated mapping_, to propogate that information to its
correspondent ITRs.

That's not necessarily bad, in purely engineering terms: its correspondent
ITRs should quickly (via mapping versioning) find out that a new mapping is
available, and load it. I do concede it's slightly ugly in architectural
terms.


Part of the problem here is that LISP is in this architectural netherworld
between a pure mapping system and a pure routing system; it has some aspects
of both (and the problems of both).

(The routing stuff is in part because of limitations in the current routing
architecture, for which it's trying to compensate, but that's neither here
not there...)

Trust me, this drive me bananas; in fact, the whole LISP architectural
approach causes me a certain amount of grief. Unfortunately, I don't think we
have the luxury of a clean slate, one in which we can produce a nice, clean,
elegant design. We have to work with the lemons that are already globally
deployed, no matter how ugly the result...


    > We want the LISP spec explicitly spell out the semantics of {RLO[C],
    > EID} information carried in Map-Replies, and specifically whether this
    > information carries any indication of whether a particular EID is
    > reachable from a particular RLOC.

Ah, got it. Well, as things stand, if an ETR R1 advertises a mapping from R1
to EID range Ex, it's making an assertion, on which others will rely, that it
can 'reach' Ex.

    > If this information does carry the indication of whether a particular
    > EID is reachable from a particular RLOC, then we want the LISP spec to
    > explicitly spell out (a) how the xTR that sends this acquires it (as
    > the information may be for RLOCs that are different from the xTR)

That may be biting off more than we want to chew right at the moment. E.g. Do
we disallow static configuration? Suppose it's getting it from the IGP - do
we have to list how that works? I'd rather just leave it exactly the way I
put it above ("if an ETR R1 advertises a mapping from R1 to EID range Ex,
it's making an assertion, on which others will rely, that it can 'reach' Ex")
and leave it at that: it makes crystal clear what the responsibility of R1 is
when it advertizes a mapping for an EID range.

    > and (b) how can one invalidate this information when (at some later
    > point) the EID is no longer reachable from the RLOC.

That one doesn't bother me much - as I said, it issues a new mapping, and
people will acquire that quickly because of the versioning.

But you're probably right that this area could use some clarification.

    > If this information does not carry the indication of whether a
    > particular EID is reachable from a particular RLOC, then we want the
    > LISP spec to explicitly spell out the procedures to determine whether
    > the EID is reachable from the RLOC

Why can't we just re-use whatever text BGP currently uses to specify what a
router has to do to ensure that an address range is reachable from it, before
it's allowed to advertize that address range? Do we currently have stringent
standards on what a router has to do before it advertizes reachability?

The thing is that the term "reachability" can have a large range of
'dependability', so what exactly does it mean to say that 'X is reachable
from R' anyway? If R is a router with an explicit route to X, is X
'reachable' from R or not? How about if R is a router which shares a hardware
network with X, but R isn't pinging X to make sure it _really_ can reach X?

I'm not trying to be a PITA here, but the term 'reachable' has historically
been ill-defined in the IETF, except in the bottom line sense (as in,q 'when I
try it, it works'), and I'd like to do better on saying just what it means,
i.e. just how much one can rely on it if some node says 'x is reachable from
me'.

    > (in the presence of multiple RLOCs for the same EID).

Synchronization of mapping information between multiple ETRs (which is what I
gather you are alluding to here), and mechanisms to perform that, are
currently an open area - in part because currently it's all manual.

Any chance you can design something, and write a spec? :-)

	Noel

From yakov@juniper.net  Thu Apr 22 14:42:57 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6583A69EC for ; Thu, 22 Apr 2010 14:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.031
X-Spam-Level: 
X-Spam-Status: No, score=-6.031 tagged_above=-999 required=5 tests=[AWL=0.568,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYnfdLZw-hI5 for ; Thu, 22 Apr 2010 14:42:56 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 07DA03A6970 for ; Thu, 22 Apr 2010 14:42:55 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS9DC04UbwVk2Wn/+Mg9edtHvex8e6oty@postini.com; Thu, 22 Apr 2010 14:42:46 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 22 Apr 2010 14:39:06 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 14:39:06 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 14:39:05 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 14:39:04 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3MLd4D51678; Thu, 22 Apr 2010 14:39:04 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <201004222139.o3MLd4D51678@magenta.juniper.net>
To: 
In-Reply-To: <4BD0BF7B.8050409@raszuk.net> 
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0B7E4.8050608@raszuk.net> <201004222106.o3ML6ED35682@magenta.juniper.net> <4BD0BF7B.8050409@raszuk.net>
X-MH-In-Reply-To: Robert Raszuk  message dated "Thu, 22 Apr 2010 23:28:27 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <88673.1271972343.1@juniper.net>
Date: Thu, 22 Apr 2010 14:39:03 -0700
From: Yakov Rekhter 
X-OriginalArrivalTime: 22 Apr 2010 21:39:04.0890 (UTC) FILETIME=[3B0E99A0:01CAE264]
Cc: lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 21:42:57 -0000

Robert,

> > Ok. Let me modify the text I proposed to reflect this, as follows:
> >
> >      Use of anycast addresses for resiliency in LISP results in
> >      inability to use LISP for traffic engineering among the xTRs
> >      that use the same anycast address, and specifically in inability
> >      to use LISP to influence the choice of which ETR should be used
> >      to reach a multi-homed enterprise if these ETRs use the same
> >      anycast address. In other words, when anycast addresses are
> >      used as RLOCs, LISP by itself does not provide any traffic
> >      engineering capabilities among the xTRs that use the same anycast
> >      address.
> 
> I think I could come up with much shorter paragraph still reflecting all 
> from the above:
> 
> "If packets are encapsulated to a given destination address (in 
> particular anycast address) one should not expect that they would end up 
> in a different destination then the one listed in the destination 
> address of the packet's header."

That does not explicitly spell out the implications of using anycast 
addresses on the LISP TE capabilities.

> >>> The observation specifically cites the case of an enterprise
> >>> "multi-homed to two (or more) ISPs". With this in mind please
> >>> consider the case of site A attached to ISPs X, Y, site B attached
>>> to ISPs Y and Z, and site C attached to ISPs X, Y, and Z.  Both
> >>> site A, site B, and site C use anycast addresses as their RLOCs.
> >>> What are the procedures for allocating these anycast addresses ?
> >>> What are the rules for advertisting routes to these anycast addresses ?
> >>
> >> Again no one says from what I know that a site is attached with single
> >> ETR to a given ISP. So with this in mind if site uses redundancy with
> >> it's attachments each anycast address may come from each ISP pool of PI
> >> addresses which would be fully able to be aggregated in the Internat
> >> without _any_ need to advertise /32s beyond area spanning given set of ETR
s.
> >
> > Please describe how this would be applied in the scenario I presented
> > above. For the purpose of the example, assume that ISP X has 10.1/16
> > pool, ISP Y has 20.2/16 pool, and ISP Z has 30.3/16 pool.
> 
> This is similar example as just provided by Dino, but let me explain 
> based on your exact data points provided:
> 
> Site A would be attached to ISP X with ETR1 and ETR1' - 10.1.1.1
> Site A would be attached to ISP Y with ETR2 and ETR2' - 20.2.1.1
> 
> Site B would be attached to ISP Y with ETR3 and ETR3' - 20.2.1.2
> Site B would be attached to ISP Z with ETR4 and ETR4' - 30.3.1.1
> 
> Site C would be attached to ISP X with ETR5 and ETR5' - 10.1.1.2
> Site C would be attached to ISP Y with ETR6 and ETR6' - 20.2.1.3
> Site C would be attached to ISP Z with ETR7 and ETR7' - 30.3.1.2
> 
> It is clearly an example of an enterprise multi-homed to two (or more) ISPs.

In your example sites A and B have 4 ETRs, while site C has 6 ETRs.

My scenario is different - site A has two ETRs, one connected to ISP X,
another to ISP Y. Ditto for site B. Site C has three ETRs, one
connected to ISP X, another to ISP Y, and the last one to ISP Z.

What are the addresses used by these ETRs ?

Yakov.

From dino@cisco.com  Thu Apr 22 14:45:53 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0AA3A6A8A for ; Thu, 22 Apr 2010 14:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.482
X-Spam-Level: 
X-Spam-Status: No, score=-9.482 tagged_above=-999 required=5 tests=[AWL=1.117,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+6MUasi5187 for ; Thu, 22 Apr 2010 14:45:52 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9C5C03A6A88 for ; Thu, 22 Apr 2010 14:45:52 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALJg0EurR7Ht/2dsb2JhbACcKnGnKpo2hQ8EgzQ
X-IronPort-AV: E=Sophos;i="4.52,259,1270425600"; d="scan'208";a="187091948"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2010 21:45:42 +0000
Received: from [10.10.10.86] (sjc-vpn7-331.cisco.com [10.21.145.75]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MLjgd0004837; Thu, 22 Apr 2010 21:45:42 GMT
Message-Id: <161D4280-7081-41F3-B546-C6DA23A74858@cisco.com>
From: Dino Farinacci 
To: Yakov Rekhter 
In-Reply-To: <201004222139.o3MLd4D51678@magenta.juniper.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 22 Apr 2010 14:45:42 -0700
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0B7E4.8050608@raszuk.net> <201004222106.o3ML6ED35682@magenta.juniper.net> <4BD0BF7B.8050409@raszuk.net> <201004222139.o3MLd4D51678@magenta.juniper.net>
X-Mailer: Apple Mail (2.936)
Cc: lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 21:45:53 -0000

> n your example sites A and B have 4 ETRs, while site C has 6 ETRs.
>
> My scenario is different - site A has two ETRs, one connected to ISP  
> X,
> another to ISP Y. Ditto for site B. Site C has three ETRs, one
> connected to ISP X, another to ISP Y, and the last one to ISP Z.
>
> What are the addresses used by these ETRs ?

In your case, and will probably be the typical case, each ETR address  
will be the PA address from the provider the ETR is connected to.

If you want to throw anycast into the mix, then create a site D with 2  
ETRs, each connected to the *same* ISP. In that case, an anycast RLOC  
could be used and assigned to each ETR.

Dino


From olivier.bonaventure@uclouvain.be  Thu Apr 22 14:47:55 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C563A68DF for ; Thu, 22 Apr 2010 14:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level: 
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QSM8wgKHbMY for ; Thu, 22 Apr 2010 14:47:54 -0700 (PDT)
Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id B2E833A68C0 for ; Thu, 22 Apr 2010 14:47:53 -0700 (PDT)
Received: from mbpobo.local (bonaventure.info.ucl.ac.be [130.104.240.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 82179ECB86; Thu, 22 Apr 2010 23:47:33 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 smtp2.sgsi.ucl.ac.be 82179ECB86
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1271972853; bh=A0OnxWNYijMlRtDO07WWKR5X7DxToJw1LiWrI9RhsTo=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=0biv20LzBJVgz7ZbSWfrkxfFaF46U5moVfXVRPkJxij8eS2aLQGL4KsVnIzxNnDEr zX5e3rG+zJ5O9vhDuS7xjrNyznb/874BAccjHRbs9oEaCEICHW2kowOlUiJmSiDfqP gma0yQsTKxHj/+iusojQIe17xs5UdCKcb6DxZjNk=
Message-ID: <4BD0C3F4.7060602@uclouvain.be>
Date: Thu, 22 Apr 2010 23:47:32 +0200
From: Olivier Bonaventure 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: robert@raszuk.net
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0B7E4.8050608@raszuk.net> <201004222106.o3ML6ED35682@magenta.juniper.net> <4BD0BF7B.8050409@raszuk.net>
In-Reply-To: <4BD0BF7B.8050409@raszuk.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96-exp at smtp-2.sipr-dc.ucl.ac.be
X-Virus-Status: Clean
X-Sgsi-Spamcheck: SASL authenticated, 
X-SGSI-MailScanner-ID: 82179ECB86.00000
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] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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: Thu, 22 Apr 2010 21:47:55 -0000

Robert,
> 
>> Ok. Let me modify the text I proposed to reflect this, as follows:
>>
>>      Use of anycast addresses for resiliency in LISP results in
>>      inability to use LISP for traffic engineering among the xTRs
>>      that use the same anycast address, and specifically in inability
>>      to use LISP to influence the choice of which ETR should be used
>>      to reach a multi-homed enterprise if these ETRs use the same
>>      anycast address. In other words, when anycast addresses are
>>      used as RLOCs, LISP by itself does not provide any traffic
>>      engineering capabilities among the xTRs that use the same anycast
>>      address.
> 
> I think I could come up with much shorter paragraph still reflecting all
> from the above:
> 
> "If packets are encapsulated to a given destination address (in
> particular anycast address) one should not expect that they would end up
> in a different destination then the one listed in the destination
> address of the packet's header."

I'm not convinced that this reflects all of the above.

Anycast addresses are one of the possible solutions to provide
resiliency, but they are not the only ones. Other techniques can be used
to provide resiliency in case of failures and they do not necessarily
suffer from the same drawbacks as anycast addresses.
Given the scalability limitations of anycast address, we should probably
not recommend their utilisations as RLOCs except in environments where
scalability is not a concern.


Olivier



-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium

From robert@raszuk.net  Thu Apr 22 14:54:37 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6551B3A6A2C for ; Thu, 22 Apr 2010 14:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.859
X-Spam-Level: 
X-Spam-Status: No, score=-9.859 tagged_above=-999 required=5 tests=[AWL=0.740,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gheNaWzi47Uk for ; Thu, 22 Apr 2010 14:54:36 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 996503A688F for ; Thu, 22 Apr 2010 14:54:31 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnQFABti0EurR7Hu/2dsb2JhbACQKYwBcacemjaFDwQ
X-IronPort-AV: E=Sophos;i="4.52,259,1270425600"; d="scan'208";a="519194359"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 22 Apr 2010 21:54:21 +0000
Received: from [192.168.1.61] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3MLsKmc028713; Thu, 22 Apr 2010 21:54:21 GMT
Message-ID: <4BD0C58B.5050608@raszuk.net>
Date: Thu, 22 Apr 2010 23:54:19 +0200
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Olivier.Bonaventure@uclouvain.be
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0B7E4.8050608@raszuk.net> <201004222106.o3ML6ED35682@magenta.juniper.net> <4BD0BF7B.8050409@raszuk.net> <4BD0C3F4.7060602@uclouvain.be>
In-Reply-To: <4BD0C3F4.7060602@uclouvain.be>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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: Thu, 22 Apr 2010 21:54:37 -0000

Hi Olivier,

 > Given the scalability limitations of anycast address, we should
 > probably not recommend their utilisations as RLOCs except in
 > environments where scalability is not a concern.

I think you are 100% right. And I do not think anyone is recommending 
use of anycast addresses on ETRs across ISPs or in any other network 
location where scalability of the current system would be of any concern.

Cheers,
R.

> Robert,
>>
>>> Ok. Let me modify the text I proposed to reflect this, as follows:
>>>
>>>       Use of anycast addresses for resiliency in LISP results in
>>>       inability to use LISP for traffic engineering among the xTRs
>>>       that use the same anycast address, and specifically in inability
>>>       to use LISP to influence the choice of which ETR should be used
>>>       to reach a multi-homed enterprise if these ETRs use the same
>>>       anycast address. In other words, when anycast addresses are
>>>       used as RLOCs, LISP by itself does not provide any traffic
>>>       engineering capabilities among the xTRs that use the same anycast
>>>       address.
>>
>> I think I could come up with much shorter paragraph still reflecting all
>> from the above:
>>
>> "If packets are encapsulated to a given destination address (in
>> particular anycast address) one should not expect that they would end up
>> in a different destination then the one listed in the destination
>> address of the packet's header."
>
> I'm not convinced that this reflects all of the above.
>
> Anycast addresses are one of the possible solutions to provide
> resiliency, but they are not the only ones. Other techniques can be used
> to provide resiliency in case of failures and they do not necessarily
> suffer from the same drawbacks as anycast addresses.
> Given the scalability limitations of anycast address, we should probably
> not recommend their utilisations as RLOCs except in environments where
> scalability is not a concern.
>
>
> Olivier
>
>
>


From jnc@mercury.lcs.mit.edu  Thu Apr 22 14:55:48 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E983A699C for ; Thu, 22 Apr 2010 14:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.61
X-Spam-Level: 
X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[AWL=0.989,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBSK-KBP8c1E for ; Thu, 22 Apr 2010 14:55:47 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3A4B93A688F for ; Thu, 22 Apr 2010 14:55:47 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B45276BE567; Thu, 22 Apr 2010 17:55:36 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20100422215536.B45276BE567@mercury.lcs.mit.edu>
Date: Thu, 22 Apr 2010 17:55:36 -0400 (EDT)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 21:55:48 -0000

    > From: Yakov Rekhter 

    > Use of anycast addresses for resiliency in LISP results in inability to
    > use LISP for traffic engineering among the xTRs that use the same
    > anycast address

Yes, but the question is 'why would one be using anycast addresses in that
application anyway'? Philosophically, routing functions such as traffic
engineering requires use of 'real addresses', and use of a 'virtual address'
such as an anycast address is in direct contradiction to that.

If a site has multiple ETRs, and one fails, RLOC reachability tests will
pretty quickly (depending on the routing scope of the anycast address, and
the reachability test parameters, perhaps more quickly than the routing can
re-route) declare it down, and all correspondent ITRs would switch to using
other ITRs. That is how LISP is intended to produce resiliency to node
failures.

	Noel

From jgs@juniper.net  Thu Apr 22 14:57:21 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7983A685B for ; Thu, 22 Apr 2010 14:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.913
X-Spam-Level: 
X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ROzKWF6IQtU for ; Thu, 22 Apr 2010 14:57:20 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id C6C6B3A680D for ; Thu, 22 Apr 2010 14:57:19 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS9DGNZN49RdW1L/N9goDcDra2Q1DErbo@postini.com; Thu, 22 Apr 2010 14:57:10 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; Thu, 22 Apr 2010 14:54:50 -0700
From: John Scudder 
To: Dino Farinacci 
Date: Thu, 22 Apr 2010 14:54:48 -0700
Thread-Topic: Discussion of comment 3 (Map-Replies) [was: Re: [lisp] comments on draft-ietf-lisp-06.txt (part 1)]
Thread-Index: AcriZm52y0xCDTTnR1+dEGrBMsh2Qg==
Message-ID: 
References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>  <6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com>
In-Reply-To: <6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "lisp@ietf.org" , John E Drake 
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 21:57:21 -0000

Hi Dino,

On Apr 21, 2010, at 5:45 PM, Dino Farinacci wrote:
[...]
>>> Yes, it is stated, the ETRs should return the same contents. When I
>>=20
>> I've only read the spec a few times so I may have missed where this =20
>> is spelled out.  Would you mind citing where this is stated in the =20
>> spec?
>=20
> It is a bit implied in the following text but I will make it more =20
> clear in the -07 update.

Making it explicit would be a good start, thanks.  ("A bit implied" doesn't=
 work very well for protocol specs, but you knew that.)

[...]
>>>> - Must the locator-set be manually configured on every entity that
>>>> returns Map-Replies for that EID?
>>>=20
>>> Yes,
>>=20
>> Is that "yes" to the "must be manually configured" question?  I =20
>> would have assumed so but you go on to talk about connecting to the =20
>> ALT and such, which would appear to be an unrelated (or tangentially =20
>> related) topic.
>=20
> Yes, the database mapping must be consistently configured on all ETRs =20
> for a given LISP site.
>=20
> Can you refer to my text that refers to the ALT? Thanks.

Sure:

"Yes, we recommend each ETR either is connected directly to the ALT or
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
registers to a Map-Server, but if they do not they won't get Map-
Requests so they don't or can't send Map-Replies. We encourage all
ETRs to accept Map-Requests so the control-plane load can be balanced
across all the CPUs of the various ETRs."

>>>> - Or might it change as a reaction to the network's operational
>>>> state?
>>>> (E.g. temporary loss of reachability from a given ETR to a given
>>>> EID.)
>>>=20
>>> No,
>>=20
>> OK...
>>=20
>>> as discussed in the spec, we keep locator reachability out of the
>>> mapping database system. Thereby if a locator goes down or out of
>>> service, *it is not removed* from the locator-set.
>>=20
>> ... but note that the parenthetical question had to do with *EID* =20
>> reachability, not locator reachability.
>=20
> If an ETR cannot connect to the site, it can set its LSB bit to 0. =20
> That is if all its site-facing interfaces go down, then it should do =20
> this. Other failure cases are more complicated but typically you won't =20
> find a site completely partitioning.

(Just to be clear, "LSB bit" expands as "locator status bit bit", right?  J=
ust making sure since the term isn't defined in the spec.)

If we look at 5.3 of the LISP spec, it sez:

     When a bit is set to 1, the
     ITR is indicating to the ETR the RLOC associated with the bit
     ordinal has up status.  See Section 6.3 for details on how an ITR
     can determine other ITRs at the site are reachable.  When a site
     has multiple EID-prefixes which result in multiple mappings (where
     each could have a different locator-set), the Locator Status Bits
     setting in an encapsulated packet MUST reflect the mapping for the
     EID-prefix that the inner-header source EID address matches.

The first sentence says the semantics of the LSB is that the RLOC is up, pe=
riod.  As written, that would seem to indicate that the status given in the=
 LSB should be applied to that RLOC (i.e., the thing indexed by that IP add=
ress), no matter which EID the RLOC is being used to reach.  It seems like =
you are suggesting that instead, the ITR has to track a different notion of=
 "up status" for each (RLOC, EID) pair.  Is that right?  If so I think the =
spec should say so explicitly.

(By the way, there's also the question of what exactly the semantics of "up=
 status" are.)

Anyway, let's proceed on the assumption that we're using your revised LSB s=
emantics instead of what the spec says.  Let's take this with the aid of a =
few examples.  These all involve some variant of the site partitioning.

Example 1:
- EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks the lo=
cator-set for EID1 is {ETR1, ETR2}.
- At some particular time, ETR1 does not actually have connectivity to EID1=
 due to an intra-site problem.
- ITR1 wants to send traffic to EID1, so it performs a mapping lookup and g=
ets back {ETR1, ETR2}.
- ITR1 picks ETR1 for whatever reason.  It sends an encapsulated data packe=
t to ETR1's RLOC.
- ETR1 gets the packet.  Now what does it do?  The locator status bits whic=
h you suggest using would only be carried in return traffic since they are =
only present in the LISP data encapsulation header.  But since the forward =
traffic can't reach the destination host (remember ETR1 can't reach EID1) t=
here is no return traffic.

Example 2:
- EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks the lo=
cator-set for EID1 is {ETR1, ETR2}.
- ETR1 initially can reach EID1.
- ITR1 sends traffic to EID1 via ETR1's RLOC.  The EID1 host sends return t=
raffic.  For whatever reason, the return traffic uses ETR2 as its ITR.
- Now ETR1 loses connectivity to EID1.
- How does ETR1 tell ITR1?

Example 3:=20
(this is a variant of example 1)
- EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks the lo=
cator-set for EID1 is {ETR1, ETR2}.
- At time T1 ITR1 wants to send traffic to EID1, so it performs a mapping l=
ookup and gets back from ETR1 {ETR1, ETR2}. At this point ETR1 has connecti=
vity to EID1.
- ITR1 picks ETR1 for whatever reason, and starts sending traffic to EID1.
- At time T2 there is no more traffic to send to EID1.
- At time T3 ETR1 loses connectivity to EID1 (due to intra-site problem)
- At time T4 ITR1 again wants to send traffic to EID1, and since ITR1 has t=
he mapping, it sends traffic to ETR1.
- ETR1 gets the packet.  Now what does it do?  The locator status bits whic=
h you suggest using would only be carried in return traffic since they are =
only present in the LISP data encapsulation header. But since the forward t=
raffic can't reach the destination host (remember ETR1can't reach EID1) the=
re is no return traffic.

Example 4:
(another variant)
- EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks the lo=
cator-set for EID1 is {ETR1, ETR2}.
- At time T1 ITR1 wants to send TCP traffic to EID1, so it performs a mappi=
ng lookup and gets back from ETR1 {ETR1, ETR2}. Note that at this point ETR=
1 has connectivity to EID1.=20
- ITR1 picks ETR1 for whatever reason, and starts sending traffic to EID1. =
Note that data in the TCP stream goes to EID1, and the only thing that EID1=
 sends back are TCP acks.
- At time T2 EID1 sends TCP ACK back to the source, and at time T3 ETR1 for=
wards this TCP ACK. Immediately after that ETR1 loses connectivity to EID1 =
(due to an intra-site problem).
- At time T4 ITR1 wants to send more data on the TCP session to EID1, and s=
ince ITR1 has the mapping, it sends traffic to ETR1.
- What happens with the TCP session ? (a) When TCP KeepAlives are in use, a=
nd (b) they aren't.

Of course there is also the variant where you've got a unidirectional strea=
m from ITR1 to EID1.  It does happen.

Other interesting scenarios are possible but let's start with those. =20

> Other failure cases are more complicated but typically you won't =20
> find a site completely partitioning.

So is it the case that LISP isn't intended to cover the case where a site b=
ecomes partitioned?  If so this is a pretty important assumption and should=
 be spelled out in the spec.  Maybe in Section 8?

> We have heard though that customers *may* want to deploy VRRP/HSRP =20
> between their xTRs at a site to detect site partitioning. We believe =20
> we don't need to add LISP mechanisms to solve this.

If they detect site partitioning, what would they do then?  (This is probab=
ly partly covered by the discussion above.)

--John=

From dino@cisco.com  Thu Apr 22 15:11:47 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF7C3A6A63 for ; Thu, 22 Apr 2010 15:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.368
X-Spam-Level: 
X-Spam-Status: No, score=-9.368 tagged_above=-999 required=5 tests=[AWL=0.631,  BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y74BpcARVkbJ for ; Thu, 22 Apr 2010 15:11:45 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A69503A6951 for ; Thu, 22 Apr 2010 15:11:22 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANtl0EurR7H+/2dsb2JhbACcKnGnEJo2hQ8EgzQ
X-IronPort-AV: E=Sophos;i="4.52,259,1270425600"; d="scan'208";a="119321442"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 22 Apr 2010 22:11:12 +0000
Received: from [10.10.10.86] (sjc-vpn7-331.cisco.com [10.21.145.75]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3MMBCkR026238; Thu, 22 Apr 2010 22:11:12 GMT
Message-Id: 
From: Dino Farinacci 
To: John Scudder 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 22 Apr 2010 15:11:12 -0700
References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>  <6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com> 
X-Mailer: Apple Mail (2.936)
Cc: "lisp@ietf.org" , John E Drake 
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Apr 2010 22:11:48 -0000

> Hi Dino,
>
> On Apr 21, 2010, at 5:45 PM, Dino Farinacci wrote:
> [...]
>>>> Yes, it is stated, the ETRs should return the same contents. When I
>>>
>>> I've only read the spec a few times so I may have missed where this
>>> is spelled out.  Would you mind citing where this is stated in the
>>> spec?
>>
>> It is a bit implied in the following text but I will make it more
>> clear in the -07 update.
>
> Making it explicit would be a good start, thanks.  ("A bit implied"  
> doesn't work very well for protocol specs, but you knew that.)

You are right. You found a bug. I fixed it. I thank you.

> [...]
>>>>> - Must the locator-set be manually configured on every entity that
>>>>> returns Map-Replies for that EID?
>>>>
>>>> Yes,
>>>
>>> Is that "yes" to the "must be manually configured" question?  I
>>> would have assumed so but you go on to talk about connecting to the
>>> ALT and such, which would appear to be an unrelated (or tangentially
>>> related) topic.
>>
>> Yes, the database mapping must be consistently configured on all ETRs
>> for a given LISP site.
>>
>> Can you refer to my text that refers to the ALT? Thanks.
>
> Sure:
>
> "Yes, we recommend each ETR either is connected directly to the ALT or
>                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> registers to a Map-Server, but if they do not they won't get Map-
> Requests so they don't or can't send Map-Replies. We encourage all
> ETRs to accept Map-Requests so the control-plane load can be balanced
> across all the CPUs of the various ETRs."

All I am trying to say is if they do not register a mapping with the  
mapping system, they will not get Map-Requests. So this ETR wouldn't  
*have to be* configured consistently with the other ETRs who *are*  
processing Map-Requests. But this is a degenerate case.

>>>>> - Or might it change as a reaction to the network's operational
>>>>> state?
>>>>> (E.g. temporary loss of reachability from a given ETR to a given
>>>>> EID.)
>>>>
>>>> No,
>>>
>>> OK...
>>>
>>>> as discussed in the spec, we keep locator reachability out of the
>>>> mapping database system. Thereby if a locator goes down or out of
>>>> service, *it is not removed* from the locator-set.
>>>
>>> ... but note that the parenthetical question had to do with *EID*
>>> reachability, not locator reachability.
>>
>> If an ETR cannot connect to the site, it can set its LSB bit to 0.
>> That is if all its site-facing interfaces go down, then it should do
>> this. Other failure cases are more complicated but typically you  
>> won't
>> find a site completely partitioning.
>
> (Just to be clear, "LSB bit" expands as "locator status bit bit",  
> right?  Just making sure since the term isn't defined in the spec.)

Yes.

> If we look at 5.3 of the LISP spec, it sez:
>
>     When a bit is set to 1, the
>     ITR is indicating to the ETR the RLOC associated with the bit
>     ordinal has up status.  See Section 6.3 for details on how an ITR
>     can determine other ITRs at the site are reachable.  When a site
>     has multiple EID-prefixes which result in multiple mappings (where
>     each could have a different locator-set), the Locator Status Bits
>     setting in an encapsulated packet MUST reflect the mapping for the
>     EID-prefix that the inner-header source EID address matches.
>
> The first sentence says the semantics of the LSB is that the RLOC is  
> up, period.  As written, that would seem to indicate that the status  
> given in the LSB should be applied to that RLOC

Right, and to be clear here, "up" means the box is up and necessarily  
reachable from everywhere.

> (i.e., the thing indexed by that IP address), no matter which EID  
> the RLOC is being used to reach.  It seems like you are suggesting  
> that instead, the ITR has to track a different notion of "up status"  
> for each (RLOC, EID) pair.  Is that right?  If so I think the spec  
> should say so explicitly.

No. There is a one to many relationship. An EID-prefix maps to a  
locator-set. The reachability algorithms are used to decide which  
locator in the locator-set is reachable. There is no provision to say  
if the ETR the locator is assigned to can reach any EID in the EID- 
prefix.

> (By the way, there's also the question of what exactly the semantics  
> of "up status" are.)

Box is up and can receive control messages and get decap LISP packets.  
That is why we change it from loc-reach-bits to loc-status-bits.

> Anyway, let's proceed on the assumption that we're using your  
> revised LSB semantics instead of what the spec says.  Let's take  
> this with the aid of a few examples.  These all involve some variant  
> of the site partitioning.

No, let's not proceed.

> Example 1:
> - EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks  
> the locator-set for EID1 is {ETR1, ETR2}.
> - At some particular time, ETR1 does not actually have connectivity  
> to EID1 due to an intra-site problem.
> - ITR1 wants to send traffic to EID1, so it performs a mapping  
> lookup and gets back {ETR1, ETR2}.
> - ITR1 picks ETR1 for whatever reason.  It sends an encapsulated  
> data packet to ETR1's RLOC.
> - ETR1 gets the packet.  Now what does it do?  The locator status  
> bits which you suggest using would only be carried in return traffic  
> since they are only present in the LISP data encapsulation header.   
> But since the forward traffic can't reach the destination host  
> (remember ETR1 can't reach EID1) there is no return traffic.
>
> Example 2:
> - EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks  
> the locator-set for EID1 is {ETR1, ETR2}.
> - ETR1 initially can reach EID1.
> - ITR1 sends traffic to EID1 via ETR1's RLOC.  The EID1 host sends  
> return traffic.  For whatever reason, the return traffic uses ETR2  
> as its ITR.
> - Now ETR1 loses connectivity to EID1.
> - How does ETR1 tell ITR1?
>
> Example 3:
> (this is a variant of example 1)
> - EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks  
> the locator-set for EID1 is {ETR1, ETR2}.
> - At time T1 ITR1 wants to send traffic to EID1, so it performs a  
> mapping lookup and gets back from ETR1 {ETR1, ETR2}. At this point  
> ETR1 has connectivity to EID1.
> - ITR1 picks ETR1 for whatever reason, and starts sending traffic to  
> EID1.
> - At time T2 there is no more traffic to send to EID1.
> - At time T3 ETR1 loses connectivity to EID1 (due to intra-site  
> problem)
> - At time T4 ITR1 again wants to send traffic to EID1, and since  
> ITR1 has the mapping, it sends traffic to ETR1.
> - ETR1 gets the packet.  Now what does it do?  The locator status  
> bits which you suggest using would only be carried in return traffic  
> since they are only present in the LISP data encapsulation header.  
> But since the forward traffic can't reach the destination host  
> (remember ETR1can't reach EID1) there is no return traffic.
>
> Example 4:
> (another variant)
> - EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks  
> the locator-set for EID1 is {ETR1, ETR2}.
> - At time T1 ITR1 wants to send TCP traffic to EID1, so it performs  
> a mapping lookup and gets back from ETR1 {ETR1, ETR2}. Note that at  
> this point ETR1 has connectivity to EID1.
> - ITR1 picks ETR1 for whatever reason, and starts sending traffic to  
> EID1. Note that data in the TCP stream goes to EID1, and the only  
> thing that EID1 sends back are TCP acks.
> - At time T2 EID1 sends TCP ACK back to the source, and at time T3  
> ETR1 forwards this TCP ACK. Immediately after that ETR1 loses  
> connectivity to EID1 (due to an intra-site problem).
> - At time T4 ITR1 wants to send more data on the TCP session to  
> EID1, and since ITR1 has the mapping, it sends traffic to ETR1.
> - What happens with the TCP session ? (a) When TCP KeepAlives are in  
> use, and (b) they aren't.
>
> Of course there is also the variant where you've got a  
> unidirectional stream from ITR1 to EID1.  It does happen.
>
> Other interesting scenarios are possible but let's start with those.

All I want to say on this subject is that the EID reachability is no  
different than we have today. That is, today a router has a prefix, it  
does not indicate that every host in that prefix is reachable. So a  
packet will travel to a place in the topology where the packet will be  
dropped. Same thing when LISP is used.

The fact that the ITR could have selected another RLOC to get to the  
destination is something we are not going to solve. I'm sure you can  
see the complexity and machinery that would have to be implemented to  
do this.

>> Other failure cases are more complicated but typically you won't
>> find a site completely partitioning.
>
> So is it the case that LISP isn't intended to cover the case where a  
> site becomes partitioned?  If so this is a pretty important  
> assumption and should be spelled out in the spec.  Maybe in Section 8?

It covers the case, but can route packets on the other side of the  
partition. You could have the ETR re-encapsulate to the other side of  
the partition, but we aren't going to spec that.

>> We have heard though that customers *may* want to deploy VRRP/HSRP
>> between their xTRs at a site to detect site partitioning. We believe
>> we don't need to add LISP mechanisms to solve this.
>
> If they detect site partitioning, what would they do then?  (This is  
> probably partly covered by the discussion above.)

Left up to the implementation.

Dino



From luigi@net.t-labs.tu-berlin.de  Fri Apr 23 00:52:42 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E9F03A6872 for ; Fri, 23 Apr 2010 00:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level: 
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[AWL=0.428,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr5XJ79TEIfW for ; Fri, 23 Apr 2010 00:52:41 -0700 (PDT)
Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id B832D3A6832 for ; Fri, 23 Apr 2010 00:52:40 -0700 (PDT)
Received: from dyn116.net.t-labs.tu-berlin.de (dyn116.net.t-labs.tu-berlin.de [130.149.220.116]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id B41AE70003B8; Fri, 23 Apr 2010 09:52:28 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: multipart/alternative; boundary=Apple-Mail-20--503311429
From: Luigi Iannone 
In-Reply-To: 
Date: Fri, 23 Apr 2010 09:52:28 +0200
Message-Id: <16779CA5-C854-42AA-AF07-3D75CA41E0D7@net.t-labs.tu-berlin.de>
References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>  <6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com> 
To: John Scudder 
X-Mailer: Apple Mail (2.1078)
Cc: John E Drake , "lisp@ietf.org" 
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Apr 2010 07:52:42 -0000

--Apple-Mail-20--503311429
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

Versioning can help in those examples (see below).

But at one cost: issuing a new version number each time there is a =
status/reachability change and this is not always worth to do it.

Note that I am _not_ suggesting that the what I describe below should be =
added in the specs.
=20
Rather I think that this just an example of operational use of the =
versioning feature. (alternatively, the examples below can be included =
in the versioning draft as example of use of the versioning feature).=20



On Apr 22, 2010, at 23:54 , John Scudder wrote:

[snip]
>=20
> Anyway, let's proceed on the assumption that we're using your revised =
LSB semantics instead of what the spec says.  Let's take this with the =
aid of a few examples.  These all involve some variant of the site =
partitioning.
>=20
> Example 1:
> - EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks =
the locator-set for EID1 is {ETR1, ETR2}.
> - At some particular time, ETR1 does not actually have connectivity to =
EID1 due to an intra-site problem.
> - ITR1 wants to send traffic to EID1, so it performs a mapping lookup =
and gets back {ETR1, ETR2}.
> - ITR1 picks ETR1 for whatever reason.

You are assuming here that ITR1 get a mapping that states that ETR1 is =
able to reach EID1, but then the IGP goes down when the packets are =
actually sent. Right?

>  It sends an encapsulated data packet to ETR1's RLOC.
> - ETR1 gets the packet.  Now what does it do? =20

If the destination site has updated the version number ETR1 will SMR =
ITR1 because the encapsulated packet will carry a stale version number.=20=


> The locator status bits which you suggest using would only be carried =
in return traffic since they are only present in the LISP data =
encapsulation header.  But since the forward traffic can't reach the =
destination host (remember ETR1 can't reach EID1) there is no return =
traffic.
>=20
> Example 2:
> - EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks =
the locator-set for EID1 is {ETR1, ETR2}.
> - ETR1 initially can reach EID1.
> - ITR1 sends traffic to EID1 via ETR1's RLOC.  The EID1 host sends =
return traffic.  For whatever reason, the return traffic uses ETR2 as =
its ITR.
> - Now ETR1 loses connectivity to EID1.
> - How does ETR1 tell ITR1?

Same solution like example 1, with the small difference that most =
probably is the traffic flowing from ETR2 to ITR1 that will notify ITR1 =
that it has a stale mapping.


>=20
> Example 3:=20
> (this is a variant of example 1)
> - EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks =
the locator-set for EID1 is {ETR1, ETR2}.
> - At time T1 ITR1 wants to send traffic to EID1, so it performs a =
mapping lookup and gets back from ETR1 {ETR1, ETR2}. At this point ETR1 =
has connectivity to EID1.
> - ITR1 picks ETR1 for whatever reason, and starts sending traffic to =
EID1.
> - At time T2 there is no more traffic to send to EID1.
> - At time T3 ETR1 loses connectivity to EID1 (due to intra-site =
problem)
> - At time T4 ITR1 again wants to send traffic to EID1, and since ITR1 =
has the mapping, it sends traffic to ETR1.
> - ETR1 gets the packet.  Now what does it do?

Exactly the same case of example 1.

>  The locator status bits which you suggest using would only be carried =
in return traffic since they are only present in the LISP data =
encapsulation header. But since the forward traffic can't reach the =
destination host (remember ETR1can't reach EID1) there is no return =
traffic.
>=20
> Example 4:
> (another variant)
> - EID1 is reached via ETR1 and ETR2, i.e., the mapping system thinks =
the locator-set for EID1 is {ETR1, ETR2}.
> - At time T1 ITR1 wants to send TCP traffic to EID1, so it performs a =
mapping lookup and gets back from ETR1 {ETR1, ETR2}. Note that at this =
point ETR1 has connectivity to EID1.=20
> - ITR1 picks ETR1 for whatever reason, and starts sending traffic to =
EID1. Note that data in the TCP stream goes to EID1, and the only thing =
that EID1 sends back are TCP acks.
> - At time T2 EID1 sends TCP ACK back to the source, and at time T3 =
ETR1 forwards this TCP ACK. Immediately after that ETR1 loses =
connectivity to EID1 (due to an intra-site problem).
> - At time T4 ITR1 wants to send more data on the TCP session to EID1, =
and since ITR1 has the mapping, it sends traffic to ETR1.
> - What happens with the TCP session ?

Here you did not specify if EID1 is able to reach ETR2, because =
otherwise your TCP session is gone and there is nothing you can do (and =
this is not a problem specific to LISP)

Assuming that EID1 is able to reach ETR2 , using versioning as described =
above, you will have some packet losses (on which TCP will react as due =
to congestion) and then things will work again.

Luigi


> (a) When TCP KeepAlives are in use, and (b) they aren't.
>=20
> Of course there is also the variant where you've got a unidirectional =
stream from ITR1 to EID1.  It does happen.
>=20
> Other interesting scenarios are possible but let's start with those. =20=

>=20
>> Other failure cases are more complicated but typically you won't =20
>> find a site completely partitioning.
>=20
> So is it the case that LISP isn't intended to cover the case where a =
site becomes partitioned?  If so this is a pretty important assumption =
and should be spelled out in the spec.  Maybe in Section 8?
>=20
>> We have heard though that customers *may* want to deploy VRRP/HSRP =20=

>> between their xTRs at a site to detect site partitioning. We believe =20=

>> we don't need to add LISP mechanisms to solve this.
>=20
> If they detect site partitioning, what would they do then?  (This is =
probably partly covered by the discussion above.)
>=20
> --John
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp


--Apple-Mail-20--503311429
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



Anyway, let's proceed on the assumption =
that we're using your revised LSB semantics instead of what the spec =
says.  Let's take this with the aid of a few examples.  These =
all involve some variant of the site partitioning.

Example =
1:
- EID1 is reached via ETR1 and ETR2, i.e., the mapping system =
thinks the locator-set for EID1 is {ETR1, ETR2}.
- At some particular =
time, ETR1 does not actually have connectivity to EID1 due to an =
intra-site problem.
- ITR1 wants to send traffic to EID1, so it =
performs a mapping lookup and gets back {ETR1, ETR2}.
- ITR1 picks =
ETR1 for whatever reason. 

You are =
assuming here that ITR1 get a mapping that states that ETR1 is able to =
reach EID1, but then the IGP goes down when the packets are actually =
sent. Right?

 It sends an =
encapsulated data packet to ETR1's =
RLOC.
- ETR1 gets =
the packet.  Now what does it do? =
 

If the destination site has =
updated the version number ETR1 will SMR ITR1 because the encapsulated =
packet will carry a stale version number. 

The locator =
status bits which you suggest using would only be carried in return =
traffic since they are only present in the LISP data encapsulation =
header.  But since the forward traffic can't reach the destination =
host (remember ETR1 can't reach EID1) there is no return =
traffic.

Example 2:
- EID1 is reached via ETR1 and ETR2, i.e., =
the mapping system thinks the locator-set for EID1 is {ETR1, ETR2}.
- =
ETR1 initially can reach EID1.
- ITR1 sends traffic to EID1 via =
ETR1's RLOC.  The EID1 host sends return traffic.  For =
whatever reason, the return traffic uses ETR2 as its ITR.
- Now ETR1 =
loses connectivity to EID1.
- How does ETR1 tell =
ITR1?

Same solution like =
example 1, with the small difference that most probably is the traffic =
flowing from ETR2 to ITR1 that will notify ITR1 that it has a stale =
mapping.



Example 3: 
(this is a variant of example =
1)
- EID1 is reached via ETR1 and ETR2, i.e., the mapping system =
thinks the locator-set for EID1 is {ETR1, ETR2}.
- At time T1 ITR1 =
wants to send traffic to EID1, so it performs a mapping lookup and gets =
back from ETR1 {ETR1, ETR2}. At this point ETR1 has connectivity to =
EID1.
- ITR1 picks ETR1 for whatever reason, and starts sending =
traffic to EID1.
- At time T2 there is no more traffic to send to =
EID1.
- At time T3 ETR1 loses connectivity to EID1 (due to intra-site =
problem)
- At time T4 ITR1 again wants to send traffic to EID1, and =
since ITR1 has the mapping, it sends traffic to ETR1.
- ETR1 gets the =
packet.  Now what does it do? =


Exactly the same case of example =
1.

 The locator status bits =
which you suggest using would only be carried in return traffic since =
they are only present in the LISP data encapsulation header. But since =
the forward traffic can't reach the destination host (remember ETR1can't =
reach EID1) there is no return traffic.

Example 4:
(another =
variant)
- EID1 is reached via ETR1 and ETR2, i.e., the mapping =
system thinks the locator-set for EID1 is {ETR1, ETR2}.
- At time T1 =
ITR1 wants to send TCP traffic to EID1, so it performs a mapping lookup =
and gets back from ETR1 {ETR1, ETR2}. Note that at this point ETR1 has =
connectivity to EID1. 
- ITR1 picks ETR1 for whatever reason, and =
starts sending traffic to EID1. Note that data in the TCP stream goes to =
EID1, and the only thing that EID1 sends back are TCP acks.
- At time =
T2 EID1 sends TCP ACK back to the source, and at time T3 ETR1 forwards =
this TCP ACK. Immediately after that ETR1 loses connectivity to EID1 =
(due to an intra-site problem).
- At time T4 ITR1 wants to send more =
data on the TCP session to EID1, and since ITR1 has the mapping, it =
sends traffic to ETR1.
- What happens with the TCP session =
?

Here you did not specify if EID1 =
is able to reach ETR2, because otherwise your TCP session is gone and =
there is nothing you can do (and this is not a problem specific to =
LISP)

Assuming that EID1 is able to reach ETR2 =
, using versioning as described above, you will have some packet losses =
(on which TCP will react as due to congestion) and then things will work =
again.

Luigi


 (a) When TCP KeepAlives are in use, and (b) they =
aren't.

Of course there is also the variant where you've got a =
unidirectional stream from ITR1 to EID1.  It does =
happen.

Other interesting scenarios are possible but let's start =
with those.  

Other failure cases =
are more complicated but typically you won't =
 
find a site completely =
partitioning.

So is it the case that LISP isn't =
intended to cover the case where a site becomes partitioned?  If so =
this is a pretty important assumption and should be spelled out in the =
spec.  Maybe in Section 8?

We have =
heard though that customers *may* want to deploy VRRP/HSRP =
 
between their xTRs at a =
site to detect site partitioning. We believe =
 
we don't need to add =
LISP mechanisms to solve this.

If they detect site =
partitioning, what would they do then?  (This is probably partly =
covered by the discussion =
above.)

--John
_______________________________________________lisp mailing list
lisp@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/lisp

=

--Apple-Mail-20--503311429--

From jgs@juniper.net  Fri Apr 23 10:07:00 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641653A6955 for ; Fri, 23 Apr 2010 10:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.295
X-Spam-Level: 
X-Spam-Status: No, score=-5.295 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSF6zKHiA4DJ for ; Fri, 23 Apr 2010 10:06:57 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 87CA93A67EF for ; Fri, 23 Apr 2010 10:06:57 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKS9HTpE/5FhCtC4gS9qvaal0okKc2kB1b@postini.com; Fri, 23 Apr 2010 10:06:47 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; Fri, 23 Apr 2010 10:05:08 -0700
From: John Scudder 
To: Dino Farinacci 
Date: Fri, 23 Apr 2010 10:05:07 -0700
Thread-Topic: Discussion of comment 3 (Map-Replies) [was: Re: [lisp] comments on draft-ietf-lisp-06.txt (part 1)]
Thread-Index: AcrjByCvSBv2MK/7RiWXosbyQoN7zg==
Message-ID: <28D2235B-E40F-402C-A881-E6403398D179@juniper.net>
References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>  <6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "lisp@ietf.org" , John E Drake 
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Apr 2010 17:07:00 -0000

On Apr 22, 2010, at 6:11 PM, Dino Farinacci wrote:
[...]
>>>>>> - Must the locator-set be manually configured on every entity that
>>>>>> returns Map-Replies for that EID?
>>>>>=20
>>>>> Yes,
>>>>=20
>>>> Is that "yes" to the "must be manually configured" question?  I
>>>> would have assumed so but you go on to talk about connecting to the
>>>> ALT and such, which would appear to be an unrelated (or tangentially
>>>> related) topic.
>>>=20
>>> Yes, the database mapping must be consistently configured on all ETRs
>>> for a given LISP site.
>>>=20
>>> Can you refer to my text that refers to the ALT? Thanks.
>>=20
>> Sure:
>>=20
>> "Yes, we recommend each ETR either is connected directly to the ALT or
>>                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> registers to a Map-Server, but if they do not they won't get Map-
>> Requests so they don't or can't send Map-Replies. We encourage all
>> ETRs to accept Map-Requests so the control-plane load can be balanced
>> across all the CPUs of the various ETRs."
>=20
> All I am trying to say is if they do not register a mapping with the =20
> mapping system, they will not get Map-Requests. So this ETR wouldn't =20
> *have to be* configured consistently with the other ETRs who *are* =20
> processing Map-Requests. But this is a degenerate case.

OK.  Although, even if they don't send Map-Replies wouldn't they have to be=
 consistent with the other ETRs in order to produce correctly formatted loc=
ator status bits?  Which would still require them to be configured consiste=
ntly?

>>>>>> - Or might it change as a reaction to the network's operational
>>>>>> state?
>>>>>> (E.g. temporary loss of reachability from a given ETR to a given
>>>>>> EID.)
>>>>>=20
>>>>> No,
>>>>=20
>>>> OK...
>>>>=20
>>>>> as discussed in the spec, we keep locator reachability out of the
>>>>> mapping database system. Thereby if a locator goes down or out of
>>>>> service, *it is not removed* from the locator-set.
>>>>=20
>>>> ... but note that the parenthetical question had to do with *EID*
>>>> reachability, not locator reachability.
>>>=20
>>> If an ETR cannot connect to the site, it can set its LSB bit to 0.
>>> That is if all its site-facing interfaces go down, then it should do
>>> this. Other failure cases are more complicated but typically you =20
>>> won't
>>> find a site completely partitioning.
>>=20
>> (Just to be clear, "LSB bit" expands as "locator status bit bit", =20
>> right?  Just making sure since the term isn't defined in the spec.)
>=20
> Yes.
>=20
>> If we look at 5.3 of the LISP spec, it sez:
>>=20
>>   When a bit is set to 1, the
>>   ITR is indicating to the ETR the RLOC associated with the bit
>>   ordinal has up status.  See Section 6.3 for details on how an ITR
>>   can determine other ITRs at the site are reachable.  When a site
>>   has multiple EID-prefixes which result in multiple mappings (where
>>   each could have a different locator-set), the Locator Status Bits
>>   setting in an encapsulated packet MUST reflect the mapping for the
>>   EID-prefix that the inner-header source EID address matches.
>>=20
>> The first sentence says the semantics of the LSB is that the RLOC is =20
>> up, period.  As written, that would seem to indicate that the status =20
>> given in the LSB should be applied to that RLOC
>=20
> Right, and to be clear here, "up" means the box is up and necessarily =20
> reachable from everywhere.

Did you mean "*not* necessarily"?

>> (i.e., the thing indexed by that IP address), no matter which EID =20
>> the RLOC is being used to reach.  It seems like you are suggesting =20
>> that instead, the ITR has to track a different notion of "up status" =20
>> for each (RLOC, EID) pair.  Is that right?  If so I think the spec =20
>> should say so explicitly.
>=20
> No. There is a one to many relationship. An EID-prefix maps to a =20
> locator-set. The reachability algorithms are used to decide which =20
> locator in the locator-set is reachable. There is no provision to say =20
> if the ETR the locator is assigned to can reach any EID in the EID-=20
> prefix.

I see.

So all you were trying to say by this:

>>> If an ETR cannot connect to the site, it can set its LSB bit to 0.
>>> That is if all its site-facing interfaces go down, then it should do
>>> this. Other failure cases are more complicated but typically you =20
>>> won't
>>> find a site completely partitioning.

was that if an ETR can't connect to *any* of the EID prefixes it serves, th=
en it can set its LSB to zero.  Is that right?  BTW, the concept of 'site' =
isn't clearly defined in the spec, so I would prefer to discuss this in ter=
ms of EIDs instead of 'sites'.  I suggest you do too, or provide a clear de=
finition of 'site'.

(Although as the examples you didn't want to discuss pointed out, there is =
a problem with this too, which is that the LSB is carried in return data tr=
affic... which will not exist if there is no connectivity to any EID prefix=
, or in various other cases.)

>> (By the way, there's also the question of what exactly the semantics =20
>> of "up status" are.)
>=20
> Box is up and can receive control messages and get decap LISP packets. =20

This should be stated in the spec.  Also, shouldn't the full statement be m=
ore like 'Box is up and can receive and process control messages and LISP p=
ackets.'? Either way, if these are the semantics of the LSB (either what yo=
u wrote, or the revision I suggested), how should one xTR determine the sta=
tus of another so that it can reflect it in the LSB?  In order for the loca=
tor status bits field to work, the various xTRs in a locator set do need to=
 determine each other's status.  'Receive and process' is more challenging =
for a remote xTR to determine than 'is the remote xTR reachable' which is w=
hat I used to think the LSB meant.

> All I want to say on this subject is that the EID reachability is no =20
> different than we have today.

I'm not interested (at this point) in comparing LISP to current routing.  I=
'm just trying to nail down what LISP's *own* characteristics are.  Only on=
ce that is done can there be meaningful comparison.  You may think you know=
 exactly what LISP's characteristics are in this respect, but it's not evid=
ent from the spec, hence these questions.  We do seem to be making progress=
 on answering the question of what LISP's characteristics are.

(As to the assertion above, suffice it to say that I think it's debatable, =
but I don't want to debate it right now since I think it's premature.)

> That is, today a router has a prefix, it =20
> does not indicate that every host in that prefix is reachable. So a =20
> packet will travel to a place in the topology where the packet will be =20
> dropped. Same thing when LISP is used.
>=20
> The fact that the ITR could have selected another RLOC to get to the =20
> destination is something we are not going to solve. I'm sure you can =20
> see the complexity and machinery that would have to be implemented to =20
> do this.
>=20
>>> Other failure cases are more complicated but typically you won't
>>> find a site completely partitioning.
>>=20
>> So is it the case that LISP isn't intended to cover the case where a =20
>> site becomes partitioned?  If so this is a pretty important =20
>> assumption and should be spelled out in the spec.  Maybe in Section 8?
>=20
> It covers the case, but can route packets on the other side of the =20
> partition. You could have the ETR re-encapsulate to the other side of =20
> the partition, but we aren't going to spec that.

Even if "we aren't going to spec that", at a minimum the spec ought to poin=
t out that this limitation exists and that solutions are considered out-of-=
scope.  Something like this:

"Section X.Y  Site Partition

"A site may be multihomed using two or more ETRs.  The hosts and infrastruc=
ture within a site will be addressed using one or more EID prefixes that ar=
e mapped to the RLOCs of the relevant ETRs in the mapping system.  One poss=
ible failure mode of such a deployment is for an ETR to lose reachability t=
o one or more of the EID prefixes.  This architecture does not provide a so=
lution for data to be reliably delivered to hosts within the site in this s=
cenario; provision of such a solution is beyond the scope of this document.=
"

--John=

From jnc@mercury.lcs.mit.edu  Fri Apr 23 12:32:30 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA8A3A6ACF for ; Fri, 23 Apr 2010 12:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.393
X-Spam-Level: 
X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wnsiko5y6MOc for ; Fri, 23 Apr 2010 12:32:25 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B440F3A6ACA for ; Fri, 23 Apr 2010 12:32:25 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E34EE6BE571; Fri, 23 Apr 2010 15:32:13 -0400 (EDT)
To: jgs@juniper.net, lisp@ietf.org
Message-Id: <20100423193213.E34EE6BE571@mercury.lcs.mit.edu>
Date: Fri, 23 Apr 2010 15:32:13 -0400 (EDT)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jdrake@juniper.net, jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Apr 2010 19:32:30 -0000

    > From: John Scudder 

    >> to be clear here, "up" means the box is up and necessarily reachable
    >> from everywhere.

    > Did you mean "*not* necessarily"?

Perhaps - and that's why we differentiate between 'up' (which is
node-specific) and 'reachable' (which applies to a {source, destination}
pair), and why there are mechanisms specifically to test reachability.

Instances have actually been seen in which an ITR/ETR pair were up, and the
routing tables _claimed_ one should be able to get packets from the ITR to
the ETR, but in which various access-control/etc settings prevented packets
from flowing.


    > the concept of 'site' isn't clearly defined in the spec, so I would
    > prefer to discuss this in terms of EIDs instead of 'sites'. 

I get a little antsy using 'EIDs' like that, because an EID is just a _name_,
and one doesn't talk to a name, one talks to the thing the EID names.

But I agree 'site' could be more clearly defined, as 'the collection of end
hosts and associated communication infrastructure named by the EID ranges
advertised by an ETR', or something like that.


    > the LSB is carried in return data traffic... which will not exist if
    > there is no connectivity to any EID prefix, or in various other cases.

The whole up/reachable status thing (above) consists of a number of somewhat
overlapping mechanisms, which did not all arrive at the same time. LSB's are
the oldest one, and one I am not particularly wild about, but anyway...
There's this concept that while none by themselves are 'perfect', and that a
'perfect' mechanism (along speed and robustness axes) would be too expensive,
the collection of them 'tile' the problem-space 'well enough'.

The thing about a lot of the mechanisms that are piggybacked on user traffic
is that there is tradeoff one has to live with in any overlay system such as
LISP, which is that the fan-out at any individual node can be really large
(since you can have neighbours anywhere on the network, not just locally),
and if one uses explicit control traffic for such functions, overhead can
really add up. Piggybacking reduces the overhead, but then you get the 'what
if there is no user traffic' thing. With luck, the control is going the same
direction as the user traffic (e.g. in mapping versioning), and then if
there's no user traffic, it doesn't matter. LSB, alas, goes in the other
direction, so if there's unidirectional traffic it can be an issue, but at
that point other mechanisms in the 'up/reachable' group can backstop.


    > at a minimum the spec ought to point out that this limitation exists a
    > and that solutions are considered out-of-scope. Something like this:

'currently out of scope'... This is the Experimental protocol, not the
Proposed Standard... :-)

    > "This architecture does not provide a solution for data to be reliably
    > delivered to hosts within the site in this scenario; provision of such
    > a solution is beyond the scope of this document."

Make it "not currently provide" and I at least would be OK with that.

	Noel

From darlewis@cisco.com  Fri Apr 23 13:33:03 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0303A6844 for ; Fri, 23 Apr 2010 13:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDdpn7fTvxpe for ; Fri, 23 Apr 2010 13:33:02 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CF57C3A67D9 for ; Fri, 23 Apr 2010 13:33:02 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,263,1270425600"; d="scan'208";a="119796125"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Apr 2010 20:32:52 +0000
Received: from dhcp-171-70-225-72.cisco.com (dhcp-171-70-225-72.cisco.com [171.70.225.72]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3NKWqg6017179; Fri, 23 Apr 2010 20:32:52 GMT
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Darrel Lewis 
In-Reply-To: <28D2235B-E40F-402C-A881-E6403398D179@juniper.net>
Date: Fri, 23 Apr 2010 13:32:55 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>  <6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com>   <28D2235B-E40F-402C-A881-E6403398D179@juniper.net>
To: John Scudder 
X-Mailer: Apple Mail (2.1078)
Cc: "lisp@ietf.org" , John E Drake 
Subject: Re: [lisp] LISP Site definition
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Apr 2010 20:33:03 -0000

>   I suggest you do too, or provide a clear definition of 'site'.
>=20

I agree and suggest that it would be good to add "LISP Site" to the =
Definition of Terms section of the document.=20

How about:

LISP site:  A set of routers in an edge network that is under =
administrative
            control by a single organization.  LISP routers which reside =
in the
            edge network are the demarcation points to separate the edge =
network
            from the core network.

-Darrel


From scott.brim@gmail.com  Fri Apr 23 13:56:57 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E2F3A6934 for ; Fri, 23 Apr 2010 13:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl5W27ZkVcnt for ; Fri, 23 Apr 2010 13:56:56 -0700 (PDT)
Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 688503A68AF for ; Fri, 23 Apr 2010 13:56:55 -0700 (PDT)
Received: by qyk11 with SMTP id 11so11978283qyk.13 for ; Fri, 23 Apr 2010 13:56:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=BxmoCrLZ9G7GU5BG2xhVbD2l4PVtmO9xTlcyZDUXIVQ=; b=HqDjxoVgbRTiUV2wK+kvn2qK43m2H1D0GegTsdCf/4DrLoZX7S6S6HTsHeNUJYEWhV 1v9ngUpenycTcNScnqiOVjtigJM4O5FcjgXIpupNsfqHv3/7EiBlAnFe/3Li/xmqD4kX S5UgD9BserIdbinfRTvWdvLlAHCtqLb7Ch1XI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=m+ecdmInNNIZx4+CjgoGDxb//so/Nt64XTE5y2j+vQevAqOI0HbL7jAuOFSokHfgn4 3xltL5Mn6k8V7OkfF+jqXD0DqwesMMRa3aFnxyPxYIGB4aLj+sC0OuIcerRazHm28Dk3 FKudR17f7Nqn/aT4P6fiFSlY4tn4wnOCjcRBk=
Received: by 10.229.192.7 with SMTP id do7mr697715qcb.71.1272056196353; Fri, 23 Apr 2010 13:56:36 -0700 (PDT)
Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id v26sm808862qce.1.2010.04.23.13.56.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Apr 2010 13:56:35 -0700 (PDT)
Message-ID: <4BD20980.6030808@gmail.com>
Date: Fri, 23 Apr 2010 16:56:32 -0400
From: Scott Brim 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Darrel Lewis 
References: <201004192048.o3JKmZD69911@magenta.juniper.net>	<66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>		<6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com>			<28D2235B-E40F-402C-A881-E6403398D179@juniper.net> 
In-Reply-To: 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "lisp@ietf.org" , John E Drake 
Subject: Re: [lisp] LISP Site definition
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Apr 2010 20:56:57 -0000

Darrel Lewis allegedly wrote on 04/23/2010 16:32 EDT:
> 
>>   I suggest you do too, or provide a clear definition of 'site'.
>>
> 
> I agree and suggest that it would be good to add "LISP Site" to the Definition of Terms section of the document. 
> 
> How about:
> 
> LISP site:  A set of routers in an edge network that is under administrative
>             control by a single organization.  LISP routers which reside in the
>             edge network are the demarcation points to separate the edge network
>             from the core network.
> 
> -Darrel

Why under control of a single organization?  All that's needed is that
they act in concert.  I would just require the minimum.

Scott

From dino@cisco.com  Fri Apr 23 15:12:01 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D043A6856 for ; Fri, 23 Apr 2010 15:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsY+sKQbXtdm for ; Fri, 23 Apr 2010 15:11:59 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4524D3A6949 for ; Fri, 23 Apr 2010 15:11:58 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,264,1270425600"; d="scan'208";a="187639836"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 23 Apr 2010 22:11:47 +0000
Received: from dhcp-171-70-225-105.cisco.com (dhcp-171-70-225-105.cisco.com [171.70.225.105]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3NMBT20024008; Fri, 23 Apr 2010 22:11:47 GMT
Message-Id: <2A7F95A9-B62D-47B3-8869-98AA40051249@cisco.com>
From: Dino Farinacci 
To: Scott Brim 
In-Reply-To: <4BD20980.6030808@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 23 Apr 2010 15:11:46 -0700
References: <201004192048.o3JKmZD69911@magenta.juniper.net>	<66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>		<6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com>			<28D2235B-E40F-402C-A881-E6403398D179@juniper.net>  <4BD20980.6030808@gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: "lisp@ietf.org" , John E Drake 
Subject: Re: [lisp] LISP Site definition
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Apr 2010 22:12:01 -0000

> Darrel Lewis allegedly wrote on 04/23/2010 16:32 EDT:
>>
>>>  I suggest you do too, or provide a clear definition of 'site'.
>>>
>>
>> I agree and suggest that it would be good to add "LISP Site" to the  
>> Definition of Terms section of the document.
>>
>> How about:
>>
>> LISP site:  A set of routers in an edge network that is under  
>> administrative
>>            control by a single organization.  LISP routers which  
>> reside in the
>>            edge network are the demarcation points to separate the  
>> edge network
>>            from the core network.
>>
>> -Darrel
>
> Why under control of a single organization?  All that's needed is that
> they act in concert.  I would just require the minimum.

Because that is how an IGP based AS is defined to today. We are not  
changing that.

Dino

>
> Scott
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp


From scott.brim@gmail.com  Fri Apr 23 17:32:04 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAF73A677C for ; Fri, 23 Apr 2010 17:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EO1JQR03f+Oj for ; Fri, 23 Apr 2010 17:32:03 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 149813A6781 for ; Fri, 23 Apr 2010 17:32:02 -0700 (PDT)
Received: by vws13 with SMTP id 13so125485vws.31 for ; Fri, 23 Apr 2010 17:31:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=hwBPi/yDm7fizLUk/Vt7Qj88Ik4TnkWbl3Is5d6JMkg=; b=ZBayERfczaLfcUl4UTQqFNIeAddXx2a4vYWOFmUEEJUBr4Y7Gux6YXH4J2jqxURhoP D8mdjhBxAq9xD1sogBkYZLPjT5azRDZYgB/pc9nV7UkXZ9wuMaDIggfg76ADgobwL+dw XikK9TGGboI4uhwrdHED+WUIo6OODknYmJFbE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Oo8qa3WJD9pjfx/oHxW2HaHp1qRBX6sObSYfAXEcSNiFsgI2CF25urfZ7UVPKxS2Dv SZ60W+FJ57dSnwkAqVRdUR5100GeGGnpasu4V5D9MARGtERdL0oc/MReULvw9LxZwSDp 7ENqOWbUXb6ERGV1ZXl7LcC5DA2rTR7OOkx5s=
Received: by 10.220.128.37 with SMTP id i37mr573861vcs.50.1272069109448; Fri, 23 Apr 2010 17:31:49 -0700 (PDT)
Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id i29sm7357491vcr.12.2010.04.23.17.31.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Apr 2010 17:31:48 -0700 (PDT)
Message-ID: <4BD23BF1.9070604@gmail.com>
Date: Fri, 23 Apr 2010 20:31:45 -0400
From: Scott Brim 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Dino Farinacci 
References: <201004192048.o3JKmZD69911@magenta.juniper.net>	<66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>		<6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com>			<28D2235B-E40F-402C-A881-E6403398D179@juniper.net>  <4BD20980.6030808@gmail.com> <2A7F95A9-B62D-47B3-8869-98AA40051249@cisco.com>
In-Reply-To: <2A7F95A9-B62D-47B3-8869-98AA40051249@cisco.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "lisp@ietf.org" , John E Drake 
Subject: Re: [lisp] LISP Site definition
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Apr 2010 00:32:04 -0000

Dino Farinacci allegedly wrote on 04/23/2010 18:11 EDT:
>> Why under control of a single organization?  All that's needed is that
>> they act in concert.  I would just require the minimum.
> 
> Because that is how an IGP based AS is defined to today. We are not
> changing that.

OK so the issue is they need to be connected by an IGP.

From dino@cisco.com  Fri Apr 23 19:06:08 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276823A67C0 for ; Fri, 23 Apr 2010 19:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPfA8xpSYUpi for ; Fri, 23 Apr 2010 19:06:06 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4FB083A67A6 for ; Fri, 23 Apr 2010 19:06:06 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAG7u0UurRN+J/2dsb2JhbACcL3GhdZlKhQsEgzc
X-IronPort-AV: E=Sophos;i="4.52,265,1270425600"; d="scan'208";a="119930256"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Apr 2010 02:05:55 +0000
Received: from [10.34.153.107] ([10.34.153.107]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3O25tFH020312; Sat, 24 Apr 2010 02:05:55 GMT
Message-Id: 
From: Dino Farinacci 
To: John Scudder 
In-Reply-To: <28D2235B-E40F-402C-A881-E6403398D179@juniper.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 23 Apr 2010 19:05:55 -0700
References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>  <6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com>   <28D2235B-E40F-402C-A881-E6403398D179@juniper.net>
X-Mailer: Apple Mail (2.936)
Cc: "lisp@ietf.org" , John E Drake 
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Apr 2010 02:06:08 -0000

> On Apr 22, 2010, at 6:11 PM, Dino Farinacci wrote:
> [...]
>>>>>>> - Must the locator-set be manually configured on every entity  
>>>>>>> that
>>>>>>> returns Map-Replies for that EID?
>>>>>>
>>>>>> Yes,
>>>>>
>>>>> Is that "yes" to the "must be manually configured" question?  I
>>>>> would have assumed so but you go on to talk about connecting to  
>>>>> the
>>>>> ALT and such, which would appear to be an unrelated (or  
>>>>> tangentially
>>>>> related) topic.
>>>>
>>>> Yes, the database mapping must be consistently configured on all  
>>>> ETRs
>>>> for a given LISP site.
>>>>
>>>> Can you refer to my text that refers to the ALT? Thanks.
>>>
>>> Sure:
>>>
>>> "Yes, we recommend each ETR either is connected directly to the  
>>> ALT or
>>>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> registers to a Map-Server, but if they do not they won't get Map-
>>> Requests so they don't or can't send Map-Replies. We encourage all
>>> ETRs to accept Map-Requests so the control-plane load can be  
>>> balanced
>>> across all the CPUs of the various ETRs."
>>
>> All I am trying to say is if they do not register a mapping with the
>> mapping system, they will not get Map-Requests. So this ETR wouldn't
>> *have to be* configured consistently with the other ETRs who *are*
>> processing Map-Requests. But this is a degenerate case.
>
> OK.  Although, even if they don't send Map-Replies wouldn't they  
> have to be consistent with the other ETRs in order to produce  
> correctly formatted locator status bits?  Which would still require  
> them to be configured consistently?

Yes, if they are also ITRs and set the L-bit to 1 in data packets.

>>>>>>> - Or might it change as a reaction to the network's operational
>>>>>>> state?
>>>>>>> (E.g. temporary loss of reachability from a given ETR to a given
>>>>>>> EID.)
>>>>>>
>>>>>> No,
>>>>>
>>>>> OK...
>>>>>
>>>>>> as discussed in the spec, we keep locator reachability out of the
>>>>>> mapping database system. Thereby if a locator goes down or out of
>>>>>> service, *it is not removed* from the locator-set.
>>>>>
>>>>> ... but note that the parenthetical question had to do with *EID*
>>>>> reachability, not locator reachability.
>>>>
>>>> If an ETR cannot connect to the site, it can set its LSB bit to 0.
>>>> That is if all its site-facing interfaces go down, then it should  
>>>> do
>>>> this. Other failure cases are more complicated but typically you
>>>> won't
>>>> find a site completely partitioning.
>>>
>>> (Just to be clear, "LSB bit" expands as "locator status bit bit",
>>> right?  Just making sure since the term isn't defined in the spec.)
>>
>> Yes.
>>
>>> If we look at 5.3 of the LISP spec, it sez:
>>>
>>>  When a bit is set to 1, the
>>>  ITR is indicating to the ETR the RLOC associated with the bit
>>>  ordinal has up status.  See Section 6.3 for details on how an ITR
>>>  can determine other ITRs at the site are reachable.  When a site
>>>  has multiple EID-prefixes which result in multiple mappings (where
>>>  each could have a different locator-set), the Locator Status Bits
>>>  setting in an encapsulated packet MUST reflect the mapping for the
>>>  EID-prefix that the inner-header source EID address matches.
>>>
>>> The first sentence says the semantics of the LSB is that the RLOC is
>>> up, period.  As written, that would seem to indicate that the status
>>> given in the LSB should be applied to that RLOC
>>
>> Right, and to be clear here, "up" means the box is up and necessarily
>> reachable from everywhere.
>
> Did you mean "*not* necessarily"?

Yes, typo. Sorry.

>
>>> (i.e., the thing indexed by that IP address), no matter which EID
>>> the RLOC is being used to reach.  It seems like you are suggesting
>>> that instead, the ITR has to track a different notion of "up status"
>>> for each (RLOC, EID) pair.  Is that right?  If so I think the spec
>>> should say so explicitly.
>>
>> No. There is a one to many relationship. An EID-prefix maps to a
>> locator-set. The reachability algorithms are used to decide which
>> locator in the locator-set is reachable. There is no provision to say
>> if the ETR the locator is assigned to can reach any EID in the EID-
>> prefix.
>
> I see.
>
> So all you were trying to say by this:
>
>>>> If an ETR cannot connect to the site, it can set its LSB bit to 0.
>>>> That is if all its site-facing interfaces go down, then it should  
>>>> do
>>>> this. Other failure cases are more complicated but typically you
>>>> won't
>>>> find a site completely partitioning.
>
> was that if an ETR can't connect to *any* of the EID prefixes it  
> serves, then it can set its LSB to zero.  Is that right?  BTW, the  
> concept of 'site' isn't clearly defined in the spec, so I would  
> prefer to discuss this in terms of EIDs instead of 'sites'.  I  
> suggest you do too, or provide a clear definition of 'site'.

Right, we put a definition in the -07 Definition of Terms section.

> (Although as the examples you didn't want to discuss pointed out,  
> there is a problem with this too, which is that the LSB is carried  
> in return data traffic... which will not exist if there is no  
> connectivity to any EID prefix, or in various other cases.)

Let me remind you that we say the LSBs are hints. There are specific  
applications where they are useful.

>>> (By the way, there's also the question of what exactly the semantics
>>> of "up status" are.)
>>
>> Box is up and can receive control messages and get decap LISP  
>> packets.
>
> This should be stated in the spec.  Also, shouldn't the full  
> statement be more like 'Box is up and can receive and process  
> control messages and LISP packets.'? Either way, if these are the  
> semantics of the LSB (either what you wrote, or the revision I  
> suggested), how should one xTR determine the status of another so  
> that it can reflect it in the LSB?  In order for the locator

 From the IGP.

> status bits field to work, the various xTRs in a locator set do need  
> to determine each other's status.  'Receive and process' is more  
> challenging for a remote xTR to determine than 'is the remote xTR  
> reachable' which is what I used to think the LSB meant.
>
>> All I want to say on this subject is that the EID reachability is no
>> different than we have today.
>
> I'm not interested (at this point) in comparing LISP to current  
> routing.  I'm just trying to nail down what LISP's *own*  
> characteristics are.  Only once that is done can there be meaningful  
> comparison.  You may think you know exactly what LISP's  
> characteristics are in this respect, but it's not evident from the  
> spec, hence these questions.  We do seem to be making progress on  
> answering the question of what LISP's characteristics are.

Sure, understand. We have been improving the spec over the last 3  
years and continue to doing so.

> (As to the assertion above, suffice it to say that I think it's  
> debatable, but I don't want to debate it right now since I think  
> it's premature.)

Fair enough.

>> That is, today a router has a prefix, it
>> does not indicate that every host in that prefix is reachable. So a
>> packet will travel to a place in the topology where the packet will  
>> be
>> dropped. Same thing when LISP is used.
>>
>> The fact that the ITR could have selected another RLOC to get to the
>> destination is something we are not going to solve. I'm sure you can
>> see the complexity and machinery that would have to be implemented to
>> do this.
>>
>>>> Other failure cases are more complicated but typically you won't
>>>> find a site completely partitioning.
>>>
>>> So is it the case that LISP isn't intended to cover the case where a
>>> site becomes partitioned?  If so this is a pretty important
>>> assumption and should be spelled out in the spec.  Maybe in  
>>> Section 8?
>>
>> It covers the case, but can route packets on the other side of the
>> partition. You could have the ETR re-encapsulate to the other side of
>> the partition, but we aren't going to spec that.
>
> Even if "we aren't going to spec that", at a minimum the spec ought  
> to point out that this limitation exists and that solutions are  
> considered out-of-scope.  Something like this:
>
> "Section X.Y  Site Partition
>
> "A site may be multihomed using two or more ETRs.  The hosts and  
> infrastructure within a site will be addressed using one or more EID  
> prefixes that are mapped to the RLOCs of the relevant ETRs in the  
> mapping system.  One possible failure mode of such a deployment is  
> for an ETR to lose reachability to one or more of the EID prefixes.   
> This architecture does not provide a solution for data to be  
> reliably delivered to hosts within the site in this scenario;  
> provision of such a solution is beyond the scope of this document."

Noted. We will include this in the -08 revision.

Thanks again,
Dino


From jgs@juniper.net  Fri Apr 23 19:09:36 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935723A67B5 for ; Fri, 23 Apr 2010 19:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.162
X-Spam-Level: 
X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.437,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjRsQjQX+BS4 for ; Fri, 23 Apr 2010 19:09:35 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id D8FE53A67A6 for ; Fri, 23 Apr 2010 19:09:34 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKS9JS0vDcj4daOIiH3gf35TgJvNfH3BK/@postini.com; Fri, 23 Apr 2010 19:09:24 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; Fri, 23 Apr 2010 12:51:18 -0700
From: John Scudder 
To: Noel Chiappa 
Date: Fri, 23 Apr 2010 12:51:16 -0700
Thread-Topic: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
Thread-Index: AcrjHlauJPii+remSCS+QWJeMdDKMQ==
Message-ID: <6B7A4440-1D47-40F9-8FF2-728EF7D62AAB@juniper.net>
References: <20100423193213.E34EE6BE571@mercury.lcs.mit.edu>
In-Reply-To: <20100423193213.E34EE6BE571@mercury.lcs.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: John E Drake , "lisp@ietf.org" 
Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Apr 2010 02:09:36 -0000

On Apr 23, 2010, at 3:32 PM, Noel Chiappa wrote:
>> From: John Scudder 
>=20
>>> to be clear here, "up" means the box is up and necessarily reachable
>>> from everywhere.
>=20
>> Did you mean "*not* necessarily"?
>=20
> Perhaps - and that's why we differentiate between 'up' (which is
> node-specific) and 'reachable' (which applies to a {source, destination}
> pair), and why there are mechanisms specifically to test reachability.
>=20
> Instances have actually been seen in which an ITR/ETR pair were up, and t=
he
> routing tables _claimed_ one should be able to get packets from the ITR t=
o
> the ETR, but in which various access-control/etc settings prevented packe=
ts
> from flowing.

Sure, hence the question.

>> the concept of 'site' isn't clearly defined in the spec, so I would
>> prefer to discuss this in terms of EIDs instead of 'sites'.=20
>=20
> I get a little antsy using 'EIDs' like that, because an EID is just a _na=
me_,
> and one doesn't talk to a name, one talks to the thing the EID names.
>=20
> But I agree 'site' could be more clearly defined, as 'the collection of e=
nd
> hosts and associated communication infrastructure named by the EID ranges
> advertised by an ETR', or something like that.

I'll use whatever term you like as long as it's clearly defined.

>> the LSB is carried in return data traffic... which will not exist if
>> there is no connectivity to any EID prefix, or in various other cases.
>=20
> The whole up/reachable status thing (above) consists of a number of somew=
hat
> overlapping mechanisms, which did not all arrive at the same time. LSB's =
are
> the oldest one, and one I am not particularly wild about, but anyway...
> There's this concept that while none by themselves are 'perfect', and tha=
t a
> 'perfect' mechanism (along speed and robustness axes) would be too expens=
ive,
> the collection of them 'tile' the problem-space 'well enough'.
>=20
> The thing about a lot of the mechanisms that are piggybacked on user traf=
fic
> is that there is tradeoff one has to live with in any overlay system such=
 as
> LISP, which is that the fan-out at any individual node can be really larg=
e
> (since you can have neighbours anywhere on the network, not just locally)=
,
> and if one uses explicit control traffic for such functions, overhead can
> really add up. Piggybacking reduces the overhead, but then you get the 'w=
hat
> if there is no user traffic' thing. With luck, the control is going the s=
ame
> direction as the user traffic (e.g. in mapping versioning), and then if
> there's no user traffic, it doesn't matter. LSB, alas, goes in the other
> direction, so if there's unidirectional traffic it can be an issue, but a=
t
> that point other mechanisms in the 'up/reachable' group can backstop.

Unidirectional traffic as such is one problem.  Another is noncongruent for=
ward/return paths, which make traffic appear unidirectional even though it'=
s not from the host-host perspective.  Another is the class of problems ide=
ntified earlier in the thread, where you don't have a complete path in the =
forward direction, and hence don't ever get enough of a transaction to prod=
uce return traffic.  (Yes these all are "unidirectional traffic" when viewe=
d through the right lens.)

>> at a minimum the spec ought to point out that this limitation exists a
>> and that solutions are considered out-of-scope. Something like this:
>=20
> 'currently out of scope'... This is the Experimental protocol, not the
> Proposed Standard... :-)
>=20
>> "This architecture does not provide a solution for data to be reliably
>> delivered to hosts within the site in this scenario; provision of such
>> a solution is beyond the scope of this document."
>=20
> Make it "not currently provide" and I at least would be OK with that.

If you like it better that way it's OK:

"This architecture does not currently provide a solution for data to be rel=
iably delivered to hosts within the site in this scenario; provision of suc=
h a solution is beyond the scope of this document."

--John=

From darlewis@cisco.com  Sat Apr 24 17:42:31 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272DE3A6765 for ; Sat, 24 Apr 2010 17:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IReBonxiBxt for ; Sat, 24 Apr 2010 17:42:30 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2D94E3A682F for ; Sat, 24 Apr 2010 17:42:29 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: rfcdiff-lisp-06-to-07.html, draft-ietf-lisp-07.txt : 202192, 184026
X-IronPort-AV: E=Sophos;i="4.52,268,1270425600";  d="txt'?html'217?scan'217,208,217";a="120163223"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 25 Apr 2010 00:42:12 +0000
Received: from sjc-vpn3-637.cisco.com (sjc-vpn3-637.cisco.com [10.21.66.125]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3P0gBJu000917;  Sun, 25 Apr 2010 00:42:11 GMT
From: Darrel Lewis 
Content-Type: multipart/mixed; boundary=Apple-Mail-20--356320157
Date: Sat, 24 Apr 2010 17:42:19 -0700
Message-Id: 
To: lisp@ietf.org
Mime-Version: 1.0 (Apple Message framework v1078)
X-Mailer: Apple Mail (2.1078)
Subject: [lisp] draft-ietf-lisp-07.txt ready to post
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Apr 2010 00:42:31 -0000

--Apple-Mail-20--356320157
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

All,

I've attached an updated diff and text with the changes based on the =
review comments received over the last couple of days.

To review, the three main substantive changes for this draft version =
from -06 are:

(1) Changing the data-header format to add V-bit for Versioning and =
I-bit for Instance IDs.

(2) Adding a list ITR-RLOCs in the Map-Request to deal with =
heterogeneous address-families
  in different sites.

(3) Using Map-Versioning (and not Version-Hashing) as the mapping update =
solution.

Below is a up to date change log for -07, which includes editorial =
responses received since the original and update emails to the list.  =
Please note that we've got many open issues in the tracker to be =
reviewed for -08, and the review of the many detailed comments is =
getting started immediately.  I'll be updating the issue tracker tickets =
with specific details (more thorough than the change log) for each =
individual issue.

Unless there is any last minute issues we'll plan to post this later =
this weekend.

-Darrel
(on behalf of Dino, Dave, and Vince)




--Apple-Mail-20--356320157
Content-Disposition: attachment;
	filename=rfcdiff-lisp-06-to-07.html
Content-Type: text/html;
	name="rfcdiff-lisp-06-to-07.html"
Content-Transfer-Encoding: 7bit



wdiff draft-ietf-lisp-06.txt draft-ietf-lisp-07.txt

Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: July 24, October 25, 2010                                       D. Lewis
                                                           cisco Systems
                                                        January 20,
                                                          April 23, 2010

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-06.txt
                           draft-ietf-lisp-07

Abstract

   This draft describes a simple, incremental, network-based protocol to
   implement separation of Internet addresses into Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  This mechanism requires no
   changes to host stacks and no major changes to existing database
   infrastructures.  The proposed protocol can be implemented in a
   relatively small number of routers.

   This proposal was stimulated by the problem statement effort at the
   Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
   place in October 2006.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 24, October 25, 2010.

Copyright Notice
   Copyright (c) 2010 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 BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  Tunneling Details  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 18
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 21 22
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 22
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 22 23
     5.5.  Using Virtualization and Segmentation with LISP  . . . . . 24
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 24 25
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 24 25
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 26 27
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 26 27
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 28 29
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 30 31
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 33 34
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 35 37
       6.1.7.  Encapsualted  Encapsulated Control Message Format  . . . . . . . . . 37 38
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 39 40
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 40 41
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 43 44
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 44 45
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 45 46
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 46 47
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 46 47
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 47 48
       6.5.3.  Database Map Versioning  . . . . . . . . . . . . . . . 49
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 49 51
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 50 52
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 51 53
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 51 53
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 52 54
     8.4.  LISP Functionality with Conventional NATs  . . . . . . . . 54
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 53 55
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 54 56
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 54 56
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 54 56
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 56 58
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 56 58
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 56 58
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 56 58
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 58 60
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 58 60
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 60 62
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 61 63
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 64
   14. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 62
   14. 65
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
     14.1. 68
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 65
     14.2. 68
     15.2. Informative References . . . . . . . . . . . . . . . . . . 66 69
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 69 73
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 70 74
     B.1.  Changes to draft-ietf-lisp-06.txt draft-ietf-lisp-07.txt  . . . . . . . . . . . . 70 74
     B.2.  Changes to draft-ietf-lisp-05.txt draft-ietf-lisp-06.txt  . . . . . . . . . . . . 71 75
     B.3.  Changes to draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt  . . . . . . . . . . . . 71 76
     B.4.  Changes to draft-ietf-lisp-03.txt draft-ietf-lisp-04.txt  . . . . . . . . . . . . 73 77
     B.5.  Changes to draft-ietf-lisp-02.txt draft-ietf-lisp-03.txt  . . . . . . . . . . . . 74 79
     B.6.  Changes to draft-ietf-lisp-01.txt draft-ietf-lisp-02.txt  . . . . . . . . . . . . 74 79
     B.7.  Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 79
     B.8.  Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 74 80
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 81

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Many years of discussion about the current IP routing and addressing
   architecture have noted that its use of a single numbering space (the
   "IP address") for both host transport session identification and
   network routing creates scaling issues (see [CHIAPPA] and [RFC1498]).
   A number of scaling benefits would be realized by separating the
   current IP address into separate spaces for Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs); among them are:

   1.  Reduction of routing table size in the "default-free zone" (DFZ).
       Use of a separate numbering space for RLOCs will allow them to be
       assigned topologically (in today's Internet, RLOCs would be
       assigned by providers at client network attachment points),
       greatly improving aggregation and reducing the number of
       globally-visible, routable prefixes.

   2.  More cost-effective multihoming for sites that connect to
       different service providers where they can control their own
       policies for packet flow into the site without using extra
       routing table resources of core routers.

   3.  Easing of renumbering burden when clients change providers.
       Because host EIDs are numbered from a separate, non-provider-
       assigned and non-topologically-bound space, they do not need to
       be renumbered when a client site changes its attachment points to
       the network.

   4.  Traffic engineering capabilities that can be performed by network
       elements and do not depend on injecting additional state into the
       routing system.  This will fall out of the mechanism that is used
       to implement the EID/RLOC split (see Section 4).

   5.  Mobility without address changing.  Existing mobility mechanisms
       will be able to work in a locator/ID separation scenario.  It
       will be possible for a host (or a collection of hosts) to move to
       a different point in the network topology either retaining its
       home-based address or acquiring a new address based on the new
       network location.  A new network location could be a physically
       different point in the network topology or the same physical
       point of the topology with a different provider.

   This draft describes protocol mechanisms to achieve the desired
   functional separation.  For flexibility, the mechanism used for
   forwarding packets is decoupled from that used to determine EID to
   RLOC mappings.  This document covers the former.  For the later, latter, see
   [CONS], [ALT], [EMACS], [RPMD], and [NERD].  This work is in response
   to and intended to address the problem statement that came out of the
   RAWS effort [RFC4984].

   The Routing and Addressing problem statement can be found in [RADIR].

   This draft focuses on a router-based solution.  Building the solution
   into the network will facilitate incremental deployment of the
   technology on the Internet.  Note that while the detailed protocol
   specification and examples in this document assume IP version 4
   (IPv4), there is nothing in the design that precludes use of the same
   techniques and mechanisms for IPv6.  It should be possible for IPv4
   packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4
   RLOCs.

   Related work on host-based solutions is described in Shim6 [SHIM6] [RFC5533]
   and HIP [RFC4423].  Related work on a router-based solution is
   described in [GSE].  This draft attempts to not compete or overlap
   with such solutions and the proposed protocol changes are expected to
   complement a host-based mechanism when Traffic Engineering
   functionality is desired.

   Some of the design goals of this proposal include:

   1.  Require no hardware or software changes to end-systems (hosts).

   2.  Minimize required changes to Internet infrastructure.

   3.  Be incrementally deployable.

   4.  Require no router hardware changes.

   5.  Minimize the number of routers which have to be modified.  In
       particular, most customer site routers and no core routers
       require changes.

   6.  Minimize router software changes in those routers which are
       affected.

   7.  Avoid or minimize packet loss when EID-to-RLOC mappings need to
       be performed.

   There are 4 variants of LISP, which differ along a spectrum of strong
   to weak dependence on the topological nature and possible need for
   routability of EIDs.  The variants are:

   LISP 1:  uses EIDs that are routable through the RLOC topology for
      bootstrapping EID-to-RLOC mappings.  [LISP1] This was intended as
      a prototyping mechanism for early protocol implementation.  It is
      now deprecated and should not SHOULD NOT be deployed.

   LISP 1.5:  uses EIDs that are routable for bootstrapping EID-to-RLOC
      mappings; such routing is via a separate topology.

   LISP 2:  uses EIDS that are not routable and EID-to-RLOC mappings are
      implemented within the DNS.  [LISP2]

   LISP 3:  uses non-routable EIDs that are used as lookup keys for a
      new EID-to-RLOC mapping database.  Use of Distributed Hash Tables
      [DHTs] [LISPDHT] to implement such a database would be an area to
      explore.  Other examples of new mapping database services are
      [CONS], [ALT], [RPMD], [NERD], and [APT].

   This document on LISP 1.5, and LISP 3 variants, both of which rely on
   a router-based distributed cache and database for EID-to-RLOC
   mappings.  The LISP 1.0 mechanism works but does not allow reduction
   of routing information in the default-free-zone of the Internet.  The
   LISP 2 mechanisms are put on hold and may never come to fruition
   since it is not architecturally pure to have routing depend on
   directory and directory depend on routing.  The LISP 3 mechanisms
   will be documented elsewhere but may use the control-plane options
   specified in this specification.

3.  Definition of Terms

   Provider Independent (PI) Addresses:   an address block assigned from
      a pool where blocks are not associated with any particular
      location in the network (e.g. from a particular service provider),
      and is therefore not topologically aggregatable in the routing
      system.

   Provider Assigned (PA) Addresses:   a block of IP addresses that are
      assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider CIDR block and is aggregated into the larger block before
      being advertised into the global Internet.  Traditionally, IP
      multihoming has been implemented by each multi-homed site
      acquiring its own, globally-visible prefix.  LISP uses only
      topologically-assigned and aggregatable address blocks for RLOCs,
      eliminating this demonstrably non-scalable practice.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
      tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
      lookup.  An EID maps to one or more RLOCs.  Typically, RLOCs are
      numbered from topologically-aggregatable blocks that are assigned
      to a site at each point to which it attaches to the global
      Internet; where the topology is defined by the connectivity of
      provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains an destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.  When used in
      discussions with other Locator/ID separation proposals, a LISP EID
      will be called a "LEID".  Throughout this document, any references
      to "EID" refers to an LEID.

   EID-prefix:   A power-of-2 block of EIDs which are allocated to a
      site by an address allocation authority.  EID-prefixes are
      associated with a set of RLOC addresses which make up a "database
      mapping".  EID-prefix allocations can be broken up into smaller
      blocks when an RLOC set is to be associated with the smaller EID-
      prefix.  A globally routed address block (whether PI or PA) is not
      an EID-prefix.  However, a globally routed address block may be
      removed from global routing and reused as an EID-prefix.  A site
      that receives an explicitly allocated EID-prefix may not use that
      EID-prefix as a globally routed prefix assigned to RLOCs.

   End-system:   is an IPv4 or IPv6 device that originates packets with
      a single IPv4 or IPv6 header.  The end-system supplies an EID
      value for the destination address field of the IP header when
      communicating globally (i.e. outside of its routing domain).  An
      end-system can be a host computer, a switch or router device, or
      any network appliance.

   Ingress Tunnel Router (ITR):   a router which accepts an IP packet
      with a single IP header (more precisely, an IP packet that does
      not contain a LISP header).  The router treats this "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally-routable RLOCs in the source address field and the
      result of the mapping lookup in the destination address field.
      Note that this destination RLOC may be an intermediate, proxy
      device that has better knowledge of the EID-to-RLOC mapping closer
      to the destination EID.  In general, an ITR receives IP packets
      from site end-systems on one side and sends LISP-encapsulated IP
      packets toward the Internet on the other side.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating hosts
      supplied EID).

   TE-ITR:   is an ITR that is deployed in a service provider network
      that prepends an additional LISP header for Traffic Engineering
      purposes.

   Egress Tunnel Router (ETR):   a router that accepts an IP packet
      where the destination address in the "outer" IP header is one of
      its own RLOCs.  The router strips the "outer" header and forwards
      the packet based on the next IP header found.  In general, an ETR
      receives LISP-encapsulated IP packets from the Internet on one
      side and sends decapsulated IP packets to site end-systems on the
      other side.  ETR functionality does not have to be limited to a
      router device.  A server host can be the endpoint of a LISP tunnel
      as well.

   TE-ETR:   is an ETR that is deployed in a service provider network
      that strips an outer LISP header for Traffic Engineering purposes.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality is at the CE
      router.

   EID-to-RLOC Cache:   a short-lived, on-demand table in an ITR that
      stores, tracks, and is responsible for timing-out and otherwise
      validating EID-to-RLOC mappings.  This cache is distinct from the
      full "database" of EID-to-RLOC mappings, it is dynamic, local to
      the ITR(s), and relatively small while the database is
      distributed, relatively static, and much more global in scope.

   EID-to-RLOC Database:   a global distributed database that contains
      all known EID-prefix to RLOC mappings.  Each potential ETR
      typically contains a small piece of the database: the EID-to-RLOC
      mappings for the EID prefixes "behind" the router.  These map to
      one of the router's own, globally-visible, IP addresses.  The same
      database mapping entries MUST be configured on all ETRs for a
      given site.  That is, the EID-prefixes for the site and locator-
      set for each EID-prefix MUST be the same on all ETRs so they
      consistently send Map-Reply messages with the same database
      mapping contents.

   Recursive Tunneling:   when a packet has more than one LISP IP
      header.  Additional layers of tunneling may be employed to
      implement traffic engineering or other re-routing as needed.  When
      this is done, an additional "outer" LISP header is added and the
      original RLOCs are preserved in the "inner" header.  Any
      references to tunnels in this specification refers to dynamic
      encapsulating tunnels and never are they statically configured.

   Reencapsulating Tunnels:   when a packet has no more than one LISP IP
      header (two IP headers total) and when it needs to be diverted to
      new RLOC, an ETR can decapsulate the packet (remove the LISP
      header) and prepends a new tunnel header, with new RLOC, on to the
      packet.  Doing this allows a packet to be re-routed by the re-
      encapsulating router without adding the overhead of additional
      tunnel headers.  Any references to tunnels in this specification
      refers to dynamic encapsulating tunnels and never are they
      statically configured.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
      header that follows the UDP header, an ITR prepends or an ETR
      strips.

   Address Family Indicator Identifier (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI] and [RFC1700] for details.  An
      AFI value of 0 used in this specification indicates an unspecified
      encoded address where the the length of the address is 0 bytes
      following the 16-bit AFI value of 0.

   Negative Mapping Entry:   also known as a negative cache entry, is an
      EID-to-RLOC entry where an EID-prefix is advertised or stored with
      no RLOCs.  That is, the locator-set for the EID-to-RLOC entry is
      empty or has an encoded locator count of 0.  This type of entry
      could be used to describe a prefix from a non-LISP site, which is
      explicitly not in the mapping database.  There are a set of well
      defined actions that are encoded in a Negative Map-Reply.

   Data Probe:   a LISP-encapsulated data packet where the inner header
      destination address equals the outer header destination address
      used to trigger a Map-Reply by a decapsulating ETR.  In addition,
      the original packet is decapsulated and delivered to the
      destination host.  A Data Probe is used in some of the mapping
      database designs to "probe" or request a Map-Reply from an ETR; in
      other cases, Map-Requests are used.  See each mapping database
      design for details.

   Proxy ITR (PITR):   also known as a PTR is defined and described in
      [INTERWORK], a PITR acts like an ITR but does so on behalf of non-
      LISP sites which send packets to destinations at LISP sites.

   Proxy ETR (PETR):   is defined and described in [INTERWORK], a PETR
      acts like an ETR but does so on behalf of LISP sites which send
      packets to destinations at non-LISP sites.

4.  Basic Overview

   One key concept of LISP

   Route-returnability:  is an assumption that end-systems (hosts) operate the same
   way they do today.  The IP addresses underlying routing
      system will deliver packets to the destination.  When combined
      with a nonce that hosts use for tracking
   sockets, connections, is provided by a sender and for sending returned by a
      receiver limits off-path data insertion.

   LISP site:  is a set of routers in an edge network that are under a
      single technical administration.  LISP routers which reside in the
      edge network are the demarcation points to separate the edge
      network from the core network.

4.  Basic Overview

   One key concept of LISP is that end-systems (hosts) operate the same
   way they do today.  The IP addresses that hosts use for tracking
   sockets, connections, and for sending and receiving packets do not
   change.  In LISP terminology, these IP addresses are called Endpoint
   Identifiers (EIDs).

   Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC.

   This design introduces "Tunnel Routers", which prepends LISP headers
   on host-originated packets and strip them prior to final delivery to
   their destination.  The IP addresses in this "outer header" are
   RLOCs.  During end-to-end packet exchange between two Internet hosts,
   an ITR prepends a new LISP header to each packet and an egress tunnel
   router strips the new header.  The ITR performs EID-to-RLOC lookups
   to determine the routing path to the the ETR, which has the RLOC as
   one of its IP addresses.

   Some basic rules governing LISP are:

   o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.

   o  EIDs are always IP addresses assigned to hosts.

   o  LISP routers mostly deal with Routing Locator addresses.  See
      details later in Section 4.1 to clarify what is meant by "mostly".

   o  RLOCs are always IP addresses assigned to routers; preferably,
      topologically-oriented addresses from provider CIDR blocks.

   o  When a router originates packets it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g. when
      terminating a transport session such as SSH, TELNET, or SNMP), it
      may use an EID that is explicitly assigned for that purpose.  An
      EID that identifies the router as a host MUST NOT be used as an
      RLOC; an EID is only routable within the scope of a site.  A
      typical BGP configuration might demonstrate this "hybrid" EID/RLOC
      usage where a router could use its "host-like" EID to terminate
      iBGP sessions to other routers in a site while at the same time
      using RLOCs to terminate eBGP sessions to routers outside the
      site.

   o  EIDs are not expected to be usable for global end-to-end
      communication in the absence of an EID-to-RLOC mapping operation.
      They are expected to be used locally for intra-site communication.

   o  EID prefixes are likely to be hierarchically assigned in a manner
      which is optimized for administrative convenience and to
      facilitate scaling of the EID-to-RLOC mapping database.  The
      hierarchy is based on a address allocation hierarchy which is not
      dependent on the network topology.

   o  EIDs may also be structured (subnetted) in a manner suitable for
      local routing within an autonomous system.

   An additional LISP header may be prepended to packets by a transit
   router (i.e.  TE-ITR) when re-routing of the path for a packet is
   desired.  An obvious instance of this would be an ISP router that
   needs to perform traffic engineering for packets in flow flowing through its
   network.  In such a situation, termed Recursive Tunneling, an ISP
   transit acts as an additional ingress tunnel router and the RLOC it
   uses for the new prepended header would be either a TE-ETR within the
   ISP (along intra-ISP traffic engineered path) or a TE-ETR within
   another ISP (an inter-ISP traffic engineered path, where an agreement
   to build such a path exists).

   This specification mandates that no more than two LISP headers get
   prepended to a packet.  This avoids excessive packet overhead as well
   as possible encapsulation loops.  It is believed two headers is
   sufficient, where the first prepended header is used at a site for
   Location/Identity separation and second prepended header is used
   inside a service provider for Traffic Engineering purposes.

   Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
   For example, the ITR for a particular end-to-end packet exchange
   might be the first-hop or default router within a site for the source
   host.  Similarly, the egress tunnel router might be the last-hop
   router directly-connected to the destination host.  Another example,
   perhaps for a VPN service out-sourced to an ISP by a site, the ITR
   could be the site's border router at the service provider attachment
   point.  Mixing and matching of site-operated, ISP-operated, and other
   tunnel routers is allowed for maximum flexibility.  See Section 8 for
   more details.

4.1.  Packet Flow Sequence

   This section provides an example of the unicast packet flow with the
   following conditions:

   o  Source host "host1.abc.com" is sending a packet to
      "host2.xyz.com", exactly what host1 would do if the site was not
      using LISP.

   o  Each site is multi-homed, so each tunnel router has an address
      (RLOC) assigned from the service provider address block for each
      provider to which that particular tunnel router is attached.

   o  The ITR(s) and ETR(s) are directly connected to the source and
      destination, respectively.

   o  Data Probes are used to solicit Map-Replies versus using Map-
      Requests.  And respectively, but the Data Probes are source and destination can be
      located anywhere in LISP site.

   o  Map-Requests can be sent on the underlying routing system topology
      (the LISP 1.0 variant) but could also be sent
      (LISP 1.0) or over an alternative topology (the LISP 1.5 variant) as it would in [ALT].

   o  Map-Replies are sent on the underlying routing system topology.

   Client host1.abc.com wants to communicate with server host2.xyz.com:

   1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
       It does a DNS lookup on host2.xyz.com.  An A/AAAA record is
       returned.  This address is used as the destination EID and the
       locally-assigned EID.  The locally-
       assigned address of host1.abc.com is used as the source EID.  An
       IPv4 or IPv6 packet is built using the EIDs in the IPv4
       or IPv6 header and sent to forwarded through the default router.

   2.  The default router is configured LISP site
       as an a normal IP packet until it reaches a LISP ITR.

   2.  The LISP ITR must be able to map the EID destination to an RLOC
       of one of the ETR ETRs at the destination site.  The ITR prepends a LISP header specific method
       used to the packet,
       with one of its RLOCs as the source IPv4 do this is not described in this example.  See [ALT] or IPv6 address.
       [CONS] for possible solutions.

   3.  The
       destination EID from ITR will send a LISP Map-Request.  Map-Requests SHOULD be
       rate-limited.

   4.  In LISP 1.0, the original Map-Request packet header is used as the
       destination IPv4 or IPv6 in routed through the prepended
       underlying routing system.  In LISP header.
       Subsequent packets, where 1.5, the outer destination address is the
       destination EID will be sent until EID-to-RLOC mapping is
       learned.

   3.  In LISP 1, the packet is routed through the Internet as it is
       today.  In LISP 1.5, the packet Map-Request packet
       is routed on a different topology
       which may have EID prefixes distributed and advertised in an
       aggregatable fashion. alternate logical topology.  In either case, when
       the packet Map-Request arrives at one of the
       ETR.  The router is configured to "punt" the packet to the
       router's processor.  See Section 7 for more details.  For LISP
       2.0 and 3.0, ETRs at the behavior is not fully defined yet.

   4.  The LISP header is stripped so that destination
       site, it will process the packet can be forwarded
       by the router as a control plane. message.

   5.  The router ETR looks up at the destination EID in the router's EID-to-RLOC database (not the cache, but the
       configured data structure of RLOCs).  An EID-to-RLOC Map-Reply
       message is originated by the ETR Map-Request and is addressed to
       matches it against the source
       RLOC prefixes in the LISP header ETR's configured EID-to-
       RLOC mapping database.  This is the list of EID-prefixes the original packet (this ETR
       is supporting for the ITR).
       The source RLOC of site it resides in.  If there is no match,
       the Map-Request is dropped.  Otherwise, a LISP Map-Reply is one of
       returned to the ETR's RLOCs.

   5. ITR.

   6.  The ITR receives the Map-Reply message, parses the message (to
       check for format validity) and stores the mapping information
       from the packet.  This information is put in the ITR's EID-to-
       RLOC mapping cache (this is the on-demand cache, the cache where
       entries time out due to inactivity).

   6.

   7.  Subsequent packets from host1.abc.com to host2.xyz.com will have
       a LISP header prepended by the ITR using the appropriate RLOC as
       the LISP header destination address learned from the ETR.  Note,
       the packet may be sent to a different ETR than the one which
       returned the Map-Reply due to the source site's hashing policy or
       the destination site's locator-set policy.

   7.

   8.  The ETR receives these packets directly (since the destination
       address is one of its assigned IP addresses), strips the LISP
       header and forwards the packets to the attached destination host.

   In order to eliminate the need for a mapping lookup in the reverse
   direction, an ETR MAY create a cache entry that maps the source EID
   (inner header source IP address) to the source RLOC (outer header
   source IP address) in a received LISP packet.  Such a cache entry is
   termed a "gleaned" mapping and only contains a single RLOC for the
   EID in question.  More complete information about additional RLOCs
   SHOULD be verified by sending a LISP Map-Request for that EID.  Both
   ITR and the ETR may also influence the decision the other makes in
   selecting an RLOC.  See Section 6 for more details.

5.  Tunneling Details

   This section describes the LISP Data Message which defines the
   tunneling header used to encapsulate IPv4 and IPv6 packets which
   contain EID addresses.  Even though the following formats illustrate
   IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2
   combinations are supported as well.

   Since additional tunnel headers are prepended, the packet becomes
   larger and in theory can exceed the MTU of any link traversed from
   the ITR to the ETR.  It is recommended, in IPv4 that packets do not
   get fragmented as they are encapsulated by the ITR.  Instead, the
   packet is dropped and an ICMP Too Big message is returned to the
   source.

   Based on informal surveys of large ISP traffic patterns, it appears
   that most transit paths can accommodate a path MTU of at least 4470
   bytes.  The exceptions, in terms of data rate, number of hosts
   affected, or any other metric are expected to be vanishingly small.

   To address MTU concerns, mainly raised on the RRG mailing list, the
   LISP deployment process will include collecting data during its pilot
   phase to either verify or refute the assumption about minimum
   available MTU.  If the assumption proves true and transit networks
   with links limited to 1500 byte MTUs are corner cases, it would seem
   more cost-effective to either upgrade or modify the equipment in
   those transit networks to support larger MTUs or to use existing
   mechanisms for accommodating packets that are too large.

   For this reason, there is currently no plan for LISP to add any new
   additional, complex mechanism for implementing fragmentation and
   reassembly in the face of limited-MTU transit links.  If analysis
   during LISP pilot deployment reveals that the assumption of
   essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect,
   then LISP can be modified prior to protocol standardization to add
   support for one of the proposed fragmentation and reassembly schemes.
   Note that two simple existing schemes are detailed in Section 5.4.

5.1.  LISP IPv4-in-IPv4 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|  rflags |                 Nonce   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       Locator                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  LISP IPv6-in-IPv6 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Payload Length        | Next Header=17|   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|  rflags |                 Nonce   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                       Locator                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Tunnel Header Field Descriptions

   Inner Header:  is the inner header, preserved from the datagram
      received from the originating host.  The source and destination IP
      addresses are EIDs.

   Outer Header:  is the outer header prepended by an ITR.  The address
      fields contain RLOCs obtained from the ingress router's EID-to-
      RLOC cache.  The IP protocol number is "UDP (17)" from [RFC0768].
      The DF bit of the Flags field is set to 0 when the method in
      Section 5.4.1 is used and set to 1 when the method in
      Section 5.4.2 is used.

   UDP Header:  contains a ITR selected source port when encapsulating a
      packet.  See Section 6.4 for details on the hash algorithm used to
      select a source port based on the 5-tuple of the inner header.
      The destination port MUST be set to the well-known IANA assigned
      port value 4341.

   UDP Checksum:  this field SHOULD be transmitted as zero by an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is received by an ETR, the ETR
      MUST accept the packet for decapsulation.  When an ITR transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes will
      be made to align LISP with the outcome of the broader discussion.

   UDP Length:  for an IPv4 encapsulated packet, the inner header Total
      Length plus the UDP and LISP header lengths are used.  For an IPv6
      encapsulated packet, the inner header Payload Length plus the size
      of the IPv6 header (40 bytes) plus the size of the UDP and LISP
      headers are used.  The UDP header length is 8 bytes.

   N: this is the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See section Section 6.3.1 for details.  Both N and V bits MUST
      NOT be set in the same packet.  If they are, a decapsulating ETR
      MUST treat the "Nonce/Map-Version" field as having a Nonce value
      present.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.

     x 1 x x 0 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Locator Status Bits                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must MUST be 1.  This bit should SHOULD be ignored and has no
      meaning when the N bit is set to 0.  See section Section 6.3.1 for
      details.

   rflags:

   V: this 5-bit field is reserved for future flag use.  It the Map-Version present bit.  When this bit is set to 0 on transmit and ignored on receipt.

   LISP Nonce:  is 1,
      the N bit MUST be 0.  Refer to Section 6.5.3 for more details.
      This bit indicates that the first 4 bytes of the LISP header is
      encoded as:

     0 x 0 1 x x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator Status Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I: this is the Instance ID bit.  See Section 5.5 for more details.
      When this bit is set to 1, the Locator Status Bits field is
      reduced to 8-bits and the high-order 24-bits are used as an
      Instance ID.  If the L-bit is set to 0, then the low-order 8 bits
      are transmitted as zero and ignored on receipt.  The format of the
      last 4 bytes of the LISP header would look like:

     x x x x 1 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID                   |     LSBs      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   flags:  this 3-bit field is reserved for future flag use.  It is set
      to 0 on transmit and ignored on receipt.

   LISP Nonce:  is a 24-bit value that is randomly generated by an ITR
      when the N-bit is set to 1.  The nonce is also used when the E-bit
      is set to request the nonce value to be echoed by the other side
      when packets are returned.  When the E-bit is clear but the N-bit
      is set, a remote ITR is either echoing a previously requested
      echo-nonce or providing a random nonce.  See section Section 6.3.1 for
      more details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the least
      significant bit of the 32-bit field.  The field is 32-bits when the I-bit is
      set to 0 and is 8 bits when the I-bit is set to 1.  When a bit Locator
      Status Bit is set to 1, the ITR is indicating to the ETR the RLOC
      associated with the bit ordinal has up status.  See Section 6.3
      for details on how an ITR can determine the status of other ITRs
      at the site are reachable. same site.  When a site has multiple EID-prefixes which
      result in multiple mappings (where each could have a different
      locator-set), the Locator Status Bits setting in an encapsulated
      packet MUST reflect the mapping for the EID-prefix that the inner-header inner-
      header source EID address matches.

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

   o  The outer header Type of Service field (or the Traffic Class
      field, in the case of IPv6) SHOULD be copied from the inner header
      Type of Service field (with one caveat, see below).

   When doing Re-encapsulated Tunneling:

   o  The new outer header Time to Live field SHOULD be copied from the
      stripped outer header Time to Live field.

   o  The new outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below).

   Copying the TTL serves two purposes: first, it preserves the distance
   the host intended the packet to travel; second, and more importantly,
   it provides for suppression of looping packets in the event there is
   a loop of concatenated tunnels due to misconfiguration.

   The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
   field and the IPv6 Traffic Class field [RFC3168].  The ECN field
   requires special treatment in order to avoid discarding indications
   of congestion [RFC3168].  ITR encapsulation MUST copy the 2-bit ECN
   field from the inner header to the outer header.  Re-encapsulation
   MUST copy the 2-bit ECN field from the stripped outer header to the
   new outer header.  If the ECN field contains a congestion indication
   codepoint (the value is '11', the Congestion Experienced (CE)
   codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
   the stripped outer header to the surviving inner header that is used
   to forward the packet beyond the ETR.  These requirements preserve
   Congestion Experienced (CE) indications when a packet that uses ECN
   traverses a LISP tunnel and becomes marked with a CE indication due
   to congestion between the tunnel endpoints.

5.4.  Dealing with Large Encapsulated Packets

   In the event that the MTU issues mentioned above prove to be more
   serious than expected, this section proposes 2 simple mechanisms to
   deal with large packets.  One is stateless using IP fragmentation and
   the other is stateful using Path MTU Discovery [RFC1191].

   It is left to the implementor to decide if the stateless or stateful
   mechanism should SHOULD be implemented.  Both or neither can be decided as
   well since it is a local decision in the ITR regarding how to deal
   with MTU issues.  Sites can interoperate with differing mechanisms.

   Both stateless and stateful mechanisms also apply to Reencapsulating
   and Recursive Tunneling.  So any actions reference below referring to an ITR
   also apply to an TE-ITR.

5.4.1.  A Stateless Solution to MTU Handling

   An ITR stateless solution to handle MTU issues is described as
   follows:

   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would receive from a source inside of
       its site.

   2.  Define L to be the maximum size, in bytes, a packet of size S
       would be after the ITR prepends the LISP header, UDP header, and
       outer network layer header of size H.

   3.  Calculate: S + H = L.

   When an ITR receives a packet from a site-facing interface and adds H
   bytes worth of encapsulation to yield a packet size greater than L
   bytes, it resolves the MTU issue by first splitting the original
   packet into 2 equal-sized fragments.  A LISP header is then prepended
   to each fragment.  This will ensure that the new, encapsulated
   packets are of size (S/2 + H), which is always below the effective
   tunnel MTU.

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

   This behavior is performed by the ITR when the source host originates
   a packet with the DF field of the IP header is set to 0.  When the DF
   field of the IP header is set to 1, or the packet is an IPv6 packet
   originated by the source host, the ITR will drop the packet when the
   size is greater than L, and sends an ICMP Too Big message to the
   source with a value of S, where S is (L - H).

   When the outer header encapsulation uses an IPv4 header, an
   implementation should consider a default behavior of setting SHOULD set the DF bit to 1 so ETR fragment reassembly
   can be avoided.  An implementation MAY set the DF bit in such headers
   to 0 if it has good reason to believe there are unresolvable path MTU
   issues between the sending ITR and the receiving ETR.

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

   An ITR stateful solution to handle MTU issues is described as follows
   and was first introduced in [OPENLISP]:

   1.  The ITR will keep state of the effective MTU for each locator per
       mapping cache entry.  The effective MTU is what the core network
       can deliver along the path between ITR and ETR.

   2.  When an IPv6 encapsulated packet or an IPv4 encapsulated packet
       with DF bit set to 1, exceeds what the core network can deliver,
       one of the intermediate routers on the path will send an ICMP Too
       Big message to the ITR.  The ITR will parse the ICMP message to
       determine which locator is affected by the effective MTU change
       and then record the new effective MTU value in the mapping cache
       entry.

   3.  When a packet is received by the ITR from a source inside of the
       site and the size of the packet is greater than the effective MTU
       stored with the mapping cache entry associated with the
       destination EID the packet is for, the ITR will send an ICMP Too
       Big message back to the source.  The packet size advertised by
       the ITR in the ICMP Too Big message is the effective MTU minus
       the LISP encapsulation length.

   Even though this mechanism is stateful, it has advantages over the
   stateless IP fragmentation mechanism, by not involving the
   destination host with reassembly of ITR fragmented packets.

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4

5.5.  Using Virtualization and IPv6 Control Plane Packet Formats

   The following new UDP packet types Segmentation with LISP

   When multiple organizations inside of a LISP site are used using private
   addresses [RFC1918] as EID-prefixes, their address spaces MUST remain
   segregated due to retrieve EID-to-RLOC
   mappings:

       0                   1 possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.  See [LCAF] for details for a possible address encoding.  The
   LCAF encoding is an area for further study.

   An Instance ID can be carried in a LISP encapsulated packet.  An ITR
   that prepends a LISP header, will copy a 24-bit value, used by the
   LISP router to uniquely identify the address space.  The value is
   copied to the Instance ID field of the LISP header and the I-bit is
   set to 1.

   When an ETR decapsulate a packet, the Instance ID from the LISP
   header is used as a table identifier to locate the forwarding table
   to use for the inner destination EID lookup.

   Some examples of the 24-bit value to copy or map into the Instance ID
   field could be a 802.1Q VLAN tag or a configured VRF-ID value.

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

   The following new UDP packet types are used to retrieve EID-to-RLOC
   mappings:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|  IHL  |Type of Service|          Total Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identification        |Flags|      Fragment Offset    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time to Live | Protocol = 17 |         Header Checksum       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Source Routing Locator                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Traffic Class |           Flow Label                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        | Next Header=17|   Hop Limit   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                     Source Routing Locator                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                  Destination Routing Locator                  +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LISP UDP-based messages are the Map-Request and Map-Reply
   messages.  When a UDP Map-Request is sent, the UDP source port is
   chosen by the sender and the destination UDP port number is set to
   4342.  When a UDP Map-Reply is sent, the source UDP port number is
   set to 4342 and the destination UDP port number is copied from the
   source port of either the Map-Request or the invoking data packet.

   The UDP Length field will reflect the length of the UDP header and
   the LISP Message payload.

   The UDP Checksum is computed and set to non-zero for Map-Request,
   Map-Reply, Map-Register and ECM control messages.  It MUST be checked
   on receipt and if the checksum fails, the packet MUST be dropped.

   LISP-CONS [CONS] use TCP to send LISP control messages.  The format
   of control messages includes the UDP header so the checksum and
   length fields can be used to protect and delimit message boundaries.

   This main LISP specification is the authoritative source for message
   format definitions for the Map-Request and Map-Reply messages.

6.1.1.  LISP Packet Type Allocations

   This section will be the authoritative source for allocating LISP
   Type values.  Current allocations are:

       Reserved:                          0    b'0000'
       LISP Map-Request:                  1    b'0001'
       LISP Map-Reply:                    2    b'0010'
       LISP Map-Register:                 3    b'0011'
       LISP Encapsulated Control Message: 8    b'1000'

6.1.2.  Map-Request Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|       Reserved      |   IRC   | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |            ITR-AFI   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Source EID         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Originating ITR RLOC                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.

   M: When set, it indicates a Map-Reply Record segment is included in
      the Map-Request.

   P: Indicates This is the probe-bit which indicates that a Map-Request should SHOULD be
      treated as a "piggyback" locator reachability probe.  The receiver should SHOULD
      respond with a Map-Reply with the P bit set and probe-bit set, indicating the
      Map-Reply is a locator reachability probe reply, with the nonce
      copied from the Map-
      Request. Map-Request.  See section Section 6.3.2 for more details.

   S: This is the SMR bit.  See Section 6.5.2 for details.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   Record Count:  The number of records in this Map-Request message.  A
      record

   IRC:  This 5-bit field is comprised of the portion of the packet that is labeled
      'Rec' above and occurs ITR-RLOC Count which encodes the number
      of times equal to Record Count.
      For (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this version of the protocol,
      message.  Multiple ITR-RLOC Address fields are used so a receiver MUST accept and Map-
      Replier can select which destination address to use for a Map-
      Reply.  The IRC value ranges from 0 to 31, where IRC value 0 means
      an ITR-RLOC address count of 1, an IRC value of 1 means an ITR-
      RLOC address count of 2, and so on up to an IRC value of 31, which
      means an ITR-RLOC address count of 32.

   Record Count:  The number of records in this Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   Source-EID-AFI:  Address family of the "Source EID Address" field.

   ITR-AFI:  Address family of the "Originating ITR RLOC Address" field.

   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, the value 0 is used.

   Originating ITR RLOC

   ITR-RLOC-AFI:  Address family of the "ITR-RLOC Address" field that
      follows this field.

   ITR-RLOC Address:  Used to give the ETR the option of
      returning a Map-Reply in selecting the address-family of this locator.
      destination address from any address family for the Map-Reply
      message.  This address MUST be a routable RLOC address.

   EID mask-len:  Mask length for EID prefix.

   EID-AFI:

   EID-prefix-AFI:  Address family of EID-prefix according to [RFC2434] [RFC5226]

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.  When a Map-Request is sent by an ITR because a
      data packet is received for a destination where there is no
      mapping entry, the EID-prefix is set to the destination IP address
      of the data packet.  And the 'EID mask-len' is set to 32 or 128
      for IPv4 or IPv6, respectively.  When an xTR wants to query a site
      about the status of a mapping it already has cached, the EID-
      prefix used in the Map-Request has the same mask-length as the
      EID-prefix returned from the site when it sent a Map-Reply
      message.

   Map-Reply Record:  When the M bit is set, this field is the size of
      the "Record" field in the Map-Reply format.  This Map-Reply record
      contains the EID-to-RLOC mapping entry associated with the Source
      EID.  This allows the ETR which will receive this Map-Request to
      cache the data if it chooses to do so.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.3.  EID-to-RLOC UDP Map-Request Message

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the later latter 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.

   In all cases, the UDP source port number for the Map-Request message
   is a randomly allocated 16-bit value and the UDP destination port
   number is set to the well-known destination port number 4342.  A
   successful Map-Reply updates the cached set of RLOCs associated with
   the EID prefix range.

   One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
   be filled in by the ITR.  The number of fields (minus 1) encoded MUST
   be placed in the IRC field.  The ITR MAY include all locally
   configured locators in this list or just provide one locator address
   from each address family it supports.  If the ITR erroneously
   provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
   Request.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4342 with a LISP type value set to "Encapsulated Control Message",
   when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
   LISP encapsulated the same way from a Map-Server to an ETR.  Details
   on encapsulated Map-Requests and Map-Resolvers can be found in
   [LISP-MS].

   Map-Requests MUST be rate-limited.  It is recommended that a Map-
   Request for the same EID-prefix be sent no more than once per second.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request and it does
   not have this mapping in the map-cache, it may originate a "verifying
   Map-Request", addressed to the map-requesting ITR.  If the ETR has a
   map-cache entry that matches the "piggybacked" EID and the RLOC is in
   the locator-set for the entry, then it may send the "verifying Map-
   Request" directly to the originating Map-Request source.  If the RLOC
   is not in the locator-set, then the ETR MUST send the "verifying Map-
   Request" to the "piggybacked" EID.  Doing this forces the "verifying
   Map-Request" to go through the mapping database system to reach the
   authoritative source of information about that EID, guarding against
   RLOC-spoofing in in the "piggybacked" mapping data.

6.1.4.  Map-Reply Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=2 |P|E|            Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved Rsvd  |  Map-Version Number   |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags      |R|     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   2 (Map-Reply)

   P: Indicates This is the probe-bit which indicates that the Map-Reply is in
      response to a "piggyback" locator reachability probe Map-Request.  The nonce
      field should MUST contain a copy of the nonce value from the original
      Map-Request.  See
      section Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site is enabled for the Echo-Nonce locator
      reachability algorithm.  See Section 6.3.1 for more details.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   Record Count:  The number of records in this reply message.  A record
      is comprised of that portion of the packet labeled 'Record' above
      and occurs the number of times equal to Record count.

   Nonce:  A 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of the Map-
      Reply.

   Record TTL:  The time in minutes the recipient of the Map-Reply will
      store the mapping.  If the TTL is 0, the entry should SHOULD be removed
      from the cache immediately.  If the value is 0xffffffff, the
      recipient can decide locally how long to store the mapping.

   Locator Count:  The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc'.  The locator count can
      be 0 indicating there are no locators for the EID-prefix.

   EID mask-len:  Mask length for EID prefix.

   ACT:  This 3-bit field describes negative Map-Reply actions.  These
      bits are used only when the 'Locator Count' field is set to 0.
      The action bits are encoded only in Map-Reply messages.  The
      actions defined are used by an ITR or PTR when a destination EID
      matches a negative mapping cache entry.  Unassigned values should
      cause a map-cache entry to be created and, when packets match this
      negative cache entry, they will be dropped.  The current assigned
      values are:

      (0) Drop:  The packet is dropped silently.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
         but natively forwarded.

      (2) Send-Map-Request:  The packet invokes sending a Map-Request.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set to 1 by the an ETR.  See [CONS] for TCP-based Map-Replies.

   EID-AFI:  Address family of EID-prefix according to [RFC2434].

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

   Priority:  each RLOC  When a
      Map-Server is assigned proxy Map-Replying [LISP-MS] for a unicast priority.  Lower values
      are more LISP site, the
      Authoritative bit is set to 0.  This indicates to requesting ITRs
      that the Map-Reply was not originated by a LISP node managed at
      the site that owns the EID-prefix.

   Map-Version Number:  When this 12-bit value is non-zero the Map-Reply
      sender is informing the ITR what the version number is for the
      EID-record contained in the Map-Reply.  The ETR can allocate this
      number internally but MUST coordinate this value with other ETRs
      for the site.  When this value is 0, there is no versioning
      information conveyed.  The Map-Version Number can be included in
      Map-Request and Map-Register messages.  See Section 6.5.3 for more
      details.

   EID-AFI:  Address family of EID-prefix according to [RFC5226].

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

   Priority:  each RLOC is assigned a unicast priority.  Lower values
      are more preferable.  When multiple RLOCs have the same priority,
      they may be used in a load-split fashion.  A value of 255 means
      the RLOC MUST NOT be used for unicast forwarding.

   Weight:  when priorities are the same for multiple RLOCs, the weight
      indicates how to balance unicast traffic between them.  Weight is
      encoded as a percentage of total unicast packets that match the
      mapping entry.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must MUST use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to load-split traffic.  See
      Section 6.4 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.  When
      a single RLOC exists in a mapping entry, the weight value MUST be
      set to 100 and ignored on receipt.

   M Priority:  each RLOC is assigned a multicast priority used by an
      ETR in a receiver multicast site to select an ITR in a source
      multicast site for building multicast distribution trees.  A value
      of 255 means the RLOC MUST NOT be used for joining a multicast
      distribution tree.

   M Weight:  when priorities are the same for multiple RLOCs, the
      weight indicates how to balance building multicast distribution
      trees across multiple ITRs.  The weight is encoded as a percentage
      of total number of trees build to the source site identified by
      the EID-prefix.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must MUST use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to distribute multicast state across
      ITRs.

   Unused Flags:  set to 0 when sending and ignored on receipt.

   R:

   L: when this bit is set, the locator is known flagged as a local locator to be reachable from
      the Map-Reply sender's perspective.

   Locator:  an IPv4 or IPv6 address (as encoded by
      the 'Loc-AFI' field)
      assigned to an ETR or router acting as that is sending the Map-Reply.  When a Map-Server is doing
      proxy replier Map-Replying [LISP-MS] for a LISP site, the
      EID-prefix.  Note L bit is set to
      0 for all locators in this locator-set.

   p: when this bit is set, an ETR informs the RLOC-probing ITR that the destination RLOC address MAY
      locator address, for which this bit is set, is the one being RLOC-
      probed and may be an
      anycast address.  A different from the source RLOC can be an anycast address as well.
      The source or destination RLOC of the Map-
      Reply.  An ITR that RLOC-probes a particular locator, MUST NOT be use
      this locator for retrieving the broadcast address
      (255.255.255.255 or any subnet data structure used to store the
      fact that the locator is reachable.  The "p" bit is set for a
      single locator in the same locator set.  If an implementation sets
      more than one "p" bit erroneously, the receiver of the Map-Reply
      MUST select the first locator.  The "p" bit MUST NOT be set for
      locator-set records sent in Map-Request and Map-Register messages.

   R: when this bit is set, the locator is known to be reachable from
      the Map-Reply sender's perspective.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR or router acting as a proxy replier for the
      EID-prefix.  Note that the destination RLOC address MAY be an
      anycast address.  A source RLOC can be an anycast address as well.
      The source or destination RLOC MUST NOT be the broadcast address
      (255.255.255.255 or any subnet broadcast address known to the
      router), and MUST NOT be a link-local multicast address.  The
      source RLOC MUST NOT be a multicast address.  The destination RLOC
      SHOULD be a multicast address if it is being mapped from a
      multicast destination EID.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.5.  EID-to-RLOC UDP Map-Reply Message

   When a Data Probe packet or a Map-Request triggers a Map-Reply to be
   sent, the RLOCs associated with the EID-prefix matched by the EID in
   the original packet destination IP address field will be returned.
   The RLOCs in the Map-Reply are the globally-routable IP addresses of
   the ETR but are not necessarily reachable; separate testing of
   reachability is required.

   Note that a Map-Reply may contain different EID-prefix granularity
   (prefix + length) than the Map-Request which triggers it.  This might
   occur if a Map-Request were for a prefix that had been returned by an
   earlier Map-Reply.  In such a case, the requester updates its cache
   with the new prefix information and granularity.  For example, a
   requester with two cached EID-prefixes that are covered by a Map-
   Reply containing one, less-specific prefix, replaces the entry with
   the less-specific EID-prefix.  Note that the reverse, replacement of
   one less-specific prefix with multiple more-specific prefixes, can
   also occur but not by removing the less-specific prefix rather by
   adding the more-specific prefixes which during a lookup will override
   the less-specific prefix.

   When an ETR is configured with overlapping EID-prefixes, a Map-
   Request with an EID that longest matches any EID-prefix MUST be
   returned in a single Map-Reply message.  For instance, if an ETR had
   database mapping entries for EID-prefixes:

     10.0.0.0/8
     10.1.0.0/16
     10.1.1.0/24
     10.1.2.0/24

   A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
   count of 1 to be returned with a mapping record EID-prefix of
   10.1.1.0/24.

   A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record
   count of 3 to be returned with mapping records for EID-prefixes
   10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.

   Note that not all overlapping EID-prefixes need to be returned, only
   the more specifics (note in the second example above 10.0.0.0/8 was
   not returned for requesting EID 10.1.5.5) entries for the matching
   EID-prefix of the requesting EID.  When more than one EID-prefix is
   returned, all SHOULD use the same Time-to-Live value so they can all
   time out at the same time.  When a more specific EID-prefix is
   received later, its Time-to-Live value in the Map-Reply record can be
   stored even when other less specifics exist.  When a a less specific
   EID-prefix is received later, its map-cache expiration time should SHOULD be
   set to the minimum expiration time of any more specific EID-prefix in
   the map-cache.

   Map-Replies SHOULD be sent for an EID-prefix no more often than once
   per second to the same requesting router.  For scalability, it is
   expected that aggregation of EID addresses into EID-prefixes will
   allow one Map-Reply to satisfy a mapping for the EID addresses in the
   prefix range thereby reducing the number of Map-Request messages.

   Map-Reply records can have an empty locator-set.  This type of a Map-
   Reply is called a Negative Map-Reply.  Negative Map-Replies convey
   special actions by the sender to the ITR or PTR which have solicited
   the Map-Reply.  There are two primary applications for Negative Map-
   Replies.  The first is for a Map-Resolver to instruct an ITR or PTR
   when a destination is for a LISP site versus a non-LISP site.  And
   the other is to source quench Map-Requests which are sent for non-
   allocated EIDs.

   For each Map-Reply record, the list of locators in a locator-set MUST
   appear in the same order for each ETR that originates a Map-Reply
   message.  The locator-set MUST be sorted in order of ascending IP
   address where an IPv4 locator address is considered numerically 'less
   than' an IPv6 locator address.

   When sending a Map-Reply message, the destination address is copied
   from the one of the ITR-RLOC fields from the Map-Request.  The ETR
   can choose a locator address from one of the address families it
   supports.  For Data-Probes, the destination address of the Map-Reply
   is copied from the source address of the Map-Request or Data-Probe message which is
   invoking the reply.  The source address of the Map-Reply is one of
   the local locator addresses listed in the locator-set of any mapping
   record in the message. message and SHOULD be chosen to allow uRPF checks to
   succeed in the upstream service provider.  The destination port of a
   Map-Reply message is copied from the source port of the Map-Request
   or Data-
   Probe Data-Probe and the source port of the Map-Reply message is set to
   the well-known UDP port 4342.

6.1.5.1.  Traffic Redirection with Coarse EID-Prefixes

   When an ETR is misconfigured or compromised, it could return coarse
   EID-prefixes in Map-Reply messages it sends.  The EID-prefix could
   cover EID-prefixes which are allocated to other sites redirecting
   their traffic to the locators of the compromised site.

   To solve this problem, there are two basic solutions that could be
   used.  The first is to have Map-Servers proxy-reply proxy-map-reply on behalf of
   ETRs so their registered EID-prefixes are the ones returned in Map-
   Replies.  Since the interaction between an ETR and Map-Server is
   secured with shared-keys, it is more difficult for an ETR to
   misbehave.  The second solution is to have ITRs and PTRs cache EID-
   prefixes with mask-lengths that are greater than or equal to a
   configured prefix length.  This limits the damage to a specific width
   of any EID-prefix advertised, but needs to be coordinated with the
   allocation of site prefixes.  These solutions can be used
   independently or at the same time.

   At the time of this writing, other approaches are being considered
   and researched.

6.1.6.  Map-Register Message Format

   The usage details of the Map-Register message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent in UDP with a destination UDP port of 4342 and a
   randomly selected UDP source port number.

   The Map-Register message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3 |P|            Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved Rsvd  |  Map-Version Number   |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags      |R|     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   3 (Map-Register)

   P: Set This is the proxy-map-reply bit, when set to 1 by an ETR which sends a Map-Register Map-
      Register message requesting for the Map-Server to proxy Map-Reply.
      The Map-Server will send non-authoritative Map-Replies on behalf
      of the ETR.  Details on this usage will be provided in a future
      version of this draft.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   Record Count:  The number of records in this Map-Register message.  A
      record is comprised of that portion of the packet labeled 'Record'
      above and occurs the number of times equal to Record count.

   Nonce:  This 8-byte Nonce field is set to 0 in Map-Register messages.

   Key ID:  A configured ID to find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The length in bytes of the
      Authentication Data field that follows this field.  The length of
      the the Authentication Data field is dependent on the Message
      Authentication Code (MAC) algorithm used.  The length field allows
      a device that doesn't know the MAC algorithm to correctly parse
      the packet.

   Authentication Data:  The message digest used from the output of the
      Message Authentication Code (MAC) algorithm.  The entire Map-
      Register payload is authenticated with this field preset to 0.
      After the MAC is computed, it is placed in this field.
      Implementations of this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   The definition of the rest of the Map-Register can be found in the
   Map-Reply section.  However, the record TTL field is not used and set
   to 0.

6.1.7.  Encapsualted  Encapsulated Control Message Format

   An Encapsulated Control Message is used to encapsulate control
   packets sent between xTRs and the mapping database system described
   in [LISP-MS].

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=8 |                   Reserved                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   IH  |                  (uses RLOC or EID addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The outer IPv4 or IPv6 header which uses RLOC addresses in the
      source and destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source
      port is randomly allocated.  The checksum field MUST be non-zero.

   LH:   Type 8 is defined to be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or IPv6 header as encoded by
      the first 4 bits after the reserved field.

   IH:   The inner IPv4 or IPv6 header which can use either RLOC or EID
      addresses in the header address fields.  When a Map-Request is
      encapsulated in this packet format the destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on the
      control packet being encapsulated.  When the control packet is a
      Map-Request or Map-Register, the source port is randomly assigned
      and the destination port is 4342.  When the control packet is a
      Map-Reply, the source port is 4342 and the destination port is
      assigned from the source port of the invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be non-zero.

   LCM:   The format is one of the control message formats described in
      this section.  At this time, only Map-Request messages and PIM
      Join-Prune messages [MLISP] are allowed to be encapsulated.
      Encapsulating other types of LISP control messages are for further
      study.  When Map-Requests are sent for RLOC-probing purposes (i.e
      the P-bit probe-bit is set), they MUST not NOT be sent inside Encapsulated
      Control Messages.

6.2.  Routing Locator Selection

   Both client-side and server-side may need control over the selection
   of RLOCs for conversations between them.  This control is achieved by
   manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information may be gleaned from
   received tunneled packets or EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for choosing RLOCs and
   the controls that are available:

   o  Server-side returns one RLOC.  Client-side can only use one RLOC.
      Server-side has complete control of the selection.

   o  Server-side returns a list of RLOC where a subset of the list has
      the same best priority.  Client can only use the subset list
      according to the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing of control exists: the server-side determines the
      destination RLOC list and load distribution while the client-side
      has the option of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight of 0 for the RLOC subset list.  In this
      case, the client-side can choose how the traffic load is spread
      across the subset list.  Control is shared by the server-side
      determining the list and the client determining load distribution.
      Again, the client can use alternative RLOCs if the server-provided
      list of RLOCs are unreachable.

   o  Either side (more likely on the server-side ETR) decides not to
      send a Map-Request.  For example, if the server-side ETR does not
      send Map-Requests, it gleans RLOCs from the client-side ITR,
      giving the client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR RLOC is done by caching the inner header source
      EID and the outer header source RLOC of received packets.  The
      client-side ITR controls how traffic is returned and can alternate
      using an outer header source RLOC, which then can be added to the
      list the server-side ETR uses to return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR must MUST assume each client-side ITR RLOC uses the same best
      Priority with a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed in data packets, the EID-to-RLOC cache
      on tunnel routers can grow to be very large.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the Routing Locator Reachability Algorithms described in the
   next section.

6.3.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the LISP header of an
       encapsulated data packet received from an ITR.  If the ETR is
       also acting as an ITR and has traffic to return to the original
       ITR site, it can use this status information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  An ITR which participates in the global routing system can
       determine that an RLOC is down if no BGP RIB route exists that
       matches the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts to use
       interworking [INTERWORK] and LISP-encapsulated data is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR, the
       source RLOC from the outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at the site.  CE-based ITRs at the source
   site can determine reachability relative to each other using the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP.

   o  If an ITR fails or if the upstream link to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack of a default route
   originated by the others to determine the Locator Status Bits it sets
   for them.

   RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit.  For example, if an RLOC
   listed in the 3rd position of the Map-Reply goes down (ordinal value
   2), then all ITRs at the site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to an RLOC that is indicated as
   down.  It will only resume using that RLOC if the corresponding Loc-
   Status-Bit returns to a value of 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the Loc-Status-Bit that corresponds to that locator's
   position in the list returned by the last Map-Reply will be set to
   zero for that particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can
   still be used to determine the reachability of Locators provided they
   are injected into the IGP.  This is typically done when a /32 address
   is configured on a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as a
   method to determine unreachability, they will refrain from using
   Locators which are described in Locator lists of Map-Replies.
   However, using this approach is unreliable because many network
   operators turn off generation of ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or Host Unreachable message,
   it MAY originate its own ICMP Unreachable message destined for the
   host that originated the data packet the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if
   a locator address from a locator-set in a mapping entry matches a
   prefix.  If it does not find one and BGP is running in the Default
   Free Zone (DFZ), it can decide to not use the locator even though the
   Loc-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can send a Map-Request to a Locator and if a Map-
   Reply is returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages originated by tunnel routers for active flows, so Locators
   are assumed to be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the receipt of ICMP Host Unreachable messages.  When an
   Locator has been determined to be unreachable, it is not used for
   active traffic; this is the same as if it were listed in a Map-Reply
   with priority 255.

   The ITR can test the reachability of the unreachable Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the risk of packet loss for end-to-end
   sessions.

   When an ETR decapsulates a packet, it knows that it is reachable from
   the encapsulating ITR because that is how the packet arrived.  In
   most cases, the ETR can also reach the ITR but cannot assume this to
   be true due to the possibility of path asymmetry.  In the presence of
   unidirectional traffic flow from an ITR to an ETR, the ITR should not SHOULD NOT
   use the lack of return traffic as an indication that the ETR is
   unreachable.  Instead, it must MUST use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there is bidirectional data flow flows bidirectionally between a pair of locators, locators from different
   sites, a simple mechanism called "nonce echoing" can be used to
   determine reachability between an ITR and ETR.  When an ITR wants to
   solicit a nonce echo, it sets the N and E bits and places a 24-bit
   nonce in the LISP header of the next encapsulated data packet.

   When this packet is received by the ETR, the encapsulated packet is
   forwarded as normal.  When the ETR next sends a data packet to the
   ITR, it includes the nonce received earlier with the N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path to
   and from the ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is unreachable is variable
   and a choice left for the implementation.

   If the ITR is receiving packets from the ETR but does not see the
   nonce echoed while being in echo-nonce-request state, then the path
   to the ETR is unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the ETR is down it can switch to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices must MUST
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the same
   time.  The number of packets sent or the time during which echo nonce
   requests are sent is an implementation specific setting.  However,
   when an ITR is in echo-nonce-request state, it can echo the ETR's
   nonce in the next set of packets that it encapsulates and then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve the forward path
   reachability problem as traffic may be unidirectional.  That is, the
   ETR receiving traffic at a site may not may not be the same device as an ITR
   which transmits traffic from that site or the site to site traffic is
   unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the nonce does not occur and the requesting side may
   regard the locator unreachable erroneously.  An ITR should SHOULD only set
   the E-bit in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the Map-
   Reply message.

   Note that other locator reachability mechanisms are being researched
   and can be used to compliment or even override the Echo Nonce
   Algorithm.  See next section for an example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR can use to determine the
   reachability status of one or more locators that it has cached in a
   map-cache entry.  The P-bit (Probe Bit) probe-bit of the Map-Request and Map-
   Reply Map-Reply
   messages are used for RLOC Probing.

   RLOC probing is done in the control-plane on a timer basis where an
   ITR or PTR will originate a Map-Request destined to a locator address
   from one of its own locator addresses.  A Map-Request used as an
   RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the Map-Request is the EID-prefix of the map-cache entry
   cached by the ITR or PTR.  The ITR or PTR may include a mapping data
   record for its own database mapping information.

   When an ETR receives a Map-Request message with the P-bit probe-bit set, it
   returns a Map-Reply with the P-bit probe-bit set.  The source address of
   the Map-Reply is set from the destination address of the Map-Request
   and the destination address of the Map-Reply is set from the source
   address of the Map-Request.  The Map-Reply should SHOULD contain mapping
   data for the EID-prefix contained in the Map-Request.  This provides
   the opportunity for the ITR or PTR, which sent the RLOC-probe to get
   mapping updates if there were changes to the ETR's database mapping
   entries.

   There are advantages and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing is that it can handle many failure scenarios
   allowing the ITR to determine when the path to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator from the cached
   locator.  RLOC Probing can also provide rough RTT estimates between a
   pair of locators which can be useful for network management purposes
   as well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in the number of control messages required and the
   amount of bandwidth used to obtain those benefits, especially if the
   requirement for failure detection times are very small.

   Continued research and testing will attempt to characterize the
   tradeoffs of failure detection times versus message overhead.

6.4.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
   a requesting ITR, the locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best priority locator exists, the ITR can decide how to load
   share traffic against the corresponding locators.

   The following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash can be used or the
       traditional 5-tuple hash which includes the source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only from the header are used to
       compute the hash.

   2.  Take the hash value and divide it by the number of locators
       stored in the locator-set for the EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the remainder to select the locator in the
       locator-set.

   Note that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs to be set.  Selecting a random value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links of
   such LAGs.  Otherwise, core routers would see a single flow, since
   packets have a source address of the ITR, for packets which are
   originated by different EIDs at the source site.  A suggested setting
   for the source port number computed by an ITR is a 5-tuple hash
   function on the inner header, as described above.

   Many core router implementations use a 5-tuple hash to decide how to
   balance packet load across members of a LAG.  The 5-tuple hash
   includes the source and destination addresses of the packet and the
   source and destination ports when the protocol number in the packet
   is TCP or UDP.  For this reason, UDP encoding is used for LISP
   encapsulation.

6.5.  Changing the Contents of EID-to-RLOC Mappings

   Since the LISP architecture uses a caching scheme to retrieve and
   store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, the ITRs do not
   know when the mappings change and the ETRs do not keep track of who
   requested its mappings.  For scalability reasons, we want to maintain
   this approach but need to provide a way for ETRs change their
   mappings and inform the sites that are currently communicating with
   the ETR site using such mappings.

   When a locator record is added to the end of a locator-set, it is
   easy to update mappings.  We assume new mappings will maintain the
   same locator ordering as the old mapping but just have new locators
   appended to the end of the list.  So some ITRs can have a new mapping
   while other ITRs have only an old mapping that is used until they
   time out.  When an ITR has only an old mapping but detects bits set
   in the loc-status-bits that correspond to locators beyond the list it
   has cached, it simply ignores them.  However, this can only happen
   for locator addresses that are lexicographically greater than the
   locator addresses in the existing locator-set.

   When a locator record is removed from a locator-set, ITRs that have
   the mapping cached will not use the removed locator because the xTRs
   will set the loc-status-bit to 0.  So even if the locator is in the
   list, it will not be used.  For new mapping requests, the xTRs can
   set the locator AFI to 0 (indicating an unspecified address), as well
   as setting the corresponding loc-status-bit to 0.  This forces ITRs
   with old or new mappings to avoid using the removed locator.

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the locator-set and new
   records appended to the locator-set.  At some point, it would be
   useful to compact the locator-set so the loc-status-bit settings can
   be efficiently packed.

   We propose here two three approaches for locator-set compaction, one
   operational and the other a two protocol mechanism. mechanisms.  The operational approach
   uses a clock sweep method.  The protocol approach uses approaches use the concept
   of Solicit-Map-Requests. Solicit-Map-Requests and Map-Versioning.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning in advance and the use of
   count-down TTLs to time out mappings that have already been cached.
   The default setting for an EID-to-RLOC mapping TTL is 24 hours.  So
   there is a 24 hour window to time out old mappings.  The following
   clock sweep procedure is used:

   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the ETRs at a site to start the clock
       sweep window.

   2.  During the clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have timed out,
       and any active cache entries will time out within 1 hour.  During
       this 1 hour window the ETRs continue to send Map-Reply messages
       with the current (unchanged) mapping records with the TTL set to
       1 minute.

   4.  At the end of the 1 hour window, the ETRs will send Map-Reply
       messages with the new (changed) mapping records.  So any active
       caches can get the new mapping contents right away if not cached,
       or in 1 minute if they had the mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for xTRs, at the site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to tell remote ITRs to update
   the mappings they have cached.

   Since the xTRs don't keep track of remote ITRs that have cached their
   mappings, they can not tell exactly who needs the new mapping
   entries.  So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to, and only from those sites.
   The xTRs can locally decide the algorithm for how often and to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in a Map-Request message.  An ITR
   or PTR will send a Map-Request when they receive an SMR message.
   Both the SMR sender and the Map-Request responder must MUST rate-limited
   these messages.

   The following procedure shows how a SMR exchange occurs when a site
   is doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the database mappings in an ETR change, the ETRs at the site
       begin to send Map-Requests with the SMR bit set for each locator
       in each map-cache entry the ETR caches.

   2.  A remote xTR which receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message.  A newly allocated random nonce is selected and the EID-
       prefix uses used is the one copied from the SMR message.

   3.  The remote xTR retransmits MUST rate-limit the Map-Request slowly until it gets a
       Map-Reply while continuing to use the cached mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message provided the Map-Request
       nonce matches the nonce from the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the site with the changed mapping, records record the fact
       that the site that sent the Map-Request has received the new
       mapping data in the mapping cache entry for the remote site so
       the loc-status-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending SMR
       messages.

   For security reasons an ITR MUST NOT process unsolicited Map-Replies.
   The nonce MUST be carried from SMR packet, into the resultant Map-
   Request, and then into Map-Reply to reduce spoofing attacks.

   To avoid map-cache entry corruption by a third-party, a sender of an
   SMR-based Map-Request must MUST be verified.  If an ITR receives an SMR-
   based Map-Request and the source is not in the locator-set for the
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to the mapping database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it will deliver the Map-Request to the authoritative source of the
   mapping data.

6.5.3.  Database Map Versioning

   When there is unidirectional packet flow between an ITR and ETR, and
   the EID-to-RLOC mappings change on the ETR, it needs to inform the
   ITR so encapsulation can stop to a removed locator and start to a new
   locator in the locator-set.

   An ETR, when it sends Map-Reply messages, conveys its own Map-Version
   number.  This is known as the Destination Map-Version Number.  ITRs
   include the Destination Map-Version Number in packets they
   encapsulate to the site.  When an ETR decapsulates a packet and
   detects the Destination Map-Version Number is less than the current
   version for its mapping, the SMR procedure described in Section 6.5.2
   occurs.

   An ITR, when it encapsulates packets to ETRs, can convey its own Map-
   Version number.  This is known as the Source Map-Version Number.

   When an ETR decapsulates a packet and detects the Source Map-Version
   Number is greater than the last Map-Version Number sent in a Map-
   Reply from the ITR's site, the ETR will send a Map-Request to one of
   the ETRs for the source site.

   A Map-Version Number is used as a sequence number per EID-prefix.  So
   values that are greater, are considered to be more recent.  A value
   of 0 for the Source Map-Version Number or the Destination Map-Version
   Number conveys no versioning information and an xTR does no
   comparison with previously received Map-Version Numbers.

   A Map-Version Number can be included in Map-Register messages as
   well.  This is a good way for the Map-Server can assure that all ETRs
   for a site registering to it will be Map-Version number synchronized.

   See [VERSIONING] for a more detailed analysis and description of
   Database Map Versioning.

7.  Router Performance Considerations

   LISP is designed to be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] and stripping instead of re-
   writing addresses, existing hardware can support the forwarding model
   with little or no modification.  Where modifications are required,
   they should be limited to re-programming existing hardware rather
   than requiring expensive design changes to hard-coded algorithms in
   silicon.

   A few implementation techniques can be used to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special FIB entries
      for the EID-prefixes of EIDs served by the ETR (those for which
      the router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be performed.  The forwarding logic of testing for particular IP
      protocol number value is not necessary.  No changes to existing,
      deployed hardware should be needed to support this.

   o  On an ITR, prepending a new IP header is as simple as adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this action.

   o  When a received packet's outer destination address contains an EID
      which is not intended to be forwarded on the routable topology
      (i.e.  LISP 1.5), the source address of a data packet or the
      router interface with which the source is associated (the
      interface from which it was received) can be associated with a VRF
      (Virtual Routing/Forwarding), in which a different (i.e. non-
      congruent) topology can be used to find EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and will discuss the pros and cons of each deployment scenario.
   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or re-encapsulating
   tunneling.

   When deciding on centralized versus distributed caching, the
   following issues should be considered:

   o  Are the tunnel routers spread out so that the caches are spread
      across all the memories of each router?

   o  Should management "touch points" be minimized by choosing few
      tunnel routers, just enough for redundancy?

   o  In general, using more ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, the
   following issues should be considered:

   o  Flat tunneling implements a single tunnel between source site and
      destination site.  This generally offers better paths between
      sources and destinations with a single tunnel path.

   o  Recursive tunneling is when tunneled traffic is again further
      encapsulated in another tunnel, either to implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the
      site has some control since the site is prepending a new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is prepending a new tunnel header, but if the site's
      ISP is doing the TE, then the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at the
      benefit of steering traffic to resource available parts of the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated with
      a new tunnel header using a new RLOC.

   The next sub-sections will describe where tunnel routers can reside
   in the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to hosts, the EID-prefix set is at
   the granularity of an IP subnet.  So at the expense of more EID-
   prefix-to-RLOC sets for the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on the number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Map-Replies are traveling between more routers.

   The advantage of placing the caches and databases at these stub
   routers is that the products deployed in this part of the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in these devices and fewer routes
   are stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and routing state.

   LISP functionality can also be deployed in edge switches.  These
   devices generally have layer-2 ports facing hosts and layer-3 ports
   facing the Internet.  Spare capacity is also often available in these
   devices as well.

8.2.  Border/Edge Tunnel Routers

   Using customer-edge (CE) routers for tunnel endpoints allows the EID
   space associated with a site to be reachable via a small set of RLOCs
   assigned to the CE routers for that site.

   This offers the opposite benefit of the first-hop/last-hop tunnel
   router scenario: the number of mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage is that less of the network's resources are used to
   reach host endpoints thereby centralizing the point-of-failure domain
   and creating network choke points at the CE router.

   Note that more than one CE router at a site can be configured with
   the same IP address.  In this case an RLOC is an anycast address.
   This allows resilience between the CE routers.  That is, if a CE
   router fails, traffic is automatically routed to the other routers
   using the same anycast address.  However, this comes with the
   disadvantage where the site cannot control the entrance point when
   the anycast route is advertised out from all border routers.

8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers gives an ISP control
   over the location of the egress tunnel endpoints.  That is, the ISP
   can decide if the tunnel endpoints are in the destination site (in
   either CE routers or last-hop routers within a site) or at other PE
   edges.  The advantage of this case is that two or more tunnel headers
   can be avoided.  By having the PE be the first router on the path to
   encapsulate, it can choose a TE path first, and the ETR can
   decapsulate and re-encapsulate for a tunnel to the destination end
   site.

   An obvious disadvantage is that the end site has no control over
   where its packets flow or the RLOCs used.

   As mentioned in earlier sections a combination of these scenarios is
   possible at the expense of extra packet header overhead, if both site
   and provider want control, then recursive or re-encapsulating tunnels
   are used.

9.  Traceroute Considerations

   When a source host in a

8.4.  LISP site initiates a traceroute to a
   destination host Functionality with Conventional NATs

   LISP routers can be deployed behind Network Address Translator (NAT)
   devices to provide the same set of packet services hosts have today
   when they are addressed out of private address space.

   It is important to note that a locator address in any LISP control
   message MUST be a globally routable address and therefore SHOULD NOT
   contain [RFC1918] addresses.  If a LISP router is configured with
   private addresses, they MUST be used only in the outer IP header so
   the NAT device can translate properly.  Otherwise, EID addresses MUST
   be translated before encapsulation is performed.  Both NAT
   translation and LISP encapsulation functions could be co-located in
   the same device.

   More details on LISP address translation can be found in [INTERWORK].

9.  Traceroute Considerations

   When a source host in a LISP site initiates a traceroute to a
   destination host in another LISP site, it is highly desirable for it
   to see the entire path.  Since packets are encapsulated from ITR to
   ETR, the hop across the tunnel could be viewed as a single hop.
   However, LISP traceroute will provide the entire path so the user can
   see 3 distinct segments of the path from a source LISP host to a
   destination LISP host:

      Segment 1 (in source LISP site based on EIDs):

          source-host ---> first-hop ... next-hop ---> ITR

      Segment 2 (in the core network based on RLOCs):

          ITR ---> next-hop ... next-hop ---> ETR

      Segment 3 (in the destination LISP site based on EIDs):

          ETR ---> next-hop ... last-hop ---> destination-host

   For segment 1 of the path, ICMP Time Exceeded messages are returned
   in the normal matter as they are today.  The ITR performs a TTL
   decrement and test for 0 before encapsulating.  So the ITR hop is
   seen by the traceroute source has an EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are returned
   to the ITR because the TTL decrement to 0 is done on the outer
   header, so the destination of the ICMP messages are to the ITR RLOC
   address, the source source RLOC address of the encapsulated traceroute
   packet.  The ITR looks inside of the ICMP payload to inspect the
   traceroute source so it can return the ICMP message to the address of
   the traceroute client as well as retaining the core router IP address
   in the ICMP message.  This is so the traceroute client can display
   the core router address (the RLOC address) in the traceroute output.
   The ETR returns its RLOC address and responds to the TTL decrement to
   0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will be
   decrementing the TTL for the packet that was encapsulated, sent into
   the core, decapsulated by the ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the destination of the traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the traceroute client.  The ICMP message will be
   encapsulated by the local ITR and sent back to the ETR in the
   originated traceroute source site, where the packet will be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs to pay special
   attention for forwarding ICMP messages back to the traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the above procedure since IPv4
   ICMP Time Exceeded messages only include the invoking IP header and 8
   bytes that follow the IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP
   payload is the encapsulated header it prepended followed by a UDP
   header.  The original invoking IP header, and therefore the identity
   of the traceroute source is lost.

   The solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the ETR.  The
   ITR will use a circular buffer for caching the IPv4 and UDP headers
   of traceroute packets.  It will select a 16-bit number as a key to
   find them later when the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as the UDP source port in the encapsulating header.
   When the ICMP Time Exceeded message is returned to the ITR, the UDP
   header of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload
   and sends the ICMP Time Exceeded message to the traceroute source
   retaining the source address of the original ICMP Time Exceeded
   message (a core router or the ETR of the site of the traceroute
   destination).

   The signature of a traceroute packet comes in two forms.  The first
   form is encoded as a UDP message where the destination port is
   inspected for a range of values.  The second form is encoded as an
   ICMP message where the IP identification field is inspected for a
   well-known value.

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is originated and
   the ITR encapsulates it in the other address family header, you
   cannot get all 3 segments of the traceroute.  Segment 2 of the
   traceroute can not be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the tunnel look like one hop.  All the ITR has to
   do to make this work is to not copy the inner TTL to the outer,
   encapsulating header's TTL when a traceroute packet is encapsulated
   using an RLOC from a different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the ITR and ETR.

10.  Mobility Considerations

   There are several kinds of mobility of which only some might be of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in EID-RLOC mappings for sites are expected to be
   handled by configuration, outside of the LISP protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering is involved.  LISP can
   help with the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a site from the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves relatively
   rapidly, changing its IP layer network attachment point.  Maintenance
   of session continuity is a goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to be explored.

   The problem is that as an endpoint moves, it may require changes to
   the mapping between its EID and a set of RLOCs for its new network
   location.  When this is added to the overhead of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint is away from home, packets to it
   are encapsulated and forwarded via a home agent which resides in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the endpoint or to
   a foreign agent which resides where the endpoint has moved to.
   Packets from the endpoint may be sent directly to the correspondent
   node, may be sent via the foreign agent, or may be reverse-tunneled
   back to the home agent for delivery to the mobile node.  As the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between the mobile node and
   the home agent, whether via foreign agent or not.  As a mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an old location to a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one of the new visited network's ITRs, which needs a EID-RLOC
      mapping for the home agent.

   o  The home agent might not have the EID-RLOC mappings for the mobile
      node's "care-of" address or its foreign agent in the new visited
      network, in which case it will need to acquire them.

   o  When packets are sent directly to the correspondent node, it may
      be that no traffic has been sent from the new visited network to
      the correspondent node's network, and the new visited network's
      ITR will need to obtain an EID-RLOC mapping for the correspondent
      node's site.

   In addition, if the IPv4 endpoint is sending packets from the new
   visited network using its original EID, then LISP will need to
   perform a route-returnability check on the new EID-RLOC mapping for
   that EID.

   In IPv6 mobility, packets can flow directly between the mobile node
   and the correspondent node in either direction.  The mobile node uses
   its "care-of" address (EID).  In this case, the route-returnability
   check would not be needed but one more LISP mapping lookup may be
   required instead:

   o  As above, three mapping changes may be needed for the mobile node
      to communicate with its home agent and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order for the correspondent node to send packets to
      the mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the number of potential mapping
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the mobile node, correspondent node, and home agent, but also state
   changes in the ITRs and ETRs for at least some EID-prefixes.

   The goal is to support rapid adaptation, with little delay or packet
   loss for the entire system.  Heuristics can be added to LISP to
   reduce the number of mapping changes required and to reduce the delay
   per mapping change.  Also IP mobility can be modified to
   require fewer mapping changes.  In order to increase overall system
   performance, there may be a need to reduce the optimization of one
   area in order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It can do this after
   performing a route-returnability check, to ensure that the new
   network location does have a internal route to that endpoint.
   However, this does not cover the case where an ITR (the node assigned
   the RLOC) at the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment in which all
   routing information is disseminated before packets can be forwarded.
   In order to allow the Internet to grow to support expected future
   use, we are moving to an environment where some information may have
   to be obtained after packets are in flight.  Modifications to IP
   mobility should be considered in order to optimize the behavior of
   the overall system.  Anything which decreases the number of new EID-
   RLOC mappings needed when a node moves, or maintains the validity of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network" can be as small as a single router and as large as
   a whole site.  This is different from site mobility in that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any endpoint will return a binding for the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   to revisit the design of the mapping service and allow for dynamic
   updates of the database.

   The issue of interactions between mobility and LISP needs to be
   explored further.  Specific improvements to the entire system will
   depend on the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   A mobile device can use the LISP infrastructure to achieve mobility
   by implementing the LISP encapsulation and decapsulation functions
   and acting as a simple ITR/ETR.  By doing this, such a "LISP mobile
   node" can use topologically-independent EID IP addresses that are not
   advertised into and do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
   only the correspondents of the LISP mobile node.

   Refer to the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined in the original Internet
   architecture is an identifier of a grouping of topologically
   independent receiver host locations.  The address encoding itself
   does not determine the location of the receiver(s).  The multicast
   routing protocol, and the network-based state the protocol creates,
   determines where the receivers are located.

   In the context of LISP, a multicast group address is both an EID and
   a Routing Locator.  Therefore, no specific semantic or action needs
   to be taken for a destination address, as it would appear in an IP
   header.  Therefore, a group address that appears in an inner IP
   header built by a source host will be used as the destination EID.
   The outer IP header (the destination Routing Locator address),
   prepended by a LISP router, will use the same group address as the
   destination Routing Locator.

   Having said that, only the source EID and source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address in the source Routing Locator field when prepending
   the outer IP header.  This source Routing Locator address, like any
   other Routing Locator address MUST be globally routable.

   Therefore, an EID-to-RLOC mapping does not need to be performed by an
   ITR when a received data packet is a multicast data packet or when
   processing a source-specific Join (either by IGMPv3 or PIM).  But the
   source Routing Locator is decided by the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach is to have the ITR not encapsulate a multicast
   packet and allow the the host built packet to flow into the core even
   if the source address is allocated out of the EID namespace.  If the
   RPF-Vector TLV [RPFV] [RFC5496] is used by PIM in the core, then core
   routers can RPF to the ITR (the Locator address which is injected
   into core routing) rather than the host source address (the EID
   address which is not injected into core routing).

   To avoid any EID-based multicast state in the network core, the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and Interworking with non-LISP sites is described in specification
   [MLISP].

12.  Security Considerations

   It is believed that most of the security mechanisms will be part of
   the mapping database service when using control plane procedures for
   obtaining EID-to-RLOC mappings.  For data plane triggered mappings,
   as described in this specification, protection is provided against
   ETR spoofing by using Return- Routability mechanisms evidenced by the
   use of a 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  The nonce, coupled
   with the ITR accepting only solicited Map-Replies goes a long way
   toward providing decent authentication.

   LISP does not rely on a PKI infrastructure or a more heavy weight
   authentication system.  These systems challenge the scalability of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies to the control plane as well as rate-
   limiting the number of data-triggered Map-Replies.

   To deal with map-cache exhaustion attempts in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list for special or frequently accessed
   sites.  This should be a configuration policy control set by the
   network administrator who manages ITRs and PTRs.

13.  IANA Considerations

   This specification has already allocated UDP port numbers 4341 and
   4342 assigned from the IANA registry.

14.  Prototype Plans and Status

   The operator community has requested that the IETF take a practical
   approach to solving the scaling problems associated with global
   routing state growth.  This document offers a simple solution which
   is intended for use in a pilot program to gain experience in working
   on this problem.

   The authors hope that publishing this specification will allow the
   rapid implementation of multiple vendor prototypes and deployment on
   a small scale.  Doing this will help the community:

   o  Decide whether a new EID-to-RLOC mapping database infrastructure
      is needed or if a simple, UDP-based, data-triggered approach is
      flexible and robust enough.

   o  Experiment with provider-independent assignment of EIDs while at
      the same time decreasing the size of DFZ routing tables through
      the use of topologically-aligned, provider-based RLOCs.

   o  Determine whether multiple levels of tunneling can be used by ISPs
      to achieve their Traffic Engineering goals while simultaneously
      removing the more specific routes currently injected into the
      global routing system for this purpose.

   o  Experiment with mobility to determine if both acceptable
      convergence and session continuity properties can be scalably
      implemented to support both individual device roaming and site
      service provider changes.

   Here is a rough set of milestones:

   1.  Interoperable implementations have been available since the
       beginning of 2009.  We are trying to converge on a packet format
       so implementations can converge on the -04 and later drafts.

   2.  Continue pilot deployment using LISP-ALT as the database mapping
       mechanism.

   3.  Continue prototyping and studying other database lookup schemes,
       be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms.

   4.  Implement the LISP Multicast draft [MLISP].

   5.  Implement the LISP Mobile Node draft [LISP-MN].

   6.  Research more on how policy affects what gets returned in a Map-
       Reply from an ETR.

   7.  Continue to experiment with mixed locator-sets to understand how
       LISP can help the IPv4 to IPv6 transition.

   8.  Add more robustness to locator reachability between LISP sites.

   9.  Continue the deployment of Proxy-ETRs (PETRs) for uses like uRPF
       avoidance, IPv6 connectivity, and LISP-MN.

   As of this writing the following accomplishments have been achieved:

   1.   A unit- and system-tested software switching implementation has
        been completed on cisco NX-OS for this draft for both IPv4 and
        IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators.

   2.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [ALT].

   3.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [INTERWORK].  Support
        for IPv4 translation is provided and PTR support for IPv4 and
        IPv6 is provided.

   4.   The cisco NX-OS implementation supports an experimental
        mechanism for slow mobility.

   5.   There are 5 LISP implementations that exist and the first 4
        below have gone through interoperability testing at IETF
        Hiroshima, based on the draft-ietf-lisp-05.txt spec:

        1.  cisco NX-OS

        2.  OpenLISP

        3.  LISP-Click

        4.  ZLisp

        5.  cisco IOS

   6.   Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and Gregg Schudel, Andrew
        Partan and the rest of the lisp-beta team continue to test all
        the features described above on a dual-stack infrastructure.

   7.   Darrel Lewis and Dave Meyer have deployed both LISP translation
        and LISP PTR support in the pilot network.  Point your browser
        to http://www.lisp4.net to see translation happening in action
        so your non-LISP site can access a web server in a LISP site.

   8.   Soon http://www.lisp6.net will work where your IPv6 LISP site
        can talk to a IPv6 web server in a LISP site by using mixed
        address-family based locators.

   9.   An public domain implementation of LISP is underway. available.  See
        [OPENLISP] for details.

   10.  We have deployed Map-Resolvers and Map-Servers on the LISP pilot
        network to gather experience with [LISP-MS].  The first layer of
        the architecture are the xTRs which use Map-Servers for EID-
        prefix registration and Map-Resolvers for EID-to-RLOC mapping
        resolution.  The second layer are the Map-Resolvers and Map-
        Servers which connect to the ALT BGP peering infrastructure.
        And the third layer are ALT-routers which aggregate EID-prefixes
        and forward Map-Requests.

   11.  A cisco IOS implementation is underway available which currently supports
        IPv4 and IPv6 encapsulation and decapsulation features.

   12.  A LISP router based LIG implementation is supported, deployed,
        and used daily to debug and test the LISP pilot network.  See
        [LIG] for details.

   13.  A Linux implementation of LIG has been made available and
        supported by Dave Meyer.  It can be run on any Linux system
        which resides in either a LISP site or non-LISP site.  See [LIG]
        for details.  Public domain code can be downloaded from
        http://github.com/davidmeyer/lig/tree/master.

   14.  An experimental implementation has been written for three
        locator reachability algorithms.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented in this
        specification.  The third is called TCP-counts which will be
        documented in future drafts.

   15.  The LISP pilot network has been converted from using MD5 HMAC
        authentication for Map-Register messages to SHA-1 HMAC
        authentication.  ETRs send with SHA-1 but Map-Servers can
        received from either for compatibility purposes.

   If interested in writing a LISP implementation, testing any of the
   LISP implementations, or want to be part of the

   16.  The LISP pilot network is in its 3rd generation.  Current
        experiments are being performed to test EID-prefix aggregation
        at multiple service boundaries as well as deploying models for
        the existence of multiple Mapping Service Providers (MSPs).

   If interested in writing a LISP implementation, testing any of the
   LISP implementations, or want to be part of the LISP pilot program,
   please contact lisp@ietf.org.

14.

15.  References

14.1.

15.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1498]  Saltzer, J., "On the Naming and Binding of Network
              Destinations", RFC 1498, August 1993.

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

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

   [RFC1955]  Hinden, R., "New Scheme for Internet Routing and
              Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 2006.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

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

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009.

   [UDP-TUNNELS]
              Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
              Packets"", draft-eubanks-chimento-6man-00.txt (work in
              progress), February 2009.

14.2.

15.2.  Informative References

   [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-02.txt
              draft-ietf-lisp-alt-04.txt (work in progress),
              January April 2010.

   [APT]      Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01.txt (work in progress), November 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network  Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [DHTs]     Ratnasamy, S., Shenker, S., and I. Stoica, "Routing
              Algorithms for DHTs: Some Open Questions", PDF
              file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.

   [EMACS]    Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              draft-curran-lisp-emacs-00.txt (work in progress),
              November 2007.

   [GSE]      "GSE - An Alternate Addressing Architecture for  IPv6",
              draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-01.txt (work in progress),
              January
              March 2010.

   [LCAF]     Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format", draft-farinacci-lisp-lcaf-01.txt (work in
              progress), April 2010.

   [LIG]      Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-01.txt
              draft-ietf-lisp-lig-00.txt (work in progress),
              May 2009. April 2010.

   [LISA96]   Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
              "Renumbering: Threat or Menace?", Usenix , September 1996.

   [LISP-MAIN]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress),
              March 2009.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), July 2009.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-03.txt
              draft-ietf-lisp-ms-05.txt (work in progress),
              September 2009. April 2010.

   [LISP1]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP1) [Routable  ID
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
              October 2006.

   [LISP2]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP2) [DNS-based
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
              November 2006.

   [LISPDHT]  Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT:
              Towards a DHT to map identifiers onto locators",
              draft-mathy-lisp-dht-00.txt (work in progress),
              February 2008.

   [LOC-ID-ARCH]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID  Separation",
              draft-meyer-loc-id-implications-01.txt (work in progress),
              Januaryr 2009.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-ietf-lisp-multicast-02.txt
              draft-ietf-lisp-multicast-03.txt (work in progress),
              September 2009.
              April 2010.

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

   [OPENLISP]
              Iannone, L. and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-08.txt (work in progress),
              January 2009.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.txt (work in
              progress), July 2007.

   [SHIM6]    Nordmark, E.

   [VERSIONING]
              Iannone, L., Saucez, D., and M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt O. Bonaventure, "LISP Mapping
              Versioning", draft-iannone-lisp-mapping-versioning-01.txt
              (work in progress), October 2006. March 2010.

Appendix A.  Acknowledgments

   An initial thank you goes to Dave Oran for planting the seeds for the
   initial ideas for LISP.  His consultation continues to provide value
   to the LISP authors.

   A special and appreciative thank you goes to Noel Chiappa for
   providing architectural impetus over the past decades on separation
   of location and identity, as well as detailed review of the LISP
   architecture and documents, coupled with enthusiasm for making LISP a
   practical and incremental transition for the Internet.

   The authors would like Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
   Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
   Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
   Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
   Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko,
   Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra
   Trivedi, Yakov Rekhter, John Scudder, John Drake, and Dimitri
   Papadimitriou.

   In particular, we would like to thank Dave Meyer for his clever
   suggestion for the name "LISP". ;-)

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-07.txt

   o  Posted April 2010.

   o  Added I-bit to data header so LSB field can also be used as an
      Instance ID field.  When this occurs, the LSB field is reduced to
      8-bits (from 32-bits).

   o  Added V-bit to the data header so the 24-bit nonce field can also
      be used for source and destination version numbers.

   o  Added Map-Version 12-bit value to the EID-record to be used in all
      of Map-Request, Map-Reply, and Map-Register messages.

   o  Added multiple ITR-RLOC fields to the Map-Request packet so an ETR
      can decide what address to select for the destination of a Map-
      Reply.

   o  Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to
      the Locator-Set record of an EID-record for a Map-Reply message.
      The L-bit indicates which RLOCs in the locator-set are local to
      the sender of the message.  The P-bit indicates which RLOC is the
      source of a RLOC-probe Reply (Map-Reply) message.

   o  Add reference to the LISP Canonical Address Format [LCAF] draft.

   o  Made editorial and clarification changes based on comments from
      Dhirendra Trivedi.

   o  Added wordsmithing comments from Joel Halpern on DF=1 setting.

   o  Add John Zwiebel clarification to Echo Nonce Algorithm section
      6.3.1.

   o  Add John Zwiebel comment about expanding on proxy-map-reply bit
      for Map-Register messages.

   o  Add NAT section per Ron Bonica comments.

   o  Fix IDnits issues per Ron Bonica.

   o  Added section on Virtualization and Segmentation to explain the
      use if the Instance ID field in the data header.

   o  There are too many P-bits, keep their scope to the packet format
      description and refer to them by name every where else in the
      spec.

   o  Scanned all occurrences of "should", "should not", "must" and
      "must not" and uppercased them.

   o  John Zwiebel offered text for section 4.1 to modernize the
      example.  Thanks Z!

   o  Make it more clear in the definition of "EID-to-RLOC Database"
      that all ETRs need to gratefully acknowledge many people who have
   contributed discussion and ideas the same database mapping.  This
      reflects a comment from John Scudder.

   o  Add a definition "Route-returnability" to the making Definition of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
   Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
   Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
   Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
   Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko,
   Gregg Schudel, Srinivas Subramanian, Amit Jain, and Xu Xiaohu. Terms
      section.

   o  In particular, we would like section 9.2, add text to thank Dave Meyer for his clever
   suggestion for the name "LISP". ;-)

   This work originated in describe what the Routing Research Group (RRG) signature of
      traceroute packets can look like.

   o  Removed references to Data Probe for introductory example.  Data-
      probes are still part of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF LISP working group draft.

Appendix B.  Document Change Log

B.1. design but not encouraged.

   o  Added the definition for "LISP site" to the Definition of Terms"
      section.

B.2.  Changes to draft-ietf-lisp-06.txt

   Editorial based changes:

   o  Posted December 2009.

   o  Fix typo for rflags flags in LISP data header.  Changed from "4" to "5".

   o  Add text to indicate that Map-Register messages must contain a
      computed UDP checksum.

   o  Add definitions for PITR and PETR.

   o  Indicate an AFI value of 0 is an unspecified address.

   o  Indicate that the TTL field of a Map-Register is not used and set
      to 0 by the sender.  This change makes this spec consistent with
      [LISP-MS].

   o  Change "... yield a packet size of L bytes" to "... yield a packet
      size greater than L bytes".

   o  Clarify section 6.1.5 on what addresses and ports are used in Map-
      Reply messages.

   o  Clarify that LSBs that go beyond the number of locators do not to
      be SMRed when the locator addresses are greater lexicographically
      than the locator in the existing locator-set.

   o  Add Gregg, Srini, and Amit to acknowledgment section.

   o  Clarify in the definition of a LISP header what is following the
      UDP header.

   o  Clarify "verifying Map-Request" text in section 6.1.3.

   o  Add Xu Xiaohu to the acknowledgment section for introducing the
      problem of overlapping EID-prefixes among multiple sites in an RRG
      email message.

   Design based changes:

   o  Use stronger language to have the outer IPv4 header set DF=1 so we
      can avoid fragment reassembly in an ETR or PETR.  This will also
      make IPv4 and IPv6 encapsulation have consistent behavior.

   o  Map-Requests should not be sent in ECM with the Probe bit is set.
      These type of Map-Requests are used as RLOC-probes and are sent
      directly to locator addresses in the underlying network.

   o  Add text in section 6.1.5 about returning all EID-prefixes in a
      Map-Reply sent by an ETR when there are overlapping EID-prefixes
      configure.

   o  Add text in a new subsection of section 6.1.5 about dealing with
      Map-Replies with coarse EID-prefixes.

B.2.

B.3.  Changes to draft-ietf-lisp-05.txt

   o  Posted September 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in Map-Registers.  Put key-id, auth-length, and auth-
      data in Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.

   o  Make more clear what source-RLOC should be for a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

   o  Removed nonce from Map-Register message, it wasn't used so no need
      for it.

   o  Clarify what to do for unspecified Action bits for negative Map-
      Replies.  Since No Action is a drop, make value 0 Drop.

B.3.

B.4.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  How do deal with record count greater than 1 for a Map-Request.
      Damien and Joel comment.  Joel suggests: 1) Specify that senders
      compliant with the current document will always set the count to
      1, and note that the count is included for future extensibility.
      2) Specify what a receiver compliant with the draft should do if
      it receives a request with a count greater than 1.  Presumably, it
      should send some error back?

   o  Add Fred Templin in acknowledgment section.

   o  Add Margaret and Sam to the acknowledgment section for their great
      comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums on
      ETR.  From the mailing list: "You'd need to word it as an ITR MAY
      send a zero checksum, an ETR MUST accept a 0 checksum and MAY
      ignore the checksum completely.  And of course we'd need to
      confirm that can actually be implemented.  In particular, hardware
      that verifies UDP checksums on receive needs to be checked to make
      sure it permits 0 checksums."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      for MNs but often enough to get mapping updates.

   o  Indicate SHA1 can be used as well for Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about spec'ing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

   o  Margaret's comment on gleaning: "The current specification does
      not make it clear how long gleaned map entries should be retained
      in the cache, nor does it make it clear how/ when they will be
      validated.  The LISP spec should, at the very least, include a
      (short) default lifetime for gleaned entries, require that they be
      validated within a short period of time, and state that a new
      gleaned entry should never overwrite an entry that was obtained
      from the mapping system.  The security implications of storing
      "gleaned" entries should also be explored in detail."

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

   o  Change LISP header to allow a "Research Bit" so the Nonce and LSB
      fields can be turned off and used for another future purpose.  For
      Luigi et al versioning convergence.

   o  Add a N-bit to the data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

   o  Indicate when doing data-gleaning that a verifying Map-Request is
      sent to the source-EID of the gleaned data packet so we can avoid
      map-cache corruption by a 3rd party.  Comment from Pedro.

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro and Dino.

   o  Jesper made a comment to loosen the language about requiring the
      copy of inner TTL to outer TTL since the text to get mixed-AF
      traceroute to work would violate the "MUST" clause.  Changed from
      MUST to SHOULD in section 5.3.

B.4.

B.5.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from John Zwiebel in Echo-Nonce section.

B.5.

B.6.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.

B.6.

B.7.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.

   o  Added Proxy-Map-Reply bit to Map-Register.

B.7.

B.8.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com




--Apple-Mail-20--356320157
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii





--Apple-Mail-20--356320157
Content-Disposition: attachment;
	filename=draft-ietf-lisp-07.txt
Content-Type: text/plain;
	name="draft-ietf-lisp-07.txt"
Content-Transfer-Encoding: quoted-printable




Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: October 25, 2010                                       D. Lewis
                                                           cisco Systems
                                                          April 23, 2010


                 Locator/ID Separation Protocol (LISP)
                           draft-ietf-lisp-07

Abstract

   This draft describes a simple, incremental, network-based protocol to
   implement separation of Internet addresses into Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  This mechanism requires no
   changes to host stacks and no major changes to existing database
   infrastructures.  The proposed protocol can be implemented in a
   relatively small number of routers.

   This proposal was stimulated by the problem statement effort at the
   Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
   place in October 2006.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 25, 2010.

Copyright Notice



Farinacci, et al.       Expires October 25, 2010                [Page 1]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   Copyright (c) 2010 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 BSD License.


Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  Tunneling Details  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 18
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 22
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 22
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 23
     5.5.  Using Virtualization and Segmentation with LISP  . . . . . 24
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 25
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 25
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 27
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 27
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 29
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 31
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 34
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 37
       6.1.7.  Encapsulated Control Message Format  . . . . . . . . . 38
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 40
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 41
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 44
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 45
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 46
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 47
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 47
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 48
       6.5.3.  Database Map Versioning  . . . . . . . . . . . . . . . 49
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 51



Farinacci, et al.       Expires October 25, 2010                [Page 2]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 52
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 53
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 53
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 54
     8.4.  LISP Functionality with Conventional NATs  . . . . . . . . 54
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 55
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 56
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 56
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 56
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 58
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 58
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 58
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 58
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 60
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 60
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 62
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 63
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 64
   14. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 65
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 68
     15.2. Informative References . . . . . . . . . . . . . . . . . . 69
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 73
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 74
     B.1.  Changes to draft-ietf-lisp-07.txt  . . . . . . . . . . . . 74
     B.2.  Changes to draft-ietf-lisp-06.txt  . . . . . . . . . . . . 75
     B.3.  Changes to draft-ietf-lisp-05.txt  . . . . . . . . . . . . 76
     B.4.  Changes to draft-ietf-lisp-04.txt  . . . . . . . . . . . . 77
     B.5.  Changes to draft-ietf-lisp-03.txt  . . . . . . . . . . . . 79
     B.6.  Changes to draft-ietf-lisp-02.txt  . . . . . . . . . . . . 79
     B.7.  Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 79
     B.8.  Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 80
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81


















Farinacci, et al.       Expires October 25, 2010                [Page 3]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Farinacci, et al.       Expires October 25, 2010                [Page 4]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


2.  Introduction

   Many years of discussion about the current IP routing and addressing
   architecture have noted that its use of a single numbering space (the
   "IP address") for both host transport session identification and
   network routing creates scaling issues (see [CHIAPPA] and [RFC1498]).
   A number of scaling benefits would be realized by separating the
   current IP address into separate spaces for Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs); among them are:

   1.  Reduction of routing table size in the "default-free zone" (DFZ).
       Use of a separate numbering space for RLOCs will allow them to be
       assigned topologically (in today's Internet, RLOCs would be
       assigned by providers at client network attachment points),
       greatly improving aggregation and reducing the number of
       globally-visible, routable prefixes.

   2.  More cost-effective multihoming for sites that connect to
       different service providers where they can control their own
       policies for packet flow into the site without using extra
       routing table resources of core routers.

   3.  Easing of renumbering burden when clients change providers.
       Because host EIDs are numbered from a separate, non-provider-
       assigned and non-topologically-bound space, they do not need to
       be renumbered when a client site changes its attachment points to
       the network.

   4.  Traffic engineering capabilities that can be performed by network
       elements and do not depend on injecting additional state into the
       routing system.  This will fall out of the mechanism that is used
       to implement the EID/RLOC split (see Section 4).

   5.  Mobility without address changing.  Existing mobility mechanisms
       will be able to work in a locator/ID separation scenario.  It
       will be possible for a host (or a collection of hosts) to move to
       a different point in the network topology either retaining its
       home-based address or acquiring a new address based on the new
       network location.  A new network location could be a physically
       different point in the network topology or the same physical
       point of the topology with a different provider.

   This draft describes protocol mechanisms to achieve the desired
   functional separation.  For flexibility, the mechanism used for
   forwarding packets is decoupled from that used to determine EID to
   RLOC mappings.  This document covers the former.  For the latter, see
   [CONS], [ALT], [EMACS], [RPMD], and [NERD].  This work is in response
   to and intended to address the problem statement that came out of the



Farinacci, et al.       Expires October 25, 2010                [Page 5]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   RAWS effort [RFC4984].

   The Routing and Addressing problem statement can be found in [RADIR].

   This draft focuses on a router-based solution.  Building the solution
   into the network will facilitate incremental deployment of the
   technology on the Internet.  Note that while the detailed protocol
   specification and examples in this document assume IP version 4
   (IPv4), there is nothing in the design that precludes use of the same
   techniques and mechanisms for IPv6.  It should be possible for IPv4
   packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4
   RLOCs.

   Related work on host-based solutions is described in Shim6 [RFC5533]
   and HIP [RFC4423].  Related work on a router-based solution is
   described in [GSE].  This draft attempts to not compete or overlap
   with such solutions and the proposed protocol changes are expected to
   complement a host-based mechanism when Traffic Engineering
   functionality is desired.

   Some of the design goals of this proposal include:

   1.  Require no hardware or software changes to end-systems (hosts).

   2.  Minimize required changes to Internet infrastructure.

   3.  Be incrementally deployable.

   4.  Require no router hardware changes.

   5.  Minimize the number of routers which have to be modified.  In
       particular, most customer site routers and no core routers
       require changes.

   6.  Minimize router software changes in those routers which are
       affected.

   7.  Avoid or minimize packet loss when EID-to-RLOC mappings need to
       be performed.

   There are 4 variants of LISP, which differ along a spectrum of strong
   to weak dependence on the topological nature and possible need for
   routability of EIDs.  The variants are:








Farinacci, et al.       Expires October 25, 2010                [Page 6]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   LISP 1:  uses EIDs that are routable through the RLOC topology for
      bootstrapping EID-to-RLOC mappings.  [LISP1] This was intended as
      a prototyping mechanism for early protocol implementation.  It is
      now deprecated and SHOULD NOT be deployed.

   LISP 1.5:  uses EIDs that are routable for bootstrapping EID-to-RLOC
      mappings; such routing is via a separate topology.

   LISP 2:  uses EIDS that are not routable and EID-to-RLOC mappings are
      implemented within the DNS.  [LISP2]

   LISP 3:  uses non-routable EIDs that are used as lookup keys for a
      new EID-to-RLOC mapping database.  Use of Distributed Hash Tables
      [DHTs] [LISPDHT] to implement such a database would be an area to
      explore.  Other examples of new mapping database services are
      [CONS], [ALT], [RPMD], [NERD], and [APT].

   This document on LISP 1.5, and LISP 3 variants, both of which rely on
   a router-based distributed cache and database for EID-to-RLOC
   mappings.  The LISP 1.0 mechanism works but does not allow reduction
   of routing information in the default-free-zone of the Internet.  The
   LISP 2 mechanisms are put on hold and may never come to fruition
   since it is not architecturally pure to have routing depend on
   directory and directory depend on routing.  The LISP 3 mechanisms
   will be documented elsewhere but may use the control-plane options
   specified in this specification.

























Farinacci, et al.       Expires October 25, 2010                [Page 7]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


3.  Definition of Terms

   Provider Independent (PI) Addresses:   an address block assigned from
      a pool where blocks are not associated with any particular
      location in the network (e.g. from a particular service provider),
      and is therefore not topologically aggregatable in the routing
      system.

   Provider Assigned (PA) Addresses:   a block of IP addresses that are
      assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider CIDR block and is aggregated into the larger block before
      being advertised into the global Internet.  Traditionally, IP
      multihoming has been implemented by each multi-homed site
      acquiring its own, globally-visible prefix.  LISP uses only
      topologically-assigned and aggregatable address blocks for RLOCs,
      eliminating this demonstrably non-scalable practice.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
      tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
      lookup.  An EID maps to one or more RLOCs.  Typically, RLOCs are
      numbered from topologically-aggregatable blocks that are assigned
      to a site at each point to which it attaches to the global
      Internet; where the topology is defined by the connectivity of
      provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains an destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.  When used in
      discussions with other Locator/ID separation proposals, a LISP EID
      will be called a "LEID".  Throughout this document, any references
      to "EID" refers to an LEID.





Farinacci, et al.       Expires October 25, 2010                [Page 8]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   EID-prefix:   A power-of-2 block of EIDs which are allocated to a
      site by an address allocation authority.  EID-prefixes are
      associated with a set of RLOC addresses which make up a "database
      mapping".  EID-prefix allocations can be broken up into smaller
      blocks when an RLOC set is to be associated with the smaller EID-
      prefix.  A globally routed address block (whether PI or PA) is not
      an EID-prefix.  However, a globally routed address block may be
      removed from global routing and reused as an EID-prefix.  A site
      that receives an explicitly allocated EID-prefix may not use that
      EID-prefix as a globally routed prefix assigned to RLOCs.

   End-system:   is an IPv4 or IPv6 device that originates packets with
      a single IPv4 or IPv6 header.  The end-system supplies an EID
      value for the destination address field of the IP header when
      communicating globally (i.e. outside of its routing domain).  An
      end-system can be a host computer, a switch or router device, or
      any network appliance.

   Ingress Tunnel Router (ITR):   a router which accepts an IP packet
      with a single IP header (more precisely, an IP packet that does
      not contain a LISP header).  The router treats this "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally-routable RLOCs in the source address field and the
      result of the mapping lookup in the destination address field.
      Note that this destination RLOC may be an intermediate, proxy
      device that has better knowledge of the EID-to-RLOC mapping closer
      to the destination EID.  In general, an ITR receives IP packets
      from site end-systems on one side and sends LISP-encapsulated IP
      packets toward the Internet on the other side.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating hosts
      supplied EID).

   TE-ITR:   is an ITR that is deployed in a service provider network
      that prepends an additional LISP header for Traffic Engineering
      purposes.

   Egress Tunnel Router (ETR):   a router that accepts an IP packet
      where the destination address in the "outer" IP header is one of
      its own RLOCs.  The router strips the "outer" header and forwards
      the packet based on the next IP header found.  In general, an ETR
      receives LISP-encapsulated IP packets from the Internet on one
      side and sends decapsulated IP packets to site end-systems on the



Farinacci, et al.       Expires October 25, 2010                [Page 9]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


      other side.  ETR functionality does not have to be limited to a
      router device.  A server host can be the endpoint of a LISP tunnel
      as well.

   TE-ETR:   is an ETR that is deployed in a service provider network
      that strips an outer LISP header for Traffic Engineering purposes.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality is at the CE
      router.

   EID-to-RLOC Cache:   a short-lived, on-demand table in an ITR that
      stores, tracks, and is responsible for timing-out and otherwise
      validating EID-to-RLOC mappings.  This cache is distinct from the
      full "database" of EID-to-RLOC mappings, it is dynamic, local to
      the ITR(s), and relatively small while the database is
      distributed, relatively static, and much more global in scope.

   EID-to-RLOC Database:   a global distributed database that contains
      all known EID-prefix to RLOC mappings.  Each potential ETR
      typically contains a small piece of the database: the EID-to-RLOC
      mappings for the EID prefixes "behind" the router.  These map to
      one of the router's own, globally-visible, IP addresses.  The same
      database mapping entries MUST be configured on all ETRs for a
      given site.  That is, the EID-prefixes for the site and locator-
      set for each EID-prefix MUST be the same on all ETRs so they
      consistently send Map-Reply messages with the same database
      mapping contents.

   Recursive Tunneling:   when a packet has more than one LISP IP
      header.  Additional layers of tunneling may be employed to
      implement traffic engineering or other re-routing as needed.  When
      this is done, an additional "outer" LISP header is added and the
      original RLOCs are preserved in the "inner" header.  Any
      references to tunnels in this specification refers to dynamic
      encapsulating tunnels and never are they statically configured.

   Reencapsulating Tunnels:   when a packet has no more than one LISP IP
      header (two IP headers total) and when it needs to be diverted to
      new RLOC, an ETR can decapsulate the packet (remove the LISP
      header) and prepends a new tunnel header, with new RLOC, on to the
      packet.  Doing this allows a packet to be re-routed by the re-
      encapsulating router without adding the overhead of additional
      tunnel headers.  Any references to tunnels in this specification
      refers to dynamic encapsulating tunnels and never are they



Farinacci, et al.       Expires October 25, 2010               [Page 10]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


      statically configured.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
      header that follows the UDP header, an ITR prepends or an ETR
      strips.

   Address Family Identifier (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI] and [RFC1700] for details.  An
      AFI value of 0 used in this specification indicates an unspecified
      encoded address where the the length of the address is 0 bytes
      following the 16-bit AFI value of 0.

   Negative Mapping Entry:   also known as a negative cache entry, is an
      EID-to-RLOC entry where an EID-prefix is advertised or stored with
      no RLOCs.  That is, the locator-set for the EID-to-RLOC entry is
      empty or has an encoded locator count of 0.  This type of entry
      could be used to describe a prefix from a non-LISP site, which is
      explicitly not in the mapping database.  There are a set of well
      defined actions that are encoded in a Negative Map-Reply.

   Data Probe:   a LISP-encapsulated data packet where the inner header
      destination address equals the outer header destination address
      used to trigger a Map-Reply by a decapsulating ETR.  In addition,
      the original packet is decapsulated and delivered to the
      destination host.  A Data Probe is used in some of the mapping
      database designs to "probe" or request a Map-Reply from an ETR; in
      other cases, Map-Requests are used.  See each mapping database
      design for details.

   Proxy ITR (PITR):   also known as a PTR is defined and described in
      [INTERWORK], a PITR acts like an ITR but does so on behalf of non-
      LISP sites which send packets to destinations at LISP sites.

   Proxy ETR (PETR):   is defined and described in [INTERWORK], a PETR
      acts like an ETR but does so on behalf of LISP sites which send
      packets to destinations at non-LISP sites.

   Route-returnability:  is an assumption that the underlying routing
      system will deliver packets to the destination.  When combined
      with a nonce that is provided by a sender and returned by a
      receiver limits off-path data insertion.

   LISP site:  is a set of routers in an edge network that are under a
      single technical administration.  LISP routers which reside in the
      edge network are the demarcation points to separate the edge
      network from the core network.



Farinacci, et al.       Expires October 25, 2010               [Page 11]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


4.  Basic Overview

   One key concept of LISP is that end-systems (hosts) operate the same
   way they do today.  The IP addresses that hosts use for tracking
   sockets, connections, and for sending and receiving packets do not
   change.  In LISP terminology, these IP addresses are called Endpoint
   Identifiers (EIDs).

   Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC.

   This design introduces "Tunnel Routers", which prepends LISP headers
   on host-originated packets and strip them prior to final delivery to
   their destination.  The IP addresses in this "outer header" are
   RLOCs.  During end-to-end packet exchange between two Internet hosts,
   an ITR prepends a new LISP header to each packet and an egress tunnel
   router strips the new header.  The ITR performs EID-to-RLOC lookups
   to determine the routing path to the the ETR, which has the RLOC as
   one of its IP addresses.

   Some basic rules governing LISP are:

   o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.

   o  EIDs are always IP addresses assigned to hosts.

   o  LISP routers mostly deal with Routing Locator addresses.  See
      details later in Section 4.1 to clarify what is meant by "mostly".

   o  RLOCs are always IP addresses assigned to routers; preferably,
      topologically-oriented addresses from provider CIDR blocks.

   o  When a router originates packets it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g. when
      terminating a transport session such as SSH, TELNET, or SNMP), it
      may use an EID that is explicitly assigned for that purpose.  An
      EID that identifies the router as a host MUST NOT be used as an
      RLOC; an EID is only routable within the scope of a site.  A
      typical BGP configuration might demonstrate this "hybrid" EID/RLOC



Farinacci, et al.       Expires October 25, 2010               [Page 12]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


      usage where a router could use its "host-like" EID to terminate
      iBGP sessions to other routers in a site while at the same time
      using RLOCs to terminate eBGP sessions to routers outside the
      site.

   o  EIDs are not expected to be usable for global end-to-end
      communication in the absence of an EID-to-RLOC mapping operation.
      They are expected to be used locally for intra-site communication.

   o  EID prefixes are likely to be hierarchically assigned in a manner
      which is optimized for administrative convenience and to
      facilitate scaling of the EID-to-RLOC mapping database.  The
      hierarchy is based on a address allocation hierarchy which is not
      dependent on the network topology.

   o  EIDs may also be structured (subnetted) in a manner suitable for
      local routing within an autonomous system.

   An additional LISP header may be prepended to packets by a transit
   router (i.e.  TE-ITR) when re-routing of the path for a packet is
   desired.  An obvious instance of this would be an ISP router that
   needs to perform traffic engineering for packets flowing through its
   network.  In such a situation, termed Recursive Tunneling, an ISP
   transit acts as an additional ingress tunnel router and the RLOC it
   uses for the new prepended header would be either a TE-ETR within the
   ISP (along intra-ISP traffic engineered path) or a TE-ETR within
   another ISP (an inter-ISP traffic engineered path, where an agreement
   to build such a path exists).

   This specification mandates that no more than two LISP headers get
   prepended to a packet.  This avoids excessive packet overhead as well
   as possible encapsulation loops.  It is believed two headers is
   sufficient, where the first prepended header is used at a site for
   Location/Identity separation and second prepended header is used
   inside a service provider for Traffic Engineering purposes.

   Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
   For example, the ITR for a particular end-to-end packet exchange
   might be the first-hop or default router within a site for the source
   host.  Similarly, the egress tunnel router might be the last-hop
   router directly-connected to the destination host.  Another example,
   perhaps for a VPN service out-sourced to an ISP by a site, the ITR
   could be the site's border router at the service provider attachment
   point.  Mixing and matching of site-operated, ISP-operated, and other
   tunnel routers is allowed for maximum flexibility.  See Section 8 for
   more details.





Farinacci, et al.       Expires October 25, 2010               [Page 13]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


4.1.  Packet Flow Sequence

   This section provides an example of the unicast packet flow with the
   following conditions:

   o  Source host "host1.abc.com" is sending a packet to
      "host2.xyz.com", exactly what host1 would do if the site was not
      using LISP.

   o  Each site is multi-homed, so each tunnel router has an address
      (RLOC) assigned from the service provider address block for each
      provider to which that particular tunnel router is attached.

   o  The ITR(s) and ETR(s) are directly connected to the source and
      destination, respectively, but the source and destination can be
      located anywhere in LISP site.

   o  Map-Requests can be sent on the underlying routing system topology
      (LISP 1.0) or over an alternative topology [ALT].

   o  Map-Replies are sent on the underlying routing system topology.

   Client host1.abc.com wants to communicate with server host2.xyz.com:

   1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
       It does a DNS lookup on host2.xyz.com.  An A/AAAA record is
       returned.  This address is the destination EID.  The locally-
       assigned address of host1.abc.com is used as the source EID.  An
       IPv4 or IPv6 packet is built and forwarded through the LISP site
       as a normal IP packet until it reaches a LISP ITR.

   2.  The LISP ITR must be able to map the EID destination to an RLOC
       of one of the ETRs at the destination site.  The specific method
       used to do this is not described in this example.  See [ALT] or
       [CONS] for possible solutions.

   3.  The ITR will send a LISP Map-Request.  Map-Requests SHOULD be
       rate-limited.

   4.  In LISP 1.0, the Map-Request packet is routed through the
       underlying routing system.  In LISP 1.5, the Map-Request packet
       is routed on an alternate logical topology.  In either case, when
       the Map-Request arrives at one of the ETRs at the destination
       site, it will process the packet as a control message.

   5.  The ETR looks at the destination EID of the Map-Request and
       matches it against the prefixes in the ETR's configured EID-to-
       RLOC mapping database.  This is the list of EID-prefixes the ETR



Farinacci, et al.       Expires October 25, 2010               [Page 14]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


       is supporting for the site it resides in.  If there is no match,
       the Map-Request is dropped.  Otherwise, a LISP Map-Reply is
       returned to the ITR.

   6.  The ITR receives the Map-Reply message, parses the message (to
       check for format validity) and stores the mapping information
       from the packet.  This information is put in the ITR's EID-to-
       RLOC mapping cache (this is the on-demand cache, the cache where
       entries time out due to inactivity).

   7.  Subsequent packets from host1.abc.com to host2.xyz.com will have
       a LISP header prepended by the ITR using the appropriate RLOC as
       the LISP header destination address learned from the ETR.  Note,
       the packet may be sent to a different ETR than the one which
       returned the Map-Reply due to the source site's hashing policy or
       the destination site's locator-set policy.

   8.  The ETR receives these packets directly (since the destination
       address is one of its assigned IP addresses), strips the LISP
       header and forwards the packets to the attached destination host.

   In order to eliminate the need for a mapping lookup in the reverse
   direction, an ETR MAY create a cache entry that maps the source EID
   (inner header source IP address) to the source RLOC (outer header
   source IP address) in a received LISP packet.  Such a cache entry is
   termed a "gleaned" mapping and only contains a single RLOC for the
   EID in question.  More complete information about additional RLOCs
   SHOULD be verified by sending a LISP Map-Request for that EID.  Both
   ITR and the ETR may also influence the decision the other makes in
   selecting an RLOC.  See Section 6 for more details.





















Farinacci, et al.       Expires October 25, 2010               [Page 15]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


5.  Tunneling Details

   This section describes the LISP Data Message which defines the
   tunneling header used to encapsulate IPv4 and IPv6 packets which
   contain EID addresses.  Even though the following formats illustrate
   IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2
   combinations are supported as well.

   Since additional tunnel headers are prepended, the packet becomes
   larger and in theory can exceed the MTU of any link traversed from
   the ITR to the ETR.  It is recommended, in IPv4 that packets do not
   get fragmented as they are encapsulated by the ITR.  Instead, the
   packet is dropped and an ICMP Too Big message is returned to the
   source.

   Based on informal surveys of large ISP traffic patterns, it appears
   that most transit paths can accommodate a path MTU of at least 4470
   bytes.  The exceptions, in terms of data rate, number of hosts
   affected, or any other metric are expected to be vanishingly small.

   To address MTU concerns, mainly raised on the RRG mailing list, the
   LISP deployment process will include collecting data during its pilot
   phase to either verify or refute the assumption about minimum
   available MTU.  If the assumption proves true and transit networks
   with links limited to 1500 byte MTUs are corner cases, it would seem
   more cost-effective to either upgrade or modify the equipment in
   those transit networks to support larger MTUs or to use existing
   mechanisms for accommodating packets that are too large.

   For this reason, there is currently no plan for LISP to add any new
   additional, complex mechanism for implementing fragmentation and
   reassembly in the face of limited-MTU transit links.  If analysis
   during LISP pilot deployment reveals that the assumption of
   essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect,
   then LISP can be modified prior to protocol standardization to add
   support for one of the proposed fragmentation and reassembly schemes.
   Note that two simple existing schemes are detailed in Section 5.4.














Farinacci, et al.       Expires October 25, 2010               [Page 16]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


5.1.  LISP IPv4-in-IPv4 Header Format



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol =3D 17 |         Header Checksum       =
|
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port =3D xxxx      |       Dest Port =3D 4341      =
  |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
















Farinacci, et al.       Expires October 25, 2010               [Page 17]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


5.2.  LISP IPv6-in-IPv6 Header Format



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Payload Length        | Next Header=3D17|   Hop Limit   =
|
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port =3D xxxx      |       Dest Port =3D 4341      =
  |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |



Farinacci, et al.       Expires October 25, 2010               [Page 18]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


5.3.  Tunnel Header Field Descriptions

   Inner Header:  is the inner header, preserved from the datagram
      received from the originating host.  The source and destination IP
      addresses are EIDs.

   Outer Header:  is the outer header prepended by an ITR.  The address
      fields contain RLOCs obtained from the ingress router's EID-to-
      RLOC cache.  The IP protocol number is "UDP (17)" from [RFC0768].
      The DF bit of the Flags field is set to 0 when the method in
      Section 5.4.1 is used and set to 1 when the method in
      Section 5.4.2 is used.

   UDP Header:  contains a ITR selected source port when encapsulating a
      packet.  See Section 6.4 for details on the hash algorithm used to
      select a source port based on the 5-tuple of the inner header.
      The destination port MUST be set to the well-known IANA assigned
      port value 4341.

   UDP Checksum:  this field SHOULD be transmitted as zero by an ITR for
      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
      packet with a zero UDP checksum is received by an ETR, the ETR
      MUST accept the packet for decapsulation.  When an ITR transmits a
      non-zero value for the UDP checksum, it MUST send a correctly
      computed value in this field.  When an ETR receives a packet with
      a non-zero UDP checksum, it MAY choose to verify the checksum
      value.  If it chooses to perform such verification, and the
      verification fails, the packet MUST be silently dropped.  If the
      ETR chooses not to perform the verification, or performs the
      verification successfully, the packet MUST be accepted for
      decapsulation.  The handling of UDP checksums for all tunneling
      protocols, including LISP, is under active discussion within the
      IETF.  When that discussion concludes, any necessary changes will
      be made to align LISP with the outcome of the broader discussion.

   UDP Length:  for an IPv4 encapsulated packet, the inner header Total
      Length plus the UDP and LISP header lengths are used.  For an IPv6
      encapsulated packet, the inner header Payload Length plus the size
      of the IPv6 header (40 bytes) plus the size of the UDP and LISP



Farinacci, et al.       Expires October 25, 2010               [Page 19]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


      headers are used.  The UDP header length is 8 bytes.

   N: this is the nonce-present bit.  When this bit is set to 1, the
      low-order 24-bits of the first 32-bits of the LISP header contains
      a Nonce.  See Section 6.3.1 for details.  Both N and V bits MUST
      NOT be set in the same packet.  If they are, a decapsulating ETR
      MUST treat the "Nonce/Map-Version" field as having a Nonce value
      present.

   L: this is the Locator-Status-Bits field enabled bit.  When this bit
      is set to 1, the Locator-Status-Bits in the second 32-bits of the
      LISP header are in use.


     x 1 x x 0 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Locator Status Bits                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit MUST be 1.  This bit SHOULD be ignored and has no
      meaning when the N bit is set to 0.  See Section 6.3.1 for
      details.

   V: this is the Map-Version present bit.  When this bit is set to 1,
      the N bit MUST be 0.  Refer to Section 6.5.3 for more details.
      This bit indicates that the first 4 bytes of the LISP header is
      encoded as:


     0 x 0 1 x x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator Status Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I: this is the Instance ID bit.  See Section 5.5 for more details.
      When this bit is set to 1, the Locator Status Bits field is
      reduced to 8-bits and the high-order 24-bits are used as an
      Instance ID.  If the L-bit is set to 0, then the low-order 8 bits
      are transmitted as zero and ignored on receipt.  The format of the
      last 4 bytes of the LISP header would look like:






Farinacci, et al.       Expires October 25, 2010               [Page 20]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


     x x x x 1 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID                   |     LSBs      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   flags:  this 3-bit field is reserved for future flag use.  It is set
      to 0 on transmit and ignored on receipt.

   LISP Nonce:  is a 24-bit value that is randomly generated by an ITR
      when the N-bit is set to 1.  The nonce is also used when the E-bit
      is set to request the nonce value to be echoed by the other side
      when packets are returned.  When the E-bit is clear but the N-bit
      is set, a remote ITR is either echoing a previously requested
      echo-nonce or providing a random nonce.  See Section 6.3.1 for
      more details.

   LISP Locator Status Bits:  in the LISP header are set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the least
      significant bit of field.  The field is 32-bits when the I-bit is
      set to 0 and is 8 bits when the I-bit is set to 1.  When a Locator
      Status Bit is set to 1, the ITR is indicating to the ETR the RLOC
      associated with the bit ordinal has up status.  See Section 6.3
      for details on how an ITR can determine the status of other ITRs
      at the same site.  When a site has multiple EID-prefixes which
      result in multiple mappings (where each could have a different
      locator-set), the Locator Status Bits setting in an encapsulated
      packet MUST reflect the mapping for the EID-prefix that the inner-
      header source EID address matches.

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

   o  The outer header Type of Service field (or the Traffic Class
      field, in the case of IPv6) SHOULD be copied from the inner header
      Type of Service field (with one caveat, see below).

   When doing Re-encapsulated Tunneling:






Farinacci, et al.       Expires October 25, 2010               [Page 21]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   o  The new outer header Time to Live field SHOULD be copied from the
      stripped outer header Time to Live field.

   o  The new outer header Type of Service field SHOULD be copied from
      the stripped OH header Type of Service field (with one caveat, see
      below).

   Copying the TTL serves two purposes: first, it preserves the distance
   the host intended the packet to travel; second, and more importantly,
   it provides for suppression of looping packets in the event there is
   a loop of concatenated tunnels due to misconfiguration.

   The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
   field and the IPv6 Traffic Class field [RFC3168].  The ECN field
   requires special treatment in order to avoid discarding indications
   of congestion [RFC3168].  ITR encapsulation MUST copy the 2-bit ECN
   field from the inner header to the outer header.  Re-encapsulation
   MUST copy the 2-bit ECN field from the stripped outer header to the
   new outer header.  If the ECN field contains a congestion indication
   codepoint (the value is '11', the Congestion Experienced (CE)
   codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
   the stripped outer header to the surviving inner header that is used
   to forward the packet beyond the ETR.  These requirements preserve
   Congestion Experienced (CE) indications when a packet that uses ECN
   traverses a LISP tunnel and becomes marked with a CE indication due
   to congestion between the tunnel endpoints.

5.4.  Dealing with Large Encapsulated Packets

   In the event that the MTU issues mentioned above prove to be more
   serious than expected, this section proposes 2 simple mechanisms to
   deal with large packets.  One is stateless using IP fragmentation and
   the other is stateful using Path MTU Discovery [RFC1191].

   It is left to the implementor to decide if the stateless or stateful
   mechanism SHOULD be implemented.  Both or neither can be decided as
   well since it is a local decision in the ITR regarding how to deal
   with MTU issues.  Sites can interoperate with differing mechanisms.

   Both stateless and stateful mechanisms also apply to Reencapsulating
   and Recursive Tunneling.  So any actions below referring to an ITR
   also apply to an TE-ITR.

5.4.1.  A Stateless Solution to MTU Handling

   An ITR stateless solution to handle MTU issues is described as
   follows:




Farinacci, et al.       Expires October 25, 2010               [Page 22]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would receive from a source inside of
       its site.

   2.  Define L to be the maximum size, in bytes, a packet of size S
       would be after the ITR prepends the LISP header, UDP header, and
       outer network layer header of size H.

   3.  Calculate: S + H =3D L.

   When an ITR receives a packet from a site-facing interface and adds H
   bytes worth of encapsulation to yield a packet size greater than L
   bytes, it resolves the MTU issue by first splitting the original
   packet into 2 equal-sized fragments.  A LISP header is then prepended
   to each fragment.  This will ensure that the new, encapsulated
   packets are of size (S/2 + H), which is always below the effective
   tunnel MTU.

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

   This behavior is performed by the ITR when the source host originates
   a packet with the DF field of the IP header is set to 0.  When the DF
   field of the IP header is set to 1, or the packet is an IPv6 packet
   originated by the source host, the ITR will drop the packet when the
   size is greater than L, and sends an ICMP Too Big message to the
   source with a value of S, where S is (L - H).

   When the outer header encapsulation uses an IPv4 header, an
   implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
   can be avoided.  An implementation MAY set the DF bit in such headers
   to 0 if it has good reason to believe there are unresolvable path MTU
   issues between the sending ITR and the receiving ETR.

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

   An ITR stateful solution to handle MTU issues is described as follows
   and was first introduced in [OPENLISP]:

   1.  The ITR will keep state of the effective MTU for each locator per
       mapping cache entry.  The effective MTU is what the core network
       can deliver along the path between ITR and ETR.




Farinacci, et al.       Expires October 25, 2010               [Page 23]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   2.  When an IPv6 encapsulated packet or an IPv4 encapsulated packet
       with DF bit set to 1, exceeds what the core network can deliver,
       one of the intermediate routers on the path will send an ICMP Too
       Big message to the ITR.  The ITR will parse the ICMP message to
       determine which locator is affected by the effective MTU change
       and then record the new effective MTU value in the mapping cache
       entry.

   3.  When a packet is received by the ITR from a source inside of the
       site and the size of the packet is greater than the effective MTU
       stored with the mapping cache entry associated with the
       destination EID the packet is for, the ITR will send an ICMP Too
       Big message back to the source.  The packet size advertised by
       the ITR in the ICMP Too Big message is the effective MTU minus
       the LISP encapsulation length.

   Even though this mechanism is stateful, it has advantages over the
   stateless IP fragmentation mechanism, by not involving the
   destination host with reassembly of ITR fragmented packets.

5.5.  Using Virtualization and Segmentation with LISP

   When multiple organizations inside of a LISP site are using private
   addresses [RFC1918] as EID-prefixes, their address spaces MUST remain
   segregated due to possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.  See [LCAF] for details for a possible address encoding.  The
   LCAF encoding is an area for further study.

   An Instance ID can be carried in a LISP encapsulated packet.  An ITR
   that prepends a LISP header, will copy a 24-bit value, used by the
   LISP router to uniquely identify the address space.  The value is
   copied to the Instance ID field of the LISP header and the I-bit is
   set to 1.

   When an ETR decapsulate a packet, the Instance ID from the LISP
   header is used as a table identifier to locate the forwarding table
   to use for the inner destination EID lookup.

   Some examples of the 24-bit value to copy or map into the Instance ID
   field could be a 802.1Q VLAN tag or a configured VRF-ID value.










Farinacci, et al.       Expires October 25, 2010               [Page 24]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

   The following new UDP packet types are used to retrieve EID-to-RLOC
   mappings:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|  IHL  |Type of Service|          Total Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identification        |Flags|      Fragment Offset    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time to Live | Protocol =3D 17 |         Header Checksum       =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Source Routing Locator                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Traffic Class |           Flow Label                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        | Next Header=3D17|   Hop Limit   =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                     Source Routing Locator                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +



Farinacci, et al.       Expires October 25, 2010               [Page 25]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


       |                                                               |
       +                  Destination Routing Locator                  +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The LISP UDP-based messages are the Map-Request and Map-Reply
   messages.  When a UDP Map-Request is sent, the UDP source port is
   chosen by the sender and the destination UDP port number is set to
   4342.  When a UDP Map-Reply is sent, the source UDP port number is
   set to 4342 and the destination UDP port number is copied from the
   source port of either the Map-Request or the invoking data packet.

   The UDP Length field will reflect the length of the UDP header and
   the LISP Message payload.

   The UDP Checksum is computed and set to non-zero for Map-Request,
   Map-Reply, Map-Register and ECM control messages.  It MUST be checked
   on receipt and if the checksum fails, the packet MUST be dropped.

   LISP-CONS [CONS] use TCP to send LISP control messages.  The format
   of control messages includes the UDP header so the checksum and
   length fields can be used to protect and delimit message boundaries.

   This main LISP specification is the authoritative source for message
   format definitions for the Map-Request and Map-Reply messages.















Farinacci, et al.       Expires October 25, 2010               [Page 26]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


6.1.1.  LISP Packet Type Allocations

   This section will be the authoritative source for allocating LISP
   Type values.  Current allocations are:


       Reserved:                          0    b'0000'
       LISP Map-Request:                  1    b'0001'
       LISP Map-Reply:                    2    b'0010'
       LISP Map-Register:                 3    b'0011'
       LISP Encapsulated Control Message: 8    b'1000'


6.1.2.  Map-Request Message Format



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3D1 |A|M|P|S|       Reserved      |   IRC   | Record Count  =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Packet field descriptions:






Farinacci, et al.       Expires October 25, 2010               [Page 27]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.

   M: When set, it indicates a Map-Reply Record segment is included in
      the Map-Request.

   P: This is the probe-bit which indicates that a Map-Request SHOULD be
      treated as a locator reachability probe.  The receiver SHOULD
      respond with a Map-Reply with the probe-bit set, indicating the
      Map-Reply is a locator reachability probe reply, with the nonce
      copied from the Map-Request.  See Section 6.3.2 for more details.

   S: This is the SMR bit.  See Section 6.5.2 for details.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   IRC:  This 5-bit field is the ITR-RLOC Count which encodes the number
      of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this
      message.  Multiple ITR-RLOC Address fields are used so a Map-
      Replier can select which destination address to use for a Map-
      Reply.  The IRC value ranges from 0 to 31, where IRC value 0 means
      an ITR-RLOC address count of 1, an IRC value of 1 means an ITR-
      RLOC address count of 2, and so on up to an IRC value of 31, which
      means an ITR-RLOC address count of 32.

   Record Count:  The number of records in this Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   Source-EID-AFI:  Address family of the "Source EID Address" field.






Farinacci, et al.       Expires October 25, 2010               [Page 28]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, the value 0 is used.

   ITR-RLOC-AFI:  Address family of the "ITR-RLOC Address" field that
      follows this field.

   ITR-RLOC Address:  Used to give the ETR the option of selecting the
      destination address from any address family for the Map-Reply
      message.  This address MUST be a routable RLOC address.

   EID mask-len:  Mask length for EID prefix.

   EID-prefix-AFI:  Address family of EID-prefix according to [RFC5226]

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.  When a Map-Request is sent by an ITR because a
      data packet is received for a destination where there is no
      mapping entry, the EID-prefix is set to the destination IP address
      of the data packet.  And the 'EID mask-len' is set to 32 or 128
      for IPv4 or IPv6, respectively.  When an xTR wants to query a site
      about the status of a mapping it already has cached, the EID-
      prefix used in the Map-Request has the same mask-length as the
      EID-prefix returned from the site when it sent a Map-Reply
      message.

   Map-Reply Record:  When the M bit is set, this field is the size of
      the "Record" field in the Map-Reply format.  This Map-Reply record
      contains the EID-to-RLOC mapping entry associated with the Source
      EID.  This allows the ETR which will receive this Map-Request to
      cache the data if it chooses to do so.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.3.  EID-to-RLOC UDP Map-Request Message

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the latter 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.



Farinacci, et al.       Expires October 25, 2010               [Page 29]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   In all cases, the UDP source port number for the Map-Request message
   is a randomly allocated 16-bit value and the UDP destination port
   number is set to the well-known destination port number 4342.  A
   successful Map-Reply updates the cached set of RLOCs associated with
   the EID prefix range.

   One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
   be filled in by the ITR.  The number of fields (minus 1) encoded MUST
   be placed in the IRC field.  The ITR MAY include all locally
   configured locators in this list or just provide one locator address
   from each address family it supports.  If the ITR erroneously
   provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
   Request.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4342 with a LISP type value set to "Encapsulated Control Message",
   when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
   LISP encapsulated the same way from a Map-Server to an ETR.  Details
   on encapsulated Map-Requests and Map-Resolvers can be found in
   [LISP-MS].

   Map-Requests MUST be rate-limited.  It is recommended that a Map-
   Request for the same EID-prefix be sent no more than once per second.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request and it does
   not have this mapping in the map-cache, it may originate a "verifying
   Map-Request", addressed to the map-requesting ITR.  If the ETR has a
   map-cache entry that matches the "piggybacked" EID and the RLOC is in
   the locator-set for the entry, then it may send the "verifying Map-
   Request" directly to the originating Map-Request source.  If the RLOC
   is not in the locator-set, then the ETR MUST send the "verifying Map-
   Request" to the "piggybacked" EID.  Doing this forces the "verifying
   Map-Request" to go through the mapping database system to reach the
   authoritative source of information about that EID, guarding against
   RLOC-spoofing in in the "piggybacked" mapping data.













Farinacci, et al.       Expires October 25, 2010               [Page 30]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


6.1.4.  Map-Reply Message Format



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3D2 |P|E|            Reserved               | Record Count  =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Packet field descriptions:

   Type:   2 (Map-Reply)

   P: This is the probe-bit which indicates that the Map-Reply is in
      response to a locator reachability probe Map-Request.  The nonce
      field MUST contain a copy of the nonce value from the original
      Map-Request.  See Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site is enabled for the Echo-Nonce locator
      reachability algorithm.  See Section 6.3.1 for more details.

   Reserved:  Set to 0 on transmission and ignored on receipt.






Farinacci, et al.       Expires October 25, 2010               [Page 31]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   Record Count:  The number of records in this reply message.  A record
      is comprised of that portion of the packet labeled 'Record' above
      and occurs the number of times equal to Record count.

   Nonce:  A 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of the Map-
      Reply.

   Record TTL:  The time in minutes the recipient of the Map-Reply will
      store the mapping.  If the TTL is 0, the entry SHOULD be removed
      from the cache immediately.  If the value is 0xffffffff, the
      recipient can decide locally how long to store the mapping.

   Locator Count:  The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc'.  The locator count can
      be 0 indicating there are no locators for the EID-prefix.

   EID mask-len:  Mask length for EID prefix.

   ACT:  This 3-bit field describes negative Map-Reply actions.  These
      bits are used only when the 'Locator Count' field is set to 0.
      The action bits are encoded only in Map-Reply messages.  The
      actions defined are used by an ITR or PTR when a destination EID
      matches a negative mapping cache entry.  Unassigned values should
      cause a map-cache entry to be created and, when packets match this
      negative cache entry, they will be dropped.  The current assigned
      values are:



      (0) Drop:  The packet is dropped silently.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
         but natively forwarded.

      (2) Send-Map-Request:  The packet invokes sending a Map-Request.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set to 1 by an ETR.  See [CONS] for TCP-based Map-Replies.  When a
      Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the
      Authoritative bit is set to 0.  This indicates to requesting ITRs
      that the Map-Reply was not originated by a LISP node managed at
      the site that owns the EID-prefix.

   Map-Version Number:  When this 12-bit value is non-zero the Map-Reply
      sender is informing the ITR what the version number is for the
      EID-record contained in the Map-Reply.  The ETR can allocate this
      number internally but MUST coordinate this value with other ETRs



Farinacci, et al.       Expires October 25, 2010               [Page 32]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


      for the site.  When this value is 0, there is no versioning
      information conveyed.  The Map-Version Number can be included in
      Map-Request and Map-Register messages.  See Section 6.5.3 for more
      details.

   EID-AFI:  Address family of EID-prefix according to [RFC5226].

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

   Priority:  each RLOC is assigned a unicast priority.  Lower values
      are more preferable.  When multiple RLOCs have the same priority,
      they may be used in a load-split fashion.  A value of 255 means
      the RLOC MUST NOT be used for unicast forwarding.

   Weight:  when priorities are the same for multiple RLOCs, the weight
      indicates how to balance unicast traffic between them.  Weight is
      encoded as a percentage of total unicast packets that match the
      mapping entry.  If a non-zero weight value is used for any RLOC,
      then all RLOCs MUST use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to load-split traffic.  See
      Section 6.4 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.  When
      a single RLOC exists in a mapping entry, the weight value MUST be
      set to 100 and ignored on receipt.

   M Priority:  each RLOC is assigned a multicast priority used by an
      ETR in a receiver multicast site to select an ITR in a source
      multicast site for building multicast distribution trees.  A value
      of 255 means the RLOC MUST NOT be used for joining a multicast
      distribution tree.

   M Weight:  when priorities are the same for multiple RLOCs, the
      weight indicates how to balance building multicast distribution
      trees across multiple ITRs.  The weight is encoded as a percentage
      of total number of trees build to the source site identified by
      the EID-prefix.  If a non-zero weight value is used for any RLOC,
      then all RLOCs MUST use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to distribute multicast state across
      ITRs.







Farinacci, et al.       Expires October 25, 2010               [Page 33]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   Unused Flags:  set to 0 when sending and ignored on receipt.

   L: when this bit is set, the locator is flagged as a local locator to
      the ETR that is sending the Map-Reply.  When a Map-Server is doing
      proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to
      0 for all locators in this locator-set.

   p: when this bit is set, an ETR informs the RLOC-probing ITR that the
      locator address, for which this bit is set, is the one being RLOC-
      probed and may be different from the source address of the Map-
      Reply.  An ITR that RLOC-probes a particular locator, MUST use
      this locator for retrieving the data structure used to store the
      fact that the locator is reachable.  The "p" bit is set for a
      single locator in the same locator set.  If an implementation sets
      more than one "p" bit erroneously, the receiver of the Map-Reply
      MUST select the first locator.  The "p" bit MUST NOT be set for
      locator-set records sent in Map-Request and Map-Register messages.

   R: when this bit is set, the locator is known to be reachable from
      the Map-Reply sender's perspective.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR or router acting as a proxy replier for the
      EID-prefix.  Note that the destination RLOC address MAY be an
      anycast address.  A source RLOC can be an anycast address as well.
      The source or destination RLOC MUST NOT be the broadcast address
      (255.255.255.255 or any subnet broadcast address known to the
      router), and MUST NOT be a link-local multicast address.  The
      source RLOC MUST NOT be a multicast address.  The destination RLOC
      SHOULD be a multicast address if it is being mapped from a
      multicast destination EID.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.5.  EID-to-RLOC UDP Map-Reply Message

   When a Data Probe packet or a Map-Request triggers a Map-Reply to be
   sent, the RLOCs associated with the EID-prefix matched by the EID in
   the original packet destination IP address field will be returned.
   The RLOCs in the Map-Reply are the globally-routable IP addresses of
   the ETR but are not necessarily reachable; separate testing of
   reachability is required.

   Note that a Map-Reply may contain different EID-prefix granularity
   (prefix + length) than the Map-Request which triggers it.  This might
   occur if a Map-Request were for a prefix that had been returned by an



Farinacci, et al.       Expires October 25, 2010               [Page 34]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   earlier Map-Reply.  In such a case, the requester updates its cache
   with the new prefix information and granularity.  For example, a
   requester with two cached EID-prefixes that are covered by a Map-
   Reply containing one, less-specific prefix, replaces the entry with
   the less-specific EID-prefix.  Note that the reverse, replacement of
   one less-specific prefix with multiple more-specific prefixes, can
   also occur but not by removing the less-specific prefix rather by
   adding the more-specific prefixes which during a lookup will override
   the less-specific prefix.

   When an ETR is configured with overlapping EID-prefixes, a Map-
   Request with an EID that longest matches any EID-prefix MUST be
   returned in a single Map-Reply message.  For instance, if an ETR had
   database mapping entries for EID-prefixes:

     10.0.0.0/8
     10.1.0.0/16
     10.1.1.0/24
     10.1.2.0/24

   A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
   count of 1 to be returned with a mapping record EID-prefix of
   10.1.1.0/24.

   A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record
   count of 3 to be returned with mapping records for EID-prefixes
   10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.

   Note that not all overlapping EID-prefixes need to be returned, only
   the more specifics (note in the second example above 10.0.0.0/8 was
   not returned for requesting EID 10.1.5.5) entries for the matching
   EID-prefix of the requesting EID.  When more than one EID-prefix is
   returned, all SHOULD use the same Time-to-Live value so they can all
   time out at the same time.  When a more specific EID-prefix is
   received later, its Time-to-Live value in the Map-Reply record can be
   stored even when other less specifics exist.  When a a less specific
   EID-prefix is received later, its map-cache expiration time SHOULD be
   set to the minimum expiration time of any more specific EID-prefix in
   the map-cache.

   Map-Replies SHOULD be sent for an EID-prefix no more often than once
   per second to the same requesting router.  For scalability, it is
   expected that aggregation of EID addresses into EID-prefixes will
   allow one Map-Reply to satisfy a mapping for the EID addresses in the
   prefix range thereby reducing the number of Map-Request messages.

   Map-Reply records can have an empty locator-set.  This type of a Map-
   Reply is called a Negative Map-Reply.  Negative Map-Replies convey



Farinacci, et al.       Expires October 25, 2010               [Page 35]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   special actions by the sender to the ITR or PTR which have solicited
   the Map-Reply.  There are two primary applications for Negative Map-
   Replies.  The first is for a Map-Resolver to instruct an ITR or PTR
   when a destination is for a LISP site versus a non-LISP site.  And
   the other is to source quench Map-Requests which are sent for non-
   allocated EIDs.

   For each Map-Reply record, the list of locators in a locator-set MUST
   appear in the same order for each ETR that originates a Map-Reply
   message.  The locator-set MUST be sorted in order of ascending IP
   address where an IPv4 locator address is considered numerically 'less
   than' an IPv6 locator address.

   When sending a Map-Reply message, the destination address is copied
   from the one of the ITR-RLOC fields from the Map-Request.  The ETR
   can choose a locator address from one of the address families it
   supports.  For Data-Probes, the destination address of the Map-Reply
   is copied from the source address of the Data-Probe message which is
   invoking the reply.  The source address of the Map-Reply is one of
   the local locator addresses listed in the locator-set of any mapping
   record in the message and SHOULD be chosen to allow uRPF checks to
   succeed in the upstream service provider.  The destination port of a
   Map-Reply message is copied from the source port of the Map-Request
   or Data-Probe and the source port of the Map-Reply message is set to
   the well-known UDP port 4342.

6.1.5.1.  Traffic Redirection with Coarse EID-Prefixes

   When an ETR is misconfigured or compromised, it could return coarse
   EID-prefixes in Map-Reply messages it sends.  The EID-prefix could
   cover EID-prefixes which are allocated to other sites redirecting
   their traffic to the locators of the compromised site.

   To solve this problem, there are two basic solutions that could be
   used.  The first is to have Map-Servers proxy-map-reply on behalf of
   ETRs so their registered EID-prefixes are the ones returned in Map-
   Replies.  Since the interaction between an ETR and Map-Server is
   secured with shared-keys, it is more difficult for an ETR to
   misbehave.  The second solution is to have ITRs and PTRs cache EID-
   prefixes with mask-lengths that are greater than or equal to a
   configured prefix length.  This limits the damage to a specific width
   of any EID-prefix advertised, but needs to be coordinated with the
   allocation of site prefixes.  These solutions can be used
   independently or at the same time.

   At the time of this writing, other approaches are being considered
   and researched.




Farinacci, et al.       Expires October 25, 2010               [Page 36]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


6.1.6.  Map-Register Message Format

   The usage details of the Map-Register message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent in UDP with a destination UDP port of 4342 and a
   randomly selected UDP source port number.

   The Map-Register message format is:



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3D3 |P|            Reserved                 | Record Count  =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Packet field descriptions:








Farinacci, et al.       Expires October 25, 2010               [Page 37]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   Type:   3 (Map-Register)

   P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map-
      Register message requesting for the Map-Server to proxy Map-Reply.
      The Map-Server will send non-authoritative Map-Replies on behalf
      of the ETR.  Details on this usage will be provided in a future
      version of this draft.

   Reserved:  Set to 0 on transmission and ignored on receipt.

   Record Count:  The number of records in this Map-Register message.  A
      record is comprised of that portion of the packet labeled 'Record'
      above and occurs the number of times equal to Record count.

   Nonce:  This 8-byte Nonce field is set to 0 in Map-Register messages.

   Key ID:  A configured ID to find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The length in bytes of the
      Authentication Data field that follows this field.  The length of
      the the Authentication Data field is dependent on the Message
      Authentication Code (MAC) algorithm used.  The length field allows
      a device that doesn't know the MAC algorithm to correctly parse
      the packet.

   Authentication Data:  The message digest used from the output of the
      Message Authentication Code (MAC) algorithm.  The entire Map-
      Register payload is authenticated with this field preset to 0.
      After the MAC is computed, it is placed in this field.
      Implementations of this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   The definition of the rest of the Map-Register can be found in the
   Map-Reply section.  However, the record TTL field is not used and set
   to 0.

6.1.7.  Encapsulated Control Message Format

   An Encapsulated Control Message is used to encapsulate control
   packets sent between xTRs and the mapping database system described
   in [LISP-MS].







Farinacci, et al.       Expires October 25, 2010               [Page 38]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port =3D xxxx      |       Dest Port =3D 4342      =
  |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=3D8 |                   Reserved                            =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   IH  |                  (uses RLOC or EID addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port =3D xxxx      |       Dest Port =3D yyyy      =
  |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The outer IPv4 or IPv6 header which uses RLOC addresses in the
      source and destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source
      port is randomly allocated.  The checksum field MUST be non-zero.

   LH:   Type 8 is defined to be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or IPv6 header as encoded by
      the first 4 bits after the reserved field.

   IH:   The inner IPv4 or IPv6 header which can use either RLOC or EID
      addresses in the header address fields.  When a Map-Request is
      encapsulated in this packet format the destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on the
      control packet being encapsulated.  When the control packet is a
      Map-Request or Map-Register, the source port is randomly assigned
      and the destination port is 4342.  When the control packet is a
      Map-Reply, the source port is 4342 and the destination port is
      assigned from the source port of the invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum



Farinacci, et al.       Expires October 25, 2010               [Page 39]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


      field MUST be non-zero.

   LCM:   The format is one of the control message formats described in
      this section.  At this time, only Map-Request messages and PIM
      Join-Prune messages [MLISP] are allowed to be encapsulated.
      Encapsulating other types of LISP control messages are for further
      study.  When Map-Requests are sent for RLOC-probing purposes (i.e
      the probe-bit is set), they MUST NOT be sent inside Encapsulated
      Control Messages.

6.2.  Routing Locator Selection

   Both client-side and server-side may need control over the selection
   of RLOCs for conversations between them.  This control is achieved by
   manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information may be gleaned from
   received tunneled packets or EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for choosing RLOCs and
   the controls that are available:

   o  Server-side returns one RLOC.  Client-side can only use one RLOC.
      Server-side has complete control of the selection.

   o  Server-side returns a list of RLOC where a subset of the list has
      the same best priority.  Client can only use the subset list
      according to the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing of control exists: the server-side determines the
      destination RLOC list and load distribution while the client-side
      has the option of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight of 0 for the RLOC subset list.  In this
      case, the client-side can choose how the traffic load is spread
      across the subset list.  Control is shared by the server-side
      determining the list and the client determining load distribution.
      Again, the client can use alternative RLOCs if the server-provided
      list of RLOCs are unreachable.

   o  Either side (more likely on the server-side ETR) decides not to
      send a Map-Request.  For example, if the server-side ETR does not
      send Map-Requests, it gleans RLOCs from the client-side ITR,
      giving the client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the



Farinacci, et al.       Expires October 25, 2010               [Page 40]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


      client-side ITR RLOC is done by caching the inner header source
      EID and the outer header source RLOC of received packets.  The
      client-side ITR controls how traffic is returned and can alternate
      using an outer header source RLOC, which then can be added to the
      list the server-side ETR uses to return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR MUST assume each client-side ITR RLOC uses the same best
      Priority with a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed in data packets, the EID-to-RLOC cache
      on tunnel routers can grow to be very large.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  Neither
   the information contained in a Map-Reply or that stored in the
   mapping database system provide reachability information for RLOCs.
   Such reachability needs to be determined separately, using one or
   more of the Routing Locator Reachability Algorithms described in the
   next section.

6.3.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the LISP header of an
       encapsulated data packet received from an ITR.  If the ETR is
       also acting as an ITR and has traffic to return to the original
       ITR site, it can use this status information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  An ITR which participates in the global routing system can
       determine that an RLOC is down if no BGP RIB route exists that



Farinacci, et al.       Expires October 25, 2010               [Page 41]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


       matches the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts to use
       interworking [INTERWORK] and LISP-encapsulated data is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR, the
       source RLOC from the outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at the site.  CE-based ITRs at the source
   site can determine reachability relative to each other using the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP.

   o  If an ITR fails or if the upstream link to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack of a default route
   originated by the others to determine the Locator Status Bits it sets
   for them.

   RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit.  For example, if an RLOC
   listed in the 3rd position of the Map-Reply goes down (ordinal value
   2), then all ITRs at the site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to an RLOC that is indicated as
   down.  It will only resume using that RLOC if the corresponding Loc-
   Status-Bit returns to a value of 1.  Loc-Status-Bits are associated



Farinacci, et al.       Expires October 25, 2010               [Page 42]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the Loc-Status-Bit that corresponds to that locator's
   position in the list returned by the last Map-Reply will be set to
   zero for that particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can
   still be used to determine the reachability of Locators provided they
   are injected into the IGP.  This is typically done when a /32 address
   is configured on a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as a
   method to determine unreachability, they will refrain from using
   Locators which are described in Locator lists of Map-Replies.
   However, using this approach is unreliable because many network
   operators turn off generation of ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or Host Unreachable message,
   it MAY originate its own ICMP Unreachable message destined for the
   host that originated the data packet the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if
   a locator address from a locator-set in a mapping entry matches a
   prefix.  If it does not find one and BGP is running in the Default
   Free Zone (DFZ), it can decide to not use the locator even though the
   Loc-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can send a Map-Request to a Locator and if a Map-
   Reply is returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages originated by tunnel routers for active flows, so Locators
   are assumed to be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the receipt of ICMP Host Unreachable messages.  When an
   Locator has been determined to be unreachable, it is not used for
   active traffic; this is the same as if it were listed in a Map-Reply
   with priority 255.

   The ITR can test the reachability of the unreachable Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the risk of packet loss for end-to-end
   sessions.

   When an ETR decapsulates a packet, it knows that it is reachable from
   the encapsulating ITR because that is how the packet arrived.  In



Farinacci, et al.       Expires October 25, 2010               [Page 43]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   most cases, the ETR can also reach the ITR but cannot assume this to
   be true due to the possibility of path asymmetry.  In the presence of
   unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT
   use the lack of return traffic as an indication that the ETR is
   unreachable.  Instead, it MUST use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When data flows bidirectionally between locators from different
   sites, a simple mechanism called "nonce echoing" can be used to
   determine reachability between an ITR and ETR.  When an ITR wants to
   solicit a nonce echo, it sets the N and E bits and places a 24-bit
   nonce in the LISP header of the next encapsulated data packet.

   When this packet is received by the ETR, the encapsulated packet is
   forwarded as normal.  When the ETR next sends a data packet to the
   ITR, it includes the nonce received earlier with the N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path to
   and from the ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is unreachable is variable
   and a choice left for the implementation.

   If the ITR is receiving packets from the ETR but does not see the
   nonce echoed while being in echo-nonce-request state, then the path
   to the ETR is unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the ETR is down it can switch to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices MUST
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the same
   time.  The number of packets sent or the time during which echo nonce
   requests are sent is an implementation specific setting.  However,
   when an ITR is in echo-nonce-request state, it can echo the ETR's
   nonce in the next set of packets that it encapsulates and then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve the forward path
   reachability problem as traffic may be unidirectional.  That is, the
   ETR receiving traffic at a site may not be the same device as an ITR
   which transmits traffic from that site or the site to site traffic is
   unidirectional so there is no ITR returning traffic.



Farinacci, et al.       Expires October 25, 2010               [Page 44]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   The echo-nonce algorithm is bilateral.  That is, if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the nonce does not occur and the requesting side may
   regard the locator unreachable erroneously.  An ITR SHOULD only set
   the E-bit in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the Map-
   Reply message.

   Note that other locator reachability mechanisms are being researched
   and can be used to compliment or even override the Echo Nonce
   Algorithm.  See next section for an example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR can use to determine the
   reachability status of one or more locators that it has cached in a
   map-cache entry.  The probe-bit of the Map-Request and Map-Reply
   messages are used for RLOC Probing.

   RLOC probing is done in the control-plane on a timer basis where an
   ITR or PTR will originate a Map-Request destined to a locator address
   from one of its own locator addresses.  A Map-Request used as an
   RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the Map-Request is the EID-prefix of the map-cache entry
   cached by the ITR or PTR.  The ITR or PTR may include a mapping data
   record for its own database mapping information.

   When an ETR receives a Map-Request message with the probe-bit set, it
   returns a Map-Reply with the probe-bit set.  The source address of
   the Map-Reply is set from the destination address of the Map-Request
   and the destination address of the Map-Reply is set from the source
   address of the Map-Request.  The Map-Reply SHOULD contain mapping
   data for the EID-prefix contained in the Map-Request.  This provides
   the opportunity for the ITR or PTR, which sent the RLOC-probe to get
   mapping updates if there were changes to the ETR's database mapping
   entries.

   There are advantages and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing is that it can handle many failure scenarios
   allowing the ITR to determine when the path to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator from the cached
   locator.  RLOC Probing can also provide rough RTT estimates between a
   pair of locators which can be useful for network management purposes
   as well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in the number of control messages required and the
   amount of bandwidth used to obtain those benefits, especially if the



Farinacci, et al.       Expires October 25, 2010               [Page 45]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   requirement for failure detection times are very small.

   Continued research and testing will attempt to characterize the
   tradeoffs of failure detection times versus message overhead.

6.4.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
   a requesting ITR, the locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best priority locator exists, the ITR can decide how to load
   share traffic against the corresponding locators.

   The following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash can be used or the
       traditional 5-tuple hash which includes the source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only from the header are used to
       compute the hash.

   2.  Take the hash value and divide it by the number of locators
       stored in the locator-set for the EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the remainder to select the locator in the
       locator-set.

   Note that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs to be set.  Selecting a random value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links of
   such LAGs.  Otherwise, core routers would see a single flow, since
   packets have a source address of the ITR, for packets which are
   originated by different EIDs at the source site.  A suggested setting
   for the source port number computed by an ITR is a 5-tuple hash
   function on the inner header, as described above.

   Many core router implementations use a 5-tuple hash to decide how to
   balance packet load across members of a LAG.  The 5-tuple hash
   includes the source and destination addresses of the packet and the
   source and destination ports when the protocol number in the packet
   is TCP or UDP.  For this reason, UDP encoding is used for LISP
   encapsulation.



Farinacci, et al.       Expires October 25, 2010               [Page 46]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


6.5.  Changing the Contents of EID-to-RLOC Mappings

   Since the LISP architecture uses a caching scheme to retrieve and
   store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, the ITRs do not
   know when the mappings change and the ETRs do not keep track of who
   requested its mappings.  For scalability reasons, we want to maintain
   this approach but need to provide a way for ETRs change their
   mappings and inform the sites that are currently communicating with
   the ETR site using such mappings.

   When a locator record is added to the end of a locator-set, it is
   easy to update mappings.  We assume new mappings will maintain the
   same locator ordering as the old mapping but just have new locators
   appended to the end of the list.  So some ITRs can have a new mapping
   while other ITRs have only an old mapping that is used until they
   time out.  When an ITR has only an old mapping but detects bits set
   in the loc-status-bits that correspond to locators beyond the list it
   has cached, it simply ignores them.  However, this can only happen
   for locator addresses that are lexicographically greater than the
   locator addresses in the existing locator-set.

   When a locator record is removed from a locator-set, ITRs that have
   the mapping cached will not use the removed locator because the xTRs
   will set the loc-status-bit to 0.  So even if the locator is in the
   list, it will not be used.  For new mapping requests, the xTRs can
   set the locator AFI to 0 (indicating an unspecified address), as well
   as setting the corresponding loc-status-bit to 0.  This forces ITRs
   with old or new mappings to avoid using the removed locator.

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the locator-set and new
   records appended to the locator-set.  At some point, it would be
   useful to compact the locator-set so the loc-status-bit settings can
   be efficiently packed.

   We propose here three approaches for locator-set compaction, one
   operational and two protocol mechanisms.  The operational approach
   uses a clock sweep method.  The protocol approaches use the concept
   of Solicit-Map-Requests and Map-Versioning.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning in advance and the use of
   count-down TTLs to time out mappings that have already been cached.
   The default setting for an EID-to-RLOC mapping TTL is 24 hours.  So
   there is a 24 hour window to time out old mappings.  The following
   clock sweep procedure is used:



Farinacci, et al.       Expires October 25, 2010               [Page 47]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the ETRs at a site to start the clock
       sweep window.

   2.  During the clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have timed out,
       and any active cache entries will time out within 1 hour.  During
       this 1 hour window the ETRs continue to send Map-Reply messages
       with the current (unchanged) mapping records with the TTL set to
       1 minute.

   4.  At the end of the 1 hour window, the ETRs will send Map-Reply
       messages with the new (changed) mapping records.  So any active
       caches can get the new mapping contents right away if not cached,
       or in 1 minute if they had the mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for xTRs, at the site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to tell remote ITRs to update
   the mappings they have cached.

   Since the xTRs don't keep track of remote ITRs that have cached their
   mappings, they can not tell exactly who needs the new mapping
   entries.  So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to, and only from those sites.
   The xTRs can locally decide the algorithm for how often and to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in a Map-Request message.  An ITR
   or PTR will send a Map-Request when they receive an SMR message.
   Both the SMR sender and the Map-Request responder MUST rate-limited
   these messages.

   The following procedure shows how a SMR exchange occurs when a site
   is doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the database mappings in an ETR change, the ETRs at the site
       begin to send Map-Requests with the SMR bit set for each locator
       in each map-cache entry the ETR caches.

   2.  A remote xTR which receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message.  A newly allocated random nonce is selected and the EID-



Farinacci, et al.       Expires October 25, 2010               [Page 48]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


       prefix used is the one copied from the SMR message.

   3.  The remote xTR MUST rate-limit the Map-Request until it gets a
       Map-Reply while continuing to use the cached mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message provided the Map-Request
       nonce matches the nonce from the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the site with the changed mapping, record the fact
       that the site that sent the Map-Request has received the new
       mapping data in the mapping cache entry for the remote site so
       the loc-status-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending SMR
       messages.

   For security reasons an ITR MUST NOT process unsolicited Map-Replies.
   The nonce MUST be carried from SMR packet, into the resultant Map-
   Request, and then into Map-Reply to reduce spoofing attacks.

   To avoid map-cache entry corruption by a third-party, a sender of an
   SMR-based Map-Request MUST be verified.  If an ITR receives an SMR-
   based Map-Request and the source is not in the locator-set for the
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to the mapping database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it will deliver the Map-Request to the authoritative source of the
   mapping data.

6.5.3.  Database Map Versioning

   When there is unidirectional packet flow between an ITR and ETR, and
   the EID-to-RLOC mappings change on the ETR, it needs to inform the
   ITR so encapsulation can stop to a removed locator and start to a new
   locator in the locator-set.

   An ETR, when it sends Map-Reply messages, conveys its own Map-Version
   number.  This is known as the Destination Map-Version Number.  ITRs
   include the Destination Map-Version Number in packets they
   encapsulate to the site.  When an ETR decapsulates a packet and
   detects the Destination Map-Version Number is less than the current
   version for its mapping, the SMR procedure described in Section 6.5.2
   occurs.

   An ITR, when it encapsulates packets to ETRs, can convey its own Map-
   Version number.  This is known as the Source Map-Version Number.



Farinacci, et al.       Expires October 25, 2010               [Page 49]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   When an ETR decapsulates a packet and detects the Source Map-Version
   Number is greater than the last Map-Version Number sent in a Map-
   Reply from the ITR's site, the ETR will send a Map-Request to one of
   the ETRs for the source site.

   A Map-Version Number is used as a sequence number per EID-prefix.  So
   values that are greater, are considered to be more recent.  A value
   of 0 for the Source Map-Version Number or the Destination Map-Version
   Number conveys no versioning information and an xTR does no
   comparison with previously received Map-Version Numbers.

   A Map-Version Number can be included in Map-Register messages as
   well.  This is a good way for the Map-Server can assure that all ETRs
   for a site registering to it will be Map-Version number synchronized.

   See [VERSIONING] for a more detailed analysis and description of
   Database Map Versioning.


































Farinacci, et al.       Expires October 25, 2010               [Page 50]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


7.  Router Performance Considerations

   LISP is designed to be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] and stripping instead of re-
   writing addresses, existing hardware can support the forwarding model
   with little or no modification.  Where modifications are required,
   they should be limited to re-programming existing hardware rather
   than requiring expensive design changes to hard-coded algorithms in
   silicon.

   A few implementation techniques can be used to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special FIB entries
      for the EID-prefixes of EIDs served by the ETR (those for which
      the router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be performed.  The forwarding logic of testing for particular IP
      protocol number value is not necessary.  No changes to existing,
      deployed hardware should be needed to support this.

   o  On an ITR, prepending a new IP header is as simple as adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this action.

   o  When a received packet's outer destination address contains an EID
      which is not intended to be forwarded on the routable topology
      (i.e.  LISP 1.5), the source address of a data packet or the
      router interface with which the source is associated (the
      interface from which it was received) can be associated with a VRF
      (Virtual Routing/Forwarding), in which a different (i.e. non-
      congruent) topology can be used to find EID-to-RLOC mappings.














Farinacci, et al.       Expires October 25, 2010               [Page 51]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and will discuss the pros and cons of each deployment scenario.
   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or re-encapsulating
   tunneling.

   When deciding on centralized versus distributed caching, the
   following issues should be considered:

   o  Are the tunnel routers spread out so that the caches are spread
      across all the memories of each router?

   o  Should management "touch points" be minimized by choosing few
      tunnel routers, just enough for redundancy?

   o  In general, using more ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, the
   following issues should be considered:

   o  Flat tunneling implements a single tunnel between source site and
      destination site.  This generally offers better paths between
      sources and destinations with a single tunnel path.

   o  Recursive tunneling is when tunneled traffic is again further
      encapsulated in another tunnel, either to implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the
      site has some control since the site is prepending a new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is prepending a new tunnel header, but if the site's
      ISP is doing the TE, then the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at the
      benefit of steering traffic to resource available parts of the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated with
      a new tunnel header using a new RLOC.

   The next sub-sections will describe where tunnel routers can reside
   in the network.




Farinacci, et al.       Expires October 25, 2010               [Page 52]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to hosts, the EID-prefix set is at
   the granularity of an IP subnet.  So at the expense of more EID-
   prefix-to-RLOC sets for the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on the number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Map-Replies are traveling between more routers.

   The advantage of placing the caches and databases at these stub
   routers is that the products deployed in this part of the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in these devices and fewer routes
   are stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and routing state.

   LISP functionality can also be deployed in edge switches.  These
   devices generally have layer-2 ports facing hosts and layer-3 ports
   facing the Internet.  Spare capacity is also often available in these
   devices as well.

8.2.  Border/Edge Tunnel Routers

   Using customer-edge (CE) routers for tunnel endpoints allows the EID
   space associated with a site to be reachable via a small set of RLOCs
   assigned to the CE routers for that site.

   This offers the opposite benefit of the first-hop/last-hop tunnel
   router scenario: the number of mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage is that less of the network's resources are used to
   reach host endpoints thereby centralizing the point-of-failure domain
   and creating network choke points at the CE router.

   Note that more than one CE router at a site can be configured with
   the same IP address.  In this case an RLOC is an anycast address.
   This allows resilience between the CE routers.  That is, if a CE
   router fails, traffic is automatically routed to the other routers
   using the same anycast address.  However, this comes with the
   disadvantage where the site cannot control the entrance point when
   the anycast route is advertised out from all border routers.





Farinacci, et al.       Expires October 25, 2010               [Page 53]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers gives an ISP control
   over the location of the egress tunnel endpoints.  That is, the ISP
   can decide if the tunnel endpoints are in the destination site (in
   either CE routers or last-hop routers within a site) or at other PE
   edges.  The advantage of this case is that two or more tunnel headers
   can be avoided.  By having the PE be the first router on the path to
   encapsulate, it can choose a TE path first, and the ETR can
   decapsulate and re-encapsulate for a tunnel to the destination end
   site.

   An obvious disadvantage is that the end site has no control over
   where its packets flow or the RLOCs used.

   As mentioned in earlier sections a combination of these scenarios is
   possible at the expense of extra packet header overhead, if both site
   and provider want control, then recursive or re-encapsulating tunnels
   are used.

8.4.  LISP Functionality with Conventional NATs

   LISP routers can be deployed behind Network Address Translator (NAT)
   devices to provide the same set of packet services hosts have today
   when they are addressed out of private address space.

   It is important to note that a locator address in any LISP control
   message MUST be a globally routable address and therefore SHOULD NOT
   contain [RFC1918] addresses.  If a LISP router is configured with
   private addresses, they MUST be used only in the outer IP header so
   the NAT device can translate properly.  Otherwise, EID addresses MUST
   be translated before encapsulation is performed.  Both NAT
   translation and LISP encapsulation functions could be co-located in
   the same device.

   More details on LISP address translation can be found in [INTERWORK].















Farinacci, et al.       Expires October 25, 2010               [Page 54]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


9.  Traceroute Considerations

   When a source host in a LISP site initiates a traceroute to a
   destination host in another LISP site, it is highly desirable for it
   to see the entire path.  Since packets are encapsulated from ITR to
   ETR, the hop across the tunnel could be viewed as a single hop.
   However, LISP traceroute will provide the entire path so the user can
   see 3 distinct segments of the path from a source LISP host to a
   destination LISP host:


      Segment 1 (in source LISP site based on EIDs):

          source-host ---> first-hop ... next-hop ---> ITR

      Segment 2 (in the core network based on RLOCs):

          ITR ---> next-hop ... next-hop ---> ETR

      Segment 3 (in the destination LISP site based on EIDs):

          ETR ---> next-hop ... last-hop ---> destination-host

   For segment 1 of the path, ICMP Time Exceeded messages are returned
   in the normal matter as they are today.  The ITR performs a TTL
   decrement and test for 0 before encapsulating.  So the ITR hop is
   seen by the traceroute source has an EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are returned
   to the ITR because the TTL decrement to 0 is done on the outer
   header, so the destination of the ICMP messages are to the ITR RLOC
   address, the source RLOC address of the encapsulated traceroute
   packet.  The ITR looks inside of the ICMP payload to inspect the
   traceroute source so it can return the ICMP message to the address of
   the traceroute client as well as retaining the core router IP address
   in the ICMP message.  This is so the traceroute client can display
   the core router address (the RLOC address) in the traceroute output.
   The ETR returns its RLOC address and responds to the TTL decrement to
   0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will be
   decrementing the TTL for the packet that was encapsulated, sent into
   the core, decapsulated by the ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the destination of the traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the traceroute client.  The ICMP message will be



Farinacci, et al.       Expires October 25, 2010               [Page 55]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   encapsulated by the local ITR and sent back to the ETR in the
   originated traceroute source site, where the packet will be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs to pay special
   attention for forwarding ICMP messages back to the traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the above procedure since IPv4
   ICMP Time Exceeded messages only include the invoking IP header and 8
   bytes that follow the IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP
   payload is the encapsulated header it prepended followed by a UDP
   header.  The original invoking IP header, and therefore the identity
   of the traceroute source is lost.

   The solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the ETR.  The
   ITR will use a circular buffer for caching the IPv4 and UDP headers
   of traceroute packets.  It will select a 16-bit number as a key to
   find them later when the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as the UDP source port in the encapsulating header.
   When the ICMP Time Exceeded message is returned to the ITR, the UDP
   header of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload
   and sends the ICMP Time Exceeded message to the traceroute source
   retaining the source address of the original ICMP Time Exceeded
   message (a core router or the ETR of the site of the traceroute
   destination).

   The signature of a traceroute packet comes in two forms.  The first
   form is encoded as a UDP message where the destination port is
   inspected for a range of values.  The second form is encoded as an
   ICMP message where the IP identification field is inspected for a
   well-known value.

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is originated and
   the ITR encapsulates it in the other address family header, you



Farinacci, et al.       Expires October 25, 2010               [Page 56]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   cannot get all 3 segments of the traceroute.  Segment 2 of the
   traceroute can not be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the tunnel look like one hop.  All the ITR has to
   do to make this work is to not copy the inner TTL to the outer,
   encapsulating header's TTL when a traceroute packet is encapsulated
   using an RLOC from a different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the ITR and ETR.










































Farinacci, et al.       Expires October 25, 2010               [Page 57]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


10.  Mobility Considerations

   There are several kinds of mobility of which only some might be of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in EID-RLOC mappings for sites are expected to be
   handled by configuration, outside of the LISP protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering is involved.  LISP can
   help with the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a site from the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves relatively
   rapidly, changing its IP layer network attachment point.  Maintenance
   of session continuity is a goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to be explored.

   The problem is that as an endpoint moves, it may require changes to
   the mapping between its EID and a set of RLOCs for its new network
   location.  When this is added to the overhead of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint is away from home, packets to it
   are encapsulated and forwarded via a home agent which resides in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the endpoint or to
   a foreign agent which resides where the endpoint has moved to.
   Packets from the endpoint may be sent directly to the correspondent
   node, may be sent via the foreign agent, or may be reverse-tunneled
   back to the home agent for delivery to the mobile node.  As the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between the mobile node and
   the home agent, whether via foreign agent or not.  As a mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:





Farinacci, et al.       Expires October 25, 2010               [Page 58]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   o  The mobile node moves from an old location to a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one of the new visited network's ITRs, which needs a EID-RLOC
      mapping for the home agent.

   o  The home agent might not have the EID-RLOC mappings for the mobile
      node's "care-of" address or its foreign agent in the new visited
      network, in which case it will need to acquire them.

   o  When packets are sent directly to the correspondent node, it may
      be that no traffic has been sent from the new visited network to
      the correspondent node's network, and the new visited network's
      ITR will need to obtain an EID-RLOC mapping for the correspondent
      node's site.

   In addition, if the IPv4 endpoint is sending packets from the new
   visited network using its original EID, then LISP will need to
   perform a route-returnability check on the new EID-RLOC mapping for
   that EID.

   In IPv6 mobility, packets can flow directly between the mobile node
   and the correspondent node in either direction.  The mobile node uses
   its "care-of" address (EID).  In this case, the route-returnability
   check would not be needed but one more LISP mapping lookup may be
   required instead:

   o  As above, three mapping changes may be needed for the mobile node
      to communicate with its home agent and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order for the correspondent node to send packets to
      the mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the number of potential mapping
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the mobile node, correspondent node, and home agent, but also state
   changes in the ITRs and ETRs for at least some EID-prefixes.

   The goal is to support rapid adaptation, with little delay or packet
   loss for the entire system.  Also IP mobility can be modified to
   require fewer mapping changes.  In order to increase overall system
   performance, there may be a need to reduce the optimization of one
   area in order to place fewer demands on another.



Farinacci, et al.       Expires October 25, 2010               [Page 59]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   In LISP, one possibility is to "glean" information.  When a packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It can do this after
   performing a route-returnability check, to ensure that the new
   network location does have a internal route to that endpoint.
   However, this does not cover the case where an ITR (the node assigned
   the RLOC) at the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment in which all
   routing information is disseminated before packets can be forwarded.
   In order to allow the Internet to grow to support expected future
   use, we are moving to an environment where some information may have
   to be obtained after packets are in flight.  Modifications to IP
   mobility should be considered in order to optimize the behavior of
   the overall system.  Anything which decreases the number of new EID-
   RLOC mappings needed when a node moves, or maintains the validity of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network" can be as small as a single router and as large as
   a whole site.  This is different from site mobility in that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any endpoint will return a binding for the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   to revisit the design of the mapping service and allow for dynamic
   updates of the database.

   The issue of interactions between mobility and LISP needs to be
   explored further.  Specific improvements to the entire system will
   depend on the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   A mobile device can use the LISP infrastructure to achieve mobility
   by implementing the LISP encapsulation and decapsulation functions
   and acting as a simple ITR/ETR.  By doing this, such a "LISP mobile
   node" can use topologically-independent EID IP addresses that are not
   advertised into and do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
   only the correspondents of the LISP mobile node.



Farinacci, et al.       Expires October 25, 2010               [Page 60]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   Refer to the LISP Mobility Architecture specification [LISP-MN] for
   more details.

















































Farinacci, et al.       Expires October 25, 2010               [Page 61]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


11.  Multicast Considerations

   A multicast group address, as defined in the original Internet
   architecture is an identifier of a grouping of topologically
   independent receiver host locations.  The address encoding itself
   does not determine the location of the receiver(s).  The multicast
   routing protocol, and the network-based state the protocol creates,
   determines where the receivers are located.

   In the context of LISP, a multicast group address is both an EID and
   a Routing Locator.  Therefore, no specific semantic or action needs
   to be taken for a destination address, as it would appear in an IP
   header.  Therefore, a group address that appears in an inner IP
   header built by a source host will be used as the destination EID.
   The outer IP header (the destination Routing Locator address),
   prepended by a LISP router, will use the same group address as the
   destination Routing Locator.

   Having said that, only the source EID and source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address in the source Routing Locator field when prepending
   the outer IP header.  This source Routing Locator address, like any
   other Routing Locator address MUST be globally routable.

   Therefore, an EID-to-RLOC mapping does not need to be performed by an
   ITR when a received data packet is a multicast data packet or when
   processing a source-specific Join (either by IGMPv3 or PIM).  But the
   source Routing Locator is decided by the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach is to have the ITR not encapsulate a multicast
   packet and allow the the host built packet to flow into the core even
   if the source address is allocated out of the EID namespace.  If the
   RPF-Vector TLV [RFC5496] is used by PIM in the core, then core
   routers can RPF to the ITR (the Locator address which is injected
   into core routing) rather than the host source address (the EID
   address which is not injected into core routing).

   To avoid any EID-based multicast state in the network core, the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and Interworking with non-LISP sites is described in specification
   [MLISP].








Farinacci, et al.       Expires October 25, 2010               [Page 62]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


12.  Security Considerations

   It is believed that most of the security mechanisms will be part of
   the mapping database service when using control plane procedures for
   obtaining EID-to-RLOC mappings.  For data plane triggered mappings,
   as described in this specification, protection is provided against
   ETR spoofing by using Return- Routability mechanisms evidenced by the
   use of a 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  The nonce, coupled
   with the ITR accepting only solicited Map-Replies goes a long way
   toward providing decent authentication.

   LISP does not rely on a PKI infrastructure or a more heavy weight
   authentication system.  These systems challenge the scalability of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies to the control plane as well as rate-
   limiting the number of data-triggered Map-Replies.

   To deal with map-cache exhaustion attempts in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list for special or frequently accessed
   sites.  This should be a configuration policy control set by the
   network administrator who manages ITRs and PTRs.


























Farinacci, et al.       Expires October 25, 2010               [Page 63]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


13.  IANA Considerations

   This specification has already allocated UDP port numbers 4341 and
   4342 assigned from the IANA registry.















































Farinacci, et al.       Expires October 25, 2010               [Page 64]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


14.  Prototype Plans and Status

   The operator community has requested that the IETF take a practical
   approach to solving the scaling problems associated with global
   routing state growth.  This document offers a simple solution which
   is intended for use in a pilot program to gain experience in working
   on this problem.

   The authors hope that publishing this specification will allow the
   rapid implementation of multiple vendor prototypes and deployment on
   a small scale.  Doing this will help the community:

   o  Decide whether a new EID-to-RLOC mapping database infrastructure
      is needed or if a simple, UDP-based, data-triggered approach is
      flexible and robust enough.

   o  Experiment with provider-independent assignment of EIDs while at
      the same time decreasing the size of DFZ routing tables through
      the use of topologically-aligned, provider-based RLOCs.

   o  Determine whether multiple levels of tunneling can be used by ISPs
      to achieve their Traffic Engineering goals while simultaneously
      removing the more specific routes currently injected into the
      global routing system for this purpose.

   o  Experiment with mobility to determine if both acceptable
      convergence and session continuity properties can be scalably
      implemented to support both individual device roaming and site
      service provider changes.

   Here is a rough set of milestones:

   1.  Interoperable implementations have been available since the
       beginning of 2009.

   2.  Continue pilot deployment using LISP-ALT as the database mapping
       mechanism.

   3.  Continue prototyping and studying other database lookup schemes,
       be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms.

   4.  Implement the LISP Multicast draft [MLISP].

   5.  Implement the LISP Mobile Node draft [LISP-MN].

   6.  Research more on how policy affects what gets returned in a Map-
       Reply from an ETR.




Farinacci, et al.       Expires October 25, 2010               [Page 65]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   7.  Continue to experiment with mixed locator-sets to understand how
       LISP can help the IPv4 to IPv6 transition.

   8.  Add more robustness to locator reachability between LISP sites.

   9.  Continue the deployment of Proxy-ETRs (PETRs) for uses like uRPF
       avoidance, IPv6 connectivity, and LISP-MN.

   As of this writing the following accomplishments have been achieved:

   1.   A unit- and system-tested software switching implementation has
        been completed on cisco NX-OS for this draft for both IPv4 and
        IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators.

   2.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [ALT].

   3.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [INTERWORK].  Support
        for IPv4 translation is provided and PTR support for IPv4 and
        IPv6 is provided.

   4.   The cisco NX-OS implementation supports an experimental
        mechanism for slow mobility.

   5.   There are 5 LISP implementations that exist and the first 4
        below have gone through interoperability testing at IETF
        Hiroshima, based on the draft-ietf-lisp-05.txt spec:

        1.  cisco NX-OS

        2.  OpenLISP

        3.  LISP-Click

        4.  ZLisp

        5.  cisco IOS

   6.   Dave Meyer, Vince Fuller, Darrel Lewis, Gregg Schudel, Andrew
        Partan and the rest of the lisp-beta team continue to test all
        the features described above on a dual-stack infrastructure.

   7.   Darrel Lewis and Dave Meyer have deployed both LISP translation
        and LISP PTR support in the pilot network.  Point your browser
        to http://www.lisp4.net to see translation happening in action
        so your non-LISP site can access a web server in a LISP site.




Farinacci, et al.       Expires October 25, 2010               [Page 66]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   8.   Soon http://www.lisp6.net will work where your IPv6 LISP site
        can talk to a IPv6 web server in a LISP site by using mixed
        address-family based locators.

   9.   An public domain implementation of LISP is available.  See
        [OPENLISP] for details.

   10.  We have deployed Map-Resolvers and Map-Servers on the LISP pilot
        network to gather experience with [LISP-MS].  The first layer of
        the architecture are the xTRs which use Map-Servers for EID-
        prefix registration and Map-Resolvers for EID-to-RLOC mapping
        resolution.  The second layer are the Map-Resolvers and Map-
        Servers which connect to the ALT BGP peering infrastructure.
        And the third layer are ALT-routers which aggregate EID-prefixes
        and forward Map-Requests.

   11.  A cisco IOS implementation is available which currently supports
        IPv4 and IPv6 encapsulation and decapsulation features.

   12.  A LISP router based LIG implementation is supported, deployed,
        and used daily to debug and test the LISP pilot network.  See
        [LIG] for details.

   13.  A Linux implementation of LIG has been made available and
        supported by Dave Meyer.  It can be run on any Linux system
        which resides in either a LISP site or non-LISP site.  See [LIG]
        for details.  Public domain code can be downloaded from
        http://github.com/davidmeyer/lig/tree/master.

   14.  An experimental implementation has been written for three
        locator reachability algorithms.  Two are the Echo-Noncing and
        RLOC-Probing algorithms which are documented in this
        specification.  The third is called TCP-counts which will be
        documented in future drafts.

   15.  The LISP pilot network has been converted from using MD5 HMAC
        authentication for Map-Register messages to SHA-1 HMAC
        authentication.  ETRs send with SHA-1 but Map-Servers can
        received from either for compatibility purposes.

   16.  The LISP pilot network is in its 3rd generation.  Current
        experiments are being performed to test EID-prefix aggregation
        at multiple service boundaries as well as deploying models for
        the existence of multiple Mapping Service Providers (MSPs).

   If interested in writing a LISP implementation, testing any of the
   LISP implementations, or want to be part of the LISP pilot program,
   please contact lisp@ietf.org.



Farinacci, et al.       Expires October 25, 2010               [Page 67]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


15.  References

15.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1498]  Saltzer, J., "On the Naming and Binding of Network
              Destinations", RFC 1498, August 1993.

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

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

   [RFC1955]  Hinden, R., "New Scheme for Internet Routing and
              Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.



Farinacci, et al.       Expires October 25, 2010               [Page 68]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 2006.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

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

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009.

   [UDP-TUNNELS]
              Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
              Packets"", draft-eubanks-chimento-6man-00.txt (work in
              progress), February 2009.

15.2.  Informative References

   [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-04.txt (work in progress), April 2010.

   [APT]      Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01.txt (work in progress), November 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network  Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.




Farinacci, et al.       Expires October 25, 2010               [Page 69]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   [DHTs]     Ratnasamy, S., Shenker, S., and I. Stoica, "Routing
              Algorithms for DHTs: Some Open Questions", PDF
              file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.

   [EMACS]    Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              draft-curran-lisp-emacs-00.txt (work in progress),
              November 2007.

   [GSE]      "GSE - An Alternate Addressing Architecture for  IPv6",
              draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-01.txt (work in progress),
              March 2010.

   [LCAF]     Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format", draft-farinacci-lisp-lcaf-01.txt (work in
              progress), April 2010.

   [LIG]      Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-ietf-lisp-lig-00.txt (work in progress), April 2010.

   [LISA96]   Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
              "Renumbering: Threat or Menace?", Usenix , September 1996.

   [LISP-MAIN]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress),
              March 2009.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), July 2009.

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

   [LISP1]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP1) [Routable  ID
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
              October 2006.

   [LISP2]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,



Farinacci, et al.       Expires October 25, 2010               [Page 70]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


              "Locator/ID Separation Protocol (LISP2) [DNS-based
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
              November 2006.

   [LISPDHT]  Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT:
              Towards a DHT to map identifiers onto locators",
              draft-mathy-lisp-dht-00.txt (work in progress),
              February 2008.

   [LOC-ID-ARCH]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID  Separation",
              draft-meyer-loc-id-implications-01.txt (work in progress),
              Januaryr 2009.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-ietf-lisp-multicast-03.txt (work in progress),
              April 2010.

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

   [OPENLISP]
              Iannone, L. and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.txt (work in
              progress), July 2007.




Farinacci, et al.       Expires October 25, 2010               [Page 71]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   [VERSIONING]
              Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
              Versioning", draft-iannone-lisp-mapping-versioning-01.txt
              (work in progress), March 2010.















































Farinacci, et al.       Expires October 25, 2010               [Page 72]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


Appendix A.  Acknowledgments

   An initial thank you goes to Dave Oran for planting the seeds for the
   initial ideas for LISP.  His consultation continues to provide value
   to the LISP authors.

   A special and appreciative thank you goes to Noel Chiappa for
   providing architectural impetus over the past decades on separation
   of location and identity, as well as detailed review of the LISP
   architecture and documents, coupled with enthusiasm for making LISP a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
   Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
   Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
   Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
   Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko,
   Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra
   Trivedi, Yakov Rekhter, John Scudder, John Drake, and Dimitri
   Papadimitriou.

   In particular, we would like to thank Dave Meyer for his clever
   suggestion for the name "LISP". ;-)

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft.
















Farinacci, et al.       Expires October 25, 2010               [Page 73]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-07.txt

   o  Posted April 2010.

   o  Added I-bit to data header so LSB field can also be used as an
      Instance ID field.  When this occurs, the LSB field is reduced to
      8-bits (from 32-bits).

   o  Added V-bit to the data header so the 24-bit nonce field can also
      be used for source and destination version numbers.

   o  Added Map-Version 12-bit value to the EID-record to be used in all
      of Map-Request, Map-Reply, and Map-Register messages.

   o  Added multiple ITR-RLOC fields to the Map-Request packet so an ETR
      can decide what address to select for the destination of a Map-
      Reply.

   o  Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to
      the Locator-Set record of an EID-record for a Map-Reply message.
      The L-bit indicates which RLOCs in the locator-set are local to
      the sender of the message.  The P-bit indicates which RLOC is the
      source of a RLOC-probe Reply (Map-Reply) message.

   o  Add reference to the LISP Canonical Address Format [LCAF] draft.

   o  Made editorial and clarification changes based on comments from
      Dhirendra Trivedi.

   o  Added wordsmithing comments from Joel Halpern on DF=3D1 setting.

   o  Add John Zwiebel clarification to Echo Nonce Algorithm section
      6.3.1.

   o  Add John Zwiebel comment about expanding on proxy-map-reply bit
      for Map-Register messages.

   o  Add NAT section per Ron Bonica comments.

   o  Fix IDnits issues per Ron Bonica.

   o  Added section on Virtualization and Segmentation to explain the
      use if the Instance ID field in the data header.

   o  There are too many P-bits, keep their scope to the packet format
      description and refer to them by name every where else in the



Farinacci, et al.       Expires October 25, 2010               [Page 74]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


      spec.

   o  Scanned all occurrences of "should", "should not", "must" and
      "must not" and uppercased them.

   o  John Zwiebel offered text for section 4.1 to modernize the
      example.  Thanks Z!

   o  Make it more clear in the definition of "EID-to-RLOC Database"
      that all ETRs need to have the same database mapping.  This
      reflects a comment from John Scudder.

   o  Add a definition "Route-returnability" to the Definition of Terms
      section.

   o  In section 9.2, add text to describe what the signature of
      traceroute packets can look like.

   o  Removed references to Data Probe for introductory example.  Data-
      probes are still part of the LISP design but not encouraged.

   o  Added the definition for "LISP site" to the Definition of Terms"
      section.

B.2.  Changes to draft-ietf-lisp-06.txt

   Editorial based changes:

   o  Posted December 2009.

   o  Fix typo for flags in LISP data header.  Changed from "4" to "5".

   o  Add text to indicate that Map-Register messages must contain a
      computed UDP checksum.

   o  Add definitions for PITR and PETR.

   o  Indicate an AFI value of 0 is an unspecified address.

   o  Indicate that the TTL field of a Map-Register is not used and set
      to 0 by the sender.  This change makes this spec consistent with
      [LISP-MS].

   o  Change "... yield a packet size of L bytes" to "... yield a packet
      size greater than L bytes".

   o  Clarify section 6.1.5 on what addresses and ports are used in Map-
      Reply messages.



Farinacci, et al.       Expires October 25, 2010               [Page 75]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   o  Clarify that LSBs that go beyond the number of locators do not to
      be SMRed when the locator addresses are greater lexicographically
      than the locator in the existing locator-set.

   o  Add Gregg, Srini, and Amit to acknowledgment section.

   o  Clarify in the definition of a LISP header what is following the
      UDP header.

   o  Clarify "verifying Map-Request" text in section 6.1.3.

   o  Add Xu Xiaohu to the acknowledgment section for introducing the
      problem of overlapping EID-prefixes among multiple sites in an RRG
      email message.

   Design based changes:

   o  Use stronger language to have the outer IPv4 header set DF=3D1 so =
we
      can avoid fragment reassembly in an ETR or PETR.  This will also
      make IPv4 and IPv6 encapsulation have consistent behavior.

   o  Map-Requests should not be sent in ECM with the Probe bit is set.
      These type of Map-Requests are used as RLOC-probes and are sent
      directly to locator addresses in the underlying network.

   o  Add text in section 6.1.5 about returning all EID-prefixes in a
      Map-Reply sent by an ETR when there are overlapping EID-prefixes
      configure.

   o  Add text in a new subsection of section 6.1.5 about dealing with
      Map-Replies with coarse EID-prefixes.

B.3.  Changes to draft-ietf-lisp-05.txt

   o  Posted September 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in Map-Registers.  Put key-id, auth-length, and auth-
      data in Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.



Farinacci, et al.       Expires October 25, 2010               [Page 76]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   o  Make more clear what source-RLOC should be for a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

   o  Removed nonce from Map-Register message, it wasn't used so no need
      for it.

   o  Clarify what to do for unspecified Action bits for negative Map-
      Replies.  Since No Action is a drop, make value 0 Drop.

B.4.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  How do deal with record count greater than 1 for a Map-Request.
      Damien and Joel comment.  Joel suggests: 1) Specify that senders
      compliant with the current document will always set the count to
      1, and note that the count is included for future extensibility.
      2) Specify what a receiver compliant with the draft should do if
      it receives a request with a count greater than 1.  Presumably, it
      should send some error back?

   o  Add Fred Templin in acknowledgment section.

   o  Add Margaret and Sam to the acknowledgment section for their great
      comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums on
      ETR.  =46rom the mailing list: "You'd need to word it as an ITR =
MAY
      send a zero checksum, an ETR MUST accept a 0 checksum and MAY
      ignore the checksum completely.  And of course we'd need to
      confirm that can actually be implemented.  In particular, hardware
      that verifies UDP checksums on receive needs to be checked to make
      sure it permits 0 checksums."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      for MNs but often enough to get mapping updates.





Farinacci, et al.       Expires October 25, 2010               [Page 77]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   o  Indicate SHA1 can be used as well for Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about spec'ing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

   o  Margaret's comment on gleaning: "The current specification does
      not make it clear how long gleaned map entries should be retained
      in the cache, nor does it make it clear how/ when they will be
      validated.  The LISP spec should, at the very least, include a
      (short) default lifetime for gleaned entries, require that they be
      validated within a short period of time, and state that a new
      gleaned entry should never overwrite an entry that was obtained
      from the mapping system.  The security implications of storing
      "gleaned" entries should also be explored in detail."

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

   o  Change LISP header to allow a "Research Bit" so the Nonce and LSB
      fields can be turned off and used for another future purpose.  For
      Luigi et al versioning convergence.

   o  Add a N-bit to the data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

   o  Indicate when doing data-gleaning that a verifying Map-Request is
      sent to the source-EID of the gleaned data packet so we can avoid
      map-cache corruption by a 3rd party.  Comment from Pedro.

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro and Dino.





Farinacci, et al.       Expires October 25, 2010               [Page 78]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   o  Jesper made a comment to loosen the language about requiring the
      copy of inner TTL to outer TTL since the text to get mixed-AF
      traceroute to work would violate the "MUST" clause.  Changed from
      MUST to SHOULD in section 5.3.

B.5.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from John Zwiebel in Echo-Nonce section.

B.6.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.

B.7.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=3D0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.




Farinacci, et al.       Expires October 25, 2010               [Page 79]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


   o  Added Proxy-Map-Reply bit to Map-Register.

B.8.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.










































Farinacci, et al.       Expires October 25, 2010               [Page 80]
=0C
Internet-Draft    Locator/ID Separation Protocol (LISP)       April 2010


Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com


   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com


   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com


   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com















Farinacci, et al.       Expires October 25, 2010               [Page 81]
=0C

--Apple-Mail-20--356320157
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii




Changes to draft-ietf-lisp-07.txt

  o  Posted April 2010.

  o  Added I-bit to data header so LSB field can also be used as an
     Instance ID field.  When this occurs, the LSB field is reduced to
     8-bits (from 32-bits).

  o  Added V-bit to the data header so the 24-bit nonce field can also
     be used for source and destination version numbers.

  o  Added Map-Version 12-bit value to the EID-record to be used in all
     of Map-Request, Map-Reply, and Map-Register messages.

  o  Added multiple ITR-RLOC fields to the Map-Request packet so an ETR
     can decide what address to select for the destination of a Map-
     Reply.

  o  Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to
     the Locator-Set record of an EID-record for a Map-Reply message.
     The L-bit indicates which RLOCs in the locator-set are local to
     the sender of the message.  The P-bit indicates which RLOC is the
     source of a RLOC-probe Reply (Map-Reply) message.

  o  Add reference to the LISP Canonical Address Format [LCAF] draft.

  o  Made editorial and clarification changes based on comments from
     Dhirendra Trivedi.

  o  Added wordsmithing comments from Joel Halpern on DF=1 setting.

  o  Add John Zwiebel clarification to Echo Nonce Algorithm section
     6.3.1.

  o  Add John Zwiebel comment about expanding on proxy-map-reply bit
     for Map-Register messages.

  o  Add NAT section per Ron Bonica comments.

  o  Fix IDnits issues per Ron Bonica.

  o  Added section on Virtualization and Segmentation to explain the
     use if the Instance ID field in the data header.

  o  There are too many P-bits, keep their scope to the packet format
     description and refer to them by name every where else in the
     spec.

  o  Scanned all occurrences of "should", "should not", "must" and
     "must not" and uppercased them.

  o  John Zwiebel offered text for section 4.1 to modernize the
     example.  Thanks Z!

  o  Make it more clear in the definition of "EID-to-RLOC Database"
     that all ETRs need to have the same database mapping.  This
     reflects a comment from John Scudder.

  o  Add a definition "Route-returnability" to the Definition of Terms
     section.

  o  In section 9.2, add text to describe what the signature of
     traceroute packets can look like.

  o  Removed references to Data Probe for introductory example.  Data-
     probes are still part of the LISP design but not encouraged.

  o  Added the definition for "LISP site" to the Definition of Terms"
     section.

--Apple-Mail-20--356320157--

From jnc@mercury.lcs.mit.edu  Sun Apr 25 19:37:42 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE143A67AF for ; Sun, 25 Apr 2010 19:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.373
X-Spam-Level: 
X-Spam-Status: No, score=-4.373 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyCNOHHiVAFi for ; Sun, 25 Apr 2010 19:37:41 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 2E34B3A677C for ; Sun, 25 Apr 2010 19:37:40 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CDBCD6BE5DA; Sun, 25 Apr 2010 22:37:28 -0400 (EDT)
To: jgs@juniper.net, lisp@ietf.org
Message-Id: <20100426023728.CDBCD6BE5DA@mercury.lcs.mit.edu>
Date: Sun, 25 Apr 2010 22:37:28 -0400 (EDT)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jdrake@juniper.net, jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] LISP Site definition
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 02:37:42 -0000

    > From: Darrel Lewis 

    > How about:
    > LISP site: A set of routers in an edge network that is under
    > administrative control by a single organization. LISP routers which
    > reside in the edge network are the demarcation points to separate the
    > edge network from the core network.

Why just the routers? I would argue that namespace blocks are just as
important to LISP as anything else, so I'd think they should be included to
(at least, if not also all the hosts named in those blocks as well).


And the "under administrative control by a single organization" could present
problems too: suppose one organization has a number of different, disparate,
LISP sites it is responsible for? (E.g. a bunch of branch offices in different
locations, which are not connected via internal links, but only through the
public Internet).

I'd think it would be more like 'the set of ETRs which are authoritative for
a given set of namespace blocks', or something like that - something to imply
that it's a set of ETRs acting in concert, not just under common admin control.

	Noel

From root@core3.amsl.com  Sun Apr 25 20:00:01 2010
Return-Path: 
X-Original-To: lisp@ietf.org
Delivered-To: lisp@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id A73F33A6A26; Sun, 25 Apr 2010 20:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100426030001.A73F33A6A26@core3.amsl.com>
Date: Sun, 25 Apr 2010 20:00:01 -0700 (PDT)
Cc: lisp@ietf.org
Subject: [lisp] I-D Action:draft-ietf-lisp-07.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 03:00:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF.


	Title           : Locator/ID Separation Protocol (LISP)
	Author(s)       : D. Farinacci, et al.
	Filename        : draft-ietf-lisp-07.txt
	Pages           : 81
	Date            : 2010-04-25

This draft describes a simple, incremental, network-based protocol to
implement separation of Internet addresses into Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs).  This mechanism requires no
changes to host stacks and no major changes to existing database
infrastructures.  The proposed protocol can be implemented in a
relatively small number of routers.

This proposal was stimulated by the problem statement effort at the
Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
place in October 2006.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lisp-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-lisp-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-04-25195909.I-D@ietf.org>


--NextPart--

From trac@tools.ietf.org  Mon Apr 26 01:17:30 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9BD3A6954 for ; Mon, 26 Apr 2010 01:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.231
X-Spam-Level: 
X-Spam-Status: No, score=-101.231 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrN4-zVBipGb for ; Mon, 26 Apr 2010 01:17:29 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1CD6E28C0EA for ; Mon, 26 Apr 2010 01:16:57 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6JUi-0004oz-7W; Mon, 26 Apr 2010 01:16:44 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 08:16:44 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/75
Message-ID: <068.6f9a0735f72eae0748ba4895dfdda8c8@tools.ietf.org>
X-Trac-Ticket-ID: 75
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #75: Security of Map-Register message.
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 08:17:30 -0000

#75: Security of Map-Register message.
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:     
    Type:  technical                      |      Status:  new
Priority:  major                          |   Component:  ms 
Severity:  -                              |    Keywords:     
------------------------------------------+---------------------------------
 '''Issue raise by J. Arkko in: http://www.ietf.org/mail-
 archive/web/lisp/current/msg02001.html'''



  A Map-Register message includes authentication data, so prior to sending
 a
  Map-Register message, the ETR and Map-Server must be configured with a
  secret  shared-key.  In addition, a Map-Server will typically perform
 additional
  verification checks, such as matching any EID-prefix listed in a Map-
 Register
  message against a list of prefixes for which the ETR is known to be
  an authoritative source.


 This seems weak in a number of ways. First, shouldn't there be some RFC
 2119 language that makes it clear exactly what aspects of this are
 required? This may also apply to other aspects of the document. Or are
 there other documents that have the normative specifications?

 Second, I think we should at the very least require that the additional
 verification is mandatory. And it needs to be spelled out in more exact
 terms, not with "such as".

 Third, the security considerations need to be clear about the security
 properties of this. What it can do and what it cannot do. In particular,
 if there is no additional verification then a local ETR can claim EID
 space that it does not own, and the Map-Server will happily distribute
 this to the world.

 Fourth, personally I would prefer to see a mechanism that allowed global
 verification of EID ownership. I believe this would be almost as easy to
 implement and and far easier to deploy than the current security model.
 Perhaps something SIDR like.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Mon Apr 26 01:24:27 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E593A69DE for ; Mon, 26 Apr 2010 01:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA14qr2NWegc for ; Mon, 26 Apr 2010 01:24:26 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 45A4628C123 for ; Mon, 26 Apr 2010 01:21:14 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6JYt-0006kX-0q; Mon, 26 Apr 2010 01:21:03 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 08:21:02 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/76
Message-ID: <068.45fcdf374d9ef1d35ed4fb98f02886e5@tools.ietf.org>
X-Trac-Ticket-ID: 76
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #76: Implication of using anycast addresses for Map-servers
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 08:24:27 -0000

#76: Implication of using anycast addresses for Map-servers
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:     
    Type:  technical                      |      Status:  new
Priority:  major                          |   Component:  ms 
Severity:  -                              |    Keywords:     
------------------------------------------+---------------------------------
 '''Issue raise by J. Arkko in:  http://www.ietf.org/mail-
 archive/web/lisp/current/msg02001.html'''

  Note that Map-Server associations with ETRs
  should NOT use anycast addresses as doing so could cause
  unpredictable forwarding of Map-Requests to the ETRs.


 I do not understand this. If the Map-Servers are on an anycast address,
 how does this affect forwarding to the ETRs? The ETRs are still on unicast
 addresses...

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Mon Apr 26 01:26:28 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0213828C0EE for ; Mon, 26 Apr 2010 01:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLaK+A3edHPg for ; Mon, 26 Apr 2010 01:26:27 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0ADE73A6A3A for ; Mon, 26 Apr 2010 01:24:14 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6Jbm-0007aY-O2; Mon, 26 Apr 2010 01:24:02 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 08:24:02 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/77
Message-ID: <068.863221f9957e52ab837ccb12f1b9b2d8@tools.ietf.org>
X-Trac-Ticket-ID: 77
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #77: On the use of key-chaining for re-keying
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 08:26:28 -0000

#77: On the use of key-chaining for re-keying
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:     
    Type:  technical                      |      Status:  new
Priority:  major                          |   Component:  alt
Severity:  -                              |    Keywords:     
------------------------------------------+---------------------------------
 '''Issue raise by J. Arkko in:  http://www.ietf.org/mail-
 archive/web/lisp/current/msg02001.html'''


  A key-chaining scheme may also be employed to facilitate
  re-keying as needed.

 This is a weak statement. If we have a chaining scheme to point to, lets
 reference it and say it SHOULD/MUST be supported. If not, maybe we can
 just say "A key-chaining scheme may be developed in the future as an
 extension of this specification." If we say the latter, we should also
 document the implications in the security considerations section.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Mon Apr 26 01:28:42 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56033A684C for ; Mon, 26 Apr 2010 01:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.527
X-Spam-Level: 
X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zlauH4A8jAA for ; Mon, 26 Apr 2010 01:28:42 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 568353A6A35 for ; Mon, 26 Apr 2010 01:27:43 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6JfA-0003ZO-3Q; Mon, 26 Apr 2010 01:27:32 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 08:27:32 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/77#comment:1
Message-ID: <077.69ba56fe724e41fa5198920634f12c49@tools.ietf.org>
References: <068.863221f9957e52ab837ccb12f1b9b2d8@tools.ietf.org>
X-Trac-Ticket-ID: 77
In-Reply-To: <068.863221f9957e52ab837ccb12f1b9b2d8@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: Re: [lisp] #77: On the use of key-chaining for re-keying
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 08:28:43 -0000

#77: On the use of key-chaining for re-keying
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:     
    Type:  technical                      |      Status:  new
Priority:  minor                          |   Component:  ms 
Severity:  -                              |    Keywords:     
------------------------------------------+---------------------------------
Changes (by luigi@…):

  * priority:  major => minor
  * component:  alt => ms


-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Mon Apr 26 01:31:37 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB2F3A6A2C for ; Mon, 26 Apr 2010 01:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.527
X-Spam-Level: 
X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMeAhRx0-ERk for ; Mon, 26 Apr 2010 01:31:36 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C48E93A68FA for ; Mon, 26 Apr 2010 01:30:53 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6JiE-0001rv-F2; Mon, 26 Apr 2010 01:30:42 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 08:30:42 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/78
Message-ID: <068.f713f8664a87d8479c836881ff78c848@tools.ietf.org>
X-Trac-Ticket-ID: 78
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #78: Missing things (from J. Arkko's mail)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 08:31:37 -0000

#78: Missing things (from J. Arkko's mail)
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:     
    Type:  technical                      |      Status:  new
Priority:  minor                          |   Component:  ms 
Severity:  -                              |    Keywords:     
------------------------------------------+---------------------------------
 '''Issue raised by J. Arkko in:  http://www.ietf.org/mail-
 archive/web/lisp/current/msg02001.html'''

 Missing things:

  * Is there some discussion somewhere about propagating changes to mapping
 data. AFAICT, caching Map-Resolvers and ITRs both store data for some
 amount of time. Can a change be propagated to them, or is this something
 that is not necessary based on some assumptions about the dynamics of the
 network?

  * Also, Map-Servers get updated with fresh information every minute.
 Perhaps the document should state that this puts a limit on how fast the
 information can change. Note that I'm not trying to argue that you should
 design the system for higher speed of change, I'm just asking for the
 characteristics of the design to be described.

  * There should probably be an operational considerations section, to talk
 about things like configurable parameters.

  * What issues do we expect the experiment to resolve? It would be good to
 document what implications of the design we do not currently fully
 understand.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Mon Apr 26 01:34:51 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C883A68EB for ; Mon, 26 Apr 2010 01:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Level: 
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vCY9-zRr374 for ; Mon, 26 Apr 2010 01:34:51 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2FD713A684F for ; Mon, 26 Apr 2010 01:34:51 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6Jm3-0001z3-US; Mon, 26 Apr 2010 01:34:39 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 08:34:39 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/79
Message-ID: <068.e4cec7b5ffd26202146ed883ccf61822@tools.ietf.org>
X-Trac-Ticket-ID: 79
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #79: Editorial Issues (from J. Arkko's mail)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 08:34:52 -0000

#79: Editorial Issues (from J. Arkko's mail)
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:     
    Type:  editorial                      |      Status:  new
Priority:  trivial                        |   Component:  ms 
Severity:  -                              |    Keywords:     
------------------------------------------+---------------------------------
 '''Issue raised by J. Arkko in:  http://www.ietf.org/mail-
 archive/web/lisp/current/msg02001.html'''

 Editorial:

 The document would benefit from a more systematic description of what the
 different message types, encapsulation modes, and src/dst addresses are. I
 had trouble following what addresses each message has in all cases, for
 instance.

   EID-to-RLOC mapping as that would introduce a circular dependancy.

 dependency...

   in a caching mode, where it saves information about oustanding Map-

 outstanding...

   Encapsulated Map-Reqeust to a matching ETR.  It does not otherwise
   Reqeusts, originates new Map-Requests to the correct ETR(s), accepts

 Request...


      ETR, though static configuration or another out-of-band mechanism

 through

  authoratative

 authoritative?

  Encapsulated Map-Request:   a LISP Map-Request with an additional
  LISP header prepended.  Sent to UDP destination port 4342.  The
  "outer" addresses are globally-routeable IP addresses, also known
  as RLOCs.  Used by an ITR when sending to a Map-Resolver and by a
  Map-Server when sending to an ETR.
 ... when forwarding a MAP-Request to an ETR?

  provides better information about the set
  of define EID prefixes.
 ... defined EID ...

 RFC 2402 is a normative reference, but not used anywhere.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From jmh@joelhalpern.com  Mon Apr 26 06:02:23 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B115C3A6A83 for ; Mon, 26 Apr 2010 06:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.72
X-Spam-Level: 
X-Spam-Status: No, score=0.72 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jog1OSgvjYdf for ; Mon, 26 Apr 2010 06:02:23 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 222733A692D for ; Mon, 26 Apr 2010 06:02:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D0A383235892 for ; Mon, 26 Apr 2010 06:02:11 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.10.14.10] (unknown [206.82.218.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id AEE503228513 for ; Mon, 26 Apr 2010 06:02:11 -0700 (PDT)
Message-ID: <4BD58ED4.1070204@joelhalpern.com>
Date: Mon, 26 Apr 2010 09:02:12 -0400
From: "Joel M. Halpern" 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "lisp@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [lisp] issue tracker
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 13:02:23 -0000

We noticed that the way the issue tracker was structured, there was no 
good way for someone to specifically mark a resolution of an issue, 
without closing it.  Closure really needs chair verification.

I asked the tools team what could be done.  We now have a new action 
(resolve) and a new state (resolved).  This represents a proposed 
resolution.  If the resolution turns out to be insufficient we can 
always re-open.  If it turns out to be right, we mark it closed.  It 
makes it easy for folks to track where we think we are with an issue.

Thank you,
Joel

From yakov@juniper.net  Mon Apr 26 07:57:10 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6404728C1CB for ; Mon, 26 Apr 2010 07:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.023
X-Spam-Level: 
X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.576,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCgJO9Mg+BQ9 for ; Mon, 26 Apr 2010 07:57:09 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id ACD773A6C3A for ; Mon, 26 Apr 2010 07:47:38 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKS9WnepmTkW9vA2fZrp+DPSGUImWvc9gC@postini.com; Mon, 26 Apr 2010 07:47:27 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Mon, 26 Apr 2010 07:45:04 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Apr 2010 07:45:04 -0700
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 07:45:04 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Apr 2010 07:45:03 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3QEj1D87077; Mon, 26 Apr 2010 07:45:02 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <201004261445.o3QEj1D87077@magenta.juniper.net>
To: Dino Farinacci 
In-Reply-To: <161D4280-7081-41F3-B546-C6DA23A74858@cisco.com> 
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0B7E4.8050608@raszuk.net> <201004222106.o3ML6ED35682@magenta.juniper.net> <4BD0BF7B.8050409@raszuk.net> <201004222139.o3MLd4D51678@magenta.juniper.net> <161D4280-7081-41F3-B546-C6DA23A74858@cisco.com>
X-MH-In-Reply-To: Dino Farinacci  message dated "Thu, 22 Apr 2010 14:45:42 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <37379.1272293101.1@juniper.net>
Date: Mon, 26 Apr 2010 07:45:01 -0700
From: Yakov Rekhter 
X-OriginalArrivalTime: 26 Apr 2010 14:45:03.0772 (UTC) FILETIME=[0E3FCDC0:01CAE54F]
Cc: lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 14:57:10 -0000

Dino,

> > In your example sites A and B have 4 ETRs, while site C has 6 ETRs.
> >
> > My scenario is different - site A has two ETRs, one connected to ISP  
> > X,
> > another to ISP Y. Ditto for site B. Site C has three ETRs, one
> > connected to ISP X, another to ISP Y, and the last one to ISP Z.
> >
> > What are the addresses used by these ETRs ?
> 
> In your case, and will probably be the typical case, each ETR address  
> will be the PA address from the provider the ETR is connected to.
> 
> If you want to throw anycast into the mix, then create a site D with 2  
> ETRs, each connected to the *same* ISP. In that case, an anycast RLOC  
> could be used and assigned to each ETR.

In this case please add the following to secion 8.2:

  When more than one CE at a site is configured with the same IP
  address (in which case an RLOC is an anycast address), then in
  order to avoid negative implications on routing scalability (in
  order to prevent carrying RLOCs as individual /32 (or /128 for
  IPv6) routes throughout the whole Internet), for a given site only
  CEs connected to the same ISP may be configured with the same IP
  address.

Yakov.

From dino@cisco.com  Mon Apr 26 08:05:26 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E123A6B7E for ; Mon, 26 Apr 2010 08:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.758
X-Spam-Level: 
X-Spam-Status: No, score=-9.758 tagged_above=-999 required=5 tests=[AWL=0.841,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3JjsaHVH32B for ; Mon, 26 Apr 2010 08:05:25 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D613F28C16C for ; Mon, 26 Apr 2010 07:58:12 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANdG1UurR7H+/2dsb2JhbACcOnGnOJlhhQwEgzk
X-IronPort-AV: E=Sophos;i="4.52,273,1270425600"; d="scan'208";a="188450259"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2010 14:58:01 +0000
Received: from [192.168.1.3] (sjc-vpn2-189.cisco.com [10.21.112.189]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3QEw1Wq014654; Mon, 26 Apr 2010 14:58:01 GMT
Message-Id: 
From: Dino Farinacci 
To: Yakov Rekhter 
In-Reply-To: <201004261445.o3QEj1D87077@magenta.juniper.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 26 Apr 2010 07:58:00 -0700
References: <068.d92e7478bf86c421ac2f1228852f774a@tools.ietf.org> <077.62c7c64ad4cb58383c62bbdfcbff96c0@tools.ietf.org> <4BD049B8.70408@cisco.com> <201004221935.o3MJZnD90060@magenta.juniper.net> <4BD0B7E4.8050608@raszuk.net> <201004222106.o3ML6ED35682@magenta.juniper.net> <4BD0BF7B.8050409@raszuk.net> <201004222139.o3MLd4D51678@magenta.juniper.net> <161D4280-7081-41F3-B546-C6DA23A74858@cisco.com> <201004261445.o3QEj1D87077@magenta.juniper.net>
X-Mailer: Apple Mail (2.936)
Cc: lisp@ietf.org
Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 15:05:26 -0000

> Dino,
>
>>> In your example sites A and B have 4 ETRs, while site C has 6 ETRs.
>>>
>>> My scenario is different - site A has two ETRs, one connected to ISP
>>> X,
>>> another to ISP Y. Ditto for site B. Site C has three ETRs, one
>>> connected to ISP X, another to ISP Y, and the last one to ISP Z.
>>>
>>> What are the addresses used by these ETRs ?
>>
>> In your case, and will probably be the typical case, each ETR address
>> will be the PA address from the provider the ETR is connected to.
>>
>> If you want to throw anycast into the mix, then create a site D  
>> with 2
>> ETRs, each connected to the *same* ISP. In that case, an anycast RLOC
>> could be used and assigned to each ETR.
>
> In this case please add the following to secion 8.2:
>
>  When more than one CE at a site is configured with the same IP
>  address (in which case an RLOC is an anycast address), then in
>  order to avoid negative implications on routing scalability (in
>  order to prevent carrying RLOCs as individual /32 (or /128 for
>  IPv6) routes throughout the whole Internet), for a given site only
>  CEs connected to the same ISP may be configured with the same IP
>  address.

Noted. Thanks.

Dino

>
> Yakov.


From jgs@juniper.net  Mon Apr 26 08:13:59 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78CC28C193 for ; Mon, 26 Apr 2010 08:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Level: 
X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCm8s0dFncHT for ; Mon, 26 Apr 2010 08:13:59 -0700 (PDT)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 196A33A6C1B for ; Mon, 26 Apr 2010 08:05:30 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKS9WrquvI9LJNlIfLnkisAGIjjPMmIAJy@postini.com; Mon, 26 Apr 2010 08:05:18 PDT
Received: from EMBX02-HQ.jnpr.net ([fe80::3453:d438:826:48d7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 26 Apr 2010 07:57:20 -0700
From: John Scudder 
To: Darrel Lewis 
Date: Mon, 26 Apr 2010 07:57:08 -0700
Thread-Topic: [lisp] LISP Site definition
Thread-Index: AcrlUMSLAaOL37YVS26Ows3tyGwUCQ==
Message-ID: 
References: <201004192048.o3JKmZD69911@magenta.juniper.net> <66E24B60-B0FC-459D-A177-8F9799104FD6@cisco.com>  <6A74C3C6-C4BF-4255-82DA-F2E062A3BFFB@cisco.com>   <28D2235B-E40F-402C-A881-E6403398D179@juniper.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Drake , John, "lisp@ietf.org" 
Subject: Re: [lisp] LISP Site definition
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 15:13:59 -0000

On Apr 23, 2010, at 4:32 PM, Darrel Lewis wrote:
> I agree and suggest that it would be good to add "LISP Site" to the Defin=
ition of Terms section of the document.=20

It might be helpful to provide examples of what a "site" can and can't be, =
e.g. it seems pretty clear a site can be a single physical office (and asso=
ciated network infrastructure, etc).  Can a site be:

- A single home?
- A single host which speaks LISP natively?
- A global enterprise with extensive internal infrastructure?

Thanks,

--John=

From root@core3.amsl.com  Mon Apr 26 09:00:01 2010
Return-Path: 
X-Original-To: lisp@ietf.org
Delivered-To: lisp@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 5A2203A69B5; Mon, 26 Apr 2010 09:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100426160001.5A2203A69B5@core3.amsl.com>
Date: Mon, 26 Apr 2010 09:00:01 -0700 (PDT)
Cc: lisp@ietf.org
Subject: [lisp] I-D Action:draft-ietf-lisp-alt-04.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 16:00:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF.


	Title           : LISP Alternative Topology (LISP+ALT)
	Author(s)       : V. Fuller, et al.
	Filename        : draft-ietf-lisp-alt-04.txt
	Pages           : 28
	Date            : 2010-04-26

This document describes a simple mapping database to be used by the
Locator/ID Separation Protocol (LISP) to find Endpoint Identifier
(EID) to Routing Locator (RLOC) mappings.  Termed the Alternative
Logical Topology (ALT), the database is built as an overlay network
on the public Internet using the Border Gateway Protocol (BGP) and
the Generic Routing Encapsulation (GRE).  Using these proven
protocols, the ALT can be built and deployed relatively quickly
without major changes to the existing routing infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lisp-alt-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-lisp-alt-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-04-26085426.I-D@ietf.org>


--NextPart--

From root@core3.amsl.com  Mon Apr 26 09:00:01 2010
Return-Path: 
X-Original-To: lisp@ietf.org
Delivered-To: lisp@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 5C2783A69C3; Mon, 26 Apr 2010 09:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100426160001.5C2783A69C3@core3.amsl.com>
Date: Mon, 26 Apr 2010 09:00:01 -0700 (PDT)
Cc: lisp@ietf.org
Subject: [lisp] I-D Action:draft-ietf-lisp-ms-05.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 16:00:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF.


	Title           : LISP Map Server
	Author(s)       : V. Fuller, D. Farinacci
	Filename        : draft-ietf-lisp-ms-05.txt
	Pages           : 14
	Date            : 2010-04-26

This draft describes the LISP Map-Server (LISP-MS), a computing
system which provides a simple LISP protocol interface as a "front
end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping
database and associated virtual network of LISP protocol elements.

The purpose of the Map-Server is to simplify the implementation and
operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel
Routers (ETRs), the devices that implement the "edge" of the LISP
infrastructure and which connect directly to LISP-capable Internet
end sites.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-lisp-ms-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-04-26085527.I-D@ietf.org>


--NextPart--

From vaf@cisco.com  Mon Apr 26 09:02:16 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48B73A690C for ; Mon, 26 Apr 2010 09:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.63
X-Spam-Level: 
X-Spam-Status: No, score=-9.63 tagged_above=-999 required=5 tests=[AWL=0.969,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p9JJ8ZfLGyq for ; Mon, 26 Apr 2010 09:02:15 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D66BE3A6840 for ; Mon, 26 Apr 2010 09:02:15 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoUGABRW1UurR7H+/2dsb2JhbACQN4wFcagnmW6FCwSDOQ
X-IronPort-AV: E=Sophos;i="4.52,274,1270425600"; d="scan'208";a="188486699"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2010 16:02:04 +0000
Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3QG24k4018063 for ; Mon, 26 Apr 2010 16:02:04 GMT
Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id B2E8720CF12; Mon, 26 Apr 2010 09:02:03 -0700 (PDT)
Date: Mon, 26 Apr 2010 09:02:03 -0700
From: Vince Fuller 
To: lisp@ietf.org
Message-ID: <20100426160203.GA58969@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: New Version Notification for draft-ietf-lisp-alt-04
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 16:02:16 -0000

FYI.

This changes are mostly editorial. The one substantive change is to update
the description of Map-Reply destination IP address selection to correspond
to the new multi-AF/multi-RLOC behavior documented in draft-ietf-lisp-07.

	--Vince
	(for the LISP draft co-authors)


----- Forwarded message from IETF I-D Submission Tool  -----

Date: Mon, 26 Apr 2010 08:54:26 -0700 (PDT)
From: IETF I-D Submission Tool 
To: vaf@cisco.com
Cc: dino@cisco.com, dmm@cisco.com, darlewis@cisco.com
Subject: New Version Notification for draft-ietf-lisp-alt-04 
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigBAG5U1UtAqmIgjmdsb2JhbACDFo0fAQGMBRUBAQEBCQsICQ8HHagZiGmRA4ElgnltBIM5


A new version of I-D, draft-ietf-lisp-alt-04.txt has been successfully submitted by Vince Fuller and posted to the IETF repository.

Filename:	 draft-ietf-lisp-alt
Revision:	 04
Title:		 LISP Alternative Topology (LISP+ALT)
Creation_date:	 2010-04-26
WG ID:		 lisp
Number_of_pages: 28

Abstract:
This document describes a simple mapping database to be used by the
Locator/ID Separation Protocol (LISP) to find Endpoint Identifier
(EID) to Routing Locator (RLOC) mappings.  Termed the Alternative
Logical Topology (ALT), the database is built as an overlay network
on the public Internet using the Border Gateway Protocol (BGP) and
the Generic Routing Encapsulation (GRE).  Using these proven
protocols, the ALT can be built and deployed relatively quickly
without major changes to the existing routing infrastructure.
                                                                                  


The IETF Secretariat.


----- End forwarded message -----

From vaf@cisco.com  Mon Apr 26 09:06:16 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0FF828C116 for ; Mon, 26 Apr 2010 09:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.39
X-Spam-Level: 
X-Spam-Status: No, score=-7.39 tagged_above=-999 required=5 tests=[AWL=-1.658,  BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, SARE_HTML_SINGLETS=1.666]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phiPaTjEzHwj for ; Mon, 26 Apr 2010 09:06:14 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 377E228C115 for ; Mon, 26 Apr 2010 09:05:58 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: rfcdiff-ms-04-to-05.html : 35373
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAE9W1UurR7Hu/2dsb2JhbACcPHGoLos3jjeFCwSDOQ
X-IronPort-AV: E=Sophos;i="4.52,274,1270425600";  d="html'217?scan'217,208,217";a="252491165"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2010 16:05:46 +0000
Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3QG5kQD002488 for ; Mon, 26 Apr 2010 16:05:46 GMT
Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id A649B20CF74; Mon, 26 Apr 2010 09:05:45 -0700 (PDT)
Date: Mon, 26 Apr 2010 09:05:45 -0700
From: Vince Fuller 
To: lisp@ietf.org
Message-ID: <20100426160545.GB58969@vaf-mac1.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [lisp] Fwd: New Version Notification for draft-ietf-lisp-ms-05
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 16:06:17 -0000

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

FYI. Again, mostly editorial changes but with several substantive and/or
clarifying changes as well:

- add caveats around Map-Resolver caching and recommendation not to do so
  in normal operation

- stronger language advocating Map-Server verification of EID-prefixes offered
  by ETR during registration process

- mention limit on convergence time based on ETR/MS refresh interval

- add open issues section

- add additional known security considerations

An "rfcdiff" of the -04 and -05 versions is attached.

	--Vince
	(for the LISP draft authors)

----- Forwarded message from IETF I-D Submission Tool  -----

Date: Mon, 26 Apr 2010 08:55:27 -0700 (PDT)
From: IETF I-D Submission Tool 
To: vaf@cisco.com
Cc: dino@cisco.com
Subject: New Version Notification for draft-ietf-lisp-ms-05 
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigBAKpU1UtAqmIgjmdsb2JhbACDFo0fAQGMBRUBAQEBCQsICQ8HHagRiGmRA4ElgnltBIM5


A new version of I-D, draft-ietf-lisp-ms-05.txt has been successfully submitted by Vince Fuller and posted to the IETF repository.

Filename:	 draft-ietf-lisp-ms
Revision:	 05
Title:		 LISP Map Server
Creation_date:	 2010-04-26
WG ID:		 lisp
Number_of_pages: 14

Abstract:
This draft describes the LISP Map-Server (LISP-MS), a computing
system which provides a simple LISP protocol interface as a "front
end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping
database and associated virtual network of LISP protocol elements.

The purpose of the Map-Server is to simplify the implementation and
operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel
Routers (ETRs), the devices that implement the "edge" of the LISP
infrastructure and which connect directly to LISP-capable Internet
end sites.
                                                                                  


The IETF Secretariat.


----- End forwarded message -----

--FL5UXtIhxfXey3p5
Content-Type: text/html; charset=us-ascii
Content-Disposition: attachment; filename="rfcdiff-ms-04-to-05.html"



wdiff draft-ietf-lisp-ms-04.txt draft-ietf-lisp-ms-05.txt

Network Working Group                                          V. Fuller
Internet-Draft                                              D. Farinacci
Intended status: Experimental                              cisco Systems
Expires: October 28, 2010                                 April 8, 26, 2010                                   October 5, 2009

                            LISP Map Server
                       draft-ietf-lisp-ms-04.txt
                       draft-ietf-lisp-ms-05.txt

Abstract

   This draft describes the LISP Map-Server (LISP-MS), a computing
   system which provides a simple LISP protocol interface as a "front
   end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping
   database and associated virtual network of LISP protocol elements.

   The purpose of the Map-Server is to simplify the implementation and
   operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel
   Routers (ETRs), the devices that implement the "edge" of the LISP
   infrastructure and which connect directly to LISP-capable Internet
   end sites.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 8, October 28, 2010.

Copyright Notice

   Copyright (c) 2009 2010 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 (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   This draft describes the LISP Map-Server (LISP-MS), a computing
   system which provides a simple LISP protocol interface  Code Components extracted from this document must
   include Simplified BSD License text 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 described in Section 4.e of
   the Map-Server is to simplify the implementation and
   operation of LISP Ingress Tunnel Routers (ITRs) Trust Legal Provisions and Egress Tunnel
   Routers (ETRs), the devices that implement the "edge" of are provided without warranty as
   described in the LISP
   infrastructure and which connect directly to LISP-capable Internet
   end sites. Simplified BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  5
   4.  4
   3.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  5
   4.  Interactions With Other LISP Components  . . . . . . . . . . .  7
     5.1.  6
     4.1.  ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . .  7
     5.2.  6
     4.2.  ETR/Map-Server EID Prefix Registration . . . . . . . . . .  7
     5.3.
     4.3.  Map-Server Processing  . . . . . . . . . . . . . . . . . .  8
     5.4.
     4.4.  Map-Resolver Processing  . . . . . . . . . . . . . . . . .  8
       5.4.1.
       4.4.1.  Anycast Map-Resolver Operation . . . . . . . . . . . .  9
   6.  Security
   5.  Open Issues and Considerations . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . 10 . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11 12
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 12 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 14

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   LISP [LISP] specifies an architecture and mechanism for replacing the
   addresses currently used by IP with two separate name spaces: EIDs,
   used within sites, and RLOCs, used on the transit networks that make
   up the Internet infrastructure.  To achieve this separation, LISP
   defines protocol mechanisms for mapping from EIDs to RLOCs.  In
   addition, LISP assumes the existence of a database to store and
   propagate those mappings globally.  Several such databases have been
   proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD] and LISP+
   ALT [ALT], with LISP+ALT being the system that is currently being
   implemented and deployed on the pilot LISP network. [ALT].

   There are two types of operation for a LISP Map-Server: as a Map-
   Resolver, which accepts Map-Requests from an ITR and "resolves" the
   EID-to-RLOC mapping using the distributed mapping database, and as a
   Map-Server, which learns authoratative authoritative EID-to-RLOC mappings from an
   ETR and publish them in the database.  A single device may implement
   one or both types of operation.

   Conceptually, LISP Map-Servers share some of the same basic
   configuration and maintenance properties as Domain Name System (DNS)
   [RFC1035] servers and caching resolvers.  With this in mind, this
   specification borrows familiar terminology (resolver and server) from
   the DNS specifications.

3.

   Note that while this document assumes a LISP+ALT database mapping
   infrastructure to illustrate certain aspects of Map-Server and Map-
   Resolver operation, this is not intended to preclude the use of Map-
   Servers and Map-Resolvers as a a standardized interface for ITRs and
   ETRs to access other mapping database systems.

2.  Definition of Terms

   Map-Server:   a network infrastructure component which learns EID-to-
      RLOC mapping entries from an authoratative authoritative source (typically, an
      ETR, though through static configuration or another out-of-band mechanism
      may be used).  A Map-Server publishes these mappings in the
      distributed mapping database.

   Map-Resolver:   a network infrastructure component which accepts LISP
      Encapsulated Map-Requests, typically from an ITR, quickly
      determines whether or not the destination IP address is part of
      the EID namespace; if it is not, a Negative Map-Reply is
      immediately returned.  Otherwise, the Map-Resolver finds the
      appropriate EID-to-RLOC mapping by consulting the distributed
      mapping database system.

   Encapsulated Map-Request:   a LISP Map-Request with an additional
      LISP header prepended.  Sent to UDP destination port 4342.  The
      "outer" addresses are globally-routeable IP addresses, also known
      as RLOCs.  Used by an ITR when sending to a Map-Resolver and by a
      Map-Server when sending forwarding a Map-Request to an ETR.

   Negative Map-Reply:   a LISP Map-Reply that contains an empty
      locator-set.  Returned in response to a Map-Request if the
      destination EID does not exist in the mapping database.
      Typically, this means that the "EID" being requested is an IP
      address connected to a non-LISP site.

   Map-Register message:   a LISP message sent by an ETR to a Map-Server
      to register its associated EID prefixes. EID-prefixes.  In addition to the set
      of EID prefixes EID-prefixes to register, the message includes one or more
      RLOCs to be be used by the Map-Server when forwarding Map-Requests
      (re-formatted as Encapsulated Map-Requests) received through the
      database mapping system.

   For definitions of other terms, notably Map-Request, Map-Reply,
   Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
   consult the LISP specification [LISP].

4.

3.  Basic Overview

   A Map-Server is a device which publishes EID-prefix information on
   behalf of ETRs and connects to the LISP distributed mapping database
   system to help answer LISP Map-Requests seeking the RLOCs for those
   EID prefixes.
   EID-prefixes.  To publish its EID-prefixes, an ETR periodically sends
   Map-Register messages to the Map-Server.  A Map-Register message
   contains a list of EID-prefixes plus a set of RLOCs that can be used
   to reach the ETR when a Map-Server needs to forward a Map-Request to
   it.

   On the LISP pilot network, which

   When LISP+ALT is expected to be a model for
   deployment of LISP on used as the Internet, mapping database, a Map-Server connects
   to LISP+ALT ALT network and acts as a "last-hop" ALT router.  Intermediate ALT
   routers forward Map-Requests to the Map-Server that advertises a
   particular EID-prefix and the Map-Server forwards them to the owning
   ETR, which responds with Map-Reply messages.

   The LISP Map-Server design also includes the operation of a Map-
   Resolver, which receives Encapsulated Map-Requests from its client
   ITRs and uses the distributed mapping database system to find the
   appropriate ETR to answer those requests.  On the pilot a LISP+ALT network, a
   Map-Resolver acts as a "first-hop" ALT router.  It has GRE tunnels
   configured to other ALT routers and uses BGP to learn paths to ETRs
   for different prefixes in the LISP+ALT database.  The Map-Resolver
   uses this path information to forward Map-Requests over the ALT to
   the correct ETRs.  A Map-Resolver may operate in a non-caching mode,
   where it simply de-capsulates and forwards the Encapsulated Map-
   Requests that it receives from ITRs.

   Alternatively, it a Map-Resolver may operate in a caching mode, where it
   saves information about oustanding Map-
   Reqeusts, outsanding Map-Reqeusts, originates new Map-Requests Map-
   Requests to the correct ETR(s), accepts and caches the Map-Replies,
   and finally forwards the Map-Replies to the original ITRs.

   Note  One
   significant issue with use of caching in a Map-Resolver is that it
   hides the original ITR source of a Map-Request, which prevents an ETR
   from tailoring its responses to that source; this reduces the inbound
   traffic- engineering capability for the site owning the ETR.  In
   addition, caching in a Map-Resolver exacerbates problems associated
   with old mappings being cached; an outdated, cached mapping in an ITR
   affects only that ITR and traffic originated by its site while an
   outdate, cached mapping in a Map-Resolver could cause a problem with
   a wider scope.  More experience with caching Map-Resolvers on the
   LISP pilot network will be needed to determine whether their use can
   be recommended.

   While a single device can implement the functions of both a Map-
   Server and a Map-Resolver.  As is the case with the DNS, however,
   operational simplicity argues for keeping those functions separate.

5.

4.  Interactions With Other LISP Components

5.1.

4.1.  ITR EID-to-RLOC Mapping Resolution

   An ITR is configured with the address of a Map-Resolver.  This
   address is a "locator" or RLOC in that it must be routeable on the
   underlying core network; it must not need to be resolved through LISP
   EID-to-RLOC mapping as that would introduce a circular dependancy. dependency.
   When using a Map-Resolver, an ITR does not need to connect to any
   other database mapping system.  In particular, the ITR need not
   connect to the LISP+ALT infrastructure or implement the BGP and GRE
   protocols that it uses.

   An ITR sends an Encapsulated Map-Request to a configured Map-Resolver
   when it needs an EID-to-RLOC mapping that is not found in its local
   map-cache.  Using the Map-Resolver greatly reduces both the
   complexity of the ITR implementation the costs associated with its
   operation.

   In response to an Encapsulated Map-Request, the ITR can expect one of
   the following:

   o  A negative LISP Map-Reply if the Map-Resolver can determine that
      the requested EID does not exist.  The ITR saves EID prefix EID-prefix
      returned in the Map-Reply in its cache, marking it as non-LISP-
      capable and knows not to attempt LISP encapsulation for
      destinations matching it.

   o  A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
      possibly from a Map-Server answering on behalf of the ETR.  Note
      that the stateless nature of non-caching Map-Resolver forwarding
      means that the Map-Reply may not be from the Map-Resolver to which
      the Encapsulated Map-Request was sent unless the target Map-
      Resolver offers caching (Section 5.4). 4.4).

   Note that an ITR may use a Map-Resolver while also participating in
   another mapping database mechanism.  For example, an ITR that runs
   LISP+ALT can also send Encapsulated Map-Requests to a Map-Resolver.
   When doing this, an ITR should prefer querying an ETR learned through
   the ALT network as LISP+ALT provides better information about the set
   of define EID prefixes. defined EID-prefixes.  Such a configuration is expected to be very
   rare, since there is little benefit to using a Map-Resolver if an ITR
   is already using a mapping database system.

5.2.  ETR/Map-Server EID Prefix Registration

   An ETR publishes its EID prefixes on  There would be, for
   example, no need for such an ITR to send a Map-Server Map-Request to a possibly
   non-existent EID (and rely on Negative Map-Replies) if it can consult
   the ALT database to verify that an EID-prefix is present before
   sending that Map-Request.

4.2.  ETR/Map-Server EID Prefix Registration

   An ETR publishes its EID-prefixes on a Map-Server by sending LISP
   Map-Register messages.  A Map-Register message includes
   authentication data, so prior to sending a Map-Register message, the
   ETR and Map-Server must be configured with a secret shared-key.  In
   addition, a Map-Server will typically perform additional verification
   checks, such as matching any EID-prefix listed in a Map-Register
   message against a  A
   Map-Server's configuration should also include list of the EID-
   prefixes for which the each ETR is known authoratative and should verify that a
   Map-Register received from an ETR only contain EID-prefixes that are
   associated with that ETR.  While this check is not mandatory, it is
   strongly encouraged as a failure to so leaves the mapping system
   vulnerable to simple EID-prefix hijacking attacks.  As developers and
   users gain experience with the mapping system, additional, stronger
   security measures may be
   an authoritative source. added to the registration process.

   Map-Register messages are sent periodically from an ETR to a Map-
   Server with a suggested interval between messages of one minute.  A
   Map-Server should time-out and remove an ETR's registration if it has
   not received a valid Map-Register message within the past three
   minutes.  When first contacting a Map-Server after restart or changes
   to its EID-to-RLOC database mappings, an ETR may initially send Map-
   Register messages at an increased frequency, up to one every 20
   seconds.  This "quick registration" period is limited to five minutes
   in duration.

   Note that a one-minute minimum registration interval during steady
   state maintenance of an association between an ITR and a Map-Server
   does set a lower-bound on how quickly and how frequently a mapping
   database entry can be updated.  This may have implications for what
   sorts of mobility can supported directly by the mapping system.  For
   a discussion on one way that faster mobility may be implemented for
   individual devices, please see [LISP-MN].

   An ETR which uses a Map-Server to publish its EID-to-RLOC mappings
   does not need to participate further in the mapping database
   protocol(s).  On the pilot network,  When using a LISP+ALT mapping database, for example,
   this means that the ETR does not need to implement GRE or BGP, which
   greatly simplifies its configuration and reduces its cost of
   operation.

   Note that use of a Map-Server does not preclude an ETR from also
   connecting to the mapping database (i.e. it could also connect to the
   LISP+ALT network) but doing so doesn't seem particularly useful as
   the whole purpose of using a Map-Server is to avoid the complexity of
   the mapping database protocols.

5.3.

4.3.  Map-Server Processing

   The operation of a Map-Server, once it has EID-prefixes registered by
   its client ETRs, is quite simple.  In response to a Map-Request
   (received over the ALT on the pilot network), if LISP+ALT is in use), the Map-Server
   verifies that the destination EID matches an EID-prefix for which it
   has one or more registered ETRs, then re-encapsulates and forwards
   the now-
   Encapsulated Map-Reqeust now-Encapsulated Map-Request to a matching ETR.  It does not
   otherwise alter the Map-Request so any Map-Reply sent by the ETR is
   returned to the RLOC in the Map-Request, not to the Map-Server.
   Unless also acting as a Map-Resolver, a Map-Server should never
   receive Map-
   Replies; Map-Replies; any such messages should be discarded without
   response, perhaps accompanied by logging of a diagnostic message if
   the rate of Map-Replies is suggestive of malicious traffic.

5.4.

4.4.  Map-Resolver Processing

   In response to an Encapsulated Map-Request, a Map-Resolver de-
   capsulates the message then checks its local database of mapping
   entries (statically configured, cached, or learned from associated
   ETRs).  If it finds a matching entry, it returns a non-authoratative non-authoritative
   LISP Map-Reply with the known mapping.

   If the Map-Resolver does not have the mapping entry and if it can
   determine that the requested IP address does not match an EID-prefix
   in the mapping database, it immediately returns a negative LISP Map-
   Reply, one which contains an EID prefix EID-prefix and an empty locator-set.  To
   minimize the number of negative cache entries needed by an ITR, the
   Map-Resolver should return the least-specific prefix which both
   matches the original query and does not match any EID-prefix known to
   exist in the LISP-capable infrastructure.

   If the Map-Resolver does not have sufficient information to know
   whether the EID exists, it needs to forward the Map-Request to
   another device which has more information about the EID being
   requested.  This is done in one of two ways:

   1.  A non-caching Map-Resolver simply forwards the unencapsulated
       Map-Request, with the original ITR RLOC as the source, on to the
       distributed mapping database.  On the pilot network,  Using a LISP+ALT mapaping
       database, the Map-
       Resolver Map-Resolver is connected to the ALT network and
       sends the Map-
       Request Map-Request to the next ALT hop learned from its ALT
       BGP neighbors.  The Map-Resolver does not send any response to
       the ITR; since the source RLOC is that of the ITR, the ETR or
       Map-Server which receives the Map-Request over the ALT and
       responds will do so directly to the ITR.

   2.  A caching Map-Resolver queues information from the Encapsulated
       Map-Request, including the ITR RLOC and the original nonce.  It
       then modifies the Map-Request to use its own RLOC, generates a
       "local nonce" (which is also saved in the request queue entry),
       and forwards the Map-Request as above.  When the Map-Resolver
       receives a Map-Reply, it looks in its request queue to match the
       reply nonce to a "local nonce" entry then de-queues the entry and
       uses the saved original nonce and ITR RLOC to re-write those
       fields in the Map-Reply before sending to the ITR.  The request
       queue entry is also deleted and the mapping entries from the Map-
       Reply are saved in the Map-Resolver's cache.

5.4.1.

4.4.1.  Anycast Map-Resolver Operation

   A Map-Resolver can be set up to use "anycast", where where the same
   address is assigned to multiple Map-Resolvers and is propagated
   through IGP routing, to facilitate the use of a topologically-close
   Map-Resolver each ITR.

   Note that Map-Server associations with ETRs should NOT not use anycast
   addresses as doing so could cause
   unpredictable forwarding of Map-Requests registrations need to be established between an ETR and
   a specific set of Map-Servers, each identified by a specific
   registation association.

5.  Open Issues and Considerations

   There are a number of issues with the ETRs. Map-Server and Map-Resolver
   design that are not yet completely understood.  Among these are:

   o  Feasibility, performance, and complexity trade-offs of
      implementing caching in Map-Resolvers

   o  Convergence time when an EID-to-RLOC mapping changes and
      mechanisms for detecting and refreshing or removing stale, cached
      information

   o  Deployability and complexity trade-offs of implementing stronger
      security measures in both EID-prefix registration and Map-Request/
      Map-Reply processing

   o  Requirements for additional state in the registration process
      between Map-Servers and ETRs

   o  Possible need for security associations between a Map-Resolver and
      its client ITRs

   The authors expect that experimentation on the LISP pilot network
   will help answer open questions surrounding these and other issues.

6.  Security Considerations

   The 2-way nonce exchange documented in [LISP] can be used to avoid
   ITR spoofing attacks.

   To publish an authoratative authoritative EID-to-RLOC mapping with a Map-Server, an
   ETR includes authentication data that is a hash of the message using
   pair-wise shared key.  An implementation MUST must support use of HMAC-
   SHA-1-96 [RFC2404] and SHOULD should support use of HMAC-SHA-128-256
   [RFC4634].  A  Key changes are initially expected to be manual though a
   key-chaining scheme may also be employed developed as a future extension of this
   specification.

   As noted in Section 4.2, a Map-Server should verify that all EID-
   prefixes registered by an ETR match configuration stored on the Map-
   Server.

   The current LISP and LISP-MS protocol exchange, where an ITR sends a
   Map-Request through a Map-Resolver, mapping database infrastructure,
   and Map-Server while an ETR returns a Map-Reply directly to facilitate
   re-keying the ITR
   makes it difficult for the ITR to verify that the returned EID-prefix
   length matches that registered by the ETR with, and therefore checked
   by, a Map-Server.

   While beyond the scope of securing an individual Map-Server or Map-
   Resolver, it should be noted that a BGP-based LISP+ALT network (if
   ALT is used as needed. the mapping database infrastructure) can take
   advantage of technology being developed by the IETF SIDR working
   group or either S-BGP [I-D.murphy-bgp-secr] or soBGP
   [I-D.white-sobgparchitecture] should they be developed and widely
   deployed.

7.  References

7.1.  Normative References

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-04.txt (work in progress), April 2010.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-07.txt (work in progress), April 2010.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 2006.

7.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-01.txt (work in progress), March 2009.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [LISP]

   [I-D.murphy-bgp-secr]
              Murphy, S., "BGP Security Analysis",
              draft-murphy-bgp-secr-04 (work in progress),
              November 2001.

   [I-D.white-sobgparchitecture]
              White, R., "Architecture and Deployment Considerations for
              Secure Origin BGP (soBGP)",
              draft-white-sobgparchitecture-00 (work in progress),
              May 2004.

   [LISP-MN]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-05.txt (work in progress) "LISP
              Mobile Node Architecture", draft-meyer-lisp-mn-01.txt
              (work in progress), September 2009. February 2010.

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

Appendix A.  Acknowledgments

   The authors would like to thank Greg Schudel, Darrel Lewis, John
   Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver,
   and members of the lisp@ietf.org mailing list for their feedback and
   helpful suggestions.

   Special thanks are due to Noel Chiappa for his extensive work on
   caching with LISP-CONS, some of which will be used by Map-Resolvers.

Authors' Addresses

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dino   Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com



--FL5UXtIhxfXey3p5--

From vaf@cisco.com  Mon Apr 26 09:08:53 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62EBE28C16C for ; Mon, 26 Apr 2010 09:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.947
X-Spam-Level: 
X-Spam-Status: No, score=-7.947 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6rOsw-jRjGU for ; Mon, 26 Apr 2010 09:08:45 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 309C13A6A02 for ; Mon, 26 Apr 2010 09:07:46 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: rfcdiff-alt-03-to-04.html : 59803
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAE5X1UurRN+J/2dsb2JhbACcPHGoRpltglUMgioEgzmMGQ
X-IronPort-AV: E=Sophos;i="4.52,274,1270425600";  d="html'217?scan'217,208,217";a="188489894"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2010 16:07:33 +0000
Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3QG7XJ3000395 for ; Mon, 26 Apr 2010 16:07:33 GMT
Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 4EF1E20CFC0; Mon, 26 Apr 2010 09:07:33 -0700 (PDT)
Date: Mon, 26 Apr 2010 09:07:33 -0700
From: Vince Fuller 
To: lisp@ietf.org
Message-ID: <20100426160732.GA59039@vaf-mac1.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [lisp] Fwd: New Version Notification for draft-ietf-lisp-alt-04
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 16:08:53 -0000

--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

(sending again with "rfcdiff" from -03 to -04 attached)

FYI.

This changes are mostly editorial. The one substantive change is to update
the description of Map-Reply destination IP address selection to correspond
to the new multi-AF/multi-RLOC behavior documented in draft-ietf-lisp-07.

	--Vince
	(for the LISP draft co-authors)


----- Forwarded message from IETF I-D Submission Tool  -----

Date: Mon, 26 Apr 2010 08:54:26 -0700 (PDT)
From: IETF I-D Submission Tool 
To: vaf@cisco.com
Cc: dino@cisco.com, dmm@cisco.com, darlewis@cisco.com
Subject: New Version Notification for draft-ietf-lisp-alt-04 
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigBAG5U1UtAqmIgjmdsb2JhbACDFo0fAQGMBRUBAQEBCQsICQ8HHagZiGmRA4ElgnltBIM5


A new version of I-D, draft-ietf-lisp-alt-04.txt has been successfully submitted by Vince Fuller and posted to the IETF repository.

Filename:	 draft-ietf-lisp-alt
Revision:	 04
Title:		 LISP Alternative Topology (LISP+ALT)
Creation_date:	 2010-04-26
WG ID:		 lisp
Number_of_pages: 28

Abstract:
This document describes a simple mapping database to be used by the
Locator/ID Separation Protocol (LISP) to find Endpoint Identifier
(EID) to Routing Locator (RLOC) mappings.  Termed the Alternative
Logical Topology (ALT), the database is built as an overlay network
on the public Internet using the Border Gateway Protocol (BGP) and
the Generic Routing Encapsulation (GRE).  Using these proven
protocols, the ALT can be built and deployed relatively quickly
without major changes to the existing routing infrastructure.
                                                                                  


The IETF Secretariat.

--6TrnltStXW4iwmi0
Content-Type: text/html; charset=us-ascii
Content-Disposition: attachment; filename="rfcdiff-alt-03-to-04.html"



wdiff draft-ietf-lisp-alt-03.txt draft-ietf-lisp-alt-04.txt

Network Working Group                                          V. Fuller
Internet-Draft                                              D. Farinacci
Intended status: Experimental                                   D. Meyer
Expires: September 30, October 28, 2010                                       D. Lewis
                                                                   Cisco
                                                          March 29,
                                                          April 26, 2010

                  LISP Alternative Topology (LISP+ALT)
                       draft-ietf-lisp-alt-03.txt
                       draft-ietf-lisp-alt-04.txt

Abstract

   This document describes a simple mapping database to be used by the
   Locator/ID Separation Protocol (LISP) to find Endpoint Identifier
   (EID) to Routing Locator (RLOC) mappings.  Termed the Alternative
   Logical Topology (ALT), the database is built as an overlay network
   on the public Internet using the Border Gateway Protocol (BGP) and
   the Generic Routing Encapsulation (GRE).  Using these proven
   protocols, the ALT can be built and deployed relatively quickly
   without major changes to the existing routing infrastructure.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 30, October 28, 2010.

Copyright Notice

   Copyright (c) 2010 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  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  5
   3.  The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Routeability of EIDs . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  Mechanisms for an ETR to originate EID-prefixes  . . .  9
       3.1.2.  Mechanisms for an ITR to forward to EID-prefixes . . .  9
       3.1.3.  Map Server Model preferred . . . . . . . . . . . . . .  9
     3.2.  Connectivity to non-LISP sites . . . . . . . . . . . . . .  9
     3.3.  Caveats on the use of Data Probes  . . . . . . . . . . . . 10
   4.  LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  ITR traffic handling . . . . . . . . . . . . . . . . . . . 12
     4.2.  EID Assignment - Hierarchy and Topology  . . . . . . . . . 12
     4.3.  Use of GRE and BGP between LISP+ALT Routers  . . . . . . . 14
   5.  EID-prefix Propagation and Map-Request Forwarding  . . . . . . 15
     5.1.  Changes to ITR behavior with LISP+ALT  . . . . . . . . . . 15
     5.2.  Changes to ETR behavior with LISP+ALT  . . . . . . . . . . 15
   6.  BGP configuration and protocol considerations  . . . . . . . . 17
     6.1.  Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 17
     6.2.  Sub-Address Family Identifier (SAFI) for LISP+ALT  . . . . 17
   7.  EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 18
     7.1.  Stability of the ALT . . . . . . . . . . . . . . . . . . . 18
     7.2.  Traffic engineering using LISP . . . . . . . . . . . . . . 18
     7.3.  Edge aggregation and dampening . . . . . . . . . . . . . . 19
     7.4.  EID assignment flexibility vs. ALT scaling . . . . . . . . 19
   8.  Connecting sites to the ALT network  . . . . . . . . . . . . . 21
     8.1.  ETRs originating information into the ALT  . . . . . . . . 21
     8.2.  ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 21
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 24
     10.1. Apparent LISP+ALT Vulnerabilities  . . . . . . . . . . . . 24
     10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 25
     10.3. Use of new IETF standard BGP Security mechanisms . . . . . 25
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     12.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28

1.  Introduction

   This document describes the LISP+ALT mapping database, to be used by
   LISP to find EID-to-RLOC mappings.  The ALT network is built using
   the Border Gateway Protocol (BGP, [RFC4271]), the BGP multi-protocol
   extension [RFC4760], and the Generic Routing Encapsulation (GRE,
   [RFC2784]) to construct an overlay nnetwork network of devices (ALT Routers)
   which operate on EID-prefixes and use EIDs as forwarding
   destinations.

   ALT Routers advertise hierarchically-delegated segments of the EID
   namespace (i.e., prefixes) toward the rest of the ALT; they also
   forward traffic destined for an EID covered by one of those prefixes
   toward the network element which that is authoritative for that EID (i.e. and is
   the origin of the BGP advertisement of the EID-to-RLOC mapping which
   applies to for that EID).  Map Resolvers (MRs; see [LISP-MS]) and, in
   some cases, EID-prefix.  An Ingress
   Tunnel Routers (ITRs) use Router (ITR) uses this overlay to send
   mapping requests (using a LISP Map-Request (see
   [LISP]) to the Egress Tunnel Routers (ETRs) Router (ETR) that hold holds the EID-to-RLOC mappings
   mapping for a particular EID-prefix matching EID-prefix.  In most cases, an ITR does not
   connect directly to the overlay network but instead sends Map-
   Requests via a Map-Resolver (MR; see [LISP-MS]) which does.
   Likewise, in most cases, an ETR does not connect directly to the
   overlay network but instead registers its EID-prefixes with a Map-
   Server that advertises those EID-prefixes on to the ALT and forwards
   Map-Requests for them to the ETR.

   It is important to note that the ALT does not distribute actual EID-
   to-RLOC mappings.  What it does provide is a forwarding path from an
   ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which
   holds that mapping.  The ITR/MR uses this path to send an ALT
   Datagram (see Section 3) to an ETR which then responds with a Map-
   Reply containing the needed mapping information.

   One design goal for LISP+ALT is to use existing technology wherever
   possible.  To this end, the ALT is intended to be built using off-
   the-shelf routers which already implement the required protocols (BGP
   and GRE); little, if any, LISP-specific modifications should be
   needed for such devices to be deployed on the ALT.  Note, though,
   that organizational and operational considerations suggest that ALT
   Routers be both logically and physically separate from the "native"
   Internet packet transport system; deploying this overlay on those
   routers which are already participating in the global routing system
   and actively forwarding Internet traffic is not recommended.

   The remainder of this document is organized as follows: Section 2
   provides the definitions of terms used in this document.  Section 3
   outlines the basic LISP 1.5 model.  Section 4 provides a basic
   overview of the LISP Alternate Topology architecture, and Section 5
   describes how the ALT uses BGP to propagate Endpoint Identifier
   reachability over the overlay network and Section 6 describes other
   considerations for using BGP on the ALT.  Section 7 describes the
   construction of the ALT aggregation hierarchy, and Section 8
   discusses how LISP+ALT elements are connected to form the overlay
   network.

2.  Definition of Terms

   LISP+ALT operates on two name spaces and introduces a new network
   element, the LISP+ALT Router (see below).  This section provides
   high-level definitions of the LISP+ALT name spaces, network elements,
   and message types.

    Alternative Logical Topology (ALT):  The virtual overlay network
      made up of tunnels between LISP+ALT Routers.  The Border Gateway
      Protocol (BGP) runs between ALT Routers and is used to carry
      reachability information for EID-prefixes.  The ALT provides a way
      to forward Map-Requests (and, if supported, Data Probes) toward
      the ETR that "owns" an EID-prefix.  As a tunneled overlay, its
      performance is expected to be quite limited so use of it to
      forward high-bandwidth flows of Data Probes is strongly
      discouraged (see Section 3.3 for additional discussion).

    Legacy Internet:  The portion of the Internet which does not run
      LISP and does not participate in LISP+ALT.

    ALT Router:  The devices which run on the ALT.  The ALT is a static
      network built using tunnels between ALT Routers.  These routers
      are deployed in a roughly-hierarchical mesh in which routers at
      each level in the topology are responsible for aggregating EID-
      prefixes learned from those logically "below" them and advertising
      summary prefixes to those logically "above" them.  Prefix learning
      and propagation between ALT Routers is done using BGP.  An ALT
      Router at the lowest level, or "edge" of the ALT, learns EID-
      prefixes from its "client" ETRs.  See Section 3.1 for a
      description of how EID-prefixes are learned at the "edge" of the
      ALT.  See also Section 6 for details on how BGP is configured
      between the different network elements.  When an ALT Router
      receives an ALT Datagram, it looks up the destination EID in its
      forwarding table (composed of EID prefix routes it learned from
      neighboring ALT Routers) and forwards it to the logical next-hop
      on the overlay network.

    Endpoint ID (EID):  A 32-bit (for IPv4) or 128-bit (for ipv6) value
      used to identify the ultimate source or destination for a LISP-
      encapsulated packet.  See [LISP] for details.

    EID-prefix:  A set of EIDs delegated in a power-of-two block.  EID-
      prefixes are routed on the ALT (not on the global Internet) and
      are expected to be assigned in a hierarchical manner such that
      they can be aggregated by ALT Routers.  Such a block is
      characterized by a prefix and a length.  Note that while the ALT
      routing system considers an EID-prefix to be an opaque block of
      EIDs, an end site may put site-local, topologically-relevant
      structure (subnetting) into an EID-prefix for intra-site routing.

    Aggregated EID-prefixes:  A set of individual EID-prefixes that have
      been aggregated in the [RFC4632] sense.

    Map Server (MS):   An edge ALT Router that provides a registration
      function for non-ALT-connected ETRs, originates EID-prefixes into
      the ALT on behalf of those ETRs, and forwards Map-Requests to
      them.  See [LISP-MS] for details.

    Map Resolver (MR):   An edge ALT Router that accepts an Encapsulated
      Map-Request from a non-ALT-connected ITR, decapsulates it, and
      forwards it on to the ALT toward the ETR which owns the requested
      EID-prefix.  See [LISP-MS] for details.

    Ingress Tunnel Router (ITR):   A router which sends LISP Map-
      Requests or encapsulates IP datagrams with LISP headers, as
      defined in [LISP].  In this document, the term refers to any
      device implementing ITR functionality, including a Proxy-ITR (see
      [LISP-IW]).  Under some circumstances, a LISP Map Resolver may
      also originate Map-Requests (see [LISP-MS]).

    Egress Tunnel Router (ETR):   A router which sends LISP Map-Replies
      in response to LISP Map-Requests and decapsulates LISP-
      encapsulated IP datagrams for delivery to end systems, as defined
      in [LISP].  In this document, the term refers to any device
      implementing ETR functionality, including a Proxy-ETR (see
      [LISP-IW]).  Under some circumstances, a LISP Map Server may also
      respond to Map-Requests (see [LISP-MS]).

    Routing Locator (RLOC):  A routable IP address for a LISP tunnel
      router (ITR or ETR).  Interchangeably referred to as a "locator"
      in this document.  An RLOC is also the output of an EID-to-RLOC
      mapping lookup; an EID-prefix maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically-aggregatable
      blocks that are assigned to a site at each point where it attaches
      to the global Internet; where the topology is defined by the
      connectivity of provider networks, RLOCs can be thought of as
      Provider Aggregatable (PA) addresses.  Routing for RLOCs is not
      carried on the ALT.

    EID-to-RLOC Mapping:  A binding between an EID-prefix and the set of
      RLOCs that can be used to reach it; sometimes referred to simply
      as a "mapping".

    EID-prefix Reachability:  An EID-prefix is said to be "reachable" if
      at least one of its locators is reachable.  That is, an EID-prefix
      is reachable if the ETR that is authoritative for a given EID-to-
      RLOC mapping is reachable.

    Default Mapping:  A Default Mapping is a mapping entry for EID-
      prefix 0.0.0.0/0 (0::/0 for ipv6).  It maps to a locator-set used
      for all EIDs in the Internet.  If there is a more specific EID-
      prefix in the mapping cache it overrides the Default Mapping
      entry.  The Default Mapping can be learned by configuration or
      from a Map-Reply message.

    ALT Default Route:  An EID-prefix value of 0.0.0.0/0 (or 0::/0 for
      ipv6) which may be learned from the ALT or statically configured
      on an edge ALT Router.  The ALT-Default Route defines a forwarding
      path for a packet to be sent into the ALT on a router which does
      not have a full ALT forwarding database.

3.  The LISP+ALT model

   The LISP+ALT model uses the same basic query/response protocol that
   is documented in [LISP].  In particular, LISP+ALT provides two types
   of packet that an ITR can originate to obtain EID-to-RLOC mappings:

   Map-Request:  A Map-Request message is sent into the ALT to request
      an EID-to-RLOC mapping.  The ETR which owns the mapping will
      respond to the ITR with a Map-Reply message.  Since the ALT only
      forwards on EID destinations, the destination address of the Map-
      Request sent on the ALT must be an EID.  See [LISP] for the format
      of Map-Request and Map-Reply packets.

   Data Probe:  Alternatively, an ITR may encapsulate and send the first
      data packet destined for an EID with no known RLOCs into the ALT
      as a Data Probe.  This might be done minimize packet loss and to
      probe for the mapping.  As above, the authoritative ETR for the
      EID-prefix will respond to the ITR with a Map-Reply message when
      it receives the data packet over the ALT.  As a side-effect, the
      encapsulated data packet is delivered to the end-system at the ETR
      site.  Note that the Data Probe's inner IP destination address,
      which is an EID, is copied to the outer IP destination address so
      that the resulting packet can be routed over the ALT.  See
      Section 3.3 for caveats on the usability of Data Probes.

   The term "ALT Datagram" is short-hand for a Map-Request or Data Probe
   to be sent into or forwarded on the ALT.  Note that while the outer
   header Source Address of an ALT Datagram is currently expected to be
   an RLOC, there may be situations (e.g. for experimentation with
   caching in intermediate ALT nodes) where an EID would be used to
   force a Map-Reply to be routed back through the ALT.

3.1.  Routeability of EIDs

   A LISP EID has the same syntax as IP address and can be used,
   unaltered, as the source or destination of an IP datagram.  In
   general, though, EIDs are not routable on the public Internet; LISP+
   ALT provides a separate, virtual network, known as the LISP
   Alternative Logical Topology (ALT) on which a datagram using an EID
   as an IP destination address may be transmitted.  This network is
   built as an overlay on the public Internet using tunnels to
   interconnect ALT Routers.  BGP runs over these tunnels to propagate
   path information needed to forward ALT Datagrams.  Importantly, while
   the ETRs are the source(s) of the unaggregated EID-prefixes, LISP+ALT
   uses existing BGP mechanisms to aggregate this information.

3.1.1.  Mechanisms for an ETR to originate EID-prefixes

   There are three ways that an ETR may originate its mappings into the
   ALT:

   1.  By registration with a Map Server as documented in [LISP-MS].
       This is the common case and is expected to be used by the
       majority of ETRs.

   2.  Using a "static route" on the ALT.  Where no Map-Server is
       available, an edge ALT Router may be configured with a "static
       EID-prefix route" pointing to an ETR.

   3.  Edge connection to the ALT.  If a site requires fine- grained
       control over how its EID-prefixes are advertised into the ALT, it
       may configure its ETR(s) with tunnel and BGP connections to edge
       ALT Routers.

3.1.2.  Mechanisms for an ITR to forward to EID-prefixes

   There are three ways that an ITR may send ALT Datagrams:

   1.  Through a Map Resolver as documented in [LISP-MS].  This is the
       common case and is expected to be used by the majority of ITRs.

   2.  Using a "default route".  Where a Map Resolver is not available,
       an ITR may be configured with a static ALT Default Route pointing
       to an edge ALT Router.

   3.  Edge connection to the ALT.  If a site requires fine-grained
       knowledge of what prefixes exist on the ALT, it may configure its
       ITR(s) with tunnel and BGP connections to edge ALT Routers.

3.1.3.  Map Server Model preferred

   The ALT-connected ITR and ETR cases are expected to be rare, as the
   Map Server/Map Resolver model is both simpler for an ITR/ETR operator
   to use, and provides a more general service interface to not only the
   ALT, but also to other mapping databases that may be developed in the
   future.

3.2.  Connectivity to non-LISP sites

   As stated above, EIDs used as IP addresses by LISP sites are not
   routable on the public Internet.  This implies that, absent a
   mechanism for communication between LISP and non-LISP sites,
   connectivity between them is not possible.  To resolve this problem,
   an "interworking" technology has been defined; see [LISP-IW] for
   details.

3.3.  Caveats on the use of Data Probes

   It is worth noting that there has been a great deal of discussion and
   controversy about whether Data Probes are a good idea.  On the one
   hand, using them offers a method of avoiding the "first packet drop"
   problem when an ITR does not have a mapping for a particular EID-
   prefix.  On the other hand, forwarding data packets on the ALT would
   require that it either be engineered to support relatively high
   traffic rates, which is not generally feasible for a tunneled
   network, or that it be carefully designed to aggressively rate-limit
   traffic to avoid congestion or DoS attacks.  There may also be issues
   caused by different latency or other performance characteristics
   between the ALT path taken by an initial Data Probe and the
   "Internet" path taken by subsequent packets on the same flow once a
   mapping is in place on an ITR.  For these reasons, the use of Data
   Probes is not recommended at this time; they should only be
   originated an ITR when explicitly configured to do so and such
   configuration should only be enabled when performing experiments
   intended to test the viability of using Data Probes.

4.  LISP+ALT: Overview

   LISP+ALT is a hybrid push/pull architecture.  Aggregated EID-prefixes
   are advertised among the ALT Routers and to those (rare) ITRs that
   are directly connected via a tunnel and BGP to the ALT.  Specific
   EID-to-RLOC mappings are requested by an ITR (and returned by an ETR)
   using LISP when it sends a request either via a Map Resolver or to an
   edge ALT Router.

   The basic idea embodied in LISP+ALT is to use BGP, running on a
   tunneled overlay network (the ALT), to establish reachability between
   ALT Routers.  The ALT BGP Route Information Base (RIB) is comprised
   of EID-prefixes and associated next hops.  ALT Routers interconnect
   using BGP and propagate EID-prefix updates among themselves.  EID-
   prefix information is learned from ETRs at the "edge" of the ALT
   either through the use of the Map Server interface (the commmon
   case), static configuration, or by BGP-speaking ETRs.

   An ITR uses the ALT to learn the best path for forwarding an ALT
   Datagram destined to a particular EID-prefix.  An ITR will normally
   use a Map Resolver to send its ALT Datagrams on to the ALT but may,
   in unusual circumstances, use a static ALT Default Route or connect
   to the ALT using BGP.

   Note that while this document specifies the use of Generic Routing
   Encapsulation (GRE) as a tunneling mechanism, there is no reason that
   parts of the ALT cannot be built using other tunneling technologies,
   particularly in cases where GRE does not meet security, management,
   or other operational requirements.  References to "GRE tunnel" in
   later sections of this document should therefore not be taken as
   prohibiting or precluding the use of other tunneling mechanisms.
   Note also that two ALT Routers that are directly adjacent (with no
   layer-3 router hops between them) need not use a tunnel between them;
   in this case, BGP may be configured across the interfaces that
   connect to their common subnet and that subnet is then considered to
   be part of the ALT topology.  Use of techniques such as "eBGP
   multihop" to connect ALT Routers that do not share a tunnel or common
   subnet is not recommended as the non-ALT Routers in between the ALT
   Routers in such a configuration may not have information necessary to
   forward ALT Datagrams destined to EID-prefixes exchanged across that
   BGP session.

   In summary, LISP+ALT uses BGP to build paths through ALT Routers so
   that an ALT Datagram sent into the ALT can be forwarded to the ETR
   that holds the EID-to-RLOC mapping for that EID-prefix.  This
   reachability is carried as IPv4 or ipv6 NLRI without modification
   (since an EID-prefix has the same syntax as IPv4 or ipv6 address
   prefix).  ALT Routers establish BGP sessions with one another,
   forming the ALT.  An ALT Router at the "edge" of the topology learns
   EID-prefixes originated by authoritative ETRs.  Learning may be
   though the Map Server interface, by static configuration, or via BGP
   with the ETRs.  An ALT Router may also be configured to aggregate
   EID-prefixes received from ETRs or from other LISP+ALT routers that
   are topologically "downstream" from it.

4.1.  ITR traffic handling

   When an ITR receives a packet originated by an end system within its
   site (i.e. a host for which the ITR is the exit path out of the site)
   and the destination EID for that packet is not known in the ITR's
   mapping cache, the ITR creates either a Map-Request for the
   destination EID or the original packet encapsulated as a Data Probe
   (see Section 3.3 for caveats on the usability of Data Probes).  The
   result, known as an ALT Datagram, is then sent to an ALT Router (see
   also [LISP-MS] for non-ALT-connected ITRs, noting that Data Probes
   cannot be sent to a Map-Resolver).  This "first hop" ALT Router uses
   EID-prefix routing information learned from other ALT Routers via BGP
   to guide the packet to the ETR which "owns" the prefix.  Upon receipt
   by the ETR, normal LISP processing occurs: the ETR responds to the
   ITR with a LISP Map-Reply that lists the RLOCs (and, thus, the ETRs
   to use) for the EID-prefix.  For Data Probes, the ETR also
   decapsulates the packet and transmits it toward its destination.

   Upon receipt of the Map-Reply, the ITR installs the RLOC information
   for a given prefix into a local mapping database.  With these mapping
   entries stored, additional packets destined to the given EID-prefix
   are routed directly to an RLOC without use of the ALT, until either
   the entry's TTL has expired, or the ITR can otherwise find no
   reachable ETR.  Note that a current mapping may exist that contains
   no reachable RLOCs; this is known as a Negative Cache Entry and it
   indicates that packets destined to the EID-prefix are to be dropped.

   Full details on Map-Request/Map-Reply processing may be found in
   [LISP].

   Traffic routed on to the ALT consists solely of ALT Datagrams, i.e.
   Map-Requests and Data Probes (if supported).  Given the relatively
   low performance expected of a tuneled topology, ALT Routers (and Map
   Resolvers) should aggressively rate-limit the ingress of ALT
   Datagrams from ITRs and, if possible, should be configured to not
   accept packets that are not ALT Datagrams.

4.2.  EID Assignment - Hierarchy and Topology

   EID-prefixes are expected to be allocated to a LISP site by Internet
   Registries.  Where a site has multiple allocations which are aligned
   on a power-of-2 block boundary, they should be aggregated into a
   single EID-prefix for advertisement.  The ALT network is built in a
   roughly hierarchical, partial mesh which is intended to allow
   aggregation where clearly-defined hierarchical boundaries exist.
   Building such a structure should minimize the number of EID-prefixes
   carried by LISP+ALT nodes near the top of the hierarchy.

   Routes on the ALT do not need to respond to changes in policy,
   subscription, or underlying physical connectivity, so the topology
   can remain relatively static and aggregation can be sustained.
   Because routing on the ALT uses BGP, the same rules apply for
   generating aggregates; in particular, a ALT Router should only be
   configured to generate an aggregate if it is configured with BGP
   sessions to all of the originators of components (more-specific
   prefixes) of that aggregate.  Not all of the components of need to be
   present for the aggregate to be originated (some may be holes in the
   covering prefix and some may be down) but the aggregating router must
   be configured to learn the state of all of the components.

   Under what circumstances the ALT Router actually generates the
   aggregate is a matter of local policy: in some cases, it will be
   statically configured to do so at all times with a "static discard"
   route.  In other cases, it may be configured to only generate the
   aggregate prefix if at least one of the components of the aggregate
   is learned via BGP.

   An ALT Router must not generate an aggregate that includes a non-
   LISP-speaking hole unless it can be configured to return a Negative
   Map-Reply with action="Natively-Forward" (see [LISP]) if it receives
   an ALT Datagram that matches that hole.  If it receives an ALT
   Datagram that matches a LISP-speaking hole that is currently not
   reachable, it should return a Negative Map-Reply with action="drop".
   Negative Map-Replies should be returned with a short TTL, as
   specified in [LISP-MS].  Note that an off-the-shelf, non-LISP-
   speaking router configured as an aggregating ALT Router cannot send
   Negative Map-Replies, so such a router must never originate an
   aggregate that includes a non-LISP-speaking hole.

   This implies that two ALT Routers that share an overlapping set of
   prefixes must exchange those prefixes if either is to generate and
   export a covering aggregate for those prefixes.  It also implies that
   an ETR which connects to the ALT using BGP must maintain BGP sessions
   with all of the ALT Routers that are configured to originate an
   aggregate which covers that prefix and that each of those ALT Routers
   must be explicitly configured to know the set of EID-prefixes that
   make up any aggregate that it originates.  See also [LISP-MS] for an
   example of other ways that prefix origin consistency and aggregation
   can be maintained.

   As an example, consider ETRs that are originating EID-prefixes for
   10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and 10.1.192.0/24.  An ALT
   Router should only be configured to generate an aggregate for
   10.1.0.0/16 if it has BGP sessions configured with all of these ETRs,
   in other words, only if it has sufficient knowledge about the state
   of those prefixes to summarize them.  If the Router originating
   10.1.0.0/16 receives an ALT Datagram destined for 10.1.77.88, a non-
   LISP destination covered by the aggregate, it returns a Negative Map-
   Reply with action "Natively-Forward".  If it receives an ALT Datagram
   destined for 10.1.128.199 but the configured LISP prefix
   10.1.128.0/24 is unreachable, it returns a Negative Map-Reply with
   action "drop".

   Note: much is currently uncertain about the best way to build the ALT
   network; as testing and prototype deployment proceeds, a guide to how
   to best build the ALT network will be developed.

4.3.  Use of GRE and BGP between LISP+ALT Routers

   The ALT network is built using GRE tunnels between ALT Routers.  BGP
   sessions are configured over those tunnels, with each ALT Router
   acting as a separate AS "hop" in a Path Vector for BGP.  For the
   purposes of LISP+ALT, the AS-path is used solely as a shortest-path
   determination and loop-avoidance mechanism.  Because all next-hops
   are on tunnel interfaces, no IGP is required to resolve those next-
   hops to exit interfaces.

   LISP+ALT's use of GRE and BGP facilities deployment and operation of
   LISP because no new protocols need to be defined, implemented, or
   used on the overlay topology; existing BGP/GRE tools and operational
   expertise are also re-used.  Tunnel address assignment is also easy:
   since the addresses on an ALT tunnel are only used by the pair of
   routers connected to the tunnel, the only requirement of the IP
   addresses used to establish that tunnel is that the attached routers
   be reachable by each other; any addressing plan, including private
   addressing, can therefore be used for ALT tunnels.

5.  EID-prefix Propagation and Map-Request Forwarding

   As described in Section 8.2, an ITR sends an ALT Datagram to a given
   EID-to-RLOC mapping.  The ALT provides the infrastructure that allows
   these requests to reach the authoritative ETR.

   Note that under normal circumstances Map-Replies are not sent over
   the ALT - ALT; an ETR sends a Map-Reply to one of the source RLOC ITR RLOCs learned
   from the original Map-Request.  There may be scenarios, perhaps to
   encourage caching of EID-to-RLOC mappings by ALT Routers, where Map-
   Replies could be sent over the ALT or where a "first-hop" ALT router
   might modify the originating RLOC on a Map-Request received from an
   ITR to force the Map-Reply to be returned to the "first-hop" ALT
   Router.  These cases will not be supported by initial LISP+ALT
   implementations but may be subject to future experimentation.

   ALT Routers propagate path information via BGP ([RFC4271]) that is
   used by ITRs to send ALT Datagrams toward the appropriate ETR for
   each EID-prefix.  BGP is run on the inter-ALT Router links, and
   possibly between an edge ("last hop") ALT Router and an ETR or
   between an edge ("first hop") ALT Router and an ITR.  The ALT BGP RIB
   consists of aggregated EID-prefixes and their next hops toward the
   authoritative ETR for that EID-prefix.

5.1.  Changes to ITR behavior with LISP+ALT

   As previously described, an ITR will usually use the Map Resolver
   interface and will send its Map Requests to a Map Resolver.  When an
   ITR instead connects via tunnels and BGP to the ALT, it sends ALT
   Datagrams to one of its "upstream" ALT Routers; these are sent only
   to obtain new EID-to-RLOC mappings - RLOC probe and cache TTL refresh
   Map-Requests are not sent on the ALT.  As in basic LISP, it should
   use one of its RLOCs as the source address of these queries; it
   should not use a tunnel interface as the source address as doing so
   will cause replies to be forwarded over the tunneled topology and may
   be problematic if the tunnel interface address is not routed
   throughout the ALT.  If the ITR is running BGP with the LISP+ALT
   router(s), it selects the appropriate ALT Router based on the BGP
   information received.  If it is not running BGP, it uses a
   statically-configued ALT Default Route to select an ALT Router.

5.2.  Changes to ETR behavior with LISP+ALT

   As previously described, an ETR will usually use the Map Server
   interface (see [LISP-MS]) and will register its EID-prefixes with its
   configured Map Servers.  When an ETR instead connects using BGP to
   one or more ALT Routers, it announces its EID-prefix(es) to those ALT
   Routers.  Note that

   As documented in [LISP], when an ETR generates a Map-Reply message to
   return to a querying ITR, it sends it sets the outer header IP destination
   address to one of the requesting ITR's source-RLOC (i.e., RLOCs so that the Map-Reply
   will be sent on the underlying Internet topology, not on the ALT;
   this avoids any latency penalty (or "stretch") that might be incurred
   by routing over sending the ALT). Map-Reply via the ALT, reduces load on the ALT, and
   ensures that the Map-Reply can be routed even if the original ITR
   does not have an ALT-routed EID.  For details on how an ETR selects
   which ITR RLOC to use, see section 6.1.5 of [LISP].

6.  BGP configuration and protocol considerations

6.1.  Autonomous System Numbers (ASNs) in LISP+ALT

   The primary use of BGP today is to define the global Internet routing
   topology in terms of its participants, known as Autonomous Systems.
   LISP+ALT specifies the use of BGP to create a global overlay network
   (the ALT) for finding EID-to-RLOC mappings.  While related to the
   global routing database, the ALT serves a very different purpose and
   is organized into a very different hierarchy.  Because LISP+ALT does
   use BGP, however, it uses ASNs in the paths that are propagated among
   ALT Routers.  To avoid confusion, it needs to be stressed that that
   these LISP+ALT ASNs use a new numbering space that is unrelated to
   the ASNs used by the global routing system.  Exactly how this new
   space will be assigned and managed will be determined during the
   deployment of LISP+ALT.

   Note that the ALT Routers that make up the "core" of the ALT will not
   be associated with any existing core-Internet ASN because the ALT
   topology is completely separate from, and independent of, the global
   Internet routing system.

6.2.  Sub-Address Family Identifier (SAFI) for LISP+ALT

   As defined by this document, LISP+ALT may be implemented using BGP
   without modification.  Given the fundamental operational difference
   between propagating global Internet routing information (the current
   dominant use of BGP) and creating an overlay network for finding EID-
   to-RLOC mappings (the use of BGP proposed by this document), it may
   be desirable to assign a new SAFI [RFC4760] to prevent operational
   confusion and difficulties, including the inadvertent leaking of
   information from one domain to the other.  Use of a separate SAFI
   would make it easier to debug many operational problems but would
   come at a significant cost: unmodified, off-the-shelf routers which
   do not understand the new SAFI could not be used to build any part of
   the ALT network.  At present, this document does not request the
   assignment of a new SAFI; additional experimentation may suggest the
   need for one in the future.

7.  EID-prefix Aggregation

   The ALT BGP peering topology should be arranged in a tree-like
   fashion (with some meshiness), with redundancy to deal with node and
   link failures.  A basic assumption is that as long as the routers are
   up and running, the underlying Internet will provide alternative
   routes to maintain BGP connectivity among ALT Routers.

   Note that, as mentioned in Section 4.2, the use of BGP by LISP+ALT
   requires that information only be aggregated where all active more-
   specific prefixes of a generated aggregate prefix are known.  This is
   no different than the way that BGP route aggregation works in the
   existing global routing system: a service provider only generates an
   aggregate route if it is configured to learn to all prefixes that
   make up that aggregate.

7.1.  Stability of the ALT

   It is worth noting that LISP+ALT does not directly propagate EID-to-
   RLOC mappings.  What it does is provide a mechanism for an ITR to
   commonicate with the ETR that holds the mapping for a particular EID-
   prefix.  This distinction is important when considering the stability
   of BGP on the ALT network as compared to the global routing system.
   It also has implications for how site-specific EID-prefix information
   may be used by LISP but not propagated by LISP+ALT (see Section 7.2
   below).

   RLOC prefixes are not propagated through the ALT so their
   reachability is not determined through use of LISP+ALT.  Instead,
   reachability of RLOCs is learned through the LISP ITR-ETR exchange.
   This means that link failures or other service disruptions that may
   cause the reachability of an RLOC to change are not known to the ALT.
   Changes to the presence of an EID-prefix on the ALT occur much less
   frequently: only at subscription time or in the event of a failure of
   the ALT infrastructure itself.  This means that "flapping" (frequent
   BGP updates and withdrawals due to prefix state changes) is not
   likely and mapping information cannot become "stale" due to slow
   propagation through the ALT BGP mesh.

7.2.  Traffic engineering using LISP

   Since an ITR learns an EID-to-RLOC mapping directly from the ETR that
   owns it, it is possible to perform site-to-site traffic engineering
   by setting the preference and/or weight fields, and by including
   more-specific EID-to-RLOC information in Map-Reply messages.

   This is a powerful mechanism that can conceivably replace the
   traditional practice of routing prefix deaggregation for traffic
   engineering purposes.  Rather than propagating more-specific
   information into the global routing system for local- or regional-
   optimization of traffic flows, such more-specific information can be
   exchanged, through LISP (not LISP+ALT), on an as-needed basis between
   only those ITRs/ETRs (and, thus, site pairs) that need it.  Should a
   receiving ITR decide that it does not wish to store such more-
   specific information, it has the option of discarding it as long as a
   shorter, covering EID-prefix exists.  Such an exchange of "more-
   specifics" between sites facilitates traffic engineering, by allowing
   richer and more fine-grained policies to be applied without
   advertising additional prefixes into either the ALT or the global
   routing system.

   Note that these new traffic engineering capabilities are an attribute
   of LISP and are not specific to LISP+ALT; discussion is included here
   because the BGP-based global routing system has traditionally used
   propagation of more-specific routes as a crude form of traffic
   engineering.

7.3.  Edge aggregation and dampening

   Normal BGP best common practices apply to the ALT network.  In
   particular, first-hop ALT Routers will aggregate EID prefixes and
   dampen changes to them in the face of excessive updates.  Since EID-
   prefix assignments are not expected to change as frequently as global
   routing BGP prefix reachability, such dampening should be very rare,
   and might be worthy of logging as an exceptional event.  It is again
   worth noting that the ALT carries only EID-prefixes, used to a
   construct BGP paths path to their owning ETRs; it each ETR (or Map-Server) that originates each
   prefix; the ALT does not carry reachability about RLOCs.  In
   addition, EID-prefix information may be aggregated as the topology
   and address assignment hierarchy allow.  Since the topology is all
   tunneled and can be modified as needed, reasonably good aggregation
   should be possible.  In addition, since most ETRs are expected to
   connect to the ALT using the Map Server interface, Map Servers will
   implement a natural "edge" for the ALT where dampening and
   aggregation can be applied.  For these reasons, the set of prefix
   information on the ALT can be expected to be both better aggregated
   and considerably less volatile than the actual EID-
   to-RLOC EID-to-RLOC mappings.

7.4.  EID assignment flexibility vs. ALT scaling

   There are major open questions regarding how the ALT will be deployed
   and what organization(s) will operate it.  In a simple, non-
   distributed world, centralized administration of EID prefix
   assignment and ALT network design would facilitate a well- aggregated
   ALT routing system.  Business and other realities will likely result
   in a more complex, distributed system involving multiple levels of
   prefix delegation, multiple operators of parts of the ALT
   infrastructure, and a combination of competition and cooperation
   among the participants.  In addition, re-use of existing IP address
   assignments, both "PI" and "PA", to avoid renumbering when sites
   transition to LISP will further complicate the processes of building
   and operating the ALT.

   A number of conflicting considerations need to be kept in mind when
   designing and building the ALT.  Among them are:

   1.  Target ALT routing state size and level of aggregation.  As
       described in Section 7.1, the ALT should not suffer from some of
       the performance constraints or stability issues as the Internet
       global routing system, so some reasonable level of deaggregation
       and increased number of EID prefixes beyond what might be
       considered ideal should be acceptable.  That said, measures, such
       as tunnel rehoming to preserve aggregation when sites move from
       one mapping provider to another and implementing aggregation at
       multiple levels in the hierarchy to collapse de-aggregation at
       lower levels, should be taken to reduce unnecessary explosion of
       ALT routing state.

   2.  Number of operators of parts of the ALT and how they will be
       organized (hierarchical delegation vs. shared administration).
       This will determine not only how EID prefixes are assigned but
       also how tunnels are configured and how EID prefixes can be
       aggregated between different parts of the ALT.

   3.  Number of connections between different parts of the ALT.  Trade-
       offs will need to be made among resilience, performance, and
       placement of aggregation boundaries.

   4.  EID prefix portability between competing operators of the ALT
       infrastructure.  A significant benefit for an end-site to adopt
       LISP is the availability of EID space that is not tied to a
       specific connectivity provider; it is important to ensure that an
       end site doesn't trade lock-in to a connectivity provider for
       lock-in to a provider of its EID assignment, ALT connectivity, or
       Map Server facilities.

   This is, by no means, and exhaustive list.

   While resolving these issues is beyond the scope of this document,
   the authors recommend that existing distributed resource structures,
   such as the IANA/Regional Internet Registries and the ICANN/Domain
   Registrar, be carefully considered when designing and deploying the
   ALT infrastructure.

8.  Connecting sites to the ALT network

8.1.  ETRs originating information into the ALT

   EID-prefix information is originated into the ALT by three different
   mechanisms:

   Map Server:  In most cases, a site will configure its ETR(s) to
      register with one or more Map Servers (see [LISP-MS]), and does
      not participate directly in the ALT.

   BGP:  For a site requiring complex control over their EID-prefix
      origination into the ALT, an ETR may connect to the LISP+ALT
      overlay network by running BGP to one or more ALT Router(s) over
      tunnel(s).  The ETR advertises reachability for its EID-prefixes
      over these BGP connection(s).  The edge ALT Router(s) that
      receive(s) these prefixes then propagate(s) them into the ALT.
      Here the ETR is simply an BGP peer of ALT Router(s) at the edge of
      the ALT.  Where possible, an ALT Router that receives EID-prefixes
      from an ETR via BGP should aggregate that information.

   Configuration:  One or more ALT Router(s) may be configured to
      originate an EID-prefix on behalf of the non-BGP-speaking ETR that
      is authoritative for a prefix.  As in the case above, the ETR is
      connected to ALT Router(s) using GRE tunnel(s) but rather than BGP
      being used, the ALT Router(s) are configured with what are in
      effect "static routes" for the EID-prefixes "owned" by the ETR.
      The GRE tunnel is used to route Map-Requests to the ETR.

   Note:  in all cases, an ETR may register to multiple Map Servers or
      connect to multiple ALT Routers for the following reasons:

      *  redundancy, so that a particular ETR is still reachable even if
         one path or tunnel is unavailable.

      *  to connect to different parts of the ALT hierarchy if the ETR
         "owns" multiple EID-to-RLOC mappings for EID-prefixes that
         cannot be aggregated by the same ALT Router (i.e. are not
         topologically "close" to each other in the ALT).

8.2.  ITRs Using the ALT

   In the common configuration, an ITR does not need to know anything
   about the ALT, since it sends Map-Requests to one of its configured
   Map-Resolvers (see [LISP-MS]).  There are two exceptional cases:

   Static default:  If a Map Resolver is not available but an ITR is
      adjacent to an ALT Router (either over a common subnet or through
      the use of a tunnel), it can use an ALT Default Route route to
      cause all ALT Datagrams to be sent that ALT Router.  This case is
      expected to be rare.

   Connection to ALT:  A site with complex Internet connectivity needs
      may need more fine-grained distinction between traffic to LISP-
      capable and non-LISP-capable sites.  Such a site may configure
      each of its ITRs to connect directly to the ALT, using a tunnel
      and BGP connection.  In this case, the ITR will receive EID-prefix
      routes from its BGP connection to the ALT Router and will LISP-
      encapsulate and send ALT Datagrams through the tunnel to the ALT
      Router.  Traffic to other destinations may be forwarded (without
      LISP encapsulation) to non-LISP next-hop routers that the ITR
      knows.

      In general, an ITR that connects to the ALT does so only to to ALT
      Routers at the "edge" of the ALT (typically two for redundancy).
      There may, though, be situations where an ITR would connect to
      other ALT Routers to receive additional, shorter path information
      about a portion of the ALT of interest to it.  This can be
      accomplished by establishing GRE tunnels between the ITR and the
      set of ALT Routers with the additional information.  This is a
      purely local policy issue between the ITR and the ALT Routers in
      question.

   As described in [LISP-MS], Map-Resolvers do not accept or forward
   Data Probes; in the rare scenario that an ITR does support and
   originate Data Probes, it must do so using one of the exceptional
   configurations described above.  Note that the use of Data Probes is
   discouraged at this time (see Section 3.3).

9.  IANA Considerations

   This document makes no request of the IANA.

10.  Security Considerations

   LISP+ALT shares many of the security characteristics of BGP.  Its
   security mechanisms are comprised of existing technologies in wide
   operational use today, so securing the ALT should be mostly a matter
   of applying the same technology that is used to secure the BGP-based
   global routing system (see Section 10.3 below).

10.1.  Apparent LISP+ALT Vulnerabilities

   This section briefly lists the known potential vulnerabilities of
   LISP+ALT.

   Mapping Integrity:  Can an attacker insert bogus mappings to black-
      hole (create Denial-of-Service, or DoS attack) or intercept LISP
      data-plane packets?

   ALT Router Availability:  Can an attacker DoS the ALT Routers
      connected to a given ETR?  If a site's ETR cannot advertise its
      EID-to-RLOC mappings, the site is essentially unavailable.

   ITR Mapping/Resources:  Can an attacker force an ITR or ALT Router to
      drop legitimate mapping requests by flooding it with random
      destinations for which it will generate large numbers of Map-
      Requests and fill its mapping cache?  Further study is required to
      see the impact of admission control on the overlay network.

   EID Map-Request Exploits for Reconnaissance:  Can an attacker learn
      about a LISP site's TE policy by sending legitimate mapping
      requests and then observing the RLOC mapping replies?  Is this
      information useful in attacking or subverting peer relationships?
      Note that any public LISP mapping database will have similar data-
      plane reconnaissance issue.

   Scaling of ALT Router Resources:  Paths through the ALT may be of
      lesser bandwidth than more "direct" paths; this may make them more
      prone to high-volume denial-of-service attacks.  For this reason,
      all components of the ALT (ETRs and ALT Routers) should be
      prepared to rate-limit traffic (ALT Datagrams) that could be
      received across the ALT.

   UDP Map-Reply from ETR:  Since Map-Replies are sent directly from the
      ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various
      types of DoS attacks (this is a general property of LISP, not an
      LISP+ALT vulnerability).

   More-specific prefix leakage:  Because EID-prefixes on the ALT are
      expected to be fairly well-aggregated and EID-prefixes propagated
      out to the global Internet (see [LISP-IW] much more so, accidental
      leaking or malicious advertisement of an EID-prefix into the
      global routing system could cause traffic redirection away from a
      LISP site.  This is not really a new problem, though, and its
      solution can only be achieved by much more strict prefix filtering
      and authentication on the global routing system.

10.2.  Survey of LISP+ALT Security Mechanisms

   Explicit peering:  The devices themselves can both prioritize
      incoming packets, as well as potentially do key checks in hardware
      to protect the control plane.

   Use of TCP to connect elements:  This makes it difficult for third
      parties to inject packets.

   Use of HMAC Protected BGP/TCP Connections:  HMAC is used to verify
      message integrity and authenticity, making it nearly impossible
      for third party devices to either insert or modify messages.

   Message Sequence Numbers and Nonce Values in Messages:  This allows
      an ITR to verify that the Map-Reply from an ETR is in response to
      a Map-Request originated by that ITR (this is a general property
      of LISP; LISP+ALT does not change this behavior).

10.3.  Use of new IETF standard BGP Security mechanisms

   LISP+ALT's use of BGP allows the ALT to take advantage of BGP
   security features designed for existing Internet BGP use.

   For example,  Should the
   Internet community converge on the work currently being done in the
   IETF SIDR working group or should either S-BGP [I-D.murphy-bgp-secr]
   or soBGP [I-D.white-sobgparchitecture] become widely deployed it expected that be implemented and widely-
   deployed, LISP+ALT could can readily use these mechanisms to provide
   authentication of EID-
   to-RLOC mappings, EID-prefix origination and EID origination. EID-to-RLOC mappings.

11.  Acknowledgments

   The authors would like to specially thank J. Noel Chiappa who was a
   key contributer to the design of the LISP-CONS mapping database (many
   ideas from which made their way into LISP+ALT) and who has continued
   to provide invaluable insight as the LISP effort has evolved.  Others
   who have provided valuable contributions include John Zwiebel, Hannu
   Flinck, Amit Jain, John Scudder, and Scott Brim.

12.  References

12.1.  Normative References

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

   [LISP-MS]  Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-04.txt
              draft-ietf-lisp-ms-05.txt (work in progress),
              October 2009. April 2010.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

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

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

12.2.  Informative References

   [I-D.murphy-bgp-secr]
              Murphy, S., "BGP Security Analysis",
              draft-murphy-bgp-secr-04 (work in progress),
              November 2001.

   [I-D.white-sobgparchitecture]
              White, R., "Architecture and Deployment Considerations for
              Secure Origin BGP (soBGP)",
              draft-white-sobgparchitecture-00 (work in progress),
              May 2004.

   [LISP-IW]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and ipv6",
              draft-ietf-lisp-interworking-02.txt (work in progress),
              February 2010.

Authors' Addresses

   Vince Fuller
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dino Farinacci
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Dave Meyer
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: darlewis@cisco.com



--6TrnltStXW4iwmi0--

From trac@tools.ietf.org  Mon Apr 26 09:31:39 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7BA3A6874 for ; Mon, 26 Apr 2010 09:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Level: 
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3l4BUYhc7N2 for ; Mon, 26 Apr 2010 09:31:37 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 102A83A6A17 for ; Mon, 26 Apr 2010 09:31:24 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6RDD-00067X-Lk; Mon, 26 Apr 2010 09:31:11 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 16:31:11 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/33#comment:3
Message-ID: <077.a64a68f30b2fe248aab008de648eb7bd@tools.ietf.org>
References: <068.55f561e469bb5634357c136824b60322@tools.ietf.org>
X-Trac-Ticket-ID: 33
In-Reply-To: <068.55f561e469bb5634357c136824b60322@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: Re: [lisp] #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 16:31:39 -0000

#33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  editorial                      |      Status:  new            
Priority:  trivial                        |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
Description changed by luigi@…:

Old description:

> '''This ticket groups together editorial issues raised by D.
> Papadimitriou and Y. Rekhter in their respective reviews.'''
>
> '''From D. Papadimitriou's review:'''
>
> Section 7: the first paragraph is a wish not a fact. As such it is
> doubtful what such paragraph actually brings in the context of a
> protocol architecture/specification.
>
> '''From Y. Rekhter's review:'''
> ''' This is part of Comment 35'''
>
> Section 7 Router Performance Considerations:
>
>  LISP is designed to be very hardware-based forwarding friendly. By
>  doing tunnel header prepending [RFC1955] and stripping instead of re-
>  writing addresses, existing hardware can support the forwarding model
>  with little or no modification. Where modifications are required,
>  they should be limited to re-programming existing hardware rather
>  than requiring expensive design changes to hard-coded algorithms in
>  silicon.
>
> This is simply an Assertion.
>
>  When a tunnel encapsulated packet is received by an ETR, the outer
>  destination address may not be the address of the router. This makes
>  it challenging for the control plane to get packets from the
>  hardware. This may be mitigated by creating special FIB entries for
>  the EID-prefixes of EIDs served by the ETR (those for which the
>  router provides an RLOC translation). These FIB entries are marked
>  with a flag indicating that control plane processing should be
>  performed. The forwarding logic of testing for particular IP protocol
>  number value is not necessary. No changes to existing, deployed
>  hardware should be needed to support this.
>
> The above explanation of why no changes to existing deployed hardware
> should be needed is fairly confusing.
>
>  On an ITR, prepending a new IP header is as simple as adding more
>  bytes to a MAC rewrite string and prepending the string as part of
>  the outgoing encapsulation procedure. Many routers that support GRE
>  tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already support
>  this action.
>
> This looks like another Assertion.
>
>  When a received packet's outer destination address contains an EID
>  which is not intended to be forwarded on the routable topology
>  (i.e. LISP 1.5), the source address of a data packet or the router
>  interface with which the source is associated (the interface from
>  which it was received) can be associated with a VRF (Virtual
>  Routing/Forwarding), in which a different (i.e. non-congruent)
>  topology can be used to find EID-to-RLOC mappings.
>
> What does the part about "When a received packet's ... to be forwarded
> on the routable topology" have to do with the part about "the source
> address of a data packet ... can be associated with a VRF" ?

New description:

 '''This ticket groups together editorial issues raised by D. Papadimitriou
 and Y. Rekhter in their respective reviews.'''

 '''From D. Papadimitriou's review:'''

 Section 7: the first paragraph is a wish not a fact. As such it is
 doubtful what such paragraph actually brings in the context of a
 protocol architecture/specification.

--

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Mon Apr 26 09:32:50 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D5A3A6936 for ; Mon, 26 Apr 2010 09:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Level: 
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmiRz7f0knYK for ; Mon, 26 Apr 2010 09:32:49 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6E2F83A6837 for ; Mon, 26 Apr 2010 09:32:49 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6REc-0006BH-11; Mon, 26 Apr 2010 09:32:38 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 16:32:37 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/80
Message-ID: <068.16cc2f76eb8757537cf620ea51234a22@tools.ietf.org>
X-Trac-Ticket-ID: 80
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #80: Router Performances
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 16:32:50 -0000

#80: Router Performances
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  technical                      |      Status:  new            
Priority:  major                          |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
 '''From Y. Rekhter's review'''
 '''This is comment 35'''

 Section 7 Router Performance Considerations:

  LISP is designed to be very hardware-based forwarding friendly. By
  doing tunnel header prepending [RFC1955] and stripping instead of re-
  writing addresses, existing hardware can support the forwarding model
  with little or no modification. Where modifications are required,
  they should be limited to re-programming existing hardware rather
  than requiring expensive design changes to hard-coded algorithms in
  silicon.

 This is simply an Assertion.

  When a tunnel encapsulated packet is received by an ETR, the outer
  destination address may not be the address of the router. This makes
  it challenging for the control plane to get packets from the
  hardware. This may be mitigated by creating special FIB entries for
  the EID-prefixes of EIDs served by the ETR (those for which the
  router provides an RLOC translation). These FIB entries are marked
  with a flag indicating that control plane processing should be
  performed. The forwarding logic of testing for particular IP protocol
  number value is not necessary. No changes to existing, deployed
  hardware should be needed to support this.

 The above explanation of why no changes to existing deployed hardware
 should be needed is fairly confusing.

  On an ITR, prepending a new IP header is as simple as adding more
  bytes to a MAC rewrite string and prepending the string as part of
  the outgoing encapsulation procedure. Many routers that support GRE
  tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already support
  this action.

 This looks like another Assertion.

  When a received packet's outer destination address contains an EID
  which is not intended to be forwarded on the routable topology
  (i.e. LISP 1.5), the source address of a data packet or the router
  interface with which the source is associated (the interface from
  which it was received) can be associated with a VRF (Virtual
  Routing/Forwarding), in which a different (i.e. non-congruent)
  topology can be used to find EID-to-RLOC mappings.

 What does the part about "When a received packet's ... to be forwarded
 on the routable topology" have to do with the part about "the source
 address of a data packet ... can be associated with a VRF" ?

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Mon Apr 26 09:38:16 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46173A67D7 for ; Mon, 26 Apr 2010 09:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.599
X-Spam-Level: 
X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kF69T6PuBbu for ; Mon, 26 Apr 2010 09:38:16 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F1A613A67C0 for ; Mon, 26 Apr 2010 09:38:15 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6RJs-0006MZ-IK; Mon, 26 Apr 2010 09:38:04 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 16:38:04 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/59#comment:2
Message-ID: <077.a8c9e9edf9289c9642890f829ad10cd1@tools.ietf.org>
References: <068.8be36db734249d6330520777c0081326@tools.ietf.org>
X-Trac-Ticket-ID: 59
In-Reply-To: <068.8be36db734249d6330520777c0081326@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: Re: [lisp] #59: Editorial Issues Section 10 of draft-ietf-lisp-06.txt (from Y. Rekhter's review)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 16:38:17 -0000

#59: Editorial Issues Section 10 of draft-ietf-lisp-06.txt (from Y. Rekhter's
review)
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  editorial                      |      Status:  new            
Priority:  trivial                        |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
Description changed by luigi@…:

Old description:

> '''This is Comment 42'''
>
> Section 10.3
>
> visited network using its original EID, then LISP will need to perform a
> route-returnability check on the new EID-RLOC mapping for that EID.
> What is a "route-returnability check"?
>
> loss for the entire system. Heuristics can be added to LISP to reduce the
> number of mapping changes required and to reduce the delay
> This sounds like an assertion.

New description:

 '''This is Comment 42'''

 Section 10.3

  visited network using its original EID, then LISP will need to perform a
 route-
  returnability check on the new EID-RLOC mapping for that EID.

 What is a "route-returnability check"?

  loss for the entire system. Heuristics can be added to LISP to reduce the
 number of
  mapping changes required and to reduce the delay

 This sounds like an assertion.

  per mapping change. Also IP mobility can be modified to require fewer
 mapping
  changes. In order to increase overall system performance, there may be a
 need to
  reduce the optimization of one area in order to place fewer demands on
 another.

 This would appear to be a tacit admission that LISP has a problem with IP
 mobility (and would therefore like IP mobility to go away). More of the
 same a few paragraphs down:

  Mobile IP packet exchange is designed for an environment in which all
 routing
  information is disseminated before packets can be forwarded. In order to
 allow the
  Internet to grow to support expected future use, we are moving to an
 environment
  where some information may have to be obtained after packets are in
 flight.
  Modifications to IP mobility should be considered in order to optimize
 the
  behavior of the overall system. Anything which decreases the number of
 new
  EID- RLOC mappings needed when a node moves, or maintains the validity of
 an
  EID- RLOC mapping for a longer time, is useful.

--

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Mon Apr 26 12:25:15 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8999C3A6AAF for ; Mon, 26 Apr 2010 12:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.525
X-Spam-Level: 
X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzcP5QNWwqhl for ; Mon, 26 Apr 2010 12:25:14 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D93A13A6A9E for ; Mon, 26 Apr 2010 12:25:13 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6TvS-0008In-6R; Mon, 26 Apr 2010 12:25:02 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: luigi@net.t-labs.tu-berlin.de
X-Trac-Project: lisp
Date: Mon, 26 Apr 2010 19:25:01 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/81
Message-ID: <068.7e4dbe7fbceb8d072eed8b21192d652d@tools.ietf.org>
X-Trac-Ticket-ID: 81
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #81: Implication of deploying  of xTRs as first/last hop.
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 19:25:15 -0000

#81: Implication of deploying  of xTRs as first/last hop.
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  technical                      |      Status:  new            
Priority:  trivial                        |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
 '''From Y. Rekhter's review'''

 Comment 37:

 Section 8.1
 If ITR/ETR are first/last hop routers, then these routers need to be
 routable within each site RLOC. This means that if a site changes
 providers, the RLOC of these routers would need to change. Therefore, any
 ACLs within each site would need to be modified to allow routing on these
 RLOCs.

 '''In order to clarify the raised issue, the comment has been refined
 as:'''

 Section 8.1 needs to document implications of changing providers
 (changing RLOCs) on configuration/provisioning of devices within
 a site. E.g., this section needs to document that if devices within
 a site use ACLs, then changing providers may require changing
 configuration on these devices.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 21:41:15 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7518C3A6AEB for ; Tue, 27 Apr 2010 21:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.781
X-Spam-Level: 
X-Spam-Status: No, score=-101.781 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_05=-1.11, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ6w2plt+1KQ for ; Tue, 27 Apr 2010 21:41:14 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 219B33A6876 for ; Tue, 27 Apr 2010 21:41:14 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6z52-0001gL-S0; Tue, 27 Apr 2010 21:41:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 04:41:00 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/82
Message-ID: <057.4cd8d8e5f55131ea251196d9debcb9ee@tools.ietf.org>
X-Trac-Ticket-ID: 82
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #82: Wording in Abstract (comment 8 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 04:41:16 -0000

#82: Wording in Abstract (comment 8 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  editorial           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 The first sentence says LISP is "simple". Yet such components of LISP as
 the additional aspects of MTU and fragmentation, cache management and
 reachability management add considerable complexity, not to mention the
 operational expense of learning to operate and debug an entirely new
 infrastructure.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 21:42:08 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87223A6AFD for ; Tue, 27 Apr 2010 21:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level: 
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaoKWRJEsrpL for ; Tue, 27 Apr 2010 21:42:08 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1E96A3A6AF9 for ; Tue, 27 Apr 2010 21:42:08 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6z5v-0001hM-Vu; Tue, 27 Apr 2010 21:41:56 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 04:41:55 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/83
Message-ID: <057.edbf85f3e9f5e57abf4a5a6f7a6c3e1c@tools.ietf.org>
X-Trac-Ticket-ID: 83
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #83: Wording in Abstract (comment 8 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 04:42:08 -0000

#83: Wording in Abstract (comment 8 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  editorial           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 The proposed protocol can be implemented in a relatively small number of
 routers.

 "small" relative to what?  If the Internet were to fully transition to
 LISP, the entire edge of the Internet would have to implement LISP.  This
 encompasses a large number of routers, greater than the number of core
 routers.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 21:45:32 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7A43A6B29 for ; Tue, 27 Apr 2010 21:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.224
X-Spam-Level: 
X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG7r6hmptwgi for ; Tue, 27 Apr 2010 21:45:31 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9FEEA3A6B50 for ; Tue, 27 Apr 2010 21:45:31 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6z9D-0001nZ-GD; Tue, 27 Apr 2010 21:45:19 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 04:45:19 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/84
Message-ID: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org>
X-Trac-Ticket-ID: 84
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 04:45:32 -0000

#84: Renumbering burden when clients change providers (comment 9 reported by Y.
Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:     
    Type:  technical           |      Status:  new
Priority:  major               |   Component:  alt
Severity:  -                   |    Keywords:     
-------------------------------+--------------------------------------------
 In the Introduction:

 3.  Easing of renumbering burden when clients change providers.
       Because host EIDs are numbered from a separate, non-provider-
       assigned and non-topologically-bound space, they do not need to
       be renumbered when a client site changes its attachment points to
       the network.

 At least with respect to LISP+ALT, this statement is incorrect.  Sites are
 simply locked in to their EID provider instead of being locked in to their
 ISP as they are now.  The lock-in would appear to be more severe than it
 is today, since unless strong aggregation is preserved, LISP's entire
 value proposition is lost.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 21:47:19 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431553A6B6E for ; Tue, 27 Apr 2010 21:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level: 
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YacMQJjZDYCC for ; Tue, 27 Apr 2010 21:47:18 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 126143A6B6A for ; Tue, 27 Apr 2010 21:47:14 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zAr-0003qz-OB; Tue, 27 Apr 2010 21:47:01 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 04:47:01 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/85
Message-ID: <057.a6d8a8a9431fa4a2fa4139f6f21dbdef@tools.ietf.org>
X-Trac-Ticket-ID: 85
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #85: Mobility without address changing (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 04:47:19 -0000

#85: Mobility without address changing (comment 9 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Introduction:

 5. Mobility without address changing.  Existing mobility mechanisms
      will be able to work in a locator/ID separation scenario.


 It appears from section 10, Mobility Considerations, that this claim is
 overstated or at least premature.  For evidence of this, consider that
 section 10 suggests that mobility requirements should be relaxed in order
 to accommodate LISP's other requirements.  This strongly suggests that
 mobility is not an important LISP design goal.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 21:50:47 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8066B3A6AED for ; Tue, 27 Apr 2010 21:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.223
X-Spam-Level: 
X-Spam-Status: No, score=-101.223 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2YvGv2ryeql for ; Tue, 27 Apr 2010 21:50:46 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 678FC3A6ADF for ; Tue, 27 Apr 2010 21:50:46 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zEI-0003x6-9J; Tue, 27 Apr 2010 21:50:34 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 04:50:34 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/86
Message-ID: <057.1f293e91cef920f8eee0de47c3c10e1d@tools.ietf.org>
X-Trac-Ticket-ID: 86
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #86: On the design goals and requirements (comment 10 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 04:50:47 -0000

#86: On the design goals and requirements (comment 10 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 2

 Some of the design goals of this proposal include:

 1.  Require no hardware or software changes to end-systems (hosts).

 2.  Minimize required changes to Internet infrastructure.

 3.  Be incrementally deployable.

 4.  Require no router hardware changes.

 5.  Minimize the number of routers which have to be modified.  In
      particular, most customer site routers and no core routers
      require changes.

 6.  Minimize router software changes in those routers which are
     affected.

 7.  Avoid or minimize packet loss when EID-to-RLOC mappings need to
      be performed.


 Wrt (2), (5), and (6) above, how could one determine whether this proposal
 really minimizes required changes?

 Wrt (4), if this statement means existing routers could be software
 upgraded to be LISP routers, this statement is questionable, for a number
 of reasons, covered elsewhere in this critique.  These include control
 plane bandwidth (existing routers typically have much lower "punt"
 processing bandwidth than hardware switching bandwidth) and
 the complex LISP forwarding plane, which may not be implementable in
 microcoded forwarding engines, especially those that are older (but still
 widely deployed).

 Wrt claim in (5) that "no core routers require changes", that is
 incorrect, as section 5 (p.16) states that:

   If the assumption proves true and transit networks with links
   limited to 1500 byte MTUs are corner cases, it would seem more
   cost-effective to either upgrade or modify the equipment in those
   transit networks to support larger MTUs or to use existing
   mechanisms for accommodating packets that are too large.

 Also, the notion that "no core routers require change(s)" is questionable
 unless one defines the proxies in [INTERWORK] as being non-core routers.

 Wrt (7) above, how could one determine whether this proposal really
 minimizes packet loss?  What needs to be documented is how LISP compares
 with the current routing model in terms of minimizing packet loss.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 21:54:45 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265F53A6AE3 for ; Tue, 27 Apr 2010 21:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level: 
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxqPum3tivPk for ; Tue, 27 Apr 2010 21:54:44 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B2BF23A6B56 for ; Tue, 27 Apr 2010 21:53:50 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zHG-0003zn-3u; Tue, 27 Apr 2010 21:53:38 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 04:53:38 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/87
Message-ID: <057.9d980920e9bd162c07874463eac20c57@tools.ietf.org>
X-Trac-Ticket-ID: 87
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #87: On reusing globally routed address block as EID-prefix (comment 11 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 04:54:45 -0000

#87: On reusing globally routed address block as EID-prefix (comment 11 reported
by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 3

      A globally routed address block (whether PI or PA) is not
      an EID-prefix.  However, a globally routed address block may be
      removed from global routing and reused as an EID-prefix.  A site
      that receives an explicitly allocated EID-prefix may not use that
      EID-prefix as a globally routed prefix assigned to RLOCs.


 The above implies that if an existing site has IPv4 addresses that are
 used for global connectivity, and thus act as RLOCs, the site can not use
 these addresses as EIDs, unless the site removes them from global routing,
 and thus stops using them as RLOCs.

 Does the spec assume that IPv4 sites that want to use LISP would need to
 get another block of IPv4 addresses for the EID prefix ?

 If yes, then where would these IPv4 addresses come from ?

 If a site that has IPv4 addresses and uses them for global connectivity
 (these addresses act as RLOCs) wants to transition to LISP, but can not
 get another block of IPv4 address for the EID-prefix, then how would that
 site transition to LISP, and what are the implications on that site's
 connectivity during the transition? E.g., could some,
 but not all, of the border routers of the site during the transition be
 xTRs ?  If yes, then how would an ITR attract traffic from a site if the
 site also has a default route to a non-ITR router ?

 Does the EID space need to be aggregatable, as if yes, then how would one
 accomplish this in the context of IPv4 addresses ?

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 21:55:20 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7FF3A6A0F for ; Tue, 27 Apr 2010 21:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level: 
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQE63nphthES for ; Tue, 27 Apr 2010 21:55:20 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C0ECB3A6A97 for ; Tue, 27 Apr 2010 21:55:19 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zIh-00040Y-6F; Tue, 27 Apr 2010 21:55:07 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 04:55:07 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/88
Message-ID: <057.b6beff53451d6277688de78ea26da1d9@tools.ietf.org>
X-Trac-Ticket-ID: 88
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #88: "Proxy device" description (comment 12 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 04:55:20 -0000

#88: "Proxy device" description (comment 12 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 3

      Note that this destination RLOC may be an intermediate, proxy
      device that has better knowledge of the EID-to-RLOC mapping closer
      to the destination EID.

 Is there any description of such "proxy device", and of its operation?

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 21:57:51 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4643A6AB5 for ; Tue, 27 Apr 2010 21:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level: 
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT4KvkcvH2eX for ; Tue, 27 Apr 2010 21:57:51 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 729193A6A0F for ; Tue, 27 Apr 2010 21:57:49 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zL7-000450-AN; Tue, 27 Apr 2010 21:57:37 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 04:57:37 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/89
Message-ID: <057.915c3b2990c494d4d75d76e0f1fee088@tools.ietf.org>
X-Trac-Ticket-ID: 89
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #89: On redefining the name of the encapsulated packet header (comment 12 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 04:57:51 -0000

#89: On redefining the name of the encapsulated packet header (comment 12
reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 3:

     Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
     used in the source and destination address fields of the first
     (most inner) LISP header of a packet.

 Is LISP redefining the name of the header of the encapsulated packet from
 "IP header" to "LISP header"?

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 21:59:13 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C9B3A6A0F for ; Tue, 27 Apr 2010 21:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level: 
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD-nXvTv529I for ; Tue, 27 Apr 2010 21:59:12 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D4EBD3A6825 for ; Tue, 27 Apr 2010 21:59:12 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zMS-00045Y-Jy; Tue, 27 Apr 2010 21:59:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 04:59:00 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/90
Message-ID: <057.c2afd19f5efd5e0b56214e525e3a2d61@tools.ietf.org>
X-Trac-Ticket-ID: 90
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #90: Restricting re-encapsulation (comment 12 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 04:59:13 -0000

#90: Restricting re-encapsulation (comment 12 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 3:

     Reencapsulating Tunnels:   when a packet has no more than one LISP IP
     header (two IP headers total) and when it needs to be diverted to
     new RLOC, an ETR can decapsulate the packet (remove the LISP
     header) and prepend a new tunnel header, with new RLOC, on to the
     packet.

 Why re-encapsulation is restricted to packets that only have a single
 level of LISP encapsulation?

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:10:35 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9AB33A6825 for ; Tue, 27 Apr 2010 22:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7aVu4DmzMlv for ; Tue, 27 Apr 2010 22:10:34 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0A90F3A6767 for ; Tue, 27 Apr 2010 22:10:30 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zXO-0005Do-7V; Tue, 27 Apr 2010 22:10:18 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:10:18 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/91
Message-ID: <057.4ef4b95468b76b9cc11050d0b9322670@tools.ietf.org>
X-Trac-Ticket-ID: 91
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #91: Data probe (comment 12 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:10:35 -0000

#91: Data probe (comment 12 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:     
    Type:  technical           |      Status:  new
Priority:  major               |   Component:  alt
Severity:  -                   |    Keywords:     
-------------------------------+--------------------------------------------
 Data Probe:

     a LISP-encapsulated data packet where the inner header
     destination address equals the outer header destination address

 These are discouraged by [ALT] due to scalability concerns.  Perhaps this
 should be noted, or Data Probes should be moved to an appendix.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:13:32 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916F73A69AA for ; Tue, 27 Apr 2010 22:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.591
X-Spam-Level: 
X-Spam-Status: No, score=-101.591 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLMKNJ5FEz4A for ; Tue, 27 Apr 2010 22:13:30 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E10203A6767 for ; Tue, 27 Apr 2010 22:13:04 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zZs-0003OV-LH; Tue, 27 Apr 2010 22:12:52 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:12:52 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/92
Message-ID: <057.19112cc202620bccb7b1e38e850c40ff@tools.ietf.org>
X-Trac-Ticket-ID: 92
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #92: Restriction on number of encapsulations (comment 13 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:13:32 -0000

#92: Restriction on number of encapsulations (comment 13 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 4:

    An additional LISP header may be prepended to packets by a transit
    router (i.e.  TE-ITR) when re-routing of the path for a packet is
    desired.  An obvious instance of this would be an ISP router that
    needs to perform traffic engineering for packets in flow through its
    network.  In such a situation, termed Recursive Tunneling, an ISP
    transit acts as an additional ingress tunnel router and the RLOC it
    uses for the new prepended header would be either a TE-ETR within the
    ISP (along intra-ISP traffic engineered path) or a TE-ETR within
    another ISP (an inter-ISP traffic engineered path, where an agreement
    to build such a path exists).

    This specification mandates that no more than two LISP headers get
    prepended to a packet.  This avoids excessive packet overhead as well
    as possible encapsulation loops.  It is believed two headers is
    sufficient, where the first prepended header is used at a site for
    Location/Identity separation and second prepended header is used
    inside a service provider for Traffic Engineering purposes.


 The restriction on the number of encapsulations seems impossible to
 enforce, and therefore somewhat pointless.  Worse, it seems harmful; in
 order to foil ISP TE, all one needs to do is place an extra header in the
 LISP packets.  If the spec is obeyed,
 re-encapsulation will be prevented.

 The restriction on the number of headers would also seem to preclude host-
 based implementations of LISP being located behind site-based LISP
 routers.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:15:20 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB923A69AA for ; Tue, 27 Apr 2010 22:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HI0g-MBq20w for ; Tue, 27 Apr 2010 22:15:19 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4B28C3A6AFD for ; Tue, 27 Apr 2010 22:14:48 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zbV-0007P9-Op; Tue, 27 Apr 2010 22:14:34 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:14:33 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/93
Message-ID: <057.63cffa477f8ccfd4caf3e3da8005eebd@tools.ietf.org>
X-Trac-Ticket-ID: 93
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #93: VPN (comment 14 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:15:20 -0000

#93: VPN (comment 14 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:     
    Type:  technical           |      Status:  new
Priority:  major               |   Component:  alt
Severity:  -                   |    Keywords:     
-------------------------------+--------------------------------------------
 Section 4

    Another example, perhaps for a VPN service out-sourced to an ISP
    by a site, the ITR could be the site's border router at the service
    provider attachment point.


 Since VPN is outside the scope of the LISP WG charter, the above should be
 deleted (as it is outside the scope).

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:16:40 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C423A682F for ; Tue, 27 Apr 2010 22:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGBPUFIYXNCu for ; Tue, 27 Apr 2010 22:16:39 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D30103A6767 for ; Tue, 27 Apr 2010 22:16:38 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zdJ-000427-7a; Tue, 27 Apr 2010 22:16:26 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:16:25 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/94
Message-ID: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@tools.ietf.org>
X-Trac-Ticket-ID: 94
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #94: Implications on using Control plane for data forwarding (comment 15 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:16:40 -0000

#94: Implications on using Control plane for data forwarding (comment 15
reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 4.1

     In LISP 1.5, the packet is routed on a different topology
     which may have EID prefixes distributed and advertised in an
     aggregatable fashion.  In either case, the packet arrives at the
     ETR.  The router is configured to "punt" the packet to the
     router's processor.


 Note that the packet is a data plane packet. That means that on ETR the
 control plane is used for data plane packet forwarding. What are the
 implications of this on control plane performance?

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:18:48 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056D23A6A45 for ; Tue, 27 Apr 2010 22:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNLMkveBKqRg for ; Tue, 27 Apr 2010 22:18:33 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 907053A68AF for ; Tue, 27 Apr 2010 22:18:33 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zfB-0008NP-BJ; Tue, 27 Apr 2010 22:18:21 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:18:21 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/95
Message-ID: <057.d5d01bfa13c7250cdec5b89a66e6ac0e@tools.ietf.org>
X-Trac-Ticket-ID: 95
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #95: On eliminating vs. deferring mapping lookup (comment 15 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:18:48 -0000

#95: On eliminating vs. deferring mapping lookup (comment 15 reported by Y.
Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 4.1:

     In order to eliminate the need for a mapping lookup in the reverse
     direction, an ETR MAY create a cache entry that maps the source EID
     (inner header source IP address) to the source RLOC (outer header
     source IP address) in a received LISP packet.  Such a cache entry is
     termed a "gleaned" mapping and only contains a single RLOC for the
     EID in question.  More complete information about additional RLOCs
     SHOULD be verified by sending a LISP Map-Request for that EID.


 The last sentence in the quote contradicts the first sentence.  The
 mapping lookup is not eliminated, but merely deferred.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:21:46 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A1F3A67D4 for ; Tue, 27 Apr 2010 22:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.773
X-Spam-Level: 
X-Spam-Status: No, score=-101.773 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_05=-1.11, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq9nxK33-Q3T for ; Tue, 27 Apr 2010 22:21:41 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C3E363A68AF for ; Tue, 27 Apr 2010 22:20:56 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zhU-0005OT-Gt; Tue, 27 Apr 2010 22:20:44 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:20:44 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/96
Message-ID: <057.6ff6aad30217bed0a620c320885db98b@tools.ietf.org>
X-Trac-Ticket-ID: 96
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #96: Confidence in informal Survey (comment 16 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:21:46 -0000

#96: Confidence in informal Survey (comment 16 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 5:

     Based on informal surveys of large ISP traffic patterns, it appears
     that most transit paths can accommodate a path MTU of at least 4470
     bytes. The exceptions, in terms of data rate, number of hosts
     affected, or any other metric are expected to be vanishingly small.


 An informal survey is not sufficient to provide confidence that the
 exception will be vanishingly small.  It seems likely that the informal
 survey may have suffered from sampling bias, as most such surveys do.
 For example, did the survey consider wireless carriers?

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:24:09 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965303A6B35 for ; Tue, 27 Apr 2010 22:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.516
X-Spam-Level: 
X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jjrbss4e+Nad for ; Tue, 27 Apr 2010 22:23:58 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 837E43A6AE3 for ; Tue, 27 Apr 2010 22:22:20 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zii-0000XT-Ru; Tue, 27 Apr 2010 22:22:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:22:00 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/97
Message-ID: <057.8ea20e7a00dec499bcff4e4fa48eacda@tools.ietf.org>
X-Trac-Ticket-ID: 97
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #97: MTU concerns (comment 16 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:24:10 -0000
X-List-Received-Date: Wed, 28 Apr 2010 05:24:10 -0000

#97: MTU concerns (comment 16 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 5:

     To address MTU concerns, mainly raised on the RRG mailing list, the
     LISP deployment process will include collecting data during its pilot
     phase to either verify or refute the assumption about minimum
     available MTU.


 Even if this is true, the LISP architecture is supposedly not restricted
 to transit networks.  The document discusses location of ITRs within sites
 rather than at site edges.  Is there evidence that 1500 byte MTUs are
 corner cases within sites?

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:27:18 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496BB3A67D4 for ; Tue, 27 Apr 2010 22:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.516
X-Spam-Level: 
X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXDFT5gtDKv8 for ; Tue, 27 Apr 2010 22:27:16 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 940113A6825 for ; Tue, 27 Apr 2010 22:23:43 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zjz-0004Kb-3J; Tue, 27 Apr 2010 22:23:19 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:23:19 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/98
Message-ID: <057.4c9852b0a65d29853b641f556c39a295@tools.ietf.org>
X-Trac-Ticket-ID: 98
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp]  #98: LISP nonce (comment 17 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:27:18 -0000

#98: LISP nonce (comment 17 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  editorial           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 5.3

     LISP Nonce:  is a 24-bit value that is randomly generated by an ITR
     when the N-bit is set to 1.


 The LISP Nonce does not seem to have a security usage.  The choice of the
 term "nonce" might lead the reader to think that it does.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:28:06 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6060C3A6AD9 for ; Tue, 27 Apr 2010 22:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.516
X-Spam-Level: 
X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQvo4S9TYjYl for ; Tue, 27 Apr 2010 22:28:05 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9C24F3A695E for ; Tue, 27 Apr 2010 22:26:46 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zmz-0006aX-Pt; Tue, 27 Apr 2010 22:26:25 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:26:25 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/99
Message-ID: <057.412ba34f2babe03fe10d1234f260eba3@tools.ietf.org>
X-Trac-Ticket-ID: 99
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #99: Confusion in Section 5.4.1 (comment 18 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:28:06 -0000

#99: Confusion in Section 5.4.1 (comment 18 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  editorial           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 5.4.1


 As written, this section seems broken.  Perhaps the fix would be to define
 S as the maximum size of a packet, in bytes, an ITR would LIKE TO receive
 from a source inside of its site.  Without knowing what the authors
 intended, it's hard to be sure.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:28:57 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30EA43A6AC4 for ; Tue, 27 Apr 2010 22:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.516
X-Spam-Level: 
X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw-gPrWNbEZ6 for ; Tue, 27 Apr 2010 22:28:56 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 58A8D3A6ACD for ; Tue, 27 Apr 2010 22:28:16 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zoZ-00044h-Oc; Tue, 27 Apr 2010 22:28:03 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:28:03 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/100
Message-ID: <057.2c7ec716cb843a3d17b46315e069c60a@tools.ietf.org>
X-Trac-Ticket-ID: 100
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #100: "Stateless" and "Stateful" MTU handling (comment 18 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:28:57 -0000

#100: "Stateless" and "Stateful" MTU handling (comment 18 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Regarding the "stateless" and "stateful" MTU handling solutions, there are
 really two orthogonal parameters at work: whether max MTU is configured
 (5.4.1) or learned (5.4.2) and whether the ITR does (5.4.1) or does not
 (5.4.2) perform fragmentation.  So, there are
 actually room for two more solutions in the matrix, a configured MTU + ITR
 that does not do fragmentation, and a learned MTU + ITR that does do
 fragmentation.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:30:09 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C9B3A693B for ; Tue, 27 Apr 2010 22:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4mOK7VO+QIo for ; Tue, 27 Apr 2010 22:30:07 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DD18D3A6863 for ; Tue, 27 Apr 2010 22:30:06 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zqJ-0000aF-3A; Tue, 27 Apr 2010 22:29:51 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:29:51 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/101
Message-ID: <057.0e0d4458c9205c12214b19f32a304af1@tools.ietf.org>
X-Trac-Ticket-ID: 101
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #101: Filtering ICMP messages (comment 19 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:30:09 -0000

#101: Filtering ICMP messages (comment 19 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 5.4.2

 How would this work if the ITR is behind the firewall, and the firewall
 filters ICMP messages?

 Also, in the case where a large volume of traffic has to be moved from one
 ITR to another (e.g., due to ITR failure), it will take time for the ITR
 to which the traffic is moved to discover the effective MTU for each
 locator mapping, and until this occurs, the traffic will be dropped.

 Moreover, this ITR could also get overloaded with ICMP Too Big messages,
 which could further increase the time required to discover the effective
 MTU for each locator mapping.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:32:42 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5A73A6883 for ; Tue, 27 Apr 2010 22:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEnGFq6BLm3J for ; Tue, 27 Apr 2010 22:32:42 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1F40D3A65A5 for ; Tue, 27 Apr 2010 22:32:42 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zsr-0001mS-Od; Tue, 27 Apr 2010 22:32:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:32:29 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/102
Message-ID: <057.e4c8cc50b0e5d4e7bd0e5b0c75ab80af@tools.ietf.org>
X-Trac-Ticket-ID: 102
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #102: Originating ITR RLOC address (comment 20 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:32:43 -0000

#102: Originating ITR RLOC address (comment 20 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 6.1.2

         Originating ITR RLOC Address:  Used to give the ETR the option of
         returning a Map-Reply in the address-family of this locator.

 => This does not seem correct.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:33:26 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAE13A69C8 for ; Tue, 27 Apr 2010 22:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnYoXyNQvfTF for ; Tue, 27 Apr 2010 22:33:24 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D8B733A69C3 for ; Tue, 27 Apr 2010 22:33:21 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6ztV-0001mg-HT; Tue, 27 Apr 2010 22:33:09 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:33:09 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/103
Message-ID: <057.d807df80a56b7add227b99565ce590d8@tools.ietf.org>
X-Trac-Ticket-ID: 103
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #103: Mapping Protocol Data (comment 20 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:33:26 -0000

#103: Mapping Protocol Data (comment 20 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  editorial           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Mapping Protocol Data:  See [CONS] or [ALT] for details.

 => There are no details in [ALT].

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:35:33 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211523A6A26 for ; Tue, 27 Apr 2010 22:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP-3fMzDlgN9 for ; Tue, 27 Apr 2010 22:35:32 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D272D3A6883 for ; Tue, 27 Apr 2010 22:35:31 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zvb-0001oN-MP; Tue, 27 Apr 2010 22:35:19 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:35:19 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/104
Message-ID: <057.f694ed8ffc9311fa27f420bbc248f1c8@tools.ietf.org>
X-Trac-Ticket-ID: 104
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #104: Impact of slashdotting ETR (comment 21 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:35:33 -0000

#104: Impact of slashdotting ETR (comment 21 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 6.1.3

 General questions on this section include what is the expected behavior
 when an ETR is slashdotted (i.e., is subjected to an unexpected, very
 high, continuous load of legitimate queries), a comparison of the failure
 mode in this scenario to the behavior of a non-LISP network in the same
 scenario, and the related question of what is considered to be
 a reasonable Map-Request rate to support.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:38:07 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4486B3A69EE for ; Tue, 27 Apr 2010 22:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfvJQN+Yjy72 for ; Tue, 27 Apr 2010 22:38:06 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0069E3A69A9 for ; Tue, 27 Apr 2010 22:38:05 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6zy4-0001rw-Uv; Tue, 27 Apr 2010 22:37:52 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:37:52 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/105
Message-ID: <057.dbd133e742ac4f8794ca979b8e84c9e4@tools.ietf.org>
X-Trac-Ticket-ID: 105
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #105: EID-to-RLOC UDP Map-Reply message (comment 23 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:38:07 -0000

#105: EID-to-RLOC UDP Map-Reply message (comment 23 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 6.1.5 EID-to-RLOC UDP Map-Reply message

     A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record
     count of 3 to be returned with mapping records for EID-prefixes
     10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.


 Why would those three prefixes be returned?  A more general comment is
 that what a Map-Reply must return in response to a given Map-Request is
 underspecified (or the specification is not comprehensible).

 To address this perhaps insert something like the following:

   "When an ETR replies to a Map-Request, it must reply with its
   EID-prefix that is the best match for the Map-Request. In addition,
   if it is configured with any EID-prefixes which are more-specifics
   of the best match EID-prefix that it returns in its Map-Reply, it
   must return all of those more-specific EID-prefixe s in the same
   Map-Reply".

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:44:47 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393F53A67D4 for ; Tue, 27 Apr 2010 22:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RPp1ph+eH8a for ; Tue, 27 Apr 2010 22:44:38 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 13BAA3A6883 for ; Tue, 27 Apr 2010 22:44:19 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O7046-000246-IU; Tue, 27 Apr 2010 22:44:06 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:44:06 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/106
Message-ID: <057.39e8e70821ba35f11c2eda95607db252@tools.ietf.org>
X-Trac-Ticket-ID: 106
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #106: Unassigned values in Map-Reply messages (comment 22 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:44:47 -0000

#106: Unassigned values in Map-Reply messages (comment 22 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 6.1.4

     ACT:  This 3-bit field describes negative Map-Reply actions.  These
     bits are used only when the 'Locator Count' field is set to 0.
     The action bits are encoded only in Map-Reply messages.  The
     actions defined are used by an ITR or PTR when a destination EID
     matches a negative mapping cache entry.  Unassigned values should
     cause a map-cache entry to be created and, when packets match this
     negative cache entry, they will be dropped.  The current assigned

 Why is this default chosen for unassigned actions?  (This assumes that
 Create map-cache drop state is what is meant by "treat unassigned actions
 like action 0").  Since a three bit field was chosen, presumably the
 authors expect that up to eight different actions may be needed, but only
 three are defined.

 How would the proposed default behavior affect whether such new flags can
 actually be deployed?

     (1) Natively-Forward:  The packet is not encapsulated or dropped
      but natively forwarded.

 Presumably "natively forwarded" means "forwarded without LISP
 encapsulation on the regular Internet topology"?

     (2) Send-Map-Request:  The packet invokes sending a Map-Request.

 What does this mean?

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:47:38 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491D03A682F for ; Tue, 27 Apr 2010 22:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pxUXdhSqG1M for ; Tue, 27 Apr 2010 22:47:37 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 90AE53A6825 for ; Tue, 27 Apr 2010 22:47:37 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O707J-0004BE-D5; Tue, 27 Apr 2010 22:47:25 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:47:25 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/107
Message-ID: <057.6c572dbc28a86db1374edfbd5b635558@tools.ietf.org>
X-Trac-Ticket-ID: 107
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #107: "Weight" in Map-Reply Message Format (comment 22 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:47:38 -0000

#107: "Weight" in Map-Reply Message Format (comment 22 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 6.1.4:

      Weight:  when priorities are the same for multiple RLOCs, the weight
                      indicates how to balance unicast traffic between
 them.  Weight is
                      encoded as a percentage of total unicast packets that
 match the
                      mapping entry.  If a non-zero weight value is used
 for any RLOC,
                      then all RLOCs must use a non-zero weight value and
 then the sum
                      of all weight values MUST equal 100.


 The document does not specify how it is to be handled if the sum is not
 100. The same criticism applies to M Weight.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:49:01 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24C73A69A9 for ; Tue, 27 Apr 2010 22:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level: 
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOVM98K7qSKH for ; Tue, 27 Apr 2010 22:49:01 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 197B53A6883 for ; Tue, 27 Apr 2010 22:49:01 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O708e-0004Bw-TR; Tue, 27 Apr 2010 22:48:48 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:48:48 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/108
Message-ID: <057.e05715fe3dc7985fc8019f02b0aabd49@tools.ietf.org>
X-Trac-Ticket-ID: 108
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #108: "R" bit in Map-Reply message format (comment 22 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:49:02 -0000

#108: "R" bit in Map-Reply message format (comment 22 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 6.1.4:

      R: when this bit is set, the locator is known to be reachable from
           the Map-Reply sender's perspective.


 The utility of this bit is never explained and it's not clear how one
 would make good use of it.  I.e.,  1 means the sender thinks the given
 locator is reachable, but 0 is just a question mark.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:50:43 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CC13A69C3 for ; Tue, 27 Apr 2010 22:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level: 
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJtvX1JP0Swf for ; Tue, 27 Apr 2010 22:50:42 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1162C3A683C for ; Tue, 27 Apr 2010 22:50:42 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O70AH-0004Fw-PK; Tue, 27 Apr 2010 22:50:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:50:29 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/109
Message-ID: <057.9c2e4d52ca3762d5ccd0de2094680378@tools.ietf.org>
X-Trac-Ticket-ID: 109
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #109: "Locator" in Map-reply message format (comment 22 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:50:43 -0000

#109: "Locator" in Map-reply message format (comment 22 reported  by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  editorial           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 6.1.4:

     Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
                      assigned to an ETR or router acting as a proxy
 replier for the
                      EID-prefix.


 "Proxy replier" is never defined.

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:52:10 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD18C3A6A45 for ; Tue, 27 Apr 2010 22:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level: 
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8pjiDCr2H0f for ; Tue, 27 Apr 2010 22:52:09 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E11F53A6A12 for ; Tue, 27 Apr 2010 22:52:09 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O70Bh-0004Hp-NY; Tue, 27 Apr 2010 22:51:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:51:57 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/110
Message-ID: <057.4533d3a2a5f3888dcb0b76e3c2e3f0ae@tools.ietf.org>
X-Trac-Ticket-ID: 110
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: [lisp] #110: "Mapping Protocol Data" in Map-Reply Message Format (comment 22 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:52:11 -0000

#110: "Mapping Protocol Data" in Map-Reply Message Format (comment 22 reported by
Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  editorial           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 6.1.4:

         Mapping Protocol Data:  See [CONS] or [ALT] for details.


 There are no details in [ALT].

-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:53:37 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6B03A6A0F for ; Tue, 27 Apr 2010 22:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHJiDBUvx+fW for ; Tue, 27 Apr 2010 22:53:35 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5FFF03A6A44 for ; Tue, 27 Apr 2010 22:53:28 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O70Cy-0004I0-7d; Tue, 27 Apr 2010 22:53:16 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:53:16 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/84#comment:1
Message-ID: <066.72806d8e7121f16560cfb4bcd3a46bd8@tools.ietf.org>
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org>
X-Trac-Ticket-ID: 84
In-Reply-To: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:53:38 -0000

#84: Renumbering burden when clients change providers (comment 9 reported by Y.
Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
Changes (by wmhaddad@…):

  * component:  alt => draft-ietf-lisp


-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:54:19 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE523A6A0F for ; Tue, 27 Apr 2010 22:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnN10zLDltfi for ; Tue, 27 Apr 2010 22:54:17 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CF0EA3A69EE for ; Tue, 27 Apr 2010 22:54:16 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O70Dk-0004JM-MS; Tue, 27 Apr 2010 22:54:04 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:54:04 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/91#comment:1
Message-ID: <066.a4f84cced6cf3caa82b48fbca4432fbc@tools.ietf.org>
References: <057.4ef4b95468b76b9cc11050d0b9322670@tools.ietf.org>
X-Trac-Ticket-ID: 91
In-Reply-To: <057.4ef4b95468b76b9cc11050d0b9322670@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: Re: [lisp] #91: Data probe (comment 12 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:54:19 -0000

#91: Data probe (comment 12 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
Changes (by wmhaddad@…):

  * component:  alt => draft-ietf-lisp


-- 
Ticket URL: 
lisp 
LISP WG document issues

From trac@tools.ietf.org  Tue Apr 27 22:55:06 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A726F3A6A64 for ; Tue, 27 Apr 2010 22:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca9GqEzzmPuX for ; Tue, 27 Apr 2010 22:55:05 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E6B163A6A44 for ; Tue, 27 Apr 2010 22:55:05 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O70EX-0004JZ-L7; Tue, 27 Apr 2010 22:54:53 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 05:54:53 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/93#comment:1
Message-ID: <066.8c9936d3fa94ffb55d5184f034b28b70@tools.ietf.org>
References: <057.63cffa477f8ccfd4caf3e3da8005eebd@tools.ietf.org>
X-Trac-Ticket-ID: 93
In-Reply-To: <057.63cffa477f8ccfd4caf3e3da8005eebd@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: Re: [lisp] #93: VPN (comment 14 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 05:55:06 -0000

#93: VPN (comment 14 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
Changes (by wmhaddad@…):

  * component:  alt => draft-ietf-lisp


-- 
Ticket URL: 
lisp 
LISP WG document issues

From lear@cisco.com  Tue Apr 27 23:02:06 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DA93A6A64 for ; Tue, 27 Apr 2010 23:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level: 
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=-3.079, BAYES_50=0.001, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrQD5L4kGBAf for ; Tue, 27 Apr 2010 23:02:06 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 712DB3A69EE for ; Tue, 27 Apr 2010 23:00:10 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: At0BAEZr10uQ/uCWiWdsb2JhbACDFplQFQEBAQoLEREGHKQTiGuRKIElgTSBSG0E
X-IronPort-AV: E=Sophos;i="4.52,286,1270425600";  d="scan'208";a="6336969"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 28 Apr 2010 05:23:03 +0000
Received: from dhcp-10-55-84-127.cisco.com (dhcp-10-55-84-127.cisco.com [10.55.84.127]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3S5xusH024426; Wed, 28 Apr 2010 05:59:56 GMT
Message-ID: <4BD7CEC8.2090902@cisco.com>
Date: Wed, 28 Apr 2010 07:59:36 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100426 Lanikai/3.1b2pre
MIME-Version: 1.0
To: lisp issue tracker 
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org>
In-Reply-To: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lisp@ietf.org
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Apr 2010 06:02:07 -0000

  Yakov (and others),

On 4/28/10 6:45 AM, lisp issue tracker wrote:
>   3.  Easing of renumbering burden when clients change providers.
>         Because host EIDs are numbered from a separate, non-provider-
>         assigned and non-topologically-bound space, they do not need to
>         be renumbered when a client site changes its attachment points to
>         the network.
>
>   At least with respect to LISP+ALT, this statement is incorrect.  Sites are
>   simply locked in to their EID provider instead of being locked in to their
>   ISP as they are now.  The lock-in would appear to be more severe than it
>   is today, since unless strong aggregation is preserved, LISP's entire
>   value proposition is lost.

This statement is overly broad, because how aggregation occurs will 
depend on how the ALT ecosystem is built up.  One approach that I have 
heard that could work well be some sort of regional system where 
aggregation occurs at that level.  For instance, there could be several 
ALT EID providers in New York that all make use of a particular block of 
address space.  They disaggregate that address space within region, but 
otherwise aggregate above.

Eliot

From trac@tools.ietf.org  Tue Apr 27 23:15:07 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B75F3A6AEE for ; Tue, 27 Apr 2010 23:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m8p6F4hBo4l for ; Tue, 27 Apr 2010 23:15:06 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9EDFC3A6AE8 for ; Tue, 27 Apr 2010 23:15:06 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O70Xs-0000sT-Lm; Tue, 27 Apr 2010 23:14:53 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "lisp issue tracker" 
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: wmhaddad@gmail.com
X-Trac-Project: lisp
Date: Wed, 28 Apr 2010 06:14:52 -0000
X-URL: http://tools.ietf.org/lisp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/82#comment:1
Message-ID: <066.11e344c45573af7834ca7432de045d41@tools.ietf.org>
References: <057.4cd8d8e5f55131ea251196d9debcb9ee@tools.ietf.org>
X-Trac-Ticket-ID: 82
In-Reply-To: <057.4cd8d8e5f55131ea251196d9debcb9ee@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wmhaddad@gmail.com, lisp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: lisp@ietf.org
Subject: Re: [lisp] #82: Wording in Abstract (comment 8 and 44 reported by Y. Rekhter) (was: Wording in Abstract (comment 8 reported by Y. Rekhter))
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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 Apr 2010 06:15:07 -0000

#82: Wording in Abstract (comment 8 and 44 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  editorial           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------

-- 
Ticket URL: 
lisp 
LISP WG document issues

From rcallon@juniper.net  Wed Apr 28 14:48:21 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A0828C134 for ; Wed, 28 Apr 2010 14:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.447
X-Spam-Level: 
X-Spam-Status: No, score=-4.447 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_50=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvXB64tSwesE for ; Wed, 28 Apr 2010 14:48:21 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id BC9963A69ED for ; Wed, 28 Apr 2010 14:47:51 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKS9is+vAs5zktrrBmdWmHDMCgqbh1p7eG@postini.com; Wed, 28 Apr 2010 14:48:07 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 28 Apr 2010 14:46:08 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 28 Apr 2010 17:46:07 -0400
From: Ross Callon 
To: Eliot Lear , lisp issue tracker 
Date: Wed, 28 Apr 2010 17:46:05 -0400
Thread-Topic: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
Thread-Index: AcrmmFCs4QFe3ggdQV+r+rbnPXV2AwAgT8MA
Message-ID: 
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>
In-Reply-To: <4BD7CEC8.2090902@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Apr 2010 21:48:21 -0000

If I understand your proposal correctly:=20

There could be several ALT EID providers in a particular region, that all a=
re capable of mapping EID's to RLOC's for a particular range of EID's. They=
 would each be allocating EID's from a particular range (ie, using a common=
 prefix). I assume that this means either that they would coordinate EID as=
signments, or that they would each have a subrange within this range of EID=
s that they could each assign. They would each advertise the same one prefi=
x into the ALT topology covering this range, and many different organizatio=
ns could have EID's taken from this range (presumably each organization wou=
ld have a smaller block out of the range). A request for an EID to RLOC map=
ping could be routed to any of these ALT EID providers, which would either =
know the mapping (for the entire range), or would know which of the other A=
LT EID providers in the region would know the mapping. In any case, for the=
 entire ALT topology outside of that region the mapping requests for EID's =
within that range could be routed to this set of ALT EID providers using a =
single prefix which covers that range.=20

Eliot, is this approximately the model that you are referring to in your em=
ail (understanding that this is not the only possible model)?=20

How would the geographic and/or topological location of the customer site e=
ffect whether or not they would accept (or be given) an EID from this parti=
cular range?=20

Thanks, Ross

-----Original Message-----
From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of Eli=
ot Lear
Sent: 28 April 2010 02:00
To: lisp issue tracker
Cc: lisp@ietf.org
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (=
comment 9 reported by Y. Rekhter)

  Yakov (and others),

On 4/28/10 6:45 AM, lisp issue tracker wrote:
>   3.  Easing of renumbering burden when clients change providers.
>         Because host EIDs are numbered from a separate, non-provider-
>         assigned and non-topologically-bound space, they do not need to
>         be renumbered when a client site changes its attachment points to
>         the network.
>
>   At least with respect to LISP+ALT, this statement is incorrect.  Sites =
are
>   simply locked in to their EID provider instead of being locked in to th=
eir
>   ISP as they are now.  The lock-in would appear to be more severe than i=
t
>   is today, since unless strong aggregation is preserved, LISP's entire
>   value proposition is lost.

This statement is overly broad, because how aggregation occurs will=20
depend on how the ALT ecosystem is built up.  One approach that I have=20
heard that could work well be some sort of regional system where=20
aggregation occurs at that level.  For instance, there could be several=20
ALT EID providers in New York that all make use of a particular block of=20
address space.  They disaggregate that address space within region, but=20
otherwise aggregate above.

Eliot
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

From dino@cisco.com  Wed Apr 28 17:33:27 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B164A3A6891 for ; Wed, 28 Apr 2010 17:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.263
X-Spam-Level: 
X-Spam-Status: No, score=-8.263 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_50=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iktp3tE8GeA6 for ; Wed, 28 Apr 2010 17:33:26 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C157F3A67EB for ; Wed, 28 Apr 2010 17:33:26 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,291,1270425600"; d="scan'208";a="522195297"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 29 Apr 2010 00:33:14 +0000
Received: from [10.34.153.107] ([10.34.153.107]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3T0XEoX003458; Thu, 29 Apr 2010 00:33:14 GMT
Message-Id: 
From: Dino Farinacci 
To: Ross Callon 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 28 Apr 2010 17:33:13 -0700
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com> 
X-Mailer: Apple Mail (2.936)
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 00:33:27 -0000

Let me add to this thread.

(1) There are no ALT providers.
(2) Sites will use map-resolver and map-servers from a mapping service  
provider (MSP).
(3) There will be multiple MSPs that sell service to sites at a  
specific tier level. This
     is not a pricing tier level, this is an EID address aggregation  
level.
(4) So when a site is allocated an EID-prefix from a RIR, it can buy  
from one or more various
     MSPs.

The site can change MSPs without changing their EID-prefix or their  
locator-set.

And, the site can change service providers and not have to renumber  
their EID-prefix, just a single locator address (it will get a new PA  
address from the new service provider it connects to) changes on the  
CPE router that connects to the new service provider.

The MSP can be an independent entity, an RIR, a service provider,  
interconnect provider, government, etc...

Dino

On Apr 28, 2010, at 2:46 PM, Ross Callon wrote:

> If I understand your proposal correctly:
>
> There could be several ALT EID providers in a particular region,  
> that all are capable of mapping EID's to RLOC's for a particular  
> range of EID's. They would each be allocating EID's from a  
> particular range (ie, using a common prefix). I assume that this  
> means either that they would coordinate EID assignments, or that  
> they would each have a subrange within this range of EIDs that they  
> could each assign. They would each advertise the same one prefix  
> into the ALT topology covering this range, and many different  
> organizations could have EID's taken from this range (presumably  
> each organization would have a smaller block out of the range). A  
> request for an EID to RLOC mapping could be routed to any of these  
> ALT EID providers, which would either know the mapping (for the  
> entire range), or would know which of the other ALT EID providers in  
> the region would know the mapping. In any case, for the entire ALT  
> topology outside of that region the mapping requests for EID's  
> within that ran
> ge could be routed to this set of ALT EID providers using a single  
> prefix which covers that range.
>
> Eliot, is this approximately the model that you are referring to in  
> your email (understanding that this is not the only possible model)?
>
> How would the geographic and/or topological location of the customer  
> site effect whether or not they would accept (or be given) an EID  
> from this particular range?
>
> Thanks, Ross
>
> -----Original Message-----
> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf  
> Of Eliot Lear
> Sent: 28 April 2010 02:00
> To: lisp issue tracker
> Cc: lisp@ietf.org
> Subject: Re: [lisp] #84: Renumbering burden when clients change  
> providers (comment 9 reported by Y. Rekhter)
>
>  Yakov (and others),
>
> On 4/28/10 6:45 AM, lisp issue tracker wrote:
>>  3.  Easing of renumbering burden when clients change providers.
>>        Because host EIDs are numbered from a separate, non-provider-
>>        assigned and non-topologically-bound space, they do not need  
>> to
>>        be renumbered when a client site changes its attachment  
>> points to
>>        the network.
>>
>>  At least with respect to LISP+ALT, this statement is incorrect.   
>> Sites are
>>  simply locked in to their EID provider instead of being locked in  
>> to their
>>  ISP as they are now.  The lock-in would appear to be more severe  
>> than it
>>  is today, since unless strong aggregation is preserved, LISP's  
>> entire
>>  value proposition is lost.
>
> This statement is overly broad, because how aggregation occurs will
> depend on how the ALT ecosystem is built up.  One approach that I have
> heard that could work well be some sort of regional system where
> aggregation occurs at that level.  For instance, there could be  
> several
> ALT EID providers in New York that all make use of a particular  
> block of
> address space.  They disaggregate that address space within region,  
> but
> otherwise aggregate above.
>
> Eliot
> _______________________________________________
> 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


From yakov@juniper.net  Wed Apr 28 18:26:45 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC1D3A6886 for ; Wed, 28 Apr 2010 18:26:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.711
X-Spam-Level: 
X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=0.288,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWYScgXwuIGz for ; Wed, 28 Apr 2010 18:26:44 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id D3A783A63EB for ; Wed, 28 Apr 2010 18:26:43 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS9jgQyuKbOwZn7AlVpWTYdPHzbL0WU++@postini.com; Wed, 28 Apr 2010 18:26:31 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 28 Apr 2010 18:25:44 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Apr 2010 18:25:44 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Apr 2010 18:25:43 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Apr 2010 18:25:43 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3T1PhD16273; Wed, 28 Apr 2010 18:25:43 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <201004290125.o3T1PhD16273@magenta.juniper.net>
To: Dino Farinacci 
In-Reply-To:  
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>  
X-MH-In-Reply-To: Dino Farinacci  message dated "Wed, 28 Apr 2010 17:33:13 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <87857.1272504342.1@juniper.net>
Date: Wed, 28 Apr 2010 18:25:42 -0700
From: Yakov Rekhter 
X-OriginalArrivalTime: 29 Apr 2010 01:25:43.0564 (UTC) FILETIME=[E2FA14C0:01CAE73A]
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 01:26:45 -0000

Dino,

> Let me add to this thread.
> 
> (1) There are no ALT providers.

>From  section 4.4 of draft-ietf-lisp-ms-05.txt:

                                            Using a LISP+ALT mapaping
       database, the Map-Resolver is connected to the ALT network and
       sends the Map-Request to the next ALT hop learned from its ALT
       BGP neighbors. 

How would the Map-Resolver connect to the ALT network if there
are no ALT providers ?

Yakov.

> (2) Sites will use map-resolver and map-servers from a mapping service  
> provider (MSP).
> (3) There will be multiple MSPs that sell service to sites at a  
> specific tier level. This
>      is not a pricing tier level, this is an EID address aggregation  
> level.
> (4) So when a site is allocated an EID-prefix from a RIR, it can buy  
> from one or more various
>      MSPs.
> 
> The site can change MSPs without changing their EID-prefix or their  
> locator-set.
> 
> And, the site can change service providers and not have to renumber  
> their EID-prefix, just a single locator address (it will get a new PA  
> address from the new service provider it connects to) changes on the  
> CPE router that connects to the new service provider.
> 
> The MSP can be an independent entity, an RIR, a service provider,  
> interconnect provider, government, etc...
> 
> Dino
> 
> On Apr 28, 2010, at 2:46 PM, Ross Callon wrote:
> 
> > If I understand your proposal correctly:
> >
> > There could be several ALT EID providers in a particular region,  
> > that all are capable of mapping EID's to RLOC's for a particular  
> > range of EID's. They would each be allocating EID's from a  
> > particular range (ie, using a common prefix). I assume that this  
> > means either that they would coordinate EID assignments, or that  
> > they would each have a subrange within this range of EIDs that they  
> > could each assign. They would each advertise the same one prefix  
> > into the ALT topology covering this range, and many different  
> > organizations could have EID's taken from this range (presumably  
> > each organization would have a smaller block out of the range). A  
> > request for an EID to RLOC mapping could be routed to any of these  
> > ALT EID providers, which would either know the mapping (for the  
> > entire range), or would know which of the other ALT EID providers in  
> > the region would know the mapping. In any case, for the entire ALT  
> > topology outside of that region the mapping requests for EID's  
> > within that ran
> > ge could be routed to this set of ALT EID providers using a single  
> > prefix which covers that range.
> >
> > Eliot, is this approximately the model that you are referring to in  
> > your email (understanding that this is not the only possible model)?
> >
> > How would the geographic and/or topological location of the customer  
> > site effect whether or not they would accept (or be given) an EID  
> > from this particular range?
> >
> > Thanks, Ross
> >
> > -----Original Message-----
> > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf  
> > Of Eliot Lear
> > Sent: 28 April 2010 02:00
> > To: lisp issue tracker
> > Cc: lisp@ietf.org
> > Subject: Re: [lisp] #84: Renumbering burden when clients change  
> > providers (comment 9 reported by Y. Rekhter)
> >
> >  Yakov (and others),
> >
> > On 4/28/10 6:45 AM, lisp issue tracker wrote:
> >>  3.  Easing of renumbering burden when clients change providers.
> >>        Because host EIDs are numbered from a separate, non-provider-
> >>        assigned and non-topologically-bound space, they do not need  
> >> to
> >>        be renumbered when a client site changes its attachment  
> >> points to
> >>        the network.
> >>
> >>  At least with respect to LISP+ALT, this statement is incorrect.   
> >> Sites are
> >>  simply locked in to their EID provider instead of being locked in  
> >> to their
> >>  ISP as they are now.  The lock-in would appear to be more severe  
> >> than it
> >>  is today, since unless strong aggregation is preserved, LISP's  
> >> entire
> >>  value proposition is lost.
> >
> > This statement is overly broad, because how aggregation occurs will
> > depend on how the ALT ecosystem is built up.  One approach that I have
> > heard that could work well be some sort of regional system where
> > aggregation occurs at that level.  For instance, there could be  
> > several
> > ALT EID providers in New York that all make use of a particular  
> > block of
> > address space.  They disaggregate that address space within region,  
> > but
> > otherwise aggregate above.
> >
> > Eliot
> > _______________________________________________
> > 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
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

From lear@cisco.com  Wed Apr 28 22:55:08 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7703B3A6AD5 for ; Wed, 28 Apr 2010 22:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level: 
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-2.651,  BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+oby7S5j7XO for ; Wed, 28 Apr 2010 22:55:07 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 1F3313A67FF for ; Wed, 28 Apr 2010 22:55:06 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtoBAJu72EuQ/uCWiWdsb2JhbACDFZl1FQEBAQoLEREGHKI9iGyRIoEmgn1tBA
X-IronPort-AV: E=Sophos;i="4.52,294,1270425600";  d="scan'208";a="6422428"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 29 Apr 2010 05:17:55 +0000
Received: from dhcp-10-61-100-52.cisco.com (dhcp-10-61-100-52.cisco.com [10.61.100.52]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3T5sqsT002823; Thu, 29 Apr 2010 05:54:52 GMT
Message-ID: <4BD91F17.9050300@cisco.com>
Date: Thu, 29 Apr 2010 07:54:31 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100426 Lanikai/3.1b2pre
MIME-Version: 1.0
To: Ross Callon 
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 05:55:08 -0000

  Ross,

First, I'll refer you also to Dino's answer since he has a different=20
model in mind.

On 4/28/10 11:46 PM, Ross Callon wrote:
> If I understand your proposal correctly:
>
> There could be several ALT EID providers in a particular region, that a=
ll are capable of mapping EID's to RLOC's for a particular range of EID's=
=2E They would each be allocating EID's from a particular range (ie, usin=
g a common prefix). I assume that this means either that they would coord=
inate EID assignments, or that they would each have a subrange within thi=
s range of EIDs that they could each assign. They would each advertise th=
e same one prefix into the ALT topology covering this range, and many dif=
ferent organizations could have EID's taken from this range (presumably e=
ach organization would have a smaller block out of the range). A request =
for an EID to RLOC mapping could be routed to any of these ALT EID provid=
ers, which would either know the mapping (for the entire range), or would=
 know which of the other ALT EID providers in the region would know the m=
apping. In any case, for the entire ALT topology outside of that region t=
he mapping requests for EID's within that range could be routed to this s=
et of ALT EID providers using a single prefix which covers that range.
>
> Eliot, is this approximately the model that you are referring to in you=
r email (understanding that this is not the only possible model)?

Yes, but see below.

> How would the geographic and/or topological location of the customer si=
te effect whether or not they would accept (or be given) an EID from this=
 particular range?

It almost doesn't matter, so long as there is known state between the=20
ETR and the ALT, because we're not talking data packets.  Put another=20
way, I *should* have written the above in terms of federations rather=20
than regions.

Eliot


From dino@cisco.com  Wed Apr 28 23:11:10 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0A43A6B22 for ; Wed, 28 Apr 2010 23:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level: 
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StepI0p5-GO2 for ; Wed, 28 Apr 2010 23:11:08 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6B7B93A6AE3 for ; Wed, 28 Apr 2010 23:11:04 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAA/A2EutJV2d/2dsb2JhbACdCnGiPZoMglqCNgSDOw
X-IronPort-AV: E=Sophos;i="4.52,294,1270425600"; d="scan'208";a="106190784"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2010 06:10:50 +0000
Received: from [192.168.1.3] (sjc-vpn7-937.cisco.com [10.21.147.169]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o3T6AnGv024597;  Thu, 29 Apr 2010 06:10:49 GMT
Message-Id: 
From: Dino Farinacci 
To: Yakov Rekhter 
In-Reply-To: <201004290125.o3T1PhD16273@magenta.juniper.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 28 Apr 2010 23:10:49 -0700
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>   <201004290125.o3T1PhD16273@magenta.juniper.net>
X-Mailer: Apple Mail (2.936)
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 06:11:10 -0000

> Dino,
>
>> Let me add to this thread.
>>
>> (1) There are no ALT providers.
>
> From  section 4.4 of draft-ietf-lisp-ms-05.txt:
>
>                                            Using a LISP+ALT mapaping
>       database, the Map-Resolver is connected to the ALT network and
>       sends the Map-Request to the next ALT hop learned from its ALT
>       BGP neighbors.
>
> How would the Map-Resolver connect to the ALT network if there
> are no ALT providers ?

A Map-Resolver has a peering agreement with another organization that  
will do ALT with it. It is not necessarily a subscription based  
service like a site would connect to a service provider as we see it  
today. Ditto for two tier-1 ISPs that BGP peer with each other.

Dino

>
> Yakov.
>
>> (2) Sites will use map-resolver and map-servers from a mapping  
>> service
>> provider (MSP).
>> (3) There will be multiple MSPs that sell service to sites at a
>> specific tier level. This
>>     is not a pricing tier level, this is an EID address aggregation
>> level.
>> (4) So when a site is allocated an EID-prefix from a RIR, it can buy
>> from one or more various
>>     MSPs.
>>
>> The site can change MSPs without changing their EID-prefix or their
>> locator-set.
>>
>> And, the site can change service providers and not have to renumber
>> their EID-prefix, just a single locator address (it will get a new PA
>> address from the new service provider it connects to) changes on the
>> CPE router that connects to the new service provider.
>>
>> The MSP can be an independent entity, an RIR, a service provider,
>> interconnect provider, government, etc...
>>
>> Dino
>>
>> On Apr 28, 2010, at 2:46 PM, Ross Callon wrote:
>>
>>> If I understand your proposal correctly:
>>>
>>> There could be several ALT EID providers in a particular region,
>>> that all are capable of mapping EID's to RLOC's for a particular
>>> range of EID's. They would each be allocating EID's from a
>>> particular range (ie, using a common prefix). I assume that this
>>> means either that they would coordinate EID assignments, or that
>>> they would each have a subrange within this range of EIDs that they
>>> could each assign. They would each advertise the same one prefix
>>> into the ALT topology covering this range, and many different
>>> organizations could have EID's taken from this range (presumably
>>> each organization would have a smaller block out of the range). A
>>> request for an EID to RLOC mapping could be routed to any of these
>>> ALT EID providers, which would either know the mapping (for the
>>> entire range), or would know which of the other ALT EID providers in
>>> the region would know the mapping. In any case, for the entire ALT
>>> topology outside of that region the mapping requests for EID's
>>> within that ran
>>> ge could be routed to this set of ALT EID providers using a single
>>> prefix which covers that range.
>>>
>>> Eliot, is this approximately the model that you are referring to in
>>> your email (understanding that this is not the only possible model)?
>>>
>>> How would the geographic and/or topological location of the customer
>>> site effect whether or not they would accept (or be given) an EID
>>> from this particular range?
>>>
>>> Thanks, Ross
>>>
>>> -----Original Message-----
>>> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf
>>> Of Eliot Lear
>>> Sent: 28 April 2010 02:00
>>> To: lisp issue tracker
>>> Cc: lisp@ietf.org
>>> Subject: Re: [lisp] #84: Renumbering burden when clients change
>>> providers (comment 9 reported by Y. Rekhter)
>>>
>>> Yakov (and others),
>>>
>>> On 4/28/10 6:45 AM, lisp issue tracker wrote:
>>>> 3.  Easing of renumbering burden when clients change providers.
>>>>       Because host EIDs are numbered from a separate, non-provider-
>>>>       assigned and non-topologically-bound space, they do not need
>>>> to
>>>>       be renumbered when a client site changes its attachment
>>>> points to
>>>>       the network.
>>>>
>>>> At least with respect to LISP+ALT, this statement is incorrect.
>>>> Sites are
>>>> simply locked in to their EID provider instead of being locked in
>>>> to their
>>>> ISP as they are now.  The lock-in would appear to be more severe
>>>> than it
>>>> is today, since unless strong aggregation is preserved, LISP's
>>>> entire
>>>> value proposition is lost.
>>>
>>> This statement is overly broad, because how aggregation occurs will
>>> depend on how the ALT ecosystem is built up.  One approach that I  
>>> have
>>> heard that could work well be some sort of regional system where
>>> aggregation occurs at that level.  For instance, there could be
>>> several
>>> ALT EID providers in New York that all make use of a particular
>>> block of
>>> address space.  They disaggregate that address space within region,
>>> but
>>> otherwise aggregate above.
>>>
>>> Eliot
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp


From yakov@juniper.net  Thu Apr 29 06:53:19 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E22828C28C for ; Thu, 29 Apr 2010 06:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.73
X-Spam-Level: 
X-Spam-Status: No, score=-5.73 tagged_above=-999 required=5 tests=[AWL=0.269,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clikHZwMIiIs for ; Thu, 29 Apr 2010 06:53:18 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id B8A423A6BF4 for ; Thu, 29 Apr 2010 06:46:03 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKS9mNi8ClDg8+yz+njWcoTqpXwJBRIw1y@postini.com; Thu, 29 Apr 2010 06:45:51 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 29 Apr 2010 06:42:56 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Apr 2010 06:42:56 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 06:42:56 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Apr 2010 06:42:55 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3TDgtD46487; Thu, 29 Apr 2010 06:42:55 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <201004291342.o3TDgtD46487@magenta.juniper.net>
To: Dino Farinacci 
In-Reply-To:  
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>   <201004290125.o3T1PhD16273@magenta.juniper.net> 
X-MH-In-Reply-To: Dino Farinacci  message dated "Wed, 28 Apr 2010 23:10:49 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <11754.1272548575.1@juniper.net>
Date: Thu, 29 Apr 2010 06:42:55 -0700
From: Yakov Rekhter 
X-OriginalArrivalTime: 29 Apr 2010 13:42:55.0897 (UTC) FILETIME=[DF807890:01CAE7A1]
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 13:53:19 -0000

Dino,

> > Dino,
> >
> >> Let me add to this thread.
> >>
> >> (1) There are no ALT providers.
> >
> > From  section 4.4 of draft-ietf-lisp-ms-05.txt:
> >
>                                            Using a LISP+ALT mapaping
> >       database, the Map-Resolver is connected to the ALT network and
> >       sends the Map-Request to the next ALT hop learned from its ALT
> >       BGP neighbors.
> >
> > How would the Map-Resolver connect to the ALT network if there
> > are no ALT providers ?
> 
> A Map-Resolver has a peering agreement with another organization that  
> will do ALT with it. It is not necessarily a subscription based  
> service like a site would connect to a service provider as we see it  
> today. Ditto for two tier-1 ISPs that BGP peer with each other.

Does the above mean that there is still an ALT network ?

Yakov.

> 
> Dino
> 
> >
> > Yakov.
> >
> >> (2) Sites will use map-resolver and map-servers from a mapping  
> >> service
> >> provider (MSP).
> >> (3) There will be multiple MSPs that sell service to sites at a
> >> specific tier level. This
> >>     is not a pricing tier level, this is an EID address aggregation
> >> level.
> >> (4) So when a site is allocated an EID-prefix from a RIR, it can buy
> >> from one or more various
> >>     MSPs.
> >>
> >> The site can change MSPs without changing their EID-prefix or their
> >> locator-set.
> >>
> >> And, the site can change service providers and not have to renumber
> >> their EID-prefix, just a single locator address (it will get a new PA
> >> address from the new service provider it connects to) changes on the
> >> CPE router that connects to the new service provider.
> >>
> >> The MSP can be an independent entity, an RIR, a service provider,
> >> interconnect provider, government, etc...
> >>
> >> Dino
> >>
> >> On Apr 28, 2010, at 2:46 PM, Ross Callon wrote:
> >>
> >>> If I understand your proposal correctly:
> >>>
> >>> There could be several ALT EID providers in a particular region,
> >>> that all are capable of mapping EID's to RLOC's for a particular
> >>> range of EID's. They would each be allocating EID's from a
> >>> particular range (ie, using a common prefix). I assume that this
> >>> means either that they would coordinate EID assignments, or that
> >>> they would each have a subrange within this range of EIDs that they
> >>> could each assign. They would each advertise the same one prefix
> >>> into the ALT topology covering this range, and many different
> >>> organizations could have EID's taken from this range (presumably
> >>> each organization would have a smaller block out of the range). A
> >>> request for an EID to RLOC mapping could be routed to any of these
> >>> ALT EID providers, which would either know the mapping (for the
> >>> entire range), or would know which of the other ALT EID providers in
> >>> the region would know the mapping. In any case, for the entire ALT
> >>> topology outside of that region the mapping requests for EID's
> >>> within that ran
> >>> ge could be routed to this set of ALT EID providers using a single
> >>> prefix which covers that range.
> >>>
> >>> Eliot, is this approximately the model that you are referring to in
> >>> your email (understanding that this is not the only possible model)?
> >>>
> >>> How would the geographic and/or topological location of the customer
> >>> site effect whether or not they would accept (or be given) an EID
> >>> from this particular range?
> >>>
> >>> Thanks, Ross
> >>>
> >>> -----Original Message-----
> >>> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf
> >>> Of Eliot Lear
> >>> Sent: 28 April 2010 02:00
> >>> To: lisp issue tracker
> >>> Cc: lisp@ietf.org
> >>> Subject: Re: [lisp] #84: Renumbering burden when clients change
> >>> providers (comment 9 reported by Y. Rekhter)
> >>>
> >>> Yakov (and others),
> >>>
> >>> On 4/28/10 6:45 AM, lisp issue tracker wrote:
> >>>> 3.  Easing of renumbering burden when clients change providers.
> >>>>       Because host EIDs are numbered from a separate, non-provider-
> >>>>       assigned and non-topologically-bound space, they do not need
> >>>> to
> >>>>       be renumbered when a client site changes its attachment
> >>>> points to
> >>>>       the network.
> >>>>
> >>>> At least with respect to LISP+ALT, this statement is incorrect.
> >>>> Sites are
> >>>> simply locked in to their EID provider instead of being locked in
> >>>> to their
> >>>> ISP as they are now.  The lock-in would appear to be more severe
> >>>> than it
> >>>> is today, since unless strong aggregation is preserved, LISP's
> >>>> entire
> >>>> value proposition is lost.
> >>>
> >>> This statement is overly broad, because how aggregation occurs will
> >>> depend on how the ALT ecosystem is built up.  One approach that I  
> >>> have
> >>> heard that could work well be some sort of regional system where
> >>> aggregation occurs at that level.  For instance, there could be
> >>> several
> >>> ALT EID providers in New York that all make use of a particular
> >>> block of
> >>> address space.  They disaggregate that address space within region,
> >>> but
> >>> otherwise aggregate above.
> >>>
> >>> Eliot
> >>> _______________________________________________
> >>> 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
> >>
> >> _______________________________________________
> >> lisp mailing list
> >> lisp@ietf.org
> >> https://www.ietf.org/mailman/listinfo/lisp
> 

From robert@raszuk.net  Thu Apr 29 07:27:10 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3F33A67AD for ; Thu, 29 Apr 2010 07:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CvSCe2DiPkK for ; Thu, 29 Apr 2010 07:27:10 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id DE07D28C2AA for ; Thu, 29 Apr 2010 07:21:51 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmkBAF4z2UuQ/uCWiWdsb2JhbACdDhUBAQEKCxERBhykUJoFhRAE
X-IronPort-AV: E=Sophos;i="4.52,295,1270425600";  d="scan'208";a="6459309"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 29 Apr 2010 13:44:38 +0000
Received: from [127.0.0.1] (dhcp-10-55-88-94.cisco.com [10.55.88.94]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3TELbNq007978; Thu, 29 Apr 2010 14:21:37 GMT
Message-ID: <4BD99606.6050906@raszuk.net>
Date: Thu, 29 Apr 2010 16:21:58 +0200
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: lisp@ietf.org, Yakov Rekhter 
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org>	<4BD7CEC8.2090902@cisco.com>			<201004290125.o3T1PhD16273@magenta.juniper.net>	 <201004291342.o3TDgtD46487@magenta.juniper.net>
In-Reply-To: <201004291342.o3TDgtD46487@magenta.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
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: Thu, 29 Apr 2010 14:27:10 -0000

Hi Yakov,

>>> How would the Map-Resolver connect to the ALT network if there
>>> are no ALT providers ?
>>
>> A Map-Resolver has a peering agreement with another organization that
>> will do ALT with it. It is not necessarily a subscription based
>> service like a site would connect to a service provider as we see it
>> today. Ditto for two tier-1 ISPs that BGP peer with each other.
>
> Does the above mean that there is still an ALT network ?
>
> Yakov.

I am sure Dino or Elliot will give you their answer, but I want to give 
you my POV too.

There is no need for ALT network in the classic understanding of 
"network" which is build and operated by single entity.

There is clearly a need for a mapping plane .. be it LISP-ALT or 
LISP-DHT or LISP-XYZ, but that can be constructed based on mutual 
non-adjacent inter-provider's agreements. (Sure it could be also 
supported by one global provider.) I think terminology wise it would be 
better for it to be referred to as ALT plane not ALT network.

You very well know that this is build using IP encapsulation technology 
which does not require any signaling in the transit networks and 
therefor allows a lot of flexibility (as opposed to any other tunneling 
technology which may require signaling and full support in any transit 
node).

Now can you clarify what is really this particular doubt you are trying 
to clarify ? I don't think I understand issue #84 if this strictly 
assumes EID to RLOC binding. AFAIK that was never the design constrain.

Deployment example:

Assume there is ALT plane in US and someone who will allocate EIDs. Me 
sitting in SJC I can get an EID or set of EIDs for my own network. All I 
need to do is to inform an ALT plane what are my current RLOCs whenever 
I decide to switch the local providers. Other then renumbering a single 
interface to my provider I don't see I need to do any thing else on my 
xTRs acting as CEs.

Cheers,
R.




From dino@cisco.com  Thu Apr 29 09:18:19 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88143A6A66 for ; Thu, 29 Apr 2010 09:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.467
X-Spam-Level: 
X-Spam-Status: No, score=-9.467 tagged_above=-999 required=5 tests=[AWL=0.532,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o22CTYeAjunk for ; Thu, 29 Apr 2010 09:18:18 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D36D93A6808 for ; Thu, 29 Apr 2010 09:18:15 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAI5O2UurR7Hu/2dsb2JhbACdD3GlHJl+glqCNgSDPA
X-IronPort-AV: E=Sophos;i="4.52,296,1270425600"; d="scan'208";a="321714163"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 29 Apr 2010 16:18:02 +0000
Received: from [192.168.5.50] (sjc-vpn6-1228.cisco.com [10.21.124.204]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3TGI2nJ006022; Thu, 29 Apr 2010 16:18:02 GMT
Message-Id: <816D98B1-2E72-433D-A343-64BA63349F34@cisco.com>
From: Dino Farinacci 
To: Yakov Rekhter 
In-Reply-To: <201004291342.o3TDgtD46487@magenta.juniper.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 29 Apr 2010 09:18:01 -0700
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>   <201004290125.o3T1PhD16273@magenta.juniper.net>  <201004291342.o3TDgtD46487@magenta.juniper.net>
X-Mailer: Apple Mail (2.936)
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 16:18:19 -0000

> Dino,
>
>>> Dino,
>>>
>>>> Let me add to this thread.
>>>>
>>>> (1) There are no ALT providers.
>>>
>>> From  section 4.4 of draft-ietf-lisp-ms-05.txt:
>>>
>>                                           Using a LISP+ALT mapaping
>>>      database, the Map-Resolver is connected to the ALT network and
>>>      sends the Map-Request to the next ALT hop learned from its ALT
>>>      BGP neighbors.
>>>
>>> How would the Map-Resolver connect to the ALT network if there
>>> are no ALT providers ?
>>
>> A Map-Resolver has a peering agreement with another organization that
>> will do ALT with it. It is not necessarily a subscription based
>> service like a site would connect to a service provider as we see it
>> today. Ditto for two tier-1 ISPs that BGP peer with each other.
>
> Does the above mean that there is still an ALT network ?

Yes, but it is relatively sparse to what you would expect from an  
underlying BGP topology. I really don't mean to be vague but trying to  
understand where the disconnect is.

Dino

>
> Yakov.
>
>>
>> Dino
>>
>>>
>>> Yakov.
>>>
>>>> (2) Sites will use map-resolver and map-servers from a mapping
>>>> service
>>>> provider (MSP).
>>>> (3) There will be multiple MSPs that sell service to sites at a
>>>> specific tier level. This
>>>>    is not a pricing tier level, this is an EID address aggregation
>>>> level.
>>>> (4) So when a site is allocated an EID-prefix from a RIR, it can  
>>>> buy
>>>> from one or more various
>>>>    MSPs.
>>>>
>>>> The site can change MSPs without changing their EID-prefix or their
>>>> locator-set.
>>>>
>>>> And, the site can change service providers and not have to renumber
>>>> their EID-prefix, just a single locator address (it will get a  
>>>> new PA
>>>> address from the new service provider it connects to) changes on  
>>>> the
>>>> CPE router that connects to the new service provider.
>>>>
>>>> The MSP can be an independent entity, an RIR, a service provider,
>>>> interconnect provider, government, etc...
>>>>
>>>> Dino
>>>>
>>>> On Apr 28, 2010, at 2:46 PM, Ross Callon wrote:
>>>>
>>>>> If I understand your proposal correctly:
>>>>>
>>>>> There could be several ALT EID providers in a particular region,
>>>>> that all are capable of mapping EID's to RLOC's for a particular
>>>>> range of EID's. They would each be allocating EID's from a
>>>>> particular range (ie, using a common prefix). I assume that this
>>>>> means either that they would coordinate EID assignments, or that
>>>>> they would each have a subrange within this range of EIDs that  
>>>>> they
>>>>> could each assign. They would each advertise the same one prefix
>>>>> into the ALT topology covering this range, and many different
>>>>> organizations could have EID's taken from this range (presumably
>>>>> each organization would have a smaller block out of the range). A
>>>>> request for an EID to RLOC mapping could be routed to any of these
>>>>> ALT EID providers, which would either know the mapping (for the
>>>>> entire range), or would know which of the other ALT EID  
>>>>> providers in
>>>>> the region would know the mapping. In any case, for the entire ALT
>>>>> topology outside of that region the mapping requests for EID's
>>>>> within that ran
>>>>> ge could be routed to this set of ALT EID providers using a single
>>>>> prefix which covers that range.
>>>>>
>>>>> Eliot, is this approximately the model that you are referring to  
>>>>> in
>>>>> your email (understanding that this is not the only possible  
>>>>> model)?
>>>>>
>>>>> How would the geographic and/or topological location of the  
>>>>> customer
>>>>> site effect whether or not they would accept (or be given) an EID
>>>>> from this particular range?
>>>>>
>>>>> Thanks, Ross
>>>>>
>>>>> -----Original Message-----
>>>>> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On  
>>>>> Behalf
>>>>> Of Eliot Lear
>>>>> Sent: 28 April 2010 02:00
>>>>> To: lisp issue tracker
>>>>> Cc: lisp@ietf.org
>>>>> Subject: Re: [lisp] #84: Renumbering burden when clients change
>>>>> providers (comment 9 reported by Y. Rekhter)
>>>>>
>>>>> Yakov (and others),
>>>>>
>>>>> On 4/28/10 6:45 AM, lisp issue tracker wrote:
>>>>>> 3.  Easing of renumbering burden when clients change providers.
>>>>>>      Because host EIDs are numbered from a separate, non- 
>>>>>> provider-
>>>>>>      assigned and non-topologically-bound space, they do not need
>>>>>> to
>>>>>>      be renumbered when a client site changes its attachment
>>>>>> points to
>>>>>>      the network.
>>>>>>
>>>>>> At least with respect to LISP+ALT, this statement is incorrect.
>>>>>> Sites are
>>>>>> simply locked in to their EID provider instead of being locked in
>>>>>> to their
>>>>>> ISP as they are now.  The lock-in would appear to be more severe
>>>>>> than it
>>>>>> is today, since unless strong aggregation is preserved, LISP's
>>>>>> entire
>>>>>> value proposition is lost.
>>>>>
>>>>> This statement is overly broad, because how aggregation occurs  
>>>>> will
>>>>> depend on how the ALT ecosystem is built up.  One approach that I
>>>>> have
>>>>> heard that could work well be some sort of regional system where
>>>>> aggregation occurs at that level.  For instance, there could be
>>>>> several
>>>>> ALT EID providers in New York that all make use of a particular
>>>>> block of
>>>>> address space.  They disaggregate that address space within  
>>>>> region,
>>>>> but
>>>>> otherwise aggregate above.
>>>>>
>>>>> Eliot
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>


From yakov@juniper.net  Thu Apr 29 10:12:13 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBA63A657C for ; Thu, 29 Apr 2010 10:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.747
X-Spam-Level: 
X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[AWL=0.252,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thJefrFUftB2 for ; Thu, 29 Apr 2010 10:12:12 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 71A363A6B7C for ; Thu, 29 Apr 2010 10:11:59 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKS9m9y3bPt5EwVJJjYLCp30JwrWoeWgz/@postini.com; Thu, 29 Apr 2010 10:11:46 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 29 Apr 2010 10:07:22 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Apr 2010 10:07:22 -0700
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 10:07:21 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Apr 2010 10:07:21 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3TH7KD47314; Thu, 29 Apr 2010 10:07:21 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <201004291707.o3TH7KD47314@magenta.juniper.net>
To: Dino Farinacci 
In-Reply-To: <816D98B1-2E72-433D-A343-64BA63349F34@cisco.com> 
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>   <201004290125.o3T1PhD16273@magenta.juniper.net>  <201004291342.o3TDgtD46487@magenta.juniper.net> <816D98B1-2E72-433D-A343-64BA63349F34@cisco.com>
X-MH-In-Reply-To: Dino Farinacci  message dated "Thu, 29 Apr 2010 09:18:01 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19797.1272560840.1@juniper.net>
Date: Thu, 29 Apr 2010 10:07:20 -0700
From: Yakov Rekhter 
X-OriginalArrivalTime: 29 Apr 2010 17:07:21.0491 (UTC) FILETIME=[6E5D9630:01CAE7BE]
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 17:12:13 -0000

Dino,

> >>> Dino,
> >>>
> >>>> Let me add to this thread.
> >>>>
> >>>> (1) There are no ALT providers.
> >>>
> >>> From  section 4.4 of draft-ietf-lisp-ms-05.txt:
> >>>
> >>                                           Using a LISP+ALT mapaping
> >>>      database, the Map-Resolver is connected to the ALT network and
> >>>      sends the Map-Request to the next ALT hop learned from its ALT
> >>>      BGP neighbors.
> >>>
> >>> How would the Map-Resolver connect to the ALT network if there
> >>> are no ALT providers ?
> >>
> >> A Map-Resolver has a peering agreement with another organization that
> >> will do ALT with it. It is not necessarily a subscription based
> >> service like a site would connect to a service provider as we see it
> >> today. Ditto for two tier-1 ISPs that BGP peer with each other.
> >
> > Does the above mean that there is still an ALT network ?
> 
> Yes, but it is relatively sparse to what you would expect from an  
> underlying BGP topology. I really don't mean to be vague but trying to  
> understand where the disconnect is.

If there will be an ALT network, then someone should provide it
(someone have to operate the equipment that forms the ALT network).

Thus stating that there is an ALT network contradicts your statement
that "there are no ALT providers".

Yakov.


> 
> Dino
> 
> >
> > Yakov.
> >
> >>
> >> Dino
> >>
> >>>
> >>> Yakov.
> >>>
> >>>> (2) Sites will use map-resolver and map-servers from a mapping
> >>>> service
> >>>> provider (MSP).
> >>>> (3) There will be multiple MSPs that sell service to sites at a
> >>>> specific tier level. This
> >>>>    is not a pricing tier level, this is an EID address aggregation
> >>>> level.
> >>>> (4) So when a site is allocated an EID-prefix from a RIR, it can  
> >>>> buy
> >>>> from one or more various
> >>>>    MSPs.
> >>>>
> >>>> The site can change MSPs without changing their EID-prefix or their
> >>>> locator-set.
> >>>>
> >>>> And, the site can change service providers and not have to renumber
> >>>> their EID-prefix, just a single locator address (it will get a  
> >>>> new PA
> >>>> address from the new service provider it connects to) changes on  
> >>>> the
> >>>> CPE router that connects to the new service provider.
> >>>>
> >>>> The MSP can be an independent entity, an RIR, a service provider,
> >>>> interconnect provider, government, etc...
> >>>>
> >>>> Dino
> >>>>
> >>>> On Apr 28, 2010, at 2:46 PM, Ross Callon wrote:
> >>>>
> >>>>> If I understand your proposal correctly:
> >>>>>
> >>>>> There could be several ALT EID providers in a particular region,
> >>>>> that all are capable of mapping EID's to RLOC's for a particular
> >>>>> range of EID's. They would each be allocating EID's from a
> >>>>> particular range (ie, using a common prefix). I assume that this
> >>>>> means either that they would coordinate EID assignments, or that
> >>>>> they would each have a subrange within this range of EIDs that  
> >>>>> they
> >>>>> could each assign. They would each advertise the same one prefix
> >>>>> into the ALT topology covering this range, and many different
> >>>>> organizations could have EID's taken from this range (presumably
> >>>>> each organization would have a smaller block out of the range). A
> >>>>> request for an EID to RLOC mapping could be routed to any of these
> >>>>> ALT EID providers, which would either know the mapping (for the
> >>>>> entire range), or would know which of the other ALT EID  
> >>>>> providers in
> >>>>> the region would know the mapping. In any case, for the entire ALT
> >>>>> topology outside of that region the mapping requests for EID's
> >>>>> within that ran
> >>>>> ge could be routed to this set of ALT EID providers using a single
> >>>>> prefix which covers that range.
> >>>>>
> >>>>> Eliot, is this approximately the model that you are referring to  
> >>>>> in
> >>>>> your email (understanding that this is not the only possible  
> >>>>> model)?
> >>>>>
> >>>>> How would the geographic and/or topological location of the  
> >>>>> customer
> >>>>> site effect whether or not they would accept (or be given) an EID
> >>>>> from this particular range?
> >>>>>
> >>>>> Thanks, Ross
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On  
> >>>>> Behalf
> >>>>> Of Eliot Lear
> >>>>> Sent: 28 April 2010 02:00
> >>>>> To: lisp issue tracker
> >>>>> Cc: lisp@ietf.org
> >>>>> Subject: Re: [lisp] #84: Renumbering burden when clients change
> >>>>> providers (comment 9 reported by Y. Rekhter)
> >>>>>
> >>>>> Yakov (and others),
> >>>>>
> >>>>> On 4/28/10 6:45 AM, lisp issue tracker wrote:
> >>>>>> 3.  Easing of renumbering burden when clients change providers.
> >>>>>>      Because host EIDs are numbered from a separate, non- 
> >>>>>> provider-
> >>>>>>      assigned and non-topologically-bound space, they do not need
> >>>>>> to
> >>>>>>      be renumbered when a client site changes its attachment
> >>>>>> points to
> >>>>>>      the network.
> >>>>>>
> >>>>>> At least with respect to LISP+ALT, this statement is incorrect.
> >>>>>> Sites are
> >>>>>> simply locked in to their EID provider instead of being locked in
> >>>>>> to their
> >>>>>> ISP as they are now.  The lock-in would appear to be more severe
> >>>>>> than it
> >>>>>> is today, since unless strong aggregation is preserved, LISP's
> >>>>>> entire
> >>>>>> value proposition is lost.
> >>>>>
> >>>>> This statement is overly broad, because how aggregation occurs  
> >>>>> will
> >>>>> depend on how the ALT ecosystem is built up.  One approach that I
> >>>>> have
> >>>>> heard that could work well be some sort of regional system where
> >>>>> aggregation occurs at that level.  For instance, there could be
> >>>>> several
> >>>>> ALT EID providers in New York that all make use of a particular
> >>>>> block of
> >>>>> address space.  They disaggregate that address space within  
> >>>>> region,
> >>>>> but
> >>>>> otherwise aggregate above.
> >>>>>
> >>>>> Eliot
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >>>> _______________________________________________
> >>>> lisp mailing list
> >>>> lisp@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/lisp
> >>
> 

From dino@cisco.com  Thu Apr 29 11:14:27 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9B33A68F5 for ; Thu, 29 Apr 2010 11:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC2MqAkCrx9z for ; Thu, 29 Apr 2010 11:14:26 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 016CB28C0E3 for ; Thu, 29 Apr 2010 11:14:19 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEdp2UurR7Ht/2dsb2JhbACdD3Gje5lthRAEgzw
X-IronPort-AV: E=Sophos;i="4.52,296,1270425600"; d="scan'208";a="190351331"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 29 Apr 2010 18:14:06 +0000
Received: from dhcp-128-107-114-47.cisco.com (dhcp-128-107-114-47.cisco.com [128.107.114.47]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3TIE6lV019308; Thu, 29 Apr 2010 18:14:06 GMT
Message-Id: 
From: Dino Farinacci 
To: Yakov Rekhter 
In-Reply-To: <201004291707.o3TH7KD47314@magenta.juniper.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 29 Apr 2010 11:14:07 -0700
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>   <201004290125.o3T1PhD16273@magenta.juniper.net>  <201004291342.o3TDgtD46487@magenta.juniper.net> <816D98B1-2E72-433D-A343-64BA63349F34@cisco.com> <201004291707.o3TH7KD47314@magenta.juniper.net>
X-Mailer: Apple Mail (2.936)
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 18:14:27 -0000

> If there will be an ALT network, then someone should provide it
> (someone have to operate the equipment that forms the ALT network).
>
> Thus stating that there is an ALT network contradicts your statement
> that "there are no ALT providers".

I told you who could be an MSP. An MSP connects to the ALT. The ALT  
node can be from any of those MSP organizations.

Dino


From dino@cisco.com  Thu Apr 29 11:23:49 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FF728C287 for ; Thu, 29 Apr 2010 11:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09wDmxUotdva for ; Thu, 29 Apr 2010 11:23:34 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9DAB83A69F4 for ; Thu, 29 Apr 2010 11:22:25 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqoFAJ9r2UurR7Hu/2dsb2JhbACQcIwfcaN5mXCFEASDPA
X-IronPort-AV: E=Sophos;i="4.52,296,1270425600"; d="scan'208";a="522639488"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 29 Apr 2010 18:22:12 +0000
Received: from dhcp-128-107-114-47.cisco.com (dhcp-128-107-114-47.cisco.com [128.107.114.47]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3TIMCDP005039; Thu, 29 Apr 2010 18:22:12 GMT
Message-Id: <848F7C4C-177B-4C86-AEAD-B201C2783D92@cisco.com>
From: Dino Farinacci 
To: robert@raszuk.net
In-Reply-To: <4BD99606.6050906@raszuk.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 29 Apr 2010 11:22:13 -0700
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org>	<4BD7CEC8.2090902@cisco.com>			<201004290125.o3T1PhD16273@magenta.juniper.net>	 <201004291342.o3TDgtD46487@magenta.juniper.net> <4BD99606.6050906@raszuk.net>
X-Mailer: Apple Mail (2.936)
Cc: lisp@ietf.org
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 18:23:49 -0000

> There is no need for ALT network in the classic understanding of  
> "network" which is build and operated by single entity.

That was what I was trying to say.

> There is clearly a need for a mapping plane .. be it LISP-ALT or  
> LISP-DHT or LISP-XYZ, but that can be constructed based on mutual  
> non-adjacent inter-provider's agreements. (Sure it could be also  
> supported by one global provider.) I think terminology wise it would  
> be better for it to be referred to as ALT plane not ALT network.

Right, that is the model we have defined. We want the "mapping  
database transport system" to be modular and can drop in easily. The  
list above are examples of mapping database transport systems.

Sites do not have to change or upgraded since the use map-resolvers  
and map-servers.

> You very well know that this is build using IP encapsulation  
> technology which does not require any signaling in the transit  
> networks and therefor allows a lot of flexibility (as opposed to any  
> other tunneling technology which may require signaling and full  
> support in any transit node).

That is correct.

> Now can you clarify what is really this particular doubt you are  
> trying to clarify ? I don't think I understand issue #84 if this  
> strictly assumes EID to RLOC binding. AFAIK that was never the  
> design constrain.
>
> Deployment example:
>
> Assume there is ALT plane in US and someone who will allocate EIDs.  
> Me sitting in SJC I can get an EID or set of EIDs for my own  
> network. All I need to do is to inform an ALT plane what are my  
> current RLOCs whenever I decide to switch the local providers. Other  
> then renumbering a single interface to my provider I don't see I  
> need to do any thing else on my xTRs acting as CEs.

Correct.

Dino


From rcallon@juniper.net  Thu Apr 29 13:28:50 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0A328C343 for ; Thu, 29 Apr 2010 13:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level: 
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zko-2rG506-3 for ; Thu, 29 Apr 2010 13:28:49 -0700 (PDT)
Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id DE3B528C34C for ; Thu, 29 Apr 2010 13:23:44 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS9nqrgLk8manapeqWaS1378Hfd41bcPZ@postini.com; Thu, 29 Apr 2010 13:23:36 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 29 Apr 2010 13:18:36 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 29 Apr 2010 16:18:35 -0400
From: Ross Callon 
To: Eliot Lear 
Date: Thu, 29 Apr 2010 16:18:34 -0400
Thread-Topic: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
Thread-Index: AcrnYIE91tR5cv7wTf2anNChKxE3fQAdKpJw
Message-ID: 
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>  <4BD91F17.9050300@cisco.com>
In-Reply-To: <4BD91F17.9050300@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 20:28:51 -0000

I don't see what would motivate a particular group of organizations to  pro=
vide EID to RLOC mapping service unless they can charge for it (or they can=
 roll it into other services, such as Internet connectivity for a corporate=
 site). For a mapping service to cooperate with others on the mapping for a=
 particular range of EIDs seems like a way to drive down the price of the s=
ervice that they offer. I don't see what would motivate a group of mapping =
service organizations to cooperate with each other on providing a mapping f=
or a single EID range.=20

What seems more likely to me is that one organization would provide a mappi=
ng service for a particular range of addresses, and a different organizatio=
n would provide a mapping service for a different range of addresses. Of co=
urse, each organization providing mapping services could make use of multip=
le redundant servers, both to spread load and to provide backup in case a s=
erver fails (and perhaps also to distribute the servers to have a server "n=
ear" where any request might come from, in a topological sense).=20

To me this seems to imply that a customer site with a EID prefix is tied in=
to a single mapping service, unless they are willing to change their EID. O=
f course, they can change their Internet service provider from which they g=
et physical connectivity with very little trouble (just tell their mapping =
service to change their mapping, and change the configured address on their=
 CE routers). =20

I do understand that this assumes a model of how the mapping service might =
be deployed, and that there might be other models and some uncertainty rega=
rding what might actually end up being deployed.=20

Ross=20

-----Original Message-----
From: Eliot Lear [mailto:lear@cisco.com]=20
Sent: 29 April 2010 01:55
To: Ross Callon
Cc: lisp issue tracker; lisp@ietf.org
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (=
comment 9 reported by Y. Rekhter)

  Ross,

First, I'll refer you also to Dino's answer since he has a different=20
model in mind.

On 4/28/10 11:46 PM, Ross Callon wrote:
> If I understand your proposal correctly:
>
> There could be several ALT EID providers in a particular region, that all=
 are capable of mapping EID's to RLOC's for a particular range of EID's. Th=
ey would each be allocating EID's from a particular range (ie, using a comm=
on prefix). I assume that this means either that they would coordinate EID =
assignments, or that they would each have a subrange within this range of E=
IDs that they could each assign. They would each advertise the same one pre=
fix into the ALT topology covering this range, and many different organizat=
ions could have EID's taken from this range (presumably each organization w=
ould have a smaller block out of the range). A request for an EID to RLOC m=
apping could be routed to any of these ALT EID providers, which would eithe=
r know the mapping (for the entire range), or would know which of the other=
 ALT EID providers in the region would know the mapping. In any case, for t=
he entire ALT topology outside of that region the mapping requests for EID'=
s within that range could be routed to this set of ALT EID providers using =
a single prefix which covers that range.
>
> Eliot, is this approximately the model that you are referring to in your =
email (understanding that this is not the only possible model)?

Yes, but see below.

> How would the geographic and/or topological location of the customer site=
 effect whether or not they would accept (or be given) an EID from this par=
ticular range?

It almost doesn't matter, so long as there is known state between the=20
ETR and the ALT, because we're not talking data packets.  Put another=20
way, I *should* have written the above in terms of federations rather=20
than regions.

Eliot


From darlewis@cisco.com  Thu Apr 29 13:48:11 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B0A3A6A81 for ; Thu, 29 Apr 2010 13:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.185
X-Spam-Level: 
X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Bv1cP+3jJt5 for ; Thu, 29 Apr 2010 13:48:10 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B77783A6942 for ; Thu, 29 Apr 2010 13:48:10 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,297,1270425600"; d="scan'208";a="122691821"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 29 Apr 2010 20:47:57 +0000
Received: from sjc-vpn2-542.cisco.com (sjc-vpn2-542.cisco.com [10.21.114.30]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3TKlvm2004369;  Thu, 29 Apr 2010 20:47:57 GMT
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Darrel Lewis 
In-Reply-To: 
Date: Thu, 29 Apr 2010 13:48:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AE9ABB9-9B35-4537-903D-C5A728FCEB62@cisco.com>
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>  <4BD91F17.9050300@cisco.com> 
To: Ross Callon 
X-Mailer: Apple Mail (2.1078)
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 20:48:11 -0000

Its my feeling that an organization will be able to charge for mapping.

We know from experience in the DFZ that service providers are willing to =
route whatever prefixes that their customers provide (PI space or PA =
space from some other provider).  Many will also route PA space from =
other providers. Finally if a end site gets PI space from the =
registries, the point of who gets originally provides the address space =
is moot.

The key point is none of this is directly tied to the provider that is =
selling them data-plane Internet access.

-D


On Apr 29, 2010, at 1:18 PM, Ross Callon wrote:

> I don't see what would motivate a particular group of organizations to =
 provide EID to RLOC mapping service unless they can charge for it (or =
they can roll it into other services, such as Internet connectivity for =
a corporate site). For a mapping service to cooperate with others on the =
mapping for a particular range of EIDs seems like a way to drive down =
the price of the service that they offer. I don't see what would =
motivate a group of mapping service organizations to cooperate with each =
other on providing a mapping for a single EID range.=20
>=20
> What seems more likely to me is that one organization would provide a =
mapping service for a particular range of addresses, and a different =
organization would provide a mapping service for a different range of =
addresses. Of course, each organization providing mapping services could =
make use of multiple redundant servers, both to spread load and to =
provide backup in case a server fails (and perhaps also to distribute =
the servers to have a server "near" where any request might come from, =
in a topological sense).=20
>=20
> To me this seems to imply that a customer site with a EID prefix is =
tied into a single mapping service, unless they are willing to change =
their EID. Of course, they can change their Internet service provider =
from which they get physical connectivity with very little trouble (just =
tell their mapping service to change their mapping, and change the =
configured address on their CE routers). =20
>=20
> I do understand that this assumes a model of how the mapping service =
might be deployed, and that there might be other models and some =
uncertainty regarding what might actually end up being deployed.=20
>=20
> Ross=20
>=20
> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]=20
> Sent: 29 April 2010 01:55
> To: Ross Callon
> Cc: lisp issue tracker; lisp@ietf.org
> Subject: Re: [lisp] #84: Renumbering burden when clients change =
providers (comment 9 reported by Y. Rekhter)
>=20
>  Ross,
>=20
> First, I'll refer you also to Dino's answer since he has a different=20=

> model in mind.
>=20
> On 4/28/10 11:46 PM, Ross Callon wrote:
>> If I understand your proposal correctly:
>>=20
>> There could be several ALT EID providers in a particular region, that =
all are capable of mapping EID's to RLOC's for a particular range of =
EID's. They would each be allocating EID's from a particular range (ie, =
using a common prefix). I assume that this means either that they would =
coordinate EID assignments, or that they would each have a subrange =
within this range of EIDs that they could each assign. They would each =
advertise the same one prefix into the ALT topology covering this range, =
and many different organizations could have EID's taken from this range =
(presumably each organization would have a smaller block out of the =
range). A request for an EID to RLOC mapping could be routed to any of =
these ALT EID providers, which would either know the mapping (for the =
entire range), or would know which of the other ALT EID providers in the =
region would know the mapping. In any case, for the entire ALT topology =
outside of that region the mapping requests for EID's within that r
> ange could be routed to this set of ALT EID providers using a single =
prefix which covers that range.
>>=20
>> Eliot, is this approximately the model that you are referring to in =
your email (understanding that this is not the only possible model)?
>=20
> Yes, but see below.
>=20
>> How would the geographic and/or topological location of the customer =
site effect whether or not they would accept (or be given) an EID from =
this particular range?
>=20
> It almost doesn't matter, so long as there is known state between the=20=

> ETR and the ALT, because we're not talking data packets.  Put another=20=

> way, I *should* have written the above in terms of federations rather=20=

> than regions.
>=20
> Eliot
>=20
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp


From lear@cisco.com  Thu Apr 29 14:06:22 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F3E3A6A63 for ; Thu, 29 Apr 2010 14:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.844
X-Spam-Level: 
X-Spam-Status: No, score=-7.844 tagged_above=-999 required=5 tests=[AWL=2.755,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjH8CaGYujcC for ; Thu, 29 Apr 2010 14:06:20 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DD6803A69DE for ; Thu, 29 Apr 2010 14:06:18 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,297,1270425600"; d="scan'208";a="60367941"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2010 21:06:04 +0000
Received: from dhcp-10-55-95-186.cisco.com (dhcp-10-55-95-186.cisco.com [10.55.95.186]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3TL647f005109; Thu, 29 Apr 2010 21:06:04 GMT
Message-ID: <4BD9F4A6.6070906@cisco.com>
Date: Thu, 29 Apr 2010 23:05:42 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100429 Lanikai/3.1pre
MIME-Version: 1.0
To: Darrel Lewis 
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org> <4BD7CEC8.2090902@cisco.com>  <4BD91F17.9050300@cisco.com>  <2AE9ABB9-9B35-4537-903D-C5A728FCEB62@cisco.com>
In-Reply-To: <2AE9ABB9-9B35-4537-903D-C5A728FCEB62@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 21:06:22 -0000

On 4/29/10 10:48 PM, Darrel Lewis wrote:
> Its my feeling that an organization will be able to charge for mapping.

We have an existence proof of sorts.  Let's look at the forward map 
registry and registrars.

Eliot


From jmh@joelhalpern.com  Fri Apr 30 20:34:07 2010
Return-Path: 
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3DB3A6923 for ; Fri, 30 Apr 2010 20:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.856
X-Spam-Level: 
X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ujah+YWk+aDu for ; Fri, 30 Apr 2010 20:34:06 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 4DF9A3A67A4 for ; Fri, 30 Apr 2010 20:34:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 978EC32362B3; Fri, 30 Apr 2010 20:33:52 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.10.10.102] (pool-71-161-52-26.clppva.btas.verizon.net [71.161.52.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 8E26432283A9; Fri, 30 Apr 2010 20:33:51 -0700 (PDT)
Message-ID: <4BDBA11F.6000707@joelhalpern.com>
Date: Fri, 30 Apr 2010 23:33:51 -0400
From: "Joel M. Halpern" 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Ross Callon 
References: <057.c1bdfa25dec19e9e9f05544b409f4401@tools.ietf.org>	<4BD7CEC8.2090902@cisco.com>		<4BD91F17.9050300@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lisp issue tracker , "lisp@ietf.org" 
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 May 2010 03:34:07 -0000

Presumably, the EID delegation to end users will be a fee based service. 
  That fee will also cover the costs of running the BGP routers that 
will be needed to maintain the aggregated mapping infrastructure.

If the top level assignment authority (as mandated by RFCs if we ever go 
standards track) requires that there be competition for the maintenance 
of assignments, then the customer can take is business to a competing 
assigner for the block from which he got his EID assigned.
This does require some extra protocol somewhere to allow competing 
assigners.  Ir probably leads to a requirement that the competitors peer 
with each other.  But those sorts of requirements can be included in the 
system.

There are probably other ways to get the competitive goal.
I agree that it is important in the long term that we be able to have 
such competition.
Until I see what the WG wants for deployments, I don't know if that is 
at all important during the experiment.

Yours,
Joel

Ross Callon wrote:
> I don't see what would motivate a particular group of organizations to  provide EID to RLOC mapping service unless they can charge for it (or they can roll it into other services, such as Internet connectivity for a corporate site). For a mapping service to cooperate with others on the mapping for a particular range of EIDs seems like a way to drive down the price of the service that they offer. I don't see what would motivate a group of mapping service organizations to cooperate with each other on providing a mapping for a single EID range. 
> 
> What seems more likely to me is that one organization would provide a mapping service for a particular range of addresses, and a different organization would provide a mapping service for a different range of addresses. Of course, each organization providing mapping services could make use of multiple redundant servers, both to spread load and to provide backup in case a server fails (and perhaps also to distribute the servers to have a server "near" where any request might come from, in a topological sense). 
> 
> To me this seems to imply that a customer site with a EID prefix is tied into a single mapping service, unless they are willing to change their EID. Of course, they can change their Internet service provider from which they get physical connectivity with very little trouble (just tell their mapping service to change their mapping, and change the configured address on their CE routers).  
> 
> I do understand that this assumes a model of how the mapping service might be deployed, and that there might be other models and some uncertainty regarding what might actually end up being deployed. 
> 
> Ross 
> 
> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com] 
> Sent: 29 April 2010 01:55
> To: Ross Callon
> Cc: lisp issue tracker; lisp@ietf.org
> Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)
> 
>   Ross,
> 
> First, I'll refer you also to Dino's answer since he has a different 
> model in mind.
> 
> On 4/28/10 11:46 PM, Ross Callon wrote:
>> If I understand your proposal correctly:
>>
>> There could be several ALT EID providers in a particular region, that all are capable of mapping EID's to RLOC's for a particular range of EID's. They would each be allocating EID's from a particular range (ie, using a common prefix). I assume that this means either that they would coordinate EID assignments, or that they would each have a subrange within this range of EIDs that they could each assign. They would each advertise the same one prefix into the ALT topology covering this range, and many different organizations could have EID's taken from this range (presumably each organization would have a smaller block out of the range). A request for an EID to RLOC mapping could be routed to any of these ALT EID providers, which would either know the mapping (for the entire range), or would know which of the other ALT EID providers in the region would know the mapping. In any case, for the entire ALT topology outside of that region the mapping requests for EID's within that
 r
>  ange could be routed to this set of ALT EID providers using a single prefix which covers that range.
>> Eliot, is this approximately the model that you are referring to in your email (understanding that this is not the only possible model)?
> 
> Yes, but see below.
> 
>> How would the geographic and/or topological location of the customer site effect whether or not they would accept (or be given) an EID from this particular range?
> 
> It almost doesn't matter, so long as there is known state between the 
> ETR and the ALT, because we're not talking data packets.  Put another 
> way, I *should* have written the above in terms of federations rather 
> than regions.
> 
> Eliot
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>