From dino@cisco.com Thu Mar 3 14:48:27 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1035128C0D7 for ; Thu, 3 Mar 2011 14:48:27 -0800 (PST) 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 m1sV4UPO69Dl for ; Thu, 3 Mar 2011 14:48:26 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 423583A68B0 for ; Thu, 3 Mar 2011 14:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=385036; q=dns/txt; s=iport; t=1299192574; x=1300402174; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=TxkiyjHvo710DhOgL9IQJuZdmKOfD2cQIFvxdfSEmkc=; b=QRgweLBxRWqObC83vfl39drBlyZlceIz9+Qif2jJNjsri1m/3qE9bLY8 6MGdxE2lCl0vK6ioznIQqFmR9IqDax1HeKePJ2KFX67DOkNHaEBUST8V0 jvkccOWW9kmUd5NUNsqSGmqSS8dj+itKcEKbJxQcy5UBB5EP/opND4og5 Q=; X-Files: draft-ietf-lisp-10.txt, rfcdiff-lisp-09-to-10.html : 188128, 185944 X-IronPort-AV: E=Sophos;i="4.62,260,1297036800"; d="txt'?html'217?scan'217,208,217";a="317005426" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 03 Mar 2011 22:49:34 +0000 Received: from [10.34.153.93] ([10.34.153.93]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p23MnYDq006444; Thu, 3 Mar 2011 22:49:34 GMT Message-Id: From: Dino Farinacci To: Dino Farinacci In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-26-910310922 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Mar 2011 14:49:34 -0800 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Proposed minor changes for draft-ietf-lisp-10.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: Thu, 03 Mar 2011 22:48:27 -0000 --Apple-Mail-26-910310922 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Reminder, the deadline for comments is tomorrow for draft-ietf- lisp-10.txt, I plan to post if there are no comments. Here is a new update. Dino --Apple-Mail-26-910310922 Content-Disposition: attachment; filename=draft-ietf-lisp-10.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-10.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: September 4, 2011 D. Lewis cisco Systems March 3, 2011 Locator/ID Separation Protocol (LISP) draft-ietf-lisp-10 Abstract This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. 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 September 4, 2011. Farinacci, et al. Expires September 4, 2011 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Copyright Notice Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 30 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 36 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38 6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40 6.1.8. Encapsulated Control Message Format . . . . . . . . . 41 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49 6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 49 6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 50 Farinacci, et al. Expires September 4, 2011 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 51 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52 6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 53 7. Router Performance Considerations . . . . . . . . . . . . . . 55 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 57 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 58 8.4. LISP Functionality with Conventional NATs . . . . . . . . 58 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 59 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 60 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 60 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 60 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 62 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 62 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 62 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 62 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 64 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 64 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 66 12. Security Considerations . . . . . . . . . . . . . . . . . . . 67 13. Network Management Considerations . . . . . . . . . . . . . . 68 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 69 14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 69 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 15.1. Normative References . . . . . . . . . . . . . . . . . . . 70 15.2. Informative References . . . . . . . . . . . . . . . . . . 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 74 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 75 B.1. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 75 B.2. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 75 B.3. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 75 B.4. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 77 B.5. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 79 B.6. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 80 B.7. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 80 B.8. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 82 B.9. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 83 B.10. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 83 B.11. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 Farinacci, et al. Expires September 4, 2011 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 2. Introduction This document describes the Locator/Identifier Separation Protocol (LISP), which provides a set of functions for routers to exchange information used to map from non-routeable Endpoint Identifiers (EIDs) to routeable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across an Internet that uses RLOCs for routing and forwarding. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October, 2006 (see [RFC4984]). A key conclusion of the workshop was that the Internet routing and addressing system was not scaling well in the face of the explosive growth of new sites; one reason for this poor scaling is the increasing number of multi-homed and other sites that cannot be addressed as part of topologically- or provider-based aggregated prefixes. Additional work that more completely described the problem statement may be found in [RADIR]. A basic observation, made many years ago in early networking research such as that documented in [CHIAPPA] and [RFC4984], is that using a single address field for both identifying a device and for determining where it is topologically located in the network requires optimization along two conflicting axes: for routing to be efficient, the address must be assigned topologically; for collections of devices to be easily and effectively managed, without the need for renumbering in response to topological change (such as that caused by adding or removing attachment points to the network or by mobility events), the address must explicitly not be tied to the topology. The approach that LISP takes to solving the routing scalability problem is to replace IP addresses with two new types of numbers: Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation) and used for routing and forwarding of packets through the network; and Endpoint Identifiers (EIDs), which are assigned independently from the network topology, are used for numbering devices, and are aggregated along administrative boundaries. LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routeable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. Both RLOCs and EIDs are syntactically- identical to IP addresses; it is the semantics of how they are used that differs. This document describes the protocol that implements these functions. The database which stores the mappings between EIDs and RLOCs is Farinacci, et al. Expires September 4, 2011 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 explicitly a separate "module" to facilitate experimentation with a variety of approaches. One database design that is being developed and prototyped as part of the LISP working group work is [ALT]. Others that have been described but not implemented include [CONS], [EMACS], [RPMD], [NERD]. Finally, [LISP-MS], documents a general- purpose service interface for accessing a mapping database; this interface is intended to make the mapping database modular so that different approaches can be tried without the need to modify installed xTRs. Farinacci, et al. Expires September 4, 2011 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 3. Definition of Terms Provider Independent (PI) Addresses: PI addresses are 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: PA addresses are an a address block assigned to a site by each service provider to which a site connects. Typically, each block is sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] 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): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC 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): An EID is 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 Domain Name System (DNS) [RFC1034] lookup or Session Invitation Protocol (SIP) [RFC3261] 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 September 4, 2011 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 EID-prefix: An EID-prefix is a power-of-two 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: An 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): An ITR is 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: A 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): An ETR is 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 Farinacci, et al. Expires September 4, 2011 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. xTR: A 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: The EID-to-RLOC cache is 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: The EID-to-RLOC database is 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: Recursive tunneling occurs 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. Farinacci, et al. Expires September 4, 2011 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Reencapsulating Tunnels: Reencapsulating tunneling occurs 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 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 length of the address is 0 bytes following the 16-bit AFI value of 0. Negative Mapping Entry: A 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 data-probe is 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): A PITR is 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. Farinacci, et al. Expires September 4, 2011 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Proxy ETR (PETR): A 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. Client-side: a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in obtaining database map cache entries by sending Map-Request messages. Server-side: a term used in this document to indicate a connection initiation attempt is being accepted for a destination EID. The ETR(s) at the destination LISP site are the first to send Map- Replies to the source site initiating the connection. The ETR(s) at this destination site can obtain mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets. Farinacci, et al. Expires September 4, 2011 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. Another key LISP concept is the "Tunnel Router". A tunnel router 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 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 September 4, 2011 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 independent of 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 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). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document mandates that a maximum of two LISP headers can be prepended to a packet. 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 September 4, 2011 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. When an alternate mapping system is not in use, the Map-Request packet is routed through the underlying routing system. Otherwise, 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- Farinacci, et al. Expires September 4, 2011 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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 stored in the ITR's EID-to- RLOC mapping cache. Note that the map cache is an on-demand cache. An ITR will manage its map cache in such a way that optimizes for its resource constraints. 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 September 4, 2011 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and 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. This specification recommends that implementations support for one of the proposed fragmentation and reassembly schemes. These two existing schemes are detailed in Section 5.4. Farinacci, et al. Expires September 4, 2011 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires September 4, 2011 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 | | 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 | | r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires September 4, 2011 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 5.3. Tunnel Header Field Descriptions Inner Header: The inner header is the header on the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer Header: The outer header is a new 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: The UDP header contains a ITR selected source port when encapsulating a packet. See Section 6.5 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: The UDP checksum 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: The UDP length field is 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: The N bit 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 Farinacci, et al. Expires September 4, 2011 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 having a Nonce value present. L: The L bit 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: The E bit 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: The V bit is the Map-Version present bit. When this bit is set to 1, the N bit MUST be 0. Refer to Section 6.6.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: The I bit 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 September 4, 2011 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags: The flags field is a 3-bit field is reserved for future flag use. It is set to 0 on transmit and ignored on receipt. LISP Nonce: The LISP nonce field 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: The locator status bits field in the LISP header is 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 ITR/PITR 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 ETR/PETR decapsulation: Farinacci, et al. Expires September 4, 2011 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 o The inner header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the outer header Time to Live field, when the Time to Live field of the outer header is less than the Time to Live of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycle. This check is also performed when doing initial encapsulation when a packet comes to an ITR or PITR destined for a LISP site. o The inner header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the outer header Type of Service field (with one caveat, see below). Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header. 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. See Section 9.3 for TTL exception handling for traceroute packets. 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 This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism should be implemented. Both or neither can be used since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Farinacci, et al. Expires September 4, 2011 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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: 1. Define an architectural constant S for the maximum size of a packet, in bytes, an ITR would like to 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. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. 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. Farinacci, et al. Expires September 4, 2011 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 IANA Considerations Section 14.1 for details for possible 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 decapsulates 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. Farinacci, et al. Expires September 4, 2011 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 For example, a 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. Farinacci, et al. Expires September 4, 2011 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 | | + 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. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values. 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] uses 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 September 4, 2011 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 Map-Notify: 4 b'0100' 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|p| 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 September 4, 2011 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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.6.2 for details. p: This is the PITR bit. This bit is set to 1 when a PITR sends a Map-Request. Reserved: Set to 0 on transmission and ignored on receipt. IRC: This 5-bit field is the ITR-RLOC Count which encodes the additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- Address) pair must always be encoded. 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, and for a value of 1, there are 2 ITR-RLOC addresses encoded and so on up to 31 which encodes a total of 32 ITR-RLOC addresses. 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. Farinacci, et al. Expires September 4, 2011 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Source-EID-AFI: Address family of the "Source EID 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, an AFI value 0 is used and this field is of zero length. 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 of the sender of the Map-Request message. 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 a single "Record" 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] 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 Farinacci, et al. Expires September 4, 2011 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 an ITR/PITR selected 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 September 4, 2011 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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|S| 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. S: This is the Security bit. When set to 1 the field following the Mapping Protocol Data field will have the following format. The detailed format of the Authentication Data Content field can be found in [LISP-SEC] when AD Type is equal to 1. Farinacci, et al. Expires September 4, 2011 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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) No-Action: The map-cache is kept alive and packet encapsulation occurs. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. Farinacci, et al. Expires September 4, 2011 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 (3) Drop: A packet that matches this map-cache entry is dropped. 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 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.6.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 relative weight 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.5 for a suggested hash algorithm to distribute load across locators with same priority and equal weight values. 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. Farinacci, et al. Expires September 4, 2011 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 relative weight of total number of trees built 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, 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: set when the sender of a Map-Reply has a route to the locator in the locator data record. This receiver may find this useful to know when determining if the locator is reachable from the receiver. See also Section 6.4 for another way the R-bit may be used. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR. 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. Farinacci, et al. Expires September 4, 2011 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 A Map-Reply returns an EID-prefix with a prefix length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are globally-routable IP addresses of all ETRs for the LISP site. Each RLOC conveys status reachability but does not convey path reachability from a requesters perspective. Separate testing of path reachability is required, See Section 6.3 for details. 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 Farinacci, et al. Expires September 4, 2011 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. A negative Map- Reply is a Map-Reply with an empty locator-set. 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 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 Farinacci, et al. Expires September 4, 2011 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. 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: Farinacci, et al. Expires September 4, 2011 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 |M| 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: 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. M: This is the want-map-notify bit, when set to 1 an ETR is requesting for a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to an acknowledge receipt of a Map-Register message. Farinacci, et al. Expires September 4, 2011 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. 6.1.7. Map-Notify Message Format The usage details of the Map-Notify message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent inside a UDP packet with a source UDP port equal to 4342 and a destination port equal to the source port from the Map- Register message this Map-Notify message is responding to. The Map-Notify message format is: Farinacci, et al. Expires September 4, 2011 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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=3D4 | 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: Type: 4 (Map-Notify) The Map-Notify message has the same contents as a Map-Register message. See Map-Register section for field descriptions. 6.1.8. 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 September 4, 2011 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 |S| 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. S: This is the Security bit. When set to 1 the field following the Reserved field will have the following format. The detailed format of the Authentication Data Content field can be found in [LISP-SEC] when AD Type is equal to 1. Farinacci, et al. Expires September 4, 2011 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 ITR/PITR selected 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 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 Farinacci, et al. Expires September 4, 2011 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator Reachability Algorithms described in the next section. Farinacci, et al. Expires September 4, 2011 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. Farinacci, et al. Expires September 4, 2011 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 Farinacci, et al. Expires September 4, 2011 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 data flows bidirectionally between locators from different sites, a data-plane 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. Farinacci, et al. Expires September 4, 2011 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. 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 may include a mapping data record for its own database mapping information which contains the local EID-prefixes and RLOCs for its site. 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 Farinacci, et al. Expires September 4, 2011 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. EID Reachability within a LISP Site 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 is for an ETR to lose reachability to one or more of the EID prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own locator. And when the ETR is also an ITR, it can clear its locator-status-bit in the encapsulation data header. 6.5. 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: Farinacci, et al. Expires September 4, 2011 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 hashed 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.6. 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 which ITRs 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 Farinacci, et al. Expires September 4, 2011 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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.6.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. Farinacci, et al. Expires September 4, 2011 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. The new mappings are cached with a time to live equal to the TTL in the Map-Reply. 6.6.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for ETRs, 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 ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data to for the last minute. In particular, an ETR will send an SMR an ITR to which it has recently sent encapsulated data. 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. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. 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 ITR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected and the EID-prefix used is the one copied from the SMR message. If the source locator is the only locator in the cached locator-set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single locator has changed and may no longer be reachable to accept the Map-Request. 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map Versioning is used, described in Section 6.6.3, an SMR sender can detect if an ITR is using the most up to date database mapping. Farinacci, et al. Expires September 4, 2011 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. 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. 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. When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it MAY not send a SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all locators in the locator-set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case, they will send Map-Requests to obtain a map-cache entry. 6.6.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.6.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 September 4, 2011 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 ITR 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 September 4, 2011 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 7. Router Performance Considerations LISP is designed to be very hardware-based forwarding friendly. 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 consists of adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. o A packet's source address or interface the packet was received on can be used to select a VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. Farinacci, et al. Expires September 4, 2011 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 survey where tunnel routers can reside in the network. Farinacci, et al. Expires September 4, 2011 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 is the default behavior envisioned in the rest of this specification. 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. Another disadvantage of using anycast locators is the limited advertisement Farinacci, et al. Expires September 4, 2011 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 scope of /32 (or /128 for IPv6) routes. 8.3. ISP Provider-Edge (PE) Tunnel Routers Use of ISP PE routers as tunnel endpoint routers is not the typical deployment scenario envisioned in the specification. This section attempts to capture some of reasoning behind this preference of implementing LISP on CE routers. Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather than a site, 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 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. Other disadvantages include the difficulty in synchronizing path liveness updates between CE and PE routers. 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 September 4, 2011 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Refer to the LISP Mobility Architecture specification [LISP-MN] for more details. Farinacci, et al. Expires September 4, 2011 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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 September 4, 2011 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 13. Network Management Considerations Considerations for Network Management tools exist so the LISP protocol suite can be operationally managed. The mechanisms can be found in [LISP-MIB] and [LISP-LIG]. Farinacci, et al. Expires September 4, 2011 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 14. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the LISP specification, in accordance with BCP 26 and RFC 5226 [RFC5226]. There are two name spaces in LISP that require registration: o LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols. o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Consensus", "Experimental Use", "First Come First Served". 14.1. LISP Address Type Codes Instance ID type codes have a range from 0 to 15, of which 0 and 1 have been allocated [LCAF]. New Type Codes MUST be allocated starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. Type Codes 11 - 15 are available on a First Come First Served policy. The following codes have been allocated: Type 0: Null Body Type Type 1: AFI List Type See [LCAF] for details for other possible unapproved address encodings. The unapproved LCAF encodings are an area for further study and experimentation. 14.2. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for LISP data-plane and control-plane operation, respectively. Farinacci, et al. Expires September 4, 2011 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 15. References 15.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [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. [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. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [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. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. Farinacci, et al. Expires September 4, 2011 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 [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. [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-05.txt (work in progress), October 2010. [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. [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. [INTERWORK] Farinacci, et al. Expires September 4, 2011 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt (work in progress), March 2011. [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-farinacci-lisp-lcaf-04.txt (work in progress), October 2010. [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, "Renumbering: Threat or Menace?", Usenix , September 1996. [LISP-LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-ietf-lisp-lig-01.txt (work in progress), October 2010. [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-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", draft-ietf-lisp-mib-01.txt (work in progress), March 2011. [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP Mobility Architecture", draft-meyer-lisp-mn-04.txt (work in progress), October 2010. [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-07.txt (work in progress), March 2011. [LISP-SEC] Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-maino-lisp-sec-00.txt (work in progress), February 2011. [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", Farinacci, et al. Expires September 4, 2011 [Page 72] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 draft-ietf-lisp-multicast-04.txt (work in progress), October 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. [VERSIONING] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Versioning", draft-iannone-lisp-mapping-versioning-02.txt (work in progress), July 2010. Farinacci, et al. Expires September 4, 2011 [Page 73] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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, Terry Manderson, 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, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, and Chris White. 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 September 4, 2011 [Page 74] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-10.txt o Posted March 2011. o Add p-bit to Map-Request so there is documentary reasons to know when a PITR has sent a Map-Request to an ETR. o Add Map-Notify message which is used to acknowledge a Map-Register message sent to a Map-Server. o Add M-bit to the Map-Register message so an ETR that wants an acknowledgment for the Map-Register can request one. o Add S-bit to the ECM and Map-Reply messages to describe security data that can be present in each message. Then refer to [LISP-SEC] for expansive details. o Add Network Management Considerations section and point to the MIB and LIG drafts. o Remove the word "simple" per Yakov's comments. B.2. Changes to draft-ietf-lisp-09.txt o Posted October 2010. o Add to IANA Consideration section about the use of LCAF Type values that accepted and maintained by the IANA registry and not the LCAF specification. o Indicate that implementations should be able to receive LISP control messages when either UDP port is 4342, so they can be robust in the face of intervening NAT boxes. o Add paragraph to SMR section to indicate that an ITR does not need to respond to an SMR-based Map-Request when it has no map-cache entry for the SMR source's EID-prefix. B.3. Changes to draft-ietf-lisp-08.txt o Posted August 2010. o In section 6.1.6, remove statement about setting TTL to 0 in Map- Register messages. Farinacci, et al. Expires September 4, 2011 [Page 75] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 o Clarify language in section 6.1.5 about Map-Replying to Data- Probes or Map-Requests. o Indicate that outer TTL should only be copied to inner TTL when it is less than inner TTL. o Indicate a source-EID for RLOC-probes are encoded with an AFI value of 0. o Indicate that SMRs can have a global or per SMR destination rate- limiter. o Add clarifications to the SMR procedures. o Add definitions for "client-side" and 'server-side" terms used in this specification. o Clear up language in section 6.4, last paragraph. o Change ACT of value 0 to "no-action". This is so we can RLOC- probe a PETR and have it return a Map-Reply with a locator-set of size 0. The way it is spec'ed the map-cache entry has action "dropped". Drop-action is set to 3. o Add statement about normalizing locator weights. o Clarify R-bit definition in the Map-Reply locator record. o Add section on EID Reachability within a LISP site. o Clarify another disadvantage of using anycast locators. o Reworded Abstract. o Change section 2.0 Introduction to remove obsolete information such as the LISP variant definitions. o Change section 5 title from "Tunneling Details" to "LISP Encapsulation Details". o Changes to section 5 to include results of network deployment experience with MTU. Recommend that implementations use either the stateful or stateless handling. o Make clarification wordsmithing to Section 7 and 8. o Identify that if there is one locator in the locator-set of a map- cache entry, that an SMR from that locator should be responded to Farinacci, et al. Expires September 4, 2011 [Page 76] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 by sending the the SMR-invoked Map-Request to the database mapping system rather than to the RLOC itself (which may be unreachable). o When describing Unicast and Multicast Weights indicate the the values are relative weights rather than percentages. So it doesn't imply the sum of all locator weights in the locator-set need to be 100. o Do some wordsmithing on copying TTL and TOS fields. o Numerous wordsmithing changes from Dave Meyer. He fine toothed combed the spec. o Removed Section 14 "Prototype Plans and Status". We felt this type of section is no longer appropriate for a protocol specification. o Add clarification text for the IRC description per Damien's commentary. o Remove text on copying nonce from SMR to SMR-invoked Map- Request per Vina's comment about a possible DoS vector. o Clarify (S/2 + H) in the stateless MTU section. o Add text to reflect Damien's comment about the description of the "ITR-RLOC Address" field in the Map-Request. that the list of RLOC addresses are local addresses of the Map-Requester. B.4. 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. Farinacci, et al. Expires September 4, 2011 [Page 77] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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! 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. Farinacci, et al. Expires September 4, 2011 [Page 78] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 o Added the definition for "LISP site" to the Definition of Terms" section. B.5. 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. Farinacci, et al. Expires September 4, 2011 [Page 79] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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.6. 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.7. 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 Farinacci, et al. Expires September 4, 2011 [Page 80] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. Farinacci, et al. Expires September 4, 2011 [Page 81] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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.8. 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. Farinacci, et al. Expires September 4, 2011 [Page 82] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 B.9. 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 [LISP-MN]. B.10. 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.11. 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 September 4, 2011 [Page 83] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 4, 2011 [Page 84] =0C --Apple-Mail-26-910310922 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-26-910310922 Content-Disposition: attachment; filename=rfcdiff-lisp-09-to-10.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-09-to-10.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-09.txt draft-ietf-lisp-10.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: April 14, September 4, 2011                                      D. Lewis
                                                           cisco Systems
                                                        October 11, 2010
                                                           March 3, 2011

                 Locator/ID Separation Protocol (LISP)
                           draft-ietf-lisp-09
                           draft-ietf-lisp-10

Abstract

   This draft describes a network-based protocol that enables separation
   of IP addresses into two new numbering spaces: Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  No changes are required to
   either host protocol stacks or to the "core" of the Internet
   infrastructure.  LISP can be incrementally deployed, without a "flag
   day", and offers traffic engineering, multi-homing, and mobility
   benefits even to early adopters, when there are relatively few LISP-
   capable sites.

   Design and development of LISP was largely motivated by the problem
   statement produced by the October, 2006 IAB Routing and Addressing
   Workshop.

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 14, September 4, 2011.

Copyright Notice

   Copyright (c) 2010 2011 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  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 17
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 22
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 23
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 24
     5.5.  Using Virtualization and Segmentation with LISP  . . . . . 24
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 26
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 28
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 28
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 30
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 32
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 35 36
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 38
       6.1.7.  Map-Notify Message Format  . . . . . . . . . . . . . . 40
       6.1.8.  Encapsulated Control Message Format  . . . . . . . . . 39 41
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 41 43
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 42 45
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 45 47
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 46 48
     6.4.  EID Reachability within a LISP Site  . . . . . . . . . . . 47 49
     6.5.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 47 49
     6.6.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 48 50
       6.6.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 49 51
       6.6.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 49 52
       6.6.3.  Database Map Versioning  . . . . . . . . . . . . . . . 51 53
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 52 55
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 53 56
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 54 57
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 54 57
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 55 58
     8.4.  LISP Functionality with Conventional NATs  . . . . . . . . 55 58
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 56 59
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 57 60
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 57 60
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 57 60
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 59 62
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 59 62
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 59 62
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 59 62
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 61 64
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 61 64
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 63 66
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 64 67
   13. Network Management Considerations  . . . . . . . . . . . . . . 68
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 65
     13.1. 69
     14.1. LISP Address Type Codes  . . . . . . . . . . . . . . . . . 65
     13.2. 69
     14.2. LISP UDP Port Numbers  . . . . . . . . . . . . . . . . . . 65
   14. 69
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
     14.1. 70
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 66
     14.2. 70
     15.2. Informative References . . . . . . . . . . . . . . . . . . 67 71
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 70 74
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 71 75
     B.1.  Changes to draft-ietf-lisp-09.txt draft-ietf-lisp-10.txt  . . . . . . . . . . . . 71 75
     B.2.  Changes to draft-ietf-lisp-08.txt draft-ietf-lisp-09.txt  . . . . . . . . . . . . 71 75
     B.3.  Changes to draft-ietf-lisp-07.txt draft-ietf-lisp-08.txt  . . . . . . . . . . . . 73 75
     B.4.  Changes to draft-ietf-lisp-06.txt draft-ietf-lisp-07.txt  . . . . . . . . . . . . 74 77
     B.5.  Changes to draft-ietf-lisp-05.txt draft-ietf-lisp-06.txt  . . . . . . . . . . . . 75 79
     B.6.  Changes to draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt  . . . . . . . . . . . . 76 80
     B.7.  Changes to draft-ietf-lisp-03.txt draft-ietf-lisp-04.txt  . . . . . . . . . . . . 78 80
     B.8.  Changes to draft-ietf-lisp-02.txt draft-ietf-lisp-03.txt  . . . . . . . . . . . . 78 82
     B.9.  Changes to draft-ietf-lisp-01.txt draft-ietf-lisp-02.txt  . . . . . . . . . . . . 78 83
     B.10. Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 83
     B.11. Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 79 83
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80 84

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

   This document describes the Locator/Identifier Separation Protocol
   (LISP), which provides a set of functions for routers to exchange
   information used to map from non-routeable Endpoint Identifiers
   (EIDs) to routeable Routing Locators (RLOCs).  It also defines a
   mechanism for these LISP routers to encapsulate IP packets addressed
   with EIDs for transmission across an Internet that uses RLOCs for
   routing and forwarding.

   Creation of LISP was initially motivated by discussions during the
   IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
   October, 2006 (see [RFC4984]).  A key conclusion of the workshop was
   that the Internet routing and addressing system was not scaling well
   in the face of the explosive growth of new sites; one reason for this
   poor scaling is the increasing number of multi-homed and other sites
   that cannot be addressed as part of topologically- or provider-based
   aggregated prefixes.  Additional work that more completely described
   the problem statement may be found in [RADIR].

   A basic observation, made many years ago in early networking research
   such as that documented in [CHIAPPA] and [RFC4984], is that using a
   single address field for both identifying a device and for
   determining where it is topologically located in the network requires
   optimization along two conflicting axes: for routing to be efficient,
   the address must be assigned topologically; for collections of
   devices to be easily and effectively managed, without the need for
   renumbering in response to topological change (such as that caused by
   adding or removing attachment points to the network or by mobility
   events), the address must explicitly not be tied to the topology.

   The approach that LISP takes to solving the routing scalability
   problem is to replace IP addresses with two new types of numbers:
   Routing Locators (RLOCs), which are topologically assigned to network
   attachment points (and are therefore amenable to aggregation) and
   used for routing and forwarding of packets through the network; and
   Endpoint Identifiers (EIDs), which are assigned independently from
   the network topology, are used for numbering devices, and are
   aggregated along administrative boundaries.  LISP then defines
   functions for mapping between the two numbering spaces and for
   encapsulating traffic originated by devices using non-routeable EIDs
   for transport across a network infrastructure that routes and
   forwards using RLOCs.  Both RLOCs and EIDs are syntactically-
   identical to IP addresses; it is the semantics of how they are used
   that differs.

   This document describes the protocol that implements these functions.
   The database which stores the mappings between EIDs and RLOCs is
   explicitly a separate "module" to facilitate experimentation with a
   variety of approaches.  One database design that is being developed
   and prototyped as part of the LISP working group work is [ALT].
   Others that have been described but not implemented include [CONS],
   [EMACS], [RPMD], [NERD].  Finally, [LISP-MS], documents a general-
   purpose service interface for accessing a mapping database; this
   interface is intended to make the mapping database modular so that
   different approaches can be tried without the need to modify
   installed xTRs.

3.  Definition of Terms

   Provider Independent (PI) Addresses:   PI addresses are 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:   PA addresses are an a address
      block assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider Classless Inter-Domain Routing (CIDR) [RFC4632] 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):   A RLOC is an IPv4 or IPv6 address of an
      egress tunnel router (ETR).  A RLOC 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):   An EID is 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 Domain Name System (DNS) [RFC1034]
      lookup or Session Invitation Protocol (SIP) [RFC3261] 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:   An EID-prefix is a power-of-two 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:   An 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):   An ITR is 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:   A 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):   An ETR is 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:   A TE-ETR is an ETR that is deployed in a service provider
      network that strips an outer LISP header for Traffic Engineering
      purposes.

   xTR:   A 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:   The EID-to-RLOC cache is 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:   The EID-to-RLOC database is 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:   Recursive tunneling occurs 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:   Reencapsulating tunneling occurs 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 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 length of the address is 0 bytes
      following the 16-bit AFI value of 0.

   Negative Mapping Entry:   A 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 data-probe is 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):   A PITR is 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):   A 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.

   Client-side:  a term used in this document to indicate a connection
      initiation attempt by an EID.  The ITR(s) at the LISP site are the
      first to get involved in obtaining database map cache entries by
      sending Map-Request messages.

   Server-side:  a term used in this document to indicate a connection
      initiation attempt is being accepted for a destination EID.  The
      ETR(s) at the destination LISP site are the first to send Map-
      Replies to the source site initiating the connection.  The ETR(s)
      at this destination site can obtain mappings by gleaning
      information from Map-Requests, Data-Probes, or encapsulated
      packets.

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.

   Another key LISP concept is the "Tunnel Router".  A tunnel router
   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 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
      independent of 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 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).

   In order to avoid excessive packet overhead as well as possible
   encapsulation loops, this document mandates that a maximum of two
   LISP headers can be prepended to a packet.  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, but the source and destination can be
      located anywhere in LISP site.

   o  Map-Requests can be sent on the underlying routing system topology
      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.  When an alternate mapping system is not in use, the Map-Request
       packet is routed through the underlying routing system.
       Otherwise, 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
       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 stored in the ITR's EID-to-
       RLOC mapping cache.  Note that the map cache is an on-demand
       cache.  An ITR will manage its map cache in such a way that
       optimizes for its resource constraints.

   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.

5.  LISP Encapsulation Details

   Since additional tunnel headers are prepended, the packet becomes
   larger and 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.

   This specification recommends that implementations support for one of
   the proposed fragmentation and reassembly schemes.  These 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|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                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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|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   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Tunnel Header Field Descriptions

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

   Outer Header:  The outer header is a new 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:  The UDP header contains a ITR selected source port when
      encapsulating a packet.  See Section 6.5 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:  The UDP checksum 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:  The UDP length field is 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: The N bit 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: The L bit 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: The E bit 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: The V bit is the Map-Version present bit.  When this bit is set to
      1, the N bit MUST be 0.  Refer to Section 6.6.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: The I bit 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:  The flags field is a 3-bit field is reserved for future flag
      use.  It is set to 0 on transmit and ignored on receipt.

   LISP Nonce:  The LISP nonce field 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:  The locator status bits field in the LISP
      header is 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 ITR/PITR 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 ETR/PETR decapsulation:

   o  The inner header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the outer header Time to Live
      field, when the Time to Live field of the outer header is less
      than the Time to Live of the inner header.  Failing to perform
      this check can cause the Time to Live of the inner header to
      increment across encapsulation/decapsulation cycle.  This check is
      also performed when doing initial encapsulation when a packet
      comes to an ITR or PITR destined for a LISP site.

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

   Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate
   after decapsulating, the net effect of this is that the new outer
   header will carry the same Time to Live as the old outer header.

   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.  See
   Section 9.3 for TTL exception handling for traceroute packets.

   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

   This section proposes two simple mechanisms to deal with packets that exceed
   the path MTU between the ITR and ETR.

   It is left to the implementor to decide if the stateless or stateful
   mechanism should be implemented.  Both or neither can be used since
   it is a local decision in the ITR regarding how to deal with MTU
   issues, and 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:

   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would like to 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.  The size of the encapsulated fragments is then
   (S/2 + H), which is less than the ITR's estimate of the path MTU
   between the ITR and its correspondent ETR.

   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.

   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 IANA Considerations Section 13.1 14.1 for details for
   possible 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 decapsulates 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.

   For example, a 802.1Q VLAN tag or VPN identifier could be used as a
   24-bit Instance ID.

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.
   Implementations MUST be prepared to accept packets when either the
   source port or destination UDP port is set to 4342 due to NATs
   changing port number values.

   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] uses 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 Map-Notify:                   4    b'0100'
       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| |A|M|P|S|p|     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:

   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.6.2 for details.

   p: This is the PITR bit.  This bit is set to 1 when a PITR sends a
      Map-Request.

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

   IRC:  This 5-bit field is the ITR-RLOC Count which encodes the
      additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
      present in this message.  At least one (ITR-RLOC-AFI, ITR-RLOC-
      Address) pair must always be encoded.  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, and for a value of 1, there are 2 ITR-RLOC addresses encoded
      and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.

   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.

   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, an AFI value 0 is used and this field is of zero
      length.

   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 of the
      sender of the Map-Request message.

   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 a
      single "Record" 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] 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.
   In all cases, the UDP source port number for the Map-Request message
   is an ITR/PITR selected 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| |P|E|S|          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.

   Record Count:  The number of records in this reply message.  A record

   S: This 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 Security bit.  When set in a Data-Probe packet or a 64-bit value
      from to 1 the Map-Request is echoed in this Nonce field of following the Map-
      Reply.

   Record TTL:  The time in minutes
      Mapping Protocol Data field will have the recipient following format.  The
      detailed format of the Authentication Data Content field can be
      found in [LISP-SEC] when AD Type is equal to 1.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    AD Type    |       Authentication Data Content . . .       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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) No-Action:  The map-cache is kept alive and packet
         encapsulation occurs.

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

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

      (3) Drop:  A packet that matches this map-cache entry is dropped.

   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
      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.6.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 relative weight 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.5 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.

   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 relative
      weight of total number of trees built 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, 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: set when the sender of a Map-Reply has a route to the locator in
      the locator data record.  This receiver may find this useful to
      know when determining if the locator is reachable from the
      receiver.  See also Section 6.4 for another way the R-bit may be
      used.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR.  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

   A Map-Reply returns an EID-prefix with a prefix length that is less
   than or equal to the EID being requested.  The EID being requested is
   either from the destination field of an IP header of a Data-Probe or
   the EID record of a Map-Request.  The RLOCs in the Map-Reply are
   globally-routable IP addresses of all ETRs for the LISP site.  Each
   RLOC conveys status reachability but does not convey path
   reachability from a requesters perspective.  Separate testing of path
   reachability is required, See Section 6.3 for details.

   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 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.  A negative Map-
   Reply is a Map-Reply with an empty locator-set.  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 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.

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                 |               |M| 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:

   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.

   M: This is the want-map-notify bit, when set to 1 an ETR is
      requesting for a Map-Notify message to be returned in response to
      sending a Map-Register message.  The Map-Notify message sent by a
      Map-Server is used to an acknowledge receipt of a Map-Register
      message.

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

6.1.7.  Map-Notify Message Format

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

   The message is sent inside a UDP packet with a source UDP port equal
   to 4342 and a destination port equal to the source port from the Map-
   Register message this Map-Notify message is responding to.

   The Map-Notify 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=4 |              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:

   Type:   4 (Map-Notify)

   The Map-Notify message has the same contents as a Map-Register
   message.  See Map-Register section for field descriptions.

6.1.8.  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 | |S|                  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 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.

   S:   This is the Security bit.  When set to 1 the field following the
      Reserved field will have the following format.  The detailed
      format of the Authentication Data Content field can be found in
      [LISP-SEC] when AD Type is equal to 1.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 bits after the reserved field. 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    AD Type    |       Authentication Data Content . . .       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 ITR/PITR selected
      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 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
      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 provides reachability information for RLOCs.
   Note that reachability is not part of the mapping system and is
   determined 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 data flows bidirectionally between locators from different
   sites, a simple data-plane 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.

   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 may include a mapping data record
   for its own database mapping information which contains the local
   EID-prefixes and RLOCs for its site.

   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
   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.  EID Reachability within a LISP Site

   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 is for an ETR to lose
   reachability to one or more of the EID prefixes within its own site.
   When this occurs when the ETR sends Map-Replies, it can clear the
   R-bit associated with its own locator.  And when the ETR is also an
   ITR, it can clear its locator-status-bit in the encapsulation data
   header.

6.5.  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 hashed 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.6.  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 which
   ITRs 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.6.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.  The new mappings
       are cached with a time to live equal to the TTL in the Map-Reply.

6.6.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for ETRs, 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 ETRs don't keep track of remote ITRs that have cached their
   mappings, they do not know which ITRs need to have their mappings
   updated.  As a result, an ETR will solicit Map-Requests (called an
   SMR message) from those sites to which it has been sending
   encapsulated data to for the last minute.  In particular, an ETR will
   send an SMR an ITR to which it has recently sent encapsulated data.

   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.  Rate-limiting can be implemented as a global rate-
   limiter or one rate-limiter per SMR destination.

   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 ITR which receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message or to the mapping database system.  A newly allocated
       random nonce is selected and the EID-prefix used is the one
       copied from the SMR message.  If the source locator is the only
       locator in the cached locator-set, the remote ITR SHOULD send a
       Map-Request to the database mapping system just in case the
       single locator has changed and may no longer be reachable to
       accept the Map-Request.

   3.  The remote ITR MUST rate-limit the Map-Request until it gets a
       Map-Reply while continuing to use the cached mapping.  When Map
       Versioning is used, described in Section 6.6.3, an SMR sender can
       detect if an ITR is using the most up to date database mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message that has a nonce from the
       SMR-invoked Map-Request.  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.
   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.

   When an ITR receives an SMR-based Map-Request for which it does not
   have a cached mapping for the EID in the SMR message, it MAY not send
   a SMR-invoked Map-Request.  This scenario can occur when an ETR sends
   SMR messages to all locators in the locator-set it has stored in its
   map-cache but the remote ITRs that receive the SMR may not be sending
   packets to the site.  There is no point in updating the ITRs until
   they need to send, in which case, they will send Map-Requests to
   obtain a map-cache entry.

6.6.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.6.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 ITR 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.  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 consists of adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Routers that support GRE
      tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
      support this action.

   o  A packet's source address or interface the packet was received on
      can be used to select a VRF (Virtual Routing/Forwarding).  The
      VRF's routing table 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 survey 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 is the default
   behavior envisioned in the rest of this specification.

   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.  Another
   disadvantage of using anycast locators is the limited advertisement
   scope of /32 (or /128 for IPv6) routes.

8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers is not the typical
   deployment scenario envisioned in the specification.  This section
   attempts to capture some of reasoning behind this preference of
   implementing LISP on CE routers.

   Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather
   than a site, 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 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.  Other disadvantages
   include the difficulty in synchronizing path liveness updates between
   CE and PE routers.

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

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

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.  Network Management Considerations

   Considerations for Network Management tools exist so the LISP
   protocol suite can be operationally managed.  The mechanisms can be
   found in [LISP-MIB] and [LISP-LIG].

14.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the LISP
   specification, in accordance with BCP 26 and RFC 5226 [RFC5226].

   There are two name spaces in LISP that require registration:

   o  LISP IANA registry allocations should not be made for purposes
      unrelated to LISP routing or transport protocols.

   o  The following policies are used here with the meanings defined in
      BCP 26: "Specification Required", "IETF Consensus", "Experimental
      Use", "First Come First Served".

13.1.

14.1.  LISP Address Type Codes

   Instance ID type codes have a range from 0 to 15, of which 0 and 1
   have been allocated [LCAF].  New Type Codes MUST be allocated
   starting at 2.  Type Codes 2 - 10 are to be assigned by IETF Review.
   Type Codes 11 - 15 are available on a First Come First Served policy.

   The following codes have been allocated:

   Type 0:  Null Body Type

   Type 1:  AFI List Type

   See [LCAF] for details for other possible unapproved address
   encodings.  The unapproved LCAF encodings are an area for further
   study and experimentation.

13.2.

14.2.  LISP UDP Port Numbers

   The IANA registry has allocated UDP port numbers 4341 and 4342 for
   LISP data-plane and control-plane operation, respectively.

14.

15.  References

14.1.

15.1.  Normative References

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

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

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

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

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

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

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 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.

   [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-04.txt
              draft-ietf-lisp-alt-05.txt (work in progress), April
              October 2010.

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

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

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

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

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

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

   [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-MIB]
              Schudel, G., Jain, A., and V. Moreno, "LISP MIB",
              draft-ietf-lisp-mib-01.txt (work in progress), March 2011.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-05.txt draft-meyer-lisp-mn-04.txt (work
              in progress), October 2010.

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

   [LISP-SEC]
              Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O.
              Bonaventure, "LISP-Security (LISP-SEC)",
              draft-maino-lisp-sec-00.txt (work in progress),
              February 2011.

   [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-04.txt (work in progress),
              October 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.

   [VERSIONING]
              Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
              Versioning", draft-iannone-lisp-mapping-versioning-02.txt
              (work in progress), July 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, Terry
   Manderson, 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, Dimitri
   Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, and Vina
   Ermagan.
   Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, and Chris
   White.

   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-10.txt

   o  Posted March 2011.

   o  Add p-bit to Map-Request so there is documentary reasons to know
      when a PITR has sent a Map-Request to an ETR.

   o  Add Map-Notify message which is used to acknowledge a Map-Register
      message sent to a Map-Server.

   o  Add M-bit to the Map-Register message so an ETR that wants an
      acknowledgment for the Map-Register can request one.

   o  Add S-bit to the ECM and Map-Reply messages to describe security
      data that can be present in each message.  Then refer to
      [LISP-SEC] for expansive details.

   o  Add Network Management Considerations section and point to the MIB
      and LIG drafts.

   o  Remove the word "simple" per Yakov's comments.

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

   o  Posted October 2010.

   o  Add to IANA Consideration section about the use of LCAF Type
      values that accepted and maintained by the IANA registry and not
      the LCAF specification.

   o  Indicate that implementations should be able to receive LISP
      control messages when either UDP port is 4342, so they can be
      robust in the face of intervening NAT boxes.

   o  Add paragraph to SMR section to indicate that an ITR does not need
      to respond to an SMR-based Map-Request when it has no map-cache
      entry for the SMR source's EID-prefix.

B.2.

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

   o  Posted August 2010.

   o  In section 6.1.6, remove statement about setting TTL to 0 in Map-
      Register messages.

   o  Clarify language in section 6.1.5 about Map-Replying to Data-
      Probes or Map-Requests.

   o  Indicate that outer TTL should only be copied to inner TTL when it
      is less than inner TTL.

   o  Indicate a source-EID for RLOC-probes are encoded with an AFI
      value of 0.

   o  Indicate that SMRs can have a global or per SMR destination rate-
      limiter.

   o  Add clarifications to the SMR procedures.

   o  Add definitions for "client-side" and 'server-side" terms used in
      this specification.

   o  Clear up language in section 6.4, last paragraph.

   o  Change ACT of value 0 to "no-action".  This is so we can RLOC-
      probe a PETR and have it return a Map-Reply with a locator-set of
      size 0.  The way it is spec'ed the map-cache entry has action
      "dropped".  Drop-action is set to 3.

   o  Add statement about normalizing locator weights.

   o  Clarify R-bit definition in the Map-Reply locator record.

   o  Add section on EID Reachability within a LISP site.

   o  Clarify another disadvantage of using anycast locators.

   o  Reworded Abstract.

   o  Change section 2.0 Introduction to remove obsolete information
      such as the LISP variant definitions.

   o  Change section 5 title from "Tunneling Details" to "LISP
      Encapsulation Details".

   o  Changes to section 5 to include results of network deployment
      experience with MTU.  Recommend that implementations use either
      the stateful or stateless handling.

   o  Make clarification wordsmithing to Section 7 and 8.

   o  Identify that if there is one locator in the locator-set of a map-
      cache entry, that an SMR from that locator should be responded to
      by sending the the SMR-invoked Map-Request to the database mapping
      system rather than to the RLOC itself (which may be unreachable).

   o  When describing Unicast and Multicast Weights indicate the the
      values are relative weights rather than percentages.  So it
      doesn't imply the sum of all locator weights in the locator-set
      need to be 100.

   o  Do some wordsmithing on copying TTL and TOS fields.

   o  Numerous wordsmithing changes from Dave Meyer.  He fine toothed
      combed the spec.

   o  Removed Section 14 "Prototype Plans and Status".  We felt this
      type of section is no longer appropriate for a protocol
      specification.

   o  Add clarification text for the IRC description per Damien's
      commentary.

   o  Remove text on copying nonce from SMR to SMR-invoked Map- Request
      per Vina's comment about a possible DoS vector.

   o  Clarify (S/2 + H) in the stateless MTU section.

   o  Add text to reflect Damien's comment about the description of the
      "ITR-RLOC Address" field in the Map-Request. that the list of RLOC
      addresses are local addresses of the Map-Requester.

B.3.

B.4.  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.

B.4.

B.5.  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=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.5.

B.6.  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.6.

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

B.8.  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.8.

B.9.  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 [LISP-MN].

B.9.

B.10.  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.10.

B.11.  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-26-910310922 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Feb 23, 2011, at 10:27 AM, Dino Farinacci wrote: > Here are some minor changes to the main LISP draft. We believe the > security-bit is general enough to adopt any security scheme. But > Fabio et al should be publishing a security draft by the end of this > week or early next week to propose a way of signing Map-Replies. > > Changes to draft-ietf-lisp-10.txt: > > o Posted March 2011. > > o Add p-bit to Map-Request so there is documentary reasons to know > when a PITR has sent a Map-Request to an ETR. > > o Add Map-Notify message which is used to acknowledge a Map- > Register > message sent to a Map-Server. > > o Add M-bit to the Map-Register message so an ETR that wants an > acknowledgment for the Map-Register can request one. > > o Add S-bit to the ECM and Map-Reply messages to describe security > data that can be present in each message. Then refer to > [LISP-SEC] for expansive details. > > o Add Network Management Considerations section and point to the > MIB > and LIG drafts. > > o Remove the word "simple" per Yakov's comments. > > We'd like to give a 10 day review period so we can post a new > version, if there are no objections, on March 4th. > > Find enclosed a diff file and a text draft. > > Thanks, > Dino/Vince/Darrel/Dave > > > > > > > > --Apple-Mail-26-910310922-- From vaf@cisco.com Fri Mar 4 09:37:31 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A81128B23E for ; Fri, 4 Mar 2011 09:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.218 X-Spam-Level: X-Spam-Status: No, score=-8.218 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_COMMENT_SAVED_URL=0.114, 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 i6VKvzzQcLmI for ; Fri, 4 Mar 2011 09:37:26 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 34C943A68B9 for ; Fri, 4 Mar 2011 09:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=125650; q=dns/txt; s=iport; t=1299260315; x=1300469915; h=date:from:to:subject:message-id:mime-version; bh=7k8lbvXtN03QXECh1+ZyQE+54FOonddhKPH+ztabhco=; b=GM5yxwNZsiMo2iRcN22imkNdD62+NJNzLf++rF48f2couAf/UyhEMa4A ENzyUe41A5R9t41i0X7Yj6uKDhwTvgvkxkYDYVMapGPY8bPszJ9Vs5Ha3 4BosneGp0rHUKVIl7xxCj6bvb879GgjVOFRKj1/F/+dtxPKpLFllaNY/P w=; X-Files: rfcdiff-ms-06-to-07.html, draft-ietf-lisp-ms-07.txt : 90200, 29388 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABaycE2rRN+K/2dsb2JhbACmC1h0o1WOEI1ahWEEhRw X-IronPort-AV: E=Sophos;i="4.62,264,1297036800"; d="txt'?html'217?scan'217,208,217";a="273775802" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2011 17:38:16 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p24HcGFf020197 for ; Fri, 4 Mar 2011 17:38:16 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 799A7DBA3C6; Fri, 4 Mar 2011 09:38:21 -0800 (PST) Date: Fri, 4 Mar 2011 09:38:21 -0800 From: Vince Fuller To: lisp@ietf.org Message-ID: <20110304173821.GA81604@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] Changes updates to draft-ietf-lisp-ms 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, 04 Mar 2011 17:37:31 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello- Attached please find a proposed version 7 of the LISP Map Server draft, along with an "rfcdiff" from version 6. Changes are fairly minor and consist mostly of editorial fixes and additions of new text to keep consistent with the base LISP specification: - Describe use of "Map-Notify" message during ETR-to-MS registration. - Describe "proxy-map-reply" service by MS on behalf of ETR. This was previously defined in the base LISP spec but not mentioned in the MS spec. - Describe Map Server and Map Resolver message processing for Encapsulated Control Messages received with security information as defined by the upcoming LISP-SEC draft. - Clarify that a Encapsulated Map-Request is a Map-Request contained within an Encapsulated Control Message. - State that co-located MR/MS functionality is the common case rather than the exceptional case (based on experience with LISP pilot network). - Fix incorrect SHA-1/HMAC reference from RFC2404 to RFC2104. - Minor editorial/spelling corrections. This message is intended to start a one-week review period prior to publication of draft-ietf-lisp-ms-07 to the Internet-Drafts repository before the Prague IETF meeting. Thanks! Vince & Dino --3MwIy2ne0vdjdPXF Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-ms-06-to-07.html" Content-Transfer-Encoding: quoted-printable wdiff draft-ietf-lisp-ms-06.txt draft-ietf-lisp-ms-07= .txt 
Network Working Group                                          V. Fuller
Internet-Draft                                              D. Farinacci
Intended status: Experimental                              cisco Systems
Expires: April 21, September 5, 2011                                 March 4=
, 2011                                 October 18, 2010

                            LISP Map Server
                       draft-ietf-lisp-ms-06.tx=
t
                       draft-ietf-lisp-ms-07.=
txt

Abstract

   This draft describes the LISP Map-Server (LISP-MS), a computing
   system which provides a simple simplified LISP protocol i=
nterface 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 reduce i=
mplementation and
   operation
   operational complexity of =
LISP Ingress Tunnel Routers (ITRs) and
   Egress Tunnel Routers (ETRs), the devices that implement the "edge"
   of the LISP infrastructure and which connect directly to LISP-capable
   Internet end sites.

Status of this Memo

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

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

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

   This Internet-Draft will expire on April 21,=
 September 5,=
 2011.

Copyright Notice

   Copyright (c) 2010 <=
font color=3D"green">2011 IETF Trust and the persons identi=
fied as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Interactions With Other LISP Components  . . . . . . . . . . .  6
     4.1.  ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . .  6
     4.2.  ETR/Map-Server EID Prefix Registration . . . . . . . . . .  7
     4.3.  Map-Server Processing  . . . . . . . . . . . . . . . . . .  8
     4.4.  Map-Resolver Processing  . . . . . . . . . . . . . . . . .  8
       4.4.1.  Anycast Map-Resolver Operation . . . . . . . . . . . .  9 10<=
/font>
   5.  Open Issues and Considerations . . . . . . . . . . . . . . . . 10 11<=
/font>
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11 12<=
/font>
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13<=
/font>
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12 13<=
/font>
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12 13<=
/font>
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13 15<=
/font>
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 16<=
/font>

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

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

   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 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 authoritative source (typically, an
      ETR, 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 carried within an
      Encapsulated Control Message, which has 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 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.  In addition to the set
      of EID-prefixes to register, the message includes one or more
      RLOCs to be be used by the Map-Server when forwarding Map-Requests
      (re-formatted as Encapsulated Map-Requests) received through the
      database mapping system.  An ETR may re=
quest that the Map-Server
      answer Map-Requests on its behalf by setting the "proxy-map-reply"
      flag (P-bit) in the message.

   Map-Notify message:   a LISP message sent by a Map-Server to an ETR
      to confirm that a Map-Register has been received and processed.
      An ETR requests that a Map-Notify be returned by setting the
      "want-map-notify" or "M" bit in the Map-Register message.

   For definitions of other terms, notably Map-Request, Map-Reply,
   Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
   consult the LISP specification [LISP].

3.  Basic Overview

   A Map-Server is a device which publishes EID-prefix information on
   behalf of ETRs and connects to the LISP distributed mapping database
   system to help answer LISP Map-Requests seeking the RLOCs for those
   EID-prefixes.  To publish its EID-prefixes, an ETR periodically sends
   Map-Register messages to the Map-Server.  A Map-Register message
   contains a list of EID-prefixes plus a set of RLOCs that can be used
   to reach the ETR when a Map-Server needs to forward a Map-Request to
   it.

   When LISP+ALT is used as the mapping database, a Map-Server connects
   to 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 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, a Map-Resolver may operate in a caching mode, where it
   saves information about outsanding Map-Reqeusts, originates new Map-
   Requests to the correct ETR(s), accepts and caches the Map-Replies,
   and finally forwards the Map-Replies to the original ITRs.  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

   Note that a single device =
can implement the functions of both a Map-
   Server and a Map-Resolver.  As is the case w=
ith Map-Resolver and, in many=
 cases, the DNS, however,
   operational simplicity argues for keeping those function=
s separate. will be
   co-located in that way.

4.  Interactions With Other LISP Components

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 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
      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 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 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.  There would be, for
   example, no need for such an ITR to send a 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.  A
   Map-Server's configuration should also include a list of the EID-
   prefixes for which each ETR is 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 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.

   An ETR may request that a Map-Server expli=
citly acknowledge receipt
   and processing of a Map-Register message by setting the "want-map-
   notify" ("M" bit) flag.  A Map-Server that receives a Map-Register
   with this flag set will respond with a Map-Notify message.  Typical
   use of this flag by an ETR would be to set it on Map-Requests sent
   during the initial "quick registration" with a Map Server but then
   set it only occasionally during steady-state maintenance of its
   association with that Map Server.

   Note that a one-minute minimum registration interval during steady
   state
   maintenance of an ETR-MS a=
ssociation 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 may also request, by setting the "p=
roxy-map-reply" flag
   (P-bit) in the Map-Regsiter message, that a Map-Server answer Map-
   Requests instead of forwarding them to the ETR.  See [LISP] for
   details on how the Map-Server sets certain flags (such as those
   indicating whether the message is authoratative and how returned
   locators should be treated) when sending a Map-Reply on behalf of an
   ETR.

   An ETR which uses a Map-Server to publish its EID-to-RLO=
C mappings
   does not need to participate further in the mapping database
   protocol(s).  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.

4.3.  Map-Server Processing

   The operation of

   Once a Map-Server, once it =
Map-Server has EID-prefixes registered by its client ETRs, =
is quite simple. it
   can accept and process Map-Requests for them.  In respon=
se to a Map-Request Map-
   Request (received over the ALT if LISP+ALT is in use), t=
he 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 resulting Encapsulated Map-Request t=
o a matching ETR.  It does
   not otherwise alter the Map-Request so any Map-Reply sent by the ETR
   is returned to the RLOC in the Map-Request, not to the Map-Server.
   Unless also acting as a Map-Resolver, a Map-Server should never
   receive Map-Replies; any such messages should be discarded without
   response, perhaps accompanied by logging of a diagnostic message if
   the rate of Map-Replies is suggestive of malicious traffic.

   A Map-Server may also receive a Map-Reques=
t that is contained inside
   of an Encapsulated Control Message (an Encapsulated Map-Request) with
   the "Security" bit (S-bit) set.  It processes the security parameters
   as described in [LISP-SEC] then generates an Encapsulated Map-Request
   to be sent as described above.

   Note that a Map-Server that is sending a Map-Reply on behalf of an
   ETR must perform security processing for that ETR as well; see
   [LISP-SEC] for details.

4.4.  Map-Resolver Processing

   In response to

   Upon receipt of an Encapsu=
lated Map-Request, a Map-Resolver de-
   capsulates the enclosed me=
ssage then checks searches for the requested EID
   in its local database of mapping entries (statically con=
figured,
   cached, or learned from associated ETRs).  If it finds a matching
   entry, it returns a 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 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.  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.  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.

   If a Map-Resolver receives a Map-Request c=
ontained in an Encapsulated
   Control Message (an Encapsulated Map-Request) with the "security"
   option (S-Bit) set, additional processing is required.  It extracts
   the enclosed Map-Request and uses the attached security paramaters to
   generate a new Encapsulated Control Message containing the original
   Map-Rqeuest and additional signature information used to protect both
   the Map-Request and the Map-Reply that will be generated by the
   destination ETR or Map-Server.  The outgoing message will have the
   S-bit set, will use the requested EID as its outer header destination
   IP address plus Map-Resolver RLOC as source IP address, and will
   include security parameters added by the Map-Resolver.  See
   [LISP-SEC] for details of the checks that are performed and the
   security information that is added during the de-encapsulation and
   re-encapsulation process.

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 use anycast
   addresses as 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 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 b=
etween 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 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 support use of HMAC-
   SHA-1-96 [RFC2404]
   SHA-1-160 [RFC2104] and sh=
ould support use of HMAC-SHA-128-256
   [RFC4634]. HMAC-SHA-256-128
   [RFC4634] (SHA-256 truncated to 128 bits).  Key changes =
are initially
   expected to be manual though a key-chaining scheme may be 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 exchan=
ge, where an ITR sends a
   Map-Request through a Map-Resolver, mapping database infrastructure,
   and Map-Server while an ETR returns

   [LISP-SEC] defines a Map-Reply directly to the ITR
   makes it difficult mechani=
sm for the ITR to verify that t=
he returned EID-prefix
   length matches that registered by the ETR with, =
providing origin authentication,
   integrity, anti-reply protection, and therefore checked
   by, a Map-Server. preventi=
on of man-in-the-middle
   and "overclaiming" attacks on the Map-Request/Map-Reply exchange.=


   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 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-05.txt=

              draft-ietf-lisp-alt-06.txt (work in progress),
              October 2010. March 2011.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-09.txt
              draft-ietf-lisp-10.txt (work in progress), October 2010. March 2011.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2404]  Madson, C.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Glenn, "The Use of HMAC-SHA-=
1-96 within
              ESP and AH", Ca=
netti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2404, November 1998. 2104,
              February 1997.

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

7.2.  Informative References

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

   [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, "LISP
              Mobile Node Architecture", draft-=
meyer-lisp-mn-03.txt draft-me=
yer-lisp-mn-04.txt
              (work in progress), August 2010.<=
/font> February 2011.

   [LISP-SEC]
              Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
              Bonaventure, "LISP-Security", draft-maino-lisp-sec-00.txt
              (work in progress), March 2011.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-08.txt (work in progress),
              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,
   Fabio Maino, and members o=
f 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 may 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
--3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-lisp-ms-07.txt" Network Working Group V. Fuller Internet-Draft D. Farinacci Intended status: Experimental cisco Systems Expires: September 5, 2011 March 4, 2011 LISP Map Server draft-ietf-lisp-ms-07.txt Abstract This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 5, 2011. Copyright Notice Copyright (c) 2011 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 Fuller & Farinacci Expires September 5, 2011 [Page 1] Internet-Draft LISP Map Server March 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Interactions With Other LISP Components . . . . . . . . . . . 6 4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 6 4.2. ETR/Map-Server EID Prefix Registration . . . . . . . . . . 7 4.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 8 4.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 8 4.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 10 5. Open Issues and Considerations . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Fuller & Farinacci Expires September 5, 2011 [Page 2] Internet-Draft LISP Map Server March 2011 1. 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]. 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 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. 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 standardized interface for ITRs and ETRs to access other mapping database systems. Fuller & Farinacci Expires September 5, 2011 [Page 3] Internet-Draft LISP Map Server March 2011 2. Definition of Terms Map-Server: a network infrastructure component which learns EID-to- RLOC mapping entries from an authoritative source (typically, an ETR, 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 carried within an Encapsulated Control Message, which has 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 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. In addition to the set of EID-prefixes to register, the message includes one or more RLOCs to be be used by the Map-Server when forwarding Map-Requests (re-formatted as Encapsulated Map-Requests) received through the database mapping system. An ETR may request that the Map-Server answer Map-Requests on its behalf by setting the "proxy-map-reply" flag (P-bit) in the message. Map-Notify message: a LISP message sent by a Map-Server to an ETR to confirm that a Map-Register has been received and processed. An ETR requests that a Map-Notify be returned by setting the "want-map-notify" or "M" bit in the Map-Register message. For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please consult the LISP specification [LISP]. Fuller & Farinacci Expires September 5, 2011 [Page 4] Internet-Draft LISP Map Server March 2011 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. 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. When LISP+ALT is used as the mapping database, a Map-Server connects to 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 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, a Map-Resolver may operate in a caching mode, where it saves information about outsanding Map-Reqeusts, originates new Map- Requests to the correct ETR(s), accepts and caches the Map-Replies, and finally forwards the Map-Replies to the original ITRs. 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. Note that a single device can implement the functions of both a Map- Server and a Map-Resolver and, in many cases, the functions will be co-located in that way. Fuller & Farinacci Expires September 5, 2011 [Page 5] Internet-Draft LISP Map Server March 2011 4. Interactions With Other LISP Components 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 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 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 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 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. There would be, for example, no need for such an ITR to send a 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. Fuller & Farinacci Expires September 5, 2011 [Page 6] Internet-Draft LISP Map Server March 2011 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. A Map-Server's configuration should also include a list of the EID- prefixes for which each ETR is 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 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. An ETR may request that a Map-Server explicitly acknowledge receipt and processing of a Map-Register message by setting the "want-map- notify" ("M" bit) flag. A Map-Server that receives a Map-Register with this flag set will respond with a Map-Notify message. Typical use of this flag by an ETR would be to set it on Map-Requests sent during the initial "quick registration" with a Map Server but then set it only occasionally during steady-state maintenance of its association with that Map Server. Note that a one-minute minimum registration interval during maintenance of an ETR-MS association 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 may also request, by setting the "proxy-map-reply" flag (P-bit) in the Map-Regsiter message, that a Map-Server answer Map- Requests instead of forwarding them to the ETR. See [LISP] for details on how the Map-Server sets certain flags (such as those indicating whether the message is authoratative and how returned locators should be treated) when sending a Map-Reply on behalf of an Fuller & Farinacci Expires September 5, 2011 [Page 7] Internet-Draft LISP Map Server March 2011 ETR. 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). 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. 4.3. Map-Server Processing Once a Map-Server has EID-prefixes registered by its client ETRs, it can accept and process Map-Requests for them. In response to a Map- Request (received over the ALT 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 resulting 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; 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. A Map-Server may also receive a Map-Request that is contained inside of an Encapsulated Control Message (an Encapsulated Map-Request) with the "Security" bit (S-bit) set. It processes the security parameters as described in [LISP-SEC] then generates an Encapsulated Map-Request to be sent as described above. Note that a Map-Server that is sending a Map-Reply on behalf of an ETR must perform security processing for that ETR as well; see [LISP-SEC] for details. 4.4. Map-Resolver Processing Upon receipt of an Encapsulated Map-Request, a Map-Resolver de- capsulates the enclosed message then searches for the requested EID in its local database of mapping entries (statically configured, cached, or learned from associated ETRs). If it finds a matching entry, it returns a non-authoritative LISP Map-Reply with the known mapping. Fuller & Farinacci Expires September 5, 2011 [Page 8] Internet-Draft LISP Map Server March 2011 If the Map-Resolver does not have the mapping entry and if it can determine that the requested IP address does not match an EID-prefix in the mapping database, it immediately returns a negative LISP Map- Reply, one which contains an EID-prefix and an empty locator-set. To minimize the number of negative cache entries needed by an ITR, the Map-Resolver should return the least-specific prefix which both matches the original query and does not match any EID-prefix known to exist in the LISP-capable infrastructure. If the Map-Resolver does not have sufficient information to know whether the EID exists, it needs to forward the Map-Request to another device which has more information about the EID being requested. This is done in one of two ways: 1. A non-caching Map-Resolver simply forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, on to the distributed mapping database. 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. 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. If a Map-Resolver receives a Map-Request contained in an Encapsulated Control Message (an Encapsulated Map-Request) with the "security" option (S-Bit) set, additional processing is required. It extracts the enclosed Map-Request and uses the attached security paramaters to generate a new Encapsulated Control Message containing the original Map-Rqeuest and additional signature information used to protect both the Map-Request and the Map-Reply that will be generated by the destination ETR or Map-Server. The outgoing message will have the S-bit set, will use the requested EID as its outer header destination IP address plus Map-Resolver RLOC as source IP address, and will include security parameters added by the Map-Resolver. See [LISP-SEC] for details of the checks that are performed and the Fuller & Farinacci Expires September 5, 2011 [Page 9] Internet-Draft LISP Map Server March 2011 security information that is added during the de-encapsulation and re-encapsulation process. 4.4.1. Anycast Map-Resolver Operation A Map-Resolver can be set up to use "anycast", where the same address is assigned to multiple Map-Resolvers and is propagated through IGP routing, to facilitate the use of a topologically-close Map-Resolver each ITR. Note that Map-Server associations with ETRs should not use anycast addresses as registrations need to be established between an ETR and a specific set of Map-Servers, each identified by a specific registation association. Fuller & Farinacci Expires September 5, 2011 [Page 10] Internet-Draft LISP Map Server March 2011 5. Open Issues and Considerations There are a number of issues with the 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 The authors expect that experimentation on the LISP pilot network will help answer open questions surrounding these and other issues. Fuller & Farinacci Expires September 5, 2011 [Page 11] Internet-Draft LISP Map Server March 2011 6. Security Considerations The 2-way nonce exchange documented in [LISP] can be used to avoid ITR spoofing attacks. To publish an 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 support use of HMAC- SHA-1-160 [RFC2104] and should support use of HMAC-SHA-256-128 [RFC4634] (SHA-256 truncated to 128 bits). Key changes are initially expected to be manual though a key-chaining scheme may be 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. [LISP-SEC] defines a mechanism for providing origin authentication, integrity, anti-reply protection, and prevention of man-in-the-middle and "overclaiming" attacks on the Map-Request/Map-Reply exchange. 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 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. Fuller & Farinacci Expires September 5, 2011 [Page 12] Internet-Draft LISP Map Server March 2011 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-06.txt (work in progress), March 2011. [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-10.txt (work in progress), March 2011. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. 7.2. Informative References [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. [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, "LISP Mobile Node Architecture", draft-meyer-lisp-mn-04.txt (work in progress), February 2011. [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. Bonaventure, "LISP-Security", draft-maino-lisp-sec-00.txt (work in progress), March 2011. Fuller & Farinacci Expires September 5, 2011 [Page 13] Internet-Draft LISP Map Server March 2011 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08.txt (work in progress), March 2010. Fuller & Farinacci Expires September 5, 2011 [Page 14] Internet-Draft LISP Map Server March 2011 Appendix A. Acknowledgments The authors would like to thank Greg Schudel, Darrel Lewis, John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, Fabio Maino, 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 may be used by Map-Resolvers. Fuller & Farinacci Expires September 5, 2011 [Page 15] Internet-Draft LISP Map Server March 2011 Authors' Addresses Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Fuller & Farinacci Expires September 5, 2011 [Page 16] --3MwIy2ne0vdjdPXF-- From Internet-Drafts@ietf.org Fri Mar 4 09:45:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144B13A67F1; Fri, 4 Mar 2011 09:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, 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 Fvq18VSu8eTy; Fri, 4 Mar 2011 09:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B873A67B1; Fri, 4 Mar 2011 09:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110304174502.22496.49648.idtracker@localhost> Date: Fri, 04 Mar 2011 09:45:02 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17: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 : Locator/ID Separation Protocol (LISP) Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-10.txt Pages : 84 Date : 2011-03-04 This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-04093925.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Fri Mar 4 10:30:02 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54893A6A19; Fri, 4 Mar 2011 10:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, 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 16GMyDdL6Mpg; Fri, 4 Mar 2011 10:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A053A6A14; Fri, 4 Mar 2011 10:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110304183002.3407.36006.idtracker@localhost> Date: Fri, 04 Mar 2011 10:30:02 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-alt-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 18:30: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 Alternative Topology (LISP+ALT) Author(s) : V. Fuller, et al. Filename : draft-ietf-lisp-alt-06.txt Pages : 28 Date : 2011-03-04 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-04102957.I-D@ietf.org> --NextPart-- From vaf@cisco.com Fri Mar 4 10:32:04 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DA033A6838 for ; Fri, 4 Mar 2011 10:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.409 X-Spam-Level: X-Spam-Status: No, score=-9.409 tagged_above=-999 required=5 tests=[AWL=1.191, 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 Fmjky1WbG9Xq for ; Fri, 4 Mar 2011 10:32:03 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7BF993A69E0 for ; Fri, 4 Mar 2011 10:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=1529; q=dns/txt; s=iport; t=1299263593; x=1300473193; h=date:from:to:subject:message-id:mime-version; bh=BOGL5NAgIpsOV/V+b24u4PE/USX9ma64IHr8LNsezOo=; b=Ca9N3PegGcquPS5yHmiP6CKUI5YhdnF8bkkXzwZbc0nfqj22jiKerIkN +jp05pc178UJjJIQY8zFAHf8tjduA7JQsRTRofbfmiqMKzZHFeYGyiiJb h6qNNDE13y2pEMblgs0rv+mlrY4v+JDVSPp4AyxFgjaQCh1Fppi2TDcg5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4IAGe/cE2rR7Hu/2dsb2JhbACYZo19dKNUm2uFYQSFHA X-IronPort-AV: E=Sophos;i="4.62,264,1297036800"; d="scan'208";a="269715463" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2011 18:33:12 +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 p24IXCEX022942 for ; Fri, 4 Mar 2011 18:33:12 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id BB734DBABFE; Fri, 4 Mar 2011 10:33:17 -0800 (PST) Date: Fri, 4 Mar 2011 10:33:17 -0800 From: Vince Fuller To: lisp@ietf.org Message-ID: <20110304183317.GA85544@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-06 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, 04 Mar 2011 18:32:04 -0000 FYI. No content changes, only updates to the references. --Vince ----- Forwarded message from IETF I-D Submission Tool ----- Date: Fri, 4 Mar 2011 10:29:58 -0800 (PST) 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-06 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogAADu/cE1AqmIgi2dsb2JhbACEKZQ7AQGNfRUBAQEKCwoHDwcgo1GLDJBfgSeDRHYEhRyHEw A new version of I-D, draft-ietf-lisp-alt-06.txt has been successfully submitted by Vince Fuller and posted to the IETF repository. Filename: draft-ietf-lisp-alt Revision: 06 Title: LISP Alternative Topology (LISP+ALT) Creation_date: 2011-03-04 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 dino@cisco.com Fri Mar 4 16:38:14 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C905A3A68EA for ; Fri, 4 Mar 2011 16:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.666 X-Spam-Level: X-Spam-Status: No, score=-9.666 tagged_above=-999 required=5 tests=[AWL=0.933, 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 cLupn+D91YFo for ; Fri, 4 Mar 2011 16:38:13 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BEA633A6875 for ; Fri, 4 Mar 2011 16:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2041; q=dns/txt; s=iport; t=1299285563; x=1300495163; h=cc:message-id:from:to:content-transfer-encoding: mime-version:subject:date:references; bh=TdxTLaUQzyNruuBXZixP0MdmyYwvPE8yt/CjXT9FLW8=; b=IFL7W2ed0KUqfPHWl1gwprjb3X08BATWZ2N6fWR5wzbU8ZO3tFfV3PyI 4naeKEg8Shv88T3u7zNgo2CSWrDSM7UcpAkJWNuqpKYzNcqhG+JSS+yy8 wjHLzn+mmdh0dJm5h5JGzmlj2MFyx5bcf6Z4cD3Wsz/Of7ShD72FeVgsF 8=; X-IronPort-AV: E=Sophos;i="4.62,267,1297036800"; d="scan'208";a="317377528" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 05 Mar 2011 00:39:23 +0000 Received: from [172.16.31.149] ([10.21.77.170]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p250dNpe001290; Sat, 5 Mar 2011 00:39:23 GMT Message-Id: <4337E250-C573-48D8-9FDD-3F8DB31E25E0@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: Fri, 4 Mar 2011 16:39:22 -0800 References: <8AB4C66C-BB31-4AAA-879C-41E87A08F1FC@gmail.com> X-Mailer: Apple Mail (2.936) Subject: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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, 05 Mar 2011 00:38:15 -0000 A proposed mechanism to deal with over-claiming attacks. This document is consistent with the general description of security encodings referred to in draft-ietf-lisp-10 and draft-ietf-lisp-ms-07. We are asking chairs for a slot to present this in Prague. Thanks, Dino Begin forwarded message: > From: Dino Farinacci > Date: March 4, 2011 4:36:15 PM PST > To: Dino Farinacci > Subject: Fwd: I-D Action:draft-maino-lisp-sec-00.txt > > > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: March 4, 2011 3:30:01 PM PST >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-maino-lisp-sec-00.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : LISP-Security (LISP-SEC) >> Author(s) : F. Maino, et al. >> Filename : draft-maino-lisp-sec-00.txt >> Pages : 17 >> Date : 2011-03-04 >> >> This memo specifies LISP-SEC, a set of security mechanisms that >> provide origin authentication, integrity and anti-replay protection >> to LISP's EID-to-RLOC mapping data. LISP-SEC also enables >> verification of authorization on EID prefix claims. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-maino-lisp-sec-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. > Content-Type: text/plain
Content-ID: <2011-03-04152104.I-D@ietf.org > >

>> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From terry.manderson@icann.org Tue Mar 8 17:54:27 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267163A67F4 for ; Tue, 8 Mar 2011 17:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 4q-iqWTYhcE1 for ; Tue, 8 Mar 2011 17:54:26 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 6368A3A67E6 for ; Tue, 8 Mar 2011 17:54:26 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 8 Mar 2011 17:55:42 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Tue, 8 Mar 2011 17:55:39 -0800 Thread-Topic: Prague, and important dates. Thread-Index: AcvHJRFos5lt+7SBRkWH2wRdb+cl0AW2AVwd 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] Prague, and important dates. 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, 09 Mar 2011 01:54:27 -0000 Hi Folks, I'm sure you are all aware that the agenda puts us mid-week in the 1300-150= 0 Afternoon Session I on Wednesday the 30th March. Given that we are a few days off needing a WG agenda, please email me agend= a items if you haven't already done so. Cheers Terry On 8/02/11 10:13 AM, "Terry" wrote: > Hi All, >=20 > Workgroup co-chair motorcycle helmet =3D on. >=20 > As you may be aware the IETF Prague meeting is barely 6 weeks away. >=20 > Joel and I have submitted the request for a session and as soon as we hav= e an > idea on the session timing we will let you know for your travel schedulin= g. It > also needs to be said that workgroups can fall on any day from Monday thr= ough > to Friday inclusive, and the IETF agenda is subject to change. >=20 > The following dates may be important to you: >=20 > *2011-02-24 (Thursday): Preliminary agenda published for comment. > *2011-02-28 (Monday): Cutoff date for requests to reschedule Working > Group and BOF meetings 17:00 PT (01:00 Tuesday, March 1 UTC). > *2011-02-28 (Monday): Working Group Chair approval for initial document > (Version -00) submissions appreciated by 17:00 PT (01:00 Tuesday, March 1 > UTC). > *2011-03-04 (Friday): Final agenda to be published. > *2011-03-16 (Wednesday): Draft Working Group agendas due by 17:00 PT > (01:00 Thursday, March 17 UTC). > *2011-03-21 (Monday): Revised Working Group agendas due by 17:00 PT > (01:00 Tuesday, March 22 UTC). >=20 > As yet I am NOT willing to accept requests for speaking slots, that call = will > come soon. However this is fair warning that 'no draft =3D=3D no slot' an= d the > STRONG preference is for on-charter items only. >=20 > Cheers > Terry From mperesse@corp.free.fr Wed Mar 9 07:05:09 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21FF83A69DE for ; Wed, 9 Mar 2011 07:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEk18zz3MYpl for ; Wed, 9 Mar 2011 07:05:08 -0800 (PST) Received: from zmc.proxad.net (zmc.proxad.net [212.27.53.206]) by core3.amsl.com (Postfix) with ESMTP id 96C1C3A69DC for ; Wed, 9 Mar 2011 07:05:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zmc.proxad.net (Postfix) with ESMTP id 07E33CDC51 for ; Wed, 9 Mar 2011 16:06:22 +0100 (CET) X-Virus-Scanned: amavisd-new at Received: from zmc.proxad.net ([127.0.0.1]) by localhost (zmc.proxad.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbqyfjhpeaMp for ; Wed, 9 Mar 2011 16:06:13 +0100 (CET) Received: from zmc.proxad.net (zmc.proxad.net [127.0.1.1]) by zmc.proxad.net (Postfix) with ESMTP id 9EBA81F6A27 for ; Wed, 9 Mar 2011 16:06:13 +0100 (CET) Date: Wed, 9 Mar 2011 16:06:13 +0100 (CET) From: Mathieu Peresse To: lisp@ietf.org Message-ID: <195752569.18251299683173571.JavaMail.root@zimbra-corp-1-b8> In-Reply-To: <891498594.18021299683071519.JavaMail.root@zimbra-corp-1-b8> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [213.228.1.121] X-Mailer: Zimbra 6.0.1_GA_1816.UBUNTU8_64 (ZimbraWebClient - SAF3 (Linux)/6.0.1_GA_1816.UBUNTU8_64) Subject: Re: [lisp] I-D Action:draft-ietf-lisp-10.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: Wed, 09 Mar 2011 15:05:09 -0000 Hi all, I'm Mathieu, I'm new to the list. I'm currently evaluating the LISP at my company... Always happy to contribute when I have the opportunity so here I am :) ----- Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol > Working Group of the IETF. FYI, the URL given in [AFI] is broken ATM (http://www.iana.org/numbers.html). I found this valid URL which seems to have the same info: http://www.iana.org/assignments/address-family-numbers/address-family-numbers.txt Regards, -- Mathieu From dino@cisco.com Wed Mar 9 09:27:37 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C803A6814 for ; Wed, 9 Mar 2011 09:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.899 X-Spam-Level: X-Spam-Status: No, score=-9.899 tagged_above=-999 required=5 tests=[AWL=0.700, 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 Zz9Jp+SxXpI4 for ; Wed, 9 Mar 2011 09:27:36 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 45B043A6765 for ; Wed, 9 Mar 2011 09:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=930; q=dns/txt; s=iport; t=1299691733; x=1300901333; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=fzBhoqnJgrKGlTpRUQEv8su/+c99JMuYVvwTqZk3dng=; b=RflZDPkI4VAsn2jBhWbBAtmJS3veS/jwQ6Jm30a4zXlyuIBxMa+D9aiH D0w9rYTTCwoH53VV1LW4OgwReMxcJMQ1K92C65xEZyvhHZZn28XxutnnS sEqzIOW9ONu7EFj+qF0cBS/Vy9xnb+UWuRluHKQV4KMZyJRTbdO6Mq8qP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG5Hd02rR7Hu/2dsb2JhbACmbnSnBZxRhWUEhSKHGINI X-IronPort-AV: E=Sophos;i="4.62,291,1297036800"; d="scan'208";a="275749581" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2011 17:28:52 +0000 Received: from [192.168.1.7] (sjc-vpn2-1284.cisco.com [10.21.117.4]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p29HSqGF024651; Wed, 9 Mar 2011 17:28:52 GMT Message-Id: <5695DA34-4FCC-48B9-8898-5C0D84ADF1EF@cisco.com> From: Dino Farinacci To: Mathieu Peresse In-Reply-To: <195752569.18251299683173571.JavaMail.root@zimbra-corp-1-b8> 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, 9 Mar 2011 09:28:52 -0800 References: <195752569.18251299683173571.JavaMail.root@zimbra-corp-1-b8> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] I-D Action:draft-ietf-lisp-10.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: Wed, 09 Mar 2011 17:27:37 -0000 Thanks Mathieu, I will fix in the next rev. Dino On Mar 9, 2011, at 7:06 AM, Mathieu Peresse wrote: > Hi all, > > I'm Mathieu, I'm new to the list. I'm currently evaluating the LISP > at my company... > Always happy to contribute when I have the opportunity so here I am :) > > ----- Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Locator/ID Separation Protocol >> Working Group of the IETF. > > FYI, the URL given in [AFI] is broken ATM (http://www.iana.org/numbers.html > ). > I found this valid URL which seems to have the same info: http://www.iana.org/assignments/address-family-numbers/address-family-numbers.txt > > > Regards, > > -- > Mathieu > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Wed Mar 9 16:11:53 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727D93A6B0D for ; Wed, 9 Mar 2011 16:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, 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 BcOqsNITERxA for ; Wed, 9 Mar 2011 16:11:52 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 3B4BF3A6B14 for ; Wed, 9 Mar 2011 16:11:52 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 9 Mar 2011 16:13:09 -0800 From: Terry Manderson To: Dino Farinacci , "lisp@ietf.org" Date: Wed, 9 Mar 2011 16:13:06 -0800 Thread-Topic: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-00.txt Thread-Index: AcvazdYG/EmUWkeMQTCpBxEY62/vHAD6hfAB Message-ID: In-Reply-To: <4337E250-C573-48D8-9FDD-3F8DB31E25E0@cisco.com> 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] Fwd: I-D Action:draft-maino-lisp-sec-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: Thu, 10 Mar 2011 00:11:53 -0000 Thanks Dino, Its been 6 days since this item was uploaded - I am floored that it hasn't generated _any_ response from the WG. Please WG, review this document as it is important. So taking off the co-chair hat. The document appears to address the communications between ITR, map server, and ETR by adding a layer of integrity to the ECM. And later in the document, the SIDR working group is identified as the plac= e to deal with the BGP in LISP+ALT. I didn't see it, and maybe I missed it. What actions does a map-server (or map server operator) take to confirm that the entity registering at a map server has the right to present the EID in question? It may be that we simply have differing ideas of 'origination' and potentially this is covered. Cheers Terry On 5/03/11 10:39 AM, "Dino Farinacci" wrote: > A proposed mechanism to deal with over-claiming attacks. This document > is consistent with the general description of security encodings > referred to in draft-ietf-lisp-10 and draft-ietf-lisp-ms-07. >=20 > We are asking chairs for a slot to present this in Prague. >=20 > Thanks, > Dino >=20 > Begin forwarded message: >=20 >> From: Dino Farinacci >> Date: March 4, 2011 4:36:15 PM PST >> To: Dino Farinacci >> Subject: Fwd: I-D Action:draft-maino-lisp-sec-00.txt >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: Internet-Drafts@ietf.org >>> Date: March 4, 2011 3:30:01 PM PST >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-maino-lisp-sec-00.txt >>> Reply-To: internet-drafts@ietf.org >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>=20 >>> Title : LISP-Security (LISP-SEC) >>> Author(s) : F. Maino, et al. >>> Filename : draft-maino-lisp-sec-00.txt >>> Pages : 17 >>> Date : 2011-03-04 >>>=20 >>> This memo specifies LISP-SEC, a set of security mechanisms that >>> provide origin authentication, integrity and anti-replay protection >>> to LISP's EID-to-RLOC mapping data. LISP-SEC also enables >>> verification of authorization on EID prefix claims. >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-maino-lisp-sec-00.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >> Content-Type: text/plain
Content-ID: <2011-03-04152104.I-D@ietf.or= g >> >

>>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Wed Mar 9 16:34:44 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4B03A67D9 for ; Wed, 9 Mar 2011 16:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.739 X-Spam-Level: X-Spam-Status: No, score=-9.739 tagged_above=-999 required=5 tests=[AWL=0.260, 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 xSFNB-lXJSUU for ; Wed, 9 Mar 2011 16:34:43 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E71C33A67B8 for ; Wed, 9 Mar 2011 16:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=4534; q=dns/txt; s=iport; t=1299717360; x=1300926960; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=urqt8FLaAHWx3eC3IeJd8l5/MzC2H/DqI1fDRUHnX5s=; b=Y9em1o4FbtKlyIkWEosm7idue+gjLl2ErytRErZ9tyxtM1VfF5Dio0BD BT0S4JorK31PGmdym+LhxMzYuE6u/GiJ9GOq7wTsS/dyJvJqqIpku+Bzz XKZzblxWWj9H57V2h/LJeqiQUlMC67vQBHFKPuFLv5SOw0Qv9vo73iSn3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFCrd02rR7H+/2dsb2JhbACmcnSme5w6hWUEhSKHGINIgxw X-IronPort-AV: E=Sophos;i="4.62,293,1297036800"; d="scan'208";a="318822102" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 10 Mar 2011 00:36:00 +0000 Received: from [192.168.1.7] (sjc-vpn2-1284.cisco.com [10.21.117.4]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p2A0Zxor018282; Thu, 10 Mar 2011 00:35:59 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: Wed, 9 Mar 2011 16:35:59 -0800 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Thu, 10 Mar 2011 00:34:45 -0000 > Thanks Dino, > > Its been 6 days since this item was uploaded - I am floored that it > hasn't > generated _any_ response from the WG. Please WG, review this > document as it > is important. > > So taking off the co-chair hat. > > The document appears to address the communications between ITR, map > server, > and ETR by adding a layer of integrity to the ECM. > > And later in the document, the SIDR working group is identified as > the place > to deal with the BGP in LISP+ALT. > > I didn't see it, and maybe I missed it. What actions does a map- > server (or > map server operator) take to confirm that the entity registering at > a map > server has the right to present the EID in question? It may be that we This is in the draft-ietf-lisp-ms-06 draft. It indicates that there is a business arrangement/transaction between the site and the Mapping Service Provider. When the locator-set is known by the site and the EID-prefix is allocated to the site, the site communicates this by non- protocol mechanisms with a shared-key to the Mapping Service Provider. Then the EID-prefix, locator-set, shared-key is configured in the Map-Server device(s). Only when the site registers the exact EID-prefix and locator-set and signs the Map-Register and the Map- Server receives and verifies the ETR signature, does Map-Requests for EIDs covered by the registered EID-prefix get sent by the Map-Server to the ETRs at the site. What the LISP-SEC adds to this is to have the Map-Server sign the EID- prefix registered and forces the ETR to sign its Map-Reply with a one- time-key the Map-Server (the trusted anchor point) chooses with no knowledge of the one-time-key the ITR selected. Then the ITR can verify that the trusted anchor point is saying the EID-prefix mask- length is the same that is being registered and the ETR believes the same for the part of the Map-Reply it signs. Did that answer your question with too much detail? Dino > simply have differing ideas of 'origination' and potentially this is > covered. > > Cheers > Terry > > > On 5/03/11 10:39 AM, "Dino Farinacci" wrote: > >> A proposed mechanism to deal with over-claiming attacks. This >> document >> is consistent with the general description of security encodings >> referred to in draft-ietf-lisp-10 and draft-ietf-lisp-ms-07. >> >> We are asking chairs for a slot to present this in Prague. >> >> Thanks, >> Dino >> >> Begin forwarded message: >> >>> From: Dino Farinacci >>> Date: March 4, 2011 4:36:15 PM PST >>> To: Dino Farinacci >>> Subject: Fwd: I-D Action:draft-maino-lisp-sec-00.txt >>> >>> >>> >>> Begin forwarded message: >>> >>>> From: Internet-Drafts@ietf.org >>>> Date: March 4, 2011 3:30:01 PM PST >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action:draft-maino-lisp-sec-00.txt >>>> Reply-To: internet-drafts@ietf.org >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : LISP-Security (LISP-SEC) >>>> Author(s) : F. Maino, et al. >>>> Filename : draft-maino-lisp-sec-00.txt >>>> Pages : 17 >>>> Date : 2011-03-04 >>>> >>>> This memo specifies LISP-SEC, a set of security mechanisms that >>>> provide origin authentication, integrity and anti-replay protection >>>> to LISP's EID-to-RLOC mapping data. LISP-SEC also enables >>>> verification of authorization on EID prefix claims. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-maino-lisp-sec-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. >>> Content-Type: text/plain
Content-ID: <2011-03-04152104.I-D@ietf.org >>> >

>>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From jmh@joelhalpern.com Wed Mar 9 16:49:44 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED043A6B16 for ; Wed, 9 Mar 2011 16:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 r6-b65ouckaU for ; Wed, 9 Mar 2011 16:49:43 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id A80F33A698A for ; Wed, 9 Mar 2011 16:49:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 02C273244C0F; Wed, 9 Mar 2011 16:51:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.170] (unknown [129.192.147.67]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 694703244A48; Wed, 9 Mar 2011 16:51:00 -0800 (PST) Message-ID: <4D782073.2050401@joelhalpern.com> Date: Wed, 09 Mar 2011 19:50:59 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dino Farinacci References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Thu, 10 Mar 2011 00:49:44 -0000 Is the ETR allowed to later update the locator-set? What if the locator set changes between the off-line notifcation and the on-line registration? Or is there a requirement that when the set of likely locators changes (for example by entering into a contract with a new ISP for a new link), there must be an off-line communication with the (all?) MS providers one works with? I realize the locator set changes relatively rarely, but I am trying to check the implications. Thanks, Joel On 3/9/2011 7:35 PM, Dino Farinacci wrote: >> Thanks Dino, >> >> Its been 6 days since this item was uploaded - I am floored that it >> hasn't >> generated _any_ response from the WG. Please WG, review this document >> as it >> is important. >> >> So taking off the co-chair hat. >> >> The document appears to address the communications between ITR, map >> server, >> and ETR by adding a layer of integrity to the ECM. >> >> And later in the document, the SIDR working group is identified as the >> place >> to deal with the BGP in LISP+ALT. >> >> I didn't see it, and maybe I missed it. What actions does a map-server >> (or >> map server operator) take to confirm that the entity registering at a map >> server has the right to present the EID in question? It may be that we > > This is in the draft-ietf-lisp-ms-06 draft. It indicates that there is a > business arrangement/transaction between the site and the Mapping > Service Provider. When the locator-set is known by the site and the > EID-prefix is allocated to the site, the site communicates this by > non-protocol mechanisms with a shared-key to the Mapping Service > Provider. Then the EID-prefix, locator-set, shared-key is configured in > the Map-Server device(s). Only when the site registers the exact > EID-prefix and locator-set and signs the Map-Register and the Map-Server > receives and verifies the ETR signature, does Map-Requests for EIDs > covered by the registered EID-prefix get sent by the Map-Server to the > ETRs at the site. > > What the LISP-SEC adds to this is to have the Map-Server sign the > EID-prefix registered and forces the ETR to sign its Map-Reply with a > one-time-key the Map-Server (the trusted anchor point) chooses with no > knowledge of the one-time-key the ITR selected. Then the ITR can verify > that the trusted anchor point is saying the EID-prefix mask-length is > the same that is being registered and the ETR believes the same for the > part of the Map-Reply it signs. > > Did that answer your question with too much detail? > > Dino > >> simply have differing ideas of 'origination' and potentially this is >> covered. >> >> Cheers >> Terry >> >> >> On 5/03/11 10:39 AM, "Dino Farinacci" wrote: >> >>> A proposed mechanism to deal with over-claiming attacks. This document >>> is consistent with the general description of security encodings >>> referred to in draft-ietf-lisp-10 and draft-ietf-lisp-ms-07. >>> >>> We are asking chairs for a slot to present this in Prague. >>> >>> Thanks, >>> Dino >>> >>> Begin forwarded message: >>> >>>> From: Dino Farinacci >>>> Date: March 4, 2011 4:36:15 PM PST >>>> To: Dino Farinacci >>>> Subject: Fwd: I-D Action:draft-maino-lisp-sec-00.txt >>>> >>>> >>>> >>>> Begin forwarded message: >>>> >>>>> From: Internet-Drafts@ietf.org >>>>> Date: March 4, 2011 3:30:01 PM PST >>>>> To: i-d-announce@ietf.org >>>>> Subject: I-D Action:draft-maino-lisp-sec-00.txt >>>>> Reply-To: internet-drafts@ietf.org >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> Title : LISP-Security (LISP-SEC) >>>>> Author(s) : F. Maino, et al. >>>>> Filename : draft-maino-lisp-sec-00.txt >>>>> Pages : 17 >>>>> Date : 2011-03-04 >>>>> >>>>> This memo specifies LISP-SEC, a set of security mechanisms that >>>>> provide origin authentication, integrity and anti-replay protection >>>>> to LISP's EID-to-RLOC mapping data. LISP-SEC also enables >>>>> verification of authorization on EID prefix claims. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-maino-lisp-sec-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. >>>> Content-Type: text/plain
Content-ID: >>>> <2011-03-04152104.I-D@ietf.org >>>> >

>>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>> >>> _______________________________________________ >>> 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 terry.manderson@icann.org Wed Mar 9 17:06:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DC43A6AFE for ; Wed, 9 Mar 2011 17:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 N64QmerHBxuZ for ; Wed, 9 Mar 2011 17:06:39 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 500E33A6937 for ; Wed, 9 Mar 2011 17:06:39 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 9 Mar 2011 17:07:55 -0800 From: Terry Manderson To: Dino Farinacci Date: Wed, 9 Mar 2011 17:07:53 -0800 Thread-Topic: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-00.txt Thread-Index: Acveuy1AQ5jYDPeRSgeocSq+BfDuJwABGe8+ 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] Fwd: I-D Action:draft-maino-lisp-sec-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: Thu, 10 Mar 2011 01:06:40 -0000 Still no wg-chair garb. On 10/03/11 10:35 AM, "Dino Farinacci" wrote: >=20 > This is in the draft-ietf-lisp-ms-06 draft. It indicates that there is > a business arrangement/transaction between the site and the Mapping Right, an in particular when I saw "origination" in the maino document and reflecting on these sentences in LISP-MS: " 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 added to the registration process." My mind raced to a point further than what the maino-lisp-sec document covers. Perhaps review what 'origination' means in maino-lisp-sec compared to the current school of thought on route origination vs the LISP collectiv= e thought on EID to RLOC origination and the ground work needed to confirm an entity has the right to originate an EID, for what period of time, and if any preconditions need to exist. Or perhaps alternatively note in the security considerations that maino-lisp-sec doesn't cover the registration process, or variances thereof= . Cheers Terry From dino@cisco.com Wed Mar 9 17:08:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5523A6AFE for ; Wed, 9 Mar 2011 17:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.782 X-Spam-Level: X-Spam-Status: No, score=-9.782 tagged_above=-999 required=5 tests=[AWL=0.217, 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 tDFeRgcGhX4B for ; Wed, 9 Mar 2011 17:08:10 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B22093A6937 for ; Wed, 9 Mar 2011 17:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=5918; q=dns/txt; s=iport; t=1299719368; x=1300928968; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=lDqLWXzFx/MMnvHR4nEnme86yNVrvnwRpfdbe6SFRG0=; b=CiiG5kcj479KvRf29e9HEeaSUx2ofor/T4U0NO9mxYhakSybGpOheU6+ 9XZRu4WdT39IMGTBf6UyNk+Scb7G7E7BM8mTJsl+XfcFHiHjYPBdapMbB f7KHtm40f3HN13No9yioHQ7kIGld3eyhQjFu8yZqpwsrpW6aOHFztgCiA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD6zd02rR7H+/2dsb2JhbACmcnSnEZxEhWUEhSKHGINIgxw X-IronPort-AV: E=Sophos;i="4.62,293,1297036800"; d="scan'208";a="276103966" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2011 01:09:27 +0000 Received: from [192.168.1.7] (sjc-vpn2-1284.cisco.com [10.21.117.4]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p2A19RwU017597; Thu, 10 Mar 2011 01:09:27 GMT Message-Id: <02838D85-255F-4253-86FC-938920F2C6F8@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4D782073.2050401@joelhalpern.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: Wed, 9 Mar 2011 17:09:27 -0800 References: <4D782073.2050401@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Thu, 10 Mar 2011 01:08:12 -0000 > Is the ETR allowed to later update the locator-set? Yes, the Map-Server can be configured with no locator-set or an "allowed-list" of locators which can be a superset of what is currently being registered. > What if the locator set changes between the off-line notifcation and > the on-line registration? If the policy is strict in the Map-Server then the registration is not accepted. This allows the mapping system to decide how *mobile* the EID-prefix can be. > Or is there a requirement that when the set of likely locators > changes (for example by entering into a contract with a new ISP for > a new link), there must be an off-line communication with the (all?) > MS providers one works with? Depends on how loose the policy is in the map-servers. Dino > I realize the locator set changes relatively rarely, but I am trying > to check the implications. > > Thanks, > Joel > > On 3/9/2011 7:35 PM, Dino Farinacci wrote: >>> Thanks Dino, >>> >>> Its been 6 days since this item was uploaded - I am floored that it >>> hasn't >>> generated _any_ response from the WG. Please WG, review this >>> document >>> as it >>> is important. >>> >>> So taking off the co-chair hat. >>> >>> The document appears to address the communications between ITR, map >>> server, >>> and ETR by adding a layer of integrity to the ECM. >>> >>> And later in the document, the SIDR working group is identified as >>> the >>> place >>> to deal with the BGP in LISP+ALT. >>> >>> I didn't see it, and maybe I missed it. What actions does a map- >>> server >>> (or >>> map server operator) take to confirm that the entity registering >>> at a map >>> server has the right to present the EID in question? It may be >>> that we >> >> This is in the draft-ietf-lisp-ms-06 draft. It indicates that there >> is a >> business arrangement/transaction between the site and the Mapping >> Service Provider. When the locator-set is known by the site and the >> EID-prefix is allocated to the site, the site communicates this by >> non-protocol mechanisms with a shared-key to the Mapping Service >> Provider. Then the EID-prefix, locator-set, shared-key is >> configured in >> the Map-Server device(s). Only when the site registers the exact >> EID-prefix and locator-set and signs the Map-Register and the Map- >> Server >> receives and verifies the ETR signature, does Map-Requests for EIDs >> covered by the registered EID-prefix get sent by the Map-Server to >> the >> ETRs at the site. >> >> What the LISP-SEC adds to this is to have the Map-Server sign the >> EID-prefix registered and forces the ETR to sign its Map-Reply with a >> one-time-key the Map-Server (the trusted anchor point) chooses with >> no >> knowledge of the one-time-key the ITR selected. Then the ITR can >> verify >> that the trusted anchor point is saying the EID-prefix mask-length is >> the same that is being registered and the ETR believes the same for >> the >> part of the Map-Reply it signs. >> >> Did that answer your question with too much detail? >> >> Dino >> >>> simply have differing ideas of 'origination' and potentially this is >>> covered. >>> >>> Cheers >>> Terry >>> >>> >>> On 5/03/11 10:39 AM, "Dino Farinacci" wrote: >>> >>>> A proposed mechanism to deal with over-claiming attacks. This >>>> document >>>> is consistent with the general description of security encodings >>>> referred to in draft-ietf-lisp-10 and draft-ietf-lisp-ms-07. >>>> >>>> We are asking chairs for a slot to present this in Prague. >>>> >>>> Thanks, >>>> Dino >>>> >>>> Begin forwarded message: >>>> >>>>> From: Dino Farinacci >>>>> Date: March 4, 2011 4:36:15 PM PST >>>>> To: Dino Farinacci >>>>> Subject: Fwd: I-D Action:draft-maino-lisp-sec-00.txt >>>>> >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Internet-Drafts@ietf.org >>>>>> Date: March 4, 2011 3:30:01 PM PST >>>>>> To: i-d-announce@ietf.org >>>>>> Subject: I-D Action:draft-maino-lisp-sec-00.txt >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet- >>>>>> Drafts >>>>>> directories. >>>>>> >>>>>> Title : LISP-Security (LISP-SEC) >>>>>> Author(s) : F. Maino, et al. >>>>>> Filename : draft-maino-lisp-sec-00.txt >>>>>> Pages : 17 >>>>>> Date : 2011-03-04 >>>>>> >>>>>> This memo specifies LISP-SEC, a set of security mechanisms that >>>>>> provide origin authentication, integrity and anti-replay >>>>>> protection >>>>>> to LISP's EID-to-RLOC mapping data. LISP-SEC also enables >>>>>> verification of authorization on EID prefix claims. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-maino-lisp-sec-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. >>>>> Content-Type: text/plain
Content-ID: >>>>> <2011-03-04152104.I-D@ietf.org >>>>> >

>>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>> >>>> _______________________________________________ >>>> 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 Wed Mar 9 17:11:55 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7343A6B20 for ; Wed, 9 Mar 2011 17:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=0.486, 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 EMQUqrdxt7vD for ; Wed, 9 Mar 2011 17:11:50 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D8D993A6B25 for ; Wed, 9 Mar 2011 17:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1481; q=dns/txt; s=iport; t=1299719585; x=1300929185; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=nW4ZVa/2t4x0BMrKl1In48eykB+h/sGLgINU2n8ygZY=; b=LAuxSOODT6TsGUBqWaIvDSJ/WhdPIfwP00RrwiNveWz67dwWy6e+W9st HgWGJdR+HK2RdykR9evIMTFC1AXtUsjLeucyht7T3pxh/bO7vHL4dklLJ XBBUHeiZnEKeyIeaAHQlFeI9qyGWeitAXvKDigP8LEtx6BZZj+8GMBCqY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGu0d02rR7Hu/2dsb2JhbACmcnSnHo4WjiuFZQSFIocYg0g X-IronPort-AV: E=Sophos;i="4.62,293,1297036800"; d="scan'208";a="413239495" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2011 01:13:04 +0000 Received: from [192.168.1.7] (sjc-vpn2-1284.cisco.com [10.21.117.4]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p2A1D4fd009053; Thu, 10 Mar 2011 01:13:04 GMT Message-Id: <5C027C92-354C-4A04-900C-A89CEEC87E33@cisco.com> 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: Wed, 9 Mar 2011 17:13:03 -0800 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Thu, 10 Mar 2011 01:11:56 -0000 > Still no wg-chair garb. > > > On 10/03/11 10:35 AM, "Dino Farinacci" wrote: > >> >> This is in the draft-ietf-lisp-ms-06 draft. It indicates that there >> is >> a business arrangement/transaction between the site and the Mapping > > Right, an in particular when I saw "origination" in the maino > document and > reflecting on these sentences in LISP-MS: > > " 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 added to the registration process." > > My mind raced to a point further than what the maino-lisp-sec document > covers. Perhaps review what 'origination' means in maino-lisp-sec > compared > to the current school of thought on route origination vs the LISP > collective > thought on EID to RLOC origination and the ground work needed to > confirm an > entity has the right to originate an EID, for what period of time, > and if > any preconditions need to exist. > > Or perhaps alternatively note in the security considerations that > maino-lisp-sec doesn't cover the registration process, or variances > thereof. That is correct. The spec's main objective is to provide integrity of the contents in a Map-Reply message. Dino > > Cheers > Terry > From fmaino@cisco.com Wed Mar 9 17:18:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264123A68D8 for ; Wed, 9 Mar 2011 17:18:03 -0800 (PST) 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 B92P46TYXD-4 for ; Wed, 9 Mar 2011 17:18:01 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E0C8D3A67D6 for ; Wed, 9 Mar 2011 17:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fmaino@cisco.com; l=2101; q=dns/txt; s=iport; t=1299719959; x=1300929559; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=P8mFBEKH2IRzt7pCzmADeL8LtVPvnU9uc9fHcb+VnaM=; b=JTGcwtdaPHxL3vSHBPJ3IRG6tKQcdcjYJkvQIWt9GItt9tIUrcGJL3Lx rYbtmWeMvIJS9ZkUmnoAb3duissy/+2YsvxSG32I4Be7opxVfFdQcdsVS XI1OsrCkPxc0l1YcuRkFlTo2PinRgA8J9wvDm445tf47WY6CbrKSGokgF E=; X-IronPort-AV: E=Sophos;i="4.62,293,1297036800"; d="scan'208";a="666226628" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2011 01:19:19 +0000 Received: from dhcp-128-107-166-128.cisco.com (dhcp-128-107-166-128.cisco.com [128.107.166.128]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p2A1JJOa013522; Thu, 10 Mar 2011 01:19:19 GMT Message-ID: <4D782716.8000703@cisco.com> Date: Wed, 09 Mar 2011 17:19:18 -0800 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dino Farinacci References: <5C027C92-354C-4A04-900C-A89CEEC87E33@cisco.com> In-Reply-To: <5C027C92-354C-4A04-900C-A89CEEC87E33@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Thu, 10 Mar 2011 01:18:03 -0000 On 3/9/11 5:13 PM, Dino Farinacci wrote: >> Still no wg-chair garb. >> >> >> On 10/03/11 10:35 AM, "Dino Farinacci" wrote: >> >>> >>> This is in the draft-ietf-lisp-ms-06 draft. It indicates that there is >>> a business arrangement/transaction between the site and the Mapping >> >> Right, an in particular when I saw "origination" in the maino >> document and >> reflecting on these sentences in LISP-MS: >> >> " 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 added to the registration process." >> >> My mind raced to a point further than what the maino-lisp-sec document >> covers. Perhaps review what 'origination' means in maino-lisp-sec >> compared >> to the current school of thought on route origination vs the LISP >> collective >> thought on EID to RLOC origination and the ground work needed to >> confirm an >> entity has the right to originate an EID, for what period of time, >> and if >> any preconditions need to exist. >> >> Or perhaps alternatively note in the security considerations that >> maino-lisp-sec doesn't cover the registration process, or variances >> thereof. > > That is correct. The spec's main objective is to provide integrity of > the contents in a Map-Reply message. Agree. We intentionally left the security of the registration process out of the scope of the document. As Dino said today EID-prefix authorization is done by configuration. We'll add the note on registration to the security section. Fabio > > Dino > >> >> Cheers >> Terry >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- Fabio Maino fmaino@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jmh@joelhalpern.com Wed Mar 9 17:24:20 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F843A68C7 for ; Wed, 9 Mar 2011 17:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 UDrkvz98PFsW for ; Wed, 9 Mar 2011 17:24:17 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id 91B453A67D6 for ; Wed, 9 Mar 2011 17:24:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id E85E83244C0F; Wed, 9 Mar 2011 17:25:34 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id C5DB332442C8; Wed, 9 Mar 2011 17:25:34 -0800 (PST) Message-ID: <4D78288D.7060400@joelhalpern.com> Date: Wed, 09 Mar 2011 20:25:33 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dino Farinacci References: <4D782073.2050401@joelhalpern.com> <02838D85-255F-4253-86FC-938920F2C6F8@cisco.com> In-Reply-To: <02838D85-255F-4253-86FC-938920F2C6F8@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Thu, 10 Mar 2011 01:24:20 -0000 Reasonable. But we probably need to say this somewhere. (And I apologize if it already says it and I missed it.) Yours, Joel On 3/9/2011 8:09 PM, Dino Farinacci wrote: >> Is the ETR allowed to later update the locator-set? > > Yes, the Map-Server can be configured with no locator-set or an > "allowed-list" of locators which can be a superset of what is currently > being registered. > >> What if the locator set changes between the off-line notifcation and >> the on-line registration? > > If the policy is strict in the Map-Server then the registration is not > accepted. This allows the mapping system to decide how *mobile* the > EID-prefix can be. > >> Or is there a requirement that when the set of likely locators changes >> (for example by entering into a contract with a new ISP for a new >> link), there must be an off-line communication with the (all?) MS >> providers one works with? > > Depends on how loose the policy is in the map-servers. > > Dino > >> I realize the locator set changes relatively rarely, but I am trying >> to check the implications. >> >> Thanks, >> Joel >> >> On 3/9/2011 7:35 PM, Dino Farinacci wrote: >>>> Thanks Dino, >>>> >>>> Its been 6 days since this item was uploaded - I am floored that it >>>> hasn't >>>> generated _any_ response from the WG. Please WG, review this document >>>> as it >>>> is important. >>>> >>>> So taking off the co-chair hat. >>>> >>>> The document appears to address the communications between ITR, map >>>> server, >>>> and ETR by adding a layer of integrity to the ECM. >>>> >>>> And later in the document, the SIDR working group is identified as the >>>> place >>>> to deal with the BGP in LISP+ALT. >>>> >>>> I didn't see it, and maybe I missed it. What actions does a map-server >>>> (or >>>> map server operator) take to confirm that the entity registering at >>>> a map >>>> server has the right to present the EID in question? It may be that we >>> >>> This is in the draft-ietf-lisp-ms-06 draft. It indicates that there is a >>> business arrangement/transaction between the site and the Mapping >>> Service Provider. When the locator-set is known by the site and the >>> EID-prefix is allocated to the site, the site communicates this by >>> non-protocol mechanisms with a shared-key to the Mapping Service >>> Provider. Then the EID-prefix, locator-set, shared-key is configured in >>> the Map-Server device(s). Only when the site registers the exact >>> EID-prefix and locator-set and signs the Map-Register and the Map-Server >>> receives and verifies the ETR signature, does Map-Requests for EIDs >>> covered by the registered EID-prefix get sent by the Map-Server to the >>> ETRs at the site. >>> >>> What the LISP-SEC adds to this is to have the Map-Server sign the >>> EID-prefix registered and forces the ETR to sign its Map-Reply with a >>> one-time-key the Map-Server (the trusted anchor point) chooses with no >>> knowledge of the one-time-key the ITR selected. Then the ITR can verify >>> that the trusted anchor point is saying the EID-prefix mask-length is >>> the same that is being registered and the ETR believes the same for the >>> part of the Map-Reply it signs. >>> >>> Did that answer your question with too much detail? >>> >>> Dino >>> >>>> simply have differing ideas of 'origination' and potentially this is >>>> covered. >>>> >>>> Cheers >>>> Terry >>>> >>>> >>>> On 5/03/11 10:39 AM, "Dino Farinacci" wrote: >>>> >>>>> A proposed mechanism to deal with over-claiming attacks. This document >>>>> is consistent with the general description of security encodings >>>>> referred to in draft-ietf-lisp-10 and draft-ietf-lisp-ms-07. >>>>> >>>>> We are asking chairs for a slot to present this in Prague. >>>>> >>>>> Thanks, >>>>> Dino >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Dino Farinacci >>>>>> Date: March 4, 2011 4:36:15 PM PST >>>>>> To: Dino Farinacci >>>>>> Subject: Fwd: I-D Action:draft-maino-lisp-sec-00.txt >>>>>> >>>>>> >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Internet-Drafts@ietf.org >>>>>>> Date: March 4, 2011 3:30:01 PM PST >>>>>>> To: i-d-announce@ietf.org >>>>>>> Subject: I-D Action:draft-maino-lisp-sec-00.txt >>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> >>>>>>> Title : LISP-Security (LISP-SEC) >>>>>>> Author(s) : F. Maino, et al. >>>>>>> Filename : draft-maino-lisp-sec-00.txt >>>>>>> Pages : 17 >>>>>>> Date : 2011-03-04 >>>>>>> >>>>>>> This memo specifies LISP-SEC, a set of security mechanisms that >>>>>>> provide origin authentication, integrity and anti-replay protection >>>>>>> to LISP's EID-to-RLOC mapping data. LISP-SEC also enables >>>>>>> verification of authorization on EID prefix claims. >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-maino-lisp-sec-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. >>>>>> Content-Type: text/plain
Content-ID: >>>>>> <2011-03-04152104.I-D@ietf.org >>>>>> >

>>>>>>> >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 mperesse@corp.free.fr Thu Mar 10 01:39:33 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810533A67EF for ; Thu, 10 Mar 2011 01:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6409NNplSbL for ; Thu, 10 Mar 2011 01:39:32 -0800 (PST) Received: from zmc.proxad.net (zmc.proxad.net [212.27.53.206]) by core3.amsl.com (Postfix) with ESMTP id 918783A68B0 for ; Thu, 10 Mar 2011 01:39:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zmc.proxad.net (Postfix) with ESMTP id 406D71F9F3F; Thu, 10 Mar 2011 10:40:47 +0100 (CET) X-Virus-Scanned: amavisd-new at Received: from zmc.proxad.net ([127.0.0.1]) by localhost (zmc.proxad.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCciWjmZMujJ; Thu, 10 Mar 2011 10:40:47 +0100 (CET) Received: from zmc.proxad.net (zmc.proxad.net [127.0.1.1]) by zmc.proxad.net (Postfix) with ESMTP id 217521F9F3C; Thu, 10 Mar 2011 10:40:47 +0100 (CET) Date: Thu, 10 Mar 2011 10:40:47 +0100 (CET) From: Mathieu Peresse To: Gregg Schudel Message-ID: <991103703.53161299750047069.JavaMail.root@zimbra-corp-1-b8> In-Reply-To: <2072705768.52731299749843378.JavaMail.root@zimbra-corp-1-b8> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [213.228.1.121] X-Mailer: Zimbra 6.0.1_GA_1816.UBUNTU8_64 (ZimbraWebClient - SAF3 (Linux)/6.0.1_GA_1816.UBUNTU8_64) Cc: lisp@ietf.org Subject: Re: [lisp] I-D Action:draft-ietf-lisp-10.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: Thu, 10 Mar 2011 09:39:33 -0000 Hi Greg, Joel, ----- "Gregg Schudel" wrote: > I just wanted to get clarification from you. Was your interest in > "contributing" to provide the typo/info below? or was it to get > involved in the LISP Beta network and get some hands-on > experience w/ LISP? > thank you for your interest. We will use LISP internally for our mobile (3GPP) network. To put it briefly, we are implementing [a subset of] it in our CPE boxes, to connect NodeBs to the mobile core network. This mobile network will be an "overlay" (with a separate address space) network on top of the Free.fr core network. We don't have plans to participate in the LISP Beta network for now. Regards, -- Mathieu From gschudel@cisco.com Thu Mar 10 07:12:45 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9A63A69CC for ; Thu, 10 Mar 2011 07:12:45 -0800 (PST) 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 TRDS8hgUrk83 for ; Thu, 10 Mar 2011 07:12:44 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 30C9B3A69E4 for ; Thu, 10 Mar 2011 07:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gschudel@cisco.com; l=833; q=dns/txt; s=iport; t=1299770042; x=1300979642; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gMBzUQ6LEbJyMDRd2Cfwa4tZyKglgIPTBMRmqHmx5Bk=; b=ScUR65kov7I6OtYSlcivun3ugV/CK86k7Vma/5aXpf+1xgdZpIlGN41B 9MamA6g8UX/3xwslsmjYWsaypoD03oJxNK4RUW0oHB0WoU/lcq1q1Mn4t PVy/ZM+Ma3Yu047aO35z4s4+clSYZ9wGlQUSiMPXOwKMG0zxcBv38c9X0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANJ4eE2rRN+J/2dsb2JhbACnAnekYZw8hWIEhSSHHw X-IronPort-AV: E=Sophos;i="4.62,296,1297036800"; d="scan'208";a="273922632" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 10 Mar 2011 15:14:02 +0000 Received: from gschudel-mac-2.local (sjc-vpn5-1032.cisco.com [10.21.92.8]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p2AFE1Ub026492; Thu, 10 Mar 2011 15:14:01 GMT Message-ID: <4D78EAB9.7030506@cisco.com> Date: Thu, 10 Mar 2011 07:14:01 -0800 From: Gregg Schudel Organization: cisco.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mathieu Peresse References: <991103703.53161299750047069.JavaMail.root@zimbra-corp-1-b8> In-Reply-To: <991103703.53161299750047069.JavaMail.root@zimbra-corp-1-b8> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] I-D Action:draft-ietf-lisp-10.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: Thu, 10 Mar 2011 15:12:45 -0000 Much Thanks Mathieu -- cheers gregg On 3/10/11 1:40 AM, Mathieu Peresse wrote: > Hi Greg, Joel, > > ----- "Gregg Schudel" wrote: > >> I just wanted to get clarification from you. Was your interest in >> "contributing" to provide the typo/info below? or was it to get >> involved in the LISP Beta network and get some hands-on >> experience w/ LISP? >> > > thank you for your interest. > > We will use LISP internally for our mobile (3GPP) network. To put it briefly, we are > implementing [a subset of] it in our CPE boxes, to connect NodeBs to the mobile core network. > This mobile network will be an "overlay" (with a separate address space) network on top of the Free.fr core network. > > We don't have plans to participate in the LISP Beta network for now. > > Regards, > From vaf@cisco.com Thu Mar 10 23:36:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7C23A6BA1 for ; Thu, 10 Mar 2011 23:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.004 X-Spam-Level: X-Spam-Status: No, score=-10.004 tagged_above=-999 required=5 tests=[AWL=0.595, 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 E8oU0WUcNhng for ; Thu, 10 Mar 2011 23:36:30 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CEC5A3A6BA0 for ; Thu, 10 Mar 2011 23:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=1667; q=dns/txt; s=iport; t=1299829070; x=1301038670; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HdflLj8uGuoBV87CCLGnsv4nnV5xVH9h+dWotq1eEXE=; b=kRwPVmZnZmAL0/OdiDqWixbmsC2XgtqnGJdlGyyp/9Eg6CEJUSPbfLZP ZaIopV6IHrtSpX21p5QkgTllE1ui6EDO7lS/Np/9BxfgbUxC0iKeyS6YZ tLx+lUiHVJnGkOTr76k8vc/ncGmJsLTZDilllKIDfjOrGK8KKJRgDQtKE c=; X-IronPort-AV: E=Sophos;i="4.62,302,1297036800"; d="scan'208";a="274458360" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 11 Mar 2011 07:37:49 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2B7bnuO001734; Fri, 11 Mar 2011 07:37:49 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 203D0E00E36; Thu, 10 Mar 2011 23:37:48 -0800 (PST) Date: Thu, 10 Mar 2011 23:37:47 -0800 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20110311073747.GA9396@vaf-mac1.cisco.com> References: <4D782073.2050401@joelhalpern.com> <02838D85-255F-4253-86FC-938920F2C6F8@cisco.com> <4D78288D.7060400@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D78288D.7060400@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Fri, 11 Mar 2011 07:36:33 -0000 On Wed, Mar 09, 2011 at 08:25:33PM -0500, Joel M. Halpern wrote: > Reasonable. But we probably need to say this somewhere. > (And I apologize if it already says it and I missed it.) As I understand it, this comment is in the context of asking what checks a Map-Server is expected to perform on the information presented to it by an ETR in a Map-Register message. The current spec says: 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. A Map-Server's configuration should also include a list of the EID- prefixes for which each ETR is 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 added to the registration process. The expectation being that a Map-Server will be configured with the list of EIDs that a particular ETR is permitted to register. When a Map-Register message is received from an ETR RLOC, the Map-Server will verify that the EIDs for which it is attempting to register a mapping are in the list of EIDs configured for that ETR. Is this not sufficiently clear? --Vince From Internet-Drafts@ietf.org Fri Mar 11 02:30:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3513A68B0; Fri, 11 Mar 2011 02:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 Z1mNyq-qdEoN; Fri, 11 Mar 2011 02:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD843A687D; Fri, 11 Mar 2011 02:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110311103001.23659.34160.idtracker@localhost> Date: Fri, 11 Mar 2011 02:30:01 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-map-versioning-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 10:30: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 Map-Versioning Author(s) : L. Iannone, et al. Filename : draft-ietf-lisp-map-versioning-01.txt Pages : 21 Date : 2011-03-11 This document describes the LISP Map-Versioning mechanism, which provides in-packet information about EID-to-RLOC mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating xTRs about modifications of the mappings used to encapsulate packets. The mechanism is transparent to legacy implementations, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by xTRs that do not support the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-01.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-map-versioning-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-11021714.I-D@ietf.org> --NextPart-- From jmh@joelhalpern.com Fri Mar 11 11:04:26 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 085233A6C7B for ; Fri, 11 Mar 2011 11:04:26 -0800 (PST) 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.075, BAYES_00=-2.599, 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 JIotcJcL9TxN for ; Fri, 11 Mar 2011 11:04:25 -0800 (PST) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 23ABD3A6956 for ; Fri, 11 Mar 2011 11:04:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F18254300CD; Fri, 11 Mar 2011 11:05:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.154.181.170] (unknown [129.192.147.67]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 5473543001A; Fri, 11 Mar 2011 11:05:44 -0800 (PST) Message-ID: <4D7A7284.9010601@joelhalpern.com> Date: Fri, 11 Mar 2011 14:05:40 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Vince Fuller References: <4D782073.2050401@joelhalpern.com> <02838D85-255F-4253-86FC-938920F2C6F8@cisco.com> <4D78288D.7060400@joelhalpern.com> <20110311073747.GA9396@vaf-mac1.cisco.com> In-Reply-To: <20110311073747.GA9396@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Fri, 11 Mar 2011 19:04:26 -0000 What Dino described included validating more information (the list of RLOCs was to be included in the message and validated), and included a description of the tradeoff in terms of operability and security with regard to validating that information. If that is what we expect, and if we understand that tradeoff, then we need to say so. Yours, Joel On 3/11/2011 2:37 AM, Vince Fuller wrote: > On Wed, Mar 09, 2011 at 08:25:33PM -0500, Joel M. Halpern wrote: >> Reasonable. But we probably need to say this somewhere. >> (And I apologize if it already says it and I missed it.) > > As I understand it, this comment is in the context of asking what checks > a Map-Server is expected to perform on the information presented to it by > an ETR in a Map-Register message. The current spec says: > > 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. A > Map-Server's configuration should also include a list of the EID- > prefixes for which each ETR is 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 added to the registration process. > > The expectation being that a Map-Server will be configured with the list > of EIDs that a particular ETR is permitted to register. When a Map-Register > message is received from an ETR RLOC, the Map-Server will verify that the > EIDs for which it is attempting to register a mapping are in the list of > EIDs configured for that ETR. > > Is this not sufficiently clear? > > --Vince > From vaf@cisco.com Fri Mar 11 11:41:56 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E903A6806 for ; Fri, 11 Mar 2011 11:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 PsjG2uBvdw9e for ; Fri, 11 Mar 2011 11:41:50 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0482A3A69CA for ; Fri, 11 Mar 2011 11:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=1112; q=dns/txt; s=iport; t=1299872589; x=1301082189; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fuzlEwcMb+fO7PLDHAx4O4Ab36seIOJZ1VrmpLo4Kz0=; b=Kj9GWGK8n+TEncc+LuDP2moyPGfUQXScmpeEg9eCCVgc44h3Sb5caOes alT/F1+bZI/6uYN+EBuw0IaD9FkGj/DsF4OyIiiv7QESqDJ5R71MXYYMa iqcDm8/IXpK8bqW0KpV0Rj9jD9xa6HXu0iRG8YikhePiqKdwmFv4BsAyh 0=; X-IronPort-AV: E=Sophos;i="4.62,304,1297036800"; d="scan'208";a="413779699" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 11 Mar 2011 19:43:07 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2BJh7BS010164; Fri, 11 Mar 2011 19:43:07 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id A2B23E05992; Fri, 11 Mar 2011 11:43:06 -0800 (PST) Date: Fri, 11 Mar 2011 11:43:06 -0800 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20110311194306.GB49339@vaf-mac1.cisco.com> References: <4D782073.2050401@joelhalpern.com> <02838D85-255F-4253-86FC-938920F2C6F8@cisco.com> <4D78288D.7060400@joelhalpern.com> <20110311073747.GA9396@vaf-mac1.cisco.com> <4D7A7284.9010601@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D7A7284.9010601@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Fri, 11 Mar 2011 19:41:56 -0000 On Fri, Mar 11, 2011 at 02:05:40PM -0500, Joel M. Halpern wrote: > What Dino described included validating more information (the list of > RLOCs was to be included in the message and validated), and included a > description of the tradeoff in terms of operability and security with > regard to validating that information. > If that is what we expect, and if we understand that tradeoff, then we > need to say so. In past discussions, I recall the consensus being that it was better to err on the side of flexibility and not require that all possible RLOCs be checked by the Map-Server when an ETR registers. Note that a Map-Server (unless performing proxy replies) doesn't participate in generation or propagation of a Map-Reply so it can't validate the set of RLOCs that an ETR returns; for that reason, it seems kind of pointless to validate them during registration. A separate email exchange with Dino indicated that he is OK with the existing text; I will wait one more day before submitting MS-07 through the Internet Drafts tool in case he wants me to change this. --Vince From jmh@joelhalpern.com Fri Mar 11 11:51:05 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD7C3A6A0B for ; Fri, 11 Mar 2011 11:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, 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 H+EtMoayDxD6 for ; Fri, 11 Mar 2011 11:51:04 -0800 (PST) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id EA7463A6B58 for ; Fri, 11 Mar 2011 11:51:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6118D4300EC; Fri, 11 Mar 2011 11:52:21 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.154.181.170] (unknown [129.192.147.67]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id BC1C64300D8; Fri, 11 Mar 2011 11:52:20 -0800 (PST) Message-ID: <4D7A7D71.50805@joelhalpern.com> Date: Fri, 11 Mar 2011 14:52:17 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Vince Fuller References: <4D782073.2050401@joelhalpern.com> <02838D85-255F-4253-86FC-938920F2C6F8@cisco.com> <4D78288D.7060400@joelhalpern.com> <20110311073747.GA9396@vaf-mac1.cisco.com> <4D7A7284.9010601@joelhalpern.com> <20110311194306.GB49339@vaf-mac1.cisco.com> In-Reply-To: <20110311194306.GB49339@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Fri, 11 Mar 2011 19:51:05 -0000 If we are not expecting the RLOC list to be checked as part of the authentication of the registration, then there clearly is no need to explain the trade-off associated with that. As the working group has not indicated it requires that, I have no objection if it remains absent. Yours, Joel PS: The reason I care is that there are interoperability issues if what the MS expects to validate and what the ETR things are authorization-relevant do not match. This resolution takes care of that potential. On 3/11/2011 2:43 PM, Vince Fuller wrote: > On Fri, Mar 11, 2011 at 02:05:40PM -0500, Joel M. Halpern wrote: >> What Dino described included validating more information (the list of >> RLOCs was to be included in the message and validated), and included a >> description of the tradeoff in terms of operability and security with >> regard to validating that information. >> If that is what we expect, and if we understand that tradeoff, then we >> need to say so. > > In past discussions, I recall the consensus being that it was better to err > on the side of flexibility and not require that all possible RLOCs be checked > by the Map-Server when an ETR registers. > > Note that a Map-Server (unless performing proxy replies) doesn't participate > in generation or propagation of a Map-Reply so it can't validate the set > of RLOCs that an ETR returns; for that reason, it seems kind of pointless > to validate them during registration. > > A separate email exchange with Dino indicated that he is OK with the > existing text; I will wait one more day before submitting MS-07 through > the Internet Drafts tool in case he wants me to change this. > > --Vince > From luigi@net.t-labs.tu-berlin.de Sat Mar 12 06:20:38 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1C23A69B4 for ; Sat, 12 Mar 2011 06:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 6XQxHgLJG7Yx for ; Sat, 12 Mar 2011 06:20:37 -0800 (PST) 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 382693A6868 for ; Sat, 12 Mar 2011 06:20:36 -0800 (PST) Received: from dyn118.net.t-labs.tu-berlin.de (dyn118.net.t-labs.tu-berlin.de [130.149.220.118]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 0F37070015AD for ; Sat, 12 Mar 2011 15:21:56 +0100 (CET) From: Luigi Iannone Content-Type: multipart/alternative; boundary=Apple-Mail-17--490031153 Date: Sat, 12 Mar 2011 15:21:55 +0100 References: <20110312141501.10577.36952.idtracker@localhost> To: lisp@ietf.org Message-Id: <252549B9-D909-4D37-A92E-B3A277A8C786@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [lisp] Fwd: I-D Action:draft-saucez-lisp-security-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, 12 Mar 2011 14:20:38 -0000 --Apple-Mail-17--490031153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 12, March, 2011 3:15:01 PM GMT+01:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-saucez-lisp-security-03.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : LISP Security Threats > Author(s) : D. Saucez, et al. > Filename : draft-saucez-lisp-security-03.txt > Pages : 26 > Date : 2011-03-12 >=20 > This draft analyzes some of the threats against the security of the > Locator/Identifier Separation Protocol and proposes a set of > recommendations to mitigate some of the identified security risks. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-saucez-lisp-security-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-17--490031153 Content-Type: multipart/mixed; boundary=Apple-Mail-18--490031153 --Apple-Mail-18--490031153 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: 12, March, 2011 3:15:01 PM = GMT+01:00
Subject: I-D = Action:draft-saucez-lisp-security-03.txt
Reply-To: internet-drafts@ietf.org
<= /span>

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

Title =           : LISP = Security Threats
Author(s) =       : D. Saucez, et al.
Filename =        : = draft-saucez-lisp-security-03.txt
Pages =           : = 26
= Date =            : = 2011-03-12

This draft analyzes some of the threats against the = security of the
Locator/Identifier Separation Protocol and proposes a = set of
recommendations to mitigate some of the identified security = risks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saucez-lisp-security-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.
= --Apple-Mail-18--490031153 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2011-03-12061403.I-D@ietf.org>

--Apple-Mail-18--490031153 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-18--490031153-- --Apple-Mail-17--490031153-- From dino@cisco.com Sat Mar 12 20:28:02 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D7B3A6AE6 for ; Sat, 12 Mar 2011 20:28:02 -0800 (PST) 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 i83uwVHB5cZu for ; Sat, 12 Mar 2011 20:27:58 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BFF413A6AE0 for ; Sat, 12 Mar 2011 20:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2002; q=dns/txt; s=iport; t=1299990560; x=1301200160; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=Wsaz5DiAFlDJzEM1CUBk+rokJDRDPnvuR07oeSOT1Rg=; b=kRxjRnMmywFljHLnzIuNIwkaobCsBeFIuL41uB0VAo+FYQbHTRnn9N4W esGEGsTC/7S51qNj0T2OZWUm60WepTF55Z0/h/xKwQJeAZ5TIxpbW6fgl M9XU7tvG9ikplCpiJwNzjdCKEEmQVlClcc80FSaPootXT00z8QBxa/ys/ k=; X-IronPort-AV: E=Sophos;i="4.62,309,1297036800"; d="scan'208";a="319846026" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 13 Mar 2011 04:29:20 +0000 Received: from [10.71.1.172] (sjc-vpn7-221.cisco.com [10.21.144.221]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2D4TJL2015856; Sun, 13 Mar 2011 04:29:19 GMT Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4D7A7D71.50805@joelhalpern.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: Sat, 12 Mar 2011 20:29:18 -0800 References: <4D782073.2050401@joelhalpern.com> <02838D85-255F-4253-86FC-938920F2C6F8@cisco.com> <4D78288D.7060400@joelhalpern.com> <20110311073747.GA9396@vaf-mac1.cisco.com> <4D7A7284.9010601@joelhalpern.com> <20110311194306.GB49339@vaf-mac1.cisco.com> <4D7A7D71.50805@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-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: Sun, 13 Mar 2011 04:28:02 -0000 Joel, I was describing what an implementation could do. We shouldn't describe this in the spec. Dino On Mar 11, 2011, at 11:52 AM, Joel M. Halpern wrote: > If we are not expecting the RLOC list to be checked as part of the > authentication of the registration, then there clearly is no need to > explain the trade-off associated with that. As the working group > has not indicated it requires that, I have no objection if it > remains absent. > > Yours, > Joel > > PS: The reason I care is that there are interoperability issues if > what the MS expects to validate and what the ETR things are > authorization-relevant do not match. This resolution takes care of > that potential. > > On 3/11/2011 2:43 PM, Vince Fuller wrote: >> On Fri, Mar 11, 2011 at 02:05:40PM -0500, Joel M. Halpern wrote: >>> What Dino described included validating more information (the list >>> of >>> RLOCs was to be included in the message and validated), and >>> included a >>> description of the tradeoff in terms of operability and security >>> with >>> regard to validating that information. >>> If that is what we expect, and if we understand that tradeoff, >>> then we >>> need to say so. >> >> In past discussions, I recall the consensus being that it was >> better to err >> on the side of flexibility and not require that all possible RLOCs >> be checked >> by the Map-Server when an ETR registers. >> >> Note that a Map-Server (unless performing proxy replies) doesn't >> participate >> in generation or propagation of a Map-Reply so it can't validate >> the set >> of RLOCs that an ETR returns; for that reason, it seems kind of >> pointless >> to validate them during registration. >> >> A separate email exchange with Dino indicated that he is OK with the >> existing text; I will wait one more day before submitting MS-07 >> through >> the Internet Drafts tool in case he wants me to change this. >> >> --Vince >> From vaf@cisco.com Sat Mar 12 20:57:50 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D153A6AE6 for ; Sat, 12 Mar 2011 20:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.111 X-Spam-Level: X-Spam-Status: No, score=-9.111 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_00=-2.599, HTML_COMMENT_SAVED_URL=0.114, 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 g7Pq27WZDdZf for ; Sat, 12 Mar 2011 20:57:46 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BF55A3A68C0 for ; Sat, 12 Mar 2011 20:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=97301; q=dns/txt; s=iport; t=1299992348; x=1301201948; h=date:from:to:subject:message-id:mime-version; bh=USh1NSpK3ELfip7Cke3XyOc7Hnm6IKEvb4/gbBeQhSk=; b=dQsXw3p7flLdhr0IhDXDU/hq6+xssWn+xNRkUFC4nvtJos2QvsoiPxEm DqdQhSQ55Bw98kGwC1yDfR1HrG2gNGS/JZ1x5FtKg1ZnMF9xo86n9VLXt bWFoTVSbJKtUF4lOGFJ8bYeNwTrt/GfjefYfU7rTcfJdKIT5gk6drzx78 k=; X-Files: rfcdiff-ms-06-to-07.html : 91906 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGvde02tJXG+/2dsb2JhbAAuAQGlO1l3pGaOIIxNhWIEhSs X-IronPort-AV: E=Sophos;i="4.62,309,1297036800"; d="html'217?scan'217,208,217";a="277491646" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 13 Mar 2011 04:59:07 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2D4x6sh029433 for ; Sun, 13 Mar 2011 04:59:06 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id E897EE14835; Sat, 12 Mar 2011 20:59:05 -0800 (PST) Date: Sat, 12 Mar 2011 20:59:05 -0800 From: Vince Fuller To: lisp@ietf.org Message-ID: <20110313045905.GA63974@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] [idsubmission@ietf.org: New Version Notification for draft-ietf-lisp-ms-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: Sun, 13 Mar 2011 04:57:50 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is an "rfcdiff" between -06 and -07. Vince and Dino ----- Forwarded message from IETF I-D Submission Tool ----- Date: Sat, 12 Mar 2011 20:49:39 -0800 (PST) From: IETF I-D Submission Tool To: vaf@cisco.com Cc: dino@cisco.com Subject: New Version Notification for draft-ietf-lisp-ms-07 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocAAHvce01AqmIgi2dsb2JhbACEPZR3AQGNDhQBAQEKCwsHEgcgpGaLG49SgSeDRXYEhSuHJw A new version of I-D, draft-ietf-lisp-ms-07.txt has been successfully submitted by Vince Fuller and posted to the IETF repository. Filename: draft-ietf-lisp-ms Revision: 07 Title: LISP Map Server Creation_date: 2011-03-10 WG ID: lisp Number_of_pages: 17 Abstract: This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. The IETF Secretariat. ----- End forwarded message ----- --GvXjxJ+pjyke8COw Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-ms-06-to-07.html" Content-Transfer-Encoding: quoted-printable wdiff draft-ietf-lisp-ms-06.txt draft-ietf-lisp-ms-07= .txt 
Network Working Group                                          V. Fuller
Internet-Draft                                              D. Farinacci
Intended status: Experimental                              cisco Systems
Expires: April 21, September 11, 2011                               March 10=
, 2011                                 October 18, 2010

                            LISP Map Server
                       draft-ietf-lisp-ms-06.tx=
t
                       draft-ietf-lisp-ms-07.=
txt

Abstract

   This draft describes the LISP Map-Server (LISP-MS), a computing
   system which provides a simple simplified LISP protocol i=
nterface 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 reduce i=
mplementation and
   operation
   operational complexity of =
LISP Ingress Tunnel Routers (ITRs) and
   Egress Tunnel Routers (ETRs), the devices that implement the "edge"
   of the LISP infrastructure and which connect directly to LISP-capable
   Internet end sites.

Status of this Memo

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

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

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

   This Internet-Draft will expire on April 21,=
 September 11, 2011.

Copyright Notice

   Copyright (c) 2010 <=
font color=3D"green">2011 IETF Trust and the persons identi=
fied as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Interactions With Other LISP Components  . . . . . . . . . . .  6
     4.1.  ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . .  6
     4.2.  ETR/Map-Server EID Prefix Registration . . . . . . . . . .  7
     4.3.  Map-Server Processing  . . . . . . . . . . . . . . . . . .  8
     4.4.  Map-Resolver Processing  . . . . . . . . . . . . . . . . .  8
       4.4.1.  Anycast Map-Resolver Operation . . . . . . . . . . . .  9 10<=
/font>
   5.  Open Issues and Considerations . . . . . . . . . . . . . . . . 10 11<=
/font>
   6.  Security  IANA Considerations  . . . . . . . . . . . =
. . . . . . . . 11 . . 12
   7.  Security Considerations  . . . . . . .=
 . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . .=
 . . . . . 12
     7.1. 14
     8.1.  Normative References . . . . . . . . . . . . . .=
 . . . . . 12
     7.2. 14
     8.2.  Informative References . . . . . . . . . . . . .=
 . . . . . 12 14
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13 16<=
/font>
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 17<=
/font>

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

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

   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 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 authoritative source (typically, an
      ETR, through static configuration or anot=
her out-of-band via the regis=
tration mechanism
      may be used). described below).  A Map-Server Map-
      Server publishes these mappings in the distributed ma=
pping
      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 carried within an
      Encapsulated Control Message, which has 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 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.  In addition to the set
      of EID-prefixes to register, the message includes one or more
      RLOCs to be be used by the Map-Server when forwarding Map-Requests
      (re-formatted as Encapsulated Map-Requests) received through the
      database mapping system.  An ETR may re=
quest that the Map-Server
      answer Map-Requests on its behalf by setting the "proxy-map-reply"
      flag (P-bit) in the message.

   Map-Notify message:   a LISP message sent by a Map-Server to an ETR
      to confirm that a Map-Register has been received and processed.
      An ETR requests that a Map-Notify be returned by setting the
      "want-map-notify" or "M" bit in the Map-Register message.

   For definitions of other terms, notably Map-Request, Map-Reply,
   Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
   consult the LISP specification [LISP].

3.  Basic Overview

   A Map-Server is a device which publishes EID-prefix information on
   behalf of ETRs and connects to the LISP distributed mapping database
   system to help answer LISP Map-Requests seeking the RLOCs for those
   EID-prefixes.  To publish its EID-prefixes, an ETR periodically sends
   Map-Register messages to the Map-Server.  A Map-Register message
   contains a list of EID-prefixes plus a set of RLOCs that can be used
   to reach the ETR when a Map-Server needs to forward a Map-Request to
   it.

   When LISP+ALT is used as the mapping database, a Map-Server connects
   to 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 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, a Map-Resolver may operate in a caching mode, where it
   saves information about outsanding Map-Reqeusts, originates new Map-
   Requests to the correct ETR(s), accepts and caches the Map-Replies,
   and finally forwards the Map-Replies to the original ITRs.  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

   Note that a single device =
can implement the functions of both a Map-
   Server and a Map-Resolver.  As is the case w=
ith Map-Resolver and, in many=
 cases, the DNS, however,
   operational simplicity argues for keeping those function=
s separate. will be
   co-located in that way.

4.  Interactions With Other LISP Components

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 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
      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 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 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.  There would be, for
   example, no need for such an ITR to send a 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.  A
   Map-Server's configuration should also include a list of the EID-
   prefixes for which each ETR is 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 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.

   An ETR may request that a Map-Server expli=
citly acknowledge receipt
   and processing of a Map-Register message by setting the "want-map-
   notify" ("M" bit) flag.  A Map-Server that receives a Map-Register
   with this flag set will respond with a Map-Notify message.  Typical
   use of this flag by an ETR would be to set it on Map-Requests sent
   during the initial "quick registration" with a Map Server but then
   set it only occasionally during steady-state maintenance of its
   association with that Map Server.

   Note that a one-minute minimum registration interval during steady
   state
   maintenance of an ETR-MS a=
ssociation 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 may also request, by setting the "p=
roxy-map-reply" flag
   (P-bit) in the Map-Regsiter message, that a Map-Server answer Map-
   Requests instead of forwarding them to the ETR.  See [LISP] for
   details on how the Map-Server sets certain flags (such as those
   indicating whether the message is authoratative and how returned
   locators should be treated) when sending a Map-Reply on behalf of an
   ETR.

   An ETR which uses a Map-Server to publish its EID-to-RLO=
C mappings
   does not need to participate further in the mapping database
   protocol(s).  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.

4.3.  Map-Server Processing

   The operation of

   Once a Map-Server, once it =
Map-Server has EID-prefixes registered by its client ETRs, =
is quite simple. it
   can accept and process Map-Requests for them.  In respon=
se to a Map-Request Map-
   Request (received over the ALT if LISP+ALT is in use), t=
he 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 resulting Encapsulated Map-Request t=
o a matching ETR.  It does
   not otherwise alter the Map-Request so any Map-Reply sent by the ETR
   is returned to the RLOC in the Map-Request, not to the Map-Server.
   Unless also acting as a Map-Resolver, a Map-Server should never
   receive Map-Replies; any such messages should be discarded without
   response, perhaps accompanied by logging of a diagnostic message if
   the rate of Map-Replies is suggestive of malicious traffic.

   A Map-Server may also receive a Map-Reques=
t that is contained inside
   of an Encapsulated Control Message (an Encapsulated Map-Request) with
   the "Security" bit (S-bit) set.  It processes the security parameters
   as described in [LISP-SEC] then generates an Encapsulated Map-Request
   to be sent as described above.

   Note that a Map-Server that is sending a Map-Reply on behalf of an
   ETR must perform security processing for that ETR as well; see
   [LISP-SEC] for details.

4.4.  Map-Resolver Processing

   In response to

   Upon receipt of an Encapsu=
lated Map-Request, a Map-Resolver de-
   capsulates the enclosed me=
ssage then checks searches for the requested EID
   in its local database of mapping entries (statically con=
figured,
   cached, or learned from associated ETRs).  If it finds a matching
   entry, it returns a 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 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.  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.  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.

   If a Map-Resolver receives a Map-Request c=
ontained in an Encapsulated
   Control Message (an Encapsulated Map-Request) with the "security"
   option (S-Bit) set, additional processing is required.  It extracts
   the enclosed Map-Request and uses the attached security paramaters to
   generate a new Encapsulated Control Message containing the original
   Map-Rqeuest and additional signature information used to protect both
   the Map-Request and the Map-Reply that will be generated by the
   destination ETR or Map-Server.  The outgoing message will have the
   S-bit set, will use the requested EID as its outer header destination
   IP address plus Map-Resolver RLOC as source IP address, and will
   include security parameters added by the Map-Resolver.  See
   [LISP-SEC] for details of the checks that are performed and the
   security information that is added during the de-encapsulation and
   re-encapsulation process.

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 use anycast
   addresses as 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 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 b=
etween 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.  IANA Considerations

   This document makes no request of the IANA.

7.  Security Considerations

   The 2-way nonce exchange documented in [LISP] can be used to avoid
   ITR spoofing attacks.

   To publish an 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 support use of HMAC-
   SHA-1-96 [RFC2404]
   SHA-1-160 [RFC2104] and sh=
ould support use of HMAC-SHA-128-256
   [RFC4634]. HMAC-SHA-256-128
   [RFC4634] (SHA-256 truncated to 128 bits).  Key changes =
are initially
   expected to be manual though a key-chaining scheme may be 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 exchan=
ge, where an ITR sends a
   Map-Request through a Map-Resolver, mapping database infrastructure,
   and Map-Server while an ETR returns

   [LISP-SEC] defines a Map-Reply directly to the ITR
   makes it difficult mechani=
sm for the ITR to verify that t=
he returned EID-prefix
   length matches that registered by the ETR with, =
providing origin authentication,
   integrity, anti-reply protection, and therefore checked
   by, a Map-Server. preventi=
on of man-in-the-middle
   and "overclaiming" attacks on the Map-Request/Map-Reply exchange.=


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

8.  References

7.1.

8.1.  Normative References

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-05.txt=

              draft-ietf-lisp-alt-06.txt (work in progress),
              October 2010. March 2011.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-09.txt
              draft-ietf-lisp-10.txt (work in progress), October 2010. March 2011.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2404]  Madson, C.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Glenn, "The Use of HMAC-SHA-=
1-96 within
              ESP and AH", Ca=
netti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2404, November 1998. 2104,
              February 1997.

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

7.2.

8.2.  Informative References

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

   [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, "LISP
              Mobile Node Architecture", draft-=
meyer-lisp-mn-03.txt draft-me=
yer-lisp-mn-04.txt
              (work in progress), August 2010.<=
/font> February 2011.

   [LISP-SEC]
              Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
              Bonaventure, "LISP-Security", draft-maino-lisp-sec-00.txt
              (work in progress), March 2011.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-08.txt (work in progress),
              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,
   Fabio Maino, and members o=
f 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 may 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
3D"ZoomInto:=
--GvXjxJ+pjyke8COw-- From Internet-Drafts@ietf.org Sat Mar 12 21:00:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FEB3A6AE6; Sat, 12 Mar 2011 21:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, 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 fIeEvbCXPDGm; Sat, 12 Mar 2011 21:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2983A686E; Sat, 12 Mar 2011 21:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110313050001.31139.33221.idtracker@localhost> Date: Sat, 12 Mar 2011 21:00:01 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-ms-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: Sun, 13 Mar 2011 05:00: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 Map Server Author(s) : V. Fuller, D. Farinacci Filename : draft-ietf-lisp-ms-07.txt Pages : 17 Date : 2011-03-12 This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-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-ms-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-12204938.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 12:00:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09C03A6B44; Mon, 14 Mar 2011 12:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, 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 KBZxnQ0dWKdJ; Mon, 14 Mar 2011 12:00:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AEE73A6B1F; Mon, 14 Mar 2011 12:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314190002.16376.77786.idtracker@localhost> Date: Mon, 14 Mar 2011 12:00:02 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-mib-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:00:04 -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 MIB Author(s) : G. Schudel, et al. Filename : draft-ietf-lisp-mib-01.txt Pages : 43 Date : 2011-03-14 This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-mib-01.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-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14115758.I-D@ietf.org> --NextPart-- From luigi@net.t-labs.tu-berlin.de Mon Mar 14 13:20:43 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31E13A6B57 for ; Mon, 14 Mar 2011 13:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 1L9rFp8VZ+ER for ; Mon, 14 Mar 2011 13:20:42 -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 46C6F3A6AAA for ; Mon, 14 Mar 2011 13:20:42 -0700 (PDT) Received: from [192.168.2.101] (p4FC25AF1.dip.t-dialin.net [79.194.90.241]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id DEFCA700D28D for ; Mon, 14 Mar 2011 21:22:04 +0100 (CET) From: Luigi Iannone Content-Type: multipart/alternative; boundary=Apple-Mail-3--295623047 Date: Mon, 14 Mar 2011 21:22:03 +0100 References: <20110314201502.20551.70416.idtracker@localhost> To: lisp@ietf.org Message-Id: <677A1B09-0A81-4410-9D41-64F53744BFBD@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [lisp] Fwd: I-D Action:draft-meyer-lisp-eid-block-02.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, 14 Mar 2011 20:20:43 -0000 --Apple-Mail-3--295623047 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 14, March, 2011 9:15:02 PM GMT+01:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-meyer-lisp-eid-block-02.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : LISP EID Block > Author(s) : L. Iannone, et al. > Filename : draft-meyer-lisp-eid-block-02.txt > Pages : 7 > Date : 2011-03-14 >=20 > This is a direction to IANA to allocate a /16 IPv6 prefix for use with > the Locator/ID Separation Protocol (LISP). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-meyer-lisp-eid-block-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-3--295623047 Content-Type: multipart/mixed; boundary=Apple-Mail-4--295623047 --Apple-Mail-4--295623047 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: 14, March, 2011 9:15:02 PM = GMT+01:00
Subject: I-D = Action:draft-meyer-lisp-eid-block-02.txt
Reply-To: internet-drafts@ietf.org
<= /span>

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

Title =           : LISP EID = Block
= Author(s)       : L. Iannone, et = al.
= Filename        : = draft-meyer-lisp-eid-block-02.txt
Pages =           : 7
Date =            : = 2011-03-14

This is a direction to IANA to allocate a /16 IPv6 = prefix for use with
the Locator/ID Separation Protocol = (LISP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-meyer-lisp-eid-block-02.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.
= --Apple-Mail-4--295623047 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2011-03-14130636.I-D@ietf.org>

--Apple-Mail-4--295623047 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-4--295623047-- --Apple-Mail-3--295623047-- From gschudel@cisco.com Mon Mar 14 14:42:43 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11783A6BC2 for ; Mon, 14 Mar 2011 14:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.051 X-Spam-Level: X-Spam-Status: No, score=-9.051 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, 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 uMJ9Ez9I-CaV for ; Mon, 14 Mar 2011 14:42:33 -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 00E7A3A6F40 for ; Mon, 14 Mar 2011 14:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gschudel@cisco.com; l=152628; q=dns/txt; s=iport; t=1300139035; x=1301348635; h=message-id:date:from:mime-version:to:subject; bh=tnzpQVYvTqkl1Nn4g909p6Wzsp9e30hyMo7OiQZmYBM=; b=TG7Bfre7mMFYGJCi4zTL4Hhn6MwY3SQ6ZanD/ssJ/KClF16y8z7afxZC n+SrCR0t+QTUyrbcDJRJ0TI+bMfwRzDFWWefCBBbS2G/p0qZH4wfyzYWS G6ErJRgFQKKxuMMDgQIKgxIm41V5AqikNG2e8ab01GIqSJK2afhtOTWnK Y=; X-Files: Attached Message Part, wdiff draft-ietf-lisp-mib-00.txt draft-ietf-lisp-mib-01.html : 124, 109553 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4MAP4ofk2tJXHA/2dsb2JhbACmDQZxW6QRnDSCfIJmBIUrhyc X-IronPort-AV: E=Sophos;i="4.62,318,1297036800"; d="txt'208?html'208,217?scan'208,217,208,217";a="414289991" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-1.cisco.com with ESMTP; 14 Mar 2011 21:43:48 +0000 Received: from gschudel-mac-2.local (sjc-vpn3-936.cisco.com [10.21.67.168]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2ELhhw5024108 for ; Mon, 14 Mar 2011 21:43:43 GMT Message-ID: <4D7E8C0E.8070307@cisco.com> Date: Mon, 14 Mar 2011 14:43:42 -0700 From: Gregg Schudel Organization: cisco.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp@ietf.org Content-Type: multipart/mixed; boundary="------------060706050807070709020401" Subject: [lisp] Fwd: I-D Action:draft-ietf-lisp-mib-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:42:43 -0000 This is a multi-part message in MIME format. --------------060706050807070709020401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI - New version, "draft-ietf-lisp-mib-01.txt" has been submitted. For info, I've also attached a "diff" -- Mainly this version corrects typos and mib convention errors. cheers gregg -------- Original Message -------- Subject: [lisp] I-D Action:draft-ietf-lisp-mib-01.txt Date: Mon, 14 Mar 2011 12:00:02 -0700 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: lisp@ietf.org 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 MIB Author(s) : G. Schudel, et al. Filename : draft-ietf-lisp-mib-01.txt Pages : 43 Date : 2011-03-14 This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-mib-01.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. --------------060706050807070709020401 Content-Type: Message/External-body; name="draft-ietf-lisp-mib-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-mib-01.txt" Content-Type: text/plain Content-ID: <2011-03-14115758.I-D@ietf.org> --------------060706050807070709020401 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --------------060706050807070709020401 Content-Type: text/html; name="wdiff draft-ietf-lisp-mib-00.txt draft-ietf-lisp-mib-01.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="wdiff draft-ietf-lisp-mib-00.txt draft-ietf-lisp-mib-01.html" CjwhLS0gc2F2ZWQgZnJvbSB1cmw9KDAwMjkpaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2Rp ZmYgLS0+CjxodG1sPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPjx0aXRsZT53ZGlmZiBkcmFm dC1pZXRmLWxpc3AtbWliLTAwLnR4dCBkcmFmdC1pZXRmLWxpc3AtbWliLTAxLnR4dDwvdGl0 bGU+PC9oZWFkPjxib2R5Pgo8cHJlPgpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcuIFNjaHVkZWwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBB LiBKYWluCkludGVuZGVkIHN0YXR1czogRXhwZXJpbWVudGFsICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFYuIE1vcmVubwpFeHBpcmVzOiA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPkp1bHkgOSw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Imdy ZWVuIj5TZXB0ZW1iZXIgMTIsPC9mb250Pjwvc3Ryb25nPiAyMDExICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjaXNjbyBTeXN0ZW1zCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9 InJlZCI+SmFudWFyeSA1LDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29s b3I9ImdyZWVuIj5NYXJjaCAxMSw8L2ZvbnQ+PC9zdHJvbmc+IDIwMTEKCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTElTUCBNSUIKICAgICAgICAgICAgICAgICAgICAgICAg IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+ZHJhZnQtaWV0Zi1saXNwLW1pYi0wMDwvZm9u dD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29s b3I9ImdyZWVuIj5kcmFmdC1pZXRmLWxpc3AtbWliLTAxPC9mb250Pjwvc3Ryb25nPgoKQWJz dHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBtYW5hZ2VkIG9iamVjdHMgZm9yIHRo ZSBMb2NhdG9yL0lEIFNlcGFyYXRpb24KICAgUHJvdG9jb2wgKExJU1ApLiAgVGhlc2Ugb2Jq ZWN0cyBwcm92aWRlIGluZm9ybWF0aW9uIHVzZWZ1bCBmb3IKICAgbW9uaXRvcmluZyBMSVNQ IGRldmljZXMsIGluY2x1ZGluZyBiYXNpYyBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uLAog ICBMSVNQIHN0YXR1cywgYW5kIG9wZXJhdGlvbmFsIHN0YXRpc3RpY3MuCgpTdGF0dXMgb2Yg VGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxs IGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1Ag NzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBh cyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBE cmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50 Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQog ICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+SnVseSA5LDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9u dCBjb2xvcj0iZ3JlZW4iPlNlcHRlbWJlciAxMiw8L2ZvbnQ+PC9zdHJvbmc+IDIwMTEuCgpD b3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTEgSUVURiBUcnVzdCBhbmQg dGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFs bCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQ IDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcg dG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2Ut aW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMg ZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHks IGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJl c3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQg ZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNl bnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBM ZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwog ICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBD b250ZW50cwoKICAgMS4gIFJlcXVpcmVtZW50cyBOb3RhdGlvbiAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgIDIuICBJbnRyb2R1Y3Rpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAzLiAg VGhlIEludGVybmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDQKICAgNC4gIERlZmluaXRpb24gb2YgVGVybXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDUuICBMSVNQIE1JQiBPYmplY3Rp dmVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICA2 LiAgU3RydWN0dXJlIG9mIExJU1AgTUlCIE1vZHVsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDcKICAgICA2LjEuICBPdmVydmlldyBvZiBEZWZpbmVkIE5vdGlmaWNh dGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgNi4yLiAgT3ZlcnZpZXcg b2YgRGVmaW5lZCBUYWJsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwog ICA3LiAgTElTUCBNSUIgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5EZWZpbml0aW9uPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+RGVmaW5pdGlvbnM8 L2ZvbnQ+PC9zdHJvbmc+IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA4CiAgIDguICBSZWxhdGlvbnNoaXAgdG8gT3RoZXIgTUlCIE1vZHVsZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjM3PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+NDA8L2ZvbnQ+PC9z dHJvbmc+CiAgICAgOC4xLiAgTUlCIG1vZHVsZXMgcmVxdWlyZWQgZm9yIElNUE9SVFMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjM3PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+NDA8L2ZvbnQ+PC9z dHJvbmc+CiAgIDkuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjM3PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+NDA8L2ZvbnQ+PC9z dHJvbmc+CiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjM3PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+NDA8L2ZvbnQ+PC9z dHJvbmc+CiAgIDExLiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjM4PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+NDE8L2ZvbnQ+PC9z dHJvbmc+CiAgICAgMTEuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjM4PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+NDE8L2ZvbnQ+PC9z dHJvbmc+CiAgICAgMTEuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjM5PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+NDI8L2ZvbnQ+PC9z dHJvbmc+CiAgIEFwcGVuZGl4IEEuICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPkNoYW5n ZSBMb2cgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM5CiAg IEFwcGVuZGl4IEIuPC9mb250Pjwvc3RyaWtlPiAgT3BlbiBJc3N1ZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVk Ij4zOTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjQyPC9m b250Pjwvc3Ryb25nPgogICBBcHBlbmRpeCA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPkMu PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+Qi48L2ZvbnQ+ PC9zdHJvbmc+ICBBY2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjQwPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+NDI8L2ZvbnQ+PC9zdHJvbmc+CgoxLiAg UmVxdWlyZW1lbnRzIE5vdGF0aW9uCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1Qg Tk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0 aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4g W1JGQzIxMTldLgoKMi4gIEludHJvZHVjdGlvbgoKICAgVGhpcyBkcmFmdCBkZXNjcmliZXMg dGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSAoTUlCKSBtb2R1bGUgZm9yCiAgIHVz ZSB3aXRoIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbHMgaW4gdGhlIEludGVybmV0IGNv bW11bml0eS4KICAgU3BlY2lmaWNhbGx5LCB0aGUgTUlCIGZvciBtYW5hZ2luZyBMb2NhdG9y L0lEIFNlcGFyYXRpb24gUHJvdG9jb2wKICAgKExJU1ApIGRldmljZXMgaXMgZGVzY3JpYmVk LgoKICAgTElTUCBbTElTUF0gc3BlY2lmaWVzIGEgbmV0d29yay1iYXNlZCBhcmNoaXRlY3R1 cmUgYW5kIG1lY2hhbmlzbXMKICAgdGhhdCBpbXBsZW1lbnQgYSBuZXcgc2VtYW50aWMgZm9y IElQIGFkZHJlc3NpbmcgdXNpbmcgdHdvIHNlcGFyYXRlCiAgIG5hbWUgc3BhY2VzOiBFbmRw b2ludCBJZGVudGlmaWVycyAoRUlEcyksIHVzZWQgd2l0aGluIHNpdGVzLCBhbmQKICAgUm91 dGluZyBMb2NhdG9ycyAoUkxPQ3MpLCB1c2VkIG9uIHRoZSB0cmFuc2l0IG5ldHdvcmtzIHRo YXQgbWFrZSB1cAogICB0aGUgSW50ZXJuZXQgaW5mcmFzdHJ1Y3R1cmUuICBUbyBhY2hpZXZl IHRoaXMgc2VwYXJhdGlvbiwgTElTUAogICBkZWZpbmVzIHByb3RvY29sIG1lY2hhbmlzbXMg Zm9yIG1hcHBpbmcgZnJvbSBFSURzIHRvIFJMT0NzLiAgSW4KICAgYWRkaXRpb24sIExJU1Ag YXNzdW1lcyB0aGUgZXhpc3RlbmNlIG9mIGEgZGF0YWJhc2UgdG8gc3RvcmUgYW5kCiAgIGds b2JhbGx5IHByb3BhZ2F0ZSB0aG9zZSBtYXBwaW5ncyBbTElTUC1NU10gW0xJU1AtQUxUXS4K CiAgIEZyb20gYSBkYXRhIHBsYW5lIHBlcnNwZWN0aXZlLCBMSVNQIHRyYWZmaWMgaXMgaGFu ZGxlZCBleGNsdXNpdmVseSBhdAogICB0aGUgbmV0d29yayBsYXllciBieSBkZXZpY2VzIHBl cmZvcm1pbmcgSW5ncmVzcyBUdW5uZWwgUm91dGVyIChJVFIpCiAgIGFuZCBFZ3Jlc3MgVHVu bmVsIFJvdXRlciAoRVRSKSBMSVNQIGZ1bmN0aW9ucy4gIERhdGEgcGxhbmUgb3BlcmF0aW9u cwogICBwZXJmb3JtZWQgYnkgdGhlc2UgZGV2aWNlcyBhcmUgZGVzY3JpYmVkIGluIFtMSVNQ XS4gIEFkZGl0aW9uYWxseSwKICAgZGF0YSBwbGFuZSBpbnRlcndvcmtpbmcgYmV0d2VlbiBs ZWdhY3kgKEludGVybmV0KSBhbmQgTElTUCBzaXRlcyBpcwogICBpbXBsZW1lbnRlZCBieSBk ZXZpY2VzIHBlcmZvcm1pbmcgUHJveHkgSVRSIChQSVRSKSBhbmQgUHJveHkgRVRSCiAgIChQ RVRSKSBmdW5jdGlvbnMuICBUaGUgZGF0YSBwbGFuZSBvcGVyYXRpb25zIG9mIHRoZXNlIGRl dmljZXMgaXMKICAgZGVzY3JpYmVkIGluIFtJTlRFUldPUktdLgoKICAgRnJvbSBhIGNvbnRy b2wgcGxhbmUgcGVyc3BlY3RpdmUsIExJU1AgZW1wbG95cyBtZWNoYW5pc21zIHJlbGF0ZWQg dG8KICAgY3JlYXRpbmcsIG1haW50YWluaW5nLCBhbmQgcmVzb2x2aW5nIG1hcHBpbmdzIGZy b20gRUlEcyB0byBSTE9Dcy4KICAgTElTUCBJVFJzLCBFVFJzLCBQSVRScywgYW5kIFBFVFJz IHBlcmZvcm0gc3BlY2lmaWMgY29udHJvbCBwbGFuZQogICBmdW5jdGlvbnMsIGFuZCB0aGVz ZSBjb250cm9sIHBsYW5lIG9wZXJhdGlvbnMgYXJlIGRlc2NyaWJlZCBpbgogICBbTElTUF0u ICBBZGRpdGlvbmFsbHksIExJU1AgaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlcyBzdXBwb3J0aW5n IExJU1AKICAgY29udHJvbCBwbGFuZSBmdW5jdGlvbmFsaXR5IGluY2x1ZGUgTWFwLVNlcnZl cnMgYW5kIE1hcC1SZXNvbHZlcnMsCiAgIGFuZCB0aGUgY29udHJvbCBwbGFuZSBvcGVyYXRp b25zIG9mIHRoZXNlIGRldmljZXMgYXJlIGRlc2NyaWJlZCBpbgogICBbTElTUC1NU10uICBG aW5hbGx5LCB3aGlsZSBub3Qgc3BlY2lmaWNhbGx5IHJlcXVpcmVkLCB0aGlzIGRvY3VtZW50 CiAgIGFzc3VtZXMgdGhhdCBhIExJU1ArQUxUIGRhdGFiYXNlIG1hcHBpbmcgaW5mcmFzdHJ1 Y3R1cmUgZXhpc3RzIGFzCiAgIHBhcnQgb2YgdGhlIExJU1AgY29udHJvbCBwbGFuZS4gIFRo ZSBjb250cm9sIHBsYW5lIG9wZXJhdGlvbnMgb2YgdGhlCiAgIEFMVCBhcmUgZGVzY3JpYmVk IGluIFtMSVNQLUFMVF0uICBOb3RlIHRoYXQgdGhpcyBNSUIgZG9lcyBub3QgcHJvdmlkZQog ICBzdXBwb3J0IGZvciB0aGUgQUxUIHNpbmNlIEFMVCBzdGF0aXN0aWNzIG1heSBiZSBvYnRh aW5lZCB0aHJvdWdoCiAgIGV4aXN0aW5nIEJHUCBhbmQgdHVubmVsIE1JQnMuCgozLiAgVGhl IEludGVybmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrCgogICBGb3IgYSBkZXRh aWxlZCBvdmVydmlldyBvZiB0aGUgZG9jdW1lbnRzIHRoYXQgZGVzY3JpYmUgdGhlIGN1cnJl bnQKICAgSW50ZXJuZXQtU3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmssIHBsZWFzZSBy ZWZlciB0byBzZWN0aW9uIDcgb2YKICAgUkZDIDM0MTAgW1JGQzM0MTBdLgoKICAgTWFuYWdl ZCBvYmplY3RzIGFyZSBhY2Nlc3NlZCB2aWEgYSB2aXJ0dWFsIGluZm9ybWF0aW9uIHN0b3Jl LCB0ZXJtZWQKICAgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSBvciBNSUIuICBN SUIgb2JqZWN0cyBhcmUgZ2VuZXJhbGx5CiAgIGFjY2Vzc2VkIHRocm91Z2ggdGhlIFNpbXBs ZSBOZXR3b3JrIE1hbmFnZW1lbnQgUHJvdG9jb2wgKFNOTVApLgogICBPYmplY3RzIGluIHRo ZSBNSUIgYXJlIGRlZmluZWQgdXNpbmcgdGhlIG1lY2hhbmlzbXMgZGVmaW5lZCBpbiB0aGUK ICAgU3RydWN0dXJlIG9mIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gKFNNSSkuICBUaGlzIG1l bW8gc3BlY2lmaWVzIGEgTUlCCiAgIG1vZHVsZSB0aGF0IGlzIGNvbXBsaWFudCB0byB0aGUg U01JdjIsIHdoaWNoIGlzIGRlc2NyaWJlZCBpbiBTVEQgNTgsCiAgIFJGQyAyNTc4IFtSRkMy NTc4XSwgU1REIDU4LCBSRkMgMjU3OSBbUkZDMjU3OV0gYW5kIFNURCA1OCwgUkZDIDI1ODAK ICAgW1JGQzI1ODBdLgoKNC4gIERlZmluaXRpb24gb2YgVGVybXMKCiAgIDxzdHJpa2U+PGZv bnQgY29sb3I9InJlZCI+Um91dGluZyBMb2NhdG9yIChSTE9DKTogIGEgMzItYml0IChmb3Ig SVB2NCkgb3IgMTI4LWJpdCAoZm9yIElQdjYpCiAgICAgIHZhbHVlIHVzZWQgaW4gdGhlIHNv dXJjZSBhbmQgZGVzdGluYXRpb24gYWRkcmVzcyBmaWVsZHMgb2YgdGhlCiAgICAgIHNlY29u ZCAob3V0ZXItbW9zdCkgSVAgaGVhZGVyIG9mIGEgTElTUCBwYWNrZXQuICBSTE9DIGFkZHJl c3NlcwogICAgICBhcmUgYWxsb2NhdGVkIHRvIGFuIGVncmVzcyB0dW5uZWwgcm91dGVyIChF VFIpIGFuZCBudW1iZXJlZCBmcm9tCiAgICAgIHRvcG9sb2dpY2FsbHktYWdncmVnYXRhYmxl IGJsb2NrcyBhc3NpZ25lZCB0byBhIHNpdGUgYXQgZWFjaCBwb2ludAogICAgICB0byB3aGlj aCBpdCBhdHRhY2hlcyB0byB0aGUgZ2xvYmFsIEludGVybmV0LjwvZm9udD48L3N0cmlrZT4K CiAgIEVuZHBvaW50IElEIChFSUQpOiAgYSAzMi1iaXQgKGZvciBJUHY0KSBvciAxMjgtYml0 IChmb3IgSVB2NikgdmFsdWUKICAgICAgdXNlZCBpbiB0aGUgc291cmNlIGFuZCBkZXN0aW5h dGlvbiBhZGRyZXNzIGZpZWxkcyBvZiB0aGUgZmlyc3QKICAgICAgKGlubmVyLW1vc3QpIElQ IGhlYWRlciBvZiBhIExJU1AgcGFja2V0LiAgQSBzb3VyY2UgRUlEIGlzCiAgICAgIGFsbG9j YXRlZCB0byBhIGhvc3QgZnJvbSBhbiBFSUQtcHJlZml4IGJsb2NrIGFzc29jaWF0ZWQgd2l0 aCB0aGUKICAgICAgc2l0ZSB3aGVyZSB0aGUgaG9zdCBpcyBsb2NhdGVkLiAgQSBob3N0IGRl dGVybWluZXMgYSBkZXN0aW5hdGlvbgogICAgICBFSUQgaW4gdGhlIHNhbWUgd2F5IHRoYXQg aXQgZGV0ZXJtaW5lcyBhIGRlc3RpbmF0aW9uIGFkZHJlc3MKICAgICAgdG9kYXksIGZvciBl eGFtcGxlIHRocm91Z2ggYSBETlMgbG9va3VwIG9yIFNJUCBleGNoYW5nZS4KCiAgIDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj5Sb3V0aW5nIExvY2F0b3IgKFJMT0MpOiAgYSAzMi1i aXQgKGZvciBJUHY0KSBvciAxMjgtYml0IChmb3IgSVB2NikKICAgICAgdmFsdWUgdXNlZCBp biB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBhZGRyZXNzIGZpZWxkcyBvZiB0aGUKICAg ICAgc2Vjb25kIChvdXRlci1tb3N0KSBJUCBoZWFkZXIgb2YgYSBMSVNQIHBhY2tldC4gIFJM T0MgYWRkcmVzc2VzCiAgICAgIGFyZSBhbGxvY2F0ZWQgdG8gYW4gZWdyZXNzIHR1bm5lbCBy b3V0ZXIgKEVUUikgYW5kIG51bWJlcmVkIGZyb20KICAgICAgdG9wb2xvZ2ljYWxseS1hZ2dy ZWdhdGFibGUgYmxvY2tzIGFzc2lnbmVkIHRvIGEgc2l0ZSBhdCBlYWNoIHBvaW50CiAgICAg IHRvIHdoaWNoIGl0IGF0dGFjaGVzIHRvIHRoZSBnbG9iYWwgSW50ZXJuZXQuPC9mb250Pjwv c3Ryb25nPgoKICAgRUlELXRvLVJMT0MgTWFwLUNhY2hlOiAgYSBzaG9ydC1saXZlZCwgb24t ZGVtYW5kIHRhYmxlIG1haW50YWluZWQKICAgICAgbG9jYWxseSBpbiBhbiBJVFIgb3IgUElU UiB0aGF0IHN0b3JlcywgdHJhY2tzLCBhbmQgaXMgcmVzcG9uc2libGUKICAgICAgZm9yIHRp bWluZy1vdXQgYW5kIG90aGVyd2lzZSB2YWxpZGF0aW5nIEVJRC10by1STE9DIG1hcHBpbmdz LgogICAgICBUaGlzIHRhYmxlIGlzIGRpc3RpbmN0IGZyb20gdGhlIGZ1bGwgImRhdGFiYXNl IiBvZiBFSUQtdG8tUkxPQwogICAgICBtYXBwaW5ncyBpbiB0aGF0IGl0IGlzIGR5bmFtaWMg YW5kIHJlbGF0aXZlbHkgc21hbGwuICBBdCBhIGdpdmVuCiAgICAgIG1vbWVudCBpbiB0aW1l LCBpdCBjb25zaXN0cyBvbmx5IG9mIGVudHJpZXMgZm9yIHRob3NlIHNpdGVzIHRvCiAgICAg IHdoaWNoIHRoZSBJVFIgb3IgUElUUiBpcyBjdXJyZW50bHkgY29tbXVuaWNhdGluZyBvciBo YXMKICAgICAgY29tbXVuaWNhdGVkIHdpdGggd2l0aGluIHRoZSBjb25maWd1cmVkIFRUTCBw ZXJpb2QuCgogICBFSUQtdG8tUkxPQyBNYXBwaW5nLURhdGFiYXNlOiAgYSBnbG9iYWwgZGlz dHJpYnV0ZWQgZGF0YWJhc2UgdGhhdAogICAgICBjb250YWlucyBhbGwga25vd24gRUlELXRv LVJMT0MgbWFwcGluZ3MuICBFYWNoIHBvdGVudGlhbCBFVFIKICAgICAgdHlwaWNhbGx5IGNv bnRhaW5zIGEgc21hbGwgcGllY2Ugb2YgdGhlIGRhdGFiYXNlIGNvbnNpc3Rpbmcgb2YKICAg ICAgb25seSB0aGUgRUlELXRvLVJMT0MgbWFwcGluZ3MgZm9yIHRoZSBFSUQgcHJlZml4KGVz KSBmb3Igd2hpY2ggdGhlCiAgICAgIEVUUiBpcyAiYXV0aG9yaXRhdGl2ZSIgYW5kIHRoZSBS TE9DKHMpIGJ5IHdoaWNoIHRob3NlIEVJRAogICAgICBwcmVmaXgoZXMpIGFyZSByZWFjaGFi bGUgZnJvbSB0aGUgZ2xvYmFsIEludGVybmV0LgoKICAgSW5ncmVzcyBUdW5uZWwgUm91dGVy IChJVFIpOiAgYSByb3V0ZXIgdGhhdCBhY2NlcHRzIGFuIElQIHBhY2tldCB3aXRoCiAgICAg IGEgc2luZ2xlIElQIGhlYWRlciAobW9yZSBwcmVjaXNlbHksIGFuIElQIHBhY2tldCB0aGF0 IGRvZXMgbm90CiAgICAgIGNvbnRhaW4gYSBMSVNQIGhlYWRlciksIHRyZWF0cyB0aGlzICJp bm5lciIgSVAgZGVzdGluYXRpb24gYWRkcmVzcwogICAgICBhcyBhbiBFSUQgYW5kIHBlcmZv cm1zIGFuIEVJRC10by1STE9DIG1hcHBpbmcgbG9va3VwLCBhbmQgdGhlbgogICAgICBwcmVw ZW5kcyBhbiAib3V0ZXIiIElQIGhlYWRlciB3aXRoIG9uZSBvZiBpdHMgb3duIGdsb2JhbGx5 LQogICAgICByb3V0YWJsZSBSTE9DcyBpbiB0aGUgc291cmNlIGFkZHJlc3MgZmllbGQgYW5k IHRoZSBSTE9DIHJlc3VsdGluZwogICAgICBmcm9tIHRoZSBtYXBwaW5nIGxvb2t1cCBpbiB0 aGUgZGVzdGluYXRpb24gYWRkcmVzcyBmaWVsZC4gIFRoYXQKICAgICAgaXMsIGluIGdlbmVy YWwgYW4gSVRSIHJlY2VpdmVzIGFuIElQIHBhY2tldCBmcm9tIHNpdGUgZW5kLXN5c3RlbXMK ICAgICAgb24gb25lIHNpZGUgYW5kIHNlbmRzIGEgTElTUC1lbmNhcHN1bGF0ZWQgSVAgcGFj a2V0IHRvd2FyZCB0aGUKICAgICAgSW50ZXJuZXQgb24gdGhlIG90aGVyIHNpZGUuCgogICBF Z3Jlc3MgVHVubmVsIFJvdXRlciAoRVRSKTogIGEgcm91dGVyIHRoYXQgYWNjZXB0cyBhbiBJ UCBwYWNrZXQgd2hlcmUKICAgICAgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MgaW4gdGhlICJv dXRlciIgSVAgaGVhZGVyIGlzIG9uZSBvZiBpdHMgb3duCiAgICAgIFJMT0NzLCBzdHJpcHMg dGhlICJvdXRlciIgaGVhZGVyLCBhbmQgZm9yd2FyZHMgdGhlIHBhY2tldCBiYXNlZCBvbgog ICAgICB0aGUgbmV4dCBJUCBoZWFkZXIgZm91bmQuICBUaGF0IGlzLCBpbiBnZW5lcmFsIGFu IEVUUiByZWNlaXZlcwogICAgICBMSVNQLWVuY2Fwc3VsYXRlZCBJUCBwYWNrZXRzIGZyb20g dGhlIEludGVybmV0IG9uIG9uZSBzaWRlIGFuZAogICAgICBzZW5kcyBkZWNhcHN1bGF0ZWQg SVAgcGFja2V0cyB0b3dhcmQgc2l0ZSBlbmQtc3lzdGVtcyBvbiB0aGUgb3RoZXIKICAgICAg c2lkZS4KCiAgIHhUUjogIGlzIGEgZ2VuZXJhbCByZWZlcmVuY2UgdG8gYW4gSVRSIG9yIEVU UiB3aGVuIGRpcmVjdGlvbiBvZiBkYXRhCiAgICAgIGZsb3cgaXMgbm90IHBhcnQgb2YgdGhl IGNvbnRleHQgZGVzY3JpcHRpb24uIHhUUiByZWZlcnMgdG8gdGhlCiAgICAgIHJvdXRlciB0 aGF0IGlzIHRoZSB0dW5uZWwgZW5kcG9pbnQgYW5kIHBlcmZvcm1zIGJvdGggSVRSIGFuZCBF VFIKICAgICAgZnVuY3Rpb25hbGl0eS4gIEZvciBleGFtcGxlLCAiQW4geFRSIGNhbiBiZSBs b2NhdGVkIGF0IHRoZQogICAgICBDdXN0b21lciBFZGdlIChDRSkgcm91dGVyIiwgbWVhbmlu ZyBib3RoIElUUiBhbmQgRVRSIGZ1bmN0aW9uYWxpdHkKICAgICAgaXMgYWN0aXZhdGVkIGF0 IHRoZSBDRSByb3V0ZXIuCgogICBQcm94eSBJVFIgKFBJVFIpOiAgYSByb3V0ZXIgdGhhdCBh Y3RzIGxpa2UgYW4gSVRSIGJ1dCBkb2VzIHNvIG9uCiAgICAgIGJlaGFsZiBvZiBub24tTElT UCBzaXRlcyB3aGljaCBzZW5kIHBhY2tldHMgdG8gZGVzdGluYXRpb25zIGF0CiAgICAgIExJ U1Agc2l0ZXMuICBUaGUgUElUUiwgYWxzbyBrbm93biBhcyBhIFBUUiwgaXMgZGVmaW5lZCBh bmQKICAgICAgZGVzY3JpYmVkIGluIFtJTlRFUldPUktdLgoKICAgUHJveHkgRVRSIChQRVRS KTogIGEgcm91dGVyIHRoYXQgYWN0cyBsaWtlIGFuIEVUUiBidXQgZG9lcyBzbyBvbgogICAg ICBiZWhhbGYgb2YgTElTUCBzaXRlcyB3aGljaCBzZW5kIHBhY2tldHMgdG8gZGVzdGluYXRp b25zIGF0IG5vbi0KICAgICAgTElTUCBzaXRlcy4gIFRoZSBQRVRSIGlzIGRlZmluZWQgYW5k IGRlc2NyaWJlZCBpbiBbSU5URVJXT1JLXS4KCiAgIExJU1AgU2l0ZTogIGlzIGEgc2V0IG9m IHJvdXRlcnMgaW4gYW4gZWRnZSBuZXR3b3JrIHRoYXQgYXJlIHVuZGVyIGEKICAgICAgc2lu Z2xlIHRlY2huaWNhbCBhZG1pbmlzdHJhdGlvbi4gIExJU1Agcm91dGVycyB3aGljaCByZXNp ZGUgaW4gdGhlCiAgICAgIGVkZ2UgbmV0d29yayBhcmUgdGhlIGRlbWFyY2F0aW9uIHBvaW50 cyB0byBzZXBhcmF0ZSB0aGUgZWRnZQogICAgICBuZXR3b3JrIGZyb20gdGhlIGNvcmUgbmV0 d29yay4KCiAgIE1hcC1TZXJ2ZXI6ICBhIExJU1AgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBj b21wb25lbnQgd2hpY2ggbGVhcm5zCiAgICAgIEVJRC10by1STE9DIG1hcHBpbmcgZW50cmll cyBmcm9tIGFuIGF1dGhvcml0YXRpdmUgc291cmNlIHN1Y2ggYXMKICAgICAgYW4gRVRSIHRo b3VnaCBzdGF0aWMgY29uZmlndXJhdGlvbiwgb3IgYW5vdGhlciBvdXQtb2YtYmFuZAogICAg ICBtZWNoYW5pc20uICBBIE1hcC1TZXJ2ZXIgYWR2ZXJ0aXNlcyB0aGVzZSBtYXBwaW5ncyBp bnRvIHRoZQogICAgICBkaXN0cmlidXRlZCBtYXBwaW5nIGRhdGFiYXNlIHN1Y2ggYXMgdGhh dCBkZXNjcmliZWQgaW4gW0xJU1AtQUxUXS4KCiAgIE1hcC1SZXNvbHZlcjogIGEgTElTUCBu ZXR3b3JrIGluZnJhc3RydWN0dXJlIGNvbXBvbmVudCB3aGljaCBhY2NlcHRzCiAgICAgIExJ U1AgRW5jYXBzdWxhdGVkIE1hcC1SZXF1ZXN0cywgdHlwaWNhbGx5IGZyb20gYW4gSVRSLCBh bmQgcXVpY2tseQogICAgICBkZXRlcm1pbmVzIHdoZXRoZXIgb3Igbm90IHRoZSBkZXN0aW5h dGlvbiBJUCBhZGRyZXNzIGlzIHBhcnQgb2YKICAgICAgdGhlIEVJRCBuYW1lc3BhY2UuICBJ ZiBpdCBpcywgdGhlIE1hcC1SZXNvbHZlciBmaW5kcyB0aGUKICAgICAgYXBwcm9wcmlhdGUg RUlELXRvLVJMT0MgbWFwcGluZyBieSBjb25zdWx0aW5nIHRoZSBkaXN0cmlidXRlZAogICAg ICBtYXBwaW5nIGRhdGFiYXNlIHN5c3RlbSBzdWNoIGFzIHRoYXQgZGVzY3JpYmVkIGluIFtM SVNQLUFMVF0uICBJZgogICAgICBpdCBpcyBub3QsIGEgTmVnYXRpdmUgTWFwLVJlcGx5IGlz IGltbWVkaWF0ZWx5IHJldHVybmVkLgoKICAgTWFwLVJlcGx5OiAgYSBMSVNQIE1hcC1SZXBs eSBtZXNzYWdlIHR5cGUgcmV0dXJuZWQgaW4gcmVzcG9uc2UgdG8gYQogICAgICBNYXAtUmVx dWVzdCBmb3IgYSBkZXN0aW5hdGlvbiBFSUQgdGhhdCBleGlzdHMgaW4gdGhlIG1hcHBpbmcK ICAgICAgZGF0YWJhc2UgYW5kIGNvbnRhaW5zIHRoZSBsb2NhdG9yLXNldCBhbmQgYXNzb2Np YXRlZCBwb2xpY3kgZm9yCiAgICAgIHRoZSBxdWVyaWVkIEVJRC4gIEluZm9ybWF0aW9uIHJl dHVybmVkIGluIGEgTWFwLVJlcGx5IGlzIHN0b3JlZCBpbgogICAgICB0aGUgRUlELXRvLVJM T0MgTWFwLUNhY2hlLgoKICAgTmVnYXRpdmUgTWFwLVJlcGx5OiAgYSBMSVNQIE1hcC1SZXBs eSBtZXNzYWdlIHR5cGUgdGhhdCBjb250YWlucyBhbgogICAgICBlbXB0eSBsb2NhdG9yLXNl dC4gIFJldHVybmVkIGluIHJlc3BvbnNlIHRvIGEgTWFwLVJlcXVlc3QgaWYgdGhlCiAgICAg IGRlc3RpbmF0aW9uIEVJRCBkb2VzIG5vdCBleGlzdCBpbiB0aGUgbWFwcGluZyBkYXRhYmFz ZS4KICAgICAgVHlwaWNhbGx5LCB0aGlzIG1lYW5zIHRoYXQgdGhlICJFSUQiIGJlaW5nIHJl cXVlc3RlZCBpcyBhbiBJUAogICAgICBhZGRyZXNzIGNvbm5lY3RlZCB0byBhIG5vbi1MSVNQ IHNpdGUuICBJbmZvcm1hdGlvbiByZXR1cm5lZCBpbiBhCiAgICAgIE5lZ2F0aXZlIE1hcC1S ZXBseSBpcyBzdG9yZWQgaW4gdGhlIEVJRC10by1STE9DIE1hcC1DYWNoZS4KCiAgIExJU1Ar QUxUOiAgYSBzdGF0aWMgbmV0d29yayBidWlsdCB1c2luZyBCb3JkZXIgR2F0ZXdheSBQcm90 b2NvbCAoQkdQLAogICAgICBbUkZDNDI3MV0pLCBCR1AgbXVsdGktcHJvdG9jb2wgZXh0ZW5z aW9uIFtSRkM0NzYwXSwgYW5kIEdlbmVyaWMKICAgICAgUm91dGluZyBFbmNhcHN1bGF0aW9u IChHUkUsIFtSRkMyNzg0XSkgdG8gY29uc3RydWN0IGFuIG92ZXJsYXkKICAgICAgbmV0d29y ayBvZiBkZXZpY2VzIChBTFQgUm91dGVycykgd2hpY2ggb3BlcmF0ZSBvbiBFSUQtcHJlZml4 ZXMgYW5kCiAgICAgIHVzZSBFSURzIGFzIGZvcndhcmRpbmcgZGVzdGluYXRpb25zLiAgVGhp cyBMSVNQK0FMVCBuZXR3b3JrIG1heSwKICAgICAgYnV0IGlzIG5vdCByZXF1aXJlZCB0byBi ZSwgdXNlZCBieSBMSVNQIHRvIGZpbmQgRUlELXRvLVJMT0MKICAgICAgbWFwcGluZ3MuICBM SVNQK0FMVCBpcyBkZXNjcmliZWQgaW4gW0xJU1AtQUxUXS4KCjUuICBMSVNQIE1JQiBPYmpl Y3RpdmVzCgogICBUaGUgb2JqZWN0aXZlcyBmb3IgZGVmaW5pbmcgdGhpcyBMSVNQIE1JQiBt b2R1bGUgYXJlIGFzIGZvbGxvd3M6CgogICBvICBQcm92aWRlIGEgbWVhbnMgZm9yIG9idGFp bmluZyBhIGxpc3Qgb2YgZW5hYmxlZCBMSVNQIGZlYXR1cmVzIGFuZAogICAgICB0aGUgY3Vy cmVudCBzdGF0dXMgb2YgY29uZmlndXJhdGlvbiBhdHRyaWJ1dGVzIHJlbGF0ZWQgdG8gdGhv c2UKICAgICAgZmVhdHVyZXMuICBBcyBhbiBleGFtcGxlLCBMSVNQIGNhcGFiaWxpdGllcyB3 aGljaCBjb3VsZCBiZSBlbmFibGVkCiAgICAgIGluY2x1ZGUgSVRSLCBFVFIsIFBJVFIsIFBF VFIsIE1TIG9yIE1SIHN1cHBvcnQgZm9yIElQdjQgb3IgSVB2NgogICAgICBhZGRyZXNzIGZh bWlsaWVzLiAgT3RoZXIgZXhhbXBsZXMgaW5jbHVkZSwgaW5kaWNhdGluZyB3aGV0aGVyCiAg ICAgIHJsb2MtcHJvYmluZyBpcyBlbmFibGVkLCBhbmQgaW5kaWNhdGluZyB0aGUgY29uZmln dXJlZCBtYXAtY2FjaGUKICAgICAgbGltaXQgdmFsdWUuCgogICBvICBQcm92aWRlIGEgbWVh bnMgZm9yIG9idGFpbmluZyB0aGUgY3VycmVudCBhdHRyaWJ1dGVzIG9mIHZhcmlvdXMKICAg ICAgTElTUCB0YWJsZXMsIHN1Y2ggYXMgdGhlIEVJRC10by1STE9DIHBvbGljeSBkYXRhIGNv bnRhaW5lZCBpbiB0aGUKICAgICAgTWFwLUNhY2hlLCBvciB0aGUgbG9jYWwgRUlELXRvLVJM T0MgcG9saWN5IGRhdGEgY29udGFpbmVkIGluIHRoZQogICAgICBNYXBwaW5nLURhdGFiYXNl LgoKICAgbyAgUHJvdmlkZSBhIG1lYW5zIGZvciBvYnRhaW5pbmcgdGhlIGN1cnJlbnQgb3Bl cmF0aW9uYWwgc3RhdGlzdGljcwogICAgICBvZiB2YXJpb3VzIExJU1AgZnVuY3Rpb25zLCBz dWNoIGFzIHRoZSBudW1iZXIgb2YgcGFja2V0cwogICAgICBlbmNhcHN1bGF0ZWQgYW5kIGRl Y2Fwc3VsYXRlZCBieSB0aGUgZGV2aWNlLiAgT3RoZXIgY291bnRlcnMgb2YKICAgICAgb3Bl cmF0aW9uYWwgaW50ZXJlc3QsIGRlcGVuZGluZyBvbiBMSVNQIGZ1bmN0aW9uLCBpbmNsdWRl IHRoaW5ncwogICAgICBsaWtlIHRoZSBjdXJyZW50IG51bWJlciBvZiBtYXAtY2FjaGUgZW50 cmllcywgYW5kIHRoZSB0b3RhbCBudW1iZXIKICAgICAgYW5kIHJhdGUgb2YgbWFwLXJlcXVl c3RzIHJlY2VpdmVkIGFuZCBzZW50LgoKNi4gIFN0cnVjdHVyZSBvZiBMSVNQIE1JQiBNb2R1 bGUKCjYuMS4gIE92ZXJ2aWV3IG9mIERlZmluZWQgTm90aWZpY2F0aW9ucwoKICAgTm8gTElT UCBNSUIgbm90aWZpY2F0aW9ucyBhcmUgZGVmaW5lZC4KCjYuMi4gIE92ZXJ2aWV3IG9mIERl ZmluZWQgVGFibGVzCgogICBUaGUgTElTUCBNSUIgbW9kdWxlIGlzIGNvbXBvc2VkIG9mIHRl biB0YWJsZXMgb2Ygb2JqZWN0cywgYXMgZm9sbG93czoKCiAgIExpc3AgLSAgVGhpcyB0YWJs ZSBwcm92aWRlcyBpbmZvcm1hdGlvbiByZXByZXNlbnRpbmcgdGhlIHZhcmlvdXMgbGlzcAog ICAgICBmZWF0dXJlcyB0aGF0IGNhbiBiZSBlbmFibGVkIG9uIExJU1AgZGV2aWNlcy4KCiAg IExpc3BNYXBwaW5nRGF0YWJhc2UgLSAgVGhpcyB0YWJsZSByZXByZXNlbnRzIHRoZSBFSUQt dG8tUkxPQyBkYXRhYmFzZQogICAgICB0aGF0IGNvbnRhaW5zIHRoZSBFSUQtcHJlZml4IHRv IFJMT0MgbWFwcGluZ3MgY29uZmlndXJlZCBvbiBhbgogICAgICBFVFIuICBJbiBnZW5lcmFs LCB0aGlzIHRhYmxlIHdvdWxkIGJlIHJlcHJlc2VudGF0aXZlIG9mIGFsbCBzdWNoCiAgICAg IG1hcHBpbmdzIGZvciBhIGdpdmVuIHNpdGUgdGhhdCB0aGlzIGRldmljZSBiZWxvbmdzIHRv LgoKICAgTGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3IgLSAgVGhpcyB0YWJsZSByZXByZXNl bnRzIHRoZSBzZXQgb2YKICAgICAgcm91dGluZyBsb2NhdG9ycyBjb250YWluZWQgaW4gdGhl IEVJRC10by1STE9DIGRhdGFiYXNlIGNvbmZpZ3VyZWQKICAgICAgb24gYW4gRVRSLgoKICAg TGlzcE1hcENhY2hlIC0gIFRoaXMgdGFibGUgcmVwcmVzZW50cyB0aGUgc2hvcnQtbGl2ZWQs IG9uLWRlbWFuZAogICAgICB0YWJsZSBvbiBhbiBJVFIgdGhhdCBzdG9yZXMsIHRyYWNrcywg YW5kIGlzIHJlc3BvbnNpYmxlIGZvcgogICAgICB0aW1pbmctb3V0IGFuZCBvdGhlcndpc2Ug dmFsaWRhdGluZyBFSUQtdG8tUkxPQyBtYXBwaW5ncy4KCiAgIExpc3BNYXBDYWNoZUxvY2F0 b3IgLSAgVGhpcyB0YWJsZSByZXByZXNlbnRzIHRoZSBzZXQgb2YgbG9jYXRvcnMgcGVyCiAg ICAgIEVJRCBwcmVmaXggY29udGFpbmVkIGluIHRoZSBtYXAtY2FjaGUgdGFibGUgb2YgYW4g SVRSLgoKICAgTGlzcFNpdGUgLSAgVGhpcyB0YWJsZSBwcm92aWRlcyB0aGUgcHJvcGVydGll cyBvZiBlYWNoIGxpc3Agc2l0ZSB0aGF0CiAgICAgIGlzIHNlcnZlZCBieSB0aGlzIGRldmlj ZSB3aGVuIGNvbmZpZ3VyZWQgdG8gYmUgYSBNYXAtU2VydmVyLgoKICAgTGlzcFNpdGVMb2Nh dG9yIC0gIFRoaXMgdGFibGUgcHJvdmlkZXMgdGhlIHByb3BlcnRpZXMgb2YgYWxsIGxvY2F0 b3JzCiAgICAgIHBlciBsaXNwIHNpdGUgdGhhdCBpcyBzZXJ2ZWQgYnkgdGhpcyBkZXZpY2Ug d2hlbiBjb25maWd1cmVkIHRvIGJlCiAgICAgIGEgTWFwLVNlcnZlci4KCiAgIExpc3BNYXBT ZXJ2ZXJzIC0gIFRoaXMgdGFibGUgcHJvdmlkZXMgdGhlIHByb3BlcnRpZXMgb2YgYWxsIE1h cC0KICAgICAgU2VydmVycyB0aGF0IHRoaXMgZGV2aWNlIGlzIGNvbmZpZ3VyZWQgdG8gdXNl LgoKICAgTGlzcE1hcFJlc29sdmVycyAtICBUaGlzIHRhYmxlIHByb3ZpZGVzIHRoZSBwcm9w ZXJ0aWVzIG9mIGFsbCBNYXAtCiAgICAgIFJlc29sdmVycyB0aGF0IHRoaXMgZGV2aWNlIGlz IGNvbmZpZ3VyZWQgdG8gdXNlLgoKICAgbGlzcFVzZVByb3h5RXRyIC0gIFRoaXMgdGFibGUg cHJvdmlkZXMgdGhlIHByb3BlcnRpZXMgb2YgYWxsIFByb3h5CiAgICAgIEVUUnMgdGhhdCB0 aGlzIGRldmljZSBpcyBjb25maWd1cmVkIHRvIHVzZS4KCjcuICBMSVNQIE1JQiA8c3RyaWtl Pjxmb250IGNvbG9yPSJyZWQiPkRlZmluaXRpb248L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9ImdyZWVuIj5EZWZpbml0aW9uczwvZm9udD48L3N0cm9uZz4KCkxJU1At TUlCIERFRklOSVRJT05TIDo6PSBCRUdJTgoKSU1QT1JUUwogICAgTU9EVUxFLUlERU5USVRZ LCBPQkpFQ1QtVFlQRSwgVW5zaWduZWQzMiwgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5D b3VudGVyNjQsVGltZVRpY2tzLDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iPkNvdW50ZXI2NCwKICAgIG1pYi0yLCBUaW1lVGlja3MsIEludGVnZXIzMiw8 L2ZvbnQ+PC9zdHJvbmc+CiAgICBOT1RJRklDQVRJT04tVFlQRSAgICAgICAgICAgICAgICAg RlJPTSBTTk1QdjItU01JICAgICAgLS0gW1JGQzI1NzhdCiAgICBNT0RVTEUtQ09NUExJQU5D RSwgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5PQkpFQ1QtR1JPVVA8L2ZvbnQ+PC9zdHJp a2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5PQkpFQ1QtR1JPVVAsPC9mb250Pjwv c3Ryb25nPgogICAgTk9USUZJQ0FUSU9OLUdST1VQICAgICAgICAgICAgICAgIEZST00gU05N UHYyLUNPTkYgICAgIC0tIFtSRkMyNTgwXQogICAgVEVYVFVBTC1DT05WRU5USU9OLCBUcnV0 aFZhbHVlLAogICAgUm93U3RhdHVzICAgICAgICAgICAgICAgICAgICAgICAgIEZST00gU05N UHYyLVRDICAgICAgIC0tIFtSRkMyNTc5XQogICAgQWRkcmVzc0ZhbWlseU51bWJlcnMKICAg ICAgICAgICAgICAgICBGUk9NIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+SUFOQS1BRERS RVNTLUZBTUlMWS1OVU1CRVJTLU1JQjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBj b2xvcj0iZ3JlZW4iPklBTkEtQUREUkVTUy1GQU1JTFktTlVNQkVSUy1NSUI7PC9mb250Pjwv c3Ryb25nPiAgICAgLS0gW0lBTkFdCgpsaXNwTUlCIE1PRFVMRS1JREVOVElUWQogICAgTEFT VC1VUERBVEVEIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+IjIwMTEwMTA1MDAwMFoiPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+IjIwMTEwMzA4MDAw MFoiPC9mb250Pjwvc3Ryb25nPiAtLSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjA1IEph bnVhcnkgMjAxMSI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVu Ij44IE1hcmNoIDIwMTE8L2ZvbnQ+PC9zdHJvbmc+CiAgICBPUkdBTklaQVRJT04KICAgICAg ICAgICAgIklFVEYgTG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKSBXb3Jr aW5nIEdyb3VwIgogICAgQ09OVEFDVC1JTkZPCiAgICAgICAgICAgICJFbWFpbDogbGlzcEBp ZXRmLm9yZwogICAgICAgICAgICBXRyBjaGFydGVyOgogICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvbGlzcC1jaGFydGVyLmh0bWwiCiAgIERFU0NSSVBU SU9OCiAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+IlRoaXMgbWVtbyBk ZXNjcmliZXMgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSAoTUlCKTwvZm9udD48 L3N0cmlrZT4KICAgICAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPiJUaGUg bWliPC9mb250Pjwvc3Ryb25nPiBtb2R1bGUgZm9yIDxzdHJpa2U+PGZvbnQgY29sb3I9InJl ZCI+dXNlIHdpdGggbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBpbiB0aGU8L2ZvbnQ+ PC9zdHJpa2U+IG1hbmFnZW1lbnQgb2YgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5Mb2Nh dG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wgKExJU1ApIGRldmljZXMuPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+TElTUCByb3V0ZXJzLjwvZm9udD48 L3N0cm9uZz4KCiAgICAgICAgICAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgPHN0 cmlrZT48Zm9udCBjb2xvcj0icmVkIj4oMjAxMCkuIjwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0iZ3JlZW4iPigyMDExKS4iPC9mb250Pjwvc3Ryb25nPgogICBSRVZJ U0lPTiAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4iMjAxMTAxMDUwMDAwWiI8L2Zv bnQ+PC9zdHJpa2U+ICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+IjIwMTEwMzA4 MDAwMFoiPC9mb250Pjwvc3Ryb25nPiAtLSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjA1 IEphbnVhcnkgMjAxMSI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Imdy ZWVuIj44IE1hcmNoIDIwMTEKICAgREVTQ1JJUFRJT04gICJJbml0aWFsIFJldmlzaW9uIjwv Zm9udD48L3N0cm9uZz4KICAgICA6Oj0geyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPnh4 eHh4PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+bWliLTIg OTk5PC9mb250Pjwvc3Ryb25nPiB9CgotLQotLSBUZXh0dWFsIENvbnZlbnRpb25zCi0tCgpM aXNwQWRkcmVzc1R5cGUgOjo9IFRFWFRVQUwtQ09OVkVOVElPTgogICAgU1RBVFVTIGN1cnJl bnQKICAgIERFU0NSSVBUSU9OCiAgICAgICAgIkxJU1AgYXJjaGl0ZWN0dXJlIGNhbiBiZSBh cHBsaWVkIHRvIGEgd2lkZSB2YXJpZXR5IG9mCiAgICAgICAgIGFkZHJlc3MtZmFtaWxpZXMu IFRoaXMgdGV4dHVhbC1jb252ZW50aW9uIGlzIGEKICAgICAgICAgZ2VuZXJhbGl6YXRpb24g Zm9yIHJlcHJlc2VudGluZyBhZGRyZXNzZXMgdGhhdCBiZWxvbmcKICAgICAgICAgdG8gdGhv c2UgYWRkcmVzcy1mYW1pbGllcy4gRm9yIGNvbnZlbmllbmNlLCB0aGlzCiAgICAgICAgIGRv Y3VtZW50IHJlZmVycyB0byBhbnkgc3VjaCBhZGRyZXNzIGFzIGEgbGlzcCBhZGRyZXNzLgog ICAgICAgICBMaXNwQWRkcmVzc1R5cGUgdGV4dHVhbC1jb252ZW50aW9uIGNvbnNpc3RzIG9m CiAgICAgICAgIHRoZSBmb2xsb3dpbmcgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5mb3Vy IHR1cGxlczo8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5m b3VyLXR1cGxlOjwvZm9udD48L3N0cm9uZz4KICAgICAgICAgIDEuIElBTkEgQWRkcmVzcyBG YW1pbHkgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5OdW1iZXJzOiBUaGlzIHR1cGxlIGZv bGxvd3M8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5OdW1i ZXI6IEEgZmllbGQgb2YgbGVuZ3RoCiAgICAgICAgICAgICAyLW9jdGV0cywgd2hvc2UgdmFs dWUgaXMgb2YgdGhlIGZvcm0gZm9sbG93aW5nPC9mb250Pjwvc3Ryb25nPiB0aGUKICAgICAg ICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5hc3NpZ25lZDwvZm9udD48L3N0 cm9uZz4gQWRkcmVzc0ZhbWlseU51bWJlcnMgdGV4dHVhbC1jb252ZW50aW9uCiAgICAgICAg ICAgICBkZXNjcmliZWQgaW4gW0lBTkFdLiBUaGUgZW51bWVyYXRpb25zIGFyZSBsaXN0ZWQK ICAgICAgICAgICAgIGluIFtJQU5BXS4gIE5vdGUgdGhhdCA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPnRoZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4i PnRoaXM8L2ZvbnQ+PC9zdHJvbmc+IGxpc3Qgb2YgYWRkcmVzcyBmYW1pbHkKICAgICAgICAg ICAgIG51bWJlcnMgaXMgbWFpbnRhaW5lZCBieSBJQU5BLgogICAgICAgICAgMi4gTGVuZ3Ro IG9mIExJU1AgYWRkcmVzczogPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5UaGlzIHR1cGxl IGlzIGFuIElOVEVHRVIKICAgICAgICAgICAgIHRvIGdpdmUgdGhlIG9jdGV0PC9mb250Pjwv c3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+QSBmaWVsZCBvZjwvZm9udD48 L3N0cm9uZz4gbGVuZ3RoIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj4xLW9jdGV0LAog ICAgICAgICAgICAgd2hvc2UgdmFsdWUgaW5kaWNhdGVzIHRoZSBvY3RldC1sZW5ndGg8L2Zv bnQ+PC9zdHJvbmc+IG9mIHRoZSBuZXh0IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+dHVw bGUuPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0i Z3JlZW4iPih0aGlyZCkgZmllbGQgb2YgdGhpcyBMaXNwQWRkcmVzc1R5cGUgZm91ci10dXBs ZS48L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAgICAzLiBMaXNwIGFkZHJlc3M6IEEgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5saXNwIGFkZHJlc3MgY2FuIGJlPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZmllbGQgb2YgdmFyaWFibGUgbGVuZ3Ro IGFzCiAgICAgICAgICAgICBpbmRpY2F0ZWQgaW4gdGhlIHByZXZpb3VzIChzZWNvbmQpIGZp ZWxkLCB3aG9zZQogICAgICAgICAgICAgdmFsdWUgaXM8L2ZvbnQ+PC9zdHJvbmc+IGFuIGFk ZHJlc3MKICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YmVsb25naW5n IHRvPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+b2YgdGhl IElBTkEgQWRkcmVzcyBGYW1pbHkKICAgICAgICAgICAgIGluZGljYXRlZCBpbiB0aGUgZmly c3QgZmllbGQgb2YgdGhpcyBMaXNwQWRkcmVzc1R5cGUKICAgICAgICAgICAgIGZvdXItdHVw bGUuICBOb3RlIHRoYXQ8L2ZvbnQ+PC9zdHJvbmc+IGFueSBvZiB0aGUgSUFOQSBBZGRyZXNz IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+RmFtaWxpZXMuCiAgICAgICAgICAgICBQYXJ0 aWN1bGFybHksPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgPHN0cm9uZz48Zm9udCBj b2xvcj0iZ3JlZW4iPkZhbWlsaWVzIGNhbiBiZSByZXByZXNlbnRlZC4gUGFydGljdWxhcmx5 PC9mb250Pjwvc3Ryb25nPiB3aGVuIHRoZQogICAgICAgICAgICAgYWRkcmVzcyBmYW1pbHkg aXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5MaXNwPC9mb250Pjwvc3RyaWtlPiA8c3Ry b25nPjxmb250IGNvbG9yPSJncmVlbiI+TElTUDwvZm9udD48L3N0cm9uZz4gQ2Fub25pY2Fs IEFkZHJlc3MgRm9ybWF0CiAgICAgICAgICAgICAoTENBRikgW0xDQUZdIHdpdGggSUFOQSBh c3NpZ25lZCBBZGRyZXNzIEZhbWlseQogICAgICAgICAgICAgTnVtYmVyIDE2Mzg3LCB0aGVu IHRoZSBmaXJzdCBvY3RldCBvZiB0aGlzIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+dHVw bGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5maWVsZDwv Zm9udD48L3N0cm9uZz4KICAgICAgICAgICAgIGluZGljYXRlcyB0aGUgTENBRiB0eXBlLCBh bmQgdGhlIHJlc3Qgb2YgdGhpcyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPnR1cGxlPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZmllbGQ8L2ZvbnQ+ PC9zdHJvbmc+CiAgICAgICAgICAgICBpcyBzYW1lIGFzIHRoZSBlbmNvZGluZyBmb3JtYXQg b2YgdGhlIExJU1AgQ2Fub25pY2FsCiAgICAgICAgICAgICBBZGRyZXNzIGFmdGVyIHRoZSBs ZW5ndGggZmllbGQsIGFzIGRlZmluZWQgaW4gW0xDQUZdLgogICAgICAgICAgNC4gTWFzay1s ZW5ndGggb2YgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmFkZHJlc3M6IEEgdmFyaWFi bGUtbGVuZ3RoIGZpZWxkCiAgICAgICAgICAgICBjb21wcmlzZWQgb2YgdGhlIHJlbWFpbmlu ZyBvY3RldHMgb2YgdGhpcwogICAgICAgICAgICAgTGlzcEFkZHJlc3NUeXBlIGZvdXItdHVw bGUsIHdob3NlIHZhbHVlIGlzIHRoZQogICAgICAgICAgICAgbWFzay1sZW5ndGggdG8gYmUg YXBwbGllZCB0byB0aGU8L2ZvbnQ+PC9zdHJvbmc+IGxpc3AgPHN0cmlrZT48Zm9udCBjb2xv cj0icmVkIj5hZGRyZXNzLiI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 ImdyZWVuIj5hZGRyZXNzCiAgICAgICAgICAgICBzcGVjaWZpZWQgaW4gdGhlIHByZXZpb3Vz ICh0aGlyZCkgZmllbGQuCgogICAgICAgICAgVG8gaWxsdXN0cmF0ZSB0aGUgdXNlIG9mIHRo aXMgb2JqZWN0LCBjb25zaWRlciB0aGUKICAgICAgICAgIExJU1AgTUlCIE9iamVjdCBiZWxv dyBlbnRpdGxlZCBsaXNwTWFwQ2FjaGVFbnRyeS4KICAgICAgICAgIFRoaXMgb2JqZWN0IGJl Z2lucyB3aXRoIHRoZSBmb2xsb3dpbmcgZW50aXRpZXM6CgogICAgICAgICAgbGlzcE1hcENh Y2hlRW50cnkgOjo9IFNFUVVFTkNFIHsKICAgICAgICAgICAgIGxpc3BNYXBDYWNoZUVpZExl bmd0aCAgICAgICAgICBJTlRFR0VSLAogICAgICAgICAgICAgbGlzcE1hcENhY2hlRWlkICAg ICAgICAgICAgICAgIExpc3BBZGRyZXNzVHlwZSwKICAgICAgICAgICAgIC0tLVtza2lwXS0t LQoKICAgICAgICAgIEV4YW1wbGUgMTogU3VwcG9zZSB0aGF0IHRoZSBJUHY0IEVJRCBwcmVm aXggc3RvcmVkIGlzCiAgICAgICAgICAxMC4xMC4xMC4wLzI0LiBJbiB0aGlzIGNhc2UsIHRo ZSB2YWx1ZXMgd2l0aGluCiAgICAgICAgICBsaXNwTWFwQ2FjaGVFbnRyeSB3b3VsZCBiZToK CiAgICAgICAgICAgICBsaXNwTWFwQ2FjaGVFaWRMZW5ndGggID0gOAogICAgICAgICAgICAg bGlzcE1hcENhY2hlRWlkID0gMSwgNCwgMTAuMTAuMTAuMCwgMjQKICAgICAgICAgICAgIC0t LVtza2lwXS0tLQoKICAgICAgICAgIHdoZXJlIDggaXMgdGhlIHRvdGFsIGxlbmd0aCBpbiBv Y3RldHMgb2YgdGhlIG5leHQKICAgICAgICAgIG9iamVjdCAobGlzcE1hcENhY2hlRUlEIG9m IHR5cGUgTGlzcEFkZHJlc3NUeXBlKS4gVGhlbiwKICAgICAgICAgIHRoZSB2YWx1ZSAxIGlu ZGljYXRlcyB0aGUgSVB2NCBBRiAocGVyIFtJQU5BXSksIHRoZQogICAgICAgICAgdmFsdWUg NCBpbmRpY2F0ZXMgdGhhdCB0aGUgQUYgaXMgNC1vY3RldHMgaW4gbGVuZ3RoLAogICAgICAg ICAgMTAuMTAuMTAuMCBpcyB0aGUgSVB2NCBhZGRyZXNzLCBhbmQgdGhlIHZhbHVlIDI0IGlz IHRoZQogICAgICAgICAgbWFzay1sZW5ndGggaW4gYml0cy4gTm90ZSB0aGF0IHRoZSBsaXNw TWFwQ2FjaGVFaWRMZW5ndGgKICAgICAgICAgIHZhbHVlIG9mIDggaXMgdXNlZCB0byBjb21w dXRlIHRoZSBsZW5ndGggb2YgdGhlIGZvdXJ0aAogICAgICAgICAgKGxhc3QpIGZpZWxkIGlu IGxpc3BNYXBDYWNoZUVpZCB0byBiZSAxIG9jdGV0IC0tIGFzCiAgICAgICAgICBjb21wdXRl ZCBieSA4IC0gKDIgKyAxICsgNCkgPSAxLgoKICAgICAgICAgIEV4YW1wbGUgMjogU3VwcG9z ZSB0aGF0IHRoZSBJUHY2IEVJRCBwcmVmaXggc3RvcmVkIGlzCiAgICAgICAgICAyMDAxOmRi ODphOjovNDguIEluIHRoaXMgY2FzZSwgdGhlIHZhbHVlcyB3aXRoaW4KICAgICAgICAgIGxp c3BNYXBDYWNoZUVudHJ5IHdvdWxkIGJlOgoKICAgICAgICAgICAgIGxpc3BNYXBDYWNoZUVp ZExlbmd0aCAgPSAyMAogICAgICAgICAgICAgbGlzcE1hcENhY2hlRWlkID0gMiwgMTYsIDIw MDE6ZGI4OmE6OiwgNDgKICAgICAgICAgICAgIC0tLVtza2lwXS0tLQoKICAgICAgICAgIHdo ZXJlIDIwIGlzIHRoZSB0b3RhbCBsZW5ndGggaW4gb2N0ZXRzIG9mIHRoZSBuZXh0CiAgICAg ICAgICBvYmplY3QgKGxpc3BNYXBDYWNoZUVJRCBvZiB0eXBlIExpc3BBZGRyZXNzVHlwZSku IFRoZW4sCiAgICAgICAgICB0aGUgdmFsdWUgMiBpbmRpY2F0ZXMgdGhlIElQdjQgQUYgKHBl ciBbSUFOQV0pLCB0aGUKICAgICAgICAgIHZhbHVlIDE2IGluZGljYXRlcyB0aGF0IHRoZSBB RiBpcyAxNi1vY3RldHMgaW4gbGVuZ3RoLAogICAgICAgICAgMjAwMTpkYjg6YTo6IGlzIHRo ZSBJUHY2IGFkZHJlc3MsIGFuZCB0aGUgdmFsdWUgNDggaXMgdGhlCiAgICAgICAgICBtYXNr LWxlbmd0aCBpbiBiaXRzLiBOb3RlIHRoYXQgdGhlIGxpc3BNYXBDYWNoZUVpZExlbmd0aAog ICAgICAgICAgdmFsdWUgb2YgMjAgaXMgdXNlZCB0byBjb21wdXRlIHRoZSBsZW5ndGggb2Yg dGhlIGZvdXJ0aAogICAgICAgICAgKGxhc3QpIGZpZWxkIGluIGxpc3BNYXBDYWNoZUVpZCB0 byBiZSAxIG9jdGV0IC0tIGFzCiAgICAgICAgICBjb21wdXRlZCBieSAyMCAtICgyICsgMSAr IDE2KSA9IDEuCgogICAgICAgICAgRXhhbXBsZSAzOiBBcyBhbiBleGFtcGxlIHdoZXJlIExD QUYgaXMgdXNlZCwgc3VwcG9zZQogICAgICAgICAgdGhhdCB0aGUgSVB2NCBFSUQgcHJlZml4 IHN0b3JlZCBpcyAxMC4xMC4xMC4wLzI0IGFuZCBpdAogICAgICAgICAgaXMgcGFydCBvZiBM SVNQIGluc3RhbmNlIGlkIDEwMS4gSW4gdGhpcyBjYXNlLCB0aGUgdmFsdWVzCiAgICAgICAg ICB3aXRoaW4gbGlzcE1hcENhY2hlRW50cnkgd291bGQgYmU6CgogICAgICAgICAgICAgbGlz cE1hcENhY2hlRWlkTGVuZ3RoICA9IDExCiAgICAgICAgICAgICBsaXNwTWFwQ2FjaGVFaWQg PSAxNjM4NywgNywgMiwgMTAxLCAxLCAxMC4xMC4xMC4wLCAyNAogICAgICAgICAgICAgLS0t W3NraXBdLS0tCgogICAgICAgICAgd2hlcmUgMTEgaXMgdGhlIHRvdGFsIGxlbmd0aCBpbiBv Y3RldHMgb2YgdGhlIG5leHQgb2JqZWN0CiAgICAgICAgICAobGlzcE1hcENhY2hlRUlEIG9m IHR5cGUgTGlzcEFkZHJlc3NUeXBlKS4gVGhlbiwgdGhlIHZhbHVlCiAgICAgICAgICAxNjM4 NyBpbmRpY2F0ZXMgdGhlIExDQUYgQUYgKHNlZSBbSUFOQV0pLCB0aGUgdmFsdWUgNwogICAg ICAgICAgaW5kaWNhdGVzIHRoYXQgdGhlIExDQUYgQUYgaXMgNy1vY3RldHMgaW4gbGVuZ3Ro IGluIHRoaXMKICAgICAgICAgIGNhc2UsIDIgaW5kaWNhdGVzIHRoYXQgTENBRiBUeXBlIDIg ZW5jb2RpbmcgaXMgdXNlZCAoc2VlCiAgICAgICAgICBbTENBRl0pLCAxMDEgZ2l2ZXMgdGhl IGluc3RhbmNlIGlkLCAxIGdpdmVzIHRoZSBBRkkgKHBlcgogICAgICAgICAgW0lBTkFdKSBm b3IgYW4gSVB2NCBhZGRyZXNzLCAxMC4xMC4xMC4wIGlzIHRoZSBJUHY0CiAgICAgICAgICBh ZGRyZXNzLCBhbmQgMjQgaXMgdGhlIG1hc2stbGVuZ3RoIGluIGJpdHMuIE5vdGUgdGhhdCB0 aGUKICAgICAgICAgIGxpc3BNYXBDYWNoZUVpZExlbmd0aCB2YWx1ZSBvZiAxMSBvY3RldHMg aXMgdXNlZCB0byBjb21wdXRlCiAgICAgICAgICB0aGUgbGVuZ3RoIG9mIHRoZSBsYXN0IGZp ZWxkIGluIGxpc3BNYXBDYWNoZUVpZCB0byBiZSAxIG9jdGV0LAogICAgICAgICAgYXMgY29t cHV0ZWQgYnkgMTEgLSAoMiArIDEgKyAxICsgMSArIDEgKyAxICsgNCkgPSAxLiI8L2ZvbnQ+ PC9zdHJvbmc+CgogICAgUkVGRVJFTkNFICJbTElTUF0iCiAgICBTWU5UQVggT0NURVQgU1RS SU5HIChTSVpFICgwLi4xMDI0KSkKCiAgIGxpc3BUYWJsZSBPQkpFQ1QtVFlQRQogICAgICAg U1lOVEFYICAgICBTRVFVRU5DRSBPRiBsaXNwRW50cnkKICAgICAgIE1BWC1BQ0NFU1Mgbm90 LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJ T04KICAgICAgICAgICAiVGhpcyB0YWJsZSByZXByZXNlbnRzIHRoZSB2YXJpb3VzIGxpc3Ag ZmVhdHVyZXMKICAgICAgICAgICAgdGhhdCBjYW4gYmUgZW5hYmxlZCBvbiBsaXNwIGRldmlj ZXMuIgoKICAgICAgIFJFRkVSRU5DRSAiW0xJU1BdIgogICAgICAgOjo9IHsgPHN0cmlrZT48 Zm9udCBjb2xvcj0icmVkIj5saXNwPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSJncmVlbiI+bGlzcE1JQjwvZm9udD48L3N0cm9uZz4gMSB9CgogICBsaXNwRW50cnkg T0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgbGlzcEVudHJ5CiAgICAgICBNQVgtQUND RVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERF U0NSSVBUSU9OCiAgICAgICAgICAgIkFuIGVudHJ5IChjb25jZXB0dWFsIHJvdykgaW4gdGhl IGxpc3BUYWJsZS4iCiAgICAgICBJTkRFWCAgICAgIHsgPHN0cmlrZT48Zm9udCBjb2xvcj0i cmVkIj5saXNwQWZpPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVl biI+bGlzcEFkZHJlc3NGYW1pbHk8L2ZvbnQ+PC9zdHJvbmc+IH0KICAgICAgIDo6PSB7IGxp c3BUYWJsZSAxIH0KCiAgIGxpc3BFbnRyeSA6Oj0gU0VRVUVOQ0UgewogICAgICAgbGlzcEFk ZHJlc3NGYW1pbHkgICAgICAgICAgICAgICAgICBBZGRyZXNzRmFtaWx5TnVtYmVycywKICAg ICAgIGxpc3BJdHJFbmFibGVkICAgICAgICAgICAgICAgICAgICAgVHJ1dGhWYWx1ZSwKICAg ICAgIGxpc3BFdHJFbmFibGVkICAgICAgICAgICAgICAgICAgICAgVHJ1dGhWYWx1ZSwKICAg ICAgIGxpc3BQcm94eUl0ckVuYWJsZWQgICAgICAgICAgICAgICAgVHJ1dGhWYWx1ZSwKICAg ICAgIGxpc3BQcm94eUV0ckVuYWJsZWQgICAgICAgICAgICAgICAgVHJ1dGhWYWx1ZSwKICAg ICAgIGxpc3BNYXBTZXJ2ZXJFbmFibGVkICAgICAgICAgICAgICAgVHJ1dGhWYWx1ZSwKICAg ICAgIGxpc3BNYXBSZXNvbHZlckVuYWJsZWQgICAgICAgICAgICAgVHJ1dGhWYWx1ZSwKICAg ICAgIGxpc3BNYXBDYWNoZVNpemUgICAgICAgICAgICAgICAgICAgVW5zaWduZWQzMiwKICAg ICAgIGxpc3BNYXBDYWNoZUxpbWl0ICAgICAgICAgICAgICAgICAgVW5zaWduZWQzMiwKICAg ICAgIGxpc3BFdHJNYXBDYWNoZVR0bCAgICAgICAgICAgICAgICAgVW5zaWduZWQzMiwKICAg ICAgIGxpc3BSbG9jUHJvYmVFbmFibGVkICAgICAgICAgICAgICAgVHJ1dGhWYWx1ZSwKICAg ICAgIGxpc3BFdHJBY2NlcHRNYXBEYXRhRW5hYmxlZCAgICAgICAgVHJ1dGhWYWx1ZSwKICAg ICAgIGxpc3BFdHJBY2NlcHRNYXBEYXRhVmVyaWZ5RW5hYmxlZCAgVHJ1dGhWYWx1ZSwKICAg ICAgIGxpc3BNYXBSZXF1ZXN0c0luICAgICAgICAgICAgICAgICAgQ291bnRlcjY0LAogICAg ICAgbGlzcE1hcFJlcXVlc3RzT3V0ICAgICAgICAgICAgICAgICBDb3VudGVyNjQsCiAgICAg ICBsaXNwTWFwUmVwbGllc0luICAgICAgICAgICAgICAgICAgIENvdW50ZXI2NCwKICAgICAg IGxpc3BNYXBSZXBsaWVzT3V0ICAgICAgICAgICAgICAgICAgQ291bnRlcjY0LAogICAgICAg bGlzcE1hcFJlZ2lzdGVyc0luICAgICAgICAgICAgICAgICBDb3VudGVyNjQsCiAgICAgICBs aXNwTWFwUmVnaXN0ZXJzT3V0ICAgICAgICAgICAgICAgIENvdW50ZXI2NAogICB9CgogICBs aXNwQWRkcmVzc0ZhbWlseSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBBZGRyZXNz RmFtaWx5TnVtYmVycwogICAgICAgTUFYLUFDQ0VTUyBub3QtYWNjZXNzaWJsZQogICAgICAg U1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUg YWRkcmVzcyBmYW1pbHkgbnVtYmVyIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+b2Y8L2Zv bnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj50aGF0PC9mb250Pjwv c3Ryb25nPiB0aGUgbGlzcCBkZXZpY2UgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj50aGF0 PC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICBpcyA8c3RyaWtlPjxmb250IGNvbG9yPSJy ZWQiPmFibGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5l bmFibGVkPC9mb250Pjwvc3Ryb25nPiB0byBsaXNwIHByb2Nlc3MgYSBwYWNrZXQgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5kZXN0aW5lZDwvZm9udD48L3N0cmlrZT4gZm9yCiAgICAg ICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+dGhhdDwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmFzIGEKICAgICAgICAgICAgZGVzdGluYXRp b248L2ZvbnQ+PC9zdHJvbmc+IGFkZHJlc3MgZmFtaWx5LiIKICAgICAgICA6Oj0geyBsaXNw RW50cnkgMSB9CgogICBsaXNwSXRyRW5hYmxlZCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFY ICAgICBUcnV0aFZhbHVlCiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9 InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0i Z3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3Vy cmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiSW5kaWNhdGVzIHRoZSBzdGF0 dXMgb2YgSVRSIHJvbGUgb24gdGhpcyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRldmlj ZS4iPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZGV2aWNl CiAgICAgICAgICAgICgwID0gSVRSIGRpc2FibGVkOyAxID0gSVRSIGVuYWJsZWQpLiI8L2Zv bnQ+PC9zdHJvbmc+CiAgICAgICA6Oj0geyBsaXNwRW50cnkgMiB9CgogICBsaXNwRXRyRW5h YmxlZCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBUcnV0aFZhbHVlCiAgICAgICBN QVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48 L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48 L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04K ICAgICAgICAgICAiSW5kaWNhdGVzIHRoZSBzdGF0dXMgb2YgRVRSIHJvbGUgb24gdGhpcyA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRldmljZS4iPC9mb250Pjwvc3RyaWtlPiA8c3Ry b25nPjxmb250IGNvbG9yPSJncmVlbiI+ZGV2aWNlCiAgICAgICAgICAgICgwID0gRVRSIGRp c2FibGVkOyAxID0gRVRSIGVuYWJsZWQpLiI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICA6Oj0g eyBsaXNwRW50cnkgMyB9CgogICBsaXNwUHJveHlJdHJFbmFibGVkIE9CSkVDVC1UWVBFCiAg ICAgICBTWU5UQVggICAgIFRydXRoVmFsdWUKICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48 Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RB VFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJJbmRpY2F0 ZXMgdGhlIHN0YXR1cyBvZiBQcm94eS1JVFIgcm9sZSBvbiB0aGlzCiAgICAgICAgICAgIDxz dHJpa2U+PGZvbnQgY29sb3I9InJlZCI+ZGV2aWNlLiI8L2ZvbnQ+PC9zdHJpa2U+CiAgICAg ICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5kZXZpY2UgKDAgPSBQSVRSIGRp c2FibGVkOyAxID0gUElUUiBlbmFibGVkKS4iPC9mb250Pjwvc3Ryb25nPgogICAgICAgOjo9 IHsgbGlzcEVudHJ5IDQgfQoKICAgbGlzcFByb3h5RXRyRW5hYmxlZCBPQkpFQ1QtVFlQRQog ICAgICAgU1lOVEFYICAgICBUcnV0aFZhbHVlCiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNU QVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiSW5kaWNh dGVzIHRoZSBzdGF0dXMgb2YgUHJveHktRVRSIHJvbGUgb24gdGhpcwogICAgICAgICAgICA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRldmljZS4iPC9mb250Pjwvc3RyaWtlPgogICAg ICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZGV2aWNlICgwID0gUEVUUiBk aXNhYmxlZDsgMSA9IFBFVFIgZW5hYmxlZCkuIjwvZm9udD48L3N0cm9uZz4KICAgICAgIDo6 PSB7IGxpc3BFbnRyeSA1IH0KCiAgIGxpc3BNYXBTZXJ2ZXJFbmFibGVkIE9CSkVDVC1UWVBF CiAgICAgICBTWU5UQVggICAgIFRydXRoVmFsdWUKICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAg U1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJJbmRp Y2F0ZXMgdGhlIHN0YXR1cyBvZiBNYXAgU2VydmVyIHJvbGUgb24gdGhpcwogICAgICAgICAg ICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRldmljZS4iPC9mb250Pjwvc3RyaWtlPgog ICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZGV2aWNlICgwID0gTVMg ZGlzYWJsZWQ7IDEgPSBNUyBlbmFibGVkKS4iPC9mb250Pjwvc3Ryb25nPgogICAgICAgOjo9 IHsgbGlzcEVudHJ5IDYgfQoKICAgbGlzcE1hcFJlc29sdmVyRW5hYmxlZCBPQkpFQ1QtVFlQ RQogICAgICAgU1lOVEFYICAgICBUcnV0aFZhbHVlCiAgICAgICBNQVgtQUNDRVNTIDxzdHJp a2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAg IFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiSW5k aWNhdGVzIHRoZSBzdGF0dXMgb2YgTWFwIFJlc29sdmVyIHJvbGUgb24KICAgICAgICAgICAg dGhpcyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRldmljZS4iPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZGV2aWNlICgwID0gTVIgZGlzYWJsZWQ7 IDEgPSBNUiBlbmFibGVkKS4iPC9mb250Pjwvc3Ryb25nPgogICAgICAgOjo9IHsgbGlzcEVu dHJ5IDcgfQoKICAgbGlzcE1hcENhY2hlU2l6ZSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFY ICAgICBVbnNpZ25lZDMyCiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9 InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0i Z3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3Vy cmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiU2l6ZSBvZiBFSUQtdG8tUkxP QyBtYXAgY2FjaGUgb24gdGhpcyBkZXZpY2UuIgogICAgICAgOjo9IHsgbGlzcEVudHJ5IDgg fQoKICAgbGlzcE1hcENhY2hlTGltaXQgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAg VW5zaWduZWQzMgogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQi PmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVu Ij5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQK ICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIk1heGltdW0gcGVybWlzc2libGUgc2l6 ZSBvZiBFSUQtdG8tUkxPQyBtYXAKICAgICAgICAgICAgY2FjaGUgb24gdGhpcyBkZXZpY2Uu IgogICAgICAgOjo9IHsgbGlzcEVudHJ5IDkgfQoKICAgbGlzcEV0ck1hcENhY2hlVHRsIE9C SkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIFVuc2lnbmVkMzIKICAgICAgIE1BWC1BQ0NF U1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25n PgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAg ICAgICJUaW1lIGluIG1pbnV0ZXMgdGhpcyBkZXZpY2Ugd2lsbCBzdG9yZSB0aGUKICAgICAg ICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5tYXBwaW5nPC9mb250Pjwvc3RyaWtl PgogICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+RUlELXRvLVJMT0Mg bWFwPC9mb250Pjwvc3Ryb25nPiByZWNvcmQgaW4gdGhlIG1hcCBjYWNoZS4iCiAgICAgICA6 Oj0geyBsaXNwRW50cnkgMTAgfQoKICAgbGlzcFJsb2NQcm9iZUVuYWJsZWQgT0JKRUNULVRZ UEUKICAgICAgIFNZTlRBWCAgICAgVHJ1dGhWYWx1ZQogICAgICAgTUFYLUFDQ0VTUyA8c3Ry aWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAg ICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIklu ZGljYXRlcyB0aGUgc3RhdHVzIG9mIHJsb2MtcHJvYmluZyBmZWF0dXJlCiAgICAgICAgICAg IG9uIHRoaXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5kZXZpY2UuIjwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRldmljZSAoMCA9IGRpc2FibGVk OyAxID0gZW5hYmxlZCkuIjwvZm9udD48L3N0cm9uZz4KICAgICAgIDo6PSB7IGxpc3BFbnRy eSAxMSB9CgogICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxpc3BFdHJBY2NlcHRNYXBE YXRhPC9mb250Pjwvc3RyaWtlPgoKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmxp c3BFdHJBY2NlcHRNYXBEYXRhRW5hYmxlZDwvZm9udD48L3N0cm9uZz4gT0JKRUNULVRZUEUK ICAgICAgIFNZTlRBWCAgICAgVHJ1dGhWYWx1ZQogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtl Pjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBT VEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkluZGlj YXRlcyB0aGUgc3RhdHVzIG9mIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+dGhpcyBkZXZp Y2UgZm9yPC9mb250Pjwvc3RyaWtlPiBhY2NlcHRpbmcgcGlnZ3liYWNrZWQKICAgICAgICAg ICAgbWFwcGluZyBkYXRhIHJlY2VpdmVkIGluIGEgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVk Ij5tYXAtcmVxdWVzdC4iPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJn cmVlbiI+bWFwLXJlcXVlc3Qgb24KICAgICAgICAgICAgdGhpcyBkZXZpY2UgKDAgPSBkaXNh YmxlZDsgMSA9IGVuYWJsZWQpLiI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICA6Oj0geyBsaXNw RW50cnkgMTIgfQoKICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5saXNwRXRyQWNjZXB0 TWFwRGF0YVZlcmlmeTwvZm9udD48L3N0cmlrZT4KCiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9 ImdyZWVuIj5saXNwRXRyQWNjZXB0TWFwRGF0YVZlcmlmeUVuYWJsZWQ8L2ZvbnQ+PC9zdHJv bmc+IE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIFRydXRoVmFsdWUKICAgICAgIE1B WC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwv c3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwv c3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgog ICAgICAgICAgICJJbmRpY2F0ZXMgdGhlIHN0YXR1cyBvZiA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPnRoaXMgZGV2aWNlIGZvcjwvZm9udD48L3N0cmlrZT4gdmVyaWZ5aW5nIGFjY2Vw dGVkCiAgICAgICAgICAgIHBpZ2d5YmFja2VkIG1hcHBpbmcgZGF0YSByZWNlaXZlZCBpbiBh IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+bWFwLXJlcXVlc3QuIjwvZm9udD48L3N0cmlr ZT4KICAgICAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPm1hcC1yZXF1ZXN0 IG9uIHRoaXMgZGV2aWNlICgwID0gZGlzYWJsZWQ7CiAgICAgICAgICAgIDEgPSBlbmFibGVk KS4iPC9mb250Pjwvc3Ryb25nPgogICAgICAgOjo9IHsgbGlzcEVudHJ5IDEzIH0KCiAgIGxp c3BNYXBSZXF1ZXN0c0luIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIENvdW50ZXI2 NAogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2li bGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9u bHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERF U0NSSVBUSU9OCiAgICAgICAgICAgIlRvdGFsIG51bWJlciBvZiBtYXAgcmVxdWVzdHMgcmVj ZWl2ZWQgYnkgdGhpcwogICAgICAgICAgICBkZXZpY2UgZm9yIGFueSBFSUQgcHJlZml4IG9m IHRoZSBnaXZlbiBhZGRyZXNzCiAgICAgICAgICAgIGZhbWlseS4iCiAgICAgICA6Oj0geyBs aXNwRW50cnkgMTQgfQoKICAgbGlzcE1hcFJlcXVlc3RzT3V0IE9CSkVDVC1UWVBFCiAgICAg ICBTWU5UQVggICAgIENvdW50ZXI2NAogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250 IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMg ICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRvdGFsIG51bWJl ciBvZiBtYXAgcmVxdWVzdHMgc2VudCBieSB0aGlzCiAgICAgICAgICAgIGRldmljZSBmb3Ig YW55IEVJRCBwcmVmaXggb2YgdGhlIGdpdmVuCiAgICAgICAgICAgIGFkZHJlc3MgZmFtaWx5 LiIKICAgICAgIDo6PSB7IGxpc3BFbnRyeSAxNSB9CgogICBsaXNwTWFwUmVwbGllc0luIE9C SkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIENvdW50ZXI2NAogICAgICAgTUFYLUFDQ0VT UyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+ IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+ CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAg ICAgIlRvdGFsIG51bWJlciBvZiBtYXAgcmVwbGllcyByZWNlaXZlZCBieSB0aGlzCiAgICAg ICAgICAgIGRldmljZSBmb3IgYW55IEVJRCBwcmVmaXggb2YgdGhlIGdpdmVuCiAgICAgICAg ICAgIGFkZHJlc3MgZmFtaWx5LiIKICAgICAgIDo6PSB7IGxpc3BFbnRyeSAxNiB9CgogICBs aXNwTWFwUmVwbGllc091dCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBDb3VudGVy NjQKICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3Np YmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1v bmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBE RVNDUklQVElPTgogICAgICAgICAgICJUb3RhbCBudW1iZXIgb2YgbWFwIHJlcGxpZXMgc2Vu dCBieSB0aGlzCiAgICAgICAgICAgIGRldmljZSBmb3IgYW55IEVJRCBwcmVmaXggb2YgdGhl IGdpdmVuCiAgICAgICAgICAgIGFkZHJlc3MgZmFtaWx5LiIKICAgICAgIDo6PSB7IGxpc3BF bnRyeSAxNyB9CgogICBsaXNwTWFwUmVnaXN0ZXJzSW4gT0JKRUNULVRZUEUKICAgICAgIFNZ TlRBWCAgICAgQ291bnRlcjY0CiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29s b3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAg Y3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVG90YWwgbnVtYmVyIG9m IG1hcCByZWdpc3RlcnMgcmVjZWl2ZWQgYnkgdGhpcwogICAgICAgICAgICBkZXZpY2UgZm9y IGFueSBFSUQgcHJlZml4IG9mIHRoZSBnaXZlbiBhZGRyZXNzCiAgICAgICAgICAgIGZhbWls eS4iCiAgICAgICA6Oj0geyBsaXNwRW50cnkgMTggfQoKICAgbGlzcE1hcFJlZ2lzdGVyc091 dCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBDb3VudGVyNjQKICAgICAgIE1BWC1B Q0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ry b25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAg ICAgICAgICJUb3RhbCBudW1iZXIgb2YgbWFwIHJlZ2lzdGVycyBzZW50IGJ5IHRoaXMKICAg ICAgICAgICAgZGV2aWNlIGZvciBhbnkgRUlEIHByZWZpeCBvZiB0aGUgZ2l2ZW4KICAgICAg ICAgICAgYWRkcmVzcyBmYW1pbHkuIgogICAgICAgOjo9IHsgbGlzcEVudHJ5IDE5IH0KCiAg IGxpc3BNYXBwaW5nRGF0YWJhc2VUYWJsZSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAg ICBTRVFVRU5DRSBPRiBsaXNwTWFwcGluZ0RhdGFiYXNlRW50cnkKICAgICAgIE1BWC1BQ0NF U1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVT Q1JJUFRJT04KICAgICAgICAgICAiVGhpcyB0YWJsZSByZXByZXNlbnRzIHRoZSBFSUQtdG8t UkxPQyBtYXBwaW5nCiAgICAgICAgICAgIGRhdGFiYXNlIHRoYXQgY29udGFpbnMgdGhlIEVJ RC1wcmVmaXggdG8gUkxPQwogICAgICAgICAgICBtYXBwaW5ncyBjb25maWd1cmVkIG9uIGFu IEVUUi4gIEluIGdlbmVyYWwsCiAgICAgICAgICAgIHRoaXMgdGFibGUgd291bGQgYmUgcmVw cmVzZW50YXRpdmUgb2YgYWxsIHN1Y2gKICAgICAgICAgICAgbWFwcGluZ3MgZm9yIDxzdHJp a2U+PGZvbnQgY29sb3I9InJlZCI+YTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBj b2xvcj0iZ3JlZW4iPnRoZTwvZm9udD48L3N0cm9uZz4gZ2l2ZW4gPHN0cm9uZz48Zm9udCBj b2xvcj0iZ3JlZW4iPmxpc3A8L2ZvbnQ+PC9zdHJvbmc+IHNpdGUKICAgICAgICAgICAgPHN0 cmlrZT48Zm9udCBjb2xvcj0icmVkIj50aGF0PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiI+dG8gd2hpY2g8L2ZvbnQ+PC9zdHJvbmc+IHRoaXMKICAgICAg ICAgICAgZGV2aWNlIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YmVsb25ncyB0by4iPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+YmVsb25ncy4iPC9m b250Pjwvc3Ryb25nPgogICAgICAgUkVGRVJFTkNFICJbTElTUF0iCiAgICAgICA6Oj0geyA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxpc3A8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9ImdyZWVuIj5saXNwTUlCPC9mb250Pjwvc3Ryb25nPiAyIH0KCiAgIGxp c3BNYXBwaW5nRGF0YWJhc2VFbnRyeSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBs aXNwTWFwcGluZ0RhdGFiYXNlRW50cnkKICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2li bGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiQW4gZW50cnkgKGNvbmNlcHR1YWwgcm93KSBpbiB0aGUKICAgICAgICAgICAgbGlz cE1hcHBpbmdEYXRhYmFzZVRhYmxlLiIKICAgICAgIElOREVYICAgeyA8c3RyaWtlPjxmb250 IGNvbG9yPSJyZWQiPmxpc3BNYXBwaW5nRGF0YWJhc2VFaWRMZW5ndGg8L2ZvbnQ+PC9zdHJp a2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5saXNwTWFwcGluZ0RhdGFiYXNlRWlk TGVuZ3RoLDwvZm9udD48L3N0cm9uZz4KICAgICAgICAgICAgICAgICBsaXNwTWFwcGluZ0Rh dGFiYXNlRWlkIH0KICAgICAgIDo6PSB7IGxpc3BNYXBwaW5nRGF0YWJhc2VUYWJsZSAxIH0K CiAgIGxpc3BNYXBwaW5nRGF0YWJhc2VFbnRyeSA6Oj0gU0VRVUVOQ0UgewogICAgICAgbGlz cE1hcHBpbmdEYXRhYmFzZUVpZExlbmd0aCAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0i cmVkIj5JTlRFR0VSLDwvZm9udD48L3N0cmlrZT4gICAgICAgIDxzdHJvbmc+PGZvbnQgY29s b3I9ImdyZWVuIj5JbnRlZ2VyMzIsPC9mb250Pjwvc3Ryb25nPgogICAgICAgbGlzcE1hcHBp bmdEYXRhYmFzZUVpZCAgICAgICAgICAgICAgTGlzcEFkZHJlc3NUeXBlLAogICAgICAgbGlz cE1hcHBpbmdEYXRhYmFzZUxzYiAgICAgICAgICAgICAgVW5zaWduZWQzMiwKICAgICAgIGxp c3BNYXBwaW5nRGF0YWJhc2VFaWRQYXJ0aXRpb25lZCAgIFRydXRoVmFsdWUsCiAgICAgICBs aXNwTWFwcGluZ0RhdGFiYXNlRGVjYXBPY3RldHMgICAgICBDb3VudGVyNjQsCiAgICAgICA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxpc3BNYXBwaW5nRGF0YWJhc2VEZWNhcFBrdHMg ICAgICAgIENvdW50ZXI2NDwvZm9udD48L3N0cmlrZT4KICAgICAgIDxzdHJvbmc+PGZvbnQg Y29sb3I9ImdyZWVuIj5saXNwTWFwcGluZ0RhdGFiYXNlRGVjYXBQYWNrZXRzICAgICBDb3Vu dGVyNjQsPC9mb250Pjwvc3Ryb25nPgogICAgICAgbGlzcE1hcHBpbmdEYXRhYmFzZUVuY2Fw T2N0ZXRzICAgICAgQ291bnRlcjY0LAogICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVk Ij5saXNwTWFwcGluZ0RhdGFiYXNlRW5jYXBQa3RzPC9mb250Pjwvc3RyaWtlPgogICAgICAg PHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmxpc3BNYXBwaW5nRGF0YWJhc2VFbmNhcFBh Y2tldHM8L2ZvbnQ+PC9zdHJvbmc+ICAgICBDb3VudGVyNjQKICAgfQoKICAgbGlzcE1hcHBp bmdEYXRhYmFzZUVpZExlbmd0aCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICA8c3Ry aWtlPjxmb250IGNvbG9yPSJyZWQiPklOVEVHRVI8L2ZvbnQ+PC9zdHJpa2U+ICAgICA8c3Ry b25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMyICgwLi4xMDI0KTwvZm9udD48L3N0 cm9uZz4KICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAg ICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhpcyBvYmplY3Qg Z2l2ZXMgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+bGVuZ3RoPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+b2N0ZXQtbGVuZ3RoPC9mb250Pjwv c3Ryb25nPiBvZgogICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxpc3BN YXBwaW5nRGF0YWJhc2VFaWQsIHRoZSBuZXh0IG9iamVjdC4iPC9mb250Pjwvc3RyaWtlPgog ICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+bGlzcE1hcHBpbmdEYXRh YmFzZUVpZC4iPC9mb250Pjwvc3Ryb25nPgogICAgICAgOjo9IHsgbGlzcE1hcHBpbmdEYXRh YmFzZUVudHJ5IDEgfQoKICAgbGlzcE1hcHBpbmdEYXRhYmFzZUVpZCBPQkpFQ1QtVFlQRQog ICAgICAgU1lOVEFYICAgICBMaXNwQWRkcmVzc1R5cGUKICAgICAgIE1BWC1BQ0NFU1Mgbm90 LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJ T04KICAgICAgICAgICAiVGhlIEVJRCBwcmVmaXggb2YgdGhlIG1hcHBpbmcgZGF0YWJhc2Uu IgogICAgICAgOjo9IHsgbGlzcE1hcHBpbmdEYXRhYmFzZUVudHJ5IDIgfQoKICAgbGlzcE1h cHBpbmdEYXRhYmFzZUxzYiBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBVbnNpZ25l ZDMyCiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNz aWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQt b25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAg REVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIGxvY2F0b3Igc3RhdHVzIGJpdHMgZm9yIHRo aXMgRUlEIHByZWZpeC4iCiAgICAgICA6Oj0geyBsaXNwTWFwcGluZ0RhdGFiYXNlRW50cnkg MyB9CgogICBsaXNwTWFwcGluZ0RhdGFiYXNlRWlkUGFydGl0aW9uZWQgT0JKRUNULVRZUEUK ICAgICAgIFNZTlRBWCAgICAgVHJ1dGhWYWx1ZQogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtl Pjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBT VEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkluZGlj YXRlcyBpZiB0aGlzIGRldmljZSBpcyBwYXJ0aXRpb25lZCBmcm9tCiAgICAgICAgICAgIHRo ZSBzaXRlIHRoYXQgY29udGFpbnMgdGhpcyBFSUQgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVk Ij5wcmVmaXguIjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4i PnByZWZpeAogICAgICAgICAgICAoMCA9IG5vdCBwYXJ0aW9uZWQ7IDEgPSBwYXJ0aXRpb25l ZCkuIjwvZm9udD48L3N0cm9uZz4KICAgICAgIDo6PSB7IGxpc3BNYXBwaW5nRGF0YWJhc2VF bnRyeSA0IH0KCiAgIGxpc3BNYXBwaW5nRGF0YWJhc2VEZWNhcE9jdGV0cyBPQkpFQ1QtVFlQ RQogICAgICAgU1lOVEFYICAgICBDb3VudGVyNjQKICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAg U1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUg bnVtYmVyIG9mIG9jdGV0cyBvZiBMaXNwIHBhY2tldHMgdGhhdAogICAgICAgICAgICB3ZXJl IGRlY2Fwc3VsYXRlZCBieSB0aGlzIGRldmljZSBhZGRyZXNzZWQKICAgICAgICAgICAgdG8g YSBob3N0IHdpdGhpbiB0aGlzIEVJRC1wcmVmaXguIgogICAgICAgOjo9IHsgbGlzcE1hcHBp bmdEYXRhYmFzZUVudHJ5IDUgfQoKICAgbGlzcE1hcHBpbmdEYXRhYmFzZURlY2FwUGFja2V0 cyBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBDb3VudGVyNjQKICAgICAgIE1BWC1B Q0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ry b25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAg ICAgICAgICJUaGUgbnVtYmVyIG9mIExpc3AgcGFja2V0cyB0aGF0IHdlcmUKICAgICAgICAg ICAgZGVjYXBzdWxhdGVkIGJ5IHRoaXMgZGV2aWNlIGFkZHJlc3NlZCB0byBhCiAgICAgICAg ICAgIGhvc3Qgd2l0aGluIHRoaXMgRUlELXByZWZpeC4iCiAgICAgICA6Oj0geyBsaXNwTWFw cGluZ0RhdGFiYXNlRW50cnkgNiB9CgogICBsaXNwTWFwcGluZ0RhdGFiYXNlRW5jYXBPY3Rl dHMgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgQ291bnRlcjY0CiAgICAgICBNQVgt QUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0 cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAg ICAgICAgICAiVGhlIG51bWJlciBvZiBvY3RldHMgb2YgTGlzcCBwYWNrZXRzLCB0aGF0CiAg ICAgICAgICAgIHdlcmUgZW5jYXBzdWxhdGVkIGJ5IHRoaXMgZGV2aWNlLCB3aG9zZSBpbm5l cgogICAgICAgICAgICBoZWFkZXIgc291cmNlIGFkZHJlc3MgbWF0Y2hlZCB0aGlzIEVJRCBw cmVmaXguIgogICAgICAgOjo9IHsgbGlzcE1hcHBpbmdEYXRhYmFzZUVudHJ5IDcgfQoKICAg bGlzcE1hcHBpbmdEYXRhYmFzZUVuY2FwUGFja2V0cyBPQkpFQ1QtVFlQRQogICAgICAgU1lO VEFYICAgICBDb3VudGVyNjQKICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xv cj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBj dXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgbnVtYmVyIG9mIExp c3AgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5wYWNrZXRzLDwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnBhY2tldHM8L2ZvbnQ+PC9zdHJvbmc+IHRo YXQgd2VyZQogICAgICAgICAgICBlbmNhcHN1bGF0ZWQgYnkgdGhpcyA8c3RyaWtlPjxmb250 IGNvbG9yPSJyZWQiPmRldmljZSw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29s b3I9ImdyZWVuIj5kZXZpY2UgdGhhdDwvZm9udD48L3N0cm9uZz4gd2hvc2UgaW5uZXIKICAg ICAgICAgICAgaGVhZGVyIHNvdXJjZSBhZGRyZXNzIG1hdGNoZWQgdGhpcyBFSUQgcHJlZml4 LiIKICAgICAgIDo6PSB7IGxpc3BNYXBwaW5nRGF0YWJhc2VFbnRyeSA4IH0KCiAgIGxpc3BN YXBwaW5nRGF0YWJhc2VMb2NhdG9yVGFibGUgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAg ICAgU0VRVUVOQ0UgT0YgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JFbnRyeQogICAgICAg TUFYLUFDQ0VTUyBub3QtYWNjZXNzaWJsZQogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAg ICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGlzIHRhYmxlIHJlcHJlc2VudHMgdGhl IHNldCBvZiByb3V0aW5nIGxvY2F0b3JzCiAgICAgICAgICAgIHBlciBFSUQgcHJlZml4IGNv bnRhaW5lZCBpbiB0aGUgRUlELXRvLVJMT0MKICAgICAgICAgICAgZGF0YWJhc2UgY29uZmln dXJlZCBvbiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFuPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+dGhpczwvZm9udD48L3N0cm9uZz4gRVRSLiIK ICAgICAgIFJFRkVSRU5DRSAiW0xJU1BdIgogICAgICAgOjo9IHsgPHN0cmlrZT48Zm9udCBj b2xvcj0icmVkIj5saXNwPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJn cmVlbiI+bGlzcE1JQjwvZm9udD48L3N0cm9uZz4gMyB9CgogICBsaXNwTWFwcGluZ0RhdGFi YXNlTG9jYXRvckVudHJ5IE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIGxpc3BNYXBw aW5nRGF0YWJhc2VMb2NhdG9yRW50cnkKICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2li bGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiQW4gZW50cnkgKGNvbmNlcHR1YWwgcm93KSBpbiB0aGUKICAgICAgICAgICAgbGlz cE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JUYWJsZS4iCiAgICAgICBJTkRFWCAgeyA8c3RyaWtl Pjxmb250IGNvbG9yPSJyZWQiPmxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yRWlkTGVuZ3Ro CiAgICAgICAgICAgICAgICBsaXNwTWFwcGluZ0RhdGFiYXNlTG9jYXRvckVpZAogICAgICAg ICAgICAgICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JSbG9jQWZpCiAgICAgICAgICAg ICAgICBsaXNwTWFwcGluZ0RhdGFiYXNlTG9jYXRvckVuY29kZWRSbG9jTGVuZ3RoCiAgICAg ICAgICAgICAgICBsaXNwTWFwcGluZ0RhdGFiYXNlTG9jYXRvckVuY29kZWRSbG9jPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+bGlzcE1hcHBpbmdEYXRh YmFzZUxvY2F0b3JFaWRMZW5ndGgsCiAgICAgICAgICAgICAgICBsaXNwTWFwcGluZ0RhdGFi YXNlTG9jYXRvckVpZCwKICAgICAgICAgICAgICAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2Nh dG9yUmxvY0xlbmd0aCwKICAgICAgICAgICAgICAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2Nh dG9yUmxvYzwvZm9udD48L3N0cm9uZz4gfQogICAgICAgOjo9IHsgbGlzcE1hcHBpbmdEYXRh YmFzZUxvY2F0b3JUYWJsZSAxIH0KCiAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yRW50 cnkgOjo9IFNFUVVFTkNFIHsKICAgICAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yRWlk TGVuZ3RoICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSLDwvZm9u dD48L3N0cmlrZT4gICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdl cjMyLDwvZm9udD48L3N0cm9uZz4KICAgICAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9y RWlkICAgICAgICAgICAgICAgTGlzcEFkZHJlc3NUeXBlLAogICAgICAgbGlzcE1hcHBpbmdE YXRhYmFzZUxvY2F0b3JSbG9jTGVuZ3RoICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJy ZWQiPklOVEVHRVIsPC9mb250Pjwvc3RyaWtlPiAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iPkludGVnZXIzMiw8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBsaXNwTWFwcGlu Z0RhdGFiYXNlTG9jYXRvclJsb2MgICAgICAgICAgICAgIExpc3BBZGRyZXNzVHlwZSwKICAg ICAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yUmxvY1ByaW9yaXR5ICAgICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSLDwvZm9udD48L3N0cmlrZT4gICAgICA8c3Ry b25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMyLDwvZm9udD48L3N0cm9uZz4KICAg ICAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yUmxvY1dlaWdodCAgICAgICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSLDwvZm9udD48L3N0cmlrZT4gICAgICAgIDxz dHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzIsPC9mb250Pjwvc3Ryb25nPgog ICAgICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JSbG9jTVByaW9yaXR5ICAgICA8c3Ry aWtlPjxmb250IGNvbG9yPSJyZWQiPklOVEVHRVIsPC9mb250Pjwvc3RyaWtlPiAgICAgPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMiw8L2ZvbnQ+PC9zdHJvbmc+CiAg ICAgICBsaXNwTWFwcGluZ0RhdGFiYXNlTG9jYXRvclJsb2NNV2VpZ2h0ICAgICAgIDxzdHJp a2U+PGZvbnQgY29sb3I9InJlZCI+SU5URUdFUiw8L2ZvbnQ+PC9zdHJpa2U+ICAgICAgIDxz dHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzIsPC9mb250Pjwvc3Ryb25nPgog ICAgICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JSbG9jU3RhdGUgICAgICAgICBJTlRF R0VSLAogICAgICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JSbG9jTG9jYWwgICAgICAg ICBJTlRFR0VSLAogICAgICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JSbG9jRGVjYXBP Y3RldHMgICBDb3VudGVyNjQsCiAgICAgICBsaXNwTWFwcGluZ0RhdGFiYXNlTG9jYXRvclJs b2NEZWNhcFBhY2tldHMgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+Q291bnRlcjY0PC9m b250Pjwvc3RyaWtlPiAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkNvdW50ZXI2NCw8 L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBsaXNwTWFwcGluZ0RhdGFiYXNlTG9jYXRvclJsb2NF bmNhcE9jdGV0cyAgIENvdW50ZXI2NCwKICAgICAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2Nh dG9yUmxvY0VuY2FwUGFja2V0cyAgQ291bnRlcjY0CiAgIH0KCiAgIGxpc3BNYXBwaW5nRGF0 YWJhc2VMb2NhdG9yRWlkTGVuZ3RoIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIDxz dHJpa2U+PGZvbnQgY29sb3I9InJlZCI+SU5URUdFUjwvZm9udD48L3N0cmlrZT4gICAgIDxz dHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzI8L2ZvbnQ+PC9zdHJvbmc+CiAg ICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJl bnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoaXMgb2JqZWN0IGlzIHVzZWQg dG8gZ2V0IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxlbmd0aDwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPm9jdGV0LWxlbmd0aDwvZm9udD48 L3N0cm9uZz4gb2YKICAgICAgICAgICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JFaWQs IHRoZSBuZXh0IG9iamVjdC4iCiAgICAgICA6Oj0geyBsaXNwTWFwcGluZ0RhdGFiYXNlTG9j YXRvckVudHJ5IDEgfQoKICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JFaWQgT0JKRUNU LVRZUEUKICAgICAgIFNZTlRBWCAgICAgTGlzcEFkZHJlc3NUeXBlCiAgICAgICBNQVgtQUND RVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERF U0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBFSUQgcHJlZml4IG9mIHRoZSBtYXBwaW5nIGRh dGFiYXNlIG1hcHBlZCB0bwogICAgICAgICAgICB0aGUgZ2l2ZW4gbG9jYXRvci4iCiAgICAg ICA6Oj0geyBsaXNwTWFwcGluZ0RhdGFiYXNlTG9jYXRvckVudHJ5IDIgfQoKICAgbGlzcE1h cHBpbmdEYXRhYmFzZUxvY2F0b3JSbG9jTGVuZ3RoIE9CSkVDVC1UWVBFCiAgICAgICBTWU5U QVggICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+SU5URUdFUjwvZm9udD48L3N0cmlr ZT4gICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzI8L2ZvbnQ+PC9z dHJvbmc+CiAgICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMg ICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoaXMgb2JqZWN0 IGlzIHVzZWQgdG8gZ2V0IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxlbmd0aDwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPm9jdGV0LWxlbmd0 aDwvZm9udD48L3N0cm9uZz4gb2YKICAgICAgICAgICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxv Y2F0b3JSbG9jLCB0aGUgbmV4dCBvYmplY3QuIgogICAgICAgOjo9IHsgbGlzcE1hcHBpbmdE YXRhYmFzZUxvY2F0b3JFbnRyeSAzIH0KCiAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9y UmxvYyBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBMaXNwQWRkcmVzc1R5cGUKICAg ICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVu dAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhpcyBvYmplY3QgaXMgYSBsb2Nh dG9yIGZvciB0aGUgZ2l2ZW4gRUlEIHByZWZpeAogICAgICAgICAgICBpbiB0aGUgbWFwcGlu ZyBkYXRhYmFzZS4iCiAgICAgICA6Oj0geyBsaXNwTWFwcGluZ0RhdGFiYXNlTG9jYXRvckVu dHJ5IDQgfQoKICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JSbG9jUHJpb3JpdHkgT0JK RUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5J TlRFR0VSPC9mb250Pjwvc3RyaWtlPiAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4i PkludGVnZXIzMjwvZm9udD48L3N0cm9uZz4KICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48 Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RB VFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgdW5p Y2FzdCBwcmlvcml0eSBvZiB0aGUgUkxPQy4iCiAgICAgICA6Oj0geyBsaXNwTWFwcGluZ0Rh dGFiYXNlTG9jYXRvckVudHJ5IDUgfQoKICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JS bG9jV2VpZ2h0IE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIDxzdHJpa2U+PGZvbnQg Y29sb3I9InJlZCI+SU5URUdFUjwvZm9udD48L3N0cmlrZT4gICAgIDxzdHJvbmc+PGZvbnQg Y29sb3I9ImdyZWVuIj5JbnRlZ2VyMzI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBNQVgtQUND RVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9u Zz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiVGhlIHVuaWNhc3Qgd2VpZ2h0IG9mIHRoZSBSTE9DLiIKICAgICAgIDo6PSB7IGxp c3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yRW50cnkgNiB9CgogICBsaXNwTWFwcGluZ0RhdGFi YXNlTG9jYXRvclJsb2NNUHJpb3JpdHkgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAg PHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSPC9mb250Pjwvc3RyaWtlPiAgICAg PHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMjwvZm9udD48L3N0cm9uZz4K ICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxl PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5 PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVND UklQVElPTgogICAgICAgICAgICJUaGUgbXVsdGljYXN0IHByaW9yaXR5IG9mIHRoZSBSTE9D LiIKICAgICAgIDo6PSB7IGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yRW50cnkgNyB9Cgog ICBsaXNwTWFwcGluZ0RhdGFiYXNlTG9jYXRvclJsb2NNV2VpZ2h0IE9CSkVDVC1UWVBFCiAg ICAgICBTWU5UQVggICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+SU5URUdFUjwvZm9u dD48L3N0cmlrZT4gICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzI8 L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9 InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0i Z3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3Vy cmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIG11bHRpY2FzdCB3ZWln aHQgb2YgdGhlIFJMT0MuIgogICAgICAgOjo9IHsgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0 b3JFbnRyeSA4IH0KCiAgIGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yUmxvY1N0YXRlIE9C SkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIElOVEVHRVIgPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iPnsKICAgICAgICAgICAgICAgICAgICAgZG93biAoMCksCiAgICAgICAgICAg ICAgICAgICAgIHVwICgxKSwKICAgICAgICAgICAgICAgICAgICAgdW5yZWFjaGFibGUgKDIp CiAgICAgICAgICAgICAgICAgIH08L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBNQVgtQUNDRVNT IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4K ICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAg ICAiVGhlIHN0YXRlIG9mIHRoaXMgUkxPQyBhcyBwZXIgdGhpcyBkZXZpY2UuCiAgICAgICAg ICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+MDwvZm9udD48L3N0cmlrZT4KICAgICAg ICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPigwID0gUkxPQzwvZm9udD48L3N0 cm9uZz4gaXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5mb3IgdXAsPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZG93bjs8L2ZvbnQ+PC9zdHJvbmc+ IDEgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPj0gUkxPQzwvZm9udD48L3N0cm9uZz4g aXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5mb3IgZG93biAuLi4iPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+dXA7CiAgICAgICAgICAgICAyID0g UkxPQyBpcyB1bnJlYWNoYWJsZSkuIjwvZm9udD48L3N0cm9uZz4KICAgICAgIDo6PSB7IGxp c3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yRW50cnkgOSB9CgogICBsaXNwTWFwcGluZ0RhdGFi YXNlTG9jYXRvclJsb2NMb2NhbCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBJTlRF R0VSIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj57CiAgICAgICAgICAgICAgICAgICAg IHNpdGVsb2NhbCAoMCksCiAgICAgICAgICAgICAgICAgICAgIHNpdGVzZWxmICgxKQogICAg ICAgICAgICAgICAgICB9PC9mb250Pjwvc3Ryb25nPgogICAgICAgTUFYLUFDQ0VTUyA8c3Ry aWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAg ICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgPHN0 cmlrZT48Zm9udCBjb2xvcj0icmVkIj4iT2JqZWN0IHZhbHVlPC9mb250Pjwvc3RyaWtlPgog ICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj4iSW5kaWNhdGVzIHdoZXRo ZXIgdGhlIFJMT0M8L2ZvbnQ+PC9zdHJvbmc+IGlzIDxzdHJpa2U+PGZvbnQgY29sb3I9InJl ZCI+MSBpZjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmxv Y2FsIHRvIHRoaXMKICAgICAgICAgICAgZGV2aWNlIChvciByZW1vdGUsIG1lYW5pbmcgbG9j YWwgdG8gYW5vdGhlcgogICAgICAgICAgICBkZXZpY2UgaW48L2ZvbnQ+PC9zdHJvbmc+IHRo ZSA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+c2FtZSBsaXNwIHNpdGUpLiAoMCA9IFJM T0MgaXMKICAgICAgICAgICAgYW4gYWRkcmVzcyBvbiBhbm90aGVyIGRldmljZTsgMSA9PC9m b250Pjwvc3Ryb25nPiBSTE9DIGlzIGFuCiAgICAgICAgICAgIGFkZHJlc3Mgb24gdGhpcyA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRldmljZSwgMCBpZiBvdGhlcndpc2UuIjwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRldmljZSkuIjwvZm9u dD48L3N0cm9uZz4KICAgICAgIDo6PSB7IGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yRW50 cnkgMTAgfQoKICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxvY2F0b3JSbG9jRGVjYXBPY3RldHMg T0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgQ291bnRlcjY0CiAgICAgICBNQVgtQUND RVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9u Zz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiVGhlIG51bWJlciBvZiBvY3RldHMgb2YgTGlzcCBwYWNrZXRzIHRoYXQgd2VyZQog ICAgICAgICAgICBhZGRyZXNzZWQgdG8gdGhpcyBSTE9DIG9mIHRoZSBFSUQtcHJlZml4IGFu ZAogICAgICAgICAgICB3ZXJlIGRlY2Fwc3VsYXRlZC4iCgogICAgICAgOjo9IHsgbGlzcE1h cHBpbmdEYXRhYmFzZUxvY2F0b3JFbnRyeSAxMSB9CgogICBsaXNwTWFwcGluZ0RhdGFiYXNl TG9jYXRvclJsb2NEZWNhcFBhY2tldHMgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAg Q291bnRlcjY0CiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+ YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4i PnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAog ICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIG51bWJlciBvZiBMaXNwIHBhY2tl dHMgdGhhdCB3ZXJlIGFkZHJlc3NlZAogICAgICAgICAgICB0byB0aGlzIFJMT0Mgb2YgdGhl IEVJRC1wcmVmaXggYW5kIHdlcmUKICAgICAgICAgICAgZGVjYXBzdWxhdGVkLiIKICAgICAg IDo6PSB7IGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yRW50cnkgMTIgfQoKICAgbGlzcE1h cHBpbmdEYXRhYmFzZUxvY2F0b3JSbG9jRW5jYXBPY3RldHMgT0JKRUNULVRZUEUKICAgICAg IFNZTlRBWCAgICAgQ291bnRlcjY0CiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQg Y29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBj b2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAg ICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIG51bWJlciBv ZiBvY3RldHMgb2YgTGlzcCBwYWNrZXRzIHRoYXQgd2VyZQogICAgICAgICAgICBlbmNhcHN1 bGF0ZWQgYnkgdGhpcyBkZXZpY2UgdXNpbmcgdGhpcyBSTE9DCiAgICAgICAgICAgIGFkZHJl c3MgYXMgdGhlIHNvdXJjZSwgYW5kIHRoYXQgd2VyZSBzb3VyY2VkCiAgICAgICAgICAgIGJ5 IGFuIGFkZHJlc3Mgb2YgdGhpcyBFSUQtcHJlZml4LiIKICAgICAgIDo6PSB7IGxpc3BNYXBw aW5nRGF0YWJhc2VMb2NhdG9yRW50cnkgMTMgfQoKICAgbGlzcE1hcHBpbmdEYXRhYmFzZUxv Y2F0b3JSbG9jRW5jYXBQYWNrZXRzIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIENv dW50ZXI2NAogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFj Y2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5y ZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAg ICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgTGlzcCBwYWNrZXRz IHRoYXQgd2VyZQogICAgICAgICAgICBlbmNhcHN1bGF0ZWQgYnkgdGhpcyBkZXZpY2UgdXNp bmcgdGhpcyBSTE9DCiAgICAgICAgICAgIGFkZHJlc3MgYXMgdGhlIHNvdXJjZSwgYW5kIHRo YXQgd2VyZSBzb3VyY2VkCiAgICAgICAgICAgIGJ5IGFuIGFkZHJlc3Mgb2YgdGhpcyBFSUQt cHJlZml4LiIKICAgICAgIDo6PSB7IGxpc3BNYXBwaW5nRGF0YWJhc2VMb2NhdG9yRW50cnkg MTQgfQoKICAgbGlzcE1hcENhY2hlVGFibGUgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAg ICAgU0VRVUVOQ0UgT0YgbGlzcE1hcENhY2hlRW50cnkKICAgICAgIE1BWC1BQ0NFU1Mgbm90 LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJ T04KICAgICAgICAgICAiVGhpcyB0YWJsZSByZXByZXNlbnRzIHRoZSBzaG9ydC1saXZlZCwg b24tZGVtYW5kCiAgICAgICAgICAgIHRhYmxlIG9uIGFuIElUUiB0aGF0IHN0b3JlcywgdHJh Y2tzLCBhbmQgaXMKICAgICAgICAgICAgcmVzcG9uc2libGUgZm9yIHRpbWluZy1vdXQgYW5k IG90aGVyd2lzZQogICAgICAgICAgICB2YWxpZGF0aW5nIEVJRC10by1STE9DIG1hcHBpbmdz LiIKICAgICAgIFJFRkVSRU5DRSAiW0xJU1BdIgogICAgICAgOjo9IHsgPHN0cmlrZT48Zm9u dCBjb2xvcj0icmVkIj5saXNwPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+bGlzcE1JQjwvZm9udD48L3N0cm9uZz4gNCB9CgogICBsaXNwTWFwQ2FjaGVF bnRyeSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBsaXNwTWFwQ2FjaGVFbnRyeQog ICAgICAgTUFYLUFDQ0VTUyBub3QtYWNjZXNzaWJsZQogICAgICAgU1RBVFVTICAgICBjdXJy ZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJBbiBlbnRyeSAoY29uY2VwdHVh bCByb3cpIGluIHRoZSBsaXNwTWFwQ2FjaGVUYWJsZS4iCiAgICAgICBJTkRFWCAgICAgIHsg PHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5saXNwTWFwQ2FjaGVFaWRMZW5ndGg8L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5saXNwTWFwQ2FjaGVFaWRM ZW5ndGgsPC9mb250Pjwvc3Ryb25nPgogICAgICAgICAgICAgICAgICAgIGxpc3BNYXBDYWNo ZUVpZAogICAgICAgICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+bGlz cE1hcENhY2hlRWlkTWFza0xlbmd0aDwvZm9udD48L3N0cmlrZT4gfQogICAgICAgOjo9IHsg bGlzcE1hcENhY2hlVGFibGUgMSB9CgogICBsaXNwTWFwQ2FjaGVFbnRyeSA6Oj0gU0VRVUVO Q0UgewogICAgICAgbGlzcE1hcENhY2hlRWlkTGVuZ3RoICAgICAgICAgICA8c3RyaWtlPjxm b250IGNvbG9yPSJyZWQiPklOVEVHRVIsPC9mb250Pjwvc3RyaWtlPiAgICAgICAgICAgPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMiw8L2ZvbnQ+PC9zdHJvbmc+CiAg ICAgICBsaXNwTWFwQ2FjaGVFaWQgICAgICAgICAgICAgICAgIExpc3BBZGRyZXNzVHlwZSwK ICAgICAgIGxpc3BNYXBDYWNoZUVpZFVwVGltZSAgICAgICAgICAgVGltZVRpY2tzLAogICAg ICAgbGlzcE1hcENhY2hlRWlkRXhwaXJ5VGltZSAgICAgICBUaW1lVGlja3MsCiAgICAgICBs aXNwTWFwQ2FjaGVFaWRTdGF0ZSAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJl ZCI+SU5URUdFUiw8L2ZvbnQ+PC9zdHJpa2U+ICAgICAgICAgICAgPHN0cm9uZz48Zm9udCBj b2xvcj0iZ3JlZW4iPlRydXRoVmFsdWUsPC9mb250Pjwvc3Ryb25nPgogICAgICAgbGlzcE1h cENhY2hlRWlkQXV0aG9yaXRhdGl2ZSAgICBUcnV0aFZhbHVlLAogICAgICAgbGlzcE1hcENh Y2hlRGVjYXBPY3RldHMgICAgICAgICBDb3VudGVyNjQsCiAgICAgICA8c3RyaWtlPjxmb250 IGNvbG9yPSJyZWQiPmxpc3BNYXBDYWNoZURlY2FwUGt0cyAgICAgICAgICAgQ291bnRlcjY0 PC9mb250Pjwvc3RyaWtlPgogICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmxp c3BNYXBDYWNoZURlY2FwUGFja2V0cyAgICAgICAgQ291bnRlcjY0LDwvZm9udD48L3N0cm9u Zz4KICAgICAgIGxpc3BNYXBDYWNoZUVuY2FwT2N0ZXRzICAgICAgICAgQ291bnRlcjY0LAog ICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5saXNwTWFwQ2FjaGVFbmNhcFBrdHM8 L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+bGlz cE1hcENhY2hlRW5jYXBQYWNrZXRzPC9mb250Pjwvc3Ryb25nPiAgICAgICAgQ291bnRlcjY0 CiAgIH0KCiAgIGxpc3BNYXBDYWNoZUVpZExlbmd0aCBPQkpFQ1QtVFlQRQogICAgICAgU1lO VEFYICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPklOVEVHRVI8L2ZvbnQ+PC9zdHJp a2U+ICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMyPC9mb250Pjwv c3Ryb25nPgogICAgICAgTUFYLUFDQ0VTUyBub3QtYWNjZXNzaWJsZQogICAgICAgU1RBVFVT ICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGlzIG9iamVj dCBpcyB1c2VkIHRvIGdldCB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5sZW5ndGg8 L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5vY3RldC1sZW5n dGg8L2ZvbnQ+PC9zdHJvbmc+IG9mCiAgICAgICAgICAgIGxpc3BNYXBDYWNoZUVpZCwgdGhl IG5leHQgb2JqZWN0LiIKICAgICAgIDo6PSB7IGxpc3BNYXBDYWNoZUVudHJ5IDEgfQoKICAg bGlzcE1hcENhY2hlRWlkIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIExpc3BBZGRy ZXNzVHlwZQogICAgICAgTUFYLUFDQ0VTUyBub3QtYWNjZXNzaWJsZQogICAgICAgU1RBVFVT ICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgRUlEIHBy ZWZpeCBpbiB0aGUgbWFwcGluZyBjYWNoZS4iCiAgICAgICA6Oj0geyBsaXNwTWFwQ2FjaGVF bnRyeSAyIH0KCiAgIGxpc3BNYXBDYWNoZUVpZFVwVGltZSBPQkpFQ1QtVFlQRQogICAgICAg U1lOVEFYICAgICBUaW1lVGlja3MKICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBj b2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAg ICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgdXAgdGltZSBv ZiB0aGUgRUlEIHByZWZpeC4iCiAgICAgICA6Oj0geyBsaXNwTWFwQ2FjaGVFbnRyeSAzIH0K CiAgIGxpc3BNYXBDYWNoZUVpZEV4cGlyeVRpbWUgT0JKRUNULVRZUEUKICAgICAgIFNZTlRB WCAgICAgVGltZVRpY2tzCiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9 InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0i Z3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3Vy cmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIHRpbWUgcmVtYWluaW5n IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+b24gdGhlIEVJRCBwcmVmaXg8L2ZvbnQ+PC9z dHJpa2U+IGJlZm9yZSB0aGUgSVRSIHRpbWVzLW91dCA8c3RyaWtlPjxmb250IGNvbG9yPSJy ZWQiPnRoZTwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iPnRoaXMgRUlEPC9mb250Pjwvc3Ryb25nPiBwcmVmaXguIgogICAgICAgOjo9 IHsgbGlzcE1hcENhY2hlRW50cnkgNCB9CgogICBsaXNwTWFwQ2FjaGVFaWRTdGF0ZSBPQkpF Q1QtVFlQRQogICAgICAgU1lOVEFYICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPklO VEVHRVI8L2ZvbnQ+PC9zdHJpa2U+ICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ VHJ1dGhWYWx1ZTwvZm9udD48L3N0cm9uZz4KICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48 Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RB VFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGlzIG9i amVjdCBpcyB1c2VkIHRvIGluZGljYXRlIHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQi PmFjdGl2dHk8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5h Y3Rpdml0eTwvZm9udD48L3N0cm9uZz4KICAgICAgICAgICAgb2YgdGhpcyBFSUQgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5wcmVmaXguIEEgdmFsdWUgb2YgMCBpbXBsaWVzIHRoZTwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnByZWZpeCAoMCA9 PC9mb250Pjwvc3Ryb25nPiBFSUQgcHJlZml4IGlzIDxzdHJpa2U+PGZvbnQgY29sb3I9InJl ZCI+aWRsZS4gQSB2YWx1ZSBvZjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iPmlkbGU7PC9mb250Pjwvc3Ryb25nPgogICAgICAgICAgICAxIDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+aW1wbGllcyB0aGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9ImdyZWVuIj49PC9mb250Pjwvc3Ryb25nPiBFSUQgcHJlZml4IGlzIDxz dHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWN0aXZlLjwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0iZ3JlZW4iPmFjdGl2ZSkuIjwvZm9udD48L3N0cm9uZz4KICAgICAg IDo6PSB7IGxpc3BNYXBDYWNoZUVudHJ5IDUgfQoKICAgbGlzcE1hcENhY2hlRWlkQXV0aG9y aXRhdGl2ZSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBUcnV0aFZhbHVlCiAgICAg ICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9u dD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJ T04KICAgICAgICAgICAiVGhpcyBvYmplY3QgaXMgdXNlZCB0byBpbmRpY2F0ZSB3aGV0aGVy IHRoZQogICAgICAgICAgICBFSUQgcHJlZml4IHdhcyBpbnN0YWxsZWQgYnkgYW4gYXV0aG9y aXRhdGl2ZQogICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPm1hcC1yZXBs eS4gQSB2YWx1ZSBvZiAwIGltcGxpZXMgdGhlPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAg ICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+bWFwLXJlcGx5ICgwID0gRUlEIHByZWZp eCB3YXMgbm90IGluc3RhbGxlZCBieQogICAgICAgICAgICBhbiBhdXRob3JpdGF0aXZlIG1h cC1yZXBseTsgMSA9PC9mb250Pjwvc3Ryb25nPiBFSUQgcHJlZml4IHdhcwogICAgICAgICAg ICBpbnN0YWxsZWQgYnkgYW4gYXV0aG9yaXRhdGl2ZSA8c3RyaWtlPjxmb250IGNvbG9yPSJy ZWQiPm1hcC1yZXBseSwKICAgICAgICAgICAgYW5kIGEgdmFsdWUgb2YgMSwgb3RoZXJ3aXNl LiI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5tYXAtcmVw bHkpLiI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICA6Oj0geyBsaXNwTWFwQ2FjaGVFbnRyeSA2 IH0KCiAgIGxpc3BNYXBDYWNoZURlY2FwT2N0ZXRzIE9CSkVDVC1UWVBFCiAgICAgICBTWU5U QVggICAgIENvdW50ZXI2NAogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1 cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBudW1iZXIgb2Ygb2N0 ZXRzIG9mIExpc3AgcGFja2V0cyB0aGF0IHdlcmUKICAgICAgICAgICAgZGVjYXBzdWxhdGVk IGJ5IHRoaXMgZGV2aWNlIGFuZCB3ZXJlIHNvdXJjZWQKICAgICAgICAgICAgZnJvbSBhIHJl bW90ZSBob3N0IHdpdGhpbiB0aGlzIEVJRC1wcmVmaXguIgogICAgICAgOjo9IHsgbGlzcE1h cENhY2hlRW50cnkgNyB9CgogICBsaXNwTWFwQ2FjaGVEZWNhcFBhY2tldHMgT0JKRUNULVRZ UEUKICAgICAgIFNZTlRBWCAgICAgQ291bnRlcjY0CiAgICAgICBNQVgtQUNDRVNTIDxzdHJp a2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAg IFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhl IG51bWJlciBvZiBMaXNwIHBhY2tldHMgdGhhdCB3ZXJlCiAgICAgICAgICAgIGRlY2Fwc3Vs YXRlZCBieSB0aGlzIGRldmljZSBhbmQgd2VyZSBzb3VyY2VkCiAgICAgICAgICAgIGZyb20g YSByZW1vdGUgaG9zdCB3aXRoaW4gdGhpcyBFSUQtcHJlZml4LiIKCiAgICAgICA6Oj0geyBs aXNwTWFwQ2FjaGVFbnRyeSA4IH0KCiAgIGxpc3BNYXBDYWNoZUVuY2FwT2N0ZXRzIE9CSkVD VC1UWVBFCiAgICAgICBTWU5UQVggICAgIENvdW50ZXI2NAogICAgICAgTUFYLUFDQ0VTUyA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxz dHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAg ICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAg IlRoZSBudW1iZXIgb2Ygb2N0ZXRzIG9mIExpc3AgcGFja2V0cyB0aGF0IHdlcmUKICAgICAg ICAgICAgZW5jYXBzdWxhdGVkIGJ5IHRoaXMgZGV2aWNlIHVzaW5nIHRoZSBnaXZlbgogICAg ICAgICAgICBFSUQtcHJlZml4IGluIHRoZSBtYXAgY2FjaGUuIgogICAgICAgOjo9IHsgbGlz cE1hcENhY2hlRW50cnkgOSB9CgogICBsaXNwTWFwQ2FjaGVFbmNhcFBhY2tldHMgT0JKRUNU LVRZUEUKICAgICAgIFNZTlRBWCAgICAgQ291bnRlcjY0CiAgICAgICBNQVgtQUNDRVNTIDxz dHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAg ICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAi VGhlIG51bWJlciBvZiBMaXNwIHBhY2tldHMgdGhhdCB3ZXJlIGVuY2Fwc3VsYXRlZAogICAg ICAgICAgICBieSB0aGlzIGRldmljZSB1c2luZyB0aGUgZ2l2ZW4gRUlELXByZWZpeCBpbiB0 aGUKICAgICAgICAgICAgbWFwIGNhY2hlLiIKICAgICAgIDo6PSB7IGxpc3BNYXBDYWNoZUVu dHJ5IDEwIH0KCiAgIGxpc3BNYXBDYWNoZUxvY2F0b3JUYWJsZSBPQkpFQ1QtVFlQRQogICAg ICAgU1lOVEFYICAgICBTRVFVRU5DRSBPRiBsaXNwTWFwQ2FjaGVMb2NhdG9yRW50cnkKICAg ICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVu dAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhpcyB0YWJsZSByZXByZXNlbnRz IHRoZSBzZXQgb2YgbG9jYXRvcnMgcGVyIEVJRAogICAgICAgICAgICBwcmVmaXggY29udGFp bmVkIGluIHRoZSBtYXAtY2FjaGUgdGFibGUgb2YgYW4gSVRSLiIKICAgICAgIFJFRkVSRU5D RSAiW0xJU1BdIgogICAgICAgOjo9IHsgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5saXNw PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+bGlzcE1JQjwv Zm9udD48L3N0cm9uZz4gNSB9CgogICBsaXNwTWFwQ2FjaGVMb2NhdG9yRW50cnkgT0JKRUNU LVRZUEUKICAgICAgIFNZTlRBWCAgICAgbGlzcE1hcENhY2hlTG9jYXRvckVudHJ5CiAgICAg ICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQK ICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkFuIGVudHJ5IChjb25jZXB0dWFsIHJv dykgaW4gdGhlCiAgICAgICAgICAgIGxpc3BNYXBDYWNoZUxvY2F0b3JUYWJsZS4iCiAgICAg ICBJTkRFWCAgICAgIHsgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5saXNwTWFwQ2FjaGVM b2NhdG9yRWlkTGVuZ3RoCiAgICAgICAgICAgICAgICAgICAgbGlzcE1hcENhY2hlTG9jYXRv ckVpZAogICAgICAgICAgICAgICAgICAgICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY0xlbmd0 aDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmxpc3BNYXBD YWNoZUxvY2F0b3JFaWRMZW5ndGgsCiAgICAgICAgICAgICAgICAgICAgbGlzcE1hcENhY2hl TG9jYXRvckVpZCwKICAgICAgICAgICAgICAgICAgICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxv Y0xlbmd0aCw8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAgICAgICAgICAgICAgbGlzcE1hcENh Y2hlTG9jYXRvclJsb2MgfQogICAgICAgOjo9IHsgbGlzcE1hcENhY2hlTG9jYXRvclRhYmxl IDEgfQoKICAgbGlzcE1hcENhY2hlTG9jYXRvckVudHJ5IDo6PSBTRVFVRU5DRSB7CiAgICAg ICBsaXNwTWFwQ2FjaGVMb2NhdG9yRWlkTGVuZ3RoICAgICAgICAgICAgICAgPHN0cmlrZT48 Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSLDwvZm9udD48L3N0cmlrZT4gICAgICAgICAgICAg ICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMyLDwvZm9udD48L3N0cm9u Zz4KICAgICAgIGxpc3BNYXBDYWNoZUxvY2F0b3JFaWQgICAgICAgICAgICAgICAgICAgICBM aXNwQWRkcmVzc1R5cGUsCiAgICAgICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY0xlbmd0aCAg ICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSLDwvZm9udD48 L3N0cmlrZT4gICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRl Z2VyMzIsPC9mb250Pjwvc3Ryb25nPgogICAgICAgbGlzcE1hcENhY2hlTG9jYXRvclJsb2Mg ICAgICAgICAgICAgICAgICAgIExpc3BBZGRyZXNzVHlwZSwKICAgICAgIGxpc3BNYXBDYWNo ZUxvY2F0b3JSbG9jUHJpb3JpdHkgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJy ZWQiPklOVEVHRVIsPC9mb250Pjwvc3RyaWtlPiAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQg Y29sb3I9ImdyZWVuIj5JbnRlZ2VyMzIsPC9mb250Pjwvc3Ryb25nPgogICAgICAgbGlzcE1h cENhY2hlTG9jYXRvclJsb2NXZWlnaHQgICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29s b3I9InJlZCI+SU5URUdFUiw8L2ZvbnQ+PC9zdHJpa2U+ICAgICAgICAgICAgICA8c3Ryb25n Pjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMyLDwvZm9udD48L3N0cm9uZz4KICAgICAg IGxpc3BNYXBDYWNoZUxvY2F0b3JSbG9jTVByaW9yaXR5ICAgICAgICAgICA8c3RyaWtlPjxm b250IGNvbG9yPSJyZWQiPklOVEVHRVIsPC9mb250Pjwvc3RyaWtlPiAgICAgICAgICAgPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMiw8L2ZvbnQ+PC9zdHJvbmc+CiAg ICAgICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY01XZWlnaHQgICAgICAgICAgICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSLDwvZm9udD48L3N0cmlrZT4gICAgICAgICAg ICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMiw8L2ZvbnQ+PC9zdHJv bmc+CiAgICAgICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY1N0YXRlICAgICAgICAgICAgICAg SU5URUdFUiwKICAgICAgIGxpc3BNYXBDYWNoZUxvY2F0b3JSbG9jVXBUaW1lICAgICAgICAg ICAgICBUaW1lVGlja3MsCiAgICAgICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY0xhc3RQcmlv cml0eUNoYW5nZSAgVGltZVRpY2tzLAogICAgICAgbGlzcE1hcENhY2hlTG9jYXRvclJsb2NM YXN0V2VpZ2h0Q2hhbmdlICAgIFRpbWVUaWNrcywKICAgICAgIGxpc3BNYXBDYWNoZUxvY2F0 b3JSbG9jTGFzdE1Qcmlvcml0eUNoYW5nZSBUaW1lVGlja3MsCiAgICAgICBsaXNwTWFwQ2Fj aGVMb2NhdG9yUmxvY0xhc3RNV2VpZ2h0Q2hhbmdlICAgVGltZVRpY2tzLAogICAgICAgbGlz cE1hcENhY2hlTG9jYXRvclJsb2NMYXN0U3RhdGVDaGFuZ2UgICAgIFRpbWVUaWNrcywKICAg ICAgIGxpc3BNYXBDYWNoZUxvY2F0b3JSbG9jUnR0ICAgICAgICAgICAgICAgICBUaW1lVGlj a3MsCiAgICAgICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY0RlY2FwT2N0ZXRzICAgICAgICAg Q291bnRlcjY0LAogICAgICAgbGlzcE1hcENhY2hlTG9jYXRvclJsb2NEZWNhcFBhY2tldHMg ICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+Q291bnRlcjY0PC9mb250Pjwvc3Ry aWtlPiAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkNvdW50ZXI2NCw8L2Zv bnQ+PC9zdHJvbmc+CiAgICAgICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY0VuY2FwT2N0ZXRz ICAgICAgICAgQ291bnRlcjY0LAogICAgICAgbGlzcE1hcENhY2hlTG9jYXRvclJsb2NFbmNh cFBhY2tldHMgICAgICAgIENvdW50ZXI2NAogICB9CgogICBsaXNwTWFwQ2FjaGVMb2NhdG9y RWlkTGVuZ3RoIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIDxzdHJpa2U+PGZvbnQg Y29sb3I9InJlZCI+SU5URUdFUjwvZm9udD48L3N0cmlrZT4gICAgIDxzdHJvbmc+PGZvbnQg Y29sb3I9ImdyZWVuIj5JbnRlZ2VyMzI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBNQVgtQUND RVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERF U0NSSVBUSU9OCiAgICAgICAgICAgIlRoaXMgb2JqZWN0IGlzIHVzZWQgdG8gZ2V0IHRoZSA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxlbmd0aDwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0iZ3JlZW4iPm9jdGV0LWxlbmd0aDwvZm9udD48L3N0cm9uZz4gb2YK ICAgICAgICAgICAgbGlzcE1hcENhY2hlTG9jYXRvckVpZCwgdGhlIG5leHQgb2JqZWN0LiIK ICAgICAgIDo6PSB7IGxpc3BNYXBDYWNoZUxvY2F0b3JFbnRyeSAxIH0KCiAgIGxpc3BNYXBD YWNoZUxvY2F0b3JFaWQgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgTGlzcEFkZHJl c3NUeXBlCiAgICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMg ICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBFSUQgcHJl Zml4IG9mIG1hcHBpbmcgY2FjaGUgbWFwcGVkIHRvIHRoZSBsb2NhdG9yLiIKICAgICAgIDo6 PSB7IGxpc3BNYXBDYWNoZUxvY2F0b3JFbnRyeSAyIH0KCiAgIGxpc3BNYXBDYWNoZUxvY2F0 b3JSbG9jTGVuZ3RoIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIDxzdHJpa2U+PGZv bnQgY29sb3I9InJlZCI+SU5URUdFUjwvZm9udD48L3N0cmlrZT4gICAgIDxzdHJvbmc+PGZv bnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBNQVgt QUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAg IERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoaXMgb2JqZWN0IGlzIHVzZWQgdG8gZ2V0IHRo ZSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxlbmd0aDwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPm9jdGV0LWxlbmd0aDwvZm9udD48L3N0cm9uZz4g b2YKICAgICAgICAgICAgbGlzcE1hcENhY2hlTG9jYXRvclJsb2MsIHRoZSBuZXh0IG9iamVj dC4iCiAgICAgICA6Oj0geyBsaXNwTWFwQ2FjaGVMb2NhdG9yRW50cnkgMyB9CgogICBsaXNw TWFwQ2FjaGVMb2NhdG9yUmxvYyBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBMaXNw QWRkcmVzc1R5cGUKICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNU QVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIGxv Y2F0b3IgZm9yIHRoZSBFSUQgcHJlZml4IGluIHRoZSBtYXBwaW5nIGNhY2hlLiIKICAgICAg IDo6PSB7IGxpc3BNYXBDYWNoZUxvY2F0b3JFbnRyeSA0IH0KCiAgIGxpc3BNYXBDYWNoZUxv Y2F0b3JSbG9jUHJpb3JpdHkgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSPC9mb250Pjwvc3RyaWtlPiAgICAgPHN0cm9u Zz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMjwvZm9udD48L3N0cm9uZz4KICAgICAg IE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250 Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElP TgogICAgICAgICAgICJUaGUgdW5pY2FzdCBwcmlvcml0eSBvZiB0aGUgUkxPQyBmb3IgdGhp cyBFSUQgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5wcmVmaXguIjwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnByZWZpeAogICAgICAgICAgICAoMC0y NTUpIGxvd2VyIG1vcmUgcHJlZmVycmVkLiAiPC9mb250Pjwvc3Ryb25nPgogICAgICAgOjo9 IHsgbGlzcE1hcENhY2hlTG9jYXRvckVudHJ5IDUgfQoKICAgbGlzcE1hcENhY2hlTG9jYXRv clJsb2NXZWlnaHQgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgPHN0cmlrZT48Zm9u dCBjb2xvcj0icmVkIj5JTlRFR0VSPC9mb250Pjwvc3RyaWtlPiAgICAgPHN0cm9uZz48Zm9u dCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMjwvZm9udD48L3N0cm9uZz4KICAgICAgIE1BWC1B Q0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ry b25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAg ICAgICAgICJUaGUgdW5pY2FzdCB3ZWlnaHQgb2YgdGhlIFJMT0MgZm9yIHRoaXMgRUlEIDxz dHJpa2U+PGZvbnQgY29sb3I9InJlZCI+cHJlZml4LiI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj5wcmVmaXgKICAgICAgICAgICAgKDAgLSAxMDApIHBl cmNlbnRhZ2UuICI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICA6Oj0geyBsaXNwTWFwQ2FjaGVM b2NhdG9yRW50cnkgNiB9CgogICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY01Qcmlvcml0eSBP QkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQi PklOVEVHRVI8L2ZvbnQ+PC9zdHJpa2U+ICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVl biI+SW50ZWdlcjMyPC9mb250Pjwvc3Ryb25nPgogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtl Pjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBT VEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBt dWx0aWNhc3QgcHJpb3JpdHkgb2YgdGhlIFJMT0MgZm9yIHRoaXMgRUlEIHByZWZpeC4iCiAg ICAgICA6Oj0geyBsaXNwTWFwQ2FjaGVMb2NhdG9yRW50cnkgNyB9CgogICBsaXNwTWFwQ2Fj aGVMb2NhdG9yUmxvY01XZWlnaHQgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgPHN0 cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSPC9mb250Pjwvc3RyaWtlPiAgICAgPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMjwvZm9udD48L3N0cm9uZz4KICAg ICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9m b250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQ VElPTgogICAgICAgICAgICJUaGUgbXVsdGljYXN0IHdlaWdodCBvZiB0aGUgUkxPQyBmb3Ig dGhpcyBFSUQgcHJlZml4LiIKICAgICAgIDo6PSB7IGxpc3BNYXBDYWNoZUxvY2F0b3JFbnRy eSA4IH0KCiAgIGxpc3BNYXBDYWNoZUxvY2F0b3JSbG9jU3RhdGUgT0JKRUNULVRZUEUKICAg ICAgIFNZTlRBWCAgICAgSU5URUdFUiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ewog ICAgICAgICAgICAgICAgICAgICBkb3duICgwKSwKICAgICAgICAgICAgICAgICAgICAgdXAg KDEpCiAgICAgICAgICAgICAgICAgIH08L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBNQVgtQUND RVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9u Zz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiVGhlIHN0YXRlIG9mIHRoaXMgUkxPQyBhcyBwZXIgdGhpcyA8c3RyaWtlPjxmb250 IGNvbG9yPSJyZWQiPmRldmljZS4KICAgICAgICAgICAgMDwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRldmljZQogICAgICAgICAgICAoMCA9IFJMT0M8 L2ZvbnQ+PC9zdHJvbmc+IGlzIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+Zm9yIHVwLDwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRvd247PC9mb250 Pjwvc3Ryb25nPiAxIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj49IFJMT0M8L2ZvbnQ+ PC9zdHJvbmc+IGlzIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+Zm9yIGRvd24gLi4uIjwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnVwKS4iPC9mb250 Pjwvc3Ryb25nPgogICAgICAgOjo9IHsgbGlzcE1hcENhY2hlTG9jYXRvckVudHJ5IDkgfQoK ICAgbGlzcE1hcENhY2hlTG9jYXRvclJsb2NVcFRpbWUgT0JKRUNULVRZUEUKICAgICAgIFNZ TlRBWCAgICAgVGltZVRpY2tzCiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29s b3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAg Y3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAgICAgIlRoZSB1cC10aW1l IG9mIHRoaXMgUkxPQy4iCiAgICAgICA6Oj0geyBsaXNwTWFwQ2FjaGVMb2NhdG9yRW50cnkg MTAgfQoKICAgbGlzcE1hcENhY2hlTG9jYXRvclJsb2NMYXN0UHJpb3JpdHlDaGFuZ2UgT0JK RUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgVGltZVRpY2tzCiAgICAgICBNQVgtQUNDRVNT IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4K ICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAg ICAiVGltZSBzaW5jZSB0aGUgbGFzdCBjaGFuZ2Ugb2YgdGhlIHVuaWNhc3QgcHJpb3JpdHkK ICAgICAgICAgICAgb2YgdGhlIFJMT0MgZm9yIHRoaXMgRUlEIHByZWZpeC4iCiAgICAgICA6 Oj0geyBsaXNwTWFwQ2FjaGVMb2NhdG9yRW50cnkgMTEgfQoKICAgbGlzcE1hcENhY2hlTG9j YXRvclJsb2NMYXN0V2VpZ2h0Q2hhbmdlIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAg IFRpbWVUaWNrcwogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQi PmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVu Ij5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQK ICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRpbWUgc2luY2UgdGhlIGxhc3QgY2hh bmdlIG9mIHRoZSB1bmljYXN0IHdlaWdodCBvZgogICAgICAgICAgICB0aGUgUkxPQyBmb3Ig dGhpcyBFSUQgcHJlZml4LiIKICAgICAgIDo6PSB7IGxpc3BNYXBDYWNoZUxvY2F0b3JFbnRy eSAxMiB9CgogICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY0xhc3RNUHJpb3JpdHlDaGFuZ2Ug T0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgVGltZVRpY2tzCiAgICAgICBNQVgtQUND RVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9u Zz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiVGltZSBzaW5jZSB0aGUgbGFzdCBjaGFuZ2Ugb2YgdGhlIG11bHRpY2FzdCBwcmlv cml0eQogICAgICAgICAgICBvZiB0aGUgUkxPQyBmb3IgdGhpcyBFSUQgcHJlZml4LiIKICAg ICAgIDo6PSB7IGxpc3BNYXBDYWNoZUxvY2F0b3JFbnRyeSAxMyB9CgogICBsaXNwTWFwQ2Fj aGVMb2NhdG9yUmxvY0xhc3RNV2VpZ2h0Q2hhbmdlIE9CSkVDVC1UWVBFCiAgICAgICBTWU5U QVggICAgIFRpbWVUaWNrcwogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1 cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRpbWUgc2luY2UgdGhlIGxh c3QgY2hhbmdlIG9mIHRoZSBtdWx0aWNhc3Qgd2VpZ2h0CiAgICAgICAgICAgIG9mIHRoZSBS TE9DIGZvciB0aGlzIEVJRCBwcmVmaXguIgogICAgICAgOjo9IHsgbGlzcE1hcENhY2hlTG9j YXRvckVudHJ5IDE0IH0KCiAgIGxpc3BNYXBDYWNoZUxvY2F0b3JSbG9jTGFzdFN0YXRlQ2hh bmdlIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIFRpbWVUaWNrcwogICAgICAgTUFY LUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9z dHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9z dHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAg ICAgICAgICAgIlRpbWUgc2luY2UgdGhlIGxhc3QgY2hhbmdlIG9mIHRoZSB1cC9kb3duIHN0 YXRlIG9mCiAgICAgICAgICAgIHRoZSBSTE9DIGZvciB0aGlzIEVJRCBwcmVmaXguIgogICAg ICAgOjo9IHsgbGlzcE1hcENhY2hlTG9jYXRvckVudHJ5IDE1IH0KCiAgIGxpc3BNYXBDYWNo ZUxvY2F0b3JSbG9jUnR0IE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIFRpbWVUaWNr cwogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2li bGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9u bHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERF U0NSSVBUSU9OCiAgICAgICAgICAgIlJvdW5kIHRyaXAgdGltZSBvZiBSTE9DIHByb2JlIGFu ZCBtYXAtcmVwbHkgZm9yCiAgICAgICAgICAgIHRoaXMgUkxPQyBhZGRyZXNzIGZvciB0aGlz IHByZWZpeC4iCiAgICAgICA6Oj0geyBsaXNwTWFwQ2FjaGVMb2NhdG9yRW50cnkgMTYgfQoK ICAgbGlzcE1hcENhY2hlTG9jYXRvclJsb2NEZWNhcE9jdGV0cyBPQkpFQ1QtVFlQRQogICAg ICAgU1lOVEFYICAgICBDb3VudGVyNjQKICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9u dCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVT ICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgbnVtYmVy IG9mIG9jdGV0cyBvZiBMaXNwIHBhY2tldHMgdGhhdCB3ZXJlCiAgICAgICAgICAgIGRlY2Fw c3VsYXRlZCBieSB0aGlzIGRldmljZSBhbmQgd2VyZSBzb3VyY2VkCiAgICAgICAgICAgIGZy b20gYSByZW1vdGUgaG9zdCB3aXRoaW4gdGhpcyBFSUQtcHJlZml4IGFuZAogICAgICAgICAg ICB3ZXJlIGVuY2Fwc3VsYXRlZCBmb3IgdGhpcyBSTE9DLiIKICAgICAgIDo6PSB7IGxpc3BN YXBDYWNoZUxvY2F0b3JFbnRyeSAxNyB9CgogICBsaXNwTWFwQ2FjaGVMb2NhdG9yUmxvY0Rl Y2FwUGFja2V0cyBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBDb3VudGVyNjQKICAg ICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9m b250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQ VElPTgogICAgICAgICAgICJUaGUgbnVtYmVyIG9mIDxzdHJpa2U+PGZvbnQgY29sb3I9InJl ZCI+b2N0ZXRzIG9mPC9mb250Pjwvc3RyaWtlPiBMaXNwIHBhY2tldHMgdGhhdCB3ZXJlIGRl Y2Fwc3VsYXRlZAogICAgICAgICAgICBieSB0aGlzIGRldmljZSBhbmQgd2VyZSBzb3VyY2Vk IGZyb20gYSByZW1vdGUgaG9zdAogICAgICAgICAgICB3aXRoaW4gdGhpcyBFSUQtcHJlZml4 IGFuZCB3ZXJlIGVuY2Fwc3VsYXRlZCBmb3IKICAgICAgICAgICAgdGhpcyBSTE9DLiIKICAg ICAgIDo6PSB7IGxpc3BNYXBDYWNoZUxvY2F0b3JFbnRyeSAxOCB9CgogICBsaXNwTWFwQ2Fj aGVMb2NhdG9yUmxvY0VuY2FwT2N0ZXRzIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAg IENvdW50ZXI2NAogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQi PmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVu Ij5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQK ICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBudW1iZXIgb2Ygb2N0ZXRzIG9m IExpc3AgcGFja2V0cyB0aGF0IG1hdGNoZWQKICAgICAgICAgICAgdGhpcyBFSUQtcHJlZml4 IGFuZCB3ZXJlIGVuY2Fwc3VsYXRlZCB1c2luZyB0aGlzCiAgICAgICAgICAgIFJMT0MgYWRk cmVzcy4iCgogICAgICAgOjo9IHsgbGlzcE1hcENhY2hlTG9jYXRvckVudHJ5IDE5IH0KCiAg IGxpc3BNYXBDYWNoZUxvY2F0b3JSbG9jRW5jYXBQYWNrZXRzIE9CSkVDVC1UWVBFCiAgICAg ICBTWU5UQVggICAgIENvdW50ZXI2NAogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250 IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMg ICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSBudW1iZXIg b2YgTGlzcCBwYWNrZXRzIHRoYXQgbWF0Y2hlZCB0aGlzCiAgICAgICAgICAgIDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+RUlELXByZWZpeDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj0iZ3JlZW4iPkVJRAogICAgICAgICAgICBwcmVmaXg8L2ZvbnQ+PC9zdHJv bmc+IGFuZCB3ZXJlIGVuY2Fwc3VsYXRlZCB1c2luZyB0aGlzIFJMT0MgYWRkcmVzcy4iCiAg ICAgICA6Oj0geyBsaXNwTWFwQ2FjaGVMb2NhdG9yRW50cnkgMjAgfQoKICAgbGlzcFNpdGVU YWJsZSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBTRVFVRU5DRSBPRiBsaXNwU2l0 ZUVudHJ5CiAgICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMg ICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoaXMgdGFibGUg cHJvdmlkZXMgdGhlIHByb3BlcnRpZXMgb2YgZWFjaCBsaXNwIHNpdGUKICAgICAgICAgICAg dGhhdCBpcyBzZXJ2ZWQgYnkgdGhpcyBkZXZpY2Ugd2hlbiBjb25maWd1cmVkIHRvIGJlCiAg ICAgICAgICAgIGEgTWFwLVNlcnZlci4iCiAgICAgICBSRUZFUkVOQ0UgIltMSVNQXSIKICAg ICAgIDo6PSB7IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+bGlzcDwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmxpc3BNSUI8L2ZvbnQ+PC9zdHJvbmc+ IDYgfQoKICAgbGlzcFNpdGVFbnRyeSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBs aXNwU2l0ZUVudHJ5CiAgICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBT VEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkFuIGVu dHJ5IChjb25jZXB0dWFsIHJvdykgaW4gdGhlIGxpc3BTaXRlVGFibGUuIgogICAgICAgSU5E RVggICAgICB7IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+bGlzcFNpdGVOYW1lCiAgICAg ICAgICAgICAgICAgICAgbGlzcFNpdGVFaWRMZW5ndGg8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj5saXNwU2l0ZU5hbWUsCiAgICAgICAgICAgICAgICAg ICAgbGlzcFNpdGVFaWRMZW5ndGgsPC9mb250Pjwvc3Ryb25nPgogICAgICAgICAgICAgICAg ICAgIGxpc3BTaXRlRWlkIH0KICAgICAgIDo6PSB7IGxpc3BTaXRlVGFibGUgMSB9CgogICBs aXNwU2l0ZUVudHJ5IDo6PSBTRVFVRU5DRSB7CiAgICAgICBsaXNwU2l0ZU5hbWUgICAgICAg ICAgICAgICAgICAgICBPQ1RFVCBTVFJJTkcsCiAgICAgICBsaXNwU2l0ZUVpZExlbmd0aCAg ICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPklOVEVHRVIsPC9mb250 Pjwvc3RyaWtlPiAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ SW50ZWdlcjMyLDwvZm9udD48L3N0cm9uZz4KICAgICAgIGxpc3BTaXRlRWlkICAgICAgICAg ICAgICAgICAgICAgIExpc3BBZGRyZXNzVHlwZSwKICAgICAgIDxzdHJvbmc+PGZvbnQgY29s b3I9ImdyZWVuIj5saXNwU2l0ZURlc2NyaXB0aW9uICAgICAgICAgICAgICBPQ1RFVCBTVFJJ TkcsPC9mb250Pjwvc3Ryb25nPgogICAgICAgbGlzcFNpdGVFaWRSZWdpc3RlclN0YXRlICAg ICAgICAgVHJ1dGhWYWx1ZSwKICAgICAgIGxpc3BTaXRlRWlkRmlyc3RSZWdpc3RlclRpbWUg ICAgIFRpbWVUaWNrcywKICAgICAgIGxpc3BTaXRlRWlkUmVnaXN0ZXJTZW5kZXJMZW5ndGgg IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+SU5URUdFUiw8L2ZvbnQ+PC9zdHJpa2U+ICA8 c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMyLDwvZm9udD48L3N0cm9uZz4K ICAgICAgIGxpc3BTaXRlRWlkUmVnaXN0ZXJTZW5kZXIgICAgICAgIExpc3BBZGRyZXNzVHlw ZSwKICAgICAgIGxpc3BTaXRlRWlkUm91dGVUYWcgICAgICAgICAgICAgIFVuc2lnbmVkMzIs CiAgICAgICBsaXNwU2l0ZUVpZEF1dGhlbnRpY2F0aW9uRXJyb3JzICBDb3VudGVyNjQsCiAg ICAgICBsaXNwU2l0ZUVpZFJlZ2lzdGVyUmxvY3NNaXNtYXRjaCA8c3RyaWtlPjxmb250IGNv bG9yPSJyZWQiPkNvdW50ZXI2NDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iPkNvdW50ZXI2NCwKICAgICAgIGxpc3BTaXRlRWlkV2FudHNNYXBOb3RpZmll cyAgICAgIFRydXRoVmFsdWU8L2ZvbnQ+PC9zdHJvbmc+CiAgIH0KICAgbGlzcFNpdGVOYW1l IE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIE9DVEVUIFNUUklORyAoU0laRSgwLi42 MykpCiAgICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAg IGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlNpdGUgbmFtZSB1c2Vk IGJ5IGEgTWFwLVNlcnZlciB0byBkaXN0aW5ndWlzaAogICAgICAgICAgICBkaWZmZXJlbnQg bGlzcCBzaXRlcyB0aGF0IGFyZSByZWdpc3RlcmluZyB3aXRoIGl0LiIKICAgICAgIDo6PSB7 IGxpc3BTaXRlRW50cnkgMSB9CgogICBsaXNwU2l0ZUVpZExlbmd0aCBPQkpFQ1QtVFlQRQog ICAgICAgU1lOVEFYICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPklOVEVHRVI8L2Zv bnQ+PC9zdHJpa2U+ICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMy PC9mb250Pjwvc3Ryb25nPgogICAgICAgTUFYLUFDQ0VTUyBub3QtYWNjZXNzaWJsZQogICAg ICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJU aGlzIG9iamVjdCBpcyB1c2VkIHRvIGdldCB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVk Ij5sZW5ndGg8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5v Y3RldC1sZW5ndGg8L2ZvbnQ+PC9zdHJvbmc+IG9mCiAgICAgICAgICAgIGxpc3BTaXRlRWlk LCB0aGUgbmV4dCBvYmplY3QuIgogICAgICAgOjo9IHsgbGlzcFNpdGVFbnRyeSAyIH0KCiAg IGxpc3BTaXRlRWlkIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIExpc3BBZGRyZXNz VHlwZQogICAgICAgTUFYLUFDQ0VTUyBub3QtYWNjZXNzaWJsZQogICAgICAgU1RBVFVTICAg ICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgRUlEIHByZWZp eCBiZWxvbmdpbmcgdG8gdGhpcyBzaXRlLiIKICAgICAgICA6Oj0geyBsaXNwU2l0ZUVudHJ5 IDMgfQoKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmxpc3BTaXRlRGVzY3JpcHRp b24gT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgT0NURVQgU1RSSU5HIChTSVpFKDAu LjI1NSkpCiAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQogICAgICAgU1RBVFVTICAgICBj dXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJEZXNjcmlwdGlvbiBmb3Ig YSBzaXRlIG5hbWUgdXNlZCBieSBhIE1hcC1TZXJ2ZXIuIgogICAgICAgOjo9IHsgbGlzcFNp dGVFbnRyeSA0IH08L2ZvbnQ+PC9zdHJvbmc+CgogICBsaXNwU2l0ZUVpZFJlZ2lzdGVyU3Rh dGUgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgVHJ1dGhWYWx1ZQogICAgICAgTUFY LUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9z dHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9z dHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAg ICAgICAgICAgIkluZGljYXRlcyB0aGUgcmVnaXN0cmF0aW9uIHN0YXR1cyBvZiB0aGUKICAg ICAgICAgICAgZ2l2ZW4gRUlEIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+cHJlZml4LiBW YWx1ZSAxIGltcGxpZXMgcmVnaXN0ZXJlZCwgdmFsdWUgMAogICAgICAgICAgICBpbXBsaWVz PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cHJlZml4ICgw ID0gRUlEIHByZWZpeCBpczwvZm9udD48L3N0cm9uZz4gbm90IDxzdHJpa2U+PGZvbnQgY29s b3I9InJlZCI+cmVnaXN0ZXJlZC4iPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICA8c3Ry b25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVnaXN0ZXJlZDsgMSA9IEVJRCBwcmVmaXggaXMg cmVnaXN0ZXJlZCkuIjwvZm9udD48L3N0cm9uZz4KICAgICAgIDo6PSB7IDxzdHJpa2U+PGZv bnQgY29sb3I9InJlZCI+bGlzcEVudHJ5IDQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZv bnQgY29sb3I9ImdyZWVuIj5saXNwU2l0ZUVudHJ5IDU8L2ZvbnQ+PC9zdHJvbmc+IH0KCiAg IGxpc3BTaXRlRWlkRmlyc3RSZWdpc3RlclRpbWUgT0JKRUNULVRZUEUKICAgICAgIFNZTlRB WCAgICAgVGltZVRpY2tzCiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9 InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0i Z3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3Vy cmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGltZSBzaW5jZSBhIGZpcnN0 IHZhbGlkIHJlZ2lzdGVyIG1lc3NhZ2UgZm9yCiAgICAgICAgICAgIHRoZSBnaXZlbiBFSUQg cHJlZml4IHdhcyByZWNlaXZlZCBieSB0aGlzIGRldmljZS4iCiAgICAgICA6Oj0geyBsaXNw U2l0ZUVudHJ5IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+NTwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjY8L2ZvbnQ+PC9zdHJvbmc+IH0KCiAgIGxp c3BTaXRlRWlkUmVnaXN0ZXJTZW5kZXJMZW5ndGggT0JKRUNULVRZUEUKICAgICAgIFNZTlRB WCAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSPC9mb250Pjwvc3RyaWtl PiAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMjwvZm9udD48L3N0 cm9uZz4KICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nl c3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVh ZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAg ICBERVNDUklQVElPTgogICAgICAgICAgICJUaGlzIG9iamVjdCBpcyB1c2VkIHRvIGdldCB0 aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5sZW5ndGg8L2ZvbnQ+PC9zdHJpa2U+IDxz dHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5vY3RldC1sZW5ndGg8L2ZvbnQ+PC9zdHJvbmc+ IG9mCiAgICAgICAgICAgIGxpc3BTaXRlRWlkUmVnaXN0ZXJTZW5kZXIsIHRoZSBuZXh0IG9i amVjdC4iCiAgICAgICA6Oj0geyBsaXNwU2l0ZUVudHJ5IDxzdHJpa2U+PGZvbnQgY29sb3I9 InJlZCI+NjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjc8 L2ZvbnQ+PC9zdHJvbmc+IH0KCiAgIGxpc3BTaXRlRWlkUmVnaXN0ZXJTZW5kZXIgT0JKRUNU LVRZUEUKICAgICAgIFNZTlRBWCAgICAgTGlzcEFkZHJlc3NUeXBlCiAgICAgICBNQVgtQUND RVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9u Zz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiU291cmNlIGFkZHJlc3Mgb2YgdGhlIGxhc3QgdmFsaWQgcmVnaXN0ZXIgbWVzc2Fn ZQogICAgICAgICAgICBmb3IgdGhlIGdpdmVuIEVJRCBwcmVmaXggdGhhdCB3YXMgcmVjZWl2 ZWQgYnkKICAgICAgICAgICAgdGhpcyBkZXZpY2UuIgogICAgICAgOjo9IHsgbGlzcFNpdGVF bnRyeSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjc8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj44PC9mb250Pjwvc3Ryb25nPiB9CgogICBsaXNwU2l0 ZUVpZFJvdXRlVGFnIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIFVuc2lnbmVkMzIK ICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxl PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5 PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVND UklQVElPTgogICAgICAgICAgICJWYWx1ZSBvZiB0aGUgcm91dGluZyB0YWJsZSB0YWcgdGhh dCBjb250YWlucyB0aGUKICAgICAgICAgICAgZ2l2ZW4gRUlEIHByZWZpeC4iCiAgICAgICA6 Oj0geyBsaXNwU2l0ZUVudHJ5IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+ODwvZm9udD48 L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjk8L2ZvbnQ+PC9zdHJvbmc+ IH0KCiAgIGxpc3BTaXRlRWlkQXV0aGVudGljYXRpb25FcnJvcnMgT0JKRUNULVRZUEUKICAg ICAgIFNZTlRBWCAgICAgQ291bnRlcjY0CiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZv bnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9u dCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRV UyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiQ291bnQgb2Yg dG90YWwgYXV0aGVudGljYXRpb24gZXJyb3JzIG9mCiAgICAgICAgICAgIG1hcC1yZWdpc3Rl cnMgcmVjZWl2ZWQgZm9yIHRoZSBnaXZlbiBFSUQKICAgICAgICAgICAgcHJlZml4LiIKICAg ICAgIDo6PSB7IGxpc3BTaXRlRW50cnkgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj45PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+MTA8L2ZvbnQ+PC9z dHJvbmc+IH0KCiAgIGxpc3BTaXRlRWlkUmVnaXN0ZXJSbG9jc01pc21hdGNoIE9CSkVDVC1U WVBFCiAgICAgICBTWU5UQVggICAgIENvdW50ZXI2NAogICAgICAgTUFYLUFDQ0VTUyA8c3Ry aWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAg ICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkNv dW50IG9mIHRvdGFsIG1hcC1yZWdpc3RlcnMgcmVjZWl2ZWQgdGhhdCBoYWQgYXQKICAgICAg ICAgICAgbGVhc3Qgb25lIFJMT0MgdGhhdCB3YXMgbm90IGluIHRoZSBhbGxvd2VkIGxpc3Qg b2YKICAgICAgICAgICAgUkxPQ3MgZm9yIHRoZSBnaXZlbiBFSUQgcHJlZml4LiIKICAgICAg IDo6PSB7IGxpc3BTaXRlRW50cnkgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4xMDwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjExIH0KCiAgIGxpc3BT aXRlRWlkV2FudHNNYXBOb3RpZmllcyBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBU cnV0aFZhbHVlCiAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQogICAgICAgU1RBVFVTICAg ICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJJbmRpY2F0ZXMgd2hl dGhlciB0aGUgRUlEIHByZWZpeCB3YW50cwogICAgICAgICAgICBNYXAtTm90aWZpY2F0aW9u cyAoMCA9IEVJRCBwcmVmaXggZG9lcyBub3Qgd2FudAogICAgICAgICAgICBNYXAtTm90aWZp Y2F0aW9uczsgMSA9IEVJRCBwcmVmaXggd2FudHMKICAgICAgICAgICAgTWFwLU5vdGlmaWNh dGlvbnMpLiIKICAgICAgIDo6PSB7IGxpc3BTaXRlRW50cnkgMTI8L2ZvbnQ+PC9zdHJvbmc+ IH0KCiAgIGxpc3BTaXRlTG9jYXRvclRhYmxlIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVgg ICAgIFNFUVVFTkNFIE9GIGxpc3BTaXRlTG9jYXRvckVudHJ5CiAgICAgICBNQVgtQUNDRVNT IG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NS SVBUSU9OCiAgICAgICAgICAgIlRoaXMgdGFibGUgcHJvdmlkZXMgdGhlIHByb3BlcnRpZXMg b2YgYWxsIGxvY2F0b3JzCiAgICAgICAgICAgIHBlciBsaXNwIHNpdGUgdGhhdCA8c3RyaWtl Pjxmb250IGNvbG9yPSJyZWQiPmlzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSJncmVlbiI+YXJlPC9mb250Pjwvc3Ryb25nPiBzZXJ2ZWQgYnkgdGhpcyBkZXZpY2Ug d2hlbgogICAgICAgICAgICBjb25maWd1cmVkIHRvIGJlIGEgTWFwLVNlcnZlci4iCiAgICAg ICBSRUZFUkVOQ0UgIltMSVNQXSIKICAgICAgIDo6PSB7IDxzdHJpa2U+PGZvbnQgY29sb3I9 InJlZCI+bGlzcDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4i Pmxpc3BNSUI8L2ZvbnQ+PC9zdHJvbmc+IDcgfQoKICAgbGlzcFNpdGVMb2NhdG9yRW50cnkg T0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgbGlzcFNpdGVMb2NhdG9yRW50cnkKICAg ICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVu dAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiQW4gZW50cnkgKGNvbmNlcHR1YWwg cm93KSBpbiB0aGUgbGlzcFNpdGVMb2NhdG9yVGFibGUuIgogICAgICAgSU5ERVggICAgICB7 IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+bGlzcFNpdGVMb2NhdG9yTmFtZQogICAgICAg ICAgICAgICAgICAgIGxpc3BTaXRlTG9jYXRvckVpZAogICAgICAgICAgICAgICAgICAgIGxp c3BTaXRlTG9jYXRvckVpZE1hc2tMZW5ndGgKICAgICAgICAgICAgICAgICAgICBsaXNwU2l0 ZUxvY2F0b3JSbG9jTGVuZ3RoPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+bGlzcFNpdGVMb2NhdG9yTmFtZSwKICAgICAgICAgICAgICAgICAgICBsaXNw U2l0ZUxvY2F0b3JFaWRMZW5ndGgsCiAgICAgICAgICAgICAgICAgICAgbGlzcFNpdGVMb2Nh dG9yRWlkLAogICAgICAgICAgICAgICAgICAgIGxpc3BTaXRlTG9jYXRvclJsb2NMZW5ndGgs PC9mb250Pjwvc3Ryb25nPgogICAgICAgICAgICAgICAgICAgIGxpc3BTaXRlTG9jYXRvclJs b2MKICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxpc3BT aXRlTG9jYXRvclJsb2NTdGF0ZTwvZm9udD48L3N0cmlrZT4gfQogICAgICAgOjo9IHsgbGlz cFNpdGVMb2NhdG9yVGFibGUgMSB9CgogICBsaXNwU2l0ZUxvY2F0b3JFbnRyeSA6Oj0gU0VR VUVOQ0UgewogICAgICAgbGlzcFNpdGVMb2NhdG9yTmFtZSAgICAgICAgICAgICAgICAgICAg IE9DVEVUIFNUUklORywKICAgICAgIGxpc3BTaXRlTG9jYXRvckVpZExlbmd0aCAgICAgICAg ICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPklOVEVHRVIsPC9mb250Pjwvc3Ry aWtlPiAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdl cjMyLDwvZm9udD48L3N0cm9uZz4KICAgICAgIGxpc3BTaXRlTG9jYXRvckVpZCAgICAgICAg ICAgICAgICAgICAgICBMaXNwQWRkcmVzc1R5cGUsCiAgICAgICBsaXNwU2l0ZUxvY2F0b3JS bG9jTGVuZ3RoICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRF R0VSLDwvZm9udD48L3N0cmlrZT4gICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+SW50ZWdlcjMyLDwvZm9udD48L3N0cm9uZz4KICAgICAgIGxpc3BTaXRlTG9j YXRvclJsb2MgICAgICAgICAgICAgICAgICAgICBMaXNwQWRkcmVzc1R5cGUsCiAgICAgICBs aXNwU2l0ZUxvY2F0b3JSbG9jU3RhdGUgICAgICAgICAgICAgICAgSU5URUdFUiwKICAgICAg IGxpc3BTaXRlTG9jYXRvclJsb2NQcmlvcml0eSAgICAgICAgICAgICA8c3RyaWtlPjxmb250 IGNvbG9yPSJyZWQiPklOVEVHRVIsPC9mb250Pjwvc3RyaWtlPiAgICAgICAgICAgICA8c3Ry b25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMyLDwvZm9udD48L3N0cm9uZz4KICAg ICAgIGxpc3BTaXRlTG9jYXRvclJsb2NXZWlnaHQgICAgICAgICAgICAgICA8c3RyaWtlPjxm b250IGNvbG9yPSJyZWQiPklOVEVHRVIsPC9mb250Pjwvc3RyaWtlPiAgICAgICAgICAgICAg IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzIsPC9mb250Pjwvc3Ryb25n PgogICAgICAgbGlzcFNpdGVMb2NhdG9yUmxvY01Qcmlvcml0eSAgICAgICAgICAgIDxzdHJp a2U+PGZvbnQgY29sb3I9InJlZCI+SU5URUdFUiw8L2ZvbnQ+PC9zdHJpa2U+ICAgICAgICAg ICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMiw8L2ZvbnQ+PC9zdHJv bmc+CiAgICAgICBsaXNwU2l0ZUxvY2F0b3JSbG9jTVdlaWdodCAgICAgICAgICAgICAgPHN0 cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSLDwvZm9udD48L3N0cmlrZT4gICAgICAg ICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzIsPC9mb250Pjwv c3Ryb25nPgogICAgICAgbGlzcFNpdGVMb2NhdG9yUmxvY1JlZ2lzdGVyU3RhdGUgICAgICAg IFRydXRoVmFsdWUsCiAgICAgICBsaXNwU2l0ZUxvY2F0b3JSbG9jRmlyc3RSZWdpc3RlclRp bWUgICAgVGltZVRpY2tzLAogICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5saXNw U2l0ZUxvY2F0b3JSbG9jUmVnaXN0ZXJUaW1lTGFzdDwvZm9udD48L3N0cmlrZT4KICAgICAg IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5saXNwU2l0ZUxvY2F0b3JSbG9jTGFzdFJl Z2lzdGVyVGltZTwvZm9udD48L3N0cm9uZz4gICAgIFRpbWVUaWNrcywKICAgICAgIGxpc3BT aXRlTG9jYXRvclJsb2NSZWdpc3RlclNlbmRlckxlbmd0aCA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPklOVEVHRVIsPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJn cmVlbiI+SW50ZWdlcjMyLDwvZm9udD48L3N0cm9uZz4KICAgICAgIGxpc3BTaXRlTG9jYXRv clJsb2NSZWdpc3RlclNlbmRlciAgICAgICBMaXNwQWRkcmVzc1R5cGUsCiAgICAgICBsaXNw U2l0ZUxvY2F0b3JSbG9jUHJveHlSZXBseSAgICAgICAgICAgVHJ1dGhWYWx1ZQogICB9Cgog ICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxpc3BTaXRlTG9jYXRvcklkZW50aWZpZXI8 L2ZvbnQ+PC9zdHJpa2U+CgogICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+bGlzcFNp dGVMb2NhdG9yTmFtZTwvZm9udD48L3N0cm9uZz4gT0JKRUNULVRZUEUKICAgICAgIFNZTlRB WCAgICAgT0NURVQgU1RSSU5HIChTSVpFKDAuLjYzKSkKICAgICAgIE1BWC1BQ0NFU1Mgbm90 LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJ T04KICAgICAgICAgICAiU2l0ZSBuYW1lIHVzZWQgYnkgYSBNYXAtU2VydmVyIHRvIGRpc3Rp bmd1aXNoCiAgICAgICAgICAgIGRpZmZlcmVudCBsaXNwIHNpdGVzIHRoYXQgYXJlIHJlZ2lz dGVyaW5nIHdpdGggaXQuIgogICAgICAgOjo9IHsgbGlzcFNpdGVMb2NhdG9yRW50cnkgMSB9 CgogICBsaXNwU2l0ZUxvY2F0b3JFaWRMZW5ndGggT0JKRUNULVRZUEUKICAgICAgIFNZTlRB WCAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSPC9mb250Pjwvc3RyaWtl PiAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMjwvZm9udD48L3N0 cm9uZz4KICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAg ICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhpcyBvYmplY3Qg aXMgdXNlZCB0byBnZXQgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+bGVuZ3RoPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+b2N0ZXQtbGVuZ3Ro PC9mb250Pjwvc3Ryb25nPiBvZgogICAgICAgICAgICBsaXNwU2l0ZUxvY2F0b3JFaWQsIHRo ZSBuZXh0IG9iamVjdC4iCiAgICAgICA6Oj0geyBsaXNwU2l0ZUxvY2F0b3JFbnRyeSAyIH0K CiAgIGxpc3BTaXRlTG9jYXRvckVpZCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBM aXNwQWRkcmVzc1R5cGUKICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAg IFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhl IEVJRCBwcmVmaXggYmVsb25naW5nIHRvIHRoaXMgc2l0ZS4iCiAgICAgICA6Oj0geyBsaXNw U2l0ZUxvY2F0b3JFbnRyeSAzIH0KCiAgIGxpc3BTaXRlTG9jYXRvclJsb2NMZW5ndGggT0JK RUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5J TlRFR0VSPC9mb250Pjwvc3RyaWtlPiAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4i PkludGVnZXIzMjwvZm9udD48L3N0cm9uZz4KICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vz c2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAg ICAgICAgICAiVGhpcyBvYmplY3QgaXMgdXNlZCB0byBnZXQgdGhlIDxzdHJpa2U+PGZvbnQg Y29sb3I9InJlZCI+bGVuZ3RoPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+b2N0ZXQtbGVuZ3RoPC9mb250Pjwvc3Ryb25nPiBvZgogICAgICAgICAgICBs aXNwU2l0ZUxvY2F0b3JSbG9jLCB0aGUgbmV4dCBvYmplY3QuIgogICAgICAgOjo9IHsgbGlz cFNpdGVMb2NhdG9yRW50cnkgNCB9CgogICBsaXNwU2l0ZUxvY2F0b3JSbG9jIE9CSkVDVC1U WVBFCiAgICAgICBTWU5UQVggICAgIExpc3BBZGRyZXNzVHlwZQogICAgICAgTUFYLUFDQ0VT UyBub3QtYWNjZXNzaWJsZQogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVND UklQVElPTgogICAgICAgICAgICJUaGUgbG9jYXRvciBvZiB0aGUgZ2l2ZW4gRUlEIHByZWZp eCBiZWxvbmdpbmcKICAgICAgICAgICAgdG8gdGhpcyBzaXRlLiIKICAgICAgIDo6PSB7IGxp c3BTaXRlTG9jYXRvckVudHJ5IDUgfQoKICAgbGlzcFNpdGVMb2NhdG9yUmxvY1N0YXRlIE9C SkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIElOVEVHRVIgPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iPnsKICAgICAgICAgICAgICAgICAgICAgZG93biAoMCksCiAgICAgICAgICAg ICAgICAgICAgIHVwICgxKQogICAgICAgICAgICAgICAgICB9PC9mb250Pjwvc3Ryb25nPgog ICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8 L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8 L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NS SVBUSU9OCiAgICAgICAgICAgIlRoZSBjYWNoZWQgc3RhdGUgb2YgdGhpcyBSTE9DIHJlY2Vp dmVkIGluCiAgICAgICAgICAgIG1hcC1yZWdpc3RlciBieSB0aGUgZGV2aWNlLCBpbiB0aGUg Y2FwYWNpdHkgb2YKICAgICAgICAgICAgYSBNYXAtU2VydmVyLiBWYWx1ZSAwIHJlZmVycyB0 byBkb3duLCB2YWx1ZSAxCiAgICAgICAgICAgIHJlZmVycyB0byB1cC4iCiAgICAgICA6Oj0g eyBsaXNwU2l0ZUxvY2F0b3JFbnRyeSA2IH0KCiAgIGxpc3BTaXRlTG9jYXRvclJsb2NQcmlv cml0eSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPklOVEVHRVI8L2ZvbnQ+PC9zdHJpa2U+ICAgICA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+SW50ZWdlcjMyPC9mb250Pjwvc3Ryb25nPgogICAgICAgTUFYLUFDQ0VTUyA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxz dHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAg ICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAg IlRoZSB1bmljYXN0IHByaW9yaXR5IG9mIHRoZSBSTE9DIGZvciB0aGlzIEVJRCBwcmVmaXgu IgogICAgICAgOjo9IHsgbGlzcFNpdGVMb2NhdG9yRW50cnkgNyB9CgogICBsaXNwU2l0ZUxv Y2F0b3JSbG9jV2VpZ2h0IE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+SU5URUdFUjwvZm9udD48L3N0cmlrZT4gICAgIDxzdHJvbmc+ PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBN QVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48 L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48 L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04K ICAgICAgICAgICAiVGhlIHVuaWNhc3Qgd2VpZ2h0IG9mIHRoZSBSTE9DIGZvciB0aGlzIEVJ RCBwcmVmaXguIgogICAgICAgOjo9IHsgbGlzcFNpdGVMb2NhdG9yRW50cnkgOCB9CgogICBs aXNwU2l0ZUxvY2F0b3JSbG9jTVByaW9yaXR5IE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVgg ICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+SU5URUdFUjwvZm9udD48L3N0cmlrZT4g ICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzI8L2ZvbnQ+PC9zdHJv bmc+CiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YWNjZXNz aWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlYWQt b25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAg REVTQ1JJUFRJT04KICAgICAgICAgICAiVGhlIG11bHRpY2FzdCBwcmlvcml0eSBvZiB0aGUg UkxPQyBmb3IgdGhpcyBFSUQgcHJlZml4LiIKICAgICAgIDo6PSB7IGxpc3BTaXRlTG9jYXRv ckVudHJ5IDkgfQoKICAgbGlzcFNpdGVMb2NhdG9yUmxvY01XZWlnaHQgT0JKRUNULVRZUEUK ICAgICAgIFNZTlRBWCAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSPC9m b250Pjwvc3RyaWtlPiAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIz MjwvZm9udD48L3N0cm9uZz4KICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xv cj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBj dXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgbXVsdGljYXN0IHdl aWdodCBvZiB0aGUgUkxPQyBmb3IgdGhpcyBFSUQgcHJlZml4LiIKICAgICAgIDo6PSB7IGxp c3BTaXRlTG9jYXRvckVudHJ5IDEwIH0KCiAgIGxpc3BTaXRlTG9jYXRvclJsb2NSZWdpc3Rl clN0YXRlIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIFRydXRoVmFsdWUKICAgICAg IE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250 Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElP TgogICAgICAgICAgICJJbmRpY2F0ZXMgdGhlIHJlZ2lzdHJhdGlvbiBzdGF0dXMgb2YgdGhl IEVJRCBwcmVmaXggYnkKICAgICAgICAgICAgdGhpcyBsb2NhdG9yLiBWYWx1ZSAxIGltcGxp ZXMgcmVnaXN0ZXJlZCwgdmFsdWUgMAogICAgICAgICAgICBpbXBsaWVzIG5vdCByZWdpc3Rl cmVkLiIKICAgICAgIDo6PSB7IGxpc3BTaXRlTG9jYXRvckVudHJ5IDExIH0KCiAgIGxpc3BT aXRlTG9jYXRvclJsb2NGaXJzdFJlZ2lzdGVyVGltZSBPQkpFQ1QtVFlQRQogICAgICAgU1lO VEFYICAgICBUaW1lVGlja3MKICAgICAgIE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xv cj0icmVkIj5hY2Nlc3NpYmxlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+cmVhZC1vbmx5PC9mb250Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBj dXJyZW50CiAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICJUaW1lIHNpbmNlIGEgZmly c3QgdmFsaWQgcmVnaXN0ZXIgbWVzc2FnZSBmb3IgdGhpcwogICAgICAgICAgICBFSUQgcHJl Zml4IHdhcyByZWNlaXZlZCBmcm9tIHRoaXMgbG9jYXRvci4iCiAgICAgICA6Oj0geyBsaXNw U2l0ZUxvY2F0b3JFbnRyeSAxMiB9CgogICBsaXNwU2l0ZUxvY2F0b3JSbG9jTGFzdFJlZ2lz dGVyVGltZSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBUaW1lVGlja3MKICAgICAg IE1BWC1BQ0NFU1MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5hY2Nlc3NpYmxlPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+cmVhZC1vbmx5PC9mb250 Pjwvc3Ryb25nPgogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElP TgogICAgICAgICAgICJUaW1lIHNpbmNlIGEgbGFzdCB2YWxpZCByZWdpc3RlciBtZXNzYWdl IGZvciB0aGlzCiAgICAgICAgICAgIEVJRCBwcmVmaXggd2FzIHJlY2VpdmVkIGZyb20gdGhp cyBsb2NhdG9yLiIKICAgICAgIDo6PSB7IGxpc3BTaXRlTG9jYXRvckVudHJ5IDEzIH0KCiAg IGxpc3BTaXRlTG9jYXRvclJsb2NSZWdpc3RlclNlbmRlckxlbmd0aCBPQkpFQ1QtVFlQRQog ICAgICAgU1lOVEFYICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPklOVEVHRVI8L2Zv bnQ+PC9zdHJpa2U+ICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMy PC9mb250Pjwvc3Ryb25nPgogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1 cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoaXMgb2JqZWN0IGlzIHVz ZWQgdG8gZ2V0IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxlbmd0aDwvZm9udD48 L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPm9jdGV0LWxlbmd0aDwvZm9u dD48L3N0cm9uZz4gb2YKICAgICAgICAgICAgbGlzcFNpdGVMb2NhdG9yUmxvY1JlZ2lzdGVy U2VuZGVyLCB0aGUgbmV4dCBvYmplY3QuIgogICAgICAgOjo9IHsgbGlzcFNpdGVMb2NhdG9y RW50cnkgMTQgfQoKICAgbGlzcFNpdGVMb2NhdG9yUmxvY1JlZ2lzdGVyU2VuZGVyIE9CSkVD VC1UWVBFCiAgICAgICBTWU5UQVggICAgIExpc3BBZGRyZXNzVHlwZQogICAgICAgTUFYLUFD Q0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJp a2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJv bmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAg ICAgICAgIlNvdXJjZSBhZGRyZXNzIG9mIHRoZSBsYXN0IHZhbGlkIHJlZ2lzdGVyIG1lc3Nh Z2UgZm9yCiAgICAgICAgICAgIHRoaXMgRUlEIHByZWZpeCB0aGF0IHdhcyByZWNlaXZlZCBm cm9tIHRoaXMgbG9jYXRvci4iCiAgICAgICA6Oj0geyBsaXNwU2l0ZUxvY2F0b3JFbnRyeSAx NSB9CgogICBsaXNwU2l0ZUxvY2F0b3JSbG9jUHJveHlSZXBseSBPQkpFQ1QtVFlQRQogICAg ICAgU1lOVEFYICAgICBUcnV0aFZhbHVlCiAgICAgICBNQVgtQUNDRVNTIDxzdHJpa2U+PGZv bnQgY29sb3I9InJlZCI+YWNjZXNzaWJsZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9u dCBjb2xvcj0iZ3JlZW4iPnJlYWQtb25seTwvZm9udD48L3N0cm9uZz4KICAgICAgIFNUQVRV UyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiSW5kaWNhdGVz IHByb3h5LXJlcGx5aW5nIHN0YXR1cyBvZiB0aGUgcmVnaXN0ZXJpbmcKICAgICAgICAgICAg bG9jYXRvciBvZiB0aGlzIEVJRCBwcmVmaXguIgogICAgICAgOjo9IHsgbGlzcFNpdGVMb2Nh dG9yRW50cnkgMTYgfQoKICAgbGlzcE1hcFNlcnZlcnNUYWJsZSBPQkpFQ1QtVFlQRQogICAg ICAgU1lOVEFYICAgICBTRVFVRU5DRSBPRiBsaXNwTWFwU2VydmVyc0VudHJ5CiAgICAgICBN QVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAg ICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoaXMgdGFibGUgcHJvdmlkZXMgdGhlIHBy b3BlcnRpZXMgb2YgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+bWFwLXNlcnZlcnM8 L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVu Ij5tYXAtc2VydmVyKHMpPC9mb250Pjwvc3Ryb25nPiB3aXRoIHdoaWNoIHRoaXMgZGV2aWNl IGlzCiAgICAgICAgICAgIGNvbmZpZ3VyZWQgdG8gcmVnaXN0ZXIuIgogICAgICAgUkVGRVJF TkNFICJbTElTUF0iCiAgICAgICA6Oj0geyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmxp c3A8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5saXNwTUlC PC9mb250Pjwvc3Ryb25nPiA4IH0KCiAgIGxpc3BNYXBTZXJ2ZXJzRW50cnkgT0JKRUNULVRZ UEUKICAgICAgIFNZTlRBWCAgICAgbGlzcE1hcFNlcnZlcnNFbnRyeQogICAgICAgTUFYLUFD Q0VTUyBub3QtYWNjZXNzaWJsZQogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBE RVNDUklQVElPTgogICAgICAgICAgICJBbiBlbnRyeSAoY29uY2VwdHVhbCByb3cpIGluIHRo ZSBsaXNwTWFwU2VydmVyc1RhYmxlLiIKICAgICAgIElOREVYICAgICAgeyA8c3RyaWtlPjxm b250IGNvbG9yPSJyZWQiPmxpc3BNYXBTZXJ2ZXJzQWRkcmVzc0xlbmd0aDwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmxpc3BNYXBTZXJ2ZXJzQWRkcmVz c0xlbmd0aCw8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAgICAgICAgICAgICAgbGlzcE1hcFNl cnZlcnNBZGRyZXNzIH0KICAgICAgIDo6PSB7IGxpc3BNYXBTZXJ2ZXJzVGFibGUgMSB9Cgog ICBsaXNwTWFwU2VydmVyc0VudHJ5IDo6PSBTRVFVRU5DRSB7CiAgICAgICBsaXNwTWFwU2Vy dmVyc0FkZHJlc3NMZW5ndGggPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSLDwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkludGVnZXIzMiw8 L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBsaXNwTWFwU2VydmVyc0FkZHJlc3MgICAgICAgTGlz cEFkZHJlc3NUeXBlLAogICAgICAgbGlzcE1hcFNlcnZlcnNTdGF0ZSAgICAgICAgIElOVEVH RVIKICAgfQoKICAgbGlzcE1hcFNlcnZlcnNBZGRyZXNzTGVuZ3RoIE9CSkVDVC1UWVBFCiAg ICAgICBTWU5UQVggICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+SU5URUdFUjwvZm9u dD48L3N0cmlrZT4gICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2VyMzI8 L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAg ICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRo aXMgb2JqZWN0IGlzIHVzZWQgdG8gZ2V0IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQi Pmxlbmd0aDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPm9j dGV0LWxlbmd0aDwvZm9udD48L3N0cm9uZz4gb2YKICAgICAgICAgICAgbGlzcE1hcFNlcnZl cnNBZGRyZXNzLCB0aGUgbmV4dCBvYmplY3QuIgoKICAgICAgIDo6PSB7IGxpc3BNYXBTZXJ2 ZXJzRW50cnkgMSB9CgogICBsaXNwTWFwU2VydmVyc0FkZHJlc3MgT0JKRUNULVRZUEUKICAg ICAgIFNZTlRBWCAgICAgTGlzcEFkZHJlc3NUeXBlCiAgICAgICBNQVgtQUNDRVNTIG5vdC1h Y2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9O CiAgICAgICAgICAgIkFkZHJlc3Mgb2YgTWFwLVNlcnZlciBjb25maWd1cmVkIG9uIHRoaXMg ZGV2aWNlLiIKICAgICAgIDo6PSB7IGxpc3BNYXBTZXJ2ZXJzRW50cnkgMiB9CgogICBsaXNw TWFwU2VydmVyc1N0YXRlIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+VHJ1dGhWYWx1ZTwvZm9udD48L3N0cmlrZT4gICAgIDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JTlRFR0VSIHsKICAgICAgICAgICAgICAgICAgICAg ZG93biAoMCksCiAgICAgICAgICAgICAgICAgICAgIHVwICgxKQogICAgICAgICAgICAgICAg ICB9PC9mb250Pjwvc3Ryb25nPgogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNv bG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29s b3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAg IGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlN0YXRlIG9mIHRoaXMg TWFwLVNlcnZlciBjb25maWd1cmVkIG9uIHRoaXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVk Ij5kZXZpY2UuCiAgICAgICAgICAgIFZhbHVlIDAgaW1wbGllcyB0aGF0IHRoZTwvZm9udD48 L3N0cmlrZT4KICAgICAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRldmlj ZSAoMCA9PC9mb250Pjwvc3Ryb25nPiBNYXAtU2VydmVyIGlzIDxzdHJpa2U+PGZvbnQgY29s b3I9InJlZCI+ZG93biwgYW5kIGEKICAgICAgICAgICAgdmFsdWUgb2Y8L2ZvbnQ+PC9zdHJp a2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5kb3duOzwvZm9udD48L3N0cm9uZz4g MSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmltcGxpZXMgdGhhdCB0aGU8L2ZvbnQ+PC9z dHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj49PC9mb250Pjwvc3Ryb25nPiBN YXAtU2VydmVyCiAgICAgICAgICAgIGlzIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+dXAu IjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnVwKS4iPC9m b250Pjwvc3Ryb25nPgogICAgICAgOjo9IHsgbGlzcE1hcFNlcnZlcnNFbnRyeSAzIH0KCiAg IGxpc3BNYXBSZXNvbHZlcnNUYWJsZSBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBT RVFVRU5DRSBPRiBsaXNwTWFwUmVzb2x2ZXJzRW50cnkKICAgICAgIE1BWC1BQ0NFU1Mgbm90 LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJ T04KICAgICAgICAgICAiVGhpcyB0YWJsZSBwcm92aWRlcyB0aGUgcHJvcGVydGllcyBvZiA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFsbCBtYXAKICAgICAgICAgICAgcmVzb2x2ZXJz IHRoYXQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj50aGUK ICAgICAgICAgICAgbWFwLXJlc29sdmVyKHMpPC9mb250Pjwvc3Ryb25nPiB0aGlzIGRldmlj ZSBpcyBjb25maWd1cmVkIHRvIHVzZS4iCiAgICAgICBSRUZFUkVOQ0UgIltMSVNQXSIKICAg ICAgIDo6PSB7IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+bGlzcDwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmxpc3BNSUI8L2ZvbnQ+PC9zdHJvbmc+ IDkgfQoKICAgbGlzcE1hcFJlc29sdmVyc0VudHJ5IE9CSkVDVC1UWVBFCiAgICAgICBTWU5U QVggICAgIGxpc3BNYXBSZXNvbHZlcnNFbnRyeQogICAgICAgTUFYLUFDQ0VTUyBub3QtYWNj ZXNzaWJsZQogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAgICBERVNDUklQVElPTgog ICAgICAgICAgICJBbiBlbnRyeSAoY29uY2VwdHVhbCByb3cpIGluIHRoZQogICAgICAgICAg ICBsaXNwTWFwUmVzb2x2ZXJzVGFibGUuIgogICAgICAgSU5ERVggICAgICB7IDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+bGlzcE1hcFJlc29sdmVyc0FkZHJlc3NMZW5ndGg8L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5saXNwTWFwUmVzb2x2ZXJz QWRkcmVzc0xlbmd0aCw8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAgICAgICAgICAgICAgbGlz cE1hcFJlc29sdmVyc0FkZHJlc3MgfQogICAgICAgOjo9IHsgbGlzcE1hcFJlc29sdmVyc1Rh YmxlIDEgfQoKICAgbGlzcE1hcFJlc29sdmVyc0VudHJ5IDo6PSBTRVFVRU5DRSB7CiAgICAg ICBsaXNwTWFwUmVzb2x2ZXJzQWRkcmVzc0xlbmd0aCAgIDxzdHJpa2U+PGZvbnQgY29sb3I9 InJlZCI+SU5URUdFUiw8L2ZvbnQ+PC9zdHJpa2U+ICAgPHN0cm9uZz48Zm9udCBjb2xvcj0i Z3JlZW4iPkludGVnZXIzMiw8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBsaXNwTWFwUmVzb2x2 ZXJzQWRkcmVzcyAgICAgICAgIExpc3BBZGRyZXNzVHlwZSwKICAgICAgIGxpc3BNYXBSZXNv bHZlcnNTdGF0ZSAgICAgICAgICAgSU5URUdFUgogICB9CgogICBsaXNwTWFwUmVzb2x2ZXJz QWRkcmVzc0xlbmd0aCBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICA8c3RyaWtlPjxm b250IGNvbG9yPSJyZWQiPklOVEVHRVI8L2ZvbnQ+PC9zdHJpa2U+ICAgICA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiI+SW50ZWdlcjMyPC9mb250Pjwvc3Ryb25nPgogICAgICAgTUFY LUFDQ0VTUyBub3QtYWNjZXNzaWJsZQogICAgICAgU1RBVFVTICAgICBjdXJyZW50CiAgICAg ICBERVNDUklQVElPTgogICAgICAgICAgICJUaGlzIG9iamVjdCBpcyB1c2VkIHRvIGdldCB0 aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5sZW5ndGg8L2ZvbnQ+PC9zdHJpa2U+IDxz dHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5vY3RldC1sZW5ndGg8L2ZvbnQ+PC9zdHJvbmc+ IG9mCiAgICAgICAgICAgIGxpc3BNYXBSZXNvbHZlcnNBZGRyZXNzLCB0aGUgbmV4dCBvYmpl Y3QuIgogICAgICAgOjo9IHsgbGlzcE1hcFJlc29sdmVyc0VudHJ5IDEgfQoKICAgbGlzcE1h cFJlc29sdmVyc0FkZHJlc3MgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgTGlzcEFk ZHJlc3NUeXBlCiAgICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFU VVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIkFkZHJlc3Mg b2YgbWFwLXJlc29sdmVyIGNvbmZpZ3VyZWQgb24gdGhpcyBkZXZpY2UuIgogICAgICAgOjo9 IHsgbGlzcE1hcFJlc29sdmVyc0VudHJ5IDIgfQoKICAgbGlzcE1hcFJlc29sdmVyc1N0YXRl IE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJl ZCI+VHJ1dGhWYWx1ZTwvZm9udD48L3N0cmlrZT4gICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9 ImdyZWVuIj5JTlRFR0VSIHsKICAgICAgICAgICAgICAgICAgICAgZG93biAoMCksCiAgICAg ICAgICAgICAgICAgICAgIHVwICgxKQogICAgICAgICAgICAgICAgICB9PC9mb250Pjwvc3Ry b25nPgogICAgICAgTUFYLUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vz c2libGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFk LW9ubHk8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAg IERFU0NSSVBUSU9OCiAgICAgICAgICAgIlN0YXRlIG9mIHRoaXMgPHN0cmlrZT48Zm9udCBj b2xvcj0icmVkIj5tYXAtcmVzb2x2ZXI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9ImdyZWVuIj5NYXAtUmVzb2x2ZXI8L2ZvbnQ+PC9zdHJvbmc+IGNvbmZpZ3VyZWQg b24gdGhpcyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRldmljZS4KICAgICAgICAgICAg VmFsdWUgMCBpbXBsaWVzIHRoYXQgdGhlIG1hcC1yZXNvbHZlcjwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRldmljZQogICAgICAgICAgICAoMCA9IE1h cC1SZXNvbHZlcjwvZm9udD48L3N0cm9uZz4gaXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVk Ij5kb3duLCBhbmQgYQogICAgICAgICAgICB2YWx1ZSBvZjwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRvd247PC9mb250Pjwvc3Ryb25nPiAxIDxzdHJp a2U+PGZvbnQgY29sb3I9InJlZCI+aW1wbGllcyB0aGF0IHRoaXMgbWFwLXJlc29sdmVyPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+PSBNYXAtUmVzb2x2 ZXI8L2ZvbnQ+PC9zdHJvbmc+IGlzIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+dXAuIjwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnVwKS4iPC9mb250 Pjwvc3Ryb25nPgogICAgICAgOjo9IHsgbGlzcE1hcFJlc29sdmVyc0VudHJ5IDMgfQoKICAg bGlzcFVzZVByb3h5RXRyVGFibGUgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgU0VR VUVOQ0UgT0YgbGlzcFVzZVByb3h5RXRyRW50cnkKICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFj Y2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04K ICAgICAgICAgICAiVGhpcyB0YWJsZSBwcm92aWRlcyB0aGUgcHJvcGVydGllcyBvZiBhbGwK ICAgICAgICAgICAgUHJveHkgRVRScyB0aGF0IHRoaXMgZGV2aWNlIGlzIGNvbmZpZ3VyZWQK ICAgICAgICAgICAgdG8gdXNlLiIKICAgICAgIFJFRkVSRU5DRSAiW0xJU1BdIgogICAgICAg Ojo9IHsgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5saXNwPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+bGlzcE1JQjwvZm9udD48L3N0cm9uZz4gMTAg fQoKICAgbGlzcFVzZVByb3h5RXRyRW50cnkgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAg ICAgbGlzcFVzZVByb3h5RXRyRW50cnkKICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2li bGUKICAgICAgIFNUQVRVUyAgICAgY3VycmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAg ICAgICAiQW4gZW50cnkgKGNvbmNlcHR1YWwgcm93KSBpbiB0aGUgbGlzcFVzZVByb3h5RXRy VGFibGUuIgogICAgICAgSU5ERVggICAgICB7IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+ bGlzcFVzZVByb3h5RXRyQWRkcmVzc0xlbmd0aDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj0iZ3JlZW4iPmxpc3BVc2VQcm94eUV0ckFkZHJlc3NMZW5ndGgsPC9mb250 Pjwvc3Ryb25nPgogICAgICAgICAgICAgICAgICAgIGxpc3BVc2VQcm94eUV0ckFkZHJlc3Mg fQogICAgICAgOjo9IHsgbGlzcFVzZVByb3h5RXRyVGFibGUgMSB9CgogICBsaXNwVXNlUHJv eHlFdHJFbnRyeSA6Oj0gU0VRVUVOQ0UgewogICAgICAgbGlzcFVzZVByb3h5RXRyQWRkcmVz c0xlbmd0aCAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JTlRFR0VSLDwvZm9u dD48L3N0cmlrZT4gICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JbnRlZ2Vy MzIsPC9mb250Pjwvc3Ryb25nPgogICAgICAgbGlzcFVzZVByb3h5RXRyQWRkcmVzcyAgICAg ICAgICAgICAgTGlzcEFkZHJlc3NUeXBlLAogICAgICAgbGlzcFVzZVByb3h5RXRyU3RhdGUg ICAgICAgICAgICAgICAgSU5URUdFUgogICB9CgogICBsaXNwVXNlUHJveHlFdHJBZGRyZXNz TGVuZ3RoIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgIDxzdHJpa2U+PGZvbnQgY29s b3I9InJlZCI+SU5URUdFUjwvZm9udD48L3N0cmlrZT4gICAgIDxzdHJvbmc+PGZvbnQgY29s b3I9ImdyZWVuIj5JbnRlZ2VyMzI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICBNQVgtQUNDRVNT IG5vdC1hY2Nlc3NpYmxlCiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NS SVBUSU9OCiAgICAgICAgICAgIlRoaXMgb2JqZWN0IGlzIHVzZWQgdG8gZ2V0IHRoZSA8c3Ry aWtlPjxmb250IGNvbG9yPSJyZWQiPmxlbmd0aDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj0iZ3JlZW4iPm9jdGV0LWxlbmd0aDwvZm9udD48L3N0cm9uZz4gb2YKICAg ICAgICAgICAgbGlzcFVzZVByb3h5RXRyQWRkcmVzcywgdGhlIG5leHQgb2JqZWN0LiIKICAg ICAgIDo6PSB7IGxpc3BVc2VQcm94eUV0ckVudHJ5IDEgfQoKICAgbGlzcFVzZVByb3h5RXRy QWRkcmVzcyBPQkpFQ1QtVFlQRQogICAgICAgU1lOVEFYICAgICBMaXNwQWRkcmVzc1R5cGUK ICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2libGUKICAgICAgIFNUQVRVUyAgICAgY3Vy cmVudAogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiQWRkcmVzcyBvZiBQcm94eSBF VFIgY29uZmlndXJlZCBvbiB0aGlzIGRldmljZS4iCiAgICAgICA6Oj0geyBsaXNwVXNlUHJv eHlFdHJFbnRyeSAyIH0KCiAgIGxpc3BVc2VQcm94eUV0clN0YXRlIE9CSkVDVC1UWVBFCiAg ICAgICBTWU5UQVggICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+VHJ1dGhWYWx1ZTwv Zm9udD48L3N0cmlrZT4gICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5JTlRFR0VS IHsKICAgICAgICAgICAgICAgICAgICAgZG93biAoMCksCiAgICAgICAgICAgICAgICAgICAg IHVwICgxKQogICAgICAgICAgICAgICAgICB9PC9mb250Pjwvc3Ryb25nPgogICAgICAgTUFY LUFDQ0VTUyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmFjY2Vzc2libGU8L2ZvbnQ+PC9z dHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5yZWFkLW9ubHk8L2ZvbnQ+PC9z dHJvbmc+CiAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQKICAgICAgIERFU0NSSVBUSU9OCiAg ICAgICAgICAgIlN0YXRlIG9mIHRoaXMgUHJveHkgRVRSIGNvbmZpZ3VyZWQgb24gdGhpcyA8 c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRldmljZS4KICAgICAgICAgICAgVmFsdWUgMCBp bXBsaWVzIHRoYXQgdGhpczwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0i Z3JlZW4iPmRldmljZQogICAgICAgICAgICAoMCA9PC9mb250Pjwvc3Ryb25nPiBQcm94eSBF VFIgaXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5kb3duLCBhbmQgYQogICAgICAgICAg ICB2YWx1ZSBvZjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4i PmRvd247PC9mb250Pjwvc3Ryb25nPiAxIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+aW1w bGllcyB0aGF0IHRoaXM8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Imdy ZWVuIj49PC9mb250Pjwvc3Ryb25nPiBQcm94eSBFVFIgaXMgPHN0cmlrZT48Zm9udCBjb2xv cj0icmVkIj51cC4iPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVl biI+dXApLiI8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICA6Oj0geyBsaXNwVXNlUHJveHlFdHJF bnRyeSAzIH0KCiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5FTkQ8L2ZvbnQ+PC9z dHJvbmc+Cgo4LiAgUmVsYXRpb25zaGlwIHRvIE90aGVyIE1JQiBNb2R1bGVzCgo4LjEuICBN SUIgbW9kdWxlcyByZXF1aXJlZCBmb3IgSU1QT1JUUwoKICAgVGhlIExJU1AgTUlCIGltcG9y dHMgdGhlIHRleHR1YWwtY29udmVudGlvbiBBZGRyZXNzRmFtaWx5TnVtYmVycyBmcm9tCiAg IHRoZSBJQU5BLUFERFJFU1MtRkFNSUxZLU5VTUJFUlMtTUlCIFtJQU5BXS4KCjkuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlcmUgYXJlIG5vIG1hbmFnZW1lbnQgb2JqZWN0 cyBkZWZpbmVkIGluIHRoaXMgTUlCIG1vZHVsZSB0aGF0IGhhdmUKICAgYSBNQVgtQUNDRVNT IGNsYXVzZSBvZiByZWFkLXdyaXRlIGFuZC9vciByZWFkLWNyZWF0ZS4gIEFzIGxvbmcgYXMK ICAgdGhlc2UgTUlCIG1vZHVsZXMgYXJlIGltcGxlbWVudGVkIGNvcnJlY3RseSwgdGhlcmUg YXJlIG5vIHJpc2tzIHRoYXQKICAgYW55IG1hbmFnZW1lbnQgb2JqZWN0cyBvZiB0aGlzIE1J QiBtb2R1bGUgY2FuIG1vZGlmeSBkZXZpY2Ugc2V0dGluZ3MKICAgdmlhIGRpcmVjdCBTTk1Q IFNFVCBvcGVyYXRpb25zLgoKICAgVGhlcmUgYXJlIG5vIHJlYWRhYmxlIG9iamVjdHMgaW4g dGhpcyBNSUIgbW9kdWxlIChpLmUuLCBvYmplY3RzIHdpdGgKICAgYSBNQVgtQUNDRVNTIG90 aGVyIHRoYW4gbm90LWFjY2Vzc2libGUpIHRoYXQgYXJlIGNvbnNpZGVyZWQKICAgc2Vuc2l0 aXZlLgoKICAgU05NUCB2ZXJzaW9ucyBwcmlvciB0byBTTk1QdjMgZGlkIG5vdCBpbmNsdWRl IGFkZXF1YXRlIHNlY3VyaXR5LgogICBFdmVuIGlmIHRoZSBuZXR3b3JrIGl0c2VsZiBpcyBz ZWN1cmUgKGZvciBleGFtcGxlIGJ5IHVzaW5nIElQc2VjKSwKICAgdGhlcmUgaXMgbm8gY29u dHJvbCBhcyB0byB3aG8gb24gdGhlIHNlY3VyZSBuZXR3b3JrIGlzIGFsbG93ZWQgdG8KICAg YWNjZXNzIGFuZCBHRVQvU0VUIChyZWFkL2NoYW5nZS9jcmVhdGUvZGVsZXRlKSB0aGUgb2Jq ZWN0cyBpbiB0aGlzCiAgIE1JQiBtb2R1bGUuCgogICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0 IGltcGxlbWVudGVycyBjb25zaWRlciB0aGUgc2VjdXJpdHkgZmVhdHVyZXMgYXMKICAgcHJv dmlkZWQgYnkgdGhlIFNOTVB2MyBmcmFtZXdvcmsgKHNlZSBbUkZDMzQxMF0sIHNlY3Rpb24g OCksCiAgIGluY2x1ZGluZyBmdWxsIHN1cHBvcnQgZm9yIHRoZSBTTk1QdjMgY3J5cHRvZ3Jh cGhpYyBtZWNoYW5pc21zIChmb3IKICAgYXV0aGVudGljYXRpb24gYW5kIHByaXZhY3kpLgoK ICAgRnVydGhlciwgZGVwbG95bWVudCBvZiBTTk1QIHZlcnNpb25zIHByaW9yIHRvIFNOTVB2 MyBpcyBOT1QKICAgUkVDT01NRU5ERUQuICBJbnN0ZWFkLCBpdCBpcyBSRUNPTU1FTkRFRCB0 byBkZXBsb3kgU05NUHYzIGFuZCB0bwogICBlbmFibGUgY3J5cHRvZ3JhcGhpYyBzZWN1cml0 eS4gIEl0IGlzIHRoZW4gYSBjdXN0b21lci9vcGVyYXRvcgogICByZXNwb25zaWJpbGl0eSB0 byBlbnN1cmUgdGhhdCB0aGUgU05NUCBlbnRpdHkgZ2l2aW5nIGFjY2VzcyB0byBhbgogICBp bnN0YW5jZSBvZiB0aGVzZSBNSUIgbW9kdWxlcyBpcyBwcm9wZXJseSBjb25maWd1cmVkIHRv IGdpdmUgYWNjZXNzCiAgIHRvIHRoZSBvYmplY3RzIG9ubHkgdG8gdGhvc2UgcHJpbmNpcGFs cyAodXNlcnMpIHRoYXQgaGF2ZSBsZWdpdGltYXRlCiAgIHJpZ2h0cyB0byBpbmRlZWQgR0VU IG9yIFNFVCAoY2hhbmdlL2NyZWF0ZS9kZWxldGUpIHRoZW0uCgoxMC4gIElBTkEgQ29uc2lk ZXJhdGlvbnMKCiAgIExJU1AgaXMgYW4gZXhwZXJpbWVudGFsIHByb3RvY29sIGFuZCB0aGUg TElTUCBNSUIgaXMgYW4gZXhwZXJpbWVudGFsCiAgIE1JQi4gIE5vIElBTkEgYWN0aW9ucyBh cmUgcmVxdWlyZWQgYnkgdGhpcyBkb2N1bWVudC4KCjExLiAgUmVmZXJlbmNlcwoxMS4xLiAg Tm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJTlRFUldPUktdICAgTGV3aXMsIEQuLCBNZXll ciwgRC4sIEZhcmluYWNjaSwgRC4sIGFuZCBWLiBGdWxsZXIsCiAgICAgICAgICAgICAgICAg IkludGVyd29ya2luZyBMSVNQIHdpdGggSVB2NCBhbmQgSVB2NiIsCiAgICAgICAgICAgICAg ICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5kcmFmdC1pZXRmLWxpc3AtaW50ZXJ3b3Jr aW5nLTAxLnR4dDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiI+ZHJhZnQtaWV0Zi1saXNwLWludGVyd29ya2luZy0wMi50eHQ8 L2ZvbnQ+PC9zdHJvbmc+ICh3b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAgICAgICBN YXJjaCA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPjIwMTAuPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+MjAxMS48L2ZvbnQ+PC9zdHJvbmc+CgogICBb TENBRl0gICAgICAgIEZhcmluYWNjaSwgRC4sIE1leWVyLCBELiwgYW5kIEouIFNuaWpkZXJz LCAiTElTUAogICAgICAgICAgICAgICAgIENhbm9uaWNhbCBBZGRyZXNzIEZvcm1hdCIsCiAg ICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5kcmFmdC1mYXJpbmFj Y2ktbGlzcC1sY2FmLTAxLnR4dDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICA8 c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZHJhZnQtZmFyaW5hY2NpLWxpc3AtbGNhZi0w NC50eHQ8L2ZvbnQ+PC9zdHJvbmc+ICh3b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAg ICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPkFwcmlsPC9mb250Pjwvc3RyaWtlPgog ICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5PY3RvYmVyPC9m b250Pjwvc3Ryb25nPiAyMDEwLgoKICAgW0xJU1BdICAgICAgICBGYXJpbmFjY2ksIEQuLCBG dWxsZXIsIFYuLCBNZXllciwgRC4sIGFuZCBELiBMZXdpcywKICAgICAgICAgICAgICAgICAi TG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKSIsCiAgICAgICAgICAgICAg ICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5kcmFmdC1pZXRmLWxpc3AtMDcudHh0PC9m b250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9Imdy ZWVuIj5kcmFmdC1pZXRmLWxpc3AtMTAudHh0PC9mb250Pjwvc3Ryb25nPiAod29yayBpbiBw cm9ncmVzcyksIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+QXByaWwgMjAxMC48L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5NYXJjaCAyMDExLjwvZm9u dD48L3N0cm9uZz4KCiAgIFtMSVNQLUFMVF0gICAgRmFyaW5hY2NpLCBELiwgRnVsbGVyLCBW LiwgTWV5ZXIsIEQuLCBhbmQgRC4gTGV3aXMsCiAgICAgICAgICAgICAgICAgIkxJU1AgQWx0 ZXJuYXRpdmUgVG9wb2xvZ3kgKExJU1AtQUxUKSIsCiAgICAgICAgICAgICAgICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIj5kcmFmdC1pZXRmLWxpc3AtYWx0LTA0LnR4dDwvZm9udD48 L3N0cmlrZT4KICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ ZHJhZnQtaWV0Zi1saXNwLWFsdC0wNi50eHQ8L2ZvbnQ+PC9zdHJvbmc+ICh3b3JrIGluIHBy b2dyZXNzKSwKICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPkFw cmlsIDIwMTAuPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZv bnQgY29sb3I9ImdyZWVuIj5NYXJjaCAyMDExLjwvZm9udD48L3N0cm9uZz4KCiAgIFtMSVNQ LU1TXSAgICAgRmFyaW5hY2NpLCBELiBhbmQgVi4gRnVsbGVyLCAiTElTUCBNYXAgU2VydmVy IiwKICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRyYWZ0LWll dGYtbGlzcC1tcy0wNS50eHQ8L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgICAgICAgICAgPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRyYWZ0LWlldGYtbGlzcC1tcy0wNy50eHQ8L2Zv bnQ+PC9zdHJvbmc+ICh3b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAgICAgICA8c3Ry aWtlPjxmb250IGNvbG9yPSJyZWQiPkFwcmlsIDIwMTAuPC9mb250Pjwvc3RyaWtlPgogICAg ICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5NYXJjaCAyMDExLjwv Zm9udD48L3N0cm9uZz4KCiAgIFtSRkMxMDM1XSAgICAgTW9ja2FwZXRyaXMsIFAuLCAiRG9t YWluIG5hbWVzIC0gaW1wbGVtZW50YXRpb24gYW5kCiAgICAgICAgICAgICAgICAgc3BlY2lm aWNhdGlvbiIsIFNURCAxMywgUkZDIDEwMzUsIE5vdmVtYmVyIDE5ODcuCgogICBbUkZDMjEx OV0gICAgIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp Y2F0ZQogICAgICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZD IDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDMjQwNF0gICAgIE1hZHNvbiwgQy4gYW5kIFIu IEdsZW5uLCAiVGhlIFVzZSBvZiBITUFDLVNIQS0xLTk2CiAgICAgICAgICAgICAgICAgd2l0 aGluIEVTUCBhbmQgQUgiLCBSRkMgMjQwNCwgTm92ZW1iZXIgMTk5OC4KCiAgIFtSRkMyNTc4 XSAgICAgTWNDbG9naHJpZSwgSy4sIEVkLiwgUGVya2lucywgRC4sIEVkLiwgYW5kIEouCiAg ICAgICAgICAgICAgICAgU2Nob2Vud2FlbGRlciwgRWQuLCAiU3RydWN0dXJlIG9mIE1hbmFn ZW1lbnQKICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbiBWZXJzaW9uIDIgKFNNSXYyKSIs IFNURCA1OCwgUkZDIDI1NzgsCiAgICAgICAgICAgICAgICAgQXByaWwgMTk5OS4KCiAgIFtS RkMyNTc5XSAgICAgTWNDbG9naHJpZSwgSy4sIEVkLiwgUGVya2lucywgRC4sIEVkLiwgYW5k IEouCiAgICAgICAgICAgICAgICAgU2Nob2Vud2FlbGRlciwgRWQuLCAiVGV4dHVhbCBDb252 ZW50aW9ucyBmb3IgU01JdjIiLAogICAgICAgICAgICAgICAgIFNURCA1OCwgUkZDIDI1Nzks IEFwcmlsIDE5OTkuCgogICBbUkZDMjU4MF0gICAgIE1jQ2xvZ2hyaWUsIEsuLCBQZXJraW5z LCBELiwgYW5kIEouIFNjaG9lbndhZWxkZXIsCiAgICAgICAgICAgICAgICAgIkNvbmZvcm1h bmNlIFN0YXRlbWVudHMgZm9yIFNNSXYyIiwgU1REIDU4LCBSRkMgMjU4MCwKICAgICAgICAg ICAgICAgICBBcHJpbCAxOTk5LgoKICAgW1JGQzQ2MzRdICAgICBFYXN0bGFrZSwgRC4gYW5k IFQuIEhhbnNlbiwgIlVTIFNlY3VyZSBIYXNoIEFsZ29yaXRobXMKICAgICAgICAgICAgICAg ICAoU0hBIGFuZCBITUFDLVNIQSkiLCBSRkMgNDYzNCwgSnVseSAyMDA2LgoKMTEuMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJQU5BXSAgICAgICAgIklBTkEtQUREUkVTUy1G QU1JTFktTlVNQkVSUy1NSUIgREVGSU5JVElPTlMiLCAmbHQ7aHR0cDovLwogICAgICAgICAg ICAgICAgIHd3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9pYW5hYWRkcmVzc2ZhbWlseW51bWJl cnMtbWliJmd0Oy4KCiAgIFtMSVNQLU1DQVNUXSAgRmFyaW5hY2NpLCBELiwgTWV5ZXIsIEQu LCBad2llYmVsLCBKLiwgYW5kIFMuIFZlbmFhcywKICAgICAgICAgICAgICAgICAiTElTUCBm b3IgTXVsdGljYXN0IEVudmlyb25tZW50cyIsCiAgICAgICAgICAgICAgICAgPHN0cmlrZT48 Zm9udCBjb2xvcj0icmVkIj5kcmFmdC1pZXRmLWxpc3AtbXVsdGljYXN0LTAzLnR4dDwvZm9u dD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVl biI+ZHJhZnQtaWV0Zi1saXNwLW11bHRpY2FzdC0wNC50eHQ8L2ZvbnQ+PC9zdHJvbmc+ICh3 b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPkFwcmlsPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAgIDxzdHJvbmc+ PGZvbnQgY29sb3I9ImdyZWVuIj5PY3RvYmVyPC9mb250Pjwvc3Ryb25nPiAyMDEwLgoKICAg W0xJU1AtTU5dICAgICBGYXJpbmFjY2ksIEQuLCBGdWxsZXIsIFYuLCBNZXllciwgRC4sIGFu ZCBELiBMZXdpcywKICAgICAgICAgICAgICAgICAiTElTUCBNb2JpbGUgTm9kZSBBcmNoaXRl Y3R1cmUiLAogICAgICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+ZHJh ZnQtbWV5ZXItbGlzcC1tbi0wMS50eHQ8L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgICAgICAg ICAgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRyYWZ0LW1leWVyLWxpc3AtbW4tMDQu dHh0PC9mb250Pjwvc3Ryb25nPiAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAg ICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5GZWJydWFyeTwvZm9udD48L3N0cmlrZT4K ICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+T2N0b2Jlcjwv Zm9udD48L3N0cm9uZz4gMjAxMC4KCiAgIFtSRkMyNzg0XSAgICAgRmFyaW5hY2NpLCBELiwg TGksIFQuLCBIYW5rcywgUy4sIE1leWVyLCBELiwgYW5kIFAuCiAgICAgICAgICAgICAgICAg VHJhaW5hLCAiR2VuZXJpYyBSb3V0aW5nIEVuY2Fwc3VsYXRpb24gKEdSRSkiLAogICAgICAg ICAgICAgICAgIFJGQyAyNzg0LCBNYXJjaCAyMDAwLgoKICAgW1JGQzM0MTBdICAgICBDYXNl LCBKLiwgTXVuZHksIFIuLCBQYXJ0YWluLCBELiwgYW5kIEIuIFN0ZXdhcnQsCiAgICAgICAg ICAgICAgICAgIkludHJvZHVjdGlvbiBhbmQgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIGZv cgogICAgICAgICAgICAgICAgIEludGVybmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3 b3JrIiwgUkZDIDM0MTAsCiAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAwMi4KCiAgIFtS RkM0MjcxXSAgICAgUmVraHRlciwgWS4sIExpLCBULiwgYW5kIFMuIEhhcmVzLCAiQSBCb3Jk ZXIgR2F0ZXdheQogICAgICAgICAgICAgICAgIFByb3RvY29sIDQgKEJHUC00KSIsIFJGQyA0 MjcxLCBKYW51YXJ5IDIwMDYuCgogICBbUkZDNDc2MF0gICAgIEJhdGVzLCBULiwgQ2hhbmRy YSwgUi4sIEthdHosIEQuLCBhbmQgWS4gUmVraHRlciwKICAgICAgICAgICAgICAgICAiTXVs dGlwcm90b2NvbCBFeHRlbnNpb25zIGZvciBCR1AtNCIsIFJGQyA0NzYwLAogICAgICAgICAg ICAgICAgIEphbnVhcnkgMjAwNy4KCkFwcGVuZGl4IEEuICA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPkNoYW5nZSBMb2cKCiAgIFRoaXMgaXMgdGhlIGZpcnN0IHZlcnNpb24gb2YgZHJh ZnQtc2NodWRlbC1saXNwLW1pYi0wMC4KCkFwcGVuZGl4IEIuPC9mb250Pjwvc3RyaWtlPiAg T3BlbiBJc3N1ZXMKCiAgIE9wZW4gaXNzdWVzIGZvciB0aGUgTElTUCBNSUIgaW5jbHVkZSB0 aGUgZm9sbG93aW5nOgoKICAgMS4gIFRoaXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5p bml0aWFsPC9mb250Pjwvc3RyaWtlPiB2ZXJzaW9uIG9mIHRoZSBMSVNQIE1JQiBkcmFmdCBk b2VzIG5vdCBpbmNsdWRlIExJU1AKICAgICAgIE11bHRpY2FzdCBjb25zaWRlcmF0aW9ucy4g IE11bHRpY2FzdCBjb25zaWRlcmF0aW9ucyB3aWxsIGJlIGFkZGVkCiAgICAgICBpbiB0aGUg bmV4dCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQuCgpBcHBlbmRpeCA8c3RyaWtlPjxmb250IGNv bG9yPSJyZWQiPkMuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVl biI+Qi48L2ZvbnQ+PC9zdHJvbmc+ICBBY2tub3dsZWRnbWVudHMKCiAgIEFuIGluaXRpYWwg dGhhbmsgeW91IGdvZXMgdG8gRGlubyBGYXJpbmFjY2kgZm9yIGhpcyBpbnB1dHMgYW5kIHJl dmlldwogICBjb21tZW50cyBvbiB0aGUgaW5pdGlhbCB2ZXJzaW9ucyBvZiB0aGlzIGRyYWZ0 LiAgSW4gYWRkaXRpb24sIHRoZQogICBhdXRob3JzIHdvdWxkIGxpa2UgdG8gZ3JhdGVmdWxs eSBhY2tub3dsZWRnZSBtYW55IHBlb3BsZSB3aG8gaGF2ZQogICByZXZpZXdlZCBhbmQgY29t bWVudGVkIG9uIHRoaXMgZHJhZnQuICBUaGV5IGluY2x1ZGU6IERhcnJlbCBMZXdpcywKICAg SXNpZG9yIEtvdXZlbGFzLCBKZXNwZXIgU2tyaXZlciwgPHN0cmlrZT48Zm9udCBjb2xvcj0i cmVkIj5hbmQ8L2ZvbnQ+PC9zdHJpa2U+IFNlbGluYSA8c3RyaWtlPjxmb250IGNvbG9yPSJy ZWQiPkhlaW1saWNoLjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3Jl ZW4iPkhlaW1saWNoLCBhbmQgUGFybmEgQWdyYXdhbC48L2ZvbnQ+PC9zdHJvbmc+CgpBdXRo b3JzJyBBZGRyZXNzZXMKCiAgIEdyZWdnIFNjaHVkZWwKICAgY2lzY28gU3lzdGVtcwogICBU YXNtYW4gRHJpdmUKICAgU2FuIEpvc2UsIENBICA5NTEzNAogICBVU0EKCiAgIEVNYWlsOiBn c2NodWRlbEBjaXNjby5jb20KCiAgIEFtaXQgSmFpbgogICBjaXNjbyBTeXN0ZW1zCiAgIFRh c21hbiBEcml2ZQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0CiAgIFVTQQoKICAgRU1haWw6IGFt aWphaW5AY2lzY28uY29tCgogICBWaWN0b3IgTW9yZW5vCiAgIGNpc2NvIFN5c3RlbXMKICAg VGFzbWFuIERyaXZlCiAgIFNhbiBKb3NlLCBDQSAgOTUxMzQKICAgVVNBCgogICBFTWFpbDog dmltb3Jlbm9AY2lzY28uY29tCjwvcHJlPgoKPC9ib2R5PjwvaHRtbD4= --------------060706050807070709020401-- From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:09:13 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABA23A68C7 for ; Wed, 16 Mar 2011 02:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 OMHRWNOzrk0r for ; Wed, 16 Mar 2011 02:09:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 55EA33A68C5 for ; Wed, 16 Mar 2011 02:09:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzmkW-00037z-V4; Wed, 16 Mar 2011 02:10: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:10:36 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:1 Message-ID: <069.7a1f56493d4e0de1169d7da955bde291@trac.tools.ietf.org> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <060.ac703c54e9577175255bc2d3a9ba9079@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 16 Mar 2011 09:09:13 -0000 #27: ETR may claim a larger prefix than is delegated to it Changes (by luigi@…): * status: new => resolved * resolution: => fixed -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:09:34 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3705A3A68C2 for ; Wed, 16 Mar 2011 02:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 b8xcabomv734 for ; Wed, 16 Mar 2011 02:09:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8D34D3A68C1 for ; Wed, 16 Mar 2011 02:09:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzmku-00039a-32; Wed, 16 Mar 2011 02:11: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:11:00 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:2 Message-ID: <069.5e968e1fb40d48e5a236b093dfc37ad9@trac.tools.ietf.org> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <060.ac703c54e9577175255bc2d3a9ba9079@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 16 Mar 2011 09:09:34 -0000 #27: ETR may claim a larger prefix than is delegated to it Changes (by luigi@…): * status: resolved => closed -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:13:39 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90053A68B1 for ; Wed, 16 Mar 2011 02:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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+gRXezHdxhw for ; Wed, 16 Mar 2011 02:13:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 06BF83A68A7 for ; Wed, 16 Mar 2011 02:13:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzmor-0007o5-3j; Wed, 16 Mar 2011 02:15: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:15:05 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/28#comment:1 Message-ID: <069.ba43ea52fef8db7ea20591865020f8c1@trac.tools.ietf.org> References: <060.393754af92cb1d410761cf740fc51e34@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <060.393754af92cb1d410761cf740fc51e34@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #28: An ITR may claim a larger prefix than is delegated to it 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, 16 Mar 2011 09:13:39 -0000 #28: An ITR may claim a larger prefix than is delegated to it Changes (by luigi@…): * status: new => resolved * resolution: => fixed -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:14:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDDEB3A68C9 for ; Wed, 16 Mar 2011 02:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 IAXWPul7xCLb for ; Wed, 16 Mar 2011 02:14:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3BE6E3A68C8 for ; Wed, 16 Mar 2011 02:14:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzmpB-0008Jh-E0; Wed, 16 Mar 2011 02:15: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:15:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/28#comment:2 Message-ID: <069.bc6c6615140be3c8c9476dfe4877b820@trac.tools.ietf.org> References: <060.393754af92cb1d410761cf740fc51e34@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <060.393754af92cb1d410761cf740fc51e34@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #28: An ITR may claim a larger prefix than is delegated to it 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, 16 Mar 2011 09:14:01 -0000 #28: An ITR may claim a larger prefix than is delegated to it Changes (by luigi@…): * status: resolved => closed -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:16:01 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BABF3A68C9 for ; Wed, 16 Mar 2011 02:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 0Hy6Dlk1qKvi for ; Wed, 16 Mar 2011 02:16:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A42163A68B1 for ; Wed, 16 Mar 2011 02:16:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzmr9-0002pS-5f; Wed, 16 Mar 2011 02:17: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:17:27 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/40#comment:1 Message-ID: <077.f1922ce90b551339b67cd95e3f7aaf55@trac.tools.ietf.org> References: <068.6be121a4e79e460e226dc9e12c9b0b5a@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <068.6be121a4e79e460e226dc9e12c9b0b5a@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org 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 List-Id: 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, 16 Mar 2011 09:16:01 -0000 #40: On the handling of decapsulated packets (from D. Papadimitriou's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:17:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768563A6822 for ; Wed, 16 Mar 2011 02:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 b7GCSQfWKQEP for ; Wed, 16 Mar 2011 02:17:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CEFAA3A68C9 for ; Wed, 16 Mar 2011 02:17:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzms9-00041s-A6; Wed, 16 Mar 2011 02:18: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:18:29 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/40#comment:2 Message-ID: <077.6661db270c6a54bfd428c73532335997@trac.tools.ietf.org> References: <068.6be121a4e79e460e226dc9e12c9b0b5a@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <068.6be121a4e79e460e226dc9e12c9b0b5a@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org 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 List-Id: 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, 16 Mar 2011 09:17:03 -0000 #40: On the handling of decapsulated packets (from D. Papadimitriou's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:18:23 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00913A68D0 for ; Wed, 16 Mar 2011 02:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 XE32-VhfMHJn for ; Wed, 16 Mar 2011 02:18:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2C5553A68C9 for ; Wed, 16 Mar 2011 02:18:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzmtP-0005yC-Ca; Wed, 16 Mar 2011 02:19: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:19:47 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/47#comment:2 Message-ID: <066.a4b0381bf58e40217a9e5c81df3c1c7f@trac.tools.ietf.org> References: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #47: Ambiguity on "MAP-replies" requirements (review 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, 16 Mar 2011 09:18:23 -0000 #47: Ambiguity on "MAP-replies" requirements (review by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:18:47 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA0E3A68D3 for ; Wed, 16 Mar 2011 02:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 AdJGDJpQPfkT for ; Wed, 16 Mar 2011 02:18:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C969C3A68D0 for ; Wed, 16 Mar 2011 02:18:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzmtn-0007op-Eg; Wed, 16 Mar 2011 02:20: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:20:11 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/47#comment:3 Message-ID: <066.d448a5a4dd4e881983cf98b93880368d@trac.tools.ietf.org> References: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #47: Ambiguity on "MAP-replies" requirements (review 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, 16 Mar 2011 09:18:47 -0000 #47: Ambiguity on "MAP-replies" requirements (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:19:53 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2473A68CB for ; Wed, 16 Mar 2011 02:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 wvQ4TliWDV5D for ; Wed, 16 Mar 2011 02:19:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8FECB3A6822 for ; Wed, 16 Mar 2011 02:19:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzmuq-0001D0-5C; Wed, 16 Mar 2011 02:21: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:21:16 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/48#comment:5 Message-ID: <066.8a30a7775311380d4662217e8a55fa97@trac.tools.ietf.org> References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:19:53 -0000 #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) Changes (by luigi@…): * status: reopened => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:21:53 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C25F3A68CB for ; Wed, 16 Mar 2011 02:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ARmDII3cu8Bj for ; Wed, 16 Mar 2011 02:21:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1F9F43A68C8 for ; Wed, 16 Mar 2011 02:21:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzmwm-0006Nq-11; Wed, 16 Mar 2011 02:23: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:23:16 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/48#comment:6 Message-ID: <066.8663e871e8d0eb570925b32ad504d723@trac.tools.ietf.org> References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:21:53 -0000 #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) Changes (by luigi@…): * status: resolved => closed Comment: Text has been modified to fix the issue. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:22:47 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4153B3A68C8 for ; Wed, 16 Mar 2011 02:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 poaAYeHc5AzM for ; Wed, 16 Mar 2011 02:22:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8AA873A68B3 for ; Wed, 16 Mar 2011 02:22:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzmxh-0008MW-2U; Wed, 16 Mar 2011 02:24: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:24:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/49#comment:1 Message-ID: <066.ab1f58fbcc0b04ac21dc06c951e00bdf@trac.tools.ietf.org> References: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [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 List-Id: 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, 16 Mar 2011 09:22:47 -0000 #49: "MAP-Replies" content that is allowed to change (review by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Text has been modified to fix the issue. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:23:05 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3513A68C8 for ; Wed, 16 Mar 2011 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 XbD-u07NYmta for ; Wed, 16 Mar 2011 02:23:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B463E3A68B3 for ; Wed, 16 Mar 2011 02:23:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzmxz-0000OZ-88; Wed, 16 Mar 2011 02:24:31 -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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:24:31 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/49#comment:2 Message-ID: <066.09f4e5fc51737dacff2ea1fa3551087e@trac.tools.ietf.org> References: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [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 List-Id: 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, 16 Mar 2011 09:23:05 -0000 #49: "MAP-Replies" content that is allowed to change (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:24:10 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4B423A68D0 for ; Wed, 16 Mar 2011 02:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 el4E78MXnE-J for ; Wed, 16 Mar 2011 02:24:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2F05F3A68C9 for ; Wed, 16 Mar 2011 02:24:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzmz2-0002Ai-HE; Wed, 16 Mar 2011 02:25: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:25:36 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/50#comment:1 Message-ID: <066.45872e4efd06274cf28b9492e00199a1@trac.tools.ietf.org> References: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #50: MAP-Replies content that MUST be invariant (review 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, 16 Mar 2011 09:24:11 -0000 #50: MAP-Replies content that MUST be invariant (review by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Text has been modified to fix the issue. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:24:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25363A68D0 for ; Wed, 16 Mar 2011 02:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 syjSYU7m5GYr for ; Wed, 16 Mar 2011 02:24:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E6E763A68C8 for ; Wed, 16 Mar 2011 02:24:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzmzO-0002eC-8D; Wed, 16 Mar 2011 02:25: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:25:58 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/50#comment:2 Message-ID: <066.03f6b93b18492578a05cac8143993565@trac.tools.ietf.org> References: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #50: MAP-Replies content that MUST be invariant (review 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, 16 Mar 2011 09:24:32 -0000 #50: MAP-Replies content that MUST be invariant (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:26:15 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6833A68CB for ; Wed, 16 Mar 2011 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 WiH3C4Krt4Xo for ; Wed, 16 Mar 2011 02:26:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 77C943A68C8 for ; Wed, 16 Mar 2011 02:26:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzn13-0005T2-0m; Wed, 16 Mar 2011 02:27: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:27:41 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/42#comment:3 Message-ID: <077.15302a19967e4c9f505793a3dda7c31e@trac.tools.ietf.org> References: <068.949be01828216d93bdf1e485048b2d40@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <068.949be01828216d93bdf1e485048b2d40@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #42: On the SMR mechanism 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, 16 Mar 2011 09:26:15 -0000 #42: On the SMR mechanism Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Text has been modified to fix the issue. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:26:48 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA323A68D2 for ; Wed, 16 Mar 2011 02:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 bBXd8dCH6QVV for ; Wed, 16 Mar 2011 02:26:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5B4223A68D0 for ; Wed, 16 Mar 2011 02:26:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzn1Z-0006oR-Sx; Wed, 16 Mar 2011 02:28: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:28:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/42#comment:4 Message-ID: <077.95ba02f27350d9a44aa9699afa0fa7d0@trac.tools.ietf.org> References: <068.949be01828216d93bdf1e485048b2d40@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <068.949be01828216d93bdf1e485048b2d40@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #42: On the SMR mechanism 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, 16 Mar 2011 09:26:48 -0000 #42: On the SMR mechanism Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:28:50 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84803A68C8 for ; Wed, 16 Mar 2011 02:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 7WsopMbHElK8 for ; Wed, 16 Mar 2011 02:28:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C93393A68DA for ; Wed, 16 Mar 2011 02:28:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzn3Y-00042D-25; Wed, 16 Mar 2011 02:30: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:30:16 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/43#comment:5 Message-ID: <077.3b4eb06e204146063f7f8c5fcdc91029@trac.tools.ietf.org> References: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:28:50 -0000 #43: Issues related to RLOC rechability (definition and mechanism) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Text has been modified to fix the issue. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:29:16 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655193A68D6 for ; Wed, 16 Mar 2011 02:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 w60nD-uOFURm for ; Wed, 16 Mar 2011 02:29:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BD35F3A68CB for ; Wed, 16 Mar 2011 02:29:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzn3v-0007Y2-VL; Wed, 16 Mar 2011 02:30: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:30:39 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/43#comment:6 Message-ID: <077.1d88fe83de297fc8dac3723a04f09d66@trac.tools.ietf.org> References: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <068.cb3ef9621f1fbbc4c08a0c5df7032f96@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:29:16 -0000 #43: Issues related to RLOC rechability (definition and mechanism) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:30:16 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72493A68D0 for ; Wed, 16 Mar 2011 02:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0tUj17tzwNW6 for ; Wed, 16 Mar 2011 02:30:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 31FFB3A68C8 for ; Wed, 16 Mar 2011 02:30:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzn4s-0007WT-Oh; Wed, 16 Mar 2011 02:31: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:31:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/34#comment:5 Message-ID: <077.65664cb0519ac2be80a1c2692dcc8850@trac.tools.ietf.org> References: <068.8aebdfd098dad3558af27ffd1331ae4e@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <068.8aebdfd098dad3558af27ffd1331ae4e@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:30:17 -0000 #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Text has been modified to fix the issue. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: resolved Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:30:46 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09923A68D6 for ; Wed, 16 Mar 2011 02:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 eylOS9PJEGAg for ; Wed, 16 Mar 2011 02:30:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D7B243A68DA for ; Wed, 16 Mar 2011 02:30:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzn5N-0003rI-Oi; Wed, 16 Mar 2011 02:32: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:32:09 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/34#comment:6 Message-ID: <077.59fdf786e87a326a9449e6c3546d5879@trac.tools.ietf.org> References: <068.8aebdfd098dad3558af27ffd1331ae4e@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <068.8aebdfd098dad3558af27ffd1331ae4e@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:30:46 -0000 #34: Editorial Issues Section 8 of draft-ietf-lisp-06.txt Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: closed Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:35:43 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27823A68E1 for ; Wed, 16 Mar 2011 02:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 hVT22AV6ivvL for ; Wed, 16 Mar 2011 02:35:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DFAEC3A68F0 for ; Wed, 16 Mar 2011 02:35:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznAB-0007ZN-7R; Wed, 16 Mar 2011 02:37: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:37:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/98#comment:1 Message-ID: <066.cdd00fd8be3b2d4301bac8dbd4435d90@trac.tools.ietf.org> References: <057.4c9852b0a65d29853b641f556c39a295@trac.tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <057.4c9852b0a65d29853b641f556c39a295@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 09:35:44 -0000 #98: LISP nonce (comment 17 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:36:01 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62123A68E2 for ; Wed, 16 Mar 2011 02:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 QbYlP+ON+oCZ for ; Wed, 16 Mar 2011 02:36:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C583E3A68D9 for ; Wed, 16 Mar 2011 02:35:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznAU-000822-BF; Wed, 16 Mar 2011 02: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:37:26 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/98#comment:2 Message-ID: <066.8662b9e9a5a05e8c8c21b169312d0d30@trac.tools.ietf.org> References: <057.4c9852b0a65d29853b641f556c39a295@trac.tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <057.4c9852b0a65d29853b641f556c39a295@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 09:36:01 -0000 #98: LISP nonce (comment 17 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:37:16 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E7F3A68E2 for ; Wed, 16 Mar 2011 02:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 VjhN2Fx6SHsl for ; Wed, 16 Mar 2011 02:37:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 11E023A68C8 for ; Wed, 16 Mar 2011 02:37:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznBe-0000Uw-7x; Wed, 16 Mar 2011 02:38: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:38:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/39#comment:1 Message-ID: <077.8c386e3c1d622ebf55be652cb592d33b@trac.tools.ietf.org> References: <068.12293221f19f6fe467bf28e060516dd4@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <068.12293221f19f6fe467bf28e060516dd4@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #39: On the performance of cache lookup (from D. Papadimitriou'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: Wed, 16 Mar 2011 09:37:16 -0000 #39: On the performance of cache lookup (from D. Papadimitriou's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:37:38 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4913A68C8 for ; Wed, 16 Mar 2011 02:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 6goebaAmiHoo for ; Wed, 16 Mar 2011 02: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 0BC883A68DB for ; Wed, 16 Mar 2011 02:37:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznC0-0000V6-CY; Wed, 16 Mar 2011 02:39: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:39:00 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/39#comment:2 Message-ID: <077.020ac4a5c4418c2a1580732f79a84ebb@trac.tools.ietf.org> References: <068.12293221f19f6fe467bf28e060516dd4@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <068.12293221f19f6fe467bf28e060516dd4@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #39: On the performance of cache lookup (from D. Papadimitriou'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: Wed, 16 Mar 2011 09:37:38 -0000 #39: On the performance of cache lookup (from D. Papadimitriou's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:38:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8F13A68C9 for ; Wed, 16 Mar 2011 02:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 aXmB2SvWCgah for ; Wed, 16 Mar 2011 02:38:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B57DA3A68E8 for ; Wed, 16 Mar 2011 02:38:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznCt-0000Xi-AI; Wed, 16 Mar 2011 02: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:39:55 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/44#comment:3 Message-ID: <066.9dcaee37ac3356beb317c1f330375bfb@trac.tools.ietf.org> References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #44: LISP vs existing (reported by Yakov 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, 16 Mar 2011 09:38:32 -0000 #44: LISP vs existing (reported by Yakov Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:38:49 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719663A68DE for ; Wed, 16 Mar 2011 02:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 3s1dy-J3TBGe for ; Wed, 16 Mar 2011 02:38:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3E2D23A68DB for ; Wed, 16 Mar 2011 02:38:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznD9-0000bT-U3; Wed, 16 Mar 2011 02:40: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:40:11 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/44#comment:4 Message-ID: <066.cad28d7fd331f16c2e5896616ac6482d@trac.tools.ietf.org> References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #44: LISP vs existing (reported by Yakov 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, 16 Mar 2011 09:38:49 -0000 #44: LISP vs existing (reported by Yakov Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:39:52 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09913A68DE for ; Wed, 16 Mar 2011 02:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cSOxJNIAJImZ for ; Wed, 16 Mar 2011 02:39:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AA0623A68DB for ; Wed, 16 Mar 2011 02:39:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznEB-0000kN-V5; Wed, 16 Mar 2011 02:41: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:41:15 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/45#comment:1 Message-ID: <066.e266c12a21301648dfdfcb005ae5ec62@trac.tools.ietf.org> References: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #45: LISP vs. Existing (from 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, 16 Mar 2011 09:39:52 -0000 #45: LISP vs. Existing (from Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:40:22 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1DF3A68F1 for ; Wed, 16 Mar 2011 02:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 8DtyrVdMspDX for ; Wed, 16 Mar 2011 02:40:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BC61A3A68DB for ; Wed, 16 Mar 2011 02:40:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznEQ-0000m9-4Z; Wed, 16 Mar 2011 02:41: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:41:30 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/45#comment:2 Message-ID: <066.f746b2b5af4b55097e4b8ff8aef5dee1@trac.tools.ietf.org> References: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #45: LISP vs. Existing (from 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, 16 Mar 2011 09:40:22 -0000 #45: LISP vs. Existing (from Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:40:49 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204613A68E8 for ; Wed, 16 Mar 2011 02:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 XCOzrmCscJvS for ; Wed, 16 Mar 2011 02:40:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C58503A68DB for ; Wed, 16 Mar 2011 02:40:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznF6-0000nX-7H; Wed, 16 Mar 2011 02:42:12 -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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:42:12 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/46#comment:2 Message-ID: <066.e563456355161895f5be21e70eda0460@trac.tools.ietf.org> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review 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, 16 Mar 2011 09:40:49 -0000 #46: Cache Thrashing (review by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:41:15 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E848C3A68C4 for ; Wed, 16 Mar 2011 02:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 fvexmTxOpXhn for ; Wed, 16 Mar 2011 02:41:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A32283A68EE for ; Wed, 16 Mar 2011 02:41:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznFO-0000ne-Uz; Wed, 16 Mar 2011 02:42: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:42:30 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/46#comment:3 Message-ID: <066.cfaff3705fe558b8eeab1d64dbcd2893@trac.tools.ietf.org> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review 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, 16 Mar 2011 09:41:15 -0000 #46: Cache Thrashing (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:41:58 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08AD63A68F2 for ; Wed, 16 Mar 2011 02:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 phLUnv+Xdl4x for ; Wed, 16 Mar 2011 02:41:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4990D3A68DB for ; Wed, 16 Mar 2011 02:41:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznGE-0000pq-Pq; Wed, 16 Mar 2011 02:43: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:43:22 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/53#comment:1 Message-ID: <066.14c25d4c8ae5bf2a973a377ac72adc97@trac.tools.ietf.org> References: <057.cd86d557ebd472d3854de590d8c2facd@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <057.cd86d557ebd472d3854de590d8c2facd@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #53: Reachability between ETR and EID (review 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, 16 Mar 2011 09:41:58 -0000 #53: Reachability between ETR and EID (review by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:42:24 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8373A68C4 for ; Wed, 16 Mar 2011 02:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 y4Tl08klMLTm for ; Wed, 16 Mar 2011 02:42:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 722FE3A68F0 for ; Wed, 16 Mar 2011 02:42:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznGb-0000qE-04; Wed, 16 Mar 2011 02:43: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:43:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/53#comment:2 Message-ID: <066.67fd41fc6d980775c83496f2760a1d10@trac.tools.ietf.org> References: <057.cd86d557ebd472d3854de590d8c2facd@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <057.cd86d557ebd472d3854de590d8c2facd@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #53: Reachability between ETR and EID (review 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, 16 Mar 2011 09:42:24 -0000 #53: Reachability between ETR and EID (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:43:25 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC743A68D5 for ; Wed, 16 Mar 2011 02:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 uYGvKOwREEet for ; Wed, 16 Mar 2011 02:43:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8CAAE3A68C4 for ; Wed, 16 Mar 2011 02:43:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznHc-0000s7-2A; Wed, 16 Mar 2011 02:44: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:44:48 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/57#comment:2 Message-ID: <077.9f344c8f5a00a2f979e6e72740fceb90@trac.tools.ietf.org> References: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <068.ce085df57fc97c68212636551555c56c@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:43:25 -0000 #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:43:52 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98313A68D5 for ; Wed, 16 Mar 2011 02:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 JSbwapJ+w59f for ; Wed, 16 Mar 2011 02:43:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BD70B3A68C4 for ; Wed, 16 Mar 2011 02:43:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznI6-0000xw-AF; Wed, 16 Mar 2011 02:45: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:45:18 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/57#comment:3 Message-ID: <077.bb1f33ec88f722b9761872648a62b346@trac.tools.ietf.org> References: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <068.ce085df57fc97c68212636551555c56c@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:43:52 -0000 #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:47:07 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2386F3A68F7 for ; Wed, 16 Mar 2011 02:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 M4oYJKnOaxzZ for ; Wed, 16 Mar 2011 02:47:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 62D883A68F9 for ; Wed, 16 Mar 2011 02:47:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznLE-0001AJ-U2; Wed, 16 Mar 2011 02:48: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:48:32 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/63#comment:3 Message-ID: <077.fe4388b1a5ea3977a69d4ea364242598@trac.tools.ietf.org> References: <068.d92e7478bf86c421ac2f1228852f774a@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <068.d92e7478bf86c421ac2f1228852f774a@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:47:07 -0000 #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:47:29 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4BE3A68EC for ; Wed, 16 Mar 2011 02:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 oI9Tklvpsv0Z for ; Wed, 16 Mar 2011 02:47:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 672EB3A68EB for ; Wed, 16 Mar 2011 02:47:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznLa-0001AN-Vc; Wed, 16 Mar 2011 02:48: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:48:54 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/63#comment:4 Message-ID: <077.ec606edcc9823e95525fdbe1dd2cbca9@trac.tools.ietf.org> References: <068.d92e7478bf86c421ac2f1228852f774a@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <068.d92e7478bf86c421ac2f1228852f774a@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:47:29 -0000 #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:49:36 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB683A68FD for ; Wed, 16 Mar 2011 02:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 HwGnRVhJ8PSE for ; Wed, 16 Mar 2011 02:49:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 820903A68FC for ; Wed, 16 Mar 2011 02:49:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznNe-0001Kf-2a; Wed, 16 Mar 2011 02:51: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:51:02 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:3 Message-ID: <077.cb2e19d18acb60e98aa14676c9c7e1af@trac.tools.ietf.org> References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <068.3a3b43d90cb0ced8925103b20f872430@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:49:36 -0000 #66: Strict RLOC ordering causing problems on mapping changes Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:58:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8EE3A6904 for ; Wed, 16 Mar 2011 02:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 DSRBey4QOTih for ; Wed, 16 Mar 2011 02:58:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 01E253A6911 for ; Wed, 16 Mar 2011 02:58:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznVm-0001ae-Ca; Wed, 16 Mar 2011 02:59: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 09:59:26 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:4 Message-ID: <077.d8c5007d771a35c58fa678062e6f4f21@trac.tools.ietf.org> References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <068.3a3b43d90cb0ced8925103b20f872430@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:58:00 -0000 #66: Strict RLOC ordering causing problems on mapping changes Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:59:13 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956FD3A68E8 for ; Wed, 16 Mar 2011 02:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 B1i7tOLXOmsI for ; Wed, 16 Mar 2011 02: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 E08083A68D8 for ; Wed, 16 Mar 2011 02:59:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznWx-0001p6-El; Wed, 16 Mar 2011 03:00: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:00:39 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/68#comment:2 Message-ID: <077.ff20d895ba1c7c68cf35c6d9875184c4@trac.tools.ietf.org> References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <068.f483118418ff0a04689ef79494e01869@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:16 -0700 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 List-Id: 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, 16 Mar 2011 09:59:13 -0000 #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 02:59:30 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373623A68E8 for ; Wed, 16 Mar 2011 02:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 DlqpVE5uRu6f for ; Wed, 16 Mar 2011 02:59:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 930C53A68D8 for ; Wed, 16 Mar 2011 02:59:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznXE-0004Ii-59; Wed, 16 Mar 2011 03:00: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:00:56 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/68#comment:3 Message-ID: <077.084a34540ff586a55f0f54fee21f31dd@trac.tools.ietf.org> References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <068.f483118418ff0a04689ef79494e01869@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 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 List-Id: 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, 16 Mar 2011 09:59:30 -0000 #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:00:59 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D323A690E for ; Wed, 16 Mar 2011 03:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 s6DVV2-LqzX6 for ; Wed, 16 Mar 2011 03:00:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D6F573A6904 for ; Wed, 16 Mar 2011 03:00:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznYf-0000yC-EC; Wed, 16 Mar 2011 03:02: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:02:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/70#comment:2 Message-ID: <077.a886f61b4773a434a5dd4c835fe8a29c@trac.tools.ietf.org> References: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <068.7ad8426e5defed8efc75a91b3b935546@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 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 List-Id: 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, 16 Mar 2011 10:00:59 -0000 #70: Client not respecting RLOC weights (from Y. Rekhter's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:01:17 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65B43A68E0 for ; Wed, 16 Mar 2011 03:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4Ge6sNWhLosm for ; Wed, 16 Mar 2011 03:01:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3AE123A68D8 for ; Wed, 16 Mar 2011 03:01:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznYx-0000yY-QI; Wed, 16 Mar 2011 03:02:43 -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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:02:43 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/70#comment:3 Message-ID: <077.6ea976b1381578bf1280e8b1ca6ad713@trac.tools.ietf.org> References: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <068.7ad8426e5defed8efc75a91b3b935546@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 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 List-Id: 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, 16 Mar 2011 10:01:17 -0000 #70: Client not respecting RLOC weights (from Y. Rekhter's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:02:23 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF923A68E8 for ; Wed, 16 Mar 2011 03:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 JGoARm2tA7LE for ; Wed, 16 Mar 2011 03:02:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A8BFC3A68E0 for ; Wed, 16 Mar 2011 03:02:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzna1-000104-7g; Wed, 16 Mar 2011 03:03: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:03:49 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/73#comment:1 Message-ID: <077.c9a1b06ab317334332c1ccaf93963721@trac.tools.ietf.org> References: <068.11139862467bb967cdc8cf5e6cf8c426@trac.tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <068.11139862467bb967cdc8cf5e6cf8c426@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #73: Tunnel liveness (from R. Bonica review for the RTG directorate) 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, 16 Mar 2011 10:02:23 -0000 #73: Tunnel liveness (from R. Bonica review for the RTG directorate) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:02:57 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 434063A68E8 for ; Wed, 16 Mar 2011 03:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 yBnDXZU1YOQD for ; Wed, 16 Mar 2011 03:02:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 96E613A68E0 for ; Wed, 16 Mar 2011 03:02:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznaZ-00010u-62; Wed, 16 Mar 2011 03:04: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:04:23 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/73#comment:2 Message-ID: <077.be8fa6f924630c2e3165013a5297ec4e@trac.tools.ietf.org> References: <068.11139862467bb967cdc8cf5e6cf8c426@trac.tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <068.11139862467bb967cdc8cf5e6cf8c426@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #73: Tunnel liveness (from R. Bonica review for the RTG directorate) 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, 16 Mar 2011 10:02:57 -0000 #73: Tunnel liveness (from R. Bonica review for the RTG directorate) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:03:49 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A3F3A68E8 for ; Wed, 16 Mar 2011 03:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 ayj7jRJYsVLW for ; Wed, 16 Mar 2011 03:03:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3B4283A68E0 for ; Wed, 16 Mar 2011 03:03:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznbM-00014n-Ik; Wed, 16 Mar 2011 03:05:12 -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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:05:12 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/84#comment:2 Message-ID: <066.4525618c4f8451780722ff100d5c53be@trac.tools.ietf.org> References: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 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, 16 Mar 2011 10:03:49 -0000 #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:04:07 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8923A6904 for ; Wed, 16 Mar 2011 03:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 UPQ+Mp+2pBlU for ; Wed, 16 Mar 2011 03:04:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C3BAD3A6909 for ; Wed, 16 Mar 2011 03:04:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznbe-00019Q-Bf; Wed, 16 Mar 2011 03:05: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:05:30 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/84#comment:3 Message-ID: <066.225a40b5125b385b346d7ef1cde4d946@trac.tools.ietf.org> References: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 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, 16 Mar 2011 10:04:07 -0000 #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:05:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7F03A68FE for ; Wed, 16 Mar 2011 03:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 o9C8eIZMyvXO for ; Wed, 16 Mar 2011 03:05:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CB98F3A68E0 for ; Wed, 16 Mar 2011 03:05:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznck-0002Lo-D5; Wed, 16 Mar 2011 03:06: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:06:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/89#comment:1 Message-ID: <066.e9922b9af90122c3c64c65910b4db41c@trac.tools.ietf.org> References: <057.915c3b2990c494d4d75d76e0f1fee088@trac.tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <057.915c3b2990c494d4d75d76e0f1fee088@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:05:12 -0000 #89: On redefining the name of the encapsulated packet header (comment 12 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:05:35 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5CC3A68E0 for ; Wed, 16 Mar 2011 03:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 UVJHVDyQlGyU for ; Wed, 16 Mar 2011 03:05:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E16943A6914 for ; Wed, 16 Mar 2011 03:05:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznd7-0002M4-Dt; Wed, 16 Mar 2011 03:07: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:07:01 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/89#comment:2 Message-ID: <066.5822996df8c2cbf7d3029434170584f8@trac.tools.ietf.org> References: <057.915c3b2990c494d4d75d76e0f1fee088@trac.tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <057.915c3b2990c494d4d75d76e0f1fee088@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:05:35 -0000 #89: On redefining the name of the encapsulated packet header (comment 12 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:06:30 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002463A6917 for ; Wed, 16 Mar 2011 03:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 pShbT6y9hhd6 for ; Wed, 16 Mar 2011 03:06:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 374DC3A68E0 for ; Wed, 16 Mar 2011 03:06:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzndz-0002Ng-Pi; Wed, 16 Mar 2011 03:07: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:07:55 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/90#comment:1 Message-ID: <066.7dc81110a5791340520cbb7bbd739595@trac.tools.ietf.org> References: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.tools.ietf.org> X-Trac-Ticket-ID: 90 In-Reply-To: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:06:30 -0000 #90: Restricting re-encapsulation (comment 12 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:06:48 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E7D3A6918 for ; Wed, 16 Mar 2011 03:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 ZGYMGHpHJKh5 for ; Wed, 16 Mar 2011 03:06:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3AE793A6915 for ; Wed, 16 Mar 2011 03:06:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzneH-0002Q2-QP; Wed, 16 Mar 2011 03:08: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:08:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/90#comment:2 Message-ID: <066.e7bf6514c7fc426aed536d9de2ca8cf6@trac.tools.ietf.org> References: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.tools.ietf.org> X-Trac-Ticket-ID: 90 In-Reply-To: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:06:48 -0000 #90: Restricting re-encapsulation (comment 12 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:07:45 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19273A68E9 for ; Wed, 16 Mar 2011 03:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 TmN9fY9xTjbD for ; Wed, 16 Mar 2011 03:07:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 36F233A68E0 for ; Wed, 16 Mar 2011 03:07:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznfD-0002RC-Pi; Wed, 16 Mar 2011 03:09: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:09:11 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/94#comment:1 Message-ID: <066.7484342797fad1c558d20b14cbf8f8a3@trac.tools.ietf.org> References: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:07:45 -0000 #94: Implications on using Control plane for data forwarding (comment 15 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:08:36 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26C63A68EE for ; Wed, 16 Mar 2011 03:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 m5fNUBt6N+iu for ; Wed, 16 Mar 2011 03:08:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4CB8B3A68E0 for ; Wed, 16 Mar 2011 03:08:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzng2-0002TE-Kq; Wed, 16 Mar 2011 03:10: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:10:02 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/94#comment:2 Message-ID: <066.8b5879a95ae60dc0e4576b08a1d9c130@trac.tools.ietf.org> References: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:08:37 -0000 #94: Implications on using Control plane for data forwarding (comment 15 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:09:48 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145023A6918 for ; Wed, 16 Mar 2011 03:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 OuI5y0wbURRS for ; Wed, 16 Mar 2011 03:09:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6F8CA3A6917 for ; Wed, 16 Mar 2011 03:09:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznhB-0002lC-U3; Wed, 16 Mar 2011 03:11: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:11:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/100#comment:1 Message-ID: <066.fc892e7ce84cbe98857ade9dae5f7fc7@trac.tools.ietf.org> References: <057.2c7ec716cb843a3d17b46315e069c60a@trac.tools.ietf.org> X-Trac-Ticket-ID: 100 In-Reply-To: <057.2c7ec716cb843a3d17b46315e069c60a@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:09:48 -0000 #100: "Stateless" and "Stateful" MTU handling (comment 18 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:10:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A114F3A6904 for ; Wed, 16 Mar 2011 03:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 pIYlfHhPD+gX for ; Wed, 16 Mar 2011 03:10:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B1A6E3A6912 for ; Wed, 16 Mar 2011 03:10:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznha-0002m2-6j; Wed, 16 Mar 2011 03:11: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:11:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/100#comment:2 Message-ID: <066.7261d889bbcf2cd6fa23461f8ba88ab9@trac.tools.ietf.org> References: <057.2c7ec716cb843a3d17b46315e069c60a@trac.tools.ietf.org> X-Trac-Ticket-ID: 100 In-Reply-To: <057.2c7ec716cb843a3d17b46315e069c60a@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:10:12 -0000 #100: "Stateless" and "Stateful" MTU handling (comment 18 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:11:24 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D863A68EE for ; Wed, 16 Mar 2011 03:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 cxgoPdwpwA1U for ; Wed, 16 Mar 2011 03:11:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 63BE43A6904 for ; Wed, 16 Mar 2011 03:11:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznic-00037q-Sx; Wed, 16 Mar 2011 03:12: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:12:42 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/101#comment:1 Message-ID: <066.2b3a86ea8afb1ff2600019560ef21e61@trac.tools.ietf.org> References: <057.0e0d4458c9205c12214b19f32a304af1@trac.tools.ietf.org> X-Trac-Ticket-ID: 101 In-Reply-To: <057.0e0d4458c9205c12214b19f32a304af1@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:11:26 -0000 #101: Filtering ICMP messages (comment 19 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:11:35 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7523A6912 for ; Wed, 16 Mar 2011 03:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 BTHiA0tku47x for ; Wed, 16 Mar 2011 03:11:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CF6D03A68EE for ; Wed, 16 Mar 2011 03:11:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzniv-0003SV-Dp; Wed, 16 Mar 2011 03:13: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:13:01 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/101#comment:2 Message-ID: <066.a6f48dc272e91a8b8722f2c15dc2ec8c@trac.tools.ietf.org> References: <057.0e0d4458c9205c12214b19f32a304af1@trac.tools.ietf.org> X-Trac-Ticket-ID: 101 In-Reply-To: <057.0e0d4458c9205c12214b19f32a304af1@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:11:36 -0000 #101: Filtering ICMP messages (comment 19 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:12:54 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06223A68C4 for ; Wed, 16 Mar 2011 03:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 iC7U8P8NsrWj for ; Wed, 16 Mar 2011 03:12:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EFA8F3A68DB for ; Wed, 16 Mar 2011 03:12:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznkC-0005tq-Gl; Wed, 16 Mar 2011 03:14: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:14:20 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/102#comment:1 Message-ID: <066.7b6cbef10fc379697ae9df31b9c78d57@trac.tools.ietf.org> References: <057.e4c8cc50b0e5d4e7bd0e5b0c75ab80af@trac.tools.ietf.org> X-Trac-Ticket-ID: 102 In-Reply-To: <057.e4c8cc50b0e5d4e7bd0e5b0c75ab80af@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:12:54 -0000 #102: Originating ITR RLOC address (comment 20 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:13:53 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEF23A6912 for ; Wed, 16 Mar 2011 03:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 OZ3qp4Xyz47w for ; Wed, 16 Mar 2011 03:13:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8806A3A68C4 for ; Wed, 16 Mar 2011 03:13:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznl8-0007fq-UY; Wed, 16 Mar 2011 03:15: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:15:18 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/102#comment:2 Message-ID: <066.227b09a9ee94ac4ab6b93c258af25f04@trac.tools.ietf.org> References: <057.e4c8cc50b0e5d4e7bd0e5b0c75ab80af@trac.tools.ietf.org> X-Trac-Ticket-ID: 102 In-Reply-To: <057.e4c8cc50b0e5d4e7bd0e5b0c75ab80af@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:13:53 -0000 #102: Originating ITR RLOC address (comment 20 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:14:57 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9DC3A68DB for ; Wed, 16 Mar 2011 03:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 Ru0ufDVQg7Jn for ; Wed, 16 Mar 2011 03:14:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A92E53A68C4 for ; Wed, 16 Mar 2011 03:14:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznmB-0000tq-8a; Wed, 16 Mar 2011 03:16: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:16:23 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/105#comment:1 Message-ID: <066.c112f3140b515b04938a9465917c57c4@trac.tools.ietf.org> References: <057.dbd133e742ac4f8794ca979b8e84c9e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 105 In-Reply-To: <057.dbd133e742ac4f8794ca979b8e84c9e4@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:14:57 -0000 #105: EID-to-RLOC UDP Map-Reply message (comment 23 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:15:15 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5E13A68E0 for ; Wed, 16 Mar 2011 03:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 WhKNoTPRbfBH for ; Wed, 16 Mar 2011 03:15:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B32583A68C4 for ; Wed, 16 Mar 2011 03:15:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznmT-0001Ej-AH; Wed, 16 Mar 2011 03:16: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:16:41 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/105#comment:2 Message-ID: <066.1cbdcc8d13f2b0fb0c36b28b155dbe1a@trac.tools.ietf.org> References: <057.dbd133e742ac4f8794ca979b8e84c9e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 105 In-Reply-To: <057.dbd133e742ac4f8794ca979b8e84c9e4@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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, 16 Mar 2011 10:15:15 -0000 #105: EID-to-RLOC UDP Map-Reply message (comment 23 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:16:01 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964AF3A6917 for ; Wed, 16 Mar 2011 03:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 WaeXkwf8e4wj for ; Wed, 16 Mar 2011 03:16:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E83BB3A68E0 for ; Wed, 16 Mar 2011 03:16:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznnD-0002l1-Gd; Wed, 16 Mar 2011 03:17: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:17:27 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/111#comment:1 Message-ID: <065.7917574a55c1cc697b54f7f52aa2ad02@trac.tools.ietf.org> References: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <056.ec8f02790caa5fcbbae985c1057f553c@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #111: Semantics of LSB 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, 16 Mar 2011 10:16:01 -0000 #111: Semantics of LSB Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:16:22 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF76D3A68E0 for ; Wed, 16 Mar 2011 03:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 uldTwH-dVYRc for ; Wed, 16 Mar 2011 03:16:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1E7993A68C4 for ; Wed, 16 Mar 2011 03:16:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznnY-000390-MP; Wed, 16 Mar 2011 03:17: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:17:48 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/111#comment:2 Message-ID: <065.791713f8a9de79c1ea61f1c0e866f9c5@trac.tools.ietf.org> References: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <056.ec8f02790caa5fcbbae985c1057f553c@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #111: Semantics of LSB 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, 16 Mar 2011 10:16:22 -0000 #111: Semantics of LSB Changes (by luigi@…): * status: resolved => closed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:17:34 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F123A68E0 for ; Wed, 16 Mar 2011 03:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 wxkH0c8i31Pa for ; Wed, 16 Mar 2011 03:17:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A55493A68EC for ; Wed, 16 Mar 2011 03:17:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznof-0004xg-I9; Wed, 16 Mar 2011 03:18: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:18:57 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/113#comment:2 Message-ID: <065.a388779083d87295d1fc586a500048f2@trac.tools.ietf.org> References: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #113: inbound traffic engineering support with LISP 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, 16 Mar 2011 10:17:34 -0000 #113: inbound traffic engineering support with LISP Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:17:49 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FF33A68DF for ; Wed, 16 Mar 2011 03:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 kcF08SLPBrbi for ; Wed, 16 Mar 2011 03:17:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 97D823A68EC for ; Wed, 16 Mar 2011 03:17:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznow-0005F7-9R; Wed, 16 Mar 2011 03:19: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:19:14 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/113#comment:3 Message-ID: <065.34e057eb3361d78952bebf187e0f7049@trac.tools.ietf.org> References: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #113: inbound traffic engineering support with LISP 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, 16 Mar 2011 10:17:49 -0000 #113: inbound traffic engineering support with LISP Changes (by luigi@…): * status: resolved => closed -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:19:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82C13A68E8 for ; Wed, 16 Mar 2011 03:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 JLYTTPA4cDxt for ; Wed, 16 Mar 2011 03:19:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9F8CF3A68E0 for ; Wed, 16 Mar 2011 03:19:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznqO-0000ZG-7K; Wed, 16 Mar 2011 03: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:20:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/38#comment:1 Message-ID: <077.7a097e387ffe1e99afe9c6e55584af23@trac.tools.ietf.org> References: <068.d78898c7d3942fc16603b8eb00cf99bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <068.d78898c7d3942fc16603b8eb00cf99bf@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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 List-Id: 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, 16 Mar 2011 10:19:18 -0000 #38: On the limitation of LISP recursive encapsulation (from D. Papadimitriou's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:19:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84603A68E8 for ; Wed, 16 Mar 2011 03:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 aSsOI1jYECob for ; Wed, 16 Mar 2011 03:19:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 36C9A3A68E0 for ; Wed, 16 Mar 2011 03:19:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznqi-0000xQ-PS; Wed, 16 Mar 2011 03:21: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:21:04 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/38#comment:2 Message-ID: <077.fc0dc4aca8652a5bb2db80aa4e6d3aa9@trac.tools.ietf.org> References: <068.d78898c7d3942fc16603b8eb00cf99bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <068.d78898c7d3942fc16603b8eb00cf99bf@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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 List-Id: 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, 16 Mar 2011 10:19:40 -0000 #38: On the limitation of LISP recursive encapsulation (from D. Papadimitriou's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:20:51 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273633A68F2 for ; Wed, 16 Mar 2011 03:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 uR1YbiXFHd6w for ; Wed, 16 Mar 2011 03:20:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A0C383A68E0 for ; Wed, 16 Mar 2011 03:20:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznri-00032z-80; Wed, 16 Mar 2011 03:22: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:22:06 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/41#comment:1 Message-ID: <077.4b26e12efa5a8a144c8c7d2b3a8fc49f@trac.tools.ietf.org> References: <068.c98233242421fa02404e78eeae2303e2@trac.tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <068.c98233242421fa02404e78eeae2303e2@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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 List-Id: 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, 16 Mar 2011 10:20:51 -0000 #41: Map-Reply sent for not reachable EID (from D. Papadimitriou's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:21:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE093A68EC for ; Wed, 16 Mar 2011 03:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 m4c+1FJShtaT for ; Wed, 16 Mar 2011 03:21:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AF5CE3A68E8 for ; Wed, 16 Mar 2011 03:21:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznsK-0004Zk-9W; Wed, 16 Mar 2011 03:22: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:22:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/41#comment:2 Message-ID: <077.848a5d9794aa810676d75ca1586bd5d2@trac.tools.ietf.org> References: <068.c98233242421fa02404e78eeae2303e2@trac.tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <068.c98233242421fa02404e78eeae2303e2@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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 List-Id: 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, 16 Mar 2011 10:21:18 -0000 #41: Map-Reply sent for not reachable EID (from D. Papadimitriou's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:22:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B65D3A68EE for ; Wed, 16 Mar 2011 03:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 sLPnScugG3ma for ; Wed, 16 Mar 2011 03:22:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5B7EC3A68E0 for ; Wed, 16 Mar 2011 03:22:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznt0-00067V-Ty; Wed, 16 Mar 2011 03:23: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:23:26 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/71#comment:1 Message-ID: <077.741e5d5df88f972b4821579eecd07e4f@trac.tools.ietf.org> References: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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 List-Id: 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, 16 Mar 2011 10:22:03 -0000 #71: Missing description mechanism to make EID-to-RLOC (from D. Papadimitriou's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:22:22 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3275E3A68EE for ; Wed, 16 Mar 2011 03:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 EEl9i98XLRjT for ; Wed, 16 Mar 2011 03:22:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7897D3A68D2 for ; Wed, 16 Mar 2011 03:22:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzntI-00071k-OG; Wed, 16 Mar 2011 03:23: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:23:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/71#comment:2 Message-ID: <077.291aaf3db0428d22c688bb178f1071ab@trac.tools.ietf.org> References: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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 List-Id: 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, 16 Mar 2011 10:22:22 -0000 #71: Missing description mechanism to make EID-to-RLOC (from D. Papadimitriou's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:23:35 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F7D3A6905 for ; Wed, 16 Mar 2011 03:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 TJ4+Hw9K9nFG for ; Wed, 16 Mar 2011 03:23:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E4CFA3A68F7 for ; Wed, 16 Mar 2011 03:23:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PznuV-0000j3-GP; Wed, 16 Mar 2011 03:24: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:24:59 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/81#comment:1 Message-ID: <077.799d1de389d84c7d75526eb74206acce@trac.tools.ietf.org> References: <068.7e4dbe7fbceb8d072eed8b21192d652d@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <068.7e4dbe7fbceb8d072eed8b21192d652d@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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: Wed, 16 Mar 2011 10:23:35 -0000 #81: Implication of deploying of xTRs as first/last hop. Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 03:23:54 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA603A6905 for ; Wed, 16 Mar 2011 03:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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+OPJRQoRGkc for ; Wed, 16 Mar 2011 03:23:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B3E783A6912 for ; Wed, 16 Mar 2011 03:23:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pznup-0001Gj-5W; Wed, 16 Mar 2011 03:25: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 16 Mar 2011 10:25:19 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/81#comment:2 Message-ID: <077.148a0ed12599b3b96fdc4e7fda7436f3@trac.tools.ietf.org> References: <068.7e4dbe7fbceb8d072eed8b21192d652d@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <068.7e4dbe7fbceb8d072eed8b21192d652d@trac.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+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [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: Wed, 16 Mar 2011 10:23:54 -0000 #81: Implication of deploying of xTRs as first/last hop. Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 07:29:25 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93023A6920 for ; Wed, 16 Mar 2011 07:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 jaJLcaRfNVTX for ; Wed, 16 Mar 2011 07:29:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E203A3A6911 for ; Wed, 16 Mar 2011 07:29:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzrkO-0003Zu-T3; Wed, 16 Mar 2011 07:30: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 14:30:48 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/113#comment:4 Message-ID: <065.f7288876fbe3cef2b0d998e627368a97@trac.tools.ietf.org> References: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] #113: inbound traffic engineering support with LISP 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, 16 Mar 2011 14:29:26 -0000 #113: inbound traffic engineering support with LISP Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The issue is still unresolved. Moreover, as I mentioned in my e-mail on 2/15/2011 To add to the above, there should be a detailed description of how TE-xTR perform traffic engineering. This description should be sufficient to address the questions I raised in my e-mail to the LISP WG mailing list on 6/1/2010. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 07:40:13 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30273A695C for ; Wed, 16 Mar 2011 07:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 5bNB-pciAJMM for ; Wed, 16 Mar 2011 07:40:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F1F453A698C for ; Wed, 16 Mar 2011 07:40:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzruX-0000A1-LM; Wed, 16 Mar 2011 07:41: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 14:41:17 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/48#comment:7 Message-ID: <066.884bc93fd296e0abdc16beb43dc861a3@trac.tools.ietf.org> References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 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 List-Id: 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, 16 Mar 2011 14:40:13 -0000 #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: Please point to the specific text that addresses this comment, and specifically describe the consequences if two entities do return MAP- replies with different contents for a given EID -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 07:46:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2333A698E for ; Wed, 16 Mar 2011 07:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 mrBnYzd2XUCc for ; Wed, 16 Mar 2011 07:46:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8EFDC3A6920 for ; Wed, 16 Mar 2011 07:46:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzs0m-0002kg-Da; Wed, 16 Mar 2011 07:47: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 14:47:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/114 Message-ID: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 114 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 16 Mar 2011 09:16:17 -0700 Cc: lisp@ietf.org Subject: [lisp] #114: EID-to-RLOC mapping - transients 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, 16 Mar 2011 14:46:18 -0000 #114: EID-to-RLOC mapping - transients From section 3: EID-to-RLOC Database: The EID-to-RLOC database is 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. During the time period when the EID-to-RLOC mapping changes, and a site has multiple ETRs the spec has to document the procedures by which all the ETRs of a given site "consistently send Map-Reply messages with the same database mapping contents". -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: new Priority: major | Component: alt Severity: - | Keywords: ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 11:52:53 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32DE3A69F4 for ; Wed, 16 Mar 2011 11:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 JGWSt45ksOPk for ; Wed, 16 Mar 2011 11:52:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F22BB3A6A0A for ; Wed, 16 Mar 2011 11:52:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzvrM-0007HB-Sj; Wed, 16 Mar 2011 11:54: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 18:54:16 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/98#comment:3 Message-ID: <066.0d0ac0f7017402f34a46cbe1f8e5babd@trac.tools.ietf.org> References: <057.4c9852b0a65d29853b641f556c39a295@trac.tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <057.4c9852b0a65d29853b641f556c39a295@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 16 Mar 2011 18:52:53 -0000 #98: LISP nonce (comment 17 reported by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: I disagree with the authors' opinion. Thus the ticket is still open -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 11:55:19 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BDA03A6A42 for ; Wed, 16 Mar 2011 11:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 7Lpb2MfyfFWT for ; Wed, 16 Mar 2011 11:55:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E0BD33A6997 for ; Wed, 16 Mar 2011 11:55:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzvtk-0007UB-FE; Wed, 16 Mar 2011 11:56: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 18:56:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/94#comment:3 Message-ID: <066.ddb3fb233edf07a65ec90f7a5780baaa@trac.tools.ietf.org> References: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 16 Mar 2011 18:55:19 -0000 #94: Implications on using Control plane for data forwarding (comment 15 reported by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The issue raised in this ticket has to be addresses. Until this issue is addressed, the ticket should stay open. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 11:56:47 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D5B3A6997 for ; Wed, 16 Mar 2011 11:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NnUSqA9HlqUQ for ; Wed, 16 Mar 2011 11:56:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 255793A6A4A for ; Wed, 16 Mar 2011 11:56:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzvvB-0007Vw-AP; Wed, 16 Mar 2011 11:58: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 18:58:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/90#comment:3 Message-ID: <066.4ede211e4f00ed8ecb7983c8a8889687@trac.tools.ietf.org> References: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.tools.ietf.org> X-Trac-Ticket-ID: 90 In-Reply-To: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 16 Mar 2011 18:56:47 -0000 #90: Restricting re-encapsulation (comment 12 reported by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The question posed in this comment is still not answered.Thus the ticket should stay open until the question is answered. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 11:59:07 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323283A6A4D for ; Wed, 16 Mar 2011 11:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 1YoLaKNF70J0 for ; Wed, 16 Mar 2011 11:59:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4E1C53A6997 for ; Wed, 16 Mar 2011 11:59:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzvxQ-0005Bp-3g; Wed, 16 Mar 2011 12:00: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:00:32 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/89#comment:3 Message-ID: <066.7677b9e804cd32ddf477939f893c4093@trac.tools.ietf.org> References: <057.915c3b2990c494d4d75d76e0f1fee088@trac.tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <057.915c3b2990c494d4d75d76e0f1fee088@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 16 Mar 2011 18:59:07 -0000 #89: On redefining the name of the encapsulated packet header (comment 12 reported by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: the question posed in this ticket is still not answered. Until the question is answered, the ticket should stay as open. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:01:16 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0D83A6A4F for ; Wed, 16 Mar 2011 12:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 OVFiZc1GyJOB for ; Wed, 16 Mar 2011 12:01:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5042F3A6A58 for ; Wed, 16 Mar 2011 12:01:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzvzF-0005eI-DX; Wed, 16 Mar 2011 12:02: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:02:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/84#comment:4 Message-ID: <066.82ce57da6e290d3cfdff868d9bf36580@trac.tools.ietf.org> References: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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, 16 Mar 2011 19:01:16 -0000 #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: I disagree with the authors that "there is no need to make any changes to the draft". I think that the issue raised in this ticket is still not addresses, and therefore the ticket should stay open. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:02:24 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB173A6997 for ; Wed, 16 Mar 2011 12:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 Ix227E3+Vv6E for ; Wed, 16 Mar 2011 12:02:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EB45C3A6974 for ; Wed, 16 Mar 2011 12:02:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzw0c-0005jT-4Y; Wed, 16 Mar 2011 12:03: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:03:50 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/81#comment:3 Message-ID: <077.0ef0b1558dff1012b377b51da8ec7020@trac.tools.ietf.org> References: <068.7e4dbe7fbceb8d072eed8b21192d652d@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <068.7e4dbe7fbceb8d072eed8b21192d652d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Wed, 16 Mar 2011 19:02:24 -0000 #81: Implication of deploying of xTRs as first/last hop. Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: I disagree with the authors that "there is no need to make any change to the draft". The issue raised in this ticket is still not addresses. Until this issue is addressed, the ticket should stay open. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:05:58 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906953A69B1 for ; Wed, 16 Mar 2011 12:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 labOoJ1WCR6E for ; Wed, 16 Mar 2011 12:05:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B56B73A6A60 for ; Wed, 16 Mar 2011 12:05:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzw42-0006S3-CJ; Wed, 16 Mar 2011 12:07: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:07:22 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/71#comment:3 Message-ID: <077.1bc67be664a96a86c452aad4322f5fc7@trac.tools.ietf.org> References: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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 List-Id: 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, 16 Mar 2011 19:05:58 -0000 #71: Missing description mechanism to make EID-to-RLOC (from D. Papadimitriou's review) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: I don't think that the issue raised in this ticket has been addressed. Thus the ticket should stay open. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:07:05 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9140A3A6A38 for ; Wed, 16 Mar 2011 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 fjR6XVrDLVj1 for ; Wed, 16 Mar 2011 12:07:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EAD5E3A68DA for ; Wed, 16 Mar 2011 12:07:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzw59-0006oR-3f; Wed, 16 Mar 2011 12:08:31 -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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:08:31 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/73#comment:3 Message-ID: <077.92669be59eab351021fcd067f03f3b5a@trac.tools.ietf.org> References: <068.11139862467bb967cdc8cf5e6cf8c426@trac.tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <068.11139862467bb967cdc8cf5e6cf8c426@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #73: Tunnel liveness (from R. Bonica review for the RTG directorate) 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, 16 Mar 2011 19:07:05 -0000 #73: Tunnel liveness (from R. Bonica review for the RTG directorate) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The issue raised in this ticket is still not addressed. Thus the ticket must stay open. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:08:38 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED903A6A67 for ; Wed, 16 Mar 2011 12:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 oezj0rLn-a3H for ; Wed, 16 Mar 2011 12:08:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5224E3A68DA for ; Wed, 16 Mar 2011 12:08:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzw6Z-0006qb-N3; Wed, 16 Mar 2011 12:10: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:09:59 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/70#comment:4 Message-ID: <077.75c61fd390081c778b991b847a4ca880@trac.tools.ietf.org> References: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 16 Mar 2011 19:08:38 -0000 #70: Client not respecting RLOC weights (from Y. Rekhter's review) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The issue raised in this ticket is still not addressed. Thus the ticket must stay open. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From jmh@joelhalpern.com Wed Mar 16 12:10:17 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948623A6A67 for ; Wed, 16 Mar 2011 12:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, 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 cqLDh9mA4O7Z for ; Wed, 16 Mar 2011 12:10:17 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id EFE093A6A3C for ; Wed, 16 Mar 2011 12:10:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0EFF14300EA; Wed, 16 Mar 2011 12:11:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 30B3B4300CC; Wed, 16 Mar 2011 12:11:43 -0700 (PDT) Message-ID: <4D810B74.9080906@joelhalpern.com> Date: Wed, 16 Mar 2011 15:11:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp issue tracker References: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> <066.ddb3fb233edf07a65ec90f7a5780baaa@trac.tools.ietf.org> In-Reply-To: <066.ddb3fb233edf07a65ec90f7a5780baaa@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [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 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, 16 Mar 2011 19:10:17 -0000 Yakov, I am confused by your re-opening this issue. The text from the ticket no longer appears in the LISP documents. The LISP ALT document does still have references to forwarding data plane packets through the control plane. That text has explicit warnings that this appears to be a bad idea, and that it should only be done for special tests aimed at verifying that question. If you feel something more is needed in one of the documents, can you please be more specific. Yours, Joel On 3/16/2011 2:56 PM, lisp issue tracker wrote: > #94: Implications on using Control plane for data forwarding (comment 15 > reported by Y. Rekhter) > > Changes (by yakov@…): > > * status: closed => reopened > * resolution: fixed => > > > Comment: > > The issue raised in this ticket has to be addresses. Until this issue is > addressed, the ticket should stay open. > From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:11:20 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6685C3A6A3C for ; Wed, 16 Mar 2011 12:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 SNUvnR7hC3Ne for ; Wed, 16 Mar 2011 12:11:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 721E63A6A63 for ; Wed, 16 Mar 2011 12:11:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzw9F-0005Oc-7m; Wed, 16 Mar 2011 12:12: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:12:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/68#comment:4 Message-ID: <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 16 Mar 2011 19:11:20 -0000 #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The question raised in this ticket is still not answered. Thus the ticket must stay open. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:13:13 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425E53A6A21 for ; Wed, 16 Mar 2011 12:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 W+mYrKRfhDo9 for ; Wed, 16 Mar 2011 12:13:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 94BCB3A69CA for ; Wed, 16 Mar 2011 12:13:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwB4-0007Mu-Pu; Wed, 16 Mar 2011 12:14: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:14:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:5 Message-ID: <077.a1eb4533e7637d61511fd172507aa653@trac.tools.ietf.org> References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 16 Mar 2011 19:13:13 -0000 #66: Strict RLOC ordering causing problems on mapping changes Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The issues raised in this ticket are still not addressed. Therefore the ticket should stay open. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From dino@cisco.com Wed Mar 16 12:19:10 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59A83A6A4F for ; Wed, 16 Mar 2011 12:19:10 -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 IQ95NeIgJyYu for ; Wed, 16 Mar 2011 12:19:07 -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 506F83A69FF for ; Wed, 16 Mar 2011 12:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1520; q=dns/txt; s=iport; t=1300303234; x=1301512834; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=WYS5f+JxIerZAHH/vaEvk5tgclNNnSAqnZE1es0EzD8=; b=Grjj36PtLPDiJCi/eUC2zsZXinx84J10giICemG5lfikiw71MZM6D/Ew jI3kLRmsC3zyMUaTMc+cIJdtrNMXyRTtZpHyrPMnfg6Y83oBlHryt2beP 5efSafkPIj5RdIRNE2Qi9EI4DBWKiTe2CF9NVbL48GeDcYlQ2i5CL+jHU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALaqgE2tJV2Y/2dsb2JhbACmDHelS5xXhWMEhS+HL4NN X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="321047820" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2011 19:20:33 +0000 Received: from [192.168.1.2] (sjc-vpn7-1011.cisco.com [10.21.147.243]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2GJKX3t021715; Wed, 16 Mar 2011 19:20:33 GMT Message-Id: <65DEB688-E7D8-4593-AA83-54D28E860D37@cisco.com> From: Dino Farinacci To: "lisp issue tracker" In-Reply-To: <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> 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: Wed, 16 Mar 2011 12:20:32 -0700 References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> X-Mailer: Apple Mail (2.936) 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 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, 16 Mar 2011 19:19:11 -0000 > #68: What is the source address for a negative reply, which has a =20 > zero length > locator -set ? (from Y. Rekhter's review) The originator's IP address is the source of the Map-Reply. In the =20 case of a positive Map-Reply from the ETR, it is the ETR's IP address =20= in the case of a negative Map-Reply, it is the Map-Resolver's IP =20 address. This is basic IP packet origination, so I am not sure what you are =20 really getting at. Please be more specific. Dino > > Changes (by yakov@=85): > > * status: closed =3D> reopened > * resolution: fixed =3D> > > > Comment: > > The question raised in this ticket is still not answered. Thus the =20 > ticket > must stay open. > > --=20 > ------------------------------------------=20 > +--------------------------------- > Reporter: luigi@=85 | Owner: > Type: technical | Status: reopened > Priority: major | Component: draft-=20 > ietf-lisp > Severity: - | Resolution: > Keywords: | > ------------------------------------------=20 > +--------------------------------- > > Ticket URL: = > > lisp > LISP WG document issues > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:22:59 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3097E3A6A85 for ; Wed, 16 Mar 2011 12:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 JRJ55PgAA9KF for ; Wed, 16 Mar 2011 12:22:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CB3A23A6A8A for ; Wed, 16 Mar 2011 12:22:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwKV-0000F7-HM; Wed, 16 Mar 2011 12:24: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:24:23 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/63#comment:5 Message-ID: <077.24cdc6c1462800d2f9870501761e7619@trac.tools.ietf.org> References: <068.d92e7478bf86c421ac2f1228852f774a@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <068.d92e7478bf86c421ac2f1228852f774a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 16 Mar 2011 19:22:59 -0000 #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The new draft still does not fully address the issue raised in this ticket. To close this ticket the authors should replace Another disadvantage of using anycast locators is the limited advertisement scope of /32 (or /128 for IPv6) routes. with the following: 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. Thus to avoid negative implications on routing scalability use of anycast addresses as RLOCs for CEs should be constrained to only the CEs connected to the same ISP. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:25:15 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587013A6A73 for ; Wed, 16 Mar 2011 12:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 gw7cKSzxHJrC for ; Wed, 16 Mar 2011 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 7B2E53A6A60 for ; Wed, 16 Mar 2011 12:25:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwMi-0005zp-Gy; Wed, 16 Mar 2011 12:26: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:26:40 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/57#comment:4 Message-ID: <077.7b96f395f01ba901f4002744f0439a9f@trac.tools.ietf.org> References: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 16 Mar 2011 19:25:15 -0000 #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: In order to close this ticket the authors should answer the question raised in this ticket. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:26:27 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8754B3A6A73 for ; Wed, 16 Mar 2011 12:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 FAnVGQjJ6OBk for ; Wed, 16 Mar 2011 12:26:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C52333A6A60 for ; Wed, 16 Mar 2011 12:26:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwNt-00086w-02; Wed, 16 Mar 2011 12:27: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:27:52 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/53#comment:3 Message-ID: <066.eef83fffd49a57650d55630f581980a1@trac.tools.ietf.org> References: <057.cd86d557ebd472d3854de590d8c2facd@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <057.cd86d557ebd472d3854de590d8c2facd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #53: Reachability between ETR and EID (review 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, 16 Mar 2011 19:26:27 -0000 #53: Reachability between ETR and EID (review by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: In order to close the ticket the authors need to answer the question raised in the ticket. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From jmh@joelhalpern.com Wed Mar 16 12:28:09 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE7C3A69CA for ; Wed, 16 Mar 2011 12:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, 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 7Vie2MKGwsSV for ; Wed, 16 Mar 2011 12:28:08 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 32D143A6A60 for ; Wed, 16 Mar 2011 12:28:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5742E4300CC; Wed, 16 Mar 2011 12:29:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 88FE443001A; Wed, 16 Mar 2011 12:29:34 -0700 (PDT) Message-ID: <4D810FA4.3010206@joelhalpern.com> Date: Wed, 16 Mar 2011 15:29:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dino Farinacci References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> <65DEB688-E7D8-4593-AA83-54D28E860D37@cisco.com> In-Reply-To: <65DEB688-E7D8-4593-AA83-54D28E860D37@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp issue tracker , 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 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, 16 Mar 2011 19:28:09 -0000 Yakov, Would it suffice to add a sentence to the end of section 6.1.5 along the lines of: In the case of a Negative Map Reply sent from the mapping system, the source IP address will be the IP address of the device sending the reply, rather than being a valid RLOC, since there are no valid RLOCs returned. ? Yours, Joel On 3/16/2011 3:20 PM, Dino Farinacci wrote: >> #68: What is the source address for a negative reply, which has a zero >> length >> locator -set ? (from Y. Rekhter's review) > > The originator's IP address is the source of the Map-Reply. In the case > of a positive Map-Reply from the ETR, it is the ETR's IP address in the > case of a negative Map-Reply, it is the Map-Resolver's IP address. > > This is basic IP packet origination, so I am not sure what you are > really getting at. Please be more specific. > > Dino > >> >> Changes (by yakov@…): >> >> * status: closed => reopened >> * resolution: fixed => >> >> >> Comment: >> >> The question raised in this ticket is still not answered. Thus the ticket >> must stay open. >> >> -- >> ------------------------------------------+--------------------------------- >> >> Reporter: luigi@… | Owner: >> Type: technical | Status: reopened >> Priority: major | Component: draft-ietf-lisp >> Severity: - | Resolution: >> Keywords: | >> ------------------------------------------+--------------------------------- >> >> >> Ticket URL: >> >> lisp >> LISP WG document issues >> _______________________________________________ >> 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 trac+lisp@trac.tools.ietf.org Wed Mar 16 12:28:38 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9C53A69CA for ; Wed, 16 Mar 2011 12:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 GigYlB9imGUp for ; Wed, 16 Mar 2011 12:28:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6CF843A6A78 for ; Wed, 16 Mar 2011 12:28:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwPz-0004VD-KO; Wed, 16 Mar 2011 12:30: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:30:03 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/50#comment:3 Message-ID: <066.8af61ed92774ee62bf84b7b9e926ea0e@trac.tools.ietf.org> References: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #50: MAP-Replies content that MUST be invariant (review 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, 16 Mar 2011 19:28:38 -0000 #50: MAP-Replies content that MUST be invariant (review by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: In order to close the issue please point to the text that has been modified to fix the issue. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:30:04 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5E43A69CA for ; Wed, 16 Mar 2011 12:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 dKwAr+L47Cdv for ; Wed, 16 Mar 2011 12:29:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7A1A93A6A58 for ; Wed, 16 Mar 2011 12:29:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwRI-0002eS-LZ; Wed, 16 Mar 2011 12: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:31:24 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/49#comment:3 Message-ID: <066.9837195cf0bd27ed0876b99e0bfa3a03@trac.tools.ietf.org> References: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #49: "MAP-Replies" content that is allowed to change (review 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, 16 Mar 2011 19:30:04 -0000 #49: "MAP-Replies" content that is allowed to change (review by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: Before closing the issue please point to the text that has been modified to address the issue. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:31:44 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB4E3A6A7B for ; Wed, 16 Mar 2011 12:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 TOllH-Z1IVO7 for ; Wed, 16 Mar 2011 12:31:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 704BD3A69CA for ; Wed, 16 Mar 2011 12:31:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwSx-0000oJ-QL; Wed, 16 Mar 2011 12:33: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:33:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/47#comment:4 Message-ID: <066.49bf97001c2e2829a228e309cf69929d@trac.tools.ietf.org> References: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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, 16 Mar 2011 19:31:44 -0000 #47: Ambiguity on "MAP-replies" requirements (review by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: Until the authors point to the text that addresses the issue raised in the ticket, the ticket should stay open. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:32:55 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4441B3A6A0C for ; Wed, 16 Mar 2011 12:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 O0KeuH8gW6TW for ; Wed, 16 Mar 2011 12:32:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2BD433A6974 for ; Wed, 16 Mar 2011 12:32:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwU3-0003EO-S2; Wed, 16 Mar 2011 12:34: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:34:15 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/46#comment:4 Message-ID: <066.e0ceb180b05579aaafc4e87dadd6ebd2@trac.tools.ietf.org> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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, 16 Mar 2011 19:32:55 -0000 #46: Cache Thrashing (review by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The issue raised in this ticket has to be addresses. Until it is addressed, the ticket should stay open. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From dino@cisco.com Wed Mar 16 12:33:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8993A69FF for ; Wed, 16 Mar 2011 12:33: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 Pjsi9C5n9Yih for ; Wed, 16 Mar 2011 12:33:39 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B5B503A6974 for ; Wed, 16 Mar 2011 12:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2635; q=dns/txt; s=iport; t=1300304106; x=1301513706; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=kcpi32XJUMcSI8/DStWXWaYNm7RCY7d/KtCRJdzWz0s=; b=VXU27X4PCyi5GY4PB5sXqFPrm6Y99bdq035npIJ84GtoVapSQEnsJT1C D9B7EOH5aeWO+DzeOppn6pYZKC86gTKeXSh+y4JkQ2AGsR7W8RJTJbhm5 GevZHFJO+rx1eGi8A0io/UWIDjpDKF5PztS/WHe/i5JKt3yKRJGsMK6B5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIetgE2tJV2b/2dsb2JhbACmDHelYpxXhWMEhS+HL4NN X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="226284591" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2011 19:35:06 +0000 Received: from [192.168.1.2] (sjc-vpn7-1011.cisco.com [10.21.147.243]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2GJZ5Zx000342; Wed, 16 Mar 2011 19:35:05 GMT Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4D810FA4.3010206@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: Wed, 16 Mar 2011 12:35:04 -0700 References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> <65DEB688-E7D8-4593-AA83-54D28E860D37@cisco.com> <4D810FA4.3010206@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , 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 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, 16 Mar 2011 19:33:40 -0000 > Yakov, > Would it suffice to add a sentence to the end of section 6.1.5 =20 > along the lines of: > In the case of a Negative Map Reply sent from the mapping system, =20 > the source IP address will be the IP address of the device sending =20 > the reply, rather than being a valid RLOC, since there are no valid =20= > RLOCs returned. Joel, the source address selection has nothing to do with the contents =20= of the control message. So why call this out specifically and make the =20= document unreadable and block the flow of continuity. What should the source address be for a positive Map-Reply? What should the source address be for a drop-action Map-Reply? What should the source address be when there are multiple EID records? Why shouldn't those among the other 100s of combinations be included =20 as well? The answer is the same for all questions, *the originator of the =20 control message*. Dino > > ? > Yours, > Joel > > On 3/16/2011 3:20 PM, Dino Farinacci wrote: >>> #68: What is the source address for a negative reply, which has a =20= >>> zero >>> length >>> locator -set ? (from Y. Rekhter's review) >> >> The originator's IP address is the source of the Map-Reply. In the =20= >> case >> of a positive Map-Reply from the ETR, it is the ETR's IP address in =20= >> the >> case of a negative Map-Reply, it is the Map-Resolver's IP address. >> >> This is basic IP packet origination, so I am not sure what you are >> really getting at. Please be more specific. >> >> Dino >> >>> >>> Changes (by yakov@=85): >>> >>> * status: closed =3D> reopened >>> * resolution: fixed =3D> >>> >>> >>> Comment: >>> >>> The question raised in this ticket is still not answered. Thus the =20= >>> ticket >>> must stay open. >>> >>> -- >>> ------------------------------------------=20 >>> +--------------------------------- >>> >>> Reporter: luigi@=85 | Owner: >>> Type: technical | Status: reopened >>> Priority: major | Component: draft-ietf-lisp >>> Severity: - | Resolution: >>> Keywords: | >>> ------------------------------------------=20 >>> +--------------------------------- >>> >>> >>> Ticket URL: >>> >>> lisp >>> LISP WG document issues >>> _______________________________________________ >>> 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 trac+lisp@trac.tools.ietf.org Wed Mar 16 12:34:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD503A69CF for ; Wed, 16 Mar 2011 12:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 cWEIrY3xbepi for ; Wed, 16 Mar 2011 12:34:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 70ABA3A6A67 for ; Wed, 16 Mar 2011 12:34:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwVM-0006Ne-0j; Wed, 16 Mar 2011 12:35: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:35:36 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/45#comment:3 Message-ID: <066.509b26d28d345b9d15292ec991955c33@trac.tools.ietf.org> References: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #45: LISP vs. Existing (from 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, 16 Mar 2011 19:34:12 -0000 #45: LISP vs. Existing (from Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: In order to close the ticket the authors should point to the text that answers the question raised in the ticket. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 12:35:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5D03A6A5A for ; Wed, 16 Mar 2011 12:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 5eLshHSEc1Zr for ; Wed, 16 Mar 2011 12:35:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E5CBB3A6A67 for ; Wed, 16 Mar 2011 12:35:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwWM-00006m-BY; Wed, 16 Mar 2011 12:36: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:36:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/44#comment:5 Message-ID: <066.084e1eb94200f3deba594431cd886d8c@trac.tools.ietf.org> References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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, 16 Mar 2011 19:35:18 -0000 #44: LISP vs existing (reported by Yakov Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: In order to close the ticket the authors need to point to the text that answers the question raised in the ticket. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From jmh@joelhalpern.com Wed Mar 16 12:39:45 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AA33A6A84 for ; Wed, 16 Mar 2011 12:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, 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 R3ProWvJkQ-d for ; Wed, 16 Mar 2011 12:39:44 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 468393A6A76 for ; Wed, 16 Mar 2011 12:39:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 691D64300D2; Wed, 16 Mar 2011 12:41:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 8D91543001A; Wed, 16 Mar 2011 12:41:10 -0700 (PDT) Message-ID: <4D811258.4050902@joelhalpern.com> Date: Wed, 16 Mar 2011 15:41:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dino Farinacci References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> <65DEB688-E7D8-4593-AA83-54D28E860D37@cisco.com> <4D810FA4.3010206@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp issue tracker , 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 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, 16 Mar 2011 19:39:45 -0000 The reason is that the text in the last paragraph of 6.1.5 says "The source address of the Map_reply is one of the local locator addresses listed in the locator set of any mapping record in teh message ..." The document makes a point of talking about the source adress here. That raises the question of what happens in the corner case when the reply has not locator sets. Yours, Joel On 3/16/2011 3:35 PM, Dino Farinacci wrote: >> Yakov, >> Would it suffice to add a sentence to the end of section 6.1.5 along >> the lines of: >> In the case of a Negative Map Reply sent from the mapping system, the >> source IP address will be the IP address of the device sending the >> reply, rather than being a valid RLOC, since there are no valid RLOCs >> returned. > > Joel, the source address selection has nothing to do with the contents > of the control message. So why call this out specifically and make the > document unreadable and block the flow of continuity. > > What should the source address be for a positive Map-Reply? > What should the source address be for a drop-action Map-Reply? > What should the source address be when there are multiple EID records? > > Why shouldn't those among the other 100s of combinations be included as > well? > > The answer is the same for all questions, *the originator of the control > message*. > > Dino > >> >> ? >> Yours, >> Joel >> >> On 3/16/2011 3:20 PM, Dino Farinacci wrote: >>>> #68: What is the source address for a negative reply, which has a zero >>>> length >>>> locator -set ? (from Y. Rekhter's review) >>> >>> The originator's IP address is the source of the Map-Reply. In the case >>> of a positive Map-Reply from the ETR, it is the ETR's IP address in the >>> case of a negative Map-Reply, it is the Map-Resolver's IP address. >>> >>> This is basic IP packet origination, so I am not sure what you are >>> really getting at. Please be more specific. >>> >>> Dino >>> >>>> >>>> Changes (by yakov@…): >>>> >>>> * status: closed => reopened >>>> * resolution: fixed => >>>> >>>> >>>> Comment: >>>> >>>> The question raised in this ticket is still not answered. Thus the >>>> ticket >>>> must stay open. >>>> >>>> -- >>>> ------------------------------------------+--------------------------------- >>>> >>>> >>>> Reporter: luigi@… | Owner: >>>> Type: technical | Status: reopened >>>> Priority: major | Component: draft-ietf-lisp >>>> Severity: - | Resolution: >>>> Keywords: | >>>> ------------------------------------------+--------------------------------- >>>> >>>> >>>> >>>> Ticket URL: >>>> >>>> lisp >>>> LISP WG document issues >>>> _______________________________________________ >>>> 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 Wed Mar 16 12:43:17 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BB33A6A9A for ; Wed, 16 Mar 2011 12:43:17 -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 J1PMlTA3Fc8r for ; Wed, 16 Mar 2011 12:43:16 -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 263C13A6A67 for ; Wed, 16 Mar 2011 12:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=3471; q=dns/txt; s=iport; t=1300304683; x=1301514283; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=TZS7xcpOWobMz3nKEy81Z2SRErzo8x6mo0zg9gS4gH0=; b=cIRevP9KG1nPb/tWF+VSMxMAda+kX13v8ZetF4r4+0ui8eayElV6ftZb eND4AoJFNitmWZXXD9ZeW7eiP02wH9x98klZ9Egio46hdyH29QEIJmYDd HjW1UAJE7yn7Qnh6xq2ItlJoBEPDUZazXtRmdFomD/cjrRDDUqOWcHDpR I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFewgE2tJXG9/2dsb2JhbACmDHele5xYhWMEhS+HL4NN X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="415094948" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 16 Mar 2011 19:44:42 +0000 Received: from [192.168.1.2] (sjc-vpn7-1011.cisco.com [10.21.147.243]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2GJifJT012072; Wed, 16 Mar 2011 19:44:42 GMT Message-Id: <3907CCB8-F359-43C5-8709-B80A59F16FAC@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4D811258.4050902@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: Wed, 16 Mar 2011 12:44:41 -0700 References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> <65DEB688-E7D8-4593-AA83-54D28E860D37@cisco.com> <4D810FA4.3010206@joelhalpern.com> <4D811258.4050902@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , 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 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, 16 Mar 2011 19:43:17 -0000 > The reason is that the text in the last paragraph of 6.1.5 says "The =20= > source address of the Map_reply is one of the local locator =20 > addresses listed in the locator set of any mapping record in teh =20 > message ..." Oh, if Yakov would have pointed that out, we could have fixed it ASAP. > The document makes a point of talking about the source adress here. =20= > That raises the question of what happens in the corner case when the =20= > reply has not locator sets. Consider it fixed in the next version. Dino > > Yours, > Joel > > On 3/16/2011 3:35 PM, Dino Farinacci wrote: >>> Yakov, >>> Would it suffice to add a sentence to the end of section 6.1.5 along >>> the lines of: >>> In the case of a Negative Map Reply sent from the mapping system, =20= >>> the >>> source IP address will be the IP address of the device sending the >>> reply, rather than being a valid RLOC, since there are no valid =20 >>> RLOCs >>> returned. >> >> Joel, the source address selection has nothing to do with the =20 >> contents >> of the control message. So why call this out specifically and make =20= >> the >> document unreadable and block the flow of continuity. >> >> What should the source address be for a positive Map-Reply? >> What should the source address be for a drop-action Map-Reply? >> What should the source address be when there are multiple EID =20 >> records? >> >> Why shouldn't those among the other 100s of combinations be =20 >> included as >> well? >> >> The answer is the same for all questions, *the originator of the =20 >> control >> message*. >> >> Dino >> >>> >>> ? >>> Yours, >>> Joel >>> >>> On 3/16/2011 3:20 PM, Dino Farinacci wrote: >>>>> #68: What is the source address for a negative reply, which has =20= >>>>> a zero >>>>> length >>>>> locator -set ? (from Y. Rekhter's review) >>>> >>>> The originator's IP address is the source of the Map-Reply. In =20 >>>> the case >>>> of a positive Map-Reply from the ETR, it is the ETR's IP address =20= >>>> in the >>>> case of a negative Map-Reply, it is the Map-Resolver's IP address. >>>> >>>> This is basic IP packet origination, so I am not sure what you are >>>> really getting at. Please be more specific. >>>> >>>> Dino >>>> >>>>> >>>>> Changes (by yakov@=85): >>>>> >>>>> * status: closed =3D> reopened >>>>> * resolution: fixed =3D> >>>>> >>>>> >>>>> Comment: >>>>> >>>>> The question raised in this ticket is still not answered. Thus the >>>>> ticket >>>>> must stay open. >>>>> >>>>> -- >>>>> ------------------------------------------=20 >>>>> +--------------------------------- >>>>> >>>>> >>>>> Reporter: luigi@=85 | Owner: >>>>> Type: technical | Status: reopened >>>>> Priority: major | Component: draft-ietf-lisp >>>>> Severity: - | Resolution: >>>>> Keywords: | >>>>> ------------------------------------------=20 >>>>> +--------------------------------- >>>>> >>>>> >>>>> >>>>> Ticket URL: >>>>> >>>>> lisp >>>>> LISP WG document issues >>>>> _______________________________________________ >>>>> 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 trac+lisp@trac.tools.ietf.org Wed Mar 16 12:51:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA253A6AA9 for ; Wed, 16 Mar 2011 12:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 ebAobiG-nE4X for ; Wed, 16 Mar 2011 12:50:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C89983A6A84 for ; Wed, 16 Mar 2011 12:50:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzwld-0001R5-CK; Wed, 16 Mar 2011 12:52: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 19:52:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/42#comment:5 Message-ID: <077.e3a7c9ddc768a677bfac7781b80a2239@trac.tools.ietf.org> References: <068.949be01828216d93bdf1e485048b2d40@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <068.949be01828216d93bdf1e485048b2d40@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 16 Mar 2011 19:51:00 -0000 #42: On the SMR mechanism Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The new text is still inadequate: Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data to for the last minute. In particular, an ETR will send an SMR an ITR to which it has recently sent encapsulated data. "recently" in the last sentence above needs to be quantified. What is the meaning of "solicit Map-Requests from those sites" ? Does it mean soliciting it from all the xTRs of a given site, or only some ? 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. "more secure" relative to what ? What is the justification for this assumption about the mapping database's security? -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 13:00:57 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9923A6AAC for ; Wed, 16 Mar 2011 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 iQ-GJ9ipbUFg for ; Wed, 16 Mar 2011 13:00:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DAE263A6A39 for ; Wed, 16 Mar 2011 13:00:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzwvG-0008JS-QI; Wed, 16 Mar 2011 13:02: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 20:02:22 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:3 Message-ID: <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #27: ETR may claim a larger prefix than is delegated to it 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, 16 Mar 2011 20:00:57 -0000 #27: ETR may claim a larger prefix than is delegated to it Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: Before closing the ticket please document how the issue raised by the ticket is resolved. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 13:02:36 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9D03A6A84 for ; Wed, 16 Mar 2011 13:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 1vY6gcovPilZ for ; Wed, 16 Mar 2011 13:02:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9C5363A6A39 for ; Wed, 16 Mar 2011 13:02:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzwwr-0008Rw-Fp; Wed, 16 Mar 2011 13:04: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 20:04:01 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/111#comment:3 Message-ID: <065.054990090bbf37f55e1f390b47f7c309@trac.tools.ietf.org> References: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #111: Semantics of LSB 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, 16 Mar 2011 20:02:36 -0000 #111: Semantics of LSB Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: In order to close the ticket the authors have to answer the question raised by the ticket. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 16 13:09:59 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5D83A69DC for ; Wed, 16 Mar 2011 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 uslnOCXCMA3e for ; Wed, 16 Mar 2011 13:09:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A39113A69BF for ; Wed, 16 Mar 2011 13:09:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pzx40-0007wN-L7; Wed, 16 Mar 2011 13:11: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 20:11:24 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/101#comment:3 Message-ID: <066.796debec96b5f11604b0c0eb5e65e7a4@trac.tools.ietf.org> References: <057.0e0d4458c9205c12214b19f32a304af1@trac.tools.ietf.org> X-Trac-Ticket-ID: 101 In-Reply-To: <057.0e0d4458c9205c12214b19f32a304af1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 16 Mar 2011 20:09:59 -0000 #101: Filtering ICMP messages (comment 19 reported by Y. Rekhter) Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: The issues raised in this ticket are still not addressed. Until these issues are addressed, the ticket should stay open. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From yakov@juniper.net Wed Mar 16 13:17:06 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F543A69D9 for ; Wed, 16 Mar 2011 13:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 OgDyKqCIBkbD for ; Wed, 16 Mar 2011 13:17:05 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 4B0FF3A6997 for ; Wed, 16 Mar 2011 13:17:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTYEbECQobJPbTp/UupGQ0KfdgbdwxMb/@postini.com; Wed, 16 Mar 2011 13:18:32 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Mar 2011 13:14:30 -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 p2GKFcv86229; Wed, 16 Mar 2011 13:15:38 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103162015.p2GKFcv86229@magenta.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4D810FA4.3010206@joelhalpern.com> References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> <65DEB688-E7D8-4593-AA83-54D28E860D37@cisco.com> <4D810FA4.3010206@joelhalpern.com> X-MH-In-Reply-To: "Joel M. Halpern" message dated "Wed, 16 Mar 2011 15:29:40 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <58009.1300306537.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 13:15:38 -0700 From: Yakov Rekhter Cc: lisp issue tracker , 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 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, 16 Mar 2011 20:17:06 -0000 Joel, > Yakov, > Would it suffice to add a sentence to the end of section 6.1.5 = > along the lines of: > In the case of a Negative Map Reply sent from the mapping system, the = > source IP address will be the IP address of the device sending the = > reply, rather than being a valid RLOC, since there are no valid RLOCs = > returned. Yes, as the text you proposed above would answer the question = raised in the ticket. Yakov. > = > ? > Yours, > Joel > = > On 3/16/2011 3:20 PM, Dino Farinacci wrote: > >> #68: What is the source address for a negative reply, which has a zer= o > >> length > >> locator -set ? (from Y. Rekhter's review) > > > > The originator's IP address is the source of the Map-Reply. In the cas= e > > of a positive Map-Reply from the ETR, it is the ETR's IP address in th= e > > case of a negative Map-Reply, it is the Map-Resolver's IP address. > > > > This is basic IP packet origination, so I am not sure what you are > > really getting at. Please be more specific. > > > > Dino > > > >> > >> Changes (by yakov@=85): > >> > >> * status: closed =3D> reopened > >> * resolution: fixed =3D> > >> > >> > >> Comment: > >> > >> The question raised in this ticket is still not answered. Thus the ti= cket > >> must stay open. > >> > >> -- > >> ------------------------------------------+--------------------------= ----- -- > >> > >> Reporter: luigi@=85 | Owner: > >> Type: technical | Status: reopened > >> Priority: major | Component: draft-ietf-lisp > >> Severity: - | Resolution: > >> Keywords: | > >> ------------------------------------------+--------------------------= ----- -- > >> > >> > >> Ticket URL: > >> > >> lisp > >> LISP WG document issues > >> _______________________________________________ > >> 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 Wed Mar 16 13:20:50 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DADA3A69E5 for ; Wed, 16 Mar 2011 13:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.274 X-Spam-Level: X-Spam-Status: No, score=-106.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ydqOB3N0TyBH for ; Wed, 16 Mar 2011 13:20:49 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 815743A69D8 for ; Wed, 16 Mar 2011 13:20:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTYEb9F4p+MkjmUS5KuwN37E4L/ctUBsh@postini.com; Wed, 16 Mar 2011 13:22:16 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Mar 2011 13:17:58 -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 p2GKJ7v87419; Wed, 16 Mar 2011 13:19:07 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103162019.p2GKJ7v87419@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <3907CCB8-F359-43C5-8709-B80A59F16FAC@cisco.com> References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> <65DEB688-E7D8-4593-AA83-54D28E860D37@cisco.com> <4D810FA4.3010206@joelhalpern.com> <4D811258.4050902@joelhalpern.com> <3907CCB8-F359-43C5-8709-B80A59F16FAC@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Wed, 16 Mar 2011 12:44:41 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <58227.1300306746.1@juniper.net> Date: Wed, 16 Mar 2011 13:19:06 -0700 From: Yakov Rekhter Cc: lisp issue tracker , 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 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, 16 Mar 2011 20:20:50 -0000 Dino, > > The reason is that the text in the last paragraph of 6.1.5 says "The > > source address of the Map_reply is one of the local locator > > addresses listed in the locator set of any mapping record in teh > > message ..." > > Oh, if Yakov would have pointed that out, we could have fixed it ASAP. I did point this out. From my original comment: 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 ? > > The document makes a point of talking about the source adress here. > > That raises the question of what happens in the corner case when the > > reply has not locator sets. > > Consider it fixed in the next version. Yakov. From trac+lisp@trac.tools.ietf.org Wed Mar 16 13:29:37 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E193A6919 for ; Wed, 16 Mar 2011 13:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GaoGPukgPmEq for ; Wed, 16 Mar 2011 13:29:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DEA6C3A67EE for ; Wed, 16 Mar 2011 13:29:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzxN0-0001Jm-Qo; Wed, 16 Mar 2011 13:31: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 16 Mar 2011 20:31:02 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/94#comment:4 Message-ID: <066.737889092302ed931e36d535f906dc3d@trac.tools.ietf.org> References: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 16 Mar 2011 20:29:37 -0000 #94: Implications on using Control plane for data forwarding (comment 15 reported by Y. Rekhter) Changes (by yakov@…): * status: reopened => resolved * resolution: => fixed Comment: The ticket should be closed as the text quoted in the ticket has been removed. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From dino@cisco.com Wed Mar 16 13:31:45 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD3F3A69D8 for ; Wed, 16 Mar 2011 13:31:45 -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 XyjvZwl6msMc for ; Wed, 16 Mar 2011 13:31:44 -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 D3AE83A69D6 for ; Wed, 16 Mar 2011 13:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1368; q=dns/txt; s=iport; t=1300307592; x=1301517192; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=pILk3lFQz0q//LEuZAEQO63p25+w+jdz914ogsA8qsc=; b=J4vqaoY0B0oSn834ENNe3/aPaynhmGTqz/Qa2imainu0gPS+WeNxPaJf EhQl1gD74BWObMCFRYlBdrnoWrVMFJmDiAiqrAV6j5mViHRGDguLuB9+M 385ZppY6hKf1+n1apWkAitZTfMnSdoqG2YyHyd+RN4KAnS83TSfZ6Nys+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFy7gE2tJV2Z/2dsb2JhbACmDHeleZxOhWMEhS+HL4NN X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="667846201" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2011 20:33:11 +0000 Received: from [192.168.1.2] (sjc-vpn7-1011.cisco.com [10.21.147.243]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2GKXAtP013415; Wed, 16 Mar 2011 20:33:10 GMT Message-Id: From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201103162019.p2GKJ7v87419@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, 16 Mar 2011 13:33:10 -0700 References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> <077.5aff7478347f2918690b5d6e739ebae9@trac.tools.ietf.org> <65DEB688-E7D8-4593-AA83-54D28E860D37@cisco.com> <4D810FA4.3010206@joelhalpern.com> <4D811258.4050902@joelhalpern.com> <3907CCB8-F359-43C5-8709-B80A59F16FAC@cisco.com> <201103162019.p2GKJ7v87419@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , 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 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, 16 Mar 2011 20:31:45 -0000 Then we missed it in the 100s of comments we received. We will fix it. Please be specific on the other items you think we did not fix. Dino On Mar 16, 2011, at 1:19 PM, Yakov Rekhter wrote: > Dino, > >>> The reason is that the text in the last paragraph of 6.1.5 says "The >>> source address of the Map_reply is one of the local locator >>> addresses listed in the locator set of any mapping record in teh >>> message ..." >> >> Oh, if Yakov would have pointed that out, we could have fixed it >> ASAP. > > I did point this out. From my original comment: > > 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 ? > >>> The document makes a point of talking about the source adress here. >>> That raises the question of what happens in the corner case when the >>> reply has not locator sets. >> >> Consider it fixed in the next version. > > Yakov. From yakov@juniper.net Wed Mar 16 13:31:55 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9CB3A69E2 for ; Wed, 16 Mar 2011 13:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.339 X-Spam-Level: X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 yKTwHRYaVhLe for ; Wed, 16 Mar 2011 13:31:54 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 93A013A699F for ; Wed, 16 Mar 2011 13:31:52 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTYEeiveOQVYl+srARJqzGjsGIjHKSviL@postini.com; Wed, 16 Mar 2011 13:33:21 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Mar 2011 13:30:25 -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 p2GKVWv93352; Wed, 16 Mar 2011 13:31:32 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103162031.p2GKVWv93352@magenta.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4D810B74.9080906@joelhalpern.com> References: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> <066.ddb3fb233edf07a65ec90f7a5780baaa@trac.tools.ietf.org> <4D810B74.9080906@joelhalpern.com> X-MH-In-Reply-To: "Joel M. Halpern" message dated "Wed, 16 Mar 2011 15:11:48 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <58812.1300307492.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 13:31:32 -0700 From: Yakov Rekhter Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [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 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, 16 Mar 2011 20:31:55 -0000 Joel, > Yakov, I am confused by your re-opening this issue. > The text from the ticket no longer appears in the LISP documents. It would be very helpful if the ticket would just say this. > The LISP ALT document does still have references to forwarding data = > plane packets through the control plane. That text has explicit = > warnings that this appears to be a bad idea, and that it should only be = > done for special tests aimed at verifying that question. > = > If you feel something more is needed in one of the documents, can you = > please be more specific. I just closed the ticket. Yakov. > = > Yours, > Joel > = > On 3/16/2011 2:56 PM, lisp issue tracker wrote: > > #94: Implications on using Control plane for data forwarding (comment = 15 > > reported by Y. Rekhter) > > > > Changes (by yakov@=E2=80=A6): > > > > * status: closed =3D> reopened > > * resolution: fixed =3D> > > > > > > Comment: > > > > The issue raised in this ticket has to be addresses. Until this issu= e is > > addressed, the ticket should stay open. > > From luigi@net.t-labs.tu-berlin.de Thu Mar 17 07:16:57 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1333A693F for ; Thu, 17 Mar 2011 07:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qRU0gkZCgScu for ; Thu, 17 Mar 2011 07:16:56 -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 6A7CD3A68AD for ; Thu, 17 Mar 2011 07:16:56 -0700 (PDT) Received: from dyn108.net.t-labs.tu-berlin.de (dyn108.net.t-labs.tu-berlin.de [130.149.220.108]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 7AE0D701F6A1; Thu, 17 Mar 2011 15:18:23 +0100 (CET) From: Luigi Iannone Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-28--58244153 Date: Thu, 17 Mar 2011 15:18:22 +0100 In-Reply-To: <066.4ede211e4f00ed8ecb7983c8a8889687@trac.tools.ietf.org> To: lisp@ietf.org, Yakov Rekhter References: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.tools.ietf.org> <066.4ede211e4f00ed8ecb7983c8a8889687@trac.tools.ietf.org> Message-Id: X-Mailer: Apple Mail (2.1082) Subject: [lisp] Re-opened issues (and further discussion) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 14:16:58 -0000 --Apple-Mail-28--58244153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yakov, Let me summarize in this mail a large part of the re-opened issues, so = to avoid to send multiple emails with the same content. What follows is a list of the re-opened issues and a link to the email = that provided an answer to the issue. All emails are dated july/august 2010.=20 IMHO and in order to progress, the original author of the issue (is not = always you) should clearly state why he is not satisfied with the = provided answer (even better would be to suggest text and corrections). Hope the following links will help in re-start the discussion and make = progress. Luigi -- Re: [lisp] #90: Restricting re-encapsulation (comment 12 reported by Y. = Rekhter) http://www.ietf.org/mail-archive/web/lisp/current/msg02324.html Re: [lisp] #89: On redefining the name of the encapsulated packet header = (comment 12 reported by Y. Rekhter) http://www.ietf.org/mail-archive/web/lisp/current/msg02323.html Re: [lisp] #71: Missing description mechanism to make EID-to-RLOC (from = D. Papadimitriou's review) http://www.ietf.org/mail-archive/web/lisp/current/msg02314.html Re: [lisp] #73: Tunnel liveness (from R. Bonica review for the RTG = directorate) http://www.ietf.org/mail-archive/web/lisp/current/msg02315.html Re: [lisp] #70: Client not respecting RLOC weights (from Y. Rekhter's = review) http://www.ietf.org/mail-archive/web/lisp/current/msg02312.html Re: [lisp] #66: Strict RLOC ordering causing problems on mapping changes http://www.ietf.org/mail-archive/web/lisp/current/msg02309.html Re: [lisp] #57: How to determine EIDs not forwardable on the routable = topology (from Y. Rekhter's review) http://www.ietf.org/mail-archive/web/lisp/current/msg02305.html Re: [lisp] #53: Reachability between ETR and EID (review by Y. Rekhter) http://www.ietf.org/mail-archive/web/lisp/current/msg02302.html Re: [lisp] #47: Ambiguity on "MAP-replies" requirements (review by Y. = Rekhter) Re: [lisp] #49: "MAP-Replies" content that is allowed to change (review = by Y. Rekhter) Re: [lisp] #50: MAP-Replies content that MUST be invariant (review by Y. = Rekhter) http://www.ietf.org/mail-archive/web/lisp/current/msg02340.html Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter) http://www.ietf.org/mail-archive/web/lisp/current/msg02300.html Re: [lisp] #45: LISP vs. Existing (from Y. Rekhter) http://www.ietf.org/mail-archive/web/lisp/current/msg02301.html Re: [lisp] #44: LISP vs existing (reported by Yakov Rekhter) http://www.ietf.org/mail-archive/web/lisp/current/msg02299.html Re: [lisp] #111: Semantics of LSB http://www.ietf.org/mail-archive/web/lisp/current/msg02332.html Re: [lisp] #101: Filtering ICMP messages (comment 19 reported by Y. = Rekhter) http://www.ietf.org/mail-archive/web/lisp/current/msg02330.html On 16, Mar, 2011, at 19:58 , lisp issue tracker wrote: > #90: Restricting re-encapsulation (comment 12 reported by Y. Rekhter) >=20 > Changes (by yakov@=85): >=20 > * status: closed =3D> reopened > * resolution: fixed =3D> >=20 >=20 > Comment: >=20 > The question posed in this comment is still not answered.Thus the = ticket > should stay open until the question is answered. >=20 > --=20 > = -------------------------------+------------------------------------------= -- > Reporter: wmhaddad@=85 | Owner: =20 > Type: technical | Status: reopened =20 > Priority: major | Component: draft-ietf-lisp > Severity: - | Resolution: =20 > Keywords: | =20 > = -------------------------------+------------------------------------------= -- >=20 > Ticket URL: = > lisp > LISP WG document issues --Apple-Mail-28--58244153 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Re: = [lisp] #90: Restricting re-encapsulation (comment 12 reported by Y. = Rekhter)


Re: [lisp] #89: On = redefining the name of the encapsulated packet header (comment 12 = reported by Y. Rekhter)


Re: [lisp] #71: Missing = description mechanism to make EID-to-RLOC (from D. Papadimitriou's = review)


Re: [lisp] #73: Tunnel = liveness (from R. Bonica review for the RTG directorate)


Re: [lisp] #70: Client = not respecting RLOC weights (from Y. Rekhter's review)


Re: [lisp] #66: Strict = RLOC ordering causing problems on mapping changes


Re: [lisp] #57: How to = determine EIDs not forwardable on the routable topology (from Y. = Rekhter's review)


Re: [lisp] #53: = Reachability between ETR and EID (review by Y. = Rekhter)


Re: [lisp] = #47: Ambiguity on "MAP-replies" requirements (review by Y. = Rekhter)

Re: [lisp] #50: MAP-Replies content that MUST be = invariant (review by Y. Rekhter)


Re: [lisp] #46: Cache = Thrashing (review by Y. Rekhter)


Re: [lisp] #45: LISP = vs. Existing (from Y. Rekhter)


Re: [lisp] #44: LISP vs = existing (reported by Yakov Rekhter)


Re: [lisp] #111: = Semantics of LSB


Re: [lisp] #101: = Filtering ICMP messages (comment 19 reported by Y. = Rekhter)



On 16, Mar, 2011, at = 19:58 , lisp issue tracker wrote:

#90: = Restricting re-encapsulation (comment 12 reported by Y. = Rekhter)

Changes (by yakov@=85):

 * status: =  closed =3D> reopened
 * resolution:  fixed = =3D>


Comment:

The question posed in this comment = is still not answered.Thus the ticket
should stay open until the = question is answered.

-- =
-------------------------------+--------------------------------------= ------
Reporter:  wmhaddad@=85 =          | =        Owner: =             &n= bsp;   
   Type:  technical =           | =       Status:  reopened =       
Priority:  major =             &n= bsp; |    Component: =  draft-ietf-lisp
Severity:  - =             &n= bsp;     |   Resolution: =             &n= bsp;   
Keywords: =             &n= bsp;        | =  
-------------------------------+--------------------------------= ------------

Ticket URL: <http:= //trac.tools.ietf.org/wg/lisp/trac/ticket/90#comment:3>
lisp = <http://tools.ietf.org/lisp/>LISP WG document = issues

= --Apple-Mail-28--58244153-- From yakov@juniper.net Thu Mar 17 08:14:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195F63A6983 for ; Thu, 17 Mar 2011 08:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.382 X-Spam-Level: X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ta1lrh7Sx4eT for ; Thu, 17 Mar 2011 08:14:11 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 1A7AE3A6920 for ; Thu, 17 Mar 2011 08:14:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTYIlms+6mnPXglpMBr2vv7HiX7ado/te@postini.com; Thu, 17 Mar 2011 08:15:39 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 17 Mar 2011 08:11:56 -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 p2HFD5v58440; Thu, 17 Mar 2011 08:13:05 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103171513.p2HFD5v58440@magenta.juniper.net> To: Darrel Lewis In-Reply-To: References: X-MH-In-Reply-To: Darrel Lewis message dated "Tue, 20 Jul 2010 14:20:32 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2064.1300374785.1@juniper.net> Date: Thu, 17 Mar 2011 08:13:05 -0700 From: Yakov Rekhter Cc: lisp@ietf.org Subject: Re: [lisp] Issue Title (number): Limiting number of headers(90) 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, 17 Mar 2011 15:14:12 -0000 Darrel, > Issue Title (number): Limiting number of headers(90) > Draft Section: 3 > Issue Description: Reincapsulation of Headers > Comments: > > 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? > > Response: > > Dear Yakov- > > Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors > have reviewed your comments but do not feel that changes to the document are > warranted at this time. To use common jargon, re-encapsulating is is a 'pop' > and then a 'push'. That is all that is meant. Please feel free to continue > discussion of your issue on the LISP working group mailing list, > lisp@ietf.org. > Should discussion result in WG consensus that changes are required, the > authors will incorporate appropriate text into a future version of the draft. That still does not answer my original question. Namely, what are the reasons why re-encapsulation is restricted to packets that have "no more than one LISP IP header" ? Yakov. From trac+lisp@trac.tools.ietf.org Thu Mar 17 08:30:42 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B95E3A6926 for ; Thu, 17 Mar 2011 08:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 h4bHUMeDp3Ub for ; Thu, 17 Mar 2011 08:30:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2508A3A686C for ; Thu, 17 Mar 2011 08:30:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0FBB-0005Ek-HJ; Thu, 17 Mar 2011 08:32: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 15:32:01 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/89#comment:4 Message-ID: <066.752fb91ef5dd7418ca954cd457dcda07@trac.tools.ietf.org> References: <057.915c3b2990c494d4d75d76e0f1fee088@trac.tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <057.915c3b2990c494d4d75d76e0f1fee088@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Thu, 17 Mar 2011 15:30:42 -0000 #89: On redefining the name of the encapsulated packet header (comment 12 reported by Y. Rekhter) Changes (by yakov@…): * status: reopened => resolved * resolution: => fixed Comment: Consider the ticket closed. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Mar 17 08:36:43 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD1D3A6A2D for ; Thu, 17 Mar 2011 08:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 meP7KkVMIohW for ; Thu, 17 Mar 2011 08: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 D88B63A6A0E for ; Thu, 17 Mar 2011 08:36:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0FH8-0002i0-Ay; Thu, 17 Mar 2011 08:38: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 15:38:10 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/71#comment:4 Message-ID: <077.0fed6bcf2bcd0561d731b7c62b810727@trac.tools.ietf.org> References: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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 List-Id: 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, 17 Mar 2011 15:36:43 -0000 #71: Missing description mechanism to make EID-to-RLOC (from D. Papadimitriou's review) Changes (by yakov@…): * status: reopened => resolved * resolution: => fixed Comment: Consider the ticket as closed. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Mar 17 08:49:16 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B863A68FC for ; Thu, 17 Mar 2011 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 GQ9pp6ekiEAi for ; Thu, 17 Mar 2011 08:49:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0D7973A6926 for ; Thu, 17 Mar 2011 08:49:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0FTG-0001Za-8f; Thu, 17 Mar 2011 08:50: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 15:50:42 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/73#comment:4 Message-ID: <077.fe5c72153d44626a1103a970bac0a1ee@trac.tools.ietf.org> References: <068.11139862467bb967cdc8cf5e6cf8c426@trac.tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <068.11139862467bb967cdc8cf5e6cf8c426@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #73: Tunnel liveness (from R. Bonica review for the RTG directorate) 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: Thu, 17 Mar 2011 15:49:16 -0000 #73: Tunnel liveness (from R. Bonica review for the RTG directorate) Comment(by yakov@…): To address the issue raised by the ticket please add the following to the beginning of 6.3: When an ETR becomes unreachable (e.g., due to the ETR crash), that results in (temporary) black-holing the traffic that have been sent to that ETR by ITRs, which in turn may result in service disruption. That black-holing and the service disruption due to that black-holing lasts until all these ITRs determine that the ETR is no longer reachable, and subsequently select another ETR. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Mar 17 09:00:29 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F343A6A71 for ; Thu, 17 Mar 2011 09:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 cjR77flCCJIK for ; Thu, 17 Mar 2011 09:00:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D51C03A6996 for ; Thu, 17 Mar 2011 09:00:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0Fe7-0000kD-I9; Thu, 17 Mar 2011 09:01: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 16:01:55 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/70#comment:5 Message-ID: <077.15a4bdb50916f5bacc857b359bf5e4d7@trac.tools.ietf.org> References: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 17 Mar 2011 16:00:29 -0000 #70: Client not respecting RLOC weights (from Y. Rekhter's review) Comment(by yakov@…): Here is from the response to my original comment: Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. Implementations must adhere to the specification. Note that the text I quoted above uses none of the ""MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". So, the text still does not say what is exactly required by the specification. Thus the spec has to replace "can" in "Client can only.." with one of the terms defined in rfc2119. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Mar 17 09:12:44 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760963A698C for ; Thu, 17 Mar 2011 09:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 i-MvwySUOYVi for ; Thu, 17 Mar 2011 09:12:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 60C7F3A6A71 for ; Thu, 17 Mar 2011 09:12:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0Fpw-0001nc-EV; Thu, 17 Mar 2011 09:14: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 16:14:08 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:6 Message-ID: <077.28c2cc9862e26b7fbd5b68671092214a@trac.tools.ietf.org> References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 17 Mar 2011 16:12:44 -0000 #66: Strict RLOC ordering causing problems on mapping changes Comment(by yakov@…): From the response to my comment: Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. We think that the use of version numbers will help this. Its also important to note that LSBs are a hint and a request/reply exchange will confirm from the R-bits of the locators in the locator-set which are reachable or not. To close the ticket the draft authors should describe how the use of version number will address the issues raised in the ticket. Likewise, the authors should point to the specific text in the draft that makes it clear that "LSBs are a hint" and thus are are not sufficient to determine locator's reachability - a request/reply exchange will be required. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Mar 17 09:17:06 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C6F3A69BA for ; Thu, 17 Mar 2011 09:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 BWQtO5VIFql9 for ; Thu, 17 Mar 2011 09:17:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1B63D3A698C for ; Thu, 17 Mar 2011 09:17:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0FuD-0000Bj-6Z; Thu, 17 Mar 2011 09:18: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 16:18:33 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/57#comment:5 Message-ID: <077.4c360fae964c487e3d8c49c145e9631d@trac.tools.ietf.org> References: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 17 Mar 2011 16:17:06 -0000 #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) Comment(by yakov@…): From the response to my ticket: Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. We feel that this subject is thoroughly covered in the draft-ietf-lisp-alt and draft-ietf-lisp-ms specifications. If that is the case, then please include in Section 7 a reference to the specific sections in lisp-alt and lisp-ms that thoroughly cover the subject. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Mar 17 09:39:20 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6293A6A59 for ; Thu, 17 Mar 2011 09:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 rgok8eKMXi5w for ; Thu, 17 Mar 2011 09:39:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ABD1B3A69BE for ; Thu, 17 Mar 2011 09:39:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0GFf-0007Ts-Tx; Thu, 17 Mar 2011 09:40:43 -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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 16:40:43 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/53#comment:4 Message-ID: <066.67a605e1571c1980937da680ae7a5223@trac.tools.ietf.org> References: <057.cd86d557ebd472d3854de590d8c2facd@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <057.cd86d557ebd472d3854de590d8c2facd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #53: Reachability between ETR and EID (review 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: Thu, 17 Mar 2011 16:39:20 -0000 #53: Reachability between ETR and EID (review by Y. Rekhter) Comment(by yakov@…): From the response to my original comment: Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. Remember that on-going locator reachability is not conveyed by the initial Map-Reply. To close the ticket please replace the following (from section 6.3 item 5): The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. with the following: The RLOC source of the Map-Reply was up at the time the ETR was able to send the Map-Reply to the ITR. However, the RLOC source may no longer be up even at the time the ITR receives the Map-Reply, and certainly may not be up after the ITR receives the Map-Reply, as the Map-Reply does not convey on-going locator reachability. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From lear@cisco.com Thu Mar 17 09:46:48 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79483A69DA for ; Thu, 17 Mar 2011 09:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.286 X-Spam-Level: X-Spam-Status: No, score=-110.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, 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 JqAcxAC6ue6L for ; Thu, 17 Mar 2011 09:46:47 -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 8F8FB3A6A59 for ; Thu, 17 Mar 2011 09:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1435; q=dns/txt; s=iport; t=1300380496; x=1301590096; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=CVN46DgTRX/e1HsaoWc33c0Mvc9DBDk9z4gp6BmSRfk=; b=U+w8s9wK1LVL6yWKzKkJCXq6dhCp/AOs9hE6bCU5XcePRuQJb9tJEsji Tzy04GevPvUF4OvFfrwzMEr2LCtPNNM43EVEVYB4lVWssqxeWKTBEWoGI 9comOcALUTmJ1AnVrgu62+orZ0E/WiTUlr01aFduufAl28R0kUwSMwVwa I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAGXYgU2Q/khLgWdsb2JhbACEPqEQFAEBFiYlpxWLI5EmgSeDRXcEjF4 X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="scan'208";a="79663680" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2011 16:48:15 +0000 Received: from dhcp-10-55-81-164.cisco.com (dhcp-10-55-81-164.cisco.com [10.55.81.164]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2HGmEHA017268; Thu, 17 Mar 2011 16:48:14 GMT Message-ID: <4D823B2A.7030504@cisco.com> Date: Thu, 17 Mar 2011 17:47:38 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp issue tracker References: <057.cd86d557ebd472d3854de590d8c2facd@trac.tools.ietf.org> <066.67a605e1571c1980937da680ae7a5223@trac.tools.ietf.org> In-Reply-To: <066.67a605e1571c1980937da680ae7a5223@trac.tools.ietf.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] #53: Reachability between ETR and EID (review 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, 17 Mar 2011 16:46:48 -0000 I don't agree with this proposed changed, as it is overly pessimistic, a common thread. In all likelihood, the ETR *is* up. There will be cases where the ETR fails, and those circumstances should be discussed (I believe they are, albeit elsewhere). Eliot On 3/17/11 5:40 PM, lisp issue tracker wrote: > #53: Reachability between ETR and EID (review by Y. Rekhter) > > > Comment(by yakov@…): > > From the response to my original comment: > > Thank you for your contribution to draft-ietf-lisp-06.txt. The draft > authors > have reviewed your comments but do not feel that changes to the document > are > warranted at this time. Remember that on-going locator reachability is > not conveyed > by the initial Map-Reply. > > To close the ticket please replace the following (from section 6.3 item > 5): > > The RLOC source of the Map-Reply is > likely up since the ETR was able to send the Map-Reply to the > ITR. > > with the following: > > The RLOC source of the Map-Reply was up at the time the ETR was able > to send the Map-Reply to the ITR. However, the RLOC source may no > longer > be up even at the time the ITR receives the Map-Reply, and certainly > may > not be up after the ITR receives the Map-Reply, as the Map-Reply > does > not convey on-going locator reachability. > From trac+lisp@trac.tools.ietf.org Thu Mar 17 09:47:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2DC3A6AA5 for ; Thu, 17 Mar 2011 09:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 5a-2-LtsK74Q for ; Thu, 17 Mar 2011 09: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 D5A773A6A88 for ; Thu, 17 Mar 2011 09:46:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0GN7-00031w-2t; Thu, 17 Mar 2011 09:48: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 16:48:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/46#comment:5 Message-ID: <066.8c9246585b388d338b410628ba9daa53@trac.tools.ietf.org> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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: Thu, 17 Mar 2011 16:47:00 -0000 #46: Cache Thrashing (review by Y. Rekhter) Comment(by yakov@…): From the response to the ticket: Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. We feel that existing text adequately describes cache management behavior. The response is insufficient, as it fails to point out to the specific section(s) of the existing text that according to the authors "adequately describes cache management behavior". In order to determine whether the existing text is adequate, the first thing the authors need to do is to point out to such text. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Mar 17 09:53:19 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357E43A6A59 for ; Thu, 17 Mar 2011 09:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 4TjgW6-B9vca for ; Thu, 17 Mar 2011 09:53:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3E1763A69DA for ; Thu, 17 Mar 2011 09:53:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0GTF-0005EC-2W; Thu, 17 Mar 2011 09:54: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 16:54:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/45#comment:4 Message-ID: <066.15fd9891d41fce9bf6d5c8940a0cd25e@trac.tools.ietf.org> References: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #45: LISP vs. Existing (from 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: Thu, 17 Mar 2011 16:53:19 -0000 #45: LISP vs. Existing (from Y. Rekhter) Comment(by yakov@…): From the response I received: Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. In this case, this draft is an experimental protocol specification it seems out of place to discuss how sites use NAT at length. Note that I did not ask "to discuss how sites use NAT at length" - I asked to document the benefits that LISP could offer to sites that use NAT. If the authors think that this should be done in some other LISP WG document, then I'll be glad to hear their proposal. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Mar 17 09:56:09 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0593A6AAE for ; Thu, 17 Mar 2011 09:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 KbKV3HfglD2X for ; Thu, 17 Mar 2011 09:56:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9696C3A6AA8 for ; Thu, 17 Mar 2011 09:56:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0GVy-0005Rc-7D; Thu, 17 Mar 2011 09:57: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 16:57:34 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/44#comment:6 Message-ID: <066.bbb0590b3eaf4ea64606607d76c438d9@trac.tools.ietf.org> References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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: Thu, 17 Mar 2011 16:56:09 -0000 #44: LISP vs existing (reported by Yakov Rekhter) Comment(by yakov@…): From the response I received: Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. In this case, this draft is an experimental protocol specification it seems out of place to discuss the benefits of existing PI multihoming at length. Note that I did not ask "to discuss the benefits of existing PI multihoming at length" - I asked to document the benefits that LISP could offer to sites that use PI. If the authors think that this should be done in some other LISP WG document, then I'll be glad to hear their proposal. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Mar 17 10:04:23 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AB13A6AC9 for ; Thu, 17 Mar 2011 10:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 na6LQQFoX0C7 for ; Thu, 17 Mar 2011 10:04:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8B0C33A6A25 for ; Thu, 17 Mar 2011 10:04:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0Gdx-0004ck-Mj; Thu, 17 Mar 2011 10:05: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 17:05:49 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/111#comment:4 Message-ID: <065.77cfd085a041fe6399ddc3fe104a8a72@trac.tools.ietf.org> References: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #111: Semantics of LSB 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: Thu, 17 Mar 2011 17:04:23 -0000 #111: Semantics of LSB Comment(by yakov@…): From the response I received: Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. LSB semantics would mean that if the LSB for an anycast locator is set, then there is at least one RLOC with that address that is considered 'up'. To close the ticket please add the following to the description of LSB in 5.3: If the LSB for an anycast locator is set to 1, then there is at least one RLOC with that address that the ITR is considered 'up'. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From jmh@joelhalpern.com Thu Mar 17 10:08:31 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E873A6A25 for ; Thu, 17 Mar 2011 10:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 Q9hEOf0y-wqo for ; Thu, 17 Mar 2011 10:08:30 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id AE8B93A6AC9 for ; Thu, 17 Mar 2011 10:08:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1011E4300AC; Thu, 17 Mar 2011 10:09:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 3824043001A; Thu, 17 Mar 2011 10:09:58 -0700 (PDT) Message-ID: <4D82406B.8030509@joelhalpern.com> Date: Thu, 17 Mar 2011 13:10:03 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp issue tracker References: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> <066.15fd9891d41fce9bf6d5c8940a0cd25e@trac.tools.ietf.org> In-Reply-To: <066.15fd9891d41fce9bf6d5c8940a0cd25e@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] #45: LISP vs. Existing (from 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, 17 Mar 2011 17:08:31 -0000 If the issue of the deployment benefit interaction needs to be addressed at all (and I am not sure it does), then it would be in either the deployment draft or in yet a different applicability statement (which I hope we do not decide we need.) Yours, Joel On 3/17/2011 12:54 PM, lisp issue tracker wrote: > #45: LISP vs. Existing (from Y. Rekhter) > > > Comment(by yakov@…): > > From the response I received: > > Thank you for your contribution to draft-ietf-lisp-06.txt. The draft > authors > have reviewed your comments but do not feel that changes to the document > are > warranted at this time. In this case, this draft is an experimental > protocol > specification it seems out of place to discuss how sites use NAT at > length. > > Note that I did not ask "to discuss how sites use NAT at length" - I asked > to document the benefits that LISP could offer to sites that use NAT. If > the authors think that this should be done in some other LISP WG document, > then I'll be glad to hear their proposal. > From jmh@joelhalpern.com Thu Mar 17 10:14:47 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD4D3A6ACB for ; Thu, 17 Mar 2011 10:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.14 X-Spam-Level: X-Spam-Status: No, score=-102.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 u9AcfOBHlgTs for ; Thu, 17 Mar 2011 10:14:46 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id BDA383A6AC9 for ; Thu, 17 Mar 2011 10:14:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 38B0B4300D2; Thu, 17 Mar 2011 10:16:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 35C0C4300BE; Thu, 17 Mar 2011 10:16:14 -0700 (PDT) Message-ID: <4D8241E3.9070101@joelhalpern.com> Date: Thu, 17 Mar 2011 13:16:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp issue tracker References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> <066.bbb0590b3eaf4ea64606607d76c438d9@trac.tools.ietf.org> In-Reply-To: <066.bbb0590b3eaf4ea64606607d76c438d9@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] #44: LISP vs existing (reported by Yakov 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, 17 Mar 2011 17:14:47 -0000 I do not understand what you are asking for here. The roginal ticket says "What LISP offers to audiences which already using PI." To a small degree, we might make such a case in the deployment document. But I would not attempt to do so. From the point of view of the eixsting PI user, they don't have a problem. However, teh system has a problem with widespread PI deployment. Now, I recognize that folks disagree about the degree of that problem. The LISP document already points to the places that is discussed. Any effort to discuss it further in the LISP documents would induce controversy without actually solving anything. Yours, Joel M. Halpern On 3/17/2011 12:57 PM, lisp issue tracker wrote: > #44: LISP vs existing (reported by Yakov Rekhter) > > > Comment(by yakov@…): > > From the response I received: > > Thank you for your contribution to draft-ietf-lisp-06.txt. The draft > authors > have reviewed your comments but do not feel that changes to the document > are > warranted at this time. In this case, this draft is an experimental > protocol > specification it seems out of place to discuss the benefits of existing > PI > multihoming at length. > > Note that I did not ask "to discuss the benefits of existing PI > multihoming at length" - I asked to document the benefits that LISP could > offer to sites that use PI. If the authors think that this should be done > in some other LISP WG document, then I'll be glad to hear their proposal. > From trac+lisp@trac.tools.ietf.org Thu Mar 17 10:34:42 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5DB3A69F7 for ; Thu, 17 Mar 2011 10:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 A+RSqItgHZnk for ; Thu, 17 Mar 2011 10:34:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AB9C93A69F3 for ; Thu, 17 Mar 2011 10:34:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0H7H-0008Km-1g; Thu, 17 Mar 2011 10:36: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Thu, 17 Mar 2011 17:36:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/101#comment:4 Message-ID: <066.a2dceb8d918411ce083829002135a23a@trac.tools.ietf.org> References: <057.0e0d4458c9205c12214b19f32a304af1@trac.tools.ietf.org> X-Trac-Ticket-ID: 101 In-Reply-To: <057.0e0d4458c9205c12214b19f32a304af1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Thu, 17 Mar 2011 17:34:42 -0000 #101: Filtering ICMP messages (comment 19 reported by Y. Rekhter) Comment(by yakov@…): Here is the response I got from the authors: Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. While this case is possible the authors assume the popular use-case will be egress active-active so the map-cache (and therefore information about path MTU) is populated in both boxes. The response still does not answer my first question, namely how would this work if the ITR is behind the firewall, and the firewall filters ICMP messages? The draft has to answer this question before the ticket is considered to be closed. Now let's look at my second question, namely that 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. Since the authors think that this case is possible, the draft needs to document the implications of relying on ICMP Too Big message on connectivity restoration time after a large volume of traffic is moved from one ITR to another. To address this the following should be added to 5.4.2: Note that when traffic is moved from one ITR to another (e.g., due to ITR failure), the ITR to which the traffic has been moved may not have the effective MTU information for the locators used by the traffic. Until the ITR discovers the effective MTU for these locators, the ITR should drop the traffic that it needs to send to these locators, which would result in temporary connectivity disruption. This disruption will last as long as it would take the ITR to discover the effective MTU. Trying to make the ITR to discover the effective MTU for multiple locators as fast as possible may result in a large volume of ICMP message being received by the ITR, which could result in dropping some of these messages, thus further increasing the time to discover the effective MTU and prolonging connectivity disruption. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From yakov@juniper.net Thu Mar 17 10:46:27 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B053A69F3 for ; Thu, 17 Mar 2011 10:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.113 X-Spam-Level: X-Spam-Status: No, score=-106.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 ZVqTYTYnSgJQ for ; Thu, 17 Mar 2011 10:46:26 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id E25423A6AC9 for ; Thu, 17 Mar 2011 10:46:23 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTYJJOtGyjKSdSAZ9SfbFY4WaqEuKkfKT@postini.com; Thu, 17 Mar 2011 10:47:54 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 17 Mar 2011 10:44:20 -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 p2HHjRv24618; Thu, 17 Mar 2011 10:45:27 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103171745.p2HHjRv24618@magenta.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4D82406B.8030509@joelhalpern.com> References: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> <066.15fd9891d41fce9bf6d5c8940a0cd25e@trac.tools.ietf.org> <4D82406B.8030509@joelhalpern.com> X-MH-In-Reply-To: "Joel M. Halpern" message dated "Thu, 17 Mar 2011 13:10:03 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <8881.1300383927.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 10:45:27 -0700 From: Yakov Rekhter Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #45: LISP vs. Existing (from 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, 17 Mar 2011 17:46:27 -0000 Joel, > If the issue of the deployment benefit interaction needs to be addressed= = > at all (and I am not sure it does), then it would be in either the = > deployment draft or in yet a different applicability statement (which I = > hope we do not decide we need.) I have no problems if this issue will be addressed in the LISP WG deployment draft (I have a problem if this issue is not addressed at all). However, (to the best of my knowledge) as of now there is no LISP WG deployment draft (there is only an individual submission). Given that, what are the mechanisms/procedures we can use to make sure that this issue will be addressed in the LISP WG deployment draft ? Yakov. > = > Yours, > Joel > = > On 3/17/2011 12:54 PM, lisp issue tracker wrote: > > #45: LISP vs. Existing (from Y. Rekhter) > > > > > > Comment(by yakov@=E2=80=A6): > > > > From the response I received: > > > > Thank you for your contribution to draft-ietf-lisp-06.txt. The dra= ft > > authors > > have reviewed your comments but do not feel that changes to the do= cumen t > > are > > warranted at this time. In this case, this draft is an experiment= al > > protocol > > specification it seems out of place to discuss how sites use NAT a= t > > length. > > > > Note that I did not ask "to discuss how sites use NAT at length" - I= aske d > > to document the benefits that LISP could offer to sites that use NAT= . If > > the authors think that this should be done in some other LISP WG doc= ument , > > then I'll be glad to hear their proposal. > > From yakov@juniper.net Thu Mar 17 10:55:05 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA193A6ADF for ; Thu, 17 Mar 2011 10:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 HtHat4JzRPX6 for ; Thu, 17 Mar 2011 10:55:05 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 797CB3A6A1C for ; Thu, 17 Mar 2011 10:55:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTYJLSyGfAXRkClNvIhMof3dSjF0fPUOc@postini.com; Thu, 17 Mar 2011 10:56:33 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 17 Mar 2011 10:53:29 -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 p2HHsdv28694; Thu, 17 Mar 2011 10:54:39 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103171754.p2HHsdv28694@magenta.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4D8241E3.9070101@joelhalpern.com> References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> <066.bbb0590b3eaf4ea64606607d76c438d9@trac.tools.ietf.org> <4D8241E3.9070101@joelhalpern.com> X-MH-In-Reply-To: "Joel M. Halpern" message dated "Thu, 17 Mar 2011 13:16:19 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9491.1300384479.1@juniper.net> Date: Thu, 17 Mar 2011 10:54:39 -0700 From: Yakov Rekhter Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #44: LISP vs existing (reported by Yakov 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, 17 Mar 2011 17:55:06 -0000 Joel, > I do not understand what you are asking for here. The original ticket > says "What LISP offers to audiences which already using PI." That is correct. > To a small degree, we might make such a case in the deployment document. And as I said in my comment, it would be fine with me if this will be addressed in the LISP WG deployment document. (I have a problem if this issue is not addressed at all). However, (to the best of my knowledge) as of now there is no LISP WG deployment draft (there is only an individual submission). Given that, what are the mechanisms/procedures we can use to make sure that this issue will be addressed in the LISP WG deployment draft ? > But I would not attempt to do so. From the point of view of the > eixsting PI user, they don't have a problem. I am not asking whether the existing PI users "have a problem" - I am asking to document whether LISP offers any benefits to *such users*. > However, the system has a problem with widespread PI deployment. There is a need to document which parts of "the system" have such problem, and which parts of "the system" would need to deploy LISP in order to solve this problem. As I said above, it would be fine with me if this will be done in the LISP WG deployment document. Yakov. From yakov@juniper.net Thu Mar 17 11:01:14 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6ED3A6A1C for ; Thu, 17 Mar 2011 11:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.121 X-Spam-Level: X-Spam-Status: No, score=-106.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 Y7Qu0ijj6KKw for ; Thu, 17 Mar 2011 11:01:14 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 0DC8E3A6A04 for ; Thu, 17 Mar 2011 11:01:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTYJMtjhB4mJoy3iep+wDYe0wN54h+0U0@postini.com; Thu, 17 Mar 2011 11:02:42 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 17 Mar 2011 10:58: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 p2HI02v30695; Thu, 17 Mar 2011 11:00:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103171800.p2HI02v30695@magenta.juniper.net> To: Eliot Lear In-Reply-To: <4D823B2A.7030504@cisco.com> References: <057.cd86d557ebd472d3854de590d8c2facd@trac.tools.ietf.org> <066.67a605e1571c1980937da680ae7a5223@trac.tools.ietf.org> <4D823B2A.7030504@cisco.com> X-MH-In-Reply-To: Eliot Lear message dated "Thu, 17 Mar 2011 17:47:38 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <9918.1300384802.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 11:00:02 -0700 From: Yakov Rekhter Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #53: Reachability between ETR and EID (review 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, 17 Mar 2011 18:01:14 -0000 Eliot, > I don't agree with this proposed changed, as it is overly pessimistic, a > common thread. = "pessimistic" is not a valid technical reason to reject the change. > In all likelihood, the ETR *is* up. = Could you quantify the likelihood ? Yakov. > There will be cases > where the ETR fails, and those circumstances should be discussed (I > believe they are, albeit elsewhere). > = > Eliot > = > On 3/17/11 5:40 PM, lisp issue tracker wrote: > > #53: Reachability between ETR and EID (review by Y. Rekhter) > > > > > > Comment(by yakov@=E2=80=A6): > > > > From the response to my original comment: > > > > Thank you for your contribution to draft-ietf-lisp-06.txt. The draf= t > > authors > > have reviewed your comments but do not feel that changes to the doc= ument > > are > > warranted at this time. Remember that on-going locator reachability= is > > not conveyed > > by the initial Map-Reply. > > > > To close the ticket please replace the following (from section 6.3 it= em > > 5): > > > > The RLOC source of the Map-Reply is > > likely up since the ETR was able to send the Map-Reply to the > > ITR. > > > > with the following: > > > > The RLOC source of the Map-Reply was up at the time the ETR was= able > > to send the Map-Reply to the ITR. However, the RLOC source may = no > > longer > > be up even at the time the ITR receives the Map-Reply, and cert= ainly > > may > > not be up after the ITR receives the Map-Reply, as the Map-Repl= y > > does > > not convey on-going locator reachability. > > From lear@cisco.com Thu Mar 17 11:36:08 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F553A6AEB for ; Thu, 17 Mar 2011 11:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 fDvisQQloUXM for ; Thu, 17 Mar 2011 11:36: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 8C8D03A6AE3 for ; Thu, 17 Mar 2011 11:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=964; q=dns/txt; s=iport; t=1300387055; x=1301596655; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5fQwfN2g7F22YVprEHYXFcV+TibvjWpiepNEokw/TLM=; b=Vb4ddFd1uZdcbF/4mPLoVteoOA8wE/mUT5EL501ShsZAwkTDiPsR9igX jsfPgnCTi2hFRqmLKotN94L/Iq3pfPLTwM+pHzrT7Gtkc3ZQ+WAKyeYNM 65jX6HQWHZnM30LJx4EiZ0SUwBU1aZDHpvgHfgByVn/q/PFbN4BAJcmEs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4EALjxgU2Q/khNgWdsb2JhbACEPqEQFAEBCwsmJadKiyORF4Eng0V3BIxe X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="scan'208";a="22160076" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 17 Mar 2011 18:37:34 +0000 Received: from dhcp-10-55-81-164.cisco.com (dhcp-10-55-81-164.cisco.com [10.55.81.164]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2HIbXc8019208; Thu, 17 Mar 2011 18:37:34 GMT Message-ID: <4D8254C9.2040708@cisco.com> Date: Thu, 17 Mar 2011 19:36:57 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yakov Rekhter References: <057.cd86d557ebd472d3854de590d8c2facd@trac.tools.ietf.org> <066.67a605e1571c1980937da680ae7a5223@trac.tools.ietf.org> <4D823B2A.7030504@cisco.com> <201103171800.p2HI02v30695@magenta.juniper.net> In-Reply-To: <201103171800.p2HI02v30695@magenta.juniper.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #53: Reachability between ETR and EID (review 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, 17 Mar 2011 18:36:09 -0000 Yakov, On 3/17/11 7:00 PM, Yakov Rekhter wrote: > Eliot, > >> I don't agree with this proposed changed, as it is overly pessimistic, a >> common thread. > "pessimistic" is not a valid technical reason to reject the change. Optimistic and pessimistic design are two classic system design approaches. The Internet is largely based on optimistic design (e.g., packets can drop and the world doesn't stop). Your text appears to come from the point of view of pessimistic design. I don't agree with that approach. I'm not saying the system shouldn't be hardened, but perhaps not everything has to happen in a single document? Otherwise RFC 791 would have been quite large! >> In all likelihood, the ETR *is* up. > Could you quantify the likelihood ? Happily. By way of example, my consumer-grade router has been up and available over 99.98% of the time over a year. I'm not saying I'm average, but I doubt I'm far from it. Eliot From jmh@joelhalpern.com Thu Mar 17 13:54:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73A33A6AF0 for ; Thu, 17 Mar 2011 13:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, 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 XGS7+cDiAzwQ for ; Thu, 17 Mar 2011 13:54:18 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id F39CE3A69DE for ; Thu, 17 Mar 2011 13:54:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A07E94300AC; Thu, 17 Mar 2011 13:55:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 7BEF64300CC; Thu, 17 Mar 2011 13:55:45 -0700 (PDT) Message-ID: <4D827556.5010003@joelhalpern.com> Date: Thu, 17 Mar 2011 16:55:50 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yakov Rekhter References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> <066.bbb0590b3eaf4ea64606607d76c438d9@trac.tools.ietf.org> <4D8241E3.9070101@joelhalpern.com> <201103171754.p2HHsdv28694@magenta.juniper.net> In-Reply-To: <201103171754.p2HHsdv28694@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #44: LISP vs existing (reported by Yakov 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, 17 Mar 2011 20:54:18 -0000 I do not follow why the LISP document need to describe all of the intricacies of the problems they are attempting to address. The introduction to the LISP base document cites a number of other RFCs that discuss the issues. If all you want is a sentence in the introduction re-iterating that the use of LISP could help reduce the need for unaggregatable PI advertisements in the core, if the experiments prove successful, I suppose we could add such a sentence. I do not see how it would help the reader. You seem to be imputing a claim to the document, and asking the authors to justify that claim. As far as I know, it is not a claim they have made. I do not see why they need to justify such a claim. I also do not see why they would need to disclaim such an intention. We do not ask drafts to disclaim all possible unjustified applications. And we certainly don't ask that of experimental drafts. Yours, Joel PS: The WG will be considering, and I expect adopting, the deployment draft in the near future. On 3/17/2011 1:54 PM, Yakov Rekhter wrote: > Joel, > >> I do not understand what you are asking for here. The original ticket >> says "What LISP offers to audiences which already using PI." > > That is correct. > >> To a small degree, we might make such a case in the deployment document. > > And as I said in my comment, it would be fine with me if this will > be addressed in the LISP WG deployment document. (I have a problem > if this issue is not addressed at all). However, (to the best of > my knowledge) as of now there is no LISP WG deployment draft (there > is only an individual submission). Given that, what are the > mechanisms/procedures we can use to make sure that this issue will > be addressed in the LISP WG deployment draft ? > >> But I would not attempt to do so. From the point of view of the >> eixsting PI user, they don't have a problem. > > I am not asking whether the existing PI users "have a problem" - I am > asking to document whether LISP offers any benefits to *such users*. > >> However, the system has a problem with widespread PI deployment. > > There is a need to document which parts of "the system" have such > problem, and which parts of "the system" would need to deploy LISP > in order to solve this problem. As I said above, it would be fine > with me if this will be done in the LISP WG deployment document. > > Yakov. > From robert@raszuk.net Thu Mar 17 16:12:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA963A69B3 for ; Thu, 17 Mar 2011 16:12:00 -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 eWZkFCIBBg8R for ; Thu, 17 Mar 2011 16:11: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 B2F3A3A6B39 for ; Thu, 17 Mar 2011 16:11:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJcygk2tJXG8/2dsb2JhbAClVXemdJwXhWMEjF6DTQ X-IronPort-AV: E=Sophos;i="4.63,202,1299456000"; d="scan'208";a="668313282" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 17 Mar 2011 23:13:27 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2HNDPKv013831; Thu, 17 Mar 2011 23:13:26 GMT Message-ID: <4D82959A.7010607@raszuk.net> Date: Fri, 18 Mar 2011 00:13:30 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yakov Rekhter References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> <066.bbb0590b3eaf4ea64606607d76c438d9@trac.tools.ietf.org> <4D8241E3.9070101@joelhalpern.com> <201103171754.p2HHsdv28694@magenta.juniper.net> In-Reply-To: <201103171754.p2HHsdv28694@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #44: LISP vs existing (reported by Yakov 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, 17 Mar 2011 23:12:00 -0000 Hi Yakov, > There is a need to document which parts of "the system" have such > problem, and which parts of "the system" would need to deploy LISP > in order to solve this problem. As I said above, it would be fine > with me if this will be done in the LISP WG deployment document. Let me allow to observe that the document answering your question does already exit. It is RFC 4984 available at http://www.ietf.org/rfc/rfc4984.txt With this in mind justification and explanation of "the problem" is beyond the scope of LISP WG or for that matter any other working group which is focused to deliver their own approach to address "the problem". I believe that if there are questions reg the definition of the problem the tickets should be open against RFC4984 and not against any WGs working on the solutions for it. Many thx, R. From trac+lisp@trac.tools.ietf.org Fri Mar 18 06:26:46 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC983A68F9 for ; Fri, 18 Mar 2011 06:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 aq9NWQnFNDnu for ; Fri, 18 Mar 2011 06:26:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 837863A68F4 for ; Fri, 18 Mar 2011 06:26:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0Ziv-0006tQ-B1; Fri, 18 Mar 2011 06:28: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 18 Mar 2011 13:28:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/3#comment:2 Message-ID: <069.a8aa90f3641942492810306320b6d372@trac.tools.ietf.org> References: <060.1160706e8afb7f5d8d1e81053d148847@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <060.1160706e8afb7f5d8d1e81053d148847@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #3: lisp-ms security mechanism between ITR and map resolver 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: Fri, 18 Mar 2011 13:26:46 -0000 #3: lisp-ms security mechanism between ITR and map resolver Old description: > Currently, the interface between the ITR and map resolver has two > security concerns. > > * There is no integrity protection of the exchange between the ITR and > map resolver > > * An ITR accepts a reply from any ETR, which makes it hard to add > security. > > The only protection of the map reply is that it needs to have the same > nonce as the map request. Long term, that is unlikely to be good > enough. It will be impossible to provide protection against on-path > attackers who can observe the nonce unless cryptographic security is > used. I understand that the alt does not currently provide > cryptographic security. I don't know whether we'll conclude that is > adequate (although suspect we'll decide it's the best we can do for > the experimental version). However even if that is adequate, it seems > like in many deployments the path between the ITR and map resolver is > more open to attack than the path over the alt. For this reason I > suspect that cryptographic security is needed to the map resolver even > if it is not provided in the alt. > > If others disagree, I'm happy to hold this issue open until we've > actually done security analysis of the ITR map resolver security. I'm > not comfortable closing this issue before that analysis. > > If cryptographic security is provided between the ITR and map > resolver, it must meet the same requirements as security between the > ETR and map server. New description: Currently, the interface between the ITR and map resolver has two security concerns. * There is no integrity protection of the exchange between the ITR and map resolver * An ITR accepts a reply from any ETR, which makes it hard to add security. The only protection of the map reply is that it needs to have the same nonce as the map request. Long term, that is unlikely to be good enough. It will be impossible to provide protection against on-path attackers who can observe the nonce unless cryptographic security is used. I understand that the alt does not currently provide cryptographic security. I don't know whether we'll conclude that is adequate (although suspect we'll decide it's the best we can do for the experimental version). However even if that is adequate, it seems like in many deployments the path between the ITR and map resolver is more open to attack than the path over the alt. For this reason I suspect that cryptographic security is needed to the map resolver even if it is not provided in the alt. If others disagree, I'm happy to hold this issue open until we've actually done security analysis of the ITR map resolver security. I'm not comfortable closing this issue before that analysis. If cryptographic security is provided between the ITR and map resolver, it must meet the same requirements as security between the ETR and map server. -- Comment(by luigi@…): Reply sent by Vince Fuller: * Covered by the LISP-SEC draft, which will be proposed as a WG item in Prague. NOTE: ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: ms Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Mar 18 06:32:11 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDBCF3A68F4 for ; Fri, 18 Mar 2011 06:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 JnjeaLClzqzL for ; Fri, 18 Mar 2011 06:32:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3F86E3A68B1 for ; Fri, 18 Mar 2011 06:32:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0ZoC-0006He-Q1; Fri, 18 Mar 2011 06:33: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 18 Mar 2011 13:33:40 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/25#comment:1 Message-ID: <069.3bc2b8c62fcc1e472646d00cf7ed49fc@trac.tools.ietf.org> References: <060.d231c2fff311c375f62f929d7213d1c4@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <060.d231c2fff311c375f62f929d7213d1c4@trac.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+lisp@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] #25: Map Server to ETR security has no automated key management 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: Fri, 18 Mar 2011 13:32:12 -0000 #25: Map Server to ETR security has no automated key management Comment(by luigi@…): Reply sent by Vince Fuller: * Outside of the scope of the current document and explicitly stated in section 7 (Security Considerations) as a subject for future work. '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: ms Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Mar 18 06:33:27 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9741C3A68F4 for ; Fri, 18 Mar 2011 06:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 YN9Hu0seQQb1 for ; Fri, 18 Mar 2011 06:33:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DD6A03A68B1 for ; Fri, 18 Mar 2011 06:33:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0ZpQ-0000O2-Ii; Fri, 18 Mar 2011 06:34: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 18 Mar 2011 13:34:56 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/75#comment:1 Message-ID: <077.6b1ed16dfa1bfb8617a1bb26538866e1@trac.tools.ietf.org> References: <068.6f9a0735f72eae0748ba4895dfdda8c8@trac.tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <068.6f9a0735f72eae0748ba4895dfdda8c8@trac.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+lisp@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] #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: Fri, 18 Mar 2011 13:33:27 -0000 #75: Security of Map-Register message. Comment(by luigi@…): Reply sent by Vince Fuller: * Covered by the LISP-SEC, draft which will be proposed as a WG item in Prague. '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: ms Severity: - | Keywords: ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Mar 18 06:35:29 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6BB3A6915 for ; Fri, 18 Mar 2011 06:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 uo4lPZMBClqP for ; Fri, 18 Mar 2011 06:35:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D2AB23A690A for ; Fri, 18 Mar 2011 06:35:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0ZrO-00050w-HJ; Fri, 18 Mar 2011 06:36: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 18 Mar 2011 13:36:58 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/77#comment:2 Message-ID: <077.6a2121cb7840ab6fb8cfc0d482d9a875@trac.tools.ietf.org> References: <068.863221f9957e52ab837ccb12f1b9b2d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <068.863221f9957e52ab837ccb12f1b9b2d8@trac.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+lisp@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: Fri, 18 Mar 2011 13:35:29 -0000 #77: On the use of key-chaining for re-keying Comment(by luigi@…): Reply sent by Vince Fuller: * Outside of the scope of the current document and explicitly stated in section 7 (Security Considerations) as a subject for future work. '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: ms Severity: - | Keywords: ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Mar 18 06:41:08 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C1A3A68F9 for ; Fri, 18 Mar 2011 06:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 gboDjKzpBamD for ; Fri, 18 Mar 2011 06:41:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0A3453A68B1 for ; Fri, 18 Mar 2011 06:41:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0Zwr-00055B-N3; Fri, 18 Mar 2011 06:42: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 18 Mar 2011 13:42:37 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/78#comment:1 Message-ID: <077.34f4799b52214303e23d40ff2abd4168@trac.tools.ietf.org> References: <068.f713f8664a87d8479c836881ff78c848@trac.tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <068.f713f8664a87d8479c836881ff78c848@trac.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+lisp@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] #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: Fri, 18 Mar 2011 13:41:08 -0000 #78: Missing things (from J. Arkko's mail) Comment(by luigi@…): Reply sent by Vince Fuller: * This should really have been separated into several different issues. His point # 1 (propagating changes to mapping data) is covered by the SMR mechanism in the latest version draft-ietf-lisp. His point # 2 (one minute rate limit on Map-Registers) should be covered in the latest MS spec. His point # 3 (need for operational considerations section) should already be covered by the existance of section 5 (Open Issues and Considerations); if there are specific items he would like to see listed in that section, we welcome suggested text. His point # 4 (goal of experiment) is a vague and open-ended question; the authors believe that the goals of developing and deploying LISP are stated in the various document introductions and that no further explicit decription of what a large-scale, experimenal deployment will accomplish should be necessary; if Jari (or others) disagree, then we welcome suggested text. '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: minor | Component: ms Severity: - | Keywords: ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Mar 18 06:42:52 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF24A3A68F4 for ; Fri, 18 Mar 2011 06:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 eN4vGj15Emun for ; Fri, 18 Mar 2011 06:42:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0526D3A68B1 for ; Fri, 18 Mar 2011 06:42:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0ZyX-0005CB-HP; Fri, 18 Mar 2011 06:44: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 18 Mar 2011 13:44:21 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/79#comment:1 Message-ID: <077.e88434d5c0b0465555cfb4e7afc26abe@trac.tools.ietf.org> References: <068.e4cec7b5ffd26202146ed883ccf61822@trac.tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <068.e4cec7b5ffd26202146ed883ccf61822@trac.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+lisp@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] #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: Fri, 18 Mar 2011 13:42:52 -0000 #79: Editorial Issues (from J. Arkko's mail) Comment(by luigi@…): Reply sent by Vince Fuller: * The first point in this issue is more a comment on style rather than substance; the LISP document authors explicitly decided to put all of the message definitions in the base protocol document (draft-ietf-lisp) rather than to scatter them in the different subsystem documents. I thought that all of the typos and other editorial nits had been fixed in the -07 document but see that some remain; I'll fix those for -08. '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: ms Severity: - | Keywords: ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Mar 18 06:45:37 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB573A690A for ; Fri, 18 Mar 2011 06:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 GMxBVtgjMcIx for ; Fri, 18 Mar 2011 06:45:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1C10B3A68B1 for ; Fri, 18 Mar 2011 06:45:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0a1C-0006k1-Mf; Fri, 18 Mar 2011 06:47: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 18 Mar 2011 13:47:06 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/76#comment:1 Message-ID: <077.1b63a12893026f82cc283a25b73f21a3@trac.tools.ietf.org> References: <068.45fcdf374d9ef1d35ed4fb98f02886e5@trac.tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <068.45fcdf374d9ef1d35ed4fb98f02886e5@trac.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+lisp@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] #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: Fri, 18 Mar 2011 13:45:37 -0000 #76: Implication of using anycast addresses for Map-servers Comment(by luigi@…): Reply sent by Vince Fuller: * Outside of the scope of the current document which only describes use of anycast addresses for Map-Resolvers; use of anycast addresses for Map- Servers is not defined and is explicitly not recommended in section 4.4.1. '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: ms Severity: - | Keywords: ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Mar 18 06:47:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6A13A6903 for ; Fri, 18 Mar 2011 06:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 rqKeS+lW7Esv for ; Fri, 18 Mar 2011 06:47:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 246CD3A68F9 for ; Fri, 18 Mar 2011 06:47:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q0a33-0001jR-0z; Fri, 18 Mar 2011 06:49: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 18 Mar 2011 13:49:01 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/23#comment:2 Message-ID: <069.2c1c1d41c44c62214ec7e6e74133184f@trac.tools.ietf.org> References: <060.5ae30f807b9da31e01375a39e603e0c9@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <060.5ae30f807b9da31e01375a39e603e0c9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #23: inner source RLOC undefined in some cases 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: Fri, 18 Mar 2011 13:47:32 -0000 #23: inner source RLOC undefined in some cases Comment(by luigi@…): Reply sent by Vince Fuller: * The description of the tracker issue appears to be incorrect; the issue appears to be related to incompatible address family usage between source and destination of Map-Request. Dino stated in a response on 9/22/2009 that this scenario represents a misconfiguration. If this is not an acceptable response then perhaps the issue should be listed in section 5 (Open Issues and Considerations) as I don't have a solution. Alternatively, the issue owner is asked to propose a mechanism and provide suggested text. '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: minor | Component: ms Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From jmh@joelhalpern.com Fri Mar 18 10:53:04 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D103A69BD for ; Fri, 18 Mar 2011 10:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 MfLE2Bajs1jT for ; Fri, 18 Mar 2011 10:53:03 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id C26513A69B7 for ; Fri, 18 Mar 2011 10:53:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 824344300F5; Fri, 18 Mar 2011 10:54:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 8AF114300AC; Fri, 18 Mar 2011 10:54:32 -0700 (PDT) Message-ID: <4D839C5E.6050701@joelhalpern.com> Date: Fri, 18 Mar 2011 13:54:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp issue tracker References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@tools.ietf.org> <066.405e92d0f7fbce601456dfe48f0625b5@tools.ietf.org> In-Reply-To: <066.405e92d0f7fbce601456dfe48f0625b5@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp #48 (reopened): MAP-Replies returning different contents for a given EID (review 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: Fri, 18 Mar 2011 17:53:04 -0000 Yakov, this appears to be a request to explain the consequence of misconfiguration (misbehavior) of devices participating in LISP. While we do sometimes explain such things, it seems unusual to require that the document try to explain the consequences of every possible misconfiguration. Is there an underlying problem you see that drives the importance of this particular explanation? On 2/15/2011 9:44 AM, lisp issue tracker wrote: > #48: MAP-Replies returning different contents for a given EID (review by Y, > Rekhter) > > > Comment(by yakov@…): > > The proposed resolution still does not address the issue raised in this > ticket, namely to document the consequences if two entities do return MAP- > replies with different contents for a given EID. > From jmh@joelhalpern.com Fri Mar 18 11:00:20 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398FD3A69B7 for ; Fri, 18 Mar 2011 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 EbWxbNjw4No3 for ; Fri, 18 Mar 2011 11:00:19 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 513523A69A1 for ; Fri, 18 Mar 2011 11:00:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 460F04300CC; Fri, 18 Mar 2011 11:01:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 2A2594300D2; Fri, 18 Mar 2011 11:01:48 -0700 (PDT) Message-ID: <4D839E11.5050005@joelhalpern.com> Date: Fri, 18 Mar 2011 14:01:53 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yakov Rekhter References: <056.b29368296d1e29e9759ce0ee81e0c335@tools.ietf.org> <065.aed1c14a347a527acb0732109678ee7a@tools.ietf.org> <9F57B0F5-7735-4D5E-8A19-0CE8074A9D94@cisco.com> <201102211948.p1LJmCL55420@magenta.juniper.net> In-Reply-To: <201102211948.p1LJmCL55420@magenta.juniper.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp #113 (new): inbound traffic engineering support with LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:00:20 -0000 Yakov, I have looked at the ticket, and the email exchange captured below. Given that the deployment document talks about the scope over which LISP TE works; and given that the LISP documents talk about priority and how that affects the steering of traffic; I do not understand what more you are asking for. The LISP document should not be expected to become a traffic engineering tutorial, even if that (TE) is one of the possible uses of LISP. can you please clarify what you are looking for? Thank you, Joel On 2/21/2011 2:48 PM, Yakov Rekhter wrote: > Dino, > >> So we believe the usage guide will be a good place to put >> configuration details on how to use LISP for traffic engineering >> purposes. >> >> Having said that, we have these detailed references in draft-ietf- >> lisp-09.txt: > > This is all fine. But as I said in my comment, I'd like to see > *detailed* answers to the questions I raised in my e-mail to the > LISP WG mailing list on 6/1/2010. Having "these detailed references" > is not sufficient. > > Yakov. > >> >> (1) In the section describing priority and weight values in Map-Reply >> messages for both unicast and >> multicast flows: >> >> 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 relative weight 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.5 for a suggested hash algorithm to distribute load >> across locators with same priority and equal weight values. >> >> (2) In the Routing Locator Selection section: >> >> 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: >> >> [there are 5 bullet paragraphs that follow, see the spec since there >> is too much text to incorporate here]. >> >> (3) This paragrapgh in the Deployment Scenarios section 8: >> >> 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. >> >> Using tunnels with stretch greater than 1 can avoid congestion on the >> shortest paths. Much like repair LSPs in MPLS. >> >> Dino >> >> On Feb 15, 2011, at 10:45 AM, lisp issue tracker wrote: >> >>> #113: inbound traffic engineering support with LISP >>> >>> >>> Comment(by yakov@�): >>> >>> To add to the above, there should be a detailed description of how >>> TE-xTR >>> perform traffic engineering. This description should be sufficient to >>> address the questions I raised in my e-mail to the LISP WG mailing >>> list on 6/1/2010. > >>> -- >>> ------------------------------ >>> +--------------------------------------------- >>> Reporter: yakov@� | Owner: >>> Type: technical | Status: new >>> Priority: major | Component: draft-ietf-lisp >>> Severity: - | Keywords: >>> ------------------------------ >>> +--------------------------------------------- >>> >>> Ticket URL:>>> >>> lisp >>> LISP WG document issues >>> _______________________________________________ >>> 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 jmh@joelhalpern.com Fri Mar 18 11:36:48 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0BD73A69D0 for ; Fri, 18 Mar 2011 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.138 X-Spam-Level: X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 vAk8ABEU9Qx5 for ; Fri, 18 Mar 2011 11:36:48 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 0818C3A69B7 for ; Fri, 18 Mar 2011 11:36:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 01B844300EC; Fri, 18 Mar 2011 11:38:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 27DCA4300E5; Fri, 18 Mar 2011 11:38:17 -0700 (PDT) Message-ID: <4D83A69E.1030303@joelhalpern.com> Date: Fri, 18 Mar 2011 14:38:22 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp issue tracker References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> <077.28c2cc9862e26b7fbd5b68671092214a@trac.tools.ietf.org> In-Reply-To: <077.28c2cc9862e26b7fbd5b68671092214a@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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, 18 Mar 2011 18:36:48 -0000 Yakov, There is extensive text on the various RLOC maintenance mechanisms, including an entire section on how the ITR cleans up its cache. Are you asking for a pointer to the lisp-map-versioning document? Yours, Joel On 3/17/2011 12:14 PM, lisp issue tracker wrote: > #66: Strict RLOC ordering causing problems on mapping changes > > > Comment(by yakov@…): > > From the response to my comment: > > Thank you for your contribution to draft-ietf-lisp-06.txt. The draft > authors > have reviewed your comments but do not feel that changes to the document > are > warranted at this time. We think that the use of version numbers will > help > this. Its also important to note that LSBs are a hint and a > request/reply > exchange will confirm from the R-bits of the locators in the locator-set > which > are reachable or not. > > To close the ticket the draft authors should describe how the use of > version number will address the issues raised in the ticket. Likewise, the > authors should point to the specific text in the draft that makes it clear > that "LSBs are a hint" and thus are are not sufficient to determine > locator's reachability - a request/reply exchange will be required. > From jmh@joelhalpern.com Fri Mar 18 13:21:47 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6A33A6A19 for ; Fri, 18 Mar 2011 13:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, 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 3tQocJ9uVRA6 for ; Fri, 18 Mar 2011 13:21:46 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 28D1B3A6A09 for ; Fri, 18 Mar 2011 13:21:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1F8814300DF; Fri, 18 Mar 2011 13:23:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 4AF1F4300D2; Fri, 18 Mar 2011 13:23:15 -0700 (PDT) Message-ID: <4D83BF39.6080707@joelhalpern.com> Date: Fri, 18 Mar 2011 16:23:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp issue tracker References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> In-Reply-To: <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 18 Mar 2011 20:21:47 -0000 The general issue of authorization for address claims was noted early on as being something for later work, not within scope for the experiment. This is dealt with in greater detail, including some pointers to ideas that we believe will address the over-claiming problem (some initial, and some more complete ideas) are described in http://datatracker.ietf.org/doc/draft-saucez-lisp-security/, which will be discussed in the upcoming meeting and likely be a future work item for the working group. Based on this, I do not see any changes needed to the LISP document to resolve this ticket. Yours, Joel M. Halpern On 3/16/2011 4:02 PM, lisp issue tracker wrote: > #27: ETR may claim a larger prefix than is delegated to it > > Changes (by yakov@…): > > * status: closed => reopened > * resolution: fixed => > > > Comment: > > Before closing the ticket please document how the issue raised by the > ticket is resolved. > From vaf@cisco.com Fri Mar 18 14:29:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F153A68FE for ; Fri, 18 Mar 2011 14:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 mNscumkDbIDQ for ; Fri, 18 Mar 2011 14:28:57 -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 28C2E3A69C7 for ; Fri, 18 Mar 2011 14:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=371; q=dns/txt; s=iport; t=1300483827; x=1301693427; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=qp2q1f/DDLTlI9sU6ltigHr/Gx7aGmQb2EYZymjSCf4=; b=FrD0RYVkw5Xq0sqqdwpNwt3+nAhLV+5fGdFhh1EywJozkF2TIP+sAXw9 uoqx4T/iYYJNThIl9RsHUwBFHPSlVvimdey4Pehbyx6u1Q3I0Zr/FtXs+ GhnD/UowsLVMoXM/vh9cvdpnZvthPWUo8GbFxjR8qYctitsMFvWdtT1KF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIRrg02tJXG+/2dsb2JhbAClcneoCJwVhWMEhTE X-IronPort-AV: E=Sophos;i="4.63,207,1299456000"; d="scan'208";a="668655510" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-6.cisco.com with ESMTP; 18 Mar 2011 21:30:20 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2ILUKs2016440; Fri, 18 Mar 2011 21:30:20 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 0A99DE52D99; Fri, 18 Mar 2011 14:30:20 -0700 (PDT) Date: Fri, 18 Mar 2011 14:30:20 -0700 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20110318213019.GA26495@vaf-mac1.cisco.com> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> <4D83BF39.6080707@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D83BF39.6080707@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 18 Mar 2011 21:29:00 -0000 On Fri, Mar 18, 2011 at 04:23:21PM -0400, Joel M. Halpern wrote: > The general issue of authorization for address claims was noted early on > as being something for later work, not within scope for the experiment. Actually, this particular issue is directly addressed by LISP-SEC, which will be presented at the Prague IETF and proposed as a WG item. --Vince From hartmans@mit.edu Fri Mar 18 14:40:06 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530C03A6A2E for ; Fri, 18 Mar 2011 14:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.994 X-Spam-Level: X-Spam-Status: No, score=-102.994 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Y79dtL-0ELgn for ; Fri, 18 Mar 2011 14:40:05 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3CE5E3A6A28 for ; Fri, 18 Mar 2011 14:40:04 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5CAEE20384; Fri, 18 Mar 2011 17:38:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 331F64547; Fri, 18 Mar 2011 17:41:29 -0400 (EDT) From: Sam Hartman To: "Joel M. Halpern" References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> <4D83BF39.6080707@joelhalpern.com> Date: Fri, 18 Mar 2011 17:41:28 -0400 In-Reply-To: <4D83BF39.6080707@joelhalpern.com> (Joel M. Halpern's message of "Fri, 18 Mar 2011 16:23:21 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 18 Mar 2011 21:40:06 -0000 >>>>> "Joel" == Joel M Halpern writes: Joel> The general issue of authorization for address claims was Joel> noted early on as being something for later work, not within Joel> scope for the experiment. I certainly think it's true that SIDR-level authorization of addresses was noted even as early as chartering as out of scope. However, this sort of issue, especially to the extent that LISP differed from the existing Internet was definitely not ruled out for any definition of early that involved time when I was active. There were some discussions with Jari about what would be out of scope for the experiment and what would not. In any of those discussions I participated in, I don't recall anything that would rule this out of scope. So, I'd like a bit more detail about when this was ruled out of scope. Thanks, --Sam From jmh@joelhalpern.com Fri Mar 18 14:58:33 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC2C3A6A48 for ; Fri, 18 Mar 2011 14:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, 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 x-PWG5LysIgZ for ; Fri, 18 Mar 2011 14:58:32 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id EAA5A3A6A33 for ; Fri, 18 Mar 2011 14:58:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 015544300D2; Fri, 18 Mar 2011 15:00:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 129904300D1; Fri, 18 Mar 2011 15:00:01 -0700 (PDT) Message-ID: <4D83D5E7.3060809@joelhalpern.com> Date: Fri, 18 Mar 2011 18:00:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Sam Hartman References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> <4D83BF39.6080707@joelhalpern.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] #27: ETR may claim a larger prefix than is delegated to it 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, 18 Mar 2011 21:58:34 -0000 What I was refering to as out of scope, which is what seems to be asked for in the ticket, is the SIDR / RPKI work. (That work clearly applies. But it is not part of the current phase of the effort.) Having said that, I do not know what more you arse asking for relative to over-claiming. Also, I should also have pointed to http://datatracker.ietf.org/doc/draft-maino-lisp-sec/?include_text=1 as a relevant document. (two lisp-security documents, evne the chairs get confused.) Yours, Joel On 3/18/2011 5:41 PM, Sam Hartman wrote: >>>>>> "Joel" == Joel M Halpern writes: > > Joel> The general issue of authorization for address claims was > Joel> noted early on as being something for later work, not within > Joel> scope for the experiment. > > I certainly think it's true that SIDR-level authorization of addresses > was noted even as early as chartering as out of scope. > > However, this sort of issue, especially to the extent that LISP differed > from the existing Internet was definitely not ruled out for any > definition of early that involved time when I was active. > > There were some discussions with Jari about what would be out of scope > for the experiment and what would not. > In any of those discussions I participated in, I don't recall anything > that would rule this out of scope. > > So, I'd like a bit more detail about when this was ruled out of scope. > > Thanks, > > --Sam > From hartmans@mit.edu Fri Mar 18 15:32:48 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE0C3A6A76 for ; Fri, 18 Mar 2011 15:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.973 X-Spam-Level: X-Spam-Status: No, score=-102.973 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 q9-Y25L9-TF1 for ; Fri, 18 Mar 2011 15:32:47 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B681D3A6A53 for ; Fri, 18 Mar 2011 15:32:47 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2CEEF20384; Fri, 18 Mar 2011 18:31:22 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A48474547; Fri, 18 Mar 2011 18:34:13 -0400 (EDT) From: Sam Hartman To: "Joel M. Halpern" References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> <4D83BF39.6080707@joelhalpern.com> <4D83D5E7.3060809@joelhalpern.com> Date: Fri, 18 Mar 2011 18:34:13 -0400 In-Reply-To: <4D83D5E7.3060809@joelhalpern.com> (Joel M. Halpern's message of "Fri, 18 Mar 2011 18:00:07 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 18 Mar 2011 22:32:48 -0000 >>>>> "Joel" == Joel M Halpern writes: Joel> What I was refering to as out of scope, which is what seems to Joel> be asked for in the ticket, is the SIDR / RPKI work. (That Joel> work clearly applies. But it is not part of the current phase Joel> of the effort.) For a single address we get authorization through the combination of the nonce, return routability, and relationships of the map server and ALT. We get security similar to what the internet gives us today. When that ticket was written the difference is that the ETR can claim a larger block than is desired. In today's internet, to do that, some BGP speaker near the person claiming the address needs to claim the larger prefix. Then the BGP speakers between me and the point where that route get chosen need to not filter that information. In LISP, we push that all to the ETR. You could instead involve the map server in the dicision so that the ITR knows both the map server and the ETR agree with the claim of how big a block should be mapped. That brings it back to a BGP speaker. It's not perfect obviously and is not quite the same as today's model. I can think of a way to do this that I think involves no extra packets and no keying material, although it does involve a couple of hash operations. I'd be happy to discuss if people are interested. I actually think SIDR-like solutions are a bad fit for LISP or at least this problem in LISP. They're probably fine for securing the ALT. My rationale is that you don't want every ITR to need to download an entire RPKI repository, or to evaluate CRLs and signature chains. You want something far simpler than that. Another place to look for this sort of thing is how we've looked at securing route optimizations for NEMO. I don't think they have any standards (and I realize it's no longer in the NEMO group), but I thought they had non-RPKI-based approaches as well. From vaf@cisco.com Fri Mar 18 15:43:21 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50CF3A6A7D for ; Fri, 18 Mar 2011 15:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 fl05d1Z18o6f for ; Fri, 18 Mar 2011 15:43:21 -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 F0FB43A6A71 for ; Fri, 18 Mar 2011 15:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=805; q=dns/txt; s=iport; t=1300488291; x=1301697891; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=1hFnhF5FiiIty4uZPd5VclPWLzMs9IAbWYwU32lFEg8=; b=gJHeYG+R95GIth7DbMkdQmk7cGciIBd3XpJRECNKngvjnkRYxTxKI0Zs Pqm3RdImZVnMk9GcIkVcabIzPk9ZUWESOW1ZRkdb1t3mFPm9UjF/agYYa GjpuFgjzmO2RFvn6QvdWE/hl0FM0mNUBKOzGwX6cx0dO1tNgnXzbU+pBB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAId9g02tJXG8/2dsb2JhbACldHeITZ89nBmFYwSFMZN6 X-IronPort-AV: E=Sophos;i="4.63,207,1299456000"; d="scan'208";a="415988408" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-1.cisco.com with ESMTP; 18 Mar 2011 22:44:50 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2IMio2x001445; Fri, 18 Mar 2011 22:44:50 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 36B5EE55156; Fri, 18 Mar 2011 15:44:50 -0700 (PDT) Date: Fri, 18 Mar 2011 15:44:50 -0700 From: Vince Fuller To: Sam Hartman Message-ID: <20110318224450.GA30893@vaf-mac1.cisco.com> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> <4D83BF39.6080707@joelhalpern.com> <4D83D5E7.3060809@joelhalpern.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 issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 18 Mar 2011 22:43:21 -0000 > In LISP, we push that all to the ETR. > You could instead involve the map server in the dicision so that the > ITR knows both the map server and the ETR agree with the claim of how > big a block should be mapped. > That brings it back to a BGP speaker. > It's not perfect obviously and is not quite the same as today's model. > > I can think of a way to do this that I think involves no extra packets > and no keying material, although it does involve a couple of hash > operations. > I'd be happy to discuss if people are interested. Please see LISP-SEC (http://tools.ietf.org/html/draft-maino-lisp-sec-00) which describes a mechanism for adding authentication to the ITR-MS-ETR-ITR interaction. One of the LISP-SEC authors will also be following-up in this thread. --Vince From jmh@joelhalpern.com Fri Mar 18 15:53:28 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3F93A6A8C for ; Fri, 18 Mar 2011 15:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, 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 QpoQGMDi2GOg for ; Fri, 18 Mar 2011 15:53:27 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 5BE133A6A89 for ; Fri, 18 Mar 2011 15:53:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9649A4300DF; Fri, 18 Mar 2011 15:54:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id B2F534300BD; Fri, 18 Mar 2011 15:54:56 -0700 (PDT) Message-ID: <4D83E2C6.5050001@joelhalpern.com> Date: Fri, 18 Mar 2011 18:55:02 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Vince Fuller References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> <4D83BF39.6080707@joelhalpern.com> <4D83D5E7.3060809@joelhalpern.com> <20110318224450.GA30893@vaf-mac1.cisco.com> In-Reply-To: <20110318224450.GA30893@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 18 Mar 2011 22:53:28 -0000 I had missed one line in reading LISP-SEC. The suggestion is that the Map Server signs a block, based on the business registration, carrying the prefix information. And then the ETR forwards that. If I read this right, this provides over-claiming protection up to the level of the business relationship between the Map-Server and the ETR? I would not claim it is complete coverage, but that does provide more coverage. Are we intending to hold up the base LISP spec for this? Or phrased differently, do you folks think the LISP-SEC material is important enough that we should ensure it is in all the implementations? Yours, Joel On 3/18/2011 6:44 PM, Vince Fuller wrote: >> In LISP, we push that all to the ETR. >> You could instead involve the map server in the dicision so that the >> ITR knows both the map server and the ETR agree with the claim of how >> big a block should be mapped. >> That brings it back to a BGP speaker. >> It's not perfect obviously and is not quite the same as today's model. >> >> I can think of a way to do this that I think involves no extra packets >> and no keying material, although it does involve a couple of hash >> operations. >> I'd be happy to discuss if people are interested. > > Please see LISP-SEC (http://tools.ietf.org/html/draft-maino-lisp-sec-00) > which describes a mechanism for adding authentication to the ITR-MS-ETR-ITR > interaction. > > One of the LISP-SEC authors will also be following-up in this thread. > > --Vince > From vaf@cisco.com Fri Mar 18 16:19:21 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119FA3A6A96 for ; Fri, 18 Mar 2011 16:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.259 X-Spam-Level: X-Spam-Status: No, score=-10.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 fO24lX-eRLim for ; Fri, 18 Mar 2011 16:19:20 -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 D87233A6A8C for ; Fri, 18 Mar 2011 16:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=1803; q=dns/txt; s=iport; t=1300490450; x=1301700050; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=VFbHBGCbQXdWtmtRlJdBw0BYPExvAelRXi4Egs15lpE=; b=GQ8xyYaYxXtakXeGBVvbO4kroYV1Ec/dXRiLr+Zw0gmrWbofVVseFziF XvwZFMAMQmwA3v5YJbYEPSC6bFhPoHT0hPVRj9ou5KhAIo1as3x/lpgst /XCLL2HxZmDPtmkptLBcvxu3xK6hJq7wkeqp4rhOQPzroC4ZPezXuqD+P k=; X-IronPort-AV: E=Sophos;i="4.63,207,1299456000"; d="scan'208";a="668680218" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-6.cisco.com with ESMTP; 18 Mar 2011 23:20:49 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2INKnlg032217; Fri, 18 Mar 2011 23:20:49 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 326C6E55B69; Fri, 18 Mar 2011 16:20:49 -0700 (PDT) Date: Fri, 18 Mar 2011 16:20:49 -0700 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20110318232049.GA33063@vaf-mac1.cisco.com> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> <4D83BF39.6080707@joelhalpern.com> <4D83D5E7.3060809@joelhalpern.com> <20110318224450.GA30893@vaf-mac1.cisco.com> <4D83E2C6.5050001@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D83E2C6.5050001@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 18 Mar 2011 23:19:21 -0000 On Fri, Mar 18, 2011 at 06:55:02PM -0400, Joel M. Halpern wrote: > I had missed one line in reading LISP-SEC. > The suggestion is that the Map Server signs a block, based on the > business registration, carrying the prefix information. > And then the ETR forwards that. > > If I read this right, this provides over-claiming protection up to the > level of the business relationship between the Map-Server and the ETR? Where else could one propose putting such checks? > I would not claim it is complete coverage, but that does provide more > coverage. As with so many other things in the Internet, security will be used if the operations community decides it is important. LISP-SEC is intended to offer a mechanism for implementing authentication between ITR, MR, MS, and ETR; whether it is actually enabled and used is quite beyond the scope of both this discussion and the LISP WG charter. > Are we intending to hold up the base LISP spec for this? Or phrased > differently, do you folks think the LISP-SEC material is important > enough that we should ensure it is in all the implementations? No, we should absolutely not hold up publication of the documents that are already within the charter of the LISP WG. Past attempts to mandate security in parts of the Internet architecture have pretty much universally resulted in failure of technology to be adopted; the lesson of history is that one can define robust security mechanisms and encourage their implementation and deployment but the market will ultimately decide whether they are actually used. I believe that the LISP effort has done proper "due dilligence" in addressing security concerns by defining appropriate technology; we cannot reasonably be expected to do more than that. --Vince From fmaino@cisco.com Fri Mar 18 16:28:14 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF6C3A6A6A for ; Fri, 18 Mar 2011 16:28:14 -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=[AWL=-0.000, 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 E2XxtSpekie9 for ; Fri, 18 Mar 2011 16:28:12 -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 165D73A6A33 for ; Fri, 18 Mar 2011 16:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fmaino@cisco.com; l=7539; q=dns/txt; s=iport; t=1300490982; x=1301700582; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=xFSCE6CKmrtFdz+epEPkvJCTSg0njJGfndHVpvLy0d0=; b=YY3nU1zkgM4wuHKpGuakLEE8Yzy50CAq3XuBYrc6hMtl3vc7FNzIgxMm YsaMPVaFk3Y2eDR9y3luJGev1NrxcahQtxGhIuBImgWrWgORLGZgop4oZ y+F6OzSdRqXb1ZbWpfLjrHBDFn23mrP1zULDpt3AqWoUuuhdRUegoWtjV 4=; X-IronPort-AV: E=Sophos;i="4.63,207,1299456000"; d="scan'208,217";a="322008406" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2011 23:29:41 +0000 Received: from dhcp-128-107-166-128.cisco.com (dhcp-128-107-166-128.cisco.com [128.107.166.128]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2INTfBp020876; Fri, 18 Mar 2011 23:29:41 GMT Message-ID: <4D83EAE4.6040905@cisco.com> Date: Fri, 18 Mar 2011 16:29:40 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Joel M. Halpern" References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org><069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org><4D83BF39.6080707@joelhalpern.com> <4D83D5E7.3060809@joelhalpern.com> <20110318224450.GA30893@vaf-mac1.cisco.com> <4D83E2C6.5050001@joelhalpern.com> In-Reply-To: <4D83E2C6.5050001@joelhalpern.com> Content-Type: multipart/alternative; boundary="------------010706090706070109010404" Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 18 Mar 2011 23:28:14 -0000 This is a multi-part message in MIME format. --------------010706090706070109010404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/18/11 3:55 PM, Joel M. Halpern wrote: > > I had missed one line in reading LISP-SEC. > The suggestion is that the Map Server signs a block, based on the > business registration, carrying the prefix information. > And then the ETR forwards that. > > If I read this right, this provides over-claiming protection up to the > level of the business relationship between the Map-Server and the ETR? > No, it's more than that. The threat model assumes that the Mapping System is trusted, but the ETR can get compromised (or be malicious). To prevent the ETR from overclaiming, the EID prefix information is signed by the Map-Server with the OTK. A KDF is applied to the OTK to derive the OTK-ETR, that is passed to the ETR to protect the integrity of the Map-Reply. The KDF is non-invertible, so the ETR cannot impersonate the Map-Server and forge the authenticated EID-prefix authorization data signed by the Map-Server. Fabio > > > I would not claim it is complete coverage, but that does provide more > coverage. > > Are we intending to hold up the base LISP spec for this? Or phrased > differently, do you folks think the LISP-SEC material is important > enough that we should ensure it is in all the implementations? > > Yours, > Joel > > On 3/18/2011 6:44 PM, Vince Fuller wrote: > >> In LISP, we push that all to the ETR. > >> You could instead involve the map server in the dicision so that the > >> ITR knows both the map server and the ETR agree with the claim of how > >> big a block should be mapped. > >> That brings it back to a BGP speaker. > >> It's not perfect obviously and is not quite the same as today's model. > >> > >> I can think of a way to do this that I think involves no extra packets > >> and no keying material, although it does involve a couple of hash > >> operations. > >> I'd be happy to discuss if people are interested. > > > > Please see LISP-SEC (http://tools.ietf.org/html/draft-maino-lisp-sec-00) > > which describes a mechanism for adding authentication to the > ITR-MS-ETR-ITR > > interaction. > > > > One of the LISP-SEC authors will also be following-up in this thread. > > > > --Vince > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- Fabio Maino fmaino@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------010706090706070109010404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/18/11 3:55 PM, Joel M. Halpern wrote:
Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it

I had missed one line in reading LISP-SEC.
The suggestion is that the Map Server signs a block, based on the
business registration, carrying the prefix information.
And then the ETR forwards that.

If I read this right, this provides over-claiming protection up to the
level of the business relationship between the Map-Server and the ETR?

No, it's more than that. The threat model assumes that the Mapping System is trusted, but the ETR can get compromised (or be malicious). To prevent the ETR from overclaiming, the EID prefix information is signed by the Map-Server with the OTK. A KDF is applied to the OTK to derive the OTK-ETR, that is passed to the ETR to protect the integrity of the Map-Reply. The KDF is non-invertible, so the ETR cannot impersonate the Map-Server and forge the authenticated EID-prefix authorization data signed by the Map-Server.

Fabio


I would not claim it is complete coverage, but that does provide more
coverage.

Are we intending to hold up the base LISP spec for this?  Or phrased
differently, do you folks think the LISP-SEC material is important
enough that we should ensure it is in all the implementations?

Yours,
Joel

On 3/18/2011 6:44 PM, Vince Fuller wrote:
>> In LISP, we push that all to the ETR.
>> You could instead involve the map server  in the dicision so that the
>> ITR  knows  both the map server and the ETR agree with the claim of how
>> big a block should be mapped.
>> That brings it back to a BGP speaker.
>> It's not perfect obviously and is not quite the same as today's model.
>>
>> I can think of a way to do this  that I think involves no extra packets
>> and no keying material, although it does involve a couple of hash
>> operations.
>> I'd be happy to discuss if people are interested.
>
> Please see LISP-SEC (http://tools.ietf.org/html/draft-maino-lisp-sec-00)
> which describes a mechanism for adding authentication to the ITR-MS-ETR-ITR
> interaction.
>
> One of the LISP-SEC authors will also be following-up in this thread.
>
>       --Vince
>
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
 



-- 
Fabio Maino
fmaino@cisco.com

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------010706090706070109010404-- From trac+lisp@trac.tools.ietf.org Mon Mar 21 02:02:42 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3083A67F5 for ; Mon, 21 Mar 2011 02:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 JVddOrtsz86g for ; Mon, 21 Mar 2011 02:02:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B383E3A6783 for ; Mon, 21 Mar 2011 02:02:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q1b25-0005cY-AU; Mon, 21 Mar 2011 02:04: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Mon, 21 Mar 2011 09:04:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/21#comment:1 Message-ID: <069.22313936c5e48b103585f0c71a7491ef@trac.tools.ietf.org> References: <060.2f6008fac67bff8ffd8bab747df7cd0b@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <060.2f6008fac67bff8ffd8bab747df7cd0b@trac.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+lisp@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] #21: Section 5.1 behavior 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, 21 Mar 2011 09:02:42 -0000 #21: Section 5.1 behavior Comment(by luigi@…): Reply sent by Vince Fuller:  * Does this issue still apply to the current section 5.1 in the current (06) ALT draft? The issue text doesn't seem to make sence in the context of the current text. '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: minor | Component: alt Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Mon Mar 21 02:04:54 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E85A3A6804 for ; Mon, 21 Mar 2011 02:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 LnRnAR8JXl7K for ; Mon, 21 Mar 2011 02:04:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 75AA33A6802 for ; Mon, 21 Mar 2011 02:04:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q1b4E-0005q4-5v; Mon, 21 Mar 2011 02:06: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Mon, 21 Mar 2011 09:06:26 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/114#comment:1 Message-ID: <065.869ff5351ad0fcdaab3027d0cfdf939c@trac.tools.ietf.org> References: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 114 In-Reply-To: <056.ca586cec75063f6a58e2730d802ad6dd@trac.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+lisp@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] #114: EID-to-RLOC mapping - transients 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, 21 Mar 2011 09:04:54 -0000 #114: EID-to-RLOC mapping - transients Comment(by luigi@…): Reply sent by Vince Fuller:  * Just as with routing protocols or any other distributed database, there will inevitibly be short windows where an update to the configuration on one device can lag an update to another device; configuring multiple ETRs with the same EID-to-RLOC mappings is no different. The existing text describes proper practice when configuration devices; the authors do not feel it is necessary to specifically state that the world won't come to an end if multiple ETRs with the same database mappings do not have their configurations updated at pricesly the same instant. If the issue author or another WG member believes that an explicit warning is necessary then the document authors welcome suggested text. '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: new Priority: major | Component: alt Severity: - | Keywords: ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Mon Mar 21 02:11:07 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4403A6803 for ; Mon, 21 Mar 2011 02:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 63--wybtVAZG for ; Mon, 21 Mar 2011 02:11:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 485543A67A8 for ; Mon, 21 Mar 2011 02:11:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q1bAC-0003UZ-TD; Mon, 21 Mar 2011 02:12: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Mon, 21 Mar 2011 09:12:36 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/22#comment:3 Message-ID: <069.84a6f288555db741da0ea1cafc59cfaf@trac.tools.ietf.org> References: <060.ea8474f8e9e720ff4a5501041a5c944c@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <060.ea8474f8e9e720ff4a5501041a5c944c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #22: An ETR MUST consume UDP port 4342 packets not addressed to it 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, 21 Mar 2011 09:11:07 -0000 #22: An ETR MUST consume UDP port 4342 packets not addressed to it Comment(by luigi@…): Reply sent by Vince Fuller:  * My reading of email records indicates that this issue was folded-in to #24 which was according to an email update sent on 8 December 2009. Cited email concerning #24: http://www.ietf.org/mail- archive/web/lisp/current/msg01828.html '''Note:''' ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: alt Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Mon Mar 21 12:48:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05433A6856 for ; Mon, 21 Mar 2011 12:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 rvjUuzaXYqCe for ; Mon, 21 Mar 2011 12:48:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 21D463A684D for ; Mon, 21 Mar 2011 12:48:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q1l6Y-000175-8E; Mon, 21 Mar 2011 12:49: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Mon, 21 Mar 2011 19:49:30 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/114#comment:2 Message-ID: <065.b238550397a09cec76bf9be039cf3f85@trac.tools.ietf.org> References: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 114 In-Reply-To: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #114: EID-to-RLOC mapping - transients 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, 21 Mar 2011 19:48:00 -0000 #114: EID-to-RLOC mapping - transients Comment(by yakov@…): To address the issue please add the following after "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." Note that there may be transient conditions when the EID-prefix for the site and locator-set for each EID-prefix MAY not be the same on all ETRs. As a result, for the duration of these transient conditions not all the ETRs would be able to send Map-Reply messages with the same database mapping contents. Furthermore, if the authors think that sending inconsistent Map-Reply during transients has no negative implications, then add the following at the end of the text I suggested above: This has no negative implications. And if the authors think that sending inconsistent Map-Reply during transients does have negative implications, then the authors should list them following the text I suggested above. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: new Priority: major | Component: alt Severity: - | Keywords: ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From lear@cisco.com Mon Mar 21 12:56:24 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D16728C0DF for ; Mon, 21 Mar 2011 12:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.626 X-Spam-Level: X-Spam-Status: No, score=-110.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 VtVlILkErm3i for ; Mon, 21 Mar 2011 12:56:17 -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 475FF28C0DD for ; Mon, 21 Mar 2011 12:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1993; q=dns/txt; s=iport; t=1300737470; x=1301947070; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0ao+9yUKlfvPlsRDyJS/SHS+cvZqJq5njldonFGh84Q=; b=iLDRhOYjwJ34epQp+Cr2F0//skM8ZaNxpdya1fj9lLkAOHYDy2pOnicq 9NWQeqxeegDF8tZeYolN245nGHKXvpv280XkOl3Bm/ogEep9QBBNk5Ptn ISbcHw+ILqErl3zWzz5/fpFPPyZyv33/8svgPKz/lyk7iK0AMRWWbs0tW k=; X-IronPort-AV: E=Sophos;i="4.63,220,1299456000"; d="scan'208";a="80129402" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2011 19:57:49 +0000 Received: from ams3-vpn-dhcp6592.cisco.com (ams3-vpn-dhcp6592.cisco.com [10.61.89.191]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2LJvmiD015217; Mon, 21 Mar 2011 19:57:49 GMT Message-ID: <4D87AD94.2000504@cisco.com> Date: Mon, 21 Mar 2011 20:57:08 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Joel M. Halpern" References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.a3dd071174a9e4d1edf923b613cf08da@trac.tools.ietf.org> <4D83BF39.6080707@joelhalpern.com> <4D83D5E7.3060809@joelhalpern.com> <20110318224450.GA30893@vaf-mac1.cisco.com> <4D83E2C6.5050001@joelhalpern.com> In-Reply-To: <4D83E2C6.5050001@joelhalpern.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 21 Mar 2011 19:56:24 -0000 Joel, Recalling that we're producing experimental RFCs, I don't see a need to hold up any of this. I would expect continued evolution of the work even after the docs go to the editor. Do others disagree? Eliot On 3/18/11 11:55 PM, Joel M. Halpern wrote: > I had missed one line in reading LISP-SEC. > The suggestion is that the Map Server signs a block, based on the > business registration, carrying the prefix information. > And then the ETR forwards that. > > If I read this right, this provides over-claiming protection up to the > level of the business relationship between the Map-Server and the ETR? > > I would not claim it is complete coverage, but that does provide more > coverage. > > Are we intending to hold up the base LISP spec for this? Or phrased > differently, do you folks think the LISP-SEC material is important > enough that we should ensure it is in all the implementations? > > Yours, > Joel > > On 3/18/2011 6:44 PM, Vince Fuller wrote: >>> In LISP, we push that all to the ETR. >>> You could instead involve the map server in the dicision so that the >>> ITR knows both the map server and the ETR agree with the claim of how >>> big a block should be mapped. >>> That brings it back to a BGP speaker. >>> It's not perfect obviously and is not quite the same as today's model. >>> >>> I can think of a way to do this that I think involves no extra packets >>> and no keying material, although it does involve a couple of hash >>> operations. >>> I'd be happy to discuss if people are interested. >> >> Please see LISP-SEC (http://tools.ietf.org/html/draft-maino-lisp-sec-00) >> which describes a mechanism for adding authentication to the >> ITR-MS-ETR-ITR >> interaction. >> >> One of the LISP-SEC authors will also be following-up in this thread. >> >> --Vince >> > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From yakov@juniper.net Mon Mar 21 13:12:13 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE09C28C0D7 for ; Mon, 21 Mar 2011 13:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.109 X-Spam-Level: X-Spam-Status: No, score=-106.109 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 PC7AUHAEOzOG for ; Mon, 21 Mar 2011 13:12:13 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 3417528B56A for ; Mon, 21 Mar 2011 13:12:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTYexcvqVJhhvKA4iHtLlhIUY9RKRDUCF@postini.com; Mon, 21 Mar 2011 13:13:44 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Mar 2011 13:10:09 -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 p2LKBPv01730; Mon, 21 Mar 2011 13:11:25 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103212011.p2LKBPv01730@magenta.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4D839C5E.6050701@joelhalpern.com> References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@tools.ietf.org> <066.405e92d0f7fbce601456dfe48f0625b5@tools.ietf.org> <4D839C5E.6050701@joelhalpern.com> X-MH-In-Reply-To: "Joel M. Halpern" message dated "Fri, 18 Mar 2011 13:54:38 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <88964.1300738285.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Mar 2011 13:11:25 -0700 From: Yakov Rekhter Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp #48 (reopened): MAP-Replies returning different contents for a given EID (review 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: Mon, 21 Mar 2011 20:12:13 -0000 Joel, > Yakov, this appears to be a request to explain the consequence of = > misconfiguration (misbehavior) of devices participating in LISP. While = > we do sometimes explain such things, it seems unusual to require that = > the document try to explain the consequences of every possible = > misconfiguration. > Is there an underlying problem you see that drives the importance of = > this particular explanation? Misconfiguration is certainly one possible reason when not all the ETRs would send Map-Reply with the same database mapping contents. But it is not the only one possible - another possible reason is during transients - see my response to #114. And as I mentioned in my response to #114, the authors should either (a) state in the draft that there are no drawbacks when inconsistent replies are sent, or (b) list in the draft (at least some of) the drawbacks when inconsistent replies are sent. Yakov. > = > On 2/15/2011 9:44 AM, lisp issue tracker wrote: > > #48: MAP-Replies returning different contents for a given EID (review = by Y, > > Rekhter) > > > > > > Comment(by yakov@=E2=80=A6): > > > > The proposed resolution still does not address the issue raised in t= his > > ticket, namely to document the consequences if two entities do retur= n MAP - > > replies with different contents for a given EID. > > From yakov@juniper.net Mon Mar 21 17:59:11 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176FB28C197 for ; Mon, 21 Mar 2011 17:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 IlBGhSD9NtTM for ; Mon, 21 Mar 2011 17:59:10 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 37A6628C1A7 for ; Mon, 21 Mar 2011 17:59:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTYf0tiEbG4dnSVhp9UN8wK2XyKfdZrXI@postini.com; Mon, 21 Mar 2011 18:00:43 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Mar 2011 17:57:53 -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 p2M0xAv25574; Mon, 21 Mar 2011 17:59:10 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103220059.p2M0xAv25574@magenta.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4D839E11.5050005@joelhalpern.com> References: <056.b29368296d1e29e9759ce0ee81e0c335@tools.ietf.org> <065.aed1c14a347a527acb0732109678ee7a@tools.ietf.org> <9F57B0F5-7735-4D5E-8A19-0CE8074A9D94@cisco.com> <201102211948.p1LJmCL55420@magenta.juniper.net> <4D839E11.5050005@joelhalpern.com> X-MH-In-Reply-To: "Joel M. Halpern" message dated "Fri, 18 Mar 2011 14:01:53 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <6289.1300755550.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Mar 2011 17:59:10 -0700 From: Yakov Rekhter Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp #113 (new): inbound traffic engineering support with LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 00:59:11 -0000 Joel, > Yakov, I have looked at the ticket, and the email exchange captured bel= ow. > Given that the deployment document talks about the scope over which LISP= = > TE works; > and given that the LISP documents talk about priority and how that = > affects the steering of traffic; > I do not understand what more you are asking for. The LISP document = > should not be expected to become a traffic engineering tutorial, even if= = > that (TE) is one of the possible uses of LISP. > = > can you please clarify what you are looking for? Given that the use of LISP for TE is documented in the deployment document, please add a pointer to the deployment document at the end of the following sentence in Section 4: An obvious instance of this would be an ISP router that needs to perform traffic engineering for packets flowing through its network. Yakov. > = > Thank you, > Joel > = > = > On 2/21/2011 2:48 PM, Yakov Rekhter wrote: > > Dino, > > > >> So we believe the usage guide will be a good place to put > >> configuration details on how to use LISP for traffic engineering > >> purposes. > >> > >> Having said that, we have these detailed references in draft-ietf- > >> lisp-09.txt: > > > > This is all fine. But as I said in my comment, I'd like to see > > *detailed* answers to the questions I raised in my e-mail to the > > LISP WG mailing list on 6/1/2010. Having "these detailed references" > > is not sufficient. > > > > Yakov. > > > >> > >> (1) In the section describing priority and weight values in Map-Reply > >> messages for both unicast and > >> multicast flows: > >> > >> Priority: each RLOC is assigned a unicast priority. Lower valu= es > >> are more preferable. When multiple RLOCs have the same prior= ity, > >> they may be used in a load-split fashion. A value of 255 mea= ns > >> the RLOC MUST NOT be used for unicast forwarding. > >> > >> Weight: when priorities are the same for multiple RLOCs, the we= ight > >> indicates how to balance unicast traffic between them. Weigh= t is > >> encoded as a relative weight of total unicast packets that ma= tch > >> the mapping entry. If a non-zero weight value is used for an= y > >> RLOC, then all RLOCs MUST use a non-zero weight value and the= n > >> 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 traff= ic. > >> See Section 6.5 for a suggested hash algorithm to distribute = load > >> across locators with same priority and equal weight values. > >> > >> (2) In the Routing Locator Selection section: > >> > >> Both client-side and server-side may need control over the selec= tion > >> of RLOCs for conversations between them. This control is achiev= ed > >> by > >> manipulating the Priority and Weight fields in EID-to-RLOC Map-R= eply > >> 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: > >> > >> [there are 5 bullet paragraphs that follow, see the spec since there > >> is too much text to incorporate here]. > >> > >> (3) This paragrapgh in the Deployment Scenarios section 8: > >> > >> o Recursive tunneling is when tunneled traffic is again further > >> encapsulated in another tunnel, either to implement VPNs or t= o > >> perform Traffic Engineering. When doing VPN-based tunneling,= the > >> site has some control since the site is prepending a new tunn= el > >> 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 th= e > >> benefit of steering traffic to resource available parts of th= e > >> network. > >> > >> Using tunnels with stretch greater than 1 can avoid congestion on the > >> shortest paths. Much like repair LSPs in MPLS. > >> > >> Dino > >> > >> On Feb 15, 2011, at 10:45 AM, lisp issue tracker wrote: > >> > >>> #113: inbound traffic engineering support with LISP > >>> > >>> > >>> Comment(by yakov@=EF=BF=BD): > >>> > >>> To add to the above, there should be a detailed description of how > >>> TE-xTR > >>> perform traffic engineering. This description should be sufficient t= o > >>> address the questions I raised in my e-mail to the LISP WG mailing > >>> list on 6/1/2010. > > > >>> -- > >>> ------------------------------ > >>> +--------------------------------------------- > >>> Reporter: yakov@=EF=BF=BD | Owner: > >>> Type: technical | Status: new > >>> Priority: major | Component: draft-ietf-lisp > >>> Severity: - | Keywords: > >>> ------------------------------ > >>> +--------------------------------------------- > >>> > >>> Ticket URL: >>>> > >>> lisp > >>> LISP WG document issues > >>> _______________________________________________ > >>> 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 Tue Mar 22 05:53:23 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75DA28C113 for ; Tue, 22 Mar 2011 05:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.091 X-Spam-Level: X-Spam-Status: No, score=-106.091 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 eMGQ7lP+yvkq for ; Tue, 22 Mar 2011 05:53:20 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 1B2EA28C10E for ; Tue, 22 Mar 2011 05:53:18 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTYicFUDYK/BxCNhEmN/uowhQk0sA9ODu@postini.com; Tue, 22 Mar 2011 05:54:53 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Mar 2011 05:52:39 -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 p2MCruv42309; Tue, 22 Mar 2011 05:53:56 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103221253.p2MCruv42309@magenta.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4D83A69E.1030303@joelhalpern.com> References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> <077.28c2cc9862e26b7fbd5b68671092214a@trac.tools.ietf.org> <4D83A69E.1030303@joelhalpern.com> X-MH-In-Reply-To: "Joel M. Halpern" message dated "Fri, 18 Mar 2011 14:38:22 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <34056.1300798436.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Mar 2011 05:53:56 -0700 From: Yakov Rekhter Cc: lisp issue tracker , 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 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, 22 Mar 2011 12:53:23 -0000 Joel, > Yakov, > There is extensive text on the various RLOC maintenance mechanisms,= = > including an entire section on how the ITR cleans up its cache. Are you= = > asking for a pointer to the lisp-map-versioning document? The problem raised in the ticket has to do with the following. Quoting from Section 6.6: 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. The above covers the case when a new locator record is appended to the end of the list. The above does *not* cover the case where (due to the algorithm used for ordering) a new locator record has to be inserted in the middle of the list. To cover this new text should be added right after the text I quoted above. Yakov. > = > Yours, > Joel > = > On 3/17/2011 12:14 PM, lisp issue tracker wrote: > > #66: Strict RLOC ordering causing problems on mapping changes > > > > > > Comment(by yakov@=E2=80=A6): > > > > From the response to my comment: > > > > Thank you for your contribution to draft-ietf-lisp-06.txt. The dra= ft > > authors > > have reviewed your comments but do not feel that changes to the do= cumen t > > are > > warranted at this time. We think that the use of version numbers w= ill > > help > > this. Its also important to note that LSBs are a hint and a > > request/reply > > exchange will confirm from the R-bits of the locators in the locat= or-se t > > which > > are reachable or not. > > > > To close the ticket the draft authors should describe how the use of > > version number will address the issues raised in the ticket. Likewis= e, th e > > authors should point to the specific text in the draft that makes it= clea r > > that "LSBs are a hint" and thus are are not sufficient to determine > > locator's reachability - a request/reply exchange will be required. > > From trac+lisp@trac.tools.ietf.org Tue Mar 22 06:04:34 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687DB28C11D for ; Tue, 22 Mar 2011 06:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 UBQNe-j9bG8M for ; Tue, 22 Mar 2011 06:04:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B819828C11F for ; Tue, 22 Mar 2011 06:04:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q21Hb-0004QL-1N; Tue, 22 Mar 2011 06:05: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Tue, 22 Mar 2011 13:05:58 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/44#comment:7 Message-ID: <066.37020421efb78b01e3dd386b60ac8c8d@trac.tools.ietf.org> References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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: Tue, 22 Mar 2011 13:04:34 -0000 #44: LISP vs existing (reported by Yakov Rekhter) Changes (by yakov@…): * status: reopened => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 22 06:04:46 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7640E28C127 for ; Tue, 22 Mar 2011 06:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 GrkPk+4ZhV2U for ; Tue, 22 Mar 2011 06:04:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CB40428C123 for ; Tue, 22 Mar 2011 06:04:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q21Ht-0004SJ-Gd; Tue, 22 Mar 2011 06:06: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Tue, 22 Mar 2011 13:06:17 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/44#comment:8 Message-ID: <066.e4da71daa51de8aaae0f9384dafb7d7c@trac.tools.ietf.org> References: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.598d71d19cb14b43d07dda5b5aaa388e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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: Tue, 22 Mar 2011 13:04:46 -0000 #44: LISP vs existing (reported by Yakov Rekhter) Changes (by yakov@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 22 06:29:42 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1AC28C126 for ; Tue, 22 Mar 2011 06:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 17WEKVFspkpf for ; Tue, 22 Mar 2011 06:29:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A585328C0D0 for ; Tue, 22 Mar 2011 06:29:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q21g2-0005db-SZ; Tue, 22 Mar 2011 06:31: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Tue, 22 Mar 2011 13:31:14 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/115 Message-ID: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-Trac-Ticket-ID: 115 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #115: claims in Section 7 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: Tue, 22 Mar 2011 13:29:42 -0000 #115: claims in Section 7 From Section 7: LISP is designed to be very hardware-based forwarding friendly. .... No changes to existing, deployed hardware should be needed to support this. Please delete the text quoted above from the spec. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From luigi@net.t-labs.tu-berlin.de Tue Mar 22 06:46:42 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA4728C0F4 for ; Tue, 22 Mar 2011 06:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.299, 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 GbWsMgrJnJ3x for ; Tue, 22 Mar 2011 06:46:42 -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 A1CF628C0EC for ; Tue, 22 Mar 2011 06:46:41 -0700 (PDT) Received: from dyn117.net.t-labs.tu-berlin.de (dyn117.net.t-labs.tu-berlin.de [130.149.220.117]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id DFC2170015AA; Tue, 22 Mar 2011 14:48:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Luigi Iannone In-Reply-To: <201103221253.p2MCruv42309@magenta.juniper.net> Date: Tue, 22 Mar 2011 14:48:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F47C1C6-815F-461A-A4FA-2E8C9F945D2C@net.t-labs.tu-berlin.de> References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> <077.28c2cc9862e26b7fbd5b68671092214a@trac.tools.ietf.org> <4D83A69E.1030303@joelhalpern.com> <201103221253.p2MCruv42309@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1084) Cc: lisp issue tracker , 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 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, 22 Mar 2011 13:46:42 -0000 Hi, I think that the misleading sentence is the first one: > When a locator record is added to the end of a locator-set, it is > easy to update mappings. =20 =46rom my understanding, whenever there is a new RLOC, authors suggest = to append it to the list of RLOC and set to 1 the corresponding bit of = the loc-status-bits. That's all. I would fix the text in the following way: When a locator record is added, it is easy to update mappings.=20= We assume new mappings will maintain the same locator ordering=20= as the old mapping but just have new locators appended to the=20 end of the list. So some ITRs can have a new mapping while = other=20 ITRs have only an old mapping that is used until they time out. =20= When an ITR has only an old mapping but detects bits set in the=20= loc-status-bits that correspond to locators beyond the list it = has=20 cached, it simply ignores them. =20 I would drop the last sentence, about lexicographic order, as well. The = above text looks sufficient to me. Luigi On 22, Mar, 2011, at 13:53 , Yakov Rekhter wrote: > Joel, >=20 >> Yakov, >> There is extensive text on the various RLOC maintenance = mechanisms,=20 >> including an entire section on how the ITR cleans up its cache. Are = you=20 >> asking for a pointer to the lisp-map-versioning document? >=20 > The problem raised in the ticket has to do with the following. Quoting > from Section 6.6: >=20 > 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. >=20 > The above covers the case when a new locator record is appended > to the end of the list. The above does *not* cover the case where > (due to the algorithm used for ordering) a new locator record > has to be inserted in the middle of the list. To cover this > new text should be added right after the text I quoted above. >=20 > Yakov. >=20 >>=20 >> Yours, >> Joel >>=20 >> On 3/17/2011 12:14 PM, lisp issue tracker wrote: >>> #66: Strict RLOC ordering causing problems on mapping changes >>>=20 >>>=20 >>> Comment(by yakov@=E2=80=A6): >>>=20 >>> =46rom the response to my comment: >>>=20 >>> Thank you for your contribution to draft-ietf-lisp-06.txt. The = draft >>> authors >>> have reviewed your comments but do not feel that changes to the = documen > t >>> are >>> warranted at this time. We think that the use of version numbers = will >>> help >>> this. Its also important to note that LSBs are a hint and a >>> request/reply >>> exchange will confirm from the R-bits of the locators in the = locator-se > t >>> which >>> are reachable or not. >>>=20 >>> To close the ticket the draft authors should describe how the use = of >>> version number will address the issues raised in the ticket. = Likewise, th > e >>> authors should point to the specific text in the draft that makes = it clea > r >>> that "LSBs are a hint" and thus are are not sufficient to determine >>> locator's reachability - a request/reply exchange will be required. >>>=20 From yakov@juniper.net Tue Mar 22 07:03:54 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4131428C0EC for ; Tue, 22 Mar 2011 07:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.084 X-Spam-Level: X-Spam-Status: No, score=-106.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 UNo7n4TxJKDZ for ; Tue, 22 Mar 2011 07:03:53 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 0ED5928C0D0 for ; Tue, 22 Mar 2011 07:03:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTYisnsZq2bXsnPo2yKspuNI45i0EZIz1@postini.com; Tue, 22 Mar 2011 07:05:26 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Mar 2011 07:02:27 -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 p2ME3cv74130; Tue, 22 Mar 2011 07:03:38 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103221403.p2ME3cv74130@magenta.juniper.net> To: Luigi Iannone In-Reply-To: <5F47C1C6-815F-461A-A4FA-2E8C9F945D2C@net.t-labs.tu-berlin.de> References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> <077.28c2cc9862e26b7fbd5b68671092214a@trac.tools.ietf.org> <4D83A69E.1030303@joelhalpern.com> <201103221253.p2MCruv42309@magenta.juniper.net> <5F47C1C6-815F-461A-A4FA-2E8C9F945D2C@net.t-labs.tu-berlin.de> X-MH-In-Reply-To: Luigi Iannone message dated "Tue, 22 Mar 2011 14:48:13 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <37721.1300802618.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Mar 2011 07:03:38 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, lisp issue tracker Subject: Re: [lisp] #66: Strict RLOC ordering causing problems on mapping changes 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, 22 Mar 2011 14:03:54 -0000 Luigi, > Hi, > = > I think that the misleading sentence is the first one: > = > > When a locator record is added to the end of a locator-set, it is > > easy to update mappings. = > = > = > From my understanding, whenever there is a new RLOC, authors suggest = > to append it to the list of RLOC and set to 1 the corresponding bit = > of the loc-status-bits. That's all. > = > I would fix the text in the following way: > = > When a locator record is added, 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. = > = > I would drop the last sentence, about lexicographic order, as well. The = above > text looks sufficient to me. Please note that in the Map-Reply "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." (from section 6.1.5). Thus the text you proposed above is still insufficient, as it does not cover the case where a new locator need to be inserted in the *middle* of the list. Yakov. > = > Luigi > = > = > On 22, Mar, 2011, at 13:53 , Yakov Rekhter wrote: > = > > Joel, > > = > >> Yakov, > >> There is extensive text on the various RLOC maintenance mechanism= s, = > >> including an entire section on how the ITR cleans up its cache. Are = you = > >> asking for a pointer to the lisp-map-versioning document? > > = > > The problem raised in the ticket has to do with the following. Quoting > > from Section 6.6: > > = > > 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 mappin= g > > 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 i= t > > 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. > > = > > The above covers the case when a new locator record is appended > > to the end of the list. The above does *not* cover the case where > > (due to the algorithm used for ordering) a new locator record > > has to be inserted in the middle of the list. To cover this > > new text should be added right after the text I quoted above. > > = > > Yakov. > > = > >> = > >> Yours, > >> Joel > >> = > >> On 3/17/2011 12:14 PM, lisp issue tracker wrote: > >>> #66: Strict RLOC ordering causing problems on mapping changes > >>> = > >>> = > >>> Comment(by yakov@=E2=80=A6): > >>> = > >>> From the response to my comment: > >>> = > >>> Thank you for your contribution to draft-ietf-lisp-06.txt. The dr= aft > >>> authors > >>> have reviewed your comments but do not feel that changes to the d= ocume n > > t > >>> are > >>> warranted at this time. We think that the use of version numbers = will > >>> help > >>> this. Its also important to note that LSBs are a hint and a > >>> request/reply > >>> exchange will confirm from the R-bits of the locators in the loca= tor-s e > > t > >>> which > >>> are reachable or not. > >>> = > >>> To close the ticket the draft authors should describe how the use o= f > >>> version number will address the issues raised in the ticket. Likewi= se, t h > > e > >>> authors should point to the specific text in the draft that makes i= t cle a > > r > >>> that "LSBs are a hint" and thus are are not sufficient to determine > >>> locator's reachability - a request/reply exchange will be required. > >>> = > = > = From trac+lisp@trac.tools.ietf.org Sat Mar 26 02:03:36 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2EBD3A6900 for ; Sat, 26 Mar 2011 02:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 s+75ciyWGsFJ for ; Sat, 26 Mar 2011 02:03:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C850A3A68FB for ; Sat, 26 Mar 2011 02:03:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q3PQh-00011l-VN; Sat, 26 Mar 2011 02:05: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Sat, 26 Mar 2011 09:05:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/114#comment:3 Message-ID: <065.7967c3d49ae29c3342f20dc2cc27d49d@trac.tools.ietf.org> References: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 114 In-Reply-To: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #114: EID-to-RLOC mapping - transients 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: Sat, 26 Mar 2011 09:03:36 -0000 #114: EID-to-RLOC mapping - transients Comment(by luigi@…): Reply sent by Vince Fuller, * In looking at the recent email exchange with Yakov over item #114, I don't see where this issue applies to draft-ietf-lisp-alt since it doesn't say anything about consistent ETR configuration. The suggested text changes would appear to the definition of "EID-to-RLOC Database" in section 3 of draft-ietf-lisp, that currently reads as follows: * EID-to-RLOC Database: The EID-to-RLOC database is 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. Seems like the simplest fix for this is simply to delete the last part of the last sentence: "so they consistently send Map-Reply messages with the same database mapping contents". Mandating consistent configuration should result in sending consistent EID-to-RLOC mappings in Map-Reply messages. The extra text invites unnecessary (IMHO) discussion of transient cases. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: new Priority: major | Component: alt Severity: - | Keywords: ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From terry.manderson@icann.org Sun Mar 27 05:45:10 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E5E3A67E3 for ; Sun, 27 Mar 2011 05:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 6OEDo2xiVR7G for ; Sun, 27 Mar 2011 05:45:09 -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 17BAA3A67CC for ; Sun, 27 Mar 2011 05:45:09 -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; Sun, 27 Mar 2011 05:46:45 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Sun, 27 Mar 2011 05:46:43 -0700 Thread-Topic: Wednesday session and presentation slides Thread-Index: AcvsfQY+F7eZ9djN0EqDcR4eJxWH/Q== 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] Wednesday session and presentation slides 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, 27 Mar 2011 12:45:10 -0000 Hi Folks, The agenda for Wednesday is posted here: http://tools.ietf.org/wg/lisp/agenda If I have missed something (ie a presentation slot) you have asked for, and I failed to respond please send me an email ASAP. For all presenters please email me your preso (pdf preferred) slides by 3pm Tuesday (Prague time ;) Cheers Terry From yakov@juniper.net Mon Mar 28 10:48:25 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82C53A689E for ; Mon, 28 Mar 2011 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.052 X-Spam-Level: X-Spam-Status: No, score=-106.052 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 J8RBYNErZtPT for ; Mon, 28 Mar 2011 10:48:25 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 454CE3A67D1 for ; Mon, 28 Mar 2011 10:48:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTZDKQgENFaT8mVGdxQQQpXbOu4Vge0/H@postini.com; Mon, 28 Mar 2011 10:50:02 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Mar 2011 10:47:20 -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 p2SHmmv14212; Mon, 28 Mar 2011 10:48:48 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103281748.p2SHmmv14212@magenta.juniper.net> To: lisp issue tracker MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <31201.1301334528.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Mar 2011 10:48:48 -0700 From: Yakov Rekhter Cc: lisp@ietf.org Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 28 Mar 2011 17:48:25 -0000 Hi, > #114: EID-to-RLOC mapping - transients > = > = > Comment(by luigi@=E2=80=A6): > = > Reply sent by Vince Fuller, > = > * In looking at the recent email exchange with Yakov over item #114, I > don't see where this issue applies to draft-ietf-lisp-alt since it does= n't > say anything about consistent ETR configuration. The suggested text > changes would appear to the definition of "EID-to-RLOC Database" in > section 3 of draft-ietf-lisp, that currently reads as follows: > * EID-to-RLOC Database: The EID-to-RLOC database is a global > distributed database that contains all known EID-prefix to RLOC mappin= gs. > Each potential ETR typically contains a small piece of the database: th= e > EID-to-RLOC mappings for the EID prefixes "behind" the router. These m= ap > 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 sit= e. > 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. > = > Seems like the simplest fix for this is simply to delete the last part= of > the last sentence: "so they consistently send Map-Reply messages with t= he > same database mapping contents". Mandating consistent configuration sho= uld > result in sending consistent EID-to-RLOC mappings in Map-Reply messages= . > The extra text invites unnecessary (IMHO) discussion of transient cases= . Deleting the last part of the last sentence is not enough. You also need to point out that the "MUST" applies only to steady state, and also document that during transients Map-Replies may not be consistent. With this in mind please replace the last sentence with the following: In a steady state the EID-prefixes for the site and the locator-set for each EID-prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document. Note that there may be transient conditions when the EID-prefix = for the site and locator-set for each EID-prefix MAY not be the = same on all ETRs. As a result, for the duration of these transient = conditions not all the ETRs would be able to send Map-Reply messages = with the same database mapping contents. Furthermore, if the authors think that sending inconsistent Map-Reply during transients has no negative implications, then add the following at the end of the text I suggested above: This has no negative implications. = And if the authors think that sending inconsistent Map-Reply during transients does have negative implications, then the authors should list them following the text I suggested above. Yakov. From dino@cisco.com Tue Mar 29 04:39:55 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B7A28C158 for ; Tue, 29 Mar 2011 04:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 LLJsqdHeHfsu for ; Tue, 29 Mar 2011 04:39:52 -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 A46F028C156 for ; Tue, 29 Mar 2011 04:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=3485; q=dns/txt; s=iport; t=1301398891; x=1302608491; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=SEzAIAQnEUMVyEdTQ5dehY91NDGQeMp9HHsHvVK7IP4=; b=H+07AIglbmx/DPwCDKVg0WtcmLPzMBtY/D+t0BZb34Koq5hzDnUbhUdl xpav/4WajDK8lKfV+n3BjXUMNo0wKtzSJSjammiK3CMRkuqlOPy04n+Br r+149dqlW5QVMcQOoiyOIuaMKZQ5RDXC78RWahixFvlUd6qOygou7UWpp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAATEkU2rRDoJ/2dsb2JhbAClRXeIeZ9onEyFagSFPIdG X-IronPort-AV: E=Sophos;i="4.63,261,1299456000"; d="scan'208";a="420126230" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2011 11:41:30 +0000 Received: from dhcp-1789.meeting.ietf.org ([10.21.79.31]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2TBfL2i005272; Tue, 29 Mar 2011 11:41:29 GMT Message-Id: <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201103281748.p2SHmmv14212@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, 29 Mar 2011 04:41:20 -0700 References: <201103281748.p2SHmmv14212@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 11:39:56 -0000 > Deleting the last part of the last sentence is not enough. You also > need to point out that the "MUST" applies only to steady state, and > also document that during transients Map-Replies may not be > consistent. > > With this in mind please replace the last sentence with the following: > > In a steady state the EID-prefixes for the site and the locator-set > for each EID-prefix MUST be the same on all ETRs. Procedures to > enforce and/or verify this are outside the scope of this document. We will add this. > Note that there may be transient conditions when the EID-prefix > for the site and locator-set for each EID-prefix MAY not be the > same on all ETRs. We will add this first sentence but change "MAY not" to "may not" since it is not a rule in this specification that the implementation has an option of making the locator-set inconsistent. The locator-set is only inconsistent between the time it takes a network administrator to make it the same. If there is a configuration error and the inconsistent state is for a longer period of time, then the text below will cover that. > As a result, for the duration of these transient > conditions not all the ETRs would be able to send Map-Reply > messages > with the same database mapping contents. We did not include this sentence above, because it is not true. The ETRs can still send Map-Replies with their idea of the locator-set. And an depending where an ITR's Map-Request is sent, will determine which locator-set the ITR caches. If the locators are disconnected from the network, RLOC-probing will tell you this and ITRs will not encapsulate to them. If there is locator-set policy on the map-server, then maybe one locator-set or the other won't be accepted by the map-server. And if proxy-replying is sent in the map-register, then it is the map- server's idea of the locator-set that is sent consistently in all Map- Replies. So we will say there are no negative implications. > Furthermore, if the authors think that sending inconsistent Map-Reply > during transients has no negative implications, then add the > following at > the end of the text I suggested above: > > This has no negative implications. > > And if the authors think that sending inconsistent Map-Reply during > transients does have negative implications, then the authors should > list > them following the text I suggested above. > > Yakov. Here is the new proposed text: EID-to-RLOC Database: The EID-to-RLOC database is 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. In a steady state the EID-prefixes for the site and the locator-set for each EID-prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document. Note that there may be transient conditions when the EID-prefix for the site and locator-set for each EID-prefix may not be the same on all ETRs. This has no negative implications. Thanks, Dino From dino@cisco.com Tue Mar 29 04:56:57 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B53D28C15C for ; Tue, 29 Mar 2011 04:56:57 -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 5I5VSpEc+0b2 for ; Tue, 29 Mar 2011 04:56:57 -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 4E58428C156 for ; Tue, 29 Mar 2011 04:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=385500; q=dns/txt; s=iport; t=1301399914; x=1302609514; h=message-id:from:to:mime-version:subject:date; bh=JFCvz14SJNIKuhHVirpxCoxW03silIU8r0vnXECDwDM=; b=GJSps0oN0u5pBRZL6pI/grmRnfoT0pPpIMnuXtt6+0ohY4qV2uNABhK/ zSxRPyAJupH5Y1V4SMyJ5WFInQ+eWWREUsm6sWTmeusYTNv1YiPMCOqvA ycO55fcvsLSdT3icw0Q+2lHiXXj/ptcKRGrzQ28pNNOlNSaWBJEnK1GDR k=; X-Files: rfcdiff-lisp-10-to-11.html, draft-ietf-lisp-11.txt : 183556, 190994 X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="txt'?html'217?scan'217,208,217";a="420134855" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2011 11:58:34 +0000 Received: from dhcp-1789.meeting.ietf.org ([10.21.79.31]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2TBw8m9030658 for ; Tue, 29 Mar 2011 11:58:32 GMT Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-21-970141354 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 29 Mar 2011 04:58:08 -0700 X-Mailer: Apple Mail (2.936) Subject: [lisp] Minor updates to drat-ietf-lisp-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:56:57 -0000 --Apple-Mail-21-970141354 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit See enclosed. The chairs have requested -11 is to be posted today to leave enough time for working group members to review before we meet tomorrow. We will wait 4 hours giving Yakov a chance to Ack/Nak the changes we made to reflect his comments. B.1. Changes to draft-ietf-lisp-11.txt o Posted April 2011. o Change IANA URL. The URL we had pointed to a general protocol numbers page. o Added the "s" bit to the Map-Request to allow SMR-invoked Map- Requests to be sent to a MN ETR via the map-server. o Generalize text for the defintion of Reencapsuatling tunnels. o Add pargraph suggested by Joel to explain how implementation experimentation will be used to determine the proper cache management techniques. o Add Yakov provided text for the definition of "EID-to-RLOC "Database". o Add reference in Section 8, Deployment Scenarios, to the draft-jakab-lisp-deploy-02.txt draft. o Clarify sentence about no hardware changes needed to support LISP encapsulation. o Add paragraph about what is the procedure when a locator is inserted in the middle of a locator-set. o Add a definition for Locator-Status-Bits so we can emphasize they are used as a hint for router up/down status and not path reachability. o Change "BGP RIB" to "RIB" per Clarence's comment. o Fixed complaints by IDnits. Thanks, Dino --Apple-Mail-21-970141354 Content-Disposition: attachment; filename=rfcdiff-lisp-10-to-11.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-10-to-11.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-10.txt draft-ietf-lisp-11.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: September 5, 30, 2011                                     D. Lewis
                                                           cisco Systems
                                                          March 4, 29, 2011

                 Locator/ID Separation Protocol (LISP)
                           draft-ietf-lisp-10
                           draft-ietf-lisp-11

Abstract

   This draft describes a network-based protocol that enables separation
   of IP addresses into two new numbering spaces: Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  No changes are required to
   either host protocol stacks or to the "core" of the Internet
   infrastructure.  LISP can be incrementally deployed, without a "flag
   day", and offers traffic engineering, multi-homing, and mobility
   benefits even to early adopters, when there are relatively few LISP-
   capable sites.

   Design and development of LISP was largely motivated by the problem
   statement produced by the October, 2006 IAB Routing and Addressing
   Workshop.

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 September 5, 30, 2011.

Copyright Notice

   Copyright (c) 2011 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  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 17
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 22
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 23
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 24
     5.5.  Using Virtualization and Segmentation with LISP  . . . . . 24
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 26
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 28
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 28
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 30 31
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 32
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 36
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 38
       6.1.7.  Map-Notify Message Format  . . . . . . . . . . . . . . 40
       6.1.8.  Encapsulated Control Message Format  . . . . . . . . . 41
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 43
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 45
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48
     6.4.  EID Reachability within a LISP Site  . . . . . . . . . . . 49
     6.5.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 49
     6.6.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 50
       6.6.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 51
       6.6.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 52
       6.6.3.  Database Map Versioning  . . . . . . . . . . . . . . . 53
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 55
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 57
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 58
     8.4.  LISP Functionality with Conventional NATs  . . . . . . . . 58
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 59
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 60
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 60
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 60
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 62
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 62
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 62
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 62
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 64
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 64
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 66
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 67
   13. Network Management Considerations  . . . . . . . . . . . . . . 68
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 69
     14.1. LISP Address Type Codes  . . . . . . . . . . . . . . . . . 69
     14.2. LISP UDP Port Numbers  . . . . . . . . . . . . . . . . . . 69
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 70
     15.2. Informative References . . . . . . . . . . . . . . . . . . 71
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 74
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 75
     B.1.  Changes to draft-ietf-lisp-10.txt draft-ietf-lisp-11.txt  . . . . . . . . . . . . 75
     B.2.  Changes to draft-ietf-lisp-09.txt draft-ietf-lisp-10.txt  . . . . . . . . . . . . 75
     B.3.  Changes to draft-ietf-lisp-08.txt draft-ietf-lisp-09.txt  . . . . . . . . . . . . 75 76
     B.4.  Changes to draft-ietf-lisp-07.txt draft-ietf-lisp-08.txt  . . . . . . . . . . . . 77 76
     B.5.  Changes to draft-ietf-lisp-06.txt draft-ietf-lisp-07.txt  . . . . . . . . . . . . 79 78
     B.6.  Changes to draft-ietf-lisp-05.txt draft-ietf-lisp-06.txt  . . . . . . . . . . . . 80 79
     B.7.  Changes to draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt  . . . . . . . . . . . . 80 81
     B.8.  Changes to draft-ietf-lisp-03.txt draft-ietf-lisp-04.txt  . . . . . . . . . . . . 82 81
     B.9.  Changes to draft-ietf-lisp-02.txt draft-ietf-lisp-03.txt  . . . . . . . . . . . . 83
     B.10. Changes to draft-ietf-lisp-01.txt draft-ietf-lisp-02.txt  . . . . . . . . . . . . 83
     B.11. Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 84
     B.12. Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 83 84
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 85

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

   This document describes the Locator/Identifier Separation Protocol
   (LISP), which provides a set of functions for routers to exchange
   information used to map from non-routeable Endpoint Identifiers
   (EIDs) to routeable Routing Locators (RLOCs).  It also defines a
   mechanism for these LISP routers to encapsulate IP packets addressed
   with EIDs for transmission across an Internet that uses RLOCs for
   routing and forwarding.

   Creation of LISP was initially motivated by discussions during the
   IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
   October, 2006 (see [RFC4984]).  A key conclusion of the workshop was
   that the Internet routing and addressing system was not scaling well
   in the face of the explosive growth of new sites; one reason for this
   poor scaling is the increasing number of multi-homed and other sites
   that cannot be addressed as part of topologically- or provider-based
   aggregated prefixes.  Additional work that more completely described
   the problem statement may be found in [RADIR].

   A basic observation, made many years ago in early networking research
   such as that documented in [CHIAPPA] and [RFC4984], is that using a
   single address field for both identifying a device and for
   determining where it is topologically located in the network requires
   optimization along two conflicting axes: for routing to be efficient,
   the address must be assigned topologically; for collections of
   devices to be easily and effectively managed, without the need for
   renumbering in response to topological change (such as that caused by
   adding or removing attachment points to the network or by mobility
   events), the address must explicitly not be tied to the topology.

   The approach that LISP takes to solving the routing scalability
   problem is to replace IP addresses with two new types of numbers:
   Routing Locators (RLOCs), which are topologically assigned to network
   attachment points (and are therefore amenable to aggregation) and
   used for routing and forwarding of packets through the network; and
   Endpoint Identifiers (EIDs), which are assigned independently from
   the network topology, are used for numbering devices, and are
   aggregated along administrative boundaries.  LISP then defines
   functions for mapping between the two numbering spaces and for
   encapsulating traffic originated by devices using non-routeable EIDs
   for transport across a network infrastructure that routes and
   forwards using RLOCs.  Both RLOCs and EIDs are syntactically-
   identical to IP addresses; it is the semantics of how they are used
   that differs.

   This document describes the protocol that implements these functions.
   The database which stores the mappings between EIDs and RLOCs is
   explicitly a separate "module" to facilitate experimentation with a
   variety of approaches.  One database design that is being developed
   and prototyped as part of the LISP working group work is [ALT].
   Others that have been described but not implemented include [CONS],
   [EMACS], [RPMD], [NERD].  Finally, [LISP-MS], documents a general-
   purpose service interface for accessing a mapping database; this
   interface is intended to make the mapping database modular so that
   different approaches can be tried without the need to modify
   installed xTRs.

3.  Definition of Terms

   Provider Independent (PI) Addresses:   PI addresses are 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:   PA addresses are an a address
      block assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider Classless Inter-Domain Routing (CIDR) [RFC4632] 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):   A RLOC is an IPv4 or IPv6 address of an
      egress tunnel router (ETR).  A RLOC 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):   An EID is 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 Domain Name System (DNS) [RFC1034]
      lookup or Session Invitation Protocol (SIP) [RFC3261] 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:   An EID-prefix is a power-of-two 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:   An 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):   An ITR is 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:   A 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):   An ETR is 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:   A TE-ETR is an ETR that is deployed in a service provider
      network that strips an outer LISP header for Traffic Engineering
      purposes.

   xTR:   A 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:   The EID-to-RLOC cache is 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:   The EID-to-RLOC database is 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,  In a steady
      state the EID-prefixes for the site and the locator-set for each
      EID-prefix MUST be the same on all ETRs so they consistently send Map-Reply
      messages with ETRs.  Procedures to enforce
      and/or verify this are outside the scope of this document.  Note
      that there may be transient conditions when the EID-prefix for the
      site and locator-set for each EID-prefix may not be the same database mapping contents. on
      all ETRs. This has no negative implications.

   Recursive Tunneling:   Recursive tunneling occurs 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:   Reencapsulating tunneling occurs 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 removes a new
      tunnel LISP header, with new RLOC, on then acts as an ITR to the packet. prepend another
      LISP header.  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 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 length of the address is 0 bytes
      following the 16-bit AFI value of 0.

   Negative Mapping Entry:   A 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 data-probe is 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):   A PITR is 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):   A 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.

   Client-side:  a term used in this document to indicate a connection
      initiation attempt by an EID.  The ITR(s) at the LISP site are the
      first to get involved in obtaining database map cache entries by
      sending Map-Request messages.

   Server-side:  a term used in this document to indicate a connection
      initiation attempt is being accepted for a destination EID.  The
      ETR(s) at the destination LISP site are the first to send Map-
      Replies to the source site initiating the connection.  The ETR(s)
      at this destination site can obtain mappings by gleaning
      information from Map-Requests, Data-Probes, or encapsulated
      packets.

   Locator-Status-Bits (LSBs):  Locator status bits are present in the
      LISP header.  They are used by ITRs to inform ETRs about the up/
      down status of all ITRs at the local site.  These bits are used as
      a hint to convey up/down router status and not path reachability
      status.  The LSBs can be verified by use of one of the Locator
      Reachability Algoriths described in Section 6.3.

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.

   Another key LISP concept is the "Tunnel Router".  A tunnel router
   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 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
      independent of 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 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).

   In order to avoid excessive packet overhead as well as possible
   encapsulation loops, this document mandates that a maximum of two
   LISP headers can be prepended to a packet.  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, but the source and destination can be
      located anywhere in LISP site.

   o  Map-Requests can be sent on the underlying routing system topology
      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.  When an alternate mapping system is not in use, the Map-Request
       packet is routed through the underlying routing system.
       Otherwise, 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
       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 stored in the ITR's EID-to-
       RLOC mapping cache.  Note that the map cache is an on-demand
       cache.  An ITR will manage its map cache in such a way that
       optimizes for its resource constraints.

   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.

5.  LISP Encapsulation Details

   Since additional tunnel headers are prepended, the packet becomes
   larger and 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.

   This specification recommends that implementations support for one of
   the proposed fragmentation and reassembly schemes.  These two
   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|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                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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|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   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Tunnel Header Field Descriptions

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

   Outer Header:  The outer header is a new 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:  The UDP header contains a ITR selected source port when
      encapsulating a packet.  See Section 6.5 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:  The UDP checksum 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:  The UDP length field is 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: The N bit 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: The L bit 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: The E bit 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: The V bit is the Map-Version present bit.  When this bit is set to
      1, the N bit MUST be 0.  Refer to Section 6.6.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: The I bit 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:  The flags field is a 3-bit field is reserved for future flag
      use.  It is set to 0 on transmit and ignored on receipt.

   LISP Nonce:  The LISP nonce field 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:  The locator status bits field in the LISP
      header is 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 ITR/PITR 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 ETR/PETR decapsulation:

   o  The inner header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the outer header Time to Live
      field, when the Time to Live field of the outer header is less
      than the Time to Live of the inner header.  Failing to perform
      this check can cause the Time to Live of the inner header to
      increment across encapsulation/decapsulation cycle.  This check is
      also performed when doing initial encapsulation when a packet
      comes to an ITR or PITR destined for a LISP site.

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

   Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate
   after decapsulating, the net effect of this is that the new outer
   header will carry the same Time to Live as the old outer header.

   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.  See
   Section 9.3 for TTL exception handling for traceroute packets.

   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

   This section proposes two mechanisms to deal with packets that exceed
   the path MTU between the ITR and ETR.

   It is left to the implementor to decide if the stateless or stateful
   mechanism should be implemented.  Both or neither can be used since
   it is a local decision in the ITR regarding how to deal with MTU
   issues, and 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:

   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would like to 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.  The size of the encapsulated fragments is then
   (S/2 + H), which is less than the ITR's estimate of the path MTU
   between the ITR and its correspondent ETR.

   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.

   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 IANA Considerations Section 14.1 for details for
   possible 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 decapsulates 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.

   For example, a 802.1Q VLAN tag or VPN identifier could be used as a
   24-bit Instance ID.

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.
   Implementations MUST be prepared to accept packets when either the
   source port or destination UDP port is set to 4342 due to NATs
   changing port number values.

   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] uses 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 Map-Notify:                   4    b'0100'
       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|p| |A|M|P|S|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:

   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.6.2 for details.

   p: This is the PITR bit.  This bit is set to 1 when a PITR sends a
      Map-Request.

   s: This is the SMR-invoked bit.  This bit is set to 1 when an xTR is
      sending a Map-Request in response to a received SMR-based Map-
      Request.

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

   IRC:  This 5-bit field is the ITR-RLOC Count which encodes the
      additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
      present in this message.  At least one (ITR-RLOC-AFI, ITR-RLOC-
      Address) pair must always be encoded.  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, and for a value of 1, there are 2 ITR-RLOC addresses encoded
      and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.

   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.

   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, an AFI value 0 is used and this field is of zero
      length.

   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 of the
      sender of the Map-Request message.

   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 a
      single "Record" 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] 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.
   In all cases, the UDP source port number for the Map-Request message
   is an ITR/PITR selected 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|S|          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.

   S: This is the Security bit.  When set to 1 the field following the
      Mapping Protocol Data field will have the following format.  The
      detailed format of the Authentication Data Content field can be
      found in [LISP-SEC] when AD Type is equal to 1.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    AD Type    |       Authentication Data Content . . .       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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) No-Action:  The map-cache is kept alive and packet
         encapsulation occurs.

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

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

      (3) Drop:  A packet that matches this map-cache entry is dropped.

   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
      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.6.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 relative weight 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.5 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.

   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 relative
      weight of total number of trees built 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, 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: set when the sender of a Map-Reply has a route to the locator in
      the locator data record.  This receiver may find this useful to
      know when determining if the locator is reachable from the
      receiver.  See also Section 6.4 for another way the R-bit may be
      used.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR.  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

   A Map-Reply returns an EID-prefix with a prefix length that is less
   than or equal to the EID being requested.  The EID being requested is
   either from the destination field of an IP header of a Data-Probe or
   the EID record of a Map-Request.  The RLOCs in the Map-Reply are
   globally-routable IP addresses of all ETRs for the LISP site.  Each
   RLOC conveys status reachability but does not convey path
   reachability from a requesters perspective.  Separate testing of path
   reachability is required, See Section 6.3 for details.

   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 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.  A negative Map-
   Reply is a Map-Reply with an empty locator-set.  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 Data-Probe message which is
   invoking the reply.  The source address of the Map-Reply is one of
   the local locator IP 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 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.

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               |M| 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:

   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.

   M: This is the want-map-notify bit, when set to 1 an ETR is
      requesting for a Map-Notify message to be returned in response to
      sending a Map-Register message.  The Map-Notify message sent by a
      Map-Server is used to an acknowledge receipt of a Map-Register
      message.

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

6.1.7.  Map-Notify Message Format

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

   The message is sent inside a UDP packet with a source UDP port equal
   to 4342 and a destination port equal to the source port from the Map-
   Register message this Map-Notify message is responding to.

   The Map-Notify 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=4 |              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:

   Type:   4 (Map-Notify)

   The Map-Notify message has the same contents as a Map-Register
   message.  See Map-Register section for field descriptions.

6.1.8.  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 |S|                  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.

   S:   This is the Security bit.  When set to 1 the field following the
      Reserved field will have the following format.  The detailed
      format of the Authentication Data Content field can be found in
      [LISP-SEC] when AD Type is equal to 1.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    AD Type    |       Authentication Data Content . . .       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 ITR/PITR selected
      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 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
      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 provides reachability information for RLOCs.
   Note that reachability is not part of the mapping system and is
   determined 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 data flows bidirectionally between locators from different
   sites, a data-plane 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.

   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 may include a mapping data record
   for its own database mapping information which contains the local
   EID-prefixes and RLOCs for its site.

   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
   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.  EID Reachability within a LISP Site

   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 is for an ETR to lose
   reachability to one or more of the EID prefixes within its own site.
   When this occurs when the ETR sends Map-Replies, it can clear the
   R-bit associated with its own locator.  And when the ETR is also an
   ITR, it can clear its locator-status-bit in the encapsulation data
   header.

6.5.  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 hashed 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.6.  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 which
   ITRs 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 inserted in the middle of a locator-set, to
   maintain lexiographic order, the SMR procedure in Section 6.6.2 is
   used to inform ITRs and PTRs of the new locator-status-bit mappings.

   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.6.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.  The new mappings
       are cached with a time to live equal to the TTL in the Map-Reply.

6.6.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for ETRs, 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 ETRs don't keep track of remote ITRs that have cached their
   mappings, they do not know which ITRs need to have their mappings
   updated.  As a result, an ETR will solicit Map-Requests (called an
   SMR message) from those sites to which it has been sending
   encapsulated data to for the last minute.  In particular, an ETR will
   send an SMR an ITR to which it has recently sent encapsulated data.

   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.  Rate-limiting can be implemented as a global rate-
   limiter or one rate-limiter per SMR destination.

   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 ITR which receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message or to the mapping database system.  A newly allocated
       random nonce is selected and the EID-prefix used is the one
       copied from the SMR message.  If the source locator is the only
       locator in the cached locator-set, the remote ITR SHOULD send a
       Map-Request to the database mapping system just in case the
       single locator has changed and may no longer be reachable to
       accept the Map-Request.

   3.  The remote ITR MUST rate-limit the Map-Request until it gets a
       Map-Reply while continuing to use the cached mapping.  When Map
       Versioning is used, described in Section 6.6.3, an SMR sender can
       detect if an ITR is using the most up to date database mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message that has a nonce from the
       SMR-invoked Map-Request.  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.
   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.

   When an ITR receives an SMR-based Map-Request for which it does not
   have a cached mapping for the EID in the SMR message, it MAY not send
   a SMR-invoked Map-Request.  This scenario can occur when an ETR sends
   SMR messages to all locators in the locator-set it has stored in its
   map-cache but the remote ITRs that receive the SMR may not be sending
   packets to the site.  There is no point in updating the ITRs until
   they need to send, in which case, they will send Map-Requests to
   obtain a map-cache entry.

6.6.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.6.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 ITR 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.  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  There are a few proven
      cases where no changes to existing, existing deployed hardware should be were needed
      to support this. the LISP data-plane.

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

   o  A packet's source address or interface the packet was received on
      can be used to select a VRF (Virtual Routing/Forwarding).  The
      VRF's routing table 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.  For
   a more detailed deployment recommendation, refer to [LISP-DEPLOY].

   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 survey 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 is the default
   behavior envisioned in the rest of this specification.

   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.  Another
   disadvantage of using anycast locators is the limited advertisement
   scope of /32 (or /128 for IPv6) routes.

8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers is not the typical
   deployment scenario envisioned in the specification.  This section
   attempts to capture some of reasoning behind this preference of
   implementing LISP on CE routers.

   Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather
   than a site, 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 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.  Other disadvantages
   include the difficulty in synchronizing path liveness updates between
   CE and PE routers.

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

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

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.

   Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings,
   cache sizing and maintenance is an issue to be kept in mind during
   implementation.  It is a good idea to have instrumentation in place
   to detect thrashing of the cache.  Implementation experimentation
   will be used to determine which cache management strategies work
   best.

13.  Network Management Considerations

   Considerations for Network Management tools exist so the LISP
   protocol suite can be operationally managed.  The mechanisms can be
   found in [LISP-MIB] and [LISP-LIG].

14.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the LISP
   specification, in accordance with BCP 26 and RFC 5226 [RFC5226].

   There are two name spaces in LISP that require registration:

   o  LISP IANA registry allocations should not be made for purposes
      unrelated to LISP routing or transport protocols.

   o  The following policies are used here with the meanings defined in
      BCP 26: "Specification Required", "IETF Consensus", "Experimental
      Use", "First Come First Served".

14.1.  LISP Address Type Codes

   Instance ID type codes have a range from 0 to 15, of which 0 and 1
   have been allocated [LCAF].  New Type Codes MUST be allocated
   starting at 2.  Type Codes 2 - 10 are to be assigned by IETF Review.
   Type Codes 11 - 15 are available on a First Come First Served policy.

   The following codes have been allocated:

   Type 0:  Null Body Type

   Type 1:  AFI List Type

   See [LCAF] for details for other possible unapproved address
   encodings.  The unapproved LCAF encodings are an area for further
   study and experimentation.

14.2.  LISP UDP Port Numbers

   The IANA registry has allocated UDP port numbers 4341 and 4342 for
   LISP data-plane and control-plane operation, respectively.

15.  References

15.1.  Normative References

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

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

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

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

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

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

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 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.

   [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, http://www.iana.org/.../address-family-numbers,
              Febuary 2007.

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

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

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

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

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

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

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

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

   [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-MIB]
              Schudel, G., Jain, A., and V. Moreno, "LISP MIB",
              draft-ietf-lisp-mib-01.txt (work in progress), March 2011.

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

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

   [LISP-SEC]
              Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O.
              Bonaventure, "LISP-Security (LISP-SEC)",
              draft-maino-lisp-sec-00.txt (work in progress),
              February 2011.

   [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-04.txt (work in progress),
              October 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.

   [VERSIONING]
              Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
              Versioning", draft-ietf-lisp-map-versioning-01.txt (work
              in progress), March 2011.

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, Terry
   Manderson, 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, Dimitri
   Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina
   Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, and Chris
   White. White,
   and Clarence Filsfils.

   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-11.txt

   o  Posted April 2011.

   o  Change IANA URL.  The URL we had pointed to a general protocol
      numbers page.

   o  Added the "s" bit to the Map-Request to allow SMR-invoked Map-
      Requests to be sent to a MN ETR via the map-server.

   o  Generalize text for the defintion of Reencapsuatling tunnels.

   o  Add pargraph suggested by Joel to explain how implementation
      experimentation will be used to determine the proper cache
      management techniques.

   o  Add Yakov provided text for the definition of "EID-to-RLOC
      "Database".

   o  Add reference in Section 8, Deployment Scenarios, to the
      draft-jakab-lisp-deploy-02.txt draft.

   o  Clarify sentence about no hardware changes needed to support LISP
      encapsulation.

   o  Add paragraph about what is the procedure when a locator is
      inserted in the middle of a locator-set.

   o  Add a definition for Locator-Status-Bits so we can emphasize they
      are used as a hint for router up/down status and not path
      reachability.

   o  Change "BGP RIB" to "RIB" per Clarence's comment.

   o  Fixed complaints by IDnits.

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

   o  Posted March 2011.

   o  Add p-bit to Map-Request so there is documentary reasons to know
      when a PITR has sent a Map-Request to an ETR.

   o  Add Map-Notify message which is used to acknowledge a Map-Register
      message sent to a Map-Server.

   o  Add M-bit to the Map-Register message so an ETR that wants an
      acknowledgment for the Map-Register can request one.

   o  Add S-bit to the ECM and Map-Reply messages to describe security
      data that can be present in each message.  Then refer to
      [LISP-SEC] for expansive details.

   o  Add Network Management Considerations section and point to the MIB
      and LIG drafts.

   o  Remove the word "simple" per Yakov's comments.

B.2.

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

   o  Posted October 2010.

   o  Add to IANA Consideration section about the use of LCAF Type
      values that accepted and maintained by the IANA registry and not
      the LCAF specification.

   o  Indicate that implementations should be able to receive LISP
      control messages when either UDP port is 4342, so they can be
      robust in the face of intervening NAT boxes.

   o  Add paragraph to SMR section to indicate that an ITR does not need
      to respond to an SMR-based Map-Request when it has no map-cache
      entry for the SMR source's EID-prefix.

B.3.

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

   o  Posted August 2010.

   o  In section 6.1.6, remove statement about setting TTL to 0 in Map-
      Register messages.

   o  Clarify language in section 6.1.5 about Map-Replying to Data-
      Probes or Map-Requests.

   o  Indicate that outer TTL should only be copied to inner TTL when it
      is less than inner TTL.

   o  Indicate a source-EID for RLOC-probes are encoded with an AFI
      value of 0.

   o  Indicate that SMRs can have a global or per SMR destination rate-
      limiter.

   o  Add clarifications to the SMR procedures.

   o  Add definitions for "client-side" and 'server-side" terms used in
      this specification.

   o  Clear up language in section 6.4, last paragraph.

   o  Change ACT of value 0 to "no-action".  This is so we can RLOC-
      probe a PETR and have it return a Map-Reply with a locator-set of
      size 0.  The way it is spec'ed the map-cache entry has action
      "dropped".  Drop-action is set to 3.

   o  Add statement about normalizing locator weights.

   o  Clarify R-bit definition in the Map-Reply locator record.

   o  Add section on EID Reachability within a LISP site.

   o  Clarify another disadvantage of using anycast locators.

   o  Reworded Abstract.

   o  Change section 2.0 Introduction to remove obsolete information
      such as the LISP variant definitions.

   o  Change section 5 title from "Tunneling Details" to "LISP
      Encapsulation Details".

   o  Changes to section 5 to include results of network deployment
      experience with MTU.  Recommend that implementations use either
      the stateful or stateless handling.

   o  Make clarification wordsmithing to Section 7 and 8.

   o  Identify that if there is one locator in the locator-set of a map-
      cache entry, that an SMR from that locator should be responded to
      by sending the the SMR-invoked Map-Request to the database mapping
      system rather than to the RLOC itself (which may be unreachable).

   o  When describing Unicast and Multicast Weights indicate the the
      values are relative weights rather than percentages.  So it
      doesn't imply the sum of all locator weights in the locator-set
      need to be 100.

   o  Do some wordsmithing on copying TTL and TOS fields.

   o  Numerous wordsmithing changes from Dave Meyer.  He fine toothed
      combed the spec.

   o  Removed Section 14 "Prototype Plans and Status".  We felt this
      type of section is no longer appropriate for a protocol
      specification.

   o  Add clarification text for the IRC description per Damien's
      commentary.

   o  Remove text on copying nonce from SMR to SMR-invoked Map- Request
      per Vina's comment about a possible DoS vector.

   o  Clarify (S/2 + H) in the stateless MTU section.

   o  Add text to reflect Damien's comment about the description of the
      "ITR-RLOC Address" field in the Map-Request. that the list of RLOC
      addresses are local addresses of the Map-Requester.

B.4.

B.5.  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.

B.5.

B.6.  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=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.6.

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

B.8.  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 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.8.

B.9.  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.9.

B.10.  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 [LISP-MN].

B.10.

B.11.  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.11.

B.12.  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-21-970141354 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-21-970141354 Content-Disposition: attachment; filename=draft-ietf-lisp-11.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-11.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: September 30, 2011 D. Lewis cisco Systems March 29, 2011 Locator/ID Separation Protocol (LISP) draft-ietf-lisp-11 Abstract This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. 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 September 30, 2011. Farinacci, et al. Expires September 30, 2011 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Copyright Notice Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 31 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 36 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38 6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40 6.1.8. Encapsulated Control Message Format . . . . . . . . . 41 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49 6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 49 6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 50 Farinacci, et al. Expires September 30, 2011 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 51 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52 6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 53 7. Router Performance Considerations . . . . . . . . . . . . . . 55 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 57 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 58 8.4. LISP Functionality with Conventional NATs . . . . . . . . 58 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 59 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 60 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 60 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 60 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 62 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 62 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 62 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 62 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 64 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 64 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 66 12. Security Considerations . . . . . . . . . . . . . . . . . . . 67 13. Network Management Considerations . . . . . . . . . . . . . . 68 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 69 14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 69 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 15.1. Normative References . . . . . . . . . . . . . . . . . . . 70 15.2. Informative References . . . . . . . . . . . . . . . . . . 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 74 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 75 B.1. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 75 B.2. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 75 B.3. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 76 B.4. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 76 B.5. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 78 B.6. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 79 B.7. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 81 B.8. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 81 B.9. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 83 B.10. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 83 B.11. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 84 B.12. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85 Farinacci, et al. Expires September 30, 2011 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 30, 2011 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 2. Introduction This document describes the Locator/Identifier Separation Protocol (LISP), which provides a set of functions for routers to exchange information used to map from non-routeable Endpoint Identifiers (EIDs) to routeable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across an Internet that uses RLOCs for routing and forwarding. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October, 2006 (see [RFC4984]). A key conclusion of the workshop was that the Internet routing and addressing system was not scaling well in the face of the explosive growth of new sites; one reason for this poor scaling is the increasing number of multi-homed and other sites that cannot be addressed as part of topologically- or provider-based aggregated prefixes. Additional work that more completely described the problem statement may be found in [RADIR]. A basic observation, made many years ago in early networking research such as that documented in [CHIAPPA] and [RFC4984], is that using a single address field for both identifying a device and for determining where it is topologically located in the network requires optimization along two conflicting axes: for routing to be efficient, the address must be assigned topologically; for collections of devices to be easily and effectively managed, without the need for renumbering in response to topological change (such as that caused by adding or removing attachment points to the network or by mobility events), the address must explicitly not be tied to the topology. The approach that LISP takes to solving the routing scalability problem is to replace IP addresses with two new types of numbers: Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation) and used for routing and forwarding of packets through the network; and Endpoint Identifiers (EIDs), which are assigned independently from the network topology, are used for numbering devices, and are aggregated along administrative boundaries. LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routeable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. Both RLOCs and EIDs are syntactically- identical to IP addresses; it is the semantics of how they are used that differs. This document describes the protocol that implements these functions. The database which stores the mappings between EIDs and RLOCs is Farinacci, et al. Expires September 30, 2011 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 explicitly a separate "module" to facilitate experimentation with a variety of approaches. One database design that is being developed and prototyped as part of the LISP working group work is [ALT]. Others that have been described but not implemented include [CONS], [EMACS], [RPMD], [NERD]. Finally, [LISP-MS], documents a general- purpose service interface for accessing a mapping database; this interface is intended to make the mapping database modular so that different approaches can be tried without the need to modify installed xTRs. Farinacci, et al. Expires September 30, 2011 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 3. Definition of Terms Provider Independent (PI) Addresses: PI addresses are 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: PA addresses are an a address block assigned to a site by each service provider to which a site connects. Typically, each block is sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] 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): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC 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): An EID is 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 Domain Name System (DNS) [RFC1034] lookup or Session Invitation Protocol (SIP) [RFC3261] 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 September 30, 2011 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 EID-prefix: An EID-prefix is a power-of-two 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: An 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): An ITR is 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: A 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): An ETR is 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 Farinacci, et al. Expires September 30, 2011 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. xTR: A 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: The EID-to-RLOC cache is 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: The EID-to-RLOC database is 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. In a steady state the EID-prefixes for the site and the locator-set for each EID-prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document. Note that there may be transient conditions when the EID-prefix for the site and locator-set for each EID-prefix may not be the same on all ETRs. This has no negative implications. Recursive Tunneling: Recursive tunneling occurs 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. Farinacci, et al. Expires September 30, 2011 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Reencapsulating Tunnels: Reencapsulating tunneling occurs when an ETR removes a LISP header, then acts as an ITR to prepend another LISP header. 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 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 length of the address is 0 bytes following the 16-bit AFI value of 0. Negative Mapping Entry: A 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 data-probe is 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): A PITR is 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): A 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 September 30, 2011 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. Client-side: a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in obtaining database map cache entries by sending Map-Request messages. Server-side: a term used in this document to indicate a connection initiation attempt is being accepted for a destination EID. The ETR(s) at the destination LISP site are the first to send Map- Replies to the source site initiating the connection. The ETR(s) at this destination site can obtain mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets. Locator-Status-Bits (LSBs): Locator status bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ITRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator Reachability Algoriths described in Section 6.3. Farinacci, et al. Expires September 30, 2011 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. Another key LISP concept is the "Tunnel Router". A tunnel router 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 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 September 30, 2011 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 independent of 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 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). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document mandates that a maximum of two LISP headers can be prepended to a packet. 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 September 30, 2011 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. When an alternate mapping system is not in use, the Map-Request packet is routed through the underlying routing system. Otherwise, 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- Farinacci, et al. Expires September 30, 2011 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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 stored in the ITR's EID-to- RLOC mapping cache. Note that the map cache is an on-demand cache. An ITR will manage its map cache in such a way that optimizes for its resource constraints. 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 September 30, 2011 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and 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. This specification recommends that implementations support for one of the proposed fragmentation and reassembly schemes. These two existing schemes are detailed in Section 5.4. Farinacci, et al. Expires September 30, 2011 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires September 30, 2011 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 | | 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 | | r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires September 30, 2011 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 5.3. Tunnel Header Field Descriptions Inner Header: The inner header is the header on the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer Header: The outer header is a new 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: The UDP header contains a ITR selected source port when encapsulating a packet. See Section 6.5 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: The UDP checksum 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: The UDP length field is 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: The N bit 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 Farinacci, et al. Expires September 30, 2011 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 having a Nonce value present. L: The L bit 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: The E bit 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: The V bit is the Map-Version present bit. When this bit is set to 1, the N bit MUST be 0. Refer to Section 6.6.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: The I bit 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 September 30, 2011 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags: The flags field is a 3-bit field is reserved for future flag use. It is set to 0 on transmit and ignored on receipt. LISP Nonce: The LISP nonce field 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: The locator status bits field in the LISP header is 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 ITR/PITR 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 ETR/PETR decapsulation: Farinacci, et al. Expires September 30, 2011 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 o The inner header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the outer header Time to Live field, when the Time to Live field of the outer header is less than the Time to Live of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycle. This check is also performed when doing initial encapsulation when a packet comes to an ITR or PITR destined for a LISP site. o The inner header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the outer header Type of Service field (with one caveat, see below). Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header. 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. See Section 9.3 for TTL exception handling for traceroute packets. 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 This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism should be implemented. Both or neither can be used since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Farinacci, et al. Expires September 30, 2011 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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: 1. Define an architectural constant S for the maximum size of a packet, in bytes, an ITR would like to 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. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. 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. Farinacci, et al. Expires September 30, 2011 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 IANA Considerations Section 14.1 for details for possible 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 decapsulates 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. Farinacci, et al. Expires September 30, 2011 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 For example, a 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. Farinacci, et al. Expires September 30, 2011 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 30, 2011 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 | | + 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. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values. 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] uses 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 September 30, 2011 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 Map-Notify: 4 b'0100' 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|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 September 30, 2011 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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.6.2 for details. p: This is the PITR bit. This bit is set to 1 when a PITR sends a Map-Request. s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map- Request. Reserved: Set to 0 on transmission and ignored on receipt. IRC: This 5-bit field is the ITR-RLOC Count which encodes the additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- Address) pair must always be encoded. 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, and for a value of 1, there are 2 ITR-RLOC addresses encoded and so on up to 31 which encodes a total of 32 ITR-RLOC addresses. 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 Farinacci, et al. Expires September 30, 2011 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 random) source. See [RFC4086] for advice on generating security- sensitive random data. Source-EID-AFI: Address family of the "Source EID 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, an AFI value 0 is used and this field is of zero length. 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 of the sender of the Map-Request message. 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 a single "Record" 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] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. Farinacci, et al. Expires September 30, 2011 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. In all cases, the UDP source port number for the Map-Request message is an ITR/PITR selected 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 Farinacci, et al. Expires September 30, 2011 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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=3D2 |P|E|S| 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. Farinacci, et al. Expires September 30, 2011 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 S: This is the Security bit. When set to 1 the field following the Mapping Protocol Data field will have the following format. The detailed format of the Authentication Data Content field can be found in [LISP-SEC] when AD Type is equal to 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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) No-Action: The map-cache is kept alive and packet encapsulation occurs. Farinacci, et al. Expires September 30, 2011 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. (3) Drop: A packet that matches this map-cache entry is dropped. 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 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.6.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 relative weight 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.5 for a suggested hash algorithm to distribute load across locators with same priority and equal weight values. 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 Farinacci, et al. Expires September 30, 2011 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 relative weight of total number of trees built 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, 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: set when the sender of a Map-Reply has a route to the locator in the locator data record. This receiver may find this useful to know when determining if the locator is reachable from the receiver. See also Section 6.4 for another way the R-bit may be used. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR. 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. Farinacci, et al. Expires September 30, 2011 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 A Map-Reply returns an EID-prefix with a prefix length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are globally-routable IP addresses of all ETRs for the LISP site. Each RLOC conveys status reachability but does not convey path reachability from a requesters perspective. Separate testing of path reachability is required, See Section 6.3 for details. 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 Farinacci, et al. Expires September 30, 2011 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. A negative Map- Reply is a Map-Reply with an empty locator-set. 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 Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local IP addresses 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 Farinacci, et al. Expires September 30, 2011 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. 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: Farinacci, et al. Expires September 30, 2011 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 |M| 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: 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. M: This is the want-map-notify bit, when set to 1 an ETR is requesting for a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to an acknowledge receipt of a Map-Register message. Farinacci, et al. Expires September 30, 2011 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. 6.1.7. Map-Notify Message Format The usage details of the Map-Notify message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent inside a UDP packet with a source UDP port equal to 4342 and a destination port equal to the source port from the Map- Register message this Map-Notify message is responding to. The Map-Notify message format is: Farinacci, et al. Expires September 30, 2011 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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=3D4 | 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: Type: 4 (Map-Notify) The Map-Notify message has the same contents as a Map-Register message. See Map-Register section for field descriptions. 6.1.8. 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 September 30, 2011 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 |S| 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. S: This is the Security bit. When set to 1 the field following the Reserved field will have the following format. The detailed format of the Authentication Data Content field can be found in [LISP-SEC] when AD Type is equal to 1. Farinacci, et al. Expires September 30, 2011 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 ITR/PITR selected 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 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 Farinacci, et al. Expires September 30, 2011 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator Reachability Algorithms described in the next section. Farinacci, et al. Expires September 30, 2011 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. Farinacci, et al. Expires September 30, 2011 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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 Farinacci, et al. Expires September 30, 2011 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 data flows bidirectionally between locators from different sites, a data-plane 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. Farinacci, et al. Expires September 30, 2011 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. 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 may include a mapping data record for its own database mapping information which contains the local EID-prefixes and RLOCs for its site. 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 Farinacci, et al. Expires September 30, 2011 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. EID Reachability within a LISP Site 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 is for an ETR to lose reachability to one or more of the EID prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own locator. And when the ETR is also an ITR, it can clear its locator-status-bit in the encapsulation data header. 6.5. 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: Farinacci, et al. Expires September 30, 2011 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 hashed 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.6. 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 which ITRs 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 Farinacci, et al. Expires September 30, 2011 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 inserted in the middle of a locator-set, to maintain lexiographic order, the SMR procedure in Section 6.6.2 is used to inform ITRs and PTRs of the new locator-status-bit mappings. 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.6.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 Farinacci, et al. Expires September 30, 2011 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. The new mappings are cached with a time to live equal to the TTL in the Map-Reply. 6.6.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for ETRs, 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 ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data to for the last minute. In particular, an ETR will send an SMR an ITR to which it has recently sent encapsulated data. 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. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. 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 ITR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected and the EID-prefix used is the one copied from the SMR message. If the source locator is the only locator in the cached locator-set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single locator has changed and may no longer be reachable to accept the Map-Request. Farinacci, et al. Expires September 30, 2011 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map Versioning is used, described in Section 6.6.3, an SMR sender can detect if an ITR is using the most up to date database mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. 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. 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. When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it MAY not send a SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all locators in the locator-set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case, they will send Map-Requests to obtain a map-cache entry. 6.6.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 Farinacci, et al. Expires September 30, 2011 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 version for its mapping, the SMR procedure described in Section 6.6.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 ITR 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 September 30, 2011 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 7. Router Performance Considerations LISP is designed to be very hardware-based forwarding friendly. 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. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data-plane. o On an ITR, prepending a new IP header consists of adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. o A packet's source address or interface the packet was received on can be used to select a VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. Farinacci, et al. Expires September 30, 2011 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. For a more detailed deployment recommendation, refer to [LISP-DEPLOY]. 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 survey where tunnel routers can reside in the network. Farinacci, et al. Expires September 30, 2011 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 is the default behavior envisioned in the rest of this specification. 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. Another disadvantage of using anycast locators is the limited advertisement Farinacci, et al. Expires September 30, 2011 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 scope of /32 (or /128 for IPv6) routes. 8.3. ISP Provider-Edge (PE) Tunnel Routers Use of ISP PE routers as tunnel endpoint routers is not the typical deployment scenario envisioned in the specification. This section attempts to capture some of reasoning behind this preference of implementing LISP on CE routers. Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather than a site, 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 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. Other disadvantages include the difficulty in synchronizing path liveness updates between CE and PE routers. 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 September 30, 2011 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 30, 2011 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 30, 2011 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 30, 2011 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 30, 2011 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 30, 2011 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 30, 2011 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Refer to the LISP Mobility Architecture specification [LISP-MN] for more details. Farinacci, et al. Expires September 30, 2011 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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 September 30, 2011 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. Farinacci, et al. Expires September 30, 2011 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 13. Network Management Considerations Considerations for Network Management tools exist so the LISP protocol suite can be operationally managed. The mechanisms can be found in [LISP-MIB] and [LISP-LIG]. Farinacci, et al. Expires September 30, 2011 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 14. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the LISP specification, in accordance with BCP 26 and RFC 5226 [RFC5226]. There are two name spaces in LISP that require registration: o LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols. o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Consensus", "Experimental Use", "First Come First Served". 14.1. LISP Address Type Codes Instance ID type codes have a range from 0 to 15, of which 0 and 1 have been allocated [LCAF]. New Type Codes MUST be allocated starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. Type Codes 11 - 15 are available on a First Come First Served policy. The following codes have been allocated: Type 0: Null Body Type Type 1: AFI List Type See [LCAF] for details for other possible unapproved address encodings. The unapproved LCAF encodings are an area for further study and experimentation. 14.2. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for LISP data-plane and control-plane operation, respectively. Farinacci, et al. Expires September 30, 2011 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 15. References 15.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [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. [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. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [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. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. Farinacci, et al. Expires September 30, 2011 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 [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. [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/.../address-family-numbers, Febuary 2007. [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in progress), March 2011. [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. [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. [INTERWORK] Farinacci, et al. Expires September 30, 2011 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt (work in progress), March 2011. [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-farinacci-lisp-lcaf-04.txt (work in progress), October 2010. [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, "Renumbering: Threat or Menace?", Usenix , September 1996. [LISP-DEPLOY] Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis, "LISP Network Element Deployment Considerations", draft-jakab-lisp-deployment-02.txt (work in progress), February 2011. [LISP-LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-ietf-lisp-lig-01.txt (work in progress), October 2010. [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-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", draft-ietf-lisp-mib-01.txt (work in progress), March 2011. [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP Mobility Architecture", draft-meyer-lisp-mn-04.txt (work in progress), October 2010. [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-07.txt (work in progress), March 2011. [LISP-SEC] Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-maino-lisp-sec-00.txt (work in progress), February 2011. [LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Farinacci, et al. Expires September 30, 2011 [Page 72] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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-04.txt (work in progress), October 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. [VERSIONING] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Versioning", draft-ietf-lisp-map-versioning-01.txt (work in progress), March 2011. Farinacci, et al. Expires September 30, 2011 [Page 73] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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, Terry Manderson, 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, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, and Clarence Filsfils. 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 September 30, 2011 [Page 74] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-11.txt o Posted April 2011. o Change IANA URL. The URL we had pointed to a general protocol numbers page. o Added the "s" bit to the Map-Request to allow SMR-invoked Map- Requests to be sent to a MN ETR via the map-server. o Generalize text for the defintion of Reencapsuatling tunnels. o Add pargraph suggested by Joel to explain how implementation experimentation will be used to determine the proper cache management techniques. o Add Yakov provided text for the definition of "EID-to-RLOC "Database". o Add reference in Section 8, Deployment Scenarios, to the draft-jakab-lisp-deploy-02.txt draft. o Clarify sentence about no hardware changes needed to support LISP encapsulation. o Add paragraph about what is the procedure when a locator is inserted in the middle of a locator-set. o Add a definition for Locator-Status-Bits so we can emphasize they are used as a hint for router up/down status and not path reachability. o Change "BGP RIB" to "RIB" per Clarence's comment. o Fixed complaints by IDnits. B.2. Changes to draft-ietf-lisp-10.txt o Posted March 2011. o Add p-bit to Map-Request so there is documentary reasons to know when a PITR has sent a Map-Request to an ETR. o Add Map-Notify message which is used to acknowledge a Map-Register message sent to a Map-Server. Farinacci, et al. Expires September 30, 2011 [Page 75] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 o Add M-bit to the Map-Register message so an ETR that wants an acknowledgment for the Map-Register can request one. o Add S-bit to the ECM and Map-Reply messages to describe security data that can be present in each message. Then refer to [LISP-SEC] for expansive details. o Add Network Management Considerations section and point to the MIB and LIG drafts. o Remove the word "simple" per Yakov's comments. B.3. Changes to draft-ietf-lisp-09.txt o Posted October 2010. o Add to IANA Consideration section about the use of LCAF Type values that accepted and maintained by the IANA registry and not the LCAF specification. o Indicate that implementations should be able to receive LISP control messages when either UDP port is 4342, so they can be robust in the face of intervening NAT boxes. o Add paragraph to SMR section to indicate that an ITR does not need to respond to an SMR-based Map-Request when it has no map-cache entry for the SMR source's EID-prefix. B.4. Changes to draft-ietf-lisp-08.txt o Posted August 2010. o In section 6.1.6, remove statement about setting TTL to 0 in Map- Register messages. o Clarify language in section 6.1.5 about Map-Replying to Data- Probes or Map-Requests. o Indicate that outer TTL should only be copied to inner TTL when it is less than inner TTL. o Indicate a source-EID for RLOC-probes are encoded with an AFI value of 0. o Indicate that SMRs can have a global or per SMR destination rate- limiter. Farinacci, et al. Expires September 30, 2011 [Page 76] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 o Add clarifications to the SMR procedures. o Add definitions for "client-side" and 'server-side" terms used in this specification. o Clear up language in section 6.4, last paragraph. o Change ACT of value 0 to "no-action". This is so we can RLOC- probe a PETR and have it return a Map-Reply with a locator-set of size 0. The way it is spec'ed the map-cache entry has action "dropped". Drop-action is set to 3. o Add statement about normalizing locator weights. o Clarify R-bit definition in the Map-Reply locator record. o Add section on EID Reachability within a LISP site. o Clarify another disadvantage of using anycast locators. o Reworded Abstract. o Change section 2.0 Introduction to remove obsolete information such as the LISP variant definitions. o Change section 5 title from "Tunneling Details" to "LISP Encapsulation Details". o Changes to section 5 to include results of network deployment experience with MTU. Recommend that implementations use either the stateful or stateless handling. o Make clarification wordsmithing to Section 7 and 8. o Identify that if there is one locator in the locator-set of a map- cache entry, that an SMR from that locator should be responded to by sending the the SMR-invoked Map-Request to the database mapping system rather than to the RLOC itself (which may be unreachable). o When describing Unicast and Multicast Weights indicate the the values are relative weights rather than percentages. So it doesn't imply the sum of all locator weights in the locator-set need to be 100. o Do some wordsmithing on copying TTL and TOS fields. o Numerous wordsmithing changes from Dave Meyer. He fine toothed combed the spec. Farinacci, et al. Expires September 30, 2011 [Page 77] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 o Removed Section 14 "Prototype Plans and Status". We felt this type of section is no longer appropriate for a protocol specification. o Add clarification text for the IRC description per Damien's commentary. o Remove text on copying nonce from SMR to SMR-invoked Map- Request per Vina's comment about a possible DoS vector. o Clarify (S/2 + H) in the stateless MTU section. o Add text to reflect Damien's comment about the description of the "ITR-RLOC Address" field in the Map-Request. that the list of RLOC addresses are local addresses of the Map-Requester. B.5. 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. Farinacci, et al. Expires September 30, 2011 [Page 78] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. B.6. 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". Farinacci, et al. Expires September 30, 2011 [Page 79] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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. Farinacci, et al. Expires September 30, 2011 [Page 80] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 B.7. 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.8. 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. Farinacci, et al. Expires September 30, 2011 [Page 81] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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. 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. Farinacci, et al. Expires September 30, 2011 [Page 82] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 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.9. 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.10. 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. Farinacci, et al. Expires September 30, 2011 [Page 83] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference [LISP-MN]. B.11. 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.12. 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 September 30, 2011 [Page 84] =0C Internet-Draft Locator/ID Separation Protocol (LISP) March 2011 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 September 30, 2011 [Page 85] =0C --Apple-Mail-21-970141354 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-21-970141354-- From yakov@juniper.net Tue Mar 29 06:21:23 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EE73A6824 for ; Tue, 29 Mar 2011 06:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.343 X-Spam-Level: X-Spam-Status: No, score=-106.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 wt9mJKubPTBs for ; Tue, 29 Mar 2011 06:21:21 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 67C943A68D0 for ; Tue, 29 Mar 2011 06:21:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTZHdLnxcb/PTeU+l8YQLZry5N2/99p9g@postini.com; Tue, 29 Mar 2011 06:22:59 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 06:19:11 -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 p2TDKev34441; Tue, 29 Mar 2011 06:20:40 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103291320.p2TDKev34441@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> References: <201103281748.p2SHmmv14212@magenta.juniper.net> <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Tue, 29 Mar 2011 04:41:20 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82546.1301404840.1@juniper.net> Date: Tue, 29 Mar 2011 06:20:40 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, lisp issue tracker Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 13:21:24 -0000 Dino, > > Deleting the last part of the last sentence is not enough. You also > > need to point out that the "MUST" applies only to steady state, and > > also document that during transients Map-Replies may not be > > consistent. > > > > With this in mind please replace the last sentence with the following: > > > > In a steady state the EID-prefixes for the site and the locator-set > > for each EID-prefix MUST be the same on all ETRs. Procedures to > > enforce and/or verify this are outside the scope of this document. > > We will add this. > > > Note that there may be transient conditions when the EID-prefix > > for the site and locator-set for each EID-prefix MAY not be the > > same on all ETRs. > > We will add this first sentence but change "MAY not" to "may not" > since it is not a rule in this specification that the implementation > has an option of making the locator-set inconsistent. The locator-set > is only inconsistent between the time it takes a network administrator > to make it the same. If there is a configuration error and the > inconsistent state is for a longer period of time, then the text below > will cover that. > > > As a result, for the duration of these transient > > conditions not all the ETRs would be able to send Map-Reply > > messages with the same database mapping contents. > > We did not include this sentence above, because it is not true. The > ETRs can still send Map-Replies with their idea of the locator-set. > And an depending where an ITR's Map-Request is sent, will determine > which locator-set the ITR caches. If the locators are disconnected > from the network, RLOC-probing will tell you this and ITRs will not > encapsulate to them. You agree that during transients the EID-prefix for the site and locator-set for each EID-prefix may not be the same on all ETRs. If that is the case, then how would all these ETRs during transients be able to send Map-Reply messages with the same database mapping contents ? > If there is locator-set policy on the map-server, then maybe one > locator-set or the other won't be accepted by the map-server. > > And if proxy-replying is sent in the map-register, then it is the map- > server's idea of the locator-set that is sent consistently in all Map- > Replies. > > So we will say there are no negative implications. > > > Furthermore, if the authors think that sending inconsistent Map-Reply > > during transients has no negative implications, then add the > > following at > > the end of the text I suggested above: > > > > This has no negative implications. > > > > And if the authors think that sending inconsistent Map-Reply during > > transients does have negative implications, then the authors should > > list > > them following the text I suggested above. > > > > Yakov. > > Here is the new proposed text: > > EID-to-RLOC Database: The EID-to-RLOC database is 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. In a steady > state the EID-prefixes for the site and the locator-set for each > EID-prefix MUST be the same on all ETRs. Procedures to enforce > and/or verify this are outside the scope of this document. Note > that there may be transient conditions when the EID-prefix for > the > site and locator-set for each EID-prefix may not be the same on > all ETRs. This has no negative implications. Please add the following before the last sentence in the above: As a result, for the duration of these transient conditions not all the ETRs may be able to send Map-Reply messages with the same database mapping contents. Yakov. From trac+lisp@trac.tools.ietf.org Tue Mar 29 08:27:27 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F293A6959 for ; Tue, 29 Mar 2011 08:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 eb916T5DT1X6 for ; Tue, 29 Mar 2011 08:27:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2DFC33A6931 for ; Tue, 29 Mar 2011 08:27:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4aqn-0006J0-SR; Tue, 29 Mar 2011 08:28: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 29 Mar 2011 15:28:57 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/3#comment:3 Message-ID: <069.75de64cc043292b18c3475d70aa2220f@trac.tools.ietf.org> References: <060.1160706e8afb7f5d8d1e81053d148847@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <060.1160706e8afb7f5d8d1e81053d148847@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #3: lisp-ms security mechanism between ITR and map resolver 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: Tue, 29 Mar 2011 15:27:27 -0000 #3: lisp-ms security mechanism between ITR and map resolver Comment(by jmh@…): Unless there is further discussion indicating that this needs to be improved in the base spec, the chairs expect that this will be mvoed to the LISP-SEC document once that is a working group document, and we will verify whether at that point it is sufficiently addressed. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: major | Component: ms Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 08:46:47 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F7E3A6A4A for ; Tue, 29 Mar 2011 08:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 PMQOGUvO9YgO for ; Tue, 29 Mar 2011 08:46:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D76203A697F for ; Tue, 29 Mar 2011 08:46:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4b9d-0007h4-35; Tue, 29 Mar 2011 08:48: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 29 Mar 2011 15:48:25 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/lisp/trac/ticket/75#comment:2 Message-ID: <077.943e586f33e4f1d1fab15f7d763c249c@trac.tools.ietf.org> References: <068.6f9a0735f72eae0748ba4895dfdda8c8@trac.tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <068.6f9a0735f72eae0748ba4895dfdda8c8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 15:46:47 -0000 #75: Security of Map-Register message. Comment(by jmh@…): In chair review of this comment, there appear to be several separate items. 1) We can use RFC 2119 language if that will help. 2) With regard to requiring the Map Server to verify the EID prefix is known to be associated with the registering ETR, section 4.3 already says that it does verify that. Section 4.2 however merely says it should verify that, and we need to fix that to align with the check being required. 3) We can note in the security considerations section that additional checks are for further study. To avoid coupling LISP-SEC, we will not say explicitly that some of those are in LISP-SEC, and some, such as full global validation, are for even later. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: new Priority: major | Component: ms Severity: - | Keywords: ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 08:48:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E603A697F for ; Tue, 29 Mar 2011 08:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 CZWFh7tJ3lA7 for ; Tue, 29 Mar 2011 08:48:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2A7573A6812 for ; Tue, 29 Mar 2011 08:48:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bBR-0001YP-IZ; Tue, 29 Mar 2011 08:50: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 15:50:17 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/98#comment:4 Message-ID: <066.606c96451008ad435e296d6dd274bd32@trac.tools.ietf.org> References: <057.4c9852b0a65d29853b641f556c39a295@trac.tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <057.4c9852b0a65d29853b641f556c39a295@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 15:48:40 -0000 #98: LISP nonce (comment 17 reported by Y. Rekhter) Changes (by yakov@…): * status: reopened => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 08:51:06 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0ECF28C0D7 for ; Tue, 29 Mar 2011 08:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 gyxdBkjxt6VR for ; Tue, 29 Mar 2011 08:51:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2B28F3A67E4 for ; Tue, 29 Mar 2011 08:51:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bDn-0001fp-OY; Tue, 29 Mar 2011 08:52:43 -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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 15:52:43 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/99#comment:1 Message-ID: <066.a11d18752b914d7322d7c40f2d04b889@trac.tools.ietf.org> References: <057.412ba34f2babe03fe10d1234f260eba3@trac.tools.ietf.org> X-Trac-Ticket-ID: 99 In-Reply-To: <057.412ba34f2babe03fe10d1234f260eba3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 15:51:06 -0000 #99: Confusion in Section 5.4.1 (comment 18 reported by Y. Rekhter) Changes (by yakov@…): * status: new => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 08:52:50 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D083A6A4F for ; Tue, 29 Mar 2011 08:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 hV9kuZ7CoMA4 for ; Tue, 29 Mar 2011 08:52:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 17D373A6A4E for ; Tue, 29 Mar 2011 08:52:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bFT-0001j7-LR; Tue, 29 Mar 2011 08:54: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 15:54:27 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/lisp/trac/ticket/103#comment:1 Message-ID: <066.1c74f2dfbb76beebc49570b7d17e3555@trac.tools.ietf.org> References: <057.d807df80a56b7add227b99565ce590d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <057.d807df80a56b7add227b99565ce590d8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 15:52:50 -0000 #103: Mapping Protocol Data (comment 20 reported by Y. Rekhter) Changes (by yakov@…): * status: new => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 08:55:28 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF653A690E for ; Tue, 29 Mar 2011 08:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 yCuUjzeUQI0d for ; Tue, 29 Mar 2011 08:55:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6E9F93A6981 for ; Tue, 29 Mar 2011 08:55:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bI0-00027L-1Y; Tue, 29 Mar 2011 08:57: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 15:57:04 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/109#comment:1 Message-ID: <066.36f8e8a7bcdae00046120216f7812f19@trac.tools.ietf.org> References: <057.9c2e4d52ca3762d5ccd0de2094680378@trac.tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <057.9c2e4d52ca3762d5ccd0de2094680378@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 15:55:28 -0000 #109: "Locator" in Map-reply message format (comment 22 reported by Y. Rekhter) Changes (by yakov@…): * status: new => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:12:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5523A6981 for ; Tue, 29 Mar 2011 09:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0lCgOItaSAx9 for ; Tue, 29 Mar 2011 09:11:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 82C0F3A6985 for ; Tue, 29 Mar 2011 09:11:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bXv-0002LD-3h; Tue, 29 Mar 2011 09:13:31 -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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:13:31 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/lisp/trac/ticket/4#comment:1 Message-ID: <093.dc7137a4cc4549c92d7f757c3c613455@trac.tools.ietf.org> References: <084.db5eb501d0b28549ddf3634d2b9c21ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <084.db5eb501d0b28549ddf3634d2b9c21ea@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #4: LISP errors 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: Tue, 29 Mar 2011 16:12:01 -0000 #4: LISP errors Changes (by jmh@…): * status: new => resolved * resolution: => invalid Comment: If there are specific error cases that need to be covered, an issued should be raised describing the problem. The IETf does not generally expect the specification to describe the handling of all possible implementation errors. -- ----------------------------------------------------------+----------------- Reporter: "Templin, Fred L" | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: invalid Keywords: | ----------------------------------------------------------+----------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:12:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140E63A6A51 for ; Tue, 29 Mar 2011 09:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 ZlOg6Zi+LKYx for ; Tue, 29 Mar 2011 09:12:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BBA4F3A6975 for ; Tue, 29 Mar 2011 09:12:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bYA-0003Xt-Pf; Tue, 29 Mar 2011 09:13: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:13:46 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/57#comment:6 Message-ID: <077.040590520c7155a4bab030ab31e02019@trac.tools.ietf.org> References: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 29 Mar 2011 16:12:12 -0000 #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) Changes (by yakov@…): * status: reopened => resolved * resolution: => fixed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:19:14 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5283A691E for ; Tue, 29 Mar 2011 09:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 b0OlgectJdJW for ; Tue, 29 Mar 2011 09:19:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1C29A3A6863 for ; Tue, 29 Mar 2011 09:19:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bf0-0005T2-Rw; Tue, 29 Mar 2011 09:20: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:20:50 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:4 Message-ID: <069.8bcb7a6d5af583176e254aed697bb359@trac.tools.ietf.org> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #27: ETR may claim a larger prefix than is delegated to it 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: Tue, 29 Mar 2011 16:19:15 -0000 #27: ETR may claim a larger prefix than is delegated to it Changes (by jmh@…): * status: reopened => resolved * resolution: => fixed Comment: While the base question of over-claiming is valid, it is also complicated and multi-faceted. As such, we will not be adding additional mechanisms in the base LISP specification to address this. Significant improvements are proposed in LISP-SEC, including noting that the use of a structure such as RPKI is for further study. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:23:08 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6C93A6A45 for ; Tue, 29 Mar 2011 09:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 nWgbBfymfS18 for ; Tue, 29 Mar 2011 09:23:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CF7153A6943 for ; Tue, 29 Mar 2011 09:23:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bin-0004a5-75; Tue, 29 Mar 2011 09:24: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:24:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/68#comment:5 Message-ID: <077.2c147404f86776d7c164524d21de1c51@trac.tools.ietf.org> References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 29 Mar 2011 16:23:08 -0000 #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) Changes (by yakov@…): * status: reopened => resolved * resolution: => fixed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:24:37 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489BD3A6A4D for ; Tue, 29 Mar 2011 09:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 YFptr4QgBB4Q for ; Tue, 29 Mar 2011 09:24:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AE9853A6A4F for ; Tue, 29 Mar 2011 09:24:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bkA-0007Mo-D8; Tue, 29 Mar 2011 09:26: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:26:10 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/46#comment:6 Message-ID: <066.78965594e2a0942ac8660a75b80688ef@trac.tools.ietf.org> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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: Tue, 29 Mar 2011 16:24:37 -0000 #46: Cache Thrashing (review by Y. Rekhter) Changes (by jmh@…): * status: reopened => resolved * resolution: => fixed Comment: Text has been added to the -11 revision of teh specification noting that cache thrashing happens, that implementors should think about it, and that the experiment may tell us more about whether this is an issue needing further attention. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:29:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8A03A6A21 for ; Tue, 29 Mar 2011 09:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2KSwN1K8i-Ay for ; Tue, 29 Mar 2011 09:29:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7C0BD3A6985 for ; Tue, 29 Mar 2011 09:29:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4box-0005YX-2P; Tue, 29 Mar 2011 09:31: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:31:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/49#comment:4 Message-ID: <066.b34b1097a720f32298169f0206684b35@trac.tools.ietf.org> References: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #49: "MAP-Replies" content that is allowed to change (review 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: Tue, 29 Mar 2011 16:29:32 -0000 #49: "MAP-Replies" content that is allowed to change (review by Y. Rekhter) Changes (by jmh@…): * status: reopened => resolved * resolution: => fixed Comment: Nothing in the specification states or implies that the contents of replies can not change over time. As such, there does not appear to be an issue to be addressed. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:30:25 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD7D3A6985 for ; Tue, 29 Mar 2011 09:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 R3UxSufvEMPM for ; Tue, 29 Mar 2011 09:30:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 368D53A6981 for ; Tue, 29 Mar 2011 09:30:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bpp-0000MK-Ly; Tue, 29 Mar 2011 09:32: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:32:01 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/50#comment:4 Message-ID: <066.616b4849163afb8be5255b639d3980a2@trac.tools.ietf.org> References: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #50: MAP-Replies content that MUST be invariant (review 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: Tue, 29 Mar 2011 16:30:25 -0000 #50: MAP-Replies content that MUST be invariant (review by Y. Rekhter) Changes (by jmh@…): * status: reopened => resolved * resolution: => fixed Comment: As noted for ticket #49, map reply contents can change over time. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:32:01 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01933A6981 for ; Tue, 29 Mar 2011 09:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 vhFhsk6LkacV for ; Tue, 29 Mar 2011 09:31:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2A1A33A695D for ; Tue, 29 Mar 2011 09:31:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4brN-0003aQ-OS; Tue, 29 Mar 2011 09:33: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:33:37 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/86#comment:1 Message-ID: <066.8ee6fe828ca9456811919cc97c83a216@trac.tools.ietf.org> References: <057.1f293e91cef920f8eee0de47c3c10e1d@trac.tools.ietf.org> X-Trac-Ticket-ID: 86 In-Reply-To: <057.1f293e91cef920f8eee0de47c3c10e1d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 16:32:01 -0000 #86: On the design goals and requirements (comment 10 reported by Y. Rekhter) Changes (by yakov@…): * status: new => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:33:35 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6553A695D for ; Tue, 29 Mar 2011 09:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 sFEwIGtgTfLG for ; Tue, 29 Mar 2011 09:33:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DF7923A68BB for ; Tue, 29 Mar 2011 09:33:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4bsv-0006w5-Gr; Tue, 29 Mar 2011 09:35: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:35:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/51#comment:1 Message-ID: <066.078654e55fa4d8b404ff14d35ef4d806@trac.tools.ietf.org> References: <057.afb9a72f6ee9de02e699ffa4cc31fd68@trac.tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <057.afb9a72f6ee9de02e699ffa4cc31fd68@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #51: Returning same locator-set for a given EID (review 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: Tue, 29 Mar 2011 16:33:35 -0000 #51: Returning same locator-set for a given EID (review by Y. Rekhter) Changes (by jmh@…): * status: new => resolved * resolution: => fixed Comment: As stated in the specification, the ETRs whcih register this information are under common administrative control, and are to be configured with the same information. Transient inconsistencies do not cause problems. If an end user porduces a problem for themselves by extreme and persistent mis- configuration, then they have hurt themselves. This is not an issue this protocol needs to address. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:42:33 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E563A6A56 for ; Tue, 29 Mar 2011 09:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 Ao9FKMw9D3gY for ; Tue, 29 Mar 2011 09:42:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 33A6A3A697F for ; Tue, 29 Mar 2011 09:42:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4c1b-0006wz-8G; Tue, 29 Mar 2011 09:44: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:44:11 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/96#comment:1 Message-ID: <066.a3ae29a7e71e0531b34d1c3fedbd0712@trac.tools.ietf.org> References: <057.6ff6aad30217bed0a620c320885db98b@trac.tools.ietf.org> X-Trac-Ticket-ID: 96 In-Reply-To: <057.6ff6aad30217bed0a620c320885db98b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 16:42:34 -0000 #96: Confidence in informal Survey (comment 16 reported by Y. Rekhter) Changes (by yakov@…): * status: new => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:43:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240CA3A6A56 for ; Tue, 29 Mar 2011 09:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TlxgEZtrxoFc for ; Tue, 29 Mar 2011 09:43:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8CD8F3A697F for ; Tue, 29 Mar 2011 09:43:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4c2Y-00070N-5s; Tue, 29 Mar 2011 09:45: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:45:10 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/97#comment:1 Message-ID: <066.aa786d1f93c881507cdda7614e934604@trac.tools.ietf.org> References: <057.8ea20e7a00dec499bcff4e4fa48eacda@trac.tools.ietf.org> X-Trac-Ticket-ID: 97 In-Reply-To: <057.8ea20e7a00dec499bcff4e4fa48eacda@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 16:43:32 -0000 #97: MTU concerns (comment 16 reported by Y. Rekhter) Changes (by yakov@…): * status: new => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 09:45:14 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB6C28C0DE for ; Tue, 29 Mar 2011 09:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 TqMhxNIaTmUm for ; Tue, 29 Mar 2011 09:45:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3A66A28C0DB for ; Tue, 29 Mar 2011 09:45:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4c4B-0007wD-KE; Tue, 29 Mar 2011 09:46: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com X-Trac-Project: lisp Date: Tue, 29 Mar 2011 16:46:51 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/55#comment:1 Message-ID: <066.dd21fdc1c74f6c356de07f8349fd1949@trac.tools.ietf.org> References: <057.cfd7e4056637dce0c518d9d74eaa3c20@trac.tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <057.cfd7e4056637dce0c518d9d74eaa3c20@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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 List-Id: 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, 29 Mar 2011 16:45:14 -0000 #55: ETR failure and its implications on connectivity restoration time (review by Y. Rekhter) Changes (by jmh@…): * status: new => resolved * resolution: => fixed Comment: Text has been added to the documents on path liveness, including ETR liveness, checking, and responses ITRs can take to failures. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 10:03:44 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3453A68C3 for ; Tue, 29 Mar 2011 10:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 WgoukXv7QXRL for ; Tue, 29 Mar 2011 10:03:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 624C83A6870 for ; Tue, 29 Mar 2011 10:03:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4cM3-0001j3-L3; Tue, 29 Mar 2011 10:05: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Tue, 29 Mar 2011 17:05:19 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/lisp/trac/ticket/69#comment:3 Message-ID: <077.cb7f3e7fe4d419fe28675bb4aefdc869@trac.tools.ietf.org> References: <068.062591f9c2a73c88a94091fd86bb2c73@trac.tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <068.062591f9c2a73c88a94091fd86bb2c73@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 29 Mar 2011 17:03:44 -0000 #69: Inadequate solution for ETR overclaims (from Y. Rekhter's review) Changes (by jmh@…): * status: new => resolved * resolution: => fixed Comment: See the resolution of ticket #27 for the plans to address this issue in the future. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From yakov@juniper.net Tue Mar 29 10:13:23 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03ABC3A6A68 for ; Tue, 29 Mar 2011 10:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.357 X-Spam-Level: X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 YXhydT2lD7qo for ; Tue, 29 Mar 2011 10:13:22 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 7BC703A6986 for ; Tue, 29 Mar 2011 10:13:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTZITiuB8p2IGYpBB5Xx+OSwL14Wjj/Yv@postini.com; Tue, 29 Mar 2011 10:15:00 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 10:12: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 p2THEIv41513; Tue, 29 Mar 2011 10:14:18 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103291714.p2THEIv41513@magenta.juniper.net> To: , , , , In-Reply-To: <066.78965594e2a0942ac8660a75b80688ef@trac.tools.ietf.org> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> <066.78965594e2a0942ac8660a75b80688ef@trac.tools.ietf.org> X-MH-In-Reply-To: "lisp issue tracker" message dated "Tue, 29 Mar 2011 16:26:10 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <93214.1301418858.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 10:14:18 -0700 From: Yakov Rekhter Subject: Re: [lisp] #46: Cache Thrashing (review 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: Tue, 29 Mar 2011 17:13:23 -0000 Hi, > #46: Cache Thrashing (review by Y. Rekhter) > = > Changes (by jmh@=E2=80=A6): > = > * status: reopened =3D> resolved > * resolution: =3D> fixed > = > = > Comment: > = > Text has been added to the -11 revision of teh specification noting tha= t > cache thrashing happens, that implementors should think about it, and t= hat > the experiment may tell us more about whether this is an issue needing > further attention. Here is the text that has been added: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue to be kept in mind during implementation. It is a good idea to have instrumentation in place = to detect thrashing of the cache. Implementation experimentation = will be used to determine which cache management strategies work best. The above text failed to mention that cache sizing is an issue not just "during implementation", but during deployment as well. Moreover, the above text failed to mention that in the context of LISP, thrashing of the cache on a given ITR/PTR has non-local implications, as it could result in excessive volume of LISP control traffic, which in turn would further deteriorate the situation. Finally, the above failed to mention that being able to detect thrasing is necessary, but not sufficient - an implementation must be able to suppress thrasing. With all this in mind I would like to propose replacing the text quoted above with the following: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue to be kept in mind during both implementation and deployment. In the context of LISP, cache thrasing on the ITR/PTR could result in the ITR/PTR dropping data, thus negatively affecting connectivity. Moreover, it could also result in excessive volume of LISP control traffic, which could spread the detrimental effects of thrasing beyond the ITR/PTR and all the hosts that communicate through this ITR/PTR. Therefore, an implementation MUST provide instrumentation in place to detect thrashing of the cache, and MUST provide mechanism(s) to suppress thrasing. Specifications of such mechanisms are outside the scope of this document. Implementation experimentation will be used to determine which cache management strategies work best. Yakov. > = > -- = > -------------------------------+----------------------------------------= ---- > Reporter: wmhaddad@=E2=80=A6 | Owner: = > Type: technical | Status: resolved = > Priority: major | Component: draft-ietf-lisp > Severity: - | Resolution: fixed = > Keywords: | = > -------------------------------+----------------------------------------= ---- > = > Ticket URL: > lisp > LISP WG document issues From yakov@juniper.net Tue Mar 29 11:25:50 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090CD3A6A93 for ; Tue, 29 Mar 2011 11:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.369 X-Spam-Level: X-Spam-Status: No, score=-106.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 X4+bT0ko9j5r for ; Tue, 29 Mar 2011 11:25:49 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id E3E683A6A82 for ; Tue, 29 Mar 2011 11:25:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTZIki0WDLx1Ou2wcDn3q/W2BWvXZgyEu@postini.com; Tue, 29 Mar 2011 11:27:27 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 11:24:58 -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 p2TIQSv78606; Tue, 29 Mar 2011 11:26:28 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103291826.p2TIQSv78606@magenta.juniper.net> To: , , In-Reply-To: <069.8bcb7a6d5af583176e254aed697bb359@trac.tools.ietf.org> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.8bcb7a6d5af583176e254aed697bb359@trac.tools.ietf.org> X-MH-In-Reply-To: "lisp issue tracker" message dated "Tue, 29 Mar 2011 16:20:50 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <99345.1301423188.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 11:26:28 -0700 From: Yakov Rekhter Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 29 Mar 2011 18:25:50 -0000 Folks, > #27: ETR may claim a larger prefix than is delegated to it > = > Changes (by jmh@=E2=80=A6): > = > * status: reopened =3D> resolved > * resolution: =3D> fixed > = > = > Comment: > = > While the base question of over-claiming is valid, it is also complicat= ed > and multi-faceted. As such, we will not be adding additional mechanism= s > in the base LISP specification to address this. Significant improvemen= ts > are proposed in LISP-SEC, including noting that the use of a structure > such as RPKI is for further study. The base LISP specification should just document the issue of over-claimin= g, = and then point to LISP-SEC. Yakov. > = > -- = > ----------------------------------+-------------------------------------= ---- > Reporter: hartmans-ietf@=E2=80=A6 | Owner: = = > Type: technical | Status: resolved = > Priority: major | Component: draft-ietf-lisp > Severity: - | Resolution: fixed = > Keywords: | = > ----------------------------------+-------------------------------------= ---- > = > Ticket URL: > lisp > LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 12:09:36 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7773A6A25 for ; Tue, 29 Mar 2011 12:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 IgeLGRord8B6 for ; Tue, 29 Mar 2011 12:09:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9A8683A6A1E for ; Tue, 29 Mar 2011 12:09:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4eJt-0006Je-7L; Tue, 29 Mar 2011 12:11: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 19:11:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/106#comment:1 Message-ID: <066.c903a3fd2b499574ad531f12d9a9e0a1@trac.tools.ietf.org> References: <057.39e8e70821ba35f11c2eda95607db252@trac.tools.ietf.org> X-Trac-Ticket-ID: 106 In-Reply-To: <057.39e8e70821ba35f11c2eda95607db252@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 19:09:36 -0000 #106: Unassigned values in Map-Reply messages (comment 22 reported by Y. Rekhter) Changes (by yakov@…): * status: new => resolved * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 12:28:17 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A2D3A6A64 for ; Tue, 29 Mar 2011 12:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 t9mXW9NjYSlv for ; Tue, 29 Mar 2011 12:28:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4E34D3A6A2A for ; Tue, 29 Mar 2011 12:28:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4ebw-0006NN-IN; Tue, 29 Mar 2011 12:29: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: yakov@juniper.net X-Trac-Project: lisp Date: Tue, 29 Mar 2011 19:29:52 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/lisp/trac/ticket/108#comment:1 Message-ID: <066.61be0cfdf5abac76c31fca3228ab5011@trac.tools.ietf.org> References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> X-Trac-Ticket-ID: 108 In-Reply-To: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Tue, 29 Mar 2011 19:28:17 -0000 #108: "R" bit in Map-Reply message format (comment 22 reported by Y. Rekhter) Comment(by yakov@…): Here is the new text (from -11 version): R: set when the sender of a Map-Reply has a route to the locator in the locator data record. This receiver may find this useful to know when determining if the locator is reachable from the receiver. See also Section 6.4 for another way the R-bit may be used. I'd like to propose the following replacement to the above: R: set when the sender of a Map-Reply has a route to the locator in the locator data record (note that since having the route, by itself, does not imply that the locator is up, having the R bit set does not imply that the locator is up). This receiver may find this useful to know when determining if the locator could be reachable from the receiver. See also Section 6.4 for another way the R-bit may be used. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From dino@cisco.com Tue Mar 29 12:32:41 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6813A6AAD for ; Tue, 29 Mar 2011 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_72=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 QrD-FhBxpPUR for ; Tue, 29 Mar 2011 12:32:40 -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 AC5813A6A93 for ; Tue, 29 Mar 2011 12:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1921; q=dns/txt; s=iport; t=1301427259; x=1302636859; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=wzDf9M95ckCAWVKsScSACJOFA0Vj6Su7Ze4fujvrpl0=; b=JlBCJL0Yl8d56EfQiFF4ae98slPxAG28o91/MaL4kXd1qR2siUFu7PiV DA5lcoDnO+SpQCCpRIpaOiD1n1h/Sb7eSA1jwYkaEYyckZkp4jGWJF4EL e8+GHK+tXlE1TlwMVxeizy6OQ1GPvU9sAyyDWN8yCFuWFhu5nFVVTTs7X c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABszkk2rRDoJ/2dsb2JhbAClT3encZxyhWoEhTyHRg X-IronPort-AV: E=Sophos;i="4.63,264,1299456000"; d="scan'208";a="285180842" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 19:34:19 +0000 Received: from dhcp-1789.meeting.ietf.org (sjc-vpn4-644.cisco.com [10.21.82.132]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2TJYHnI016611; Tue, 29 Mar 2011 19:34:18 GMT Message-Id: <6C05CFEE-653D-44EA-946A-2C051D035E3A@cisco.com> From: Dino Farinacci To: "lisp issue tracker" In-Reply-To: <066.61be0cfdf5abac76c31fca3228ab5011@trac.tools.ietf.org> 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: Tue, 29 Mar 2011 12:34:16 -0700 References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> <066.61be0cfdf5abac76c31fca3228ab5011@trac.tools.ietf.org> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [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 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, 29 Mar 2011 19:32:41 -0000 We mentioned this in the locator-reachability section. I don't think =20 we need to repeat it again in a packet format field description area. Dino On Mar 29, 2011, at 12:29 PM, lisp issue tracker wrote: > #108: "R" bit in Map-Reply message format (comment 22 reported by Y. =20= > Rekhter) > > > Comment(by yakov@=85): > > Here is the new text (from -11 version): > > R: set when the sender of a Map-Reply has a route to the locator in > the locator data record. This receiver may find this useful to > know when determining if the locator is reachable from the > receiver. See also Section 6.4 for another way the R-bit may be > used. > > I'd like to propose the following replacement to the above: > > R: set when the sender of a Map-Reply has a route to the locator in > the locator data record (note that since having the route, by =20 > itself, > does not imply that the locator is up, having > the R bit set does not imply that the locator is up). > This receiver may find this useful to know when determining if =20= > the > locator could be reachable from the receiver. > See also Section 6.4 for another way the R-bit may be used. > > --=20 > -------------------------------=20 > +-------------------------------------------- > Reporter: wmhaddad@=85 | Owner: > Type: technical | Status: new > Priority: major | Component: draft-ietf-lisp > Severity: - | Keywords: > -------------------------------=20 > +-------------------------------------------- > > Ticket URL: > lisp > LISP WG document issues > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Tue Mar 29 12:34:17 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F3A3A6A1E for ; Tue, 29 Mar 2011 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 mzKt35S8mz0l for ; Tue, 29 Mar 2011 12:34:16 -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 109443A6825 for ; Tue, 29 Mar 2011 12:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=4385; q=dns/txt; s=iport; t=1301427354; x=1302636954; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=hjxJ1NFKNXOI//MkuapmmrixGV2FUibIRUzr0rPjQWM=; b=VYQpbKUudjQ9MvsCJDAdMZ6zmGnmXTGNxZ9ZGb66TXFotmGL9c52OnJh 80tH4/2LBAehyqFJiFzxZNt/iItqfEmofFDUmoyQ9jicjtnTFVXe17z7M 5hueA8lK2F5ZaZOrcmMgxWnVII8yySZLNTmq6ZoUC9T6wSsUsnn7a16Fx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE00kk2rRDoH/2dsb2JhbAClT3eIeZ8BnG+FagSFPIdG X-IronPort-AV: E=Sophos;i="4.63,264,1299456000"; d="scan'208";a="285182397" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 19:35:54 +0000 Received: from dhcp-1789.meeting.ietf.org (sjc-vpn4-644.cisco.com [10.21.82.132]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2TJZqbb010039; Tue, 29 Mar 2011 19:35:53 GMT Message-Id: <624CEB8B-49C6-4C80-BC81-9DE1B3F6CEBF@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201103291320.p2TDKev34441@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, 29 Mar 2011 12:35:51 -0700 References: <201103281748.p2SHmmv14212@magenta.juniper.net> <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> <201103291320.p2TDKev34441@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 19:34:17 -0000 > Dino, > >>> Deleting the last part of the last sentence is not enough. You also >>> need to point out that the "MUST" applies only to steady state, and >>> also document that during transients Map-Replies may not be >>> consistent. >>> >>> With this in mind please replace the last sentence with the >>> following: >>> >>> In a steady state the EID-prefixes for the site and the locator- >>> set >>> for each EID-prefix MUST be the same on all ETRs. Procedures to >>> enforce and/or verify this are outside the scope of this document. >> >> We will add this. >> >>> Note that there may be transient conditions when the EID-prefix >>> for the site and locator-set for each EID-prefix MAY not be the >>> same on all ETRs. >> >> We will add this first sentence but change "MAY not" to "may not" >> since it is not a rule in this specification that the implementation >> has an option of making the locator-set inconsistent. The locator-set >> is only inconsistent between the time it takes a network >> administrator >> to make it the same. If there is a configuration error and the >> inconsistent state is for a longer period of time, then the text >> below >> will cover that. >> >>> As a result, for the duration of these transient >>> conditions not all the ETRs would be able to send Map-Reply >>> messages with the same database mapping contents. >> >> We did not include this sentence above, because it is not true. The >> ETRs can still send Map-Replies with their idea of the locator-set. >> And an depending where an ITR's Map-Request is sent, will determine >> which locator-set the ITR caches. If the locators are disconnected >> from the network, RLOC-probing will tell you this and ITRs will not >> encapsulate to them. > > You agree that during transients the EID-prefix for the site > and locator-set for each EID-prefix may not be the same on all ETRs. Yes, I agree. > If that is the case, then how would all these ETRs during transients > be able to send Map-Reply messages with the same database mapping > contents ? No, they won't. But this text we are beating to death is in a definition section of "EID-to-RLOC Database". >> If there is locator-set policy on the map-server, then maybe one >> locator-set or the other won't be accepted by the map-server. >> >> And if proxy-replying is sent in the map-register, then it is the >> map- >> server's idea of the locator-set that is sent consistently in all >> Map- >> Replies. >> >> So we will say there are no negative implications. >> >>> Furthermore, if the authors think that sending inconsistent Map- >>> Reply >>> during transients has no negative implications, then add the >>> following at >>> the end of the text I suggested above: >>> >>> This has no negative implications. >>> >>> And if the authors think that sending inconsistent Map-Reply during >>> transients does have negative implications, then the authors should >>> list >>> them following the text I suggested above. >>> >>> Yakov. >> >> Here is the new proposed text: >> >> EID-to-RLOC Database: The EID-to-RLOC database is 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. In a steady >> state the EID-prefixes for the site and the locator-set for >> each >> EID-prefix MUST be the same on all ETRs. Procedures to enforce >> and/or verify this are outside the scope of this document. >> Note >> that there may be transient conditions when the EID-prefix for >> the >> site and locator-set for each EID-prefix may not be the same on >> all ETRs. This has no negative implications. > > Please add the following before the last sentence in the above: > > As a result, for the duration of these transient > conditions not all the ETRs may be able to send Map-Reply > messages with the same database mapping contents. I don't think it is necessary. Dino > > Yakov. From yakov@juniper.net Tue Mar 29 12:43:37 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8303A6AA1 for ; Tue, 29 Mar 2011 12:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.08 X-Spam-Level: X-Spam-Status: No, score=-106.08 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 mAUiSbNoFLb5 for ; Tue, 29 Mar 2011 12:43:34 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 1AB013A6A2E for ; Tue, 29 Mar 2011 12:43:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTZI2xAOt/s3CZSehSa0w/wUzx7ptV6g/@postini.com; Tue, 29 Mar 2011 12:45:12 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 12:43:34 -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 p2TJj3v38570; Tue, 29 Mar 2011 12:45:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103291945.p2TJj3v38570@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <6C05CFEE-653D-44EA-946A-2C051D035E3A@cisco.com> References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> <066.61be0cfdf5abac76c31fca3228ab5011@trac.tools.ietf.org> <6C05CFEE-653D-44EA-946A-2C051D035E3A@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Tue, 29 Mar 2011 12:34:16 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <4109.1301427903.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 12:45:03 -0700 From: Yakov Rekhter Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [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 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, 29 Mar 2011 19:43:37 -0000 Dino, > We mentioned this in the locator-reachability section. = Could you please point me to the specific text in the locator-reachability section that talks about using the R bit. Yakov. > I don't think = > we need to repeat it again in a packet format field description area. > = > Dino > = > On Mar 29, 2011, at 12:29 PM, lisp issue tracker wrote: > = > > #108: "R" bit in Map-Reply message format (comment 22 reported by Y. = > > Rekhter) > > > > > > Comment(by yakov@=85): > > > > Here is the new text (from -11 version): > > > > R: set when the sender of a Map-Reply has a route to the locator in > > the locator data record. This receiver may find this useful to > > know when determining if the locator is reachable from the > > receiver. See also Section 6.4 for another way the R-bit may be > > used. > > > > I'd like to propose the following replacement to the above: > > > > R: set when the sender of a Map-Reply has a route to the locator in > > the locator data record (note that since having the route, by = > > itself, > > does not imply that the locator is up, having > > the R bit set does not imply that the locator is up). > > This receiver may find this useful to know when determining if = > > the > > locator could be reachable from the receiver. > > See also Section 6.4 for another way the R-bit may be used. > > > > -- = > > ------------------------------- = > > +-------------------------------------------- > > Reporter: wmhaddad@=85 | Owner: > > Type: technical | Status: new > > Priority: major | Component: draft-ietf-lisp > > Severity: - | Keywords: > > ------------------------------- = > > +-------------------------------------------- > > > > Ticket URL: > > lisp > > LISP WG document issues > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > = > = From dino@cisco.com Tue Mar 29 12:45:19 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE6E3A68F4 for ; Tue, 29 Mar 2011 12:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_72=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 WHdfBdymvxPI for ; Tue, 29 Mar 2011 12:45:09 -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 698F63A6AA1 for ; Tue, 29 Mar 2011 12:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2365; q=dns/txt; s=iport; t=1301428004; x=1302637604; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=kQCKduch6EG5QsHyNEkP5yo42LXXFZvz5A58E0lWSn4=; b=mJSZiuv2RhGi8mlRKFZrUSbNdfG0e+pyWP5bSGcxeUMkiTW2IrycXGca 43L0pRCLctAnd2ATACxVO5V7Tqti9u5FZiiftJENhC8tmAPK7UmtMN5xv HhymCq8tI1pl+Z7/lScImWs2IxomEgCn17FAhJ/39nPYk5YAG2Q9Rgj3E k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALM1kk2rRDoG/2dsb2JhbAClT3eIeZ8DnG+FagSFPIdG X-IronPort-AV: E=Sophos;i="4.63,264,1299456000"; d="scan'208";a="420456684" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2011 19:46:43 +0000 Received: from dhcp-1789.meeting.ietf.org (sjc-vpn4-644.cisco.com [10.21.82.132]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2TJkfhL009667; Tue, 29 Mar 2011 19:46:42 GMT Message-Id: <1ECBB39B-709D-40AA-81F4-D9A949B8DC6C@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201103291945.p2TJj3v38570@magenta.juniper.net> 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: Tue, 29 Mar 2011 12:46:40 -0700 References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> <066.61be0cfdf5abac76c31fca3228ab5011@trac.tools.ietf.org> <6C05CFEE-653D-44EA-946A-2C051D035E3A@cisco.com> <201103291945.p2TJj3v38570@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [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 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, 29 Mar 2011 19:45:19 -0000 > Dino, > >> We mentioned this in the locator-reachability section. > > Could you please point me to the specific text in the locator-=20 > reachability > section that talks about using the R bit. The Locator Reachability Section indicates that even if a route is =20 present it does not mean you can reach the RLOC. That was the point =20 you wanted us to capture. Dino > > Yakov. > >> I don't think >> we need to repeat it again in a packet format field description area. >> >> Dino >> >> On Mar 29, 2011, at 12:29 PM, lisp issue tracker wrote: >> >>> #108: "R" bit in Map-Reply message format (comment 22 reported by Y. >>> Rekhter) >>> >>> >>> Comment(by yakov@=85): >>> >>> Here is the new text (from -11 version): >>> >>> R: set when the sender of a Map-Reply has a route to the locator in >>> the locator data record. This receiver may find this useful to >>> know when determining if the locator is reachable from the >>> receiver. See also Section 6.4 for another way the R-bit may =20= >>> be >>> used. >>> >>> I'd like to propose the following replacement to the above: >>> >>> R: set when the sender of a Map-Reply has a route to the locator in >>> the locator data record (note that since having the route, by >>> itself, >>> does not imply that the locator is up, having >>> the R bit set does not imply that the locator is up). >>> This receiver may find this useful to know when determining if >>> the >>> locator could be reachable from the receiver. >>> See also Section 6.4 for another way the R-bit may be used. >>> >>> --=20 >>> ------------------------------- >>> +-------------------------------------------- >>> Reporter: wmhaddad@=85 | Owner: >>> Type: technical | Status: new >>> Priority: major | Component: draft-ietf-lisp >>> Severity: - | Keywords: >>> ------------------------------- >>> +-------------------------------------------- >>> >>> Ticket URL: >> 1> >>> lisp >>> LISP WG document issues >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> From yakov@juniper.net Tue Mar 29 12:51:42 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87DBA3A6AB3 for ; Tue, 29 Mar 2011 12:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.376 X-Spam-Level: X-Spam-Status: No, score=-106.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Pnyp3mS0OMdX for ; Tue, 29 Mar 2011 12:51:41 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 200903A6AA1 for ; Tue, 29 Mar 2011 12:51:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTZI4q7hN3WlLMT9GffqgmNyW06wE+UkO@postini.com; Tue, 29 Mar 2011 12:53:19 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 12:50:53 -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 p2TJqNv41849; Tue, 29 Mar 2011 12:52:23 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103291952.p2TJqNv41849@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <624CEB8B-49C6-4C80-BC81-9DE1B3F6CEBF@cisco.com> References: <201103281748.p2SHmmv14212@magenta.juniper.net> <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> <201103291320.p2TDKev34441@magenta.juniper.net> <624CEB8B-49C6-4C80-BC81-9DE1B3F6CEBF@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Tue, 29 Mar 2011 12:35:51 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4349.1301428343.1@juniper.net> Date: Tue, 29 Mar 2011 12:52:23 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, lisp issue tracker Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 19:51:42 -0000 Dino, > >>> Deleting the last part of the last sentence is not enough. You also > >>> need to point out that the "MUST" applies only to steady state, and > >>> also document that during transients Map-Replies may not be > >>> consistent. > >>> > >>> With this in mind please replace the last sentence with the > >>> following: > >>> > >>> In a steady state the EID-prefixes for the site and the locator-set > >>> for each EID-prefix MUST be the same on all ETRs. Procedures to > >>> enforce and/or verify this are outside the scope of this document. > >> > >> We will add this. > >> > >>> Note that there may be transient conditions when the EID-prefix > >>> for the site and locator-set for each EID-prefix MAY not be the > >>> same on all ETRs. > >> > >> We will add this first sentence but change "MAY not" to "may not" > >> since it is not a rule in this specification that the implementation > >> has an option of making the locator-set inconsistent. The locator-set > >> is only inconsistent between the time it takes a network administrator > >> to make it the same. If there is a configuration error and the > >> inconsistent state is for a longer period of time, then the text below > >> will cover that. > >> > >>> As a result, for the duration of these transient > >>> conditions not all the ETRs would be able to send Map-Reply > >>> messages with the same database mapping contents. > >> > >> We did not include this sentence above, because it is not true. The > >> ETRs can still send Map-Replies with their idea of the locator-set. > >> And an depending where an ITR's Map-Request is sent, will determine > >> which locator-set the ITR caches. If the locators are disconnected > >> from the network, RLOC-probing will tell you this and ITRs will not > >> encapsulate to them. > > > > You agree that during transients the EID-prefix for the site > > and locator-set for each EID-prefix may not be the same on all ETRs. > > Yes, I agree. > > > If that is the case, then how would all these ETRs during transients > > be able to send Map-Reply messages with the same database mapping > > contents ? > > No, they won't. So you agree that these ETRs during transients may not be able to send Map-Reply messages with the same database mapping contents. Yet when I proposed to document it with the following: As a result, for the duration of these transient conditions not all the ETRs would be able to send Map-Reply messages with the same database mapping contents. your argument against this was We did not include this sentence above, because it is not true. So, does the sentence I proposed true or not true ? Yakov. > But this text we are beating to death is in a > definition section of "EID-to-RLOC Database". > > >> If there is locator-set policy on the map-server, then maybe one > >> locator-set or the other won't be accepted by the map-server. > >> > >> And if proxy-replying is sent in the map-register, then it is the > >> map- > >> server's idea of the locator-set that is sent consistently in all > >> Map- >> Replies. > >> > >> So we will say there are no negative implications. > >> > >>> Furthermore, if the authors think that sending inconsistent Map- > >>> Reply > >>> during transients has no negative implications, then add the > >>> following at > >>> the end of the text I suggested above: > >>> > >>> This has no negative implications. > >>> > >>> And if the authors think that sending inconsistent Map-Reply during > >>> transients does have negative implications, then the authors should > >>> list > >>> them following the text I suggested above. > >>> > >>> Yakov. > >> > >> Here is the new proposed text: > >> > >> EID-to-RLOC Database: The EID-to-RLOC database is 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. In a steady > >> state the EID-prefixes for the site and the locator-set for > >> each > >> EID-prefix MUST be the same on all ETRs. Procedures to enforce > >> and/or verify this are outside the scope of this document. > >> Note > >> that there may be transient conditions when the EID-prefix for > >> the > >> site and locator-set for each EID-prefix may not be the same on > >> all ETRs. This has no negative implications. > > > > Please add the following before the last sentence in the above: > > > > As a result, for the duration of these transient > > conditions not all the ETRs may be able to send Map-Reply > > messages with the same database mapping contents. > > I don't think it is necessary. > > Dino > > > > > Yakov. > From dino@cisco.com Tue Mar 29 12:54:38 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B14E3A6A95 for ; Tue, 29 Mar 2011 12:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 DhVv92LxqkMh for ; Tue, 29 Mar 2011 12:54:37 -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 A96133A693C for ; Tue, 29 Mar 2011 12:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=5449; q=dns/txt; s=iport; t=1301428574; x=1302638174; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=YL43KrDkU8l1gRcEqRg8l8qowT9yYfcigEx+EQZrBsg=; b=P7vA3F6AJJhbMRlvP5WqN7M1HMRwKCcI+zeE8/jMFhPNQ6zNcxu03HYi 5Wv4BBiapfItZgRwLfpQPAs1t/CUyGt/0aVbSnuxEADFVfwFVg9GIfTwg sT9ALTYw4fztj7k34mhEQPI8ZDSYVOQSffk/Ni/mi8DpSHzC606d01cPR I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPI4kk2rRDoJ/2dsb2JhbAClT3eIeZ51nG6FagSFPIdG X-IronPort-AV: E=Sophos;i="4.63,264,1299456000"; d="scan'208";a="285197762" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 19:56:03 +0000 Received: from dhcp-1789.meeting.ietf.org (sjc-vpn4-644.cisco.com [10.21.82.132]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2TJu1UY004497; Tue, 29 Mar 2011 19:56:01 GMT Message-Id: <34C88890-CB2E-493A-897F-D7E1F97CE8F8@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201103291952.p2TJqNv41849@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, 29 Mar 2011 12:56:00 -0700 References: <201103281748.p2SHmmv14212@magenta.juniper.net> <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> <201103291320.p2TDKev34441@magenta.juniper.net> <624CEB8B-49C6-4C80-BC81-9DE1B3F6CEBF@cisco.com> <201103291952.p2TJqNv41849@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 19:54:38 -0000 >>>>> Deleting the last part of the last sentence is not enough. You >>>>> also >>>>> need to point out that the "MUST" applies only to steady state, >>>>> and >>>>> also document that during transients Map-Replies may not be >>>>> consistent. >>>>> >>>>> With this in mind please replace the last sentence with the >>>>> following: >>>>> >>>>> In a steady state the EID-prefixes for the site and the locator- >>>>> set >>>>> for each EID-prefix MUST be the same on all ETRs. Procedures to >>>>> enforce and/or verify this are outside the scope of this >>>>> document. >>>> >>>> We will add this. >>>> >>>>> Note that there may be transient conditions when the EID-prefix >>>>> for the site and locator-set for each EID-prefix MAY not be the >>>>> same on all ETRs. >>>> >>>> We will add this first sentence but change "MAY not" to "may not" >>>> since it is not a rule in this specification that the >>>> implementation >>>> has an option of making the locator-set inconsistent. The locator- >>>> set >>>> is only inconsistent between the time it takes a network >>>> administrator >>>> to make it the same. If there is a configuration error and the >>>> inconsistent state is for a longer period of time, then the text >>>> below >>>> will cover that. >>>> >>>>> As a result, for the duration of these transient >>>>> conditions not all the ETRs would be able to send Map-Reply >>>>> messages with the same database mapping contents. >>>> >>>> We did not include this sentence above, because it is not true. The >>>> ETRs can still send Map-Replies with their idea of the locator-set. >>>> And an depending where an ITR's Map-Request is sent, will determine >>>> which locator-set the ITR caches. If the locators are disconnected >>>> from the network, RLOC-probing will tell you this and ITRs will not >>>> encapsulate to them. >>> >>> You agree that during transients the EID-prefix for the site >>> and locator-set for each EID-prefix may not be the same on all ETRs. >> >> Yes, I agree. >> >>> If that is the case, then how would all these ETRs during transients >>> be able to send Map-Reply messages with the same database mapping >>> contents ? >> >> No, they won't. > > So you agree that these ETRs during transients may not be able > to send Map-Reply messages with the same database mapping contents. > Yet when I proposed to document it with the following: > > As a result, for the duration of these transient > conditions not all the ETRs would be able to send Map-Reply > messages with the same database mapping contents. > > your argument against this was > > We did not include this sentence above, because it is not true. > > So, does the sentence I proposed true or not true ? I first read it as not being able to send Map-Replies at all. Now wondering why so much detail is necessary for a definition of EID-to- RLOC Database. Yakov, this really isn't critical, so can we put this to rest? Dino > > Yakov. > >> But this text we are beating to death is in a >> definition section of "EID-to-RLOC Database". >> >>>> If there is locator-set policy on the map-server, then maybe one >>>> locator-set or the other won't be accepted by the map-server. >>>> >>>> And if proxy-replying is sent in the map-register, then it is the >>>> map- >>>> server's idea of the locator-set that is sent consistently in all >>>> Map- >>> Replies. >>>> >>>> So we will say there are no negative implications. >>>> >>>>> Furthermore, if the authors think that sending inconsistent Map- >>>>> Reply >>>>> during transients has no negative implications, then add the >>>>> following at >>>>> the end of the text I suggested above: >>>>> >>>>> This has no negative implications. >>>>> >>>>> And if the authors think that sending inconsistent Map-Reply >>>>> during >>>>> transients does have negative implications, then the authors >>>>> should >>>>> list >>>>> them following the text I suggested above. >>>>> >>>>> Yakov. >>>> >>>> Here is the new proposed text: >>>> >>>> EID-to-RLOC Database: The EID-to-RLOC database is 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. In a steady >>>> state the EID-prefixes for the site and the locator-set for >>>> each >>>> EID-prefix MUST be the same on all ETRs. Procedures to >>>> enforce >>>> and/or verify this are outside the scope of this document. >>>> Note >>>> that there may be transient conditions when the EID-prefix for >>>> the >>>> site and locator-set for each EID-prefix may not be the same >>>> on >>>> all ETRs. This has no negative implications. >>> >>> Please add the following before the last sentence in the above: >>> >>> As a result, for the duration of these transient >>> conditions not all the ETRs may be able to send Map-Reply >>> messages with the same database mapping contents. >> >> I don't think it is necessary. >> >> Dino >> >>> >>> Yakov. >> From yakov@juniper.net Tue Mar 29 12:59:15 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E0828C0E0 for ; Tue, 29 Mar 2011 12:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.086 X-Spam-Level: X-Spam-Status: No, score=-106.086 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 rph-gfLRYGUP for ; Tue, 29 Mar 2011 12:59:14 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 42CAE3A6ABE for ; Tue, 29 Mar 2011 12:59:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTZI6cYF3Bj7pGeun5NNTHDmi/zC9HY0s@postini.com; Tue, 29 Mar 2011 13:00:53 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 12:57:25 -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 p2TJwsv44672; Tue, 29 Mar 2011 12:58:54 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103291958.p2TJwsv44672@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <1ECBB39B-709D-40AA-81F4-D9A949B8DC6C@cisco.com> References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> <066.61be0cfdf5abac76c31fca3228ab5011@trac.tools.ietf.org> <6C05CFEE-653D-44EA-946A-2C051D035E3A@cisco.com> <201103291945.p2TJj3v38570@magenta.juniper.net> <1ECBB39B-709D-40AA-81F4-D9A949B8DC6C@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Tue, 29 Mar 2011 12:46:40 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <4683.1301428734.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 12:58:54 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, lisp issue tracker Subject: Re: [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 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, 29 Mar 2011 19:59:15 -0000 Dino, > >> We mentioned this in the locator-reachability section. > > > > Could you please point me to the specific text in the locator-reachabi= lity > > section that talks about using the R bit. > = > The Locator Reachability Section indicates that even if a route is = > present it does not mean you can reach the RLOC. That was the point = > you wanted us to capture. R: set when the sender of a Map-Reply has a route to the locator in the locator data record. This receiver may find this useful to know when determining if the locator is reachable from the receiver. See also Section 6.4 for another way the R-bit may = The above text suggests that if the sender has a route to the locator (which is the first sentence in the above text), then the receiver, using the R bit, may use this when determining locator's reachability (which is the second sentence above). This contradicts the point you made above, namely that the presence of a route does *not* mean RLOC reachability. Yakov. > = > Dino > = > > > > Yakov. > > > >> I don't think > >> we need to repeat it again in a packet format field description area. > >> > >> Dino > >> > >> On Mar 29, 2011, at 12:29 PM, lisp issue tracker wrote: > >> > >>> #108: "R" bit in Map-Reply message format (comment 22 reported by Y. > >>> Rekhter) > >>> > >>> > >>> Comment(by yakov@=85): > >>> > >>> Here is the new text (from -11 version): > >>> > >>> R: set when the sender of a Map-Reply has a route to the locator in > >>> the locator data record. This receiver may find this useful to > >>> know when determining if the locator is reachable from the > >>> receiver. See also Section 6.4 for another way the R-bit may = > >>> be > >>> used. > >>> > >>> I'd like to propose the following replacement to the above: > >>> > >>> R: set when the sender of a Map-Reply has a route to the locator in > >>> the locator data record (note that since having the route, by > >>> itself, > >>> does not imply that the locator is up, having > >>> the R bit set does not imply that the locator is up). > >>> This receiver may find this useful to know when determining if > >>> the > >>> locator could be reachable from the receiver. > >>> See also Section 6.4 for another way the R-bit may be used. > >>> > >>> -- = > >>> ------------------------------- > >>> +-------------------------------------------- > >>> Reporter: wmhaddad@=85 | Owner: > >>> Type: technical | Status: new > >>> Priority: major | Component: draft-ietf-lisp > >>> Severity: - | Keywords: > >>> ------------------------------- > >>> +-------------------------------------------- > >>> > >>> Ticket URL: >>> 1> > >>> lisp > >>> LISP WG document issues > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > >> > >> > = > = From dino@cisco.com Tue Mar 29 13:01:09 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F233A6ABE for ; Tue, 29 Mar 2011 13:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.187 X-Spam-Level: X-Spam-Status: No, score=-10.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_72=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 kOuJnhcXSDh1 for ; Tue, 29 Mar 2011 13:01:07 -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 BE6153A6ABC for ; Tue, 29 Mar 2011 13:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=3323; q=dns/txt; s=iport; t=1301428966; x=1302638566; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=IcWNwHl3WDNZv8EgP3hNxhaaJrnv112cuIuM73aqZ44=; b=Yh3XHAO89XK6zImIchCX90KenW9mKVUY+wSFEfNFS/0H9qhXTNfesEFU G9wxU0vg7no4at/JncbLSKApxCRZoCG3jVUkgatxcXK0PAl7XYdCt98pk YZITu6z/3gcG6hk0M6bL2Ij6ntjiPw+E7DF+M12RYjmv1B7mpLhi3LEg1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ86kk2rRDoJ/2dsb2JhbAClT3eIeZ8BnHKFagSFPIdG X-IronPort-AV: E=Sophos;i="4.63,264,1299456000"; d="scan'208";a="420471262" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2011 20:02:46 +0000 Received: from dhcp-1789.meeting.ietf.org (sjc-vpn4-644.cisco.com [10.21.82.132]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2TK2ix7010681; Tue, 29 Mar 2011 20:02:45 GMT Message-Id: <083D92BE-CF88-4826-899E-C4DF59845AD2@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201103291958.p2TJwsv44672@magenta.juniper.net> 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: Tue, 29 Mar 2011 13:02:43 -0700 References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> <066.61be0cfdf5abac76c31fca3228ab5011@trac.tools.ietf.org> <6C05CFEE-653D-44EA-946A-2C051D035E3A@cisco.com> <201103291945.p2TJj3v38570@magenta.juniper.net> <1ECBB39B-709D-40AA-81F4-D9A949B8DC6C@cisco.com> <201103291958.p2TJwsv44672@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [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 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, 29 Mar 2011 20:01:09 -0000 These are hints as well. Dino On Mar 29, 2011, at 12:58 PM, Yakov Rekhter wrote: > Dino, > >>>> We mentioned this in the locator-reachability section. >>> >>> Could you please point me to the specific text in the locator-=20 >>> reachability >>> section that talks about using the R bit. >> >> The Locator Reachability Section indicates that even if a route is >> present it does not mean you can reach the RLOC. That was the point >> you wanted us to capture. > > R: set when the sender of a Map-Reply has a route to the locator in > the locator data record. This receiver may find this useful to > know when determining if the locator is reachable from the > receiver. See also Section 6.4 for another way the R-bit may > > The above text suggests that if the sender has a route to the locator > (which is the first sentence in the above text), then the receiver, > using the R bit, may use this when determining locator's reachability > (which is the second sentence above). This contradicts the point > you made above, namely that the presence of a route does *not* mean > RLOC reachability. > > Yakov. > >> >> Dino >> >>> >>> Yakov. >>> >>>> I don't think >>>> we need to repeat it again in a packet format field description =20 >>>> area. >>>> >>>> Dino >>>> >>>> On Mar 29, 2011, at 12:29 PM, lisp issue tracker wrote: >>>> >>>>> #108: "R" bit in Map-Reply message format (comment 22 reported =20 >>>>> by Y. >>>>> Rekhter) >>>>> >>>>> >>>>> Comment(by yakov@=85): >>>>> >>>>> Here is the new text (from -11 version): >>>>> >>>>> R: set when the sender of a Map-Reply has a route to the locator =20= >>>>> in >>>>> the locator data record. This receiver may find this useful =20= >>>>> to >>>>> know when determining if the locator is reachable from the >>>>> receiver. See also Section 6.4 for another way the R-bit may >>>>> be >>>>> used. >>>>> >>>>> I'd like to propose the following replacement to the above: >>>>> >>>>> R: set when the sender of a Map-Reply has a route to the locator =20= >>>>> in >>>>> the locator data record (note that since having the route, by >>>>> itself, >>>>> does not imply that the locator is up, having >>>>> the R bit set does not imply that the locator is up). >>>>> This receiver may find this useful to know when determining if >>>>> the >>>>> locator could be reachable from the receiver. >>>>> See also Section 6.4 for another way the R-bit may be used. >>>>> >>>>> --=20 >>>>> ------------------------------- >>>>> +-------------------------------------------- >>>>> Reporter: wmhaddad@=85 | Owner: >>>>> Type: technical | Status: new >>>>> Priority: major | Component: draft-ietf-lisp >>>>> Severity: - | Keywords: >>>>> ------------------------------- >>>>> +-------------------------------------------- >>>>> >>>>> Ticket URL: >>>> 108#comment: >>>>> 1> >>>>> lisp >>>>> LISP WG document issues >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> >> >> From yakov@juniper.net Tue Mar 29 13:03:51 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB4E28B797 for ; Tue, 29 Mar 2011 13:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.382 X-Spam-Level: X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 v0c800nWxJRT for ; Tue, 29 Mar 2011 13:03:50 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 1C8183A6AAD for ; Tue, 29 Mar 2011 13:03:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTZI7hvaZ8I/CRRPuwmmJkDmHb85FIU0a@postini.com; Tue, 29 Mar 2011 13:05:28 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 13:03:08 -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 p2TK4bv48136; Tue, 29 Mar 2011 13:04:37 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103292004.p2TK4bv48136@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <34C88890-CB2E-493A-897F-D7E1F97CE8F8@cisco.com> References: <201103281748.p2SHmmv14212@magenta.juniper.net> <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> <201103291320.p2TDKev34441@magenta.juniper.net> <624CEB8B-49C6-4C80-BC81-9DE1B3F6CEBF@cisco.com> <201103291952.p2TJqNv41849@magenta.juniper.net> <34C88890-CB2E-493A-897F-D7E1F97CE8F8@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Tue, 29 Mar 2011 12:56:00 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5049.1301429077.1@juniper.net> Date: Tue, 29 Mar 2011 13:04:37 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, lisp issue tracker Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 20:03:51 -0000 Dino, > >>>>> Deleting the last part of the last sentence is not enough. You also > >>>>> need to point out that the "MUST" applies only to steady state, and > >>>>> also document that during transients Map-Replies may not be > >>>>> consistent. > >>>>> > >>>>> With this in mind please replace the last sentence with the > >>>>> following: > >>>>> > >>>>> In a steady state the EID-prefixes for the site and the locator-set > >>>>> for each EID-prefix MUST be the same on all ETRs. Procedures to > >>>>> enforce and/or verify this are outside the scope of this > >>>>> document. > >>>> > >>>> We will add this. > >>>> > >>>>> Note that there may be transient conditions when the EID-prefix > >>>>> for the site and locator-set for each EID-prefix MAY not be the > >>>>> same on all ETRs. > >>>> > >>>> We will add this first sentence but change "MAY not" to "may not" > >>>> since it is not a rule in this specification that the > >>>> implementation > >>>> has an option of making the locator-set inconsistent. The locator- > >>>> set > >>>> is only inconsistent between the time it takes a network > >>>> administrator > >>>> to make it the same. If there is a configuration error and the > >>>> inconsistent state is for a longer period of time, then the text > >>>> below > >>>> will cover that. > >>>> > >>>>> As a result, for the duration of these transient > >>>>> conditions not all the ETRs would be able to send Map-Reply > >>>>> messages with the same database mapping contents. > >>>> > >>>> We did not include this sentence above, because it is not true. The > >>>> ETRs can still send Map-Replies with their idea of the locator-set. > >>>> And an depending where an ITR's Map-Request is sent, will determine > >>>> which locator-set the ITR caches. If the locators are disconnected > >>>> from the network, RLOC-probing will tell you this and ITRs will not > >>>> encapsulate to them. > >>> > >>> You agree that during transients the EID-prefix for the site > >>> and locator-set for each EID-prefix may not be the same on all ETRs. > >> > >> Yes, I agree. > >> > >>> If that is the case, then how would all these ETRs during transients > >>> be able to send Map-Reply messages with the same database mapping > >>> contents ? > >> > >> No, they won't. > > > > So you agree that these ETRs during transients may not be able > > to send Map-Reply messages with the same database mapping contents. > > Yet when I proposed to document it with the following: > > > > As a result, for the duration of these transient > > conditions not all the ETRs would be able to send Map-Reply > > messages with the same database mapping contents. > > > > your argument against this was > > > > We did not include this sentence above, because it is not true. > > > > So, does the sentence I proposed true or not true ? > > I first read it as not being able to send Map-Replies at all. Now > wondering why so much detail is necessary for a definition of EID-to- > RLOC Database. > > Yakov, this really isn't critical, so can we put this to rest? The spec needs to document that during transients not all the ETRs would be able to send Map-Reply messages with the same database mapping contents, and that this has no negative implications. I am fairly open wrt whether this is documented in the definition section, or in some other section of the draft. So, if you think there is a better place in the draft to document this, then please propose the place. Yakov. > > Dino > > > > > Yakov. > > > >> But this text we are beating to death is in a > >> definition section of "EID-to-RLOC Database". > >> > >>>> If there is locator-set policy on the map-server, then maybe one > >>>> locator-set or the other won't be accepted by the map-server. > >>>> > >>>> And if proxy-replying is sent in the map-register, then it is the > >>>> map- > >>>> server's idea of the locator-set that is sent consistently in all > >>>> Map- > >>> Replies. > >>>> > >>>> So we will say there are no negative implications. > >>>> > >>>>> Furthermore, if the authors think that sending inconsistent Map- > >>>>> Reply > >>>>> during transients has no negative implications, then add the > >>>>> following at > >>>>> the end of the text I suggested above: > >>>>> > >>>>> This has no negative implications. > >>>>> > >>>>> And if the authors think that sending inconsistent Map-Reply > >>>>> during > >>>>> transients does have negative implications, then the authors > >>>>> should > >>>>> list > >>>>> them following the text I suggested above. > >>>>> > >>>>> Yakov. > >>>> > >>>> Here is the new proposed text: > >>>> > >>>> EID-to-RLOC Database: The EID-to-RLOC database is 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. In a steady > >>>> state the EID-prefixes for the site and the locator-set for > >>>> each > >>>> EID-prefix MUST be the same on all ETRs. Procedures to > >>>> enforce > >>>> and/or verify this are outside the scope of this document. > >>>> Note > >>>> that there may be transient conditions when the EID-prefix for > >>>> the > >>>> site and locator-set for each EID-prefix may not be the same > >>>> on > >>>> all ETRs. This has no negative implications. > >>> > >>> Please add the following before the last sentence in the above: > >>> > >>> As a result, for the duration of these transient > >>> conditions not all the ETRs may be able to send Map-Reply > >>> messages with the same database mapping contents. > >> > >> I don't think it is necessary. > >> > >> Dino > >> > >>> > >>> Yakov. > >> > From yakov@juniper.net Tue Mar 29 13:07:43 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5C33A6ABC for ; Tue, 29 Mar 2011 13:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.091 X-Spam-Level: X-Spam-Status: No, score=-106.091 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 3GmmMrB6vECE for ; Tue, 29 Mar 2011 13:07:42 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 725F23A6AB5 for ; Tue, 29 Mar 2011 13:07:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTZI8bZ3gKJWEXA+SxEW9G2plf8IAp8jN@postini.com; Tue, 29 Mar 2011 13:09:21 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 13:05:08 -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 p2TK6bv49177; Tue, 29 Mar 2011 13:06:37 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103292006.p2TK6bv49177@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <083D92BE-CF88-4826-899E-C4DF59845AD2@cisco.com> References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> <066.61be0cfdf5abac76c31fca3228ab5011@trac.tools.ietf.org> <6C05CFEE-653D-44EA-946A-2C051D035E3A@cisco.com> <201103291945.p2TJj3v38570@magenta.juniper.net> <1ECBB39B-709D-40AA-81F4-D9A949B8DC6C@cisco.com> <201103291958.p2TJwsv44672@magenta.juniper.net> <083D92BE-CF88-4826-899E-C4DF59845AD2@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Tue, 29 Mar 2011 13:02:43 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <5239.1301429197.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 13:06:37 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, lisp issue tracker Subject: Re: [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 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, 29 Mar 2011 20:07:43 -0000 Dino, > These are hints as well. That is precisely what is captured in the text I proposed. Yakov. > = > Dino > = > On Mar 29, 2011, at 12:58 PM, Yakov Rekhter wrote: > = > > Dino, > > > >>>> We mentioned this in the locator-reachability section. > >>> > >>> Could you please point me to the specific text in the locator- = > >>> reachability > >>> section that talks about using the R bit. > >> > >> The Locator Reachability Section indicates that even if a route is > >> present it does not mean you can reach the RLOC. That was the point > >> you wanted us to capture. > > > > R: set when the sender of a Map-Reply has a route to the locator in > > the locator data record. This receiver may find this useful to > > know when determining if the locator is reachable from the > > receiver. See also Section 6.4 for another way the R-bit may > > > > The above text suggests that if the sender has a route to the locator > > (which is the first sentence in the above text), then the receiver, > > using the R bit, may use this when determining locator's reachability > > (which is the second sentence above). This contradicts the point > > you made above, namely that the presence of a route does *not* mean > > RLOC reachability. > > > > Yakov. > > > >> > >> Dino > >> > >>> > >>> Yakov. > >>> > >>>> I don't think > >>>> we need to repeat it again in a packet format field description = > >>>> area. > >>>> > >>>> Dino > >>>> > >>>> On Mar 29, 2011, at 12:29 PM, lisp issue tracker wrote: > >>>> > >>>>> #108: "R" bit in Map-Reply message format (comment 22 reported = > >>>>> by Y. > >>>>> Rekhter) > >>>>> > >>>>> > >>>>> Comment(by yakov@=85): > >>>>> > >>>>> Here is the new text (from -11 version): > >>>>> > >>>>> R: set when the sender of a Map-Reply has a route to the locator = > >>>>> in > >>>>> the locator data record. This receiver may find this useful = > >>>>> to > >>>>> know when determining if the locator is reachable from the > >>>>> receiver. See also Section 6.4 for another way the R-bit may > >>>>> be > >>>>> used. > >>>>> > >>>>> I'd like to propose the following replacement to the above: > >>>>> > >>>>> R: set when the sender of a Map-Reply has a route to the locator = > >>>>> in > >>>>> the locator data record (note that since having the route, by > >>>>> itself, > >>>>> does not imply that the locator is up, having > >>>>> the R bit set does not imply that the locator is up). > >>>>> This receiver may find this useful to know when determining if > >>>>> the > >>>>> locator could be reachable from the receiver. > >>>>> See also Section 6.4 for another way the R-bit may be used. > >>>>> > >>>>> -- = > >>>>> ------------------------------- > >>>>> +-------------------------------------------- > >>>>> Reporter: wmhaddad@=85 | Owner: > >>>>> Type: technical | Status: new > >>>>> Priority: major | Component: draft-ietf-lisp > >>>>> Severity: - | Keywords: > >>>>> ------------------------------- > >>>>> +-------------------------------------------- > >>>>> > >>>>> Ticket URL: >>>>> 108#comment: > >>>>> 1> > >>>>> lisp > >>>>> LISP WG document issues > >>>>> _______________________________________________ > >>>>> lisp mailing list > >>>>> lisp@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/lisp > >>>> > >>>> > >> > >> > = > = From yakov@juniper.net Tue Mar 29 13:21:04 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14CB3A6AB6 for ; Tue, 29 Mar 2011 13:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.387 X-Spam-Level: X-Spam-Status: No, score=-106.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3G2x3CO2wo7U for ; Tue, 29 Mar 2011 13:21:03 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id B6CF728B797 for ; Tue, 29 Mar 2011 13:20:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTZI/e6pzoGdiEGdWJ/Y795squYmDuxtE@postini.com; Tue, 29 Mar 2011 13:22:41 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 13:19:02 -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 p2TKKWv55902; Tue, 29 Mar 2011 13:20:32 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103292020.p2TKKWv55902@magenta.juniper.net> To: Dino Farinacci In-Reply-To: References: <201103281748.p2SHmmv14212@magenta.juniper.net> <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> <201103291320.p2TDKev34441@magenta.juniper.net> <624CEB8B-49C6-4C80-BC81-9DE1B3F6CEBF@cisco.com> <201103291952.p2TJqNv41849@magenta.juniper.net> <34C88890-CB2E-493A-897F-D7E1F97CE8F8@cisco.com> <201103292004.p2TK4bv48136@magenta.juniper.net> X-MH-In-Reply-To: Dino Farinacci message dated "Tue, 29 Mar 2011 13:09:18 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5998.1301430032.1@juniper.net> Date: Tue, 29 Mar 2011 13:20:32 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, David Meyer Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 20:21:04 -0000 Dino, > Copying the chairs and co-authors. adding back the LISP WG mailing list... > On Mar 29, 2011, at 1:04 PM, Yakov Rekhter wrote: > > > Dino, > > > >>>>>>> Deleting the last part of the last sentence is not enough. You > >>>>>>> also > >>>>>>> need to point out that the "MUST" applies only to steady > >>>>>>> state, and > >>>>>>> also document that during transients Map-Replies may not be > >>>>>>> consistent. > >>>>>>> > >>>>>>> With this in mind please replace the last sentence with the > >>>>>>> following: > >>>>>>> > >>>>>>> In a steady state the EID-prefixes for the site and the > >>>>>>> locator-set > >>>>>>> for each EID-prefix MUST be the same on all ETRs. Procedures to > >>>>>>> enforce and/or verify this are outside the scope of this > >>>>>>> document. > >>>>>> > >>>>>> We will add this. > >>>>>> > >>>>>>> Note that there may be transient conditions when the EID-prefix > >>>>>>> for the site and locator-set for each EID-prefix MAY not be the > >>>>>>> same on all ETRs. > >>>>>> > >>>>>> We will add this first sentence but change "MAY not" to "may not" > >>>>>> since it is not a rule in this specification that the > >>>>>> implementation > >>>>>> has an option of making the locator-set inconsistent. The > >>>>>> locator- > >>>>>> set > >>>>>> is only inconsistent between the time it takes a network > >>>>>> administrator > >>>>>> to make it the same. If there is a configuration error and the > >>>>>> inconsistent state is for a longer period of time, then the text > >>>>>> below > >>>>>> will cover that. > >>>>>> > >>>>>>> As a result, for the duration of these transient > >>>>>>> conditions not all the ETRs would be able to send Map-Reply > >>>>>>> messages with the same database mapping contents. > >>>>>> > >>>>>> We did not include this sentence above, because it is not true. > >>>>>> The > >>>>>> ETRs can still send Map-Replies with their idea of the locator- > >>>>>> set. > >>>>>> And an depending where an ITR's Map-Request is sent, will > >>>>>> determine > >>>>>> which locator-set the ITR caches. If the locators are > >>>>>> disconnected > >>>>>> from the network, RLOC-probing will tell you this and ITRs will > >>>>>> not > >>>>>> encapsulate to them. > >>>>> > >>>>> You agree that during transients the EID-prefix for the site > >>>>> and locator-set for each EID-prefix may not be the same on all > >>>>> ETRs. > >>>> > >>>> Yes, I agree. > >>>> > >>>>> If that is the case, then how would all these ETRs during > >>>>> transients > >>>>> be able to send Map-Reply messages with the same database mapping > >>>>> contents ? > >>>> > >>>> No, they won't. > >>> > >>> So you agree that these ETRs during transients may not be able > >>> to send Map-Reply messages with the same database mapping contents. > >>> Yet when I proposed to document it with the following: > >>> > >>> As a result, for the duration of these transient > >>> conditions not all the ETRs would be able to send Map-Reply > >>> messages with the same database mapping contents. > >>> > >>> your argument against this was > >>> > >>> We did not include this sentence above, because it is not true. > >>> > >>> So, does the sentence I proposed true or not true ? > >> > >> I first read it as not being able to send Map-Replies at all. Now > >> wondering why so much detail is necessary for a definition of EID-to- > >> RLOC Database. > >> > >> Yakov, this really isn't critical, so can we put this to rest? > > > > The spec needs to document that during transients not all the ETRs > > would be able to send Map-Reply messages with the same database > > mapping contents, and that this has no negative implications. > > No it doesn't. You are nit-picking. What do you mean by "No it doesn't" ? > > I am fairly open wrt whether this is documented in the definition > > section, or in some other section of the draft. So, if you think > > there is a better place in the draft to document this, then please > > propose the place. > > It is a misconfiguration. We already stated that the locator-sets may > not be the same. If we document all possible misconfigurations, (1) we > would miss all of the, and (2) the document would become unreadable. Misconfiguration is one possible reason, but not the only one possible - transients is another possible reason. And all I am asking is to document that transients is another possible reason. Yakov. > The best place is to keep it out. We gave you some text, you should > meet us half way. > > Dino > > > > > Yakov. > > > >> > >> Dino > >> > >>> > >>> Yakov. > >>> > >>>> But this text we are beating to death is in a > >>>> definition section of "EID-to-RLOC Database". > >>>> > >>>>>> If there is locator-set policy on the map-server, then maybe one > >>>>>> locator-set or the other won't be accepted by the map-server. > >>>>>> > >>>>>> And if proxy-replying is sent in the map-register, then it is the > >>>>>> map- > >>>>>> server's idea of the locator-set that is sent consistently in all > >>>>>> Map- > >>>>> Replies. > >>>>>> > >>>>>> So we will say there are no negative implications. > >>>>>> > >>>>>>> Furthermore, if the authors think that sending inconsistent Map- > >>>>>>> Reply > >>>>>>> during transients has no negative implications, then add the > >>>>>>> following at > >>>>>>> the end of the text I suggested above: > >>>>>>> > >>>>>>> This has no negative implications. > >>>>>>> > >>>>>>> And if the authors think that sending inconsistent Map-Reply > >>>>>>> during > >>>>>>> transients does have negative implications, then the authors > >>>>>>> should > >>>>>>> list > >>>>>>> them following the text I suggested above. > >>>>>>> > >>>>>>> Yakov. > >>>>>> > >>>>>> Here is the new proposed text: > >>>>>> > >>>>>> EID-to-RLOC Database: The EID-to-RLOC database is 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. In a steady > >>>>>> state the EID-prefixes for the site and the locator-set for > >>>>>> each > >>>>>> EID-prefix MUST be the same on all ETRs. Procedures to > >>>>>> enforce > >>>>>> and/or verify this are outside the scope of this document. > >>>>>> Note > >>>>>> that there may be transient conditions when the EID-prefix > >>>>>> for > >>>>>> the > >>>>>> site and locator-set for each EID-prefix may not be the same > >>>>>> on > >>>>>> all ETRs. This has no negative implications. > >>>>> > >>>>> Please add the following before the last sentence in the above: > >>>>> > >>>>> As a result, for the duration of these transient > >>>>> conditions not all the ETRs may be able to send Map-Reply > >>>>> messages with the same database mapping contents. > >>>> > >>>> I don't think it is necessary. > >>>> > >>>> Dino > >>>> > >>>>> > >>>>> Yakov. > >>>> > >> > From dino@cisco.com Tue Mar 29 13:22:50 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661EA3A6AB9 for ; Tue, 29 Mar 2011 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 AHtfN+LPhRaB for ; Tue, 29 Mar 2011 13:22:49 -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 78A1E3A6AB6 for ; Tue, 29 Mar 2011 13:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=270; q=dns/txt; s=iport; t=1301430268; x=1302639868; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=7EQZjDXGtgCk016UdES1SQH1GHShJo/CH4FurqPTFJU=; b=d5gydiTT+wSAQQrVzb88LeuXGAoWOtMjmhpA3qpmdhfp55Fm2OauMvZ4 y+S4zyEcVHgVQrjPNHyoW+/FDdmY7CV4G9vKd3rYCdolBK1DjD+WbfHfX ltJQqsZ5f9+R3wS1/o3gxIYW6adm9i0bNnwL4uPg7fdO7bW9mCydm5UOM E=; X-IronPort-AV: E=Sophos;i="4.63,264,1299456000"; d="scan'208";a="420489060" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2011 20:24:28 +0000 Received: from dhcp-1789.meeting.ietf.org (sjc-vpn4-644.cisco.com [10.21.82.132]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2TKOPEu008052; Tue, 29 Mar 2011 20:24:26 GMT Message-Id: From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201103292020.p2TKKWv55902@magenta.juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 29 Mar 2011 13:24:24 -0700 References: <201103281748.p2SHmmv14212@magenta.juniper.net> <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> <201103291320.p2TDKev34441@magenta.juniper.net> <624CEB8B-49C6-4C80-BC81-9DE1B3F6CEBF@cisco.com> <201103291952.p2TJqNv41849@magenta.juniper.net> <34C88890-CB2E-493A-897F-D7E1F97CE8F8@cisco.com> <201103292004.p2TK4bv48136@magenta.juniper.net> <201103292020.p2TKKWv55902@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org, David Meyer Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 20:22:50 -0000 > Misconfiguration is one possible reason, but not the only one > possible - transients is another possible reason. And all I am > asking is to document that transients is another possible reason. What is your definition of transients? Be specific please. Dino From yakov@juniper.net Tue Mar 29 13:31:36 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C5128C0E0 for ; Tue, 29 Mar 2011 13:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.395 X-Spam-Level: X-Spam-Status: No, score=-106.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 L7uCSkm7ZdTt for ; Tue, 29 Mar 2011 13:31:35 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id E2A293A6AB5 for ; Tue, 29 Mar 2011 13:30:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTZJB5JpSeT1/+yo6uhxVEIclaLb9y5rq@postini.com; Tue, 29 Mar 2011 13:33:14 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 13:29:33 -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 p2TKV2v61080; Tue, 29 Mar 2011 13:31:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103292031.p2TKV2v61080@magenta.juniper.net> To: Dino Farinacci In-Reply-To: References: <201103281748.p2SHmmv14212@magenta.juniper.net> <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> <201103291320.p2TDKev34441@magenta.juniper.net> <624CEB8B-49C6-4C80-BC81-9DE1B3F6CEBF@cisco.com> <201103291952.p2TJqNv41849@magenta.juniper.net> <34C88890-CB2E-493A-897F-D7E1F97CE8F8@cisco.com> <201103292004.p2TK4bv48136@magenta.juniper.net> <201103292020.p2TKKWv55902@magenta.juniper.net> X-MH-In-Reply-To: Dino Farinacci message dated "Tue, 29 Mar 2011 13:24:24 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6529.1301430662.1@juniper.net> Date: Tue, 29 Mar 2011 13:31:02 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, David Meyer Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 20:31:36 -0000 Dino, > > Misconfiguration is one possible reason, but not the only one > > possible - transients is another possible reason. And all I am > > asking is to document that transients is another possible reason. > > What is your definition of transients? Be specific please. The same as in the following from -11 version: Note that there may be transient conditions when the EID-prefix for the site and locator-set for each EID-prefix may not be the same on all ETRs. Yakov. From dino@cisco.com Tue Mar 29 13:36:57 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7747A28B797 for ; Tue, 29 Mar 2011 13:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 3BLGQkSUXBNP for ; Tue, 29 Mar 2011 13:36:56 -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 9E5353A6A88 for ; Tue, 29 Mar 2011 13:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=829; q=dns/txt; s=iport; t=1301431115; x=1302640715; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=eN0lUPnGwg8AIVbvfWpDBe/SZROCAknUda5p0bH5vKg=; b=HIzUHKgfJBcxnHrt1ku3OV7arPBpBtkh+I5FGchHCuYikptqrPX3zHqr 9p+EA11rj7Iba1sKqdJuAUDLG261L/2xE7VQRCrifbvU0eEbUFti0Tp6w JtyCt0F4j8cu5k0WD44slE5w//IUXCx9Pfr/IFPSaDiEdWb+0CRLuOaEM k=; X-IronPort-AV: E=Sophos;i="4.63,264,1299456000"; d="scan'208";a="326967480" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2011 20:38:35 +0000 Received: from dhcp-1789.meeting.ietf.org (sjc-vpn4-644.cisco.com [10.21.82.132]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2TKcWUU018569; Tue, 29 Mar 2011 20:38:33 GMT Message-Id: <1C0ACDD9-D53D-474B-BD43-3F18C9B9F9A5@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201103292031.p2TKV2v61080@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, 29 Mar 2011 13:38:31 -0700 References: <201103281748.p2SHmmv14212@magenta.juniper.net> <3411E70A-63D2-4249-B464-927D010EE032@cisco.com> <201103291320.p2TDKev34441@magenta.juniper.net> <624CEB8B-49C6-4C80-BC81-9DE1B3F6CEBF@cisco.com> <201103291952.p2TJqNv41849@magenta.juniper.net> <34C88890-CB2E-493A-897F-D7E1F97CE8F8@cisco.com> <201103292004.p2TK4bv48136@magenta.juniper.net> <201103292020.p2TKKWv55902@magenta.juniper.net> <201103292031.p2TKV2v61080@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org, David Meyer Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients 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, 29 Mar 2011 20:36:57 -0000 The RLOCs are not the same in all ETRs *because of the transient conditions*. You have to define what the transient condition is that causes this inconsistency. Dino On Mar 29, 2011, at 1:31 PM, Yakov Rekhter wrote: > Dino, > >>> Misconfiguration is one possible reason, but not the only one >>> possible - transients is another possible reason. And all I am >>> asking is to document that transients is another possible reason. >> >> What is your definition of transients? Be specific please. > > The same as in the following from -11 version: > > Note > that there may be transient conditions when the EID-prefix for > the > site and locator-set for each EID-prefix may not be the same on > all ETRs. > > Yakov. From lear@cisco.com Tue Mar 29 13:50:28 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46F53A6A2E for ; Tue, 29 Mar 2011 13:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 op8UpFHXHbMB for ; Tue, 29 Mar 2011 13:50:27 -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 7D4B83A6981 for ; Tue, 29 Mar 2011 13:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1806; q=dns/txt; s=iport; t=1301431926; x=1302641526; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6oJ+Vc641cCISn9uZhesKCLAkPx77v7S+pxpSSWOdDE=; b=j2oet48GsN/X+Uozc9p9TbmvPKANajTSvr4gCRnK1Xgs/qzvatpSbQkK abZLtqc/vT7Kas/tShLderorRXz/hQ8ubd4SI+BAK1UQSGNWOANaCke0e cA7DjDZOqjV2p87dnY4d7GWHOUUsKpEw4P3C8OcZyYJpJVXntmFKLdyq6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsEABlGkk2Q/khMgWdsb2JhbACER6EIFAEBFiYliHmeaIs9kSuBJ4NMdwSNAg X-IronPort-AV: E=Sophos;i="4.63,264,1299456000"; d="scan'208";a="23689880" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2011 20:52:05 +0000 Received: from ams3-vpn-dhcp1987.cisco.com (ams3-vpn-dhcp1987.cisco.com [10.61.71.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2TKq4Jp029807; Tue, 29 Mar 2011 20:52:05 GMT Message-ID: <4D92464E.1060101@cisco.com> Date: Tue, 29 Mar 2011 22:51:26 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yakov Rekhter References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> <066.78965594e2a0942ac8660a75b80688ef@trac.tools.ietf.org> <201103291714.p2THEIv41513@magenta.juniper.net> In-Reply-To: <201103291714.p2THEIv41513@magenta.juniper.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review 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: Tue, 29 Mar 2011 20:50:28 -0000 Hi Yakov, > Here is the text that has been added: > > Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, > cache sizing and maintenance is an issue to be kept in mind during > implementation. It is a good idea to have instrumentation in place > to detect thrashing of the cache. Implementation experimentation > will be used to determine which cache management strategies work > best. > > The above text failed to mention that cache sizing is an issue not > just "during implementation", but during deployment as well. I agree with this point. I believe actually the change for the above text is to change "Implementation experimentation" simply to "Experimentation" or "Deployment experience". > Moreover, the above text failed to mention that in the context of > LISP, thrashing of the cache on a given ITR/PTR has non-local > implications, as it could result in excessive volume of LISP control > traffic, which in turn would further deteriorate the situation. I agree with this concern. The degenerative case one could imagine is a cache of 1 entry, in which case packets to every separate site would generate queries, presumably through the ALT. However... > Finally, the above failed to mention that being able to > detect thrasing is necessary, but not sufficient - an implementation > must be able to suppress thrasing. I agree with this point. However, I would suggest a different set of text: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, and that undersized caches could cause excessive control traffic, implementations MUST have some form of cache management in place. The specific management mechanisms are beyond the scope of this specification. Regards, Eliot From chopra.huawei@gmail.com Tue Mar 29 12:24:48 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B183A6A94 for ; Tue, 29 Mar 2011 12:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkJNMnCB9uEj for ; Tue, 29 Mar 2011 12:24:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id DECD83A6A2E for ; Tue, 29 Mar 2011 12:24:46 -0700 (PDT) Received: by eye13 with SMTP id 13so190239eye.31 for ; Tue, 29 Mar 2011 12:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=FptolnkeGQ/vC+kVZvOLwGT93pQEkevU4dg0S0zKeZ4=; b=QR6cGykOfKG/DcSxVc4T/Cp0dXlKuvmAZNkOP1BU21Ft4h9NZd6AIvJTko6S+3IZki G7csxpouZz3TgrDuIjGtEl84w3DVWJFya8goyuM77y4YABhrb1+FHsI6wfOmOgnHYB1L +RW8Lpo9v311x1Q8hun13t9Hoa8Ni1AMFYLIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bxzqxlVuNDMj8xlvIQdWK0/GwCvjJG5+7mu1DvGbAhRNlrwVLnDHghRukdQxTLu9jb Jd+T7j4dbjVoG5uxqrxpFN+nybuehDGlhtnTZ/qJKXP91H5NhrmqN9MKjKm2V6HwBNcv WLgBfUIDgHdGEwGBTkaXArT989cwPlkmEMSQA= MIME-Version: 1.0 Received: by 10.14.120.137 with SMTP id p9mr142965eeh.219.1301426783956; Tue, 29 Mar 2011 12:26:23 -0700 (PDT) Received: by 10.14.37.10 with HTTP; Tue, 29 Mar 2011 12:26:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2011 12:26:23 -0700 Message-ID: From: Aditya Chopra To: lisp@ietf.org Content-Type: multipart/alternative; boundary=e0cb4e43ccb928af5a049fa4098e Subject: Re: [lisp] Subject: Re: #46: Cache Thrashing (review 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: Tue, 29 Mar 2011 20:55:03 -0000 --e0cb4e43ccb928af5a049fa4098e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable People rise to their level of incompetence - way to go Yakov "Peter Principle" Rekhter!! Love the Cisco-Juniper war, somebody else can then steal the pie. ------ Forwarded Message From: Yakov Rekhter Date: Tue, 29 Mar 2011 10:14:18 -0700 To: , , < wmhaddad@gmail.com>, , Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter) Hi, > #46: Cache Thrashing (review by Y. Rekhter) > > Changes (by jmh@=E2=95=9C): > > * status: reopened =3D> resolved > * resolution: =3D> fixed > > > Comment: > > Text has been added to the -11 revision of teh specification noting that > cache thrashing happens, that implementors should think about it, and that > the experiment may tell us more about whether this is an issue needing > further attention. Here is the text that has been added: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. The above text failed to mention that cache sizing is an issue not just "during implementation", but during deployment as well. Moreover, the above text failed to mention that in the context of LISP, thrashing of the cache on a given ITR/PTR has non-local implications, as it could result in excessive volume of LISP control traffic, which in turn would further deteriorate the situation. Finally, the above failed to mention that being able to detect thrasing is necessary, but not sufficient - an implementation must be able to suppress thrasing. With all this in mind I would like to propose replacing the text quoted above with the following: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue to be kept in mind during both implementation and deployment. In the context of LISP, cache thrasing on the ITR/PTR could result in the ITR/PTR dropping data, thus negatively affecting connectivity. Moreover, it could also result in excessive volume of LISP control traffic, which could spread the detrimental effects of thrasing beyond the ITR/PTR and all the hosts that communicate through this ITR/PTR. Therefore, an implementation MUST provide instrumentation in place to detect thrashing of the cache, and MUST provide mechanism(s) to suppress thrasing. Specifications of such mechanisms are outside the scope of this document. Implementation experimentation will be used to determine which cache management strategies work best. Yakov. > > -- > -------------------------------+-------------------------------------------= - > Reporter: wmhaddad@=E2=95=9C | Owner: > Type: technical | Status: resolved > Priority: major | Component: draft-ietf-lisp > Severity: - | Resolution: fixed > Keywords: | > -------------------------------+-------------------------------------------= - > > Ticket URL: > lisp > LISP WG document issues _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ------ End of Forwarded Message --e0cb4e43ccb928af5a049fa4098e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable People rise to their level of incompetence - way to go Yakov "Peter Pr= inciple" Rekhter!! Love the Cisco-Juniper war, somebody else can then = steal the pie.

------ Forwarded Message From: Yakov Rekhter <yakov@juniper.net>
Date: Tue, 29 Mar 2011 10:14:18 -0700
To: <jmh@joelhalpern.com>, <luigi@net.t-labs.tu= -berlin.de>, <wmhaddad@gmail.com>, <yakov@juniper.net>, <lisp@ietf.org>
Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter)

Hi,<= br>
> #46: Cache Thrashing (review by Y. Rekhter)
>
> Ch= anges (by jmh@=E2=95=9C):
>
>=A0=A0 * status:=A0 reopened =3D&= gt; resolved
>=A0=A0 * resolution:=A0 =3D> fixed
>
>
> Comment= :
>
>=A0 Text has been added to the -11 revision of teh specif= ication noting that
>=A0 cache thrashing happens, that implementors s= hould think about it, and that
>=A0 the experiment may tell us more about whether this is an issue need= ing
>=A0 further attention.

Here is the text that has been add= ed:

=A0=A0 Given that the ITR/PTR maintains a cache of EID-to-RLOC m= appings,
=A0=A0 cache sizing and maintenance is an issue to be kept in mind during=A0=A0 implementation.=A0 It is a good idea to have instrumentation in pl= ace=A0
=A0=A0 to detect thrashing of the cache.=A0 Implementation exper= imentation=A0
=A0=A0 will be used to determine which cache management strategies work
= =A0=A0 best.

The above text failed to mention that cache sizing is a= n issue not
just "during implementation", but during deploymen= t as well.

Moreover, the above text failed to mention that in the context of
LI= SP, thrashing of the cache on a given ITR/PTR has non-local
implications= , as it could result in excessive volume of LISP control
traffic, which = in turn would further deteriorate the situation.

Finally, the above failed to mention that being able to
detect thras= ing is necessary, but not sufficient - an implementation
must be able to= suppress thrasing.

With all this in mind I would like to propose re= placing the text
quoted above with the following:

=A0=A0 Given that the ITR/PTR maint= ains a cache of EID-to-RLOC mappings,
=A0=A0 cache sizing and maintenanc= e is an issue to be kept in mind
=A0=A0 during both implementation and d= eployment. In the context of
=A0=A0 LISP, cache thrasing on the ITR/PTR could result in the ITR/PTR
= =A0=A0 dropping data, thus negatively affecting connectivity. Moreover,
= =A0=A0 it could also result in excessive volume of LISP control traffic,=A0=A0 which could spread the detrimental effects of thrasing beyond
=A0=A0 the ITR/PTR and all the hosts that communicate through this
=A0= =A0 ITR/PTR. Therefore, an implementation MUST provide instrumentation
= =A0=A0 in place to detect thrashing of the cache, and MUST provide
=A0= =A0 mechanism(s) to suppress thrasing.=A0 Specifications of such
=A0=A0 mechanisms are outside the scope of this document.=A0 Implementation=
=A0=A0 experimentation will be used to determine which cache management=
=A0=A0 strategies work best.

Yakov.

>
> --
= > -------------------------------+--------------------------------------= ------
> Reporter:=A0 wmhaddad@=E2=95=9C=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= =A0=A0=A0=A0 Owner:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
>= ;=A0=A0=A0=A0 Type:=A0 technical=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= =A0=A0=A0 Status:=A0 resolved=A0=A0=A0=A0=A0=A0
> Priority:=A0 major= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 Component:=A0 draft-i= etf-lisp
> Severity:=A0 -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0 Resolution:=A0 fixed=A0=A0=A0=A0=A0=A0=A0=A0=A0
> Keywords:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0
> -------------------------------+-------------------------= -------------------
>
> Ticket URL: <https:= //wiki.tools.ietf.org/wg/lisp/trac/ticket/46#comment:6>
> lisp <htt= p://tools.ietf.org/lisp/>
> LISP WG document issues
_______= ________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

------ End of Forwarded= Message

--e0cb4e43ccb928af5a049fa4098e-- From Internet-Drafts@ietf.org Tue Mar 29 14:15:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F9428C0EC; Tue, 29 Mar 2011 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, 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 jDCnSGSWfg7s; Tue, 29 Mar 2011 14:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C25028C0EE; Tue, 29 Mar 2011 14:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110329211502.31015.16441.idtracker@localhost> Date: Tue, 29 Mar 2011 14:15:02 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 21:15: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 : Locator/ID Separation Protocol (LISP) Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-11.txt Pages : 85 Date : 2011-03-29 This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-11.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-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29141400.I-D@ietf.org> --NextPart-- From jnc@mercury.lcs.mit.edu Tue Mar 29 14:32:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1101C3A6AC5 for ; Tue, 29 Mar 2011 14:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 NzcfT9Js0LjY for ; Tue, 29 Mar 2011 14:32:11 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 2DAD13A6A93 for ; Tue, 29 Mar 2011 14:32:11 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 08B7218C0DF; Tue, 29 Mar 2011 17:33:49 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110329213349.08B7218C0DF@mercury.lcs.mit.edu> Date: Tue, 29 Mar 2011 17:33:49 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #46: Cache Thrashing (review 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: Tue, 29 Mar 2011 21:32:12 -0000 > From: Yakov Rekhter > being able to detect thrasing is necessary, but not sufficient - an > implementation must be able to suppress thrasing. I'm interested in the engineering aspects of this, not just what to say in this particular document. The only way I've ever heard of to really 'fix' (AKA prevent) cache thrashing problems (going all the way back to the days of page replacement algorithms on big time-sharing machines, back when machines had relatively small main memories) is to either i) change the access pattern (perhaps by reducing offered load), or ii) increase the size of the cache. (Yes, yes, I know that in very limited-size caches, and to make the cache hardware 'relatively' simple, you get things like N-way associative caches. I don't think those apply here, because our caches will of necessity be much larger - since the cost of a miss is so large, we have to minimize miss count - and implemented very differently.) Since i) isn't really feasible for us , and ii) is 'relatively' easy now that memory is so cheap, is there any reason not to say something to the effect of 'we recommend that to prevent any possibility of cache thrashing, the ITR MUST be able to cache all the mappings it receives, only discarding mappings which have not been used in a considerable time (e.g. 1 hour)'. (Also, I think there is some data from one of the simulations done by the guys in Europe which shows how large caches have to be - or had to be at the time the simulations were done - to provide low levels of cache miss for previously seen destinations. I seem to recall that there was enough info there to work out how long you had to be able to hold mappings in the cache to keep refill overhead, etc, down to a reasonable level. Perhaps we should refer to that for setting the recommended hold time, above?) Noel From jmh@joelhalpern.com Tue Mar 29 14:42:41 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7EA3A6ACB for ; Tue, 29 Mar 2011 14:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 wwZgjfJmnyHz for ; Tue, 29 Mar 2011 14:42:40 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 46C2B3A6ACA for ; Tue, 29 Mar 2011 14:42:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DA3544300E1; Tue, 29 Mar 2011 14:44:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [130.129.69.15] (dhcp-450f.meeting.ietf.org [130.129.69.15]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 41E1D439FC8; Tue, 29 Mar 2011 14:44:17 -0700 (PDT) Message-ID: <4D9252AD.8020905@joelhalpern.com> Date: Tue, 29 Mar 2011 17:44:13 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Noel Chiappa References: <20110329213349.08B7218C0DF@mercury.lcs.mit.edu> In-Reply-To: <20110329213349.08B7218C0DF@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] #46: Cache Thrashing (review 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: Tue, 29 Mar 2011 21:42:41 -0000 While I like the theory you advance, I don't know how to build it in practice. What size memory, short of the full LISP table, should I build in my device to meet the MUST? Whatever size I build, someone can easily build a test case for which it fails. Personally, I am actually curious to see, in an enterprise edge deployment, how well this works. I presume there is already some data. The experiment will tell us more. I wonder about the interaction of caching with all sorts of other cases, but I do not see that the document needs to spell out all of the history of our problems, or the difficulties in addressing this, in order to conduct the experiment. Yours, Joel On 3/29/2011 5:33 PM, Noel Chiappa wrote: > > From: Yakov Rekhter > > > being able to detect thrasing is necessary, but not sufficient - an > > implementation must be able to suppress thrasing. > > I'm interested in the engineering aspects of this, not just what to say in > this particular document. > > The only way I've ever heard of to really 'fix' (AKA prevent) cache thrashing > problems (going all the way back to the days of page replacement algorithms on > big time-sharing machines, back when machines had relatively small main > memories) is to either i) change the access pattern (perhaps by reducing > offered load), or ii) increase the size of the cache. > > (Yes, yes, I know that in very limited-size caches, and to make the cache > hardware 'relatively' simple, you get things like N-way associative caches. I > don't think those apply here, because our caches will of necessity be much > larger - since the cost of a miss is so large, we have to minimize miss count > - and implemented very differently.) > > Since i) isn't really feasible for us , and ii) is 'relatively' easy now that > memory is so cheap, is there any reason not to say something to the effect of > 'we recommend that to prevent any possibility of cache thrashing, the ITR > MUST be able to cache all the mappings it receives, only discarding mappings > which have not been used in a considerable time (e.g. 1 hour)'. > > (Also, I think there is some data from one of the simulations done by the > guys in Europe which shows how large caches have to be - or had to be at the > time the simulations were done - to provide low levels of cache miss for > previously seen destinations. I seem to recall that there was enough info > there to work out how long you had to be able to hold mappings in the cache > to keep refill overhead, etc, down to a reasonable level. Perhaps we should > refer to that for setting the recommended hold time, above?) > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Tue Mar 29 14:44:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE513A6ACB for ; Tue, 29 Mar 2011 14:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.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 EpqOkSMZIlxV for ; Tue, 29 Mar 2011 14:44:31 -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 651903A6ACA for ; Tue, 29 Mar 2011 14:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=3305; q=dns/txt; s=iport; t=1301435170; x=1302644770; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=pwX1Q5/sc8UwAkHtWOp7RLeOByZM0DoEj5vJHsmly8Q=; b=dHSRE1n0oLMRv2s7n7wHCA8E/GL6UZpUoy5mC3UVFCfr/XlpIrBAPXy4 kIJ/WBRHBvN3AP4UooUrB26vrqvIWAAojNFfpp16W1bASH+37NNs0aF7u S0Hd9JRtoarCCIAyhjtk847NKGsrmFYKTMnTnes3Gq55p6LHJpiCkseVd w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIlSkk2rRDoH/2dsb2JhbAClTneIeZw3nGaFagSFPIdG X-IronPort-AV: E=Sophos;i="4.63,264,1299456000"; d="scan'208";a="327011697" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2011 21:46:09 +0000 Received: from dhcp-1789.meeting.ietf.org (sjc-vpn4-644.cisco.com [10.21.82.132]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2TLk8VY028970; Tue, 29 Mar 2011 21:46:08 GMT Message-Id: <8804CC98-361C-49F7-AE3B-1CBB015DB8E5@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4D9252AD.8020905@joelhalpern.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: Tue, 29 Mar 2011 14:46:07 -0700 References: <20110329213349.08B7218C0DF@mercury.lcs.mit.edu> <4D9252AD.8020905@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review 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: Tue, 29 Mar 2011 21:44:32 -0000 > While I like the theory you advance, I don't know how to build it in > practice. What size memory, short of the full LISP table, should I > build in my device to meet the MUST? Whatever size I build, someone > can easily build a test case for which it fails. This is true for all tables, and the analysis to deploy a new box always takes this in consideration. Dino > Personally, I am actually curious to see, in an enterprise edge > deployment, how well this works. I presume there is already some > data. The experiment will tell us more. > I wonder about the interaction of caching with all sorts of other > cases, but I do not see that the document needs to spell out all of > the history of our problems, or the difficulties in addressing this, > in order to conduct the experiment. > > Yours, > Joel > > On 3/29/2011 5:33 PM, Noel Chiappa wrote: >> > From: Yakov Rekhter >> >> > being able to detect thrasing is necessary, but not >> sufficient - an >> > implementation must be able to suppress thrasing. >> >> I'm interested in the engineering aspects of this, not just what to >> say in >> this particular document. >> >> The only way I've ever heard of to really 'fix' (AKA prevent) cache >> thrashing >> problems (going all the way back to the days of page replacement >> algorithms on >> big time-sharing machines, back when machines had relatively small >> main >> memories) is to either i) change the access pattern (perhaps by >> reducing >> offered load), or ii) increase the size of the cache. >> >> (Yes, yes, I know that in very limited-size caches, and to make the >> cache >> hardware 'relatively' simple, you get things like N-way associative >> caches. I >> don't think those apply here, because our caches will of necessity >> be much >> larger - since the cost of a miss is so large, we have to minimize >> miss count >> - and implemented very differently.) >> >> Since i) isn't really feasible for us , and ii) is 'relatively' >> easy now that >> memory is so cheap, is there any reason not to say something to the >> effect of >> 'we recommend that to prevent any possibility of cache thrashing, >> the ITR >> MUST be able to cache all the mappings it receives, only discarding >> mappings >> which have not been used in a considerable time (e.g. 1 hour)'. >> >> (Also, I think there is some data from one of the simulations done >> by the >> guys in Europe which shows how large caches have to be - or had to >> be at the >> time the simulations were done - to provide low levels of cache >> miss for >> previously seen destinations. I seem to recall that there was >> enough info >> there to work out how long you had to be able to hold mappings in >> the cache >> to keep refill overhead, etc, down to a reasonable level. Perhaps >> we should >> refer to that for setting the recommended hold time, above?) >> >> Noel >> _______________________________________________ >> 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 trac+lisp@trac.tools.ietf.org Tue Mar 29 22:56:27 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77313A6A8C for ; Tue, 29 Mar 2011 22:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 n-jWd-auUx+p for ; Tue, 29 Mar 2011 22:56:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D721F3A680E for ; Tue, 29 Mar 2011 22:56:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4oPf-0000aD-Im; Tue, 29 Mar 2011 22:57: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 05:57:51 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/45#comment:5 Message-ID: <066.7200d273731837eca3553bdf03ec18af@trac.tools.ietf.org> References: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #45: LISP vs. Existing (from 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, 30 Mar 2011 05:56:27 -0000 #45: LISP vs. Existing (from Y. Rekhter) Changes (by terry.manderson@…): * status: reopened => resolved * resolution: => fixed Comment: As a protocol definition in a document with experimental status we do not believe, as chairs, that it needs to outline the benefits that LISP may offer in NAT environments, or many other similar technology environments. It may be that these benefits are outlined in another informational document in the future, but it is out of scope for draft-ietf-lisp. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:37:28 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28DA428C0D7 for ; Tue, 29 Mar 2011 23:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 di2ClJTG1CYG for ; Tue, 29 Mar 2011 23:37:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3D57628C0CF for ; Tue, 29 Mar 2011 23:37:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4p3X-0006FV-7v; Tue, 29 Mar 2011 23:39: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:39:03 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/22#comment:4 Message-ID: <069.c011195d60ac30f65adaac4b8da4472d@trac.tools.ietf.org> References: <060.ea8474f8e9e720ff4a5501041a5c944c@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <060.ea8474f8e9e720ff4a5501041a5c944c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #22: An ETR MUST consume UDP port 4342 packets not addressed to it 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, 30 Mar 2011 06:37:28 -0000 #22: An ETR MUST consume UDP port 4342 packets not addressed to it Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: On Decision of the WG Chairs this issue is closed. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: resolved Priority: major | Component: alt Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:37:44 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A8C3A6B12 for ; Tue, 29 Mar 2011 23:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 kaVvB4imeZ-N for ; Tue, 29 Mar 2011 23:37:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 28D663A6B11 for ; Tue, 29 Mar 2011 23:37:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4p3q-0006jx-3k; Tue, 29 Mar 2011 23:39: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:39:22 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/22#comment:5 Message-ID: <069.4084ccb54066b54ca11ede2ee961a5e5@trac.tools.ietf.org> References: <060.ea8474f8e9e720ff4a5501041a5c944c@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <060.ea8474f8e9e720ff4a5501041a5c944c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #22: An ETR MUST consume UDP port 4342 packets not addressed to it 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, 30 Mar 2011 06:37:44 -0000 #22: An ETR MUST consume UDP port 4342 packets not addressed to it Changes (by luigi@…): * status: resolved => closed -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: closed Priority: major | Component: alt Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:43:06 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F20A3A6AB7 for ; Tue, 29 Mar 2011 23:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 tEac+DwFiosq for ; Tue, 29 Mar 2011 23:43:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ACC6E3A67F8 for ; Tue, 29 Mar 2011 23:43:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4p92-0002HA-Jf; Tue, 29 Mar 2011 23:44: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:44:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/21#comment:2 Message-ID: <069.f8e80ec024ee4e1c82c92d17f857672b@trac.tools.ietf.org> References: <060.2f6008fac67bff8ffd8bab747df7cd0b@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <060.2f6008fac67bff8ffd8bab747df7cd0b@trac.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+lisp@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] #21: Section 5.1 behavior 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, 30 Mar 2011 06:43:06 -0000 #21: Section 5.1 behavior Changes (by luigi@…): * status: new => resolved * resolution: => invalid Comment: The WG Chairs, while acknowledging that this was a legitimate question, believe that since the text is describing the behavior of an ITR when it is part of the ALT there is no need to transfer the text to the main specs. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: resolved Priority: minor | Component: alt Severity: - | Resolution: invalid Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:43:24 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABE73A6AD4 for ; Tue, 29 Mar 2011 23:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 CGyyxIANusTI for ; Tue, 29 Mar 2011 23:43:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 89A173A67F8 for ; Tue, 29 Mar 2011 23:43:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4p9H-0002W5-IV; Tue, 29 Mar 2011 23:44: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:44:59 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/21#comment:3 Message-ID: <069.62b35e6c0674e5a9b39af26bc4bfce4e@trac.tools.ietf.org> References: <060.2f6008fac67bff8ffd8bab747df7cd0b@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <060.2f6008fac67bff8ffd8bab747df7cd0b@trac.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+lisp@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] #21: Section 5.1 behavior 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, 30 Mar 2011 06:43:24 -0000 #21: Section 5.1 behavior Changes (by luigi@…): * status: resolved => closed -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: closed Priority: minor | Component: alt Severity: - | Resolution: invalid Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:51:08 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CFF33A6982 for ; Tue, 29 Mar 2011 23:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NnjHLAGcyxEO for ; Tue, 29 Mar 2011 23:51:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B07F83A6859 for ; Tue, 29 Mar 2011 23:51:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pGo-00036f-Md; Tue, 29 Mar 2011 23:52: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:52:46 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/76#comment:2 Message-ID: <077.3854317f13becfe4b07522034b012743@trac.tools.ietf.org> References: <068.45fcdf374d9ef1d35ed4fb98f02886e5@trac.tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <068.45fcdf374d9ef1d35ed4fb98f02886e5@trac.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+lisp@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] #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: Wed, 30 Mar 2011 06:51:08 -0000 #76: Implication of using anycast addresses for Map-servers Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The WG Chairs do not plan to allow the use of anycast for Map-Servers, hence consider that no change in the text is required. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: ms Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:51:24 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D4B3A6B18 for ; Tue, 29 Mar 2011 23:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 NljSslaUEqVv for ; Tue, 29 Mar 2011 23:51:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 284513A6B02 for ; Tue, 29 Mar 2011 23:51:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pH4-000379-6H; Tue, 29 Mar 2011 23:53: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:53:02 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/76#comment:3 Message-ID: <077.0ae7a0fecac9f1a353e62e7dbe1b99fa@trac.tools.ietf.org> References: <068.45fcdf374d9ef1d35ed4fb98f02886e5@trac.tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <068.45fcdf374d9ef1d35ed4fb98f02886e5@trac.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+lisp@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] #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: Wed, 30 Mar 2011 06:51:25 -0000 #76: Implication of using anycast addresses for Map-servers Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: ms Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:52:56 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8254B3A6B02 for ; Tue, 29 Mar 2011 23:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 9ZZMJigYXSEL for ; Tue, 29 Mar 2011 23:52:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B3FD63A6859 for ; Tue, 29 Mar 2011 23:52:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pIX-000382-OF; Tue, 29 Mar 2011 23:54: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:54:33 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/23#comment:3 Message-ID: <069.99c167a8c9af4836c136b48c008a6201@trac.tools.ietf.org> References: <060.5ae30f807b9da31e01375a39e603e0c9@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <060.5ae30f807b9da31e01375a39e603e0c9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #23: inner source RLOC undefined in some cases 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, 30 Mar 2011 06:52:56 -0000 #23: inner source RLOC undefined in some cases Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The WG Chairs believe that the response provided is sufficient to close the ticket. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: resolved Priority: minor | Component: ms Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:53:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753B43A6AB0 for ; Tue, 29 Mar 2011 23:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 8DuJ0i7L8S+O for ; Tue, 29 Mar 2011 23:53:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C75583A6826 for ; Tue, 29 Mar 2011 23:53:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pIo-00038N-6D; Tue, 29 Mar 2011 23:54: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:54:50 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/23#comment:4 Message-ID: <069.80f80a5e28320dc0b6e65e6db8e367cf@trac.tools.ietf.org> References: <060.5ae30f807b9da31e01375a39e603e0c9@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <060.5ae30f807b9da31e01375a39e603e0c9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #23: inner source RLOC undefined in some cases 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, 30 Mar 2011 06:53:12 -0000 #23: inner source RLOC undefined in some cases Changes (by luigi@…): * status: resolved => closed -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: closed Priority: minor | Component: ms Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:55:20 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801D83A6A46 for ; Tue, 29 Mar 2011 23:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 N93MweVPJaxf for ; Tue, 29 Mar 2011 23:55:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AB4FF3A67F8 for ; Tue, 29 Mar 2011 23:55:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pKs-0003II-Nj; Tue, 29 Mar 2011 23: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:56:58 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/77#comment:3 Message-ID: <077.bfeff270bc6a28f93acb693767a17d8f@trac.tools.ietf.org> References: <068.863221f9957e52ab837ccb12f1b9b2d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <068.863221f9957e52ab837ccb12f1b9b2d8@trac.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+lisp@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: Wed, 30 Mar 2011 06:55:20 -0000 #77: On the use of key-chaining for re-keying Changes (by luigi@…): * status: new => resolved * resolution: => invalid Comment: The WG Chairs believe that this is an implementation issue outside the scope of the document, hence consider the issue closed. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: minor | Component: ms Severity: - | Resolution: invalid Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:55:33 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60893A6B20 for ; Tue, 29 Mar 2011 23:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 v2qM00sDb5w2 for ; Tue, 29 Mar 2011 23:55:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8EB8A3A6B02 for ; Tue, 29 Mar 2011 23:55:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pL5-0003In-Im; Tue, 29 Mar 2011 23:57: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:57:11 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/77#comment:4 Message-ID: <077.6e19b453a3b19a227488daf85cfb4de7@trac.tools.ietf.org> References: <068.863221f9957e52ab837ccb12f1b9b2d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <068.863221f9957e52ab837ccb12f1b9b2d8@trac.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+lisp@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: Wed, 30 Mar 2011 06:55:33 -0000 #77: On the use of key-chaining for re-keying Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: minor | Component: ms Severity: - | Resolution: invalid Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:57:13 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859143A6B23 for ; Tue, 29 Mar 2011 23:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 IYiw+Ah6YvYC for ; Tue, 29 Mar 2011 23:57:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 63EEF3A6B20 for ; Tue, 29 Mar 2011 23:57:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pMh-0003Kr-DZ; Tue, 29 Mar 2011 23:58: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:58:51 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/78#comment:2 Message-ID: <077.a1e5969ef3d20a7551179a0316de4ade@trac.tools.ietf.org> References: <068.f713f8664a87d8479c836881ff78c848@trac.tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <068.f713f8664a87d8479c836881ff78c848@trac.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+lisp@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] #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: Wed, 30 Mar 2011 06:57:13 -0000 #78: Missing things (from J. Arkko's mail) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The WG Chairs believe that the response provided is sufficient to close this issue. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: minor | Component: ms Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:58:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846253A6982 for ; Tue, 29 Mar 2011 23:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 NsX4he232wWQ for ; Tue, 29 Mar 2011 23:57:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CC07C3A67F8 for ; Tue, 29 Mar 2011 23:57:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pNS-0003LW-S4; Tue, 29 Mar 2011 23:59: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 06:59:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/78#comment:3 Message-ID: <077.448198765f35d0c87edb91dafb08dd5e@trac.tools.ietf.org> References: <068.f713f8664a87d8479c836881ff78c848@trac.tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <068.f713f8664a87d8479c836881ff78c848@trac.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+lisp@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] #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: Wed, 30 Mar 2011 06:58:00 -0000 #78: Missing things (from J. Arkko's mail) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: minor | Component: ms Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Tue Mar 29 23:59:53 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02403A6B15 for ; Tue, 29 Mar 2011 23:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 Wz9eKEpswQI2 for ; Tue, 29 Mar 2011 23:59:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 003CD3A6B0F for ; Tue, 29 Mar 2011 23:59:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pPI-0000ks-0D; Wed, 30 Mar 2011 00:01: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:01:31 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/79#comment:2 Message-ID: <077.c77801e057d80503038c8e4b2d06176c@trac.tools.ietf.org> References: <068.e4cec7b5ffd26202146ed883ccf61822@trac.tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <068.e4cec7b5ffd26202146ed883ccf61822@trac.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+lisp@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] #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: Wed, 30 Mar 2011 06:59:53 -0000 #79: Editorial Issues (from J. Arkko's mail) Comment(by luigi@…): The WG Chairs will wait for the -08 version of the draft before taking a final decision on this issue. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: trivial | Component: ms Severity: - | Keywords: ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 00:15:38 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D0028C0F4 for ; Wed, 30 Mar 2011 00:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 3-m+02hwINZt for ; Wed, 30 Mar 2011 00:15:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D124D28C0FF for ; Wed, 30 Mar 2011 00:15:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4peN-0002UH-At; Wed, 30 Mar 2011 00: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:17:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/114#comment:4 Message-ID: <065.989cb314d36f5c56197828a1418e9af8@trac.tools.ietf.org> References: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 114 In-Reply-To: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #114: EID-to-RLOC mapping - transients 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, 30 Mar 2011 07:15:38 -0000 #114: EID-to-RLOC mapping - transients Changes (by terry.manderson@…): * status: new => resolved * resolution: => fixed Comment: As WG-Chairs we are closing this ticket. It is sufficient to document in draft-ietf-lisp that transients exist. As an experimental draft it is not necessary to require the draft to document all cases where the transient existence will cause a failure. That awareness can and will come, from experimentation and post analysis. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: resolved Priority: major | Component: alt Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From jmh@joelhalpern.com Wed Mar 30 00:21:41 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC9028C115 for ; Wed, 30 Mar 2011 00:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, 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 C6oFFSCNStpU for ; Wed, 30 Mar 2011 00:21:40 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 44B2228C10D for ; Wed, 30 Mar 2011 00:21:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3ABB74300D8 for ; Wed, 30 Mar 2011 00:23:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [130.129.38.181] (dhcp-26b5.meeting.ietf.org [130.129.38.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9190843004E for ; Wed, 30 Mar 2011 00:23:18 -0700 (PDT) Message-ID: <4D92DA61.6000303@joelhalpern.com> Date: Wed, 30 Mar 2011 03:23:13 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp@ietf.org References: <20110329213349.08B7218C0DF@mercury.lcs.mit.edu> <4D9252AD.8020905@joelhalpern.com> <8804CC98-361C-49F7-AE3B-1CBB015DB8E5@cisco.com> In-Reply-To: <8804CC98-361C-49F7-AE3B-1CBB015DB8E5@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] #46: Cache Thrashing (review 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, 30 Mar 2011 07:21:41 -0000 How about adding a second sentence to the paragraph in -11 that currently addresses this saying: Cache sizing has deployment and control plane implications. While one can get tempted into a long discussion of those implications, I do not think that is needed, whereas it is useful to remind implementors that those implications are present. Thank you, Joel On 3/29/2011 5:46 PM, Dino Farinacci wrote: >> While I like the theory you advance, I don't know how to build it in >> practice. What size memory, short of the full LISP table, should I >> build in my device to meet the MUST? Whatever size I build, someone >> can easily build a test case for which it fails. > > This is true for all tables, and the analysis to deploy a new box always > takes this in consideration. > > Dino > >> Personally, I am actually curious to see, in an enterprise edge >> deployment, how well this works. I presume there is already some data. >> The experiment will tell us more. >> I wonder about the interaction of caching with all sorts of other >> cases, but I do not see that the document needs to spell out all of >> the history of our problems, or the difficulties in addressing this, >> in order to conduct the experiment. >> >> Yours, >> Joel >> >> On 3/29/2011 5:33 PM, Noel Chiappa wrote: >>> > From: Yakov Rekhter >>> >>> > being able to detect thrasing is necessary, but not sufficient - an >>> > implementation must be able to suppress thrasing. >>> >>> I'm interested in the engineering aspects of this, not just what to >>> say in >>> this particular document. >>> >>> The only way I've ever heard of to really 'fix' (AKA prevent) cache >>> thrashing >>> problems (going all the way back to the days of page replacement >>> algorithms on >>> big time-sharing machines, back when machines had relatively small main >>> memories) is to either i) change the access pattern (perhaps by reducing >>> offered load), or ii) increase the size of the cache. >>> >>> (Yes, yes, I know that in very limited-size caches, and to make the >>> cache >>> hardware 'relatively' simple, you get things like N-way associative >>> caches. I >>> don't think those apply here, because our caches will of necessity be >>> much >>> larger - since the cost of a miss is so large, we have to minimize >>> miss count >>> - and implemented very differently.) >>> >>> Since i) isn't really feasible for us , and ii) is 'relatively' easy >>> now that >>> memory is so cheap, is there any reason not to say something to the >>> effect of >>> 'we recommend that to prevent any possibility of cache thrashing, the >>> ITR >>> MUST be able to cache all the mappings it receives, only discarding >>> mappings >>> which have not been used in a considerable time (e.g. 1 hour)'. >>> >>> (Also, I think there is some data from one of the simulations done by >>> the >>> guys in Europe which shows how large caches have to be - or had to be >>> at the >>> time the simulations were done - to provide low levels of cache miss for >>> previously seen destinations. I seem to recall that there was enough >>> info >>> there to work out how long you had to be able to hold mappings in the >>> cache >>> to keep refill overhead, etc, down to a reasonable level. Perhaps we >>> should >>> refer to that for setting the recommended hold time, above?) >>> >>> Noel >>> _______________________________________________ >>> 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 trac+lisp@trac.tools.ietf.org Wed Mar 30 00:22:14 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32D03A6B21 for ; Wed, 30 Mar 2011 00:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Myf3Bi3ZVKmN for ; Wed, 30 Mar 2011 00:22:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 075313A67FD for ; Wed, 30 Mar 2011 00:22:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pkX-00028R-GH; Wed, 30 Mar 2011 00:23: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:23:29 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/114#comment:5 Message-ID: <065.98aa1663c4043c9fa048103240215c41@trac.tools.ietf.org> References: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 114 In-Reply-To: <056.ca586cec75063f6a58e2730d802ad6dd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #114: EID-to-RLOC mapping - transients 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, 30 Mar 2011 07:22:15 -0000 #114: EID-to-RLOC mapping - transients Changes (by terry.manderson@…): * status: resolved => closed -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: closed Priority: major | Component: alt Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 00:28:20 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9E73A6802 for ; Wed, 30 Mar 2011 00:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 SW9bdAwo7eDn for ; Wed, 30 Mar 2011 00:28:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C690B3A6AD4 for ; Wed, 30 Mar 2011 00:28:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pqo-0005Nv-Oc; Wed, 30 Mar 2011 00:29: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:29:58 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/80#comment:1 Message-ID: <077.5b1f9a19b398616ea46cb3a9f5f711b9@trac.tools.ietf.org> References: <068.16cc2f76eb8757537cf620ea51234a22@trac.tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <068.16cc2f76eb8757537cf620ea51234a22@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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: Wed, 30 Mar 2011 07:28:20 -0000 #80: Router Performances Changes (by jmh@…): * status: new => resolved * resolution: => fixed Comment: As the section itself is informative, and probably useful to readers, with the changes made in -11 this appears to be sufficiently addressed. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 00:31:26 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E3D3A6B21 for ; Wed, 30 Mar 2011 00:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 LYXZqQ7OTBCL for ; Wed, 30 Mar 2011 00:31:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 04F393A6B15 for ; Wed, 30 Mar 2011 00:31:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pth-0008BM-NQ; Wed, 30 Mar 2011 00:32: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:32:57 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/82#comment:3 Message-ID: <066.7e1a44c3cf9042897ec4acaf6d3fc701@trac.tools.ietf.org> References: <057.4cd8d8e5f55131ea251196d9debcb9ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <057.4cd8d8e5f55131ea251196d9debcb9ee@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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, 30 Mar 2011 07:31:26 -0000 #82: Wording in Abstract (comment 8 and 44 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: new => resolved * resolution: => fixed Comment: This has been addressed as of -11. The raised wording no longer appears. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 00:32:05 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BB73A6B26 for ; Wed, 30 Mar 2011 00:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 Z7Vg7CcVuDkz for ; Wed, 30 Mar 2011 00:32:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 637543A6B24 for ; Wed, 30 Mar 2011 00:32:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4puO-0000TU-MD; Wed, 30 Mar 2011 00:33: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:33:36 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/82#comment:4 Message-ID: <066.8f84baf8c6da1d66c429cb2eaa9c4fff@trac.tools.ietf.org> References: <057.4cd8d8e5f55131ea251196d9debcb9ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <057.4cd8d8e5f55131ea251196d9debcb9ee@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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, 30 Mar 2011 07:32:05 -0000 #82: Wording in Abstract (comment 8 and 44 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 00:33:28 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8F228C130 for ; Wed, 30 Mar 2011 00:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 RWuv8uZ6qu4t for ; Wed, 30 Mar 2011 00:33:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B4C5B28C128 for ; Wed, 30 Mar 2011 00:33:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pvc-0002hr-PN; Wed, 30 Mar 2011 00:34: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:34:56 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/83#comment:1 Message-ID: <066.ab1a442dde570fff0b3ec52475b8d0b5@trac.tools.ietf.org> References: <057.edbf85f3e9f5e57abf4a5a6f7a6c3e1c@trac.tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <057.edbf85f3e9f5e57abf4a5a6f7a6c3e1c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 07:33:28 -0000 #83: Wording in Abstract (comment 8 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: new => resolved * resolution: => fixed Comment: This has be addressed as of -11. The raised text no longer appears in the draft. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 00:33:46 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2EF428C115 for ; Wed, 30 Mar 2011 00:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0M-rmWBx-A8O for ; Wed, 30 Mar 2011 00:33:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 57C793A6B20 for ; Wed, 30 Mar 2011 00:33:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4pvw-0003Gz-CJ; Wed, 30 Mar 2011 00:35: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:35:16 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/83#comment:2 Message-ID: <066.f1e65bba925378f52f4e5bae46f080f0@trac.tools.ietf.org> References: <057.edbf85f3e9f5e57abf4a5a6f7a6c3e1c@trac.tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <057.edbf85f3e9f5e57abf4a5a6f7a6c3e1c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 07:33:46 -0000 #83: Wording in Abstract (comment 8 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 00:49:14 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AF83A6B10 for ; Wed, 30 Mar 2011 00:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 Qojj8AJWjBtp for ; Wed, 30 Mar 2011 00:49:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CBB3C3A6866 for ; Wed, 30 Mar 2011 00:49:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qAv-0004qT-12; Wed, 30 Mar 2011 00:50: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:50:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/84#comment:5 Message-ID: <066.4647b14e2b0b93a5bec06379cd2a6841@trac.tools.ietf.org> References: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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, 30 Mar 2011 07:49:14 -0000 #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter) Changes (by jmh@…): * status: reopened => resolved * resolution: => fixed Comment: The revised text as of -11 as been reworded to clarify the scope of this renumbering coverage. This seems to sufficiently address the issue, as the text is not misleading and it would be inappropriate to try to address all of the system complexities in the introduction. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 00:51:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1253A6B31 for ; Wed, 30 Mar 2011 00:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 3HDauaV8MNqI for ; Wed, 30 Mar 2011 00:51:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E5EE13A6B28 for ; Wed, 30 Mar 2011 00:51:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qDO-0004v9-LW; Wed, 30 Mar 2011 00:53: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:53:18 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/85#comment:1 Message-ID: <066.99577950ce3aa38373ba29b0ae19ca75@trac.tools.ietf.org> References: <057.a6d8a8a9431fa4a2fa4139f6f21dbdef@trac.tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <057.a6d8a8a9431fa4a2fa4139f6f21dbdef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 07:51:40 -0000 #85: Mobility without address changing (comment 9 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: new => resolved * resolution: => fixed Comment: The chairs believe the authors have sufficiently reworded the draft text as of -11 and this item has been addressed. This ticket is being closed. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 00:51:56 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEEBE3A6B31 for ; Wed, 30 Mar 2011 00:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 k9EOn5g16scJ for ; Wed, 30 Mar 2011 00:51:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 493BF3A6A98 for ; Wed, 30 Mar 2011 00:51:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qDe-0004vP-BC; Wed, 30 Mar 2011 00:53: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 07:53:34 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/85#comment:2 Message-ID: <066.f70b4a4886631184b39da491e8e1cbe2@trac.tools.ietf.org> References: <057.a6d8a8a9431fa4a2fa4139f6f21dbdef@trac.tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <057.a6d8a8a9431fa4a2fa4139f6f21dbdef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 07:51:56 -0000 #85: Mobility without address changing (comment 9 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 01:02:08 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812233A6B0E for ; Wed, 30 Mar 2011 01:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 bzy5FjPxHeqx for ; Wed, 30 Mar 2011 01:02:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D2AF83A6B31 for ; Wed, 30 Mar 2011 01:02:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qNW-0002ew-Jd; Wed, 30 Mar 2011 01:03: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 08:03:46 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/88#comment:1 Message-ID: <066.fc1810a3baf656486d1059bb12dc7f66@trac.tools.ietf.org> References: <057.b6beff53451d6277688de78ea26da1d9@trac.tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <057.b6beff53451d6277688de78ea26da1d9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 08:02:08 -0000 #88: "Proxy device" description (comment 12 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: new => resolved * resolution: => fixed Comment: From the chairs point of view the Proxy ITRs and Proxy ETRs are well defined and this ticket is closed. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 01:02:21 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAE63A6AF5 for ; Wed, 30 Mar 2011 01:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 MdlDcCf10Kso for ; Wed, 30 Mar 2011 01:02:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 354CD3A6B30 for ; Wed, 30 Mar 2011 01:02:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qNk-0002fY-8F; Wed, 30 Mar 2011 01:04: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 08:04:00 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/88#comment:2 Message-ID: <066.2d455a09d83cca59e80c61cd83ad87c8@trac.tools.ietf.org> References: <057.b6beff53451d6277688de78ea26da1d9@trac.tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <057.b6beff53451d6277688de78ea26da1d9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 08:02:21 -0000 #88: "Proxy device" description (comment 12 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 01:04:11 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFE03A6B0E for ; Wed, 30 Mar 2011 01:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 lSWtnQZlP1IG for ; Wed, 30 Mar 2011 01:04:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CDB113A6AF5 for ; Wed, 30 Mar 2011 01:04:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qPR-0002pi-TD; Wed, 30 Mar 2011 01:05: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 08:05:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/90#comment:4 Message-ID: <066.8a0edeec858363f55bda8bef123a9dce@trac.tools.ietf.org> References: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.tools.ietf.org> X-Trac-Ticket-ID: 90 In-Reply-To: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 08:04:11 -0000 #90: Restricting re-encapsulation (comment 12 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: reopened => resolved * resolution: => fixed Comment: from the chairs point of view this issue is fixed, the restriction was removed. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 01:04:24 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E363A6B32 for ; Wed, 30 Mar 2011 01:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 7NIqdAtKjI2A for ; Wed, 30 Mar 2011 01:04:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9DE413A6B30 for ; Wed, 30 Mar 2011 01:04:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qPe-0002qO-T1; Wed, 30 Mar 2011 01:05: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 08:05:58 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/90#comment:5 Message-ID: <066.170c89eb98c09e64a44fe1b5382c5b6b@trac.tools.ietf.org> References: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.tools.ietf.org> X-Trac-Ticket-ID: 90 In-Reply-To: <057.c2afd19f5efd5e0b56214e525e3a2d61@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 08:04:24 -0000 #90: Restricting re-encapsulation (comment 12 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 01:08:21 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1362B3A6969 for ; Wed, 30 Mar 2011 01:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 e0Vntcq+lLWF for ; Wed, 30 Mar 2011 01:08:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 274DC3A6886 for ; Wed, 30 Mar 2011 01:08:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qTW-0002xe-Ab; Wed, 30 Mar 2011 01:09: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 30 Mar 2011 08:09:58 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/91#comment:2 Message-ID: <066.6187a57209d0948488e24837d36534ca@trac.tools.ietf.org> References: <057.4ef4b95468b76b9cc11050d0b9322670@trac.tools.ietf.org> X-Trac-Ticket-ID: 91 In-Reply-To: <057.4ef4b95468b76b9cc11050d0b9322670@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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, 30 Mar 2011 08:08:21 -0000 #91: Data probe (comment 12 reported by Y. Rekhter) Changes (by jmh@…): * status: new => resolved * resolution: => fixed Comment: The definition now notes that the usage of data probes is dependent upon the specifics of the mapping system. This seems to sufficiently address the issue. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 01:11:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3DA3A6B33 for ; Wed, 30 Mar 2011 01:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 G9m8j1Yb5bnw for ; Wed, 30 Mar 2011 01:11:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DCB0D3A6B31 for ; Wed, 30 Mar 2011 01:10:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qW5-0003CW-I5; Wed, 30 Mar 2011 01:12: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, terry.manderson@icann.org, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 30 Mar 2011 08:12:37 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/91#comment:3 Message-ID: <066.9cc2559381bec95f00b8c4289dc9b30c@trac.tools.ietf.org> References: <057.4ef4b95468b76b9cc11050d0b9322670@trac.tools.ietf.org> X-Trac-Ticket-ID: 91 In-Reply-To: <057.4ef4b95468b76b9cc11050d0b9322670@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, terry.manderson@icann.org, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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, 30 Mar 2011 08:11:03 -0000 #91: Data probe (comment 12 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 01:20:19 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8801C28C0CE for ; Wed, 30 Mar 2011 01:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 QnqUW0bb90-q for ; Wed, 30 Mar 2011 01:20:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7DAA93A6AFD for ; Wed, 30 Mar 2011 01:20:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qf3-0002Ee-Av; Wed, 30 Mar 2011 01:21: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 30 Mar 2011 08:21:53 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/93#comment:2 Message-ID: <066.29216d966dcb9d413dff22e574bc8088@trac.tools.ietf.org> References: <057.63cffa477f8ccfd4caf3e3da8005eebd@trac.tools.ietf.org> X-Trac-Ticket-ID: 93 In-Reply-To: <057.63cffa477f8ccfd4caf3e3da8005eebd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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, 30 Mar 2011 08:20:19 -0000 #93: VPN (comment 14 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: new => resolved * type: technical => editorial * resolution: => fixed Comment: This is just and example, the LISP spec is not deciding how to do VPNs. This is editorial in nature, and not technical. We the chairs believe it is fine to leave this text. Ticket closed. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 01:20:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A4028C119 for ; Wed, 30 Mar 2011 01:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 0Ebua2A43aij for ; Wed, 30 Mar 2011 01:20:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 15BF528C0F6 for ; Wed, 30 Mar 2011 01:20:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qfP-0002on-Qr; Wed, 30 Mar 2011 01:22: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org, wmhaddad@gmail.com X-Trac-Project: lisp Date: Wed, 30 Mar 2011 08:22:15 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/93#comment:3 Message-ID: <066.5d0fd68189f012f4e964853aaad9c634@trac.tools.ietf.org> References: <057.63cffa477f8ccfd4caf3e3da8005eebd@trac.tools.ietf.org> X-Trac-Ticket-ID: 93 In-Reply-To: <057.63cffa477f8ccfd4caf3e3da8005eebd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, wmhaddad@gmail.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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, 30 Mar 2011 08:20:40 -0000 #93: VPN (comment 14 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 01:36:52 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99EC28C101 for ; Wed, 30 Mar 2011 01:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 Dr40kKyRj6do for ; Wed, 30 Mar 2011 01:36:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C101328C0DD for ; Wed, 30 Mar 2011 01:36:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4qv8-0008GH-Po; Wed, 30 Mar 2011 01:38: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com X-Trac-Project: lisp Date: Wed, 30 Mar 2011 08:38:30 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/104#comment:1 Message-ID: <066.df49a467a7cc5c5ef8394dd437c4d5d9@trac.tools.ietf.org> References: <057.f694ed8ffc9311fa27f420bbc248f1c8@trac.tools.ietf.org> X-Trac-Ticket-ID: 104 In-Reply-To: <057.f694ed8ffc9311fa27f420bbc248f1c8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 08:36:52 -0000 #104: Impact of slashdotting ETR (comment 21 reported by Y. Rekhter) Changes (by jmh@…): * status: new => resolved * resolution: => fixed Comment: This kind of information is usually captured in a protocol analysis document. That is not normally needed for experimental document publication, and does not seem necessary in this case. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:08:23 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808993A6AFB for ; Wed, 30 Mar 2011 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 nUkOdhqXdMHi for ; Wed, 30 Mar 2011 02:08:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 200A23A69FC for ; Wed, 30 Mar 2011 02:08:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rPb-0004Xi-TN; Wed, 30 Mar 2011 02:09: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:09:59 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/108#comment:2 Message-ID: <066.a34116068e4a43e0ea8028641d4f6cea@trac.tools.ietf.org> References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> X-Trac-Ticket-ID: 108 In-Reply-To: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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, 30 Mar 2011 09:08:23 -0000 #108: "R" bit in Map-Reply message format (comment 22 reported by Y. Rekhter) Changes (by terry.manderson@…): * priority: major => minor * type: technical => editorial -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:13:56 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01BEA3A6B35 for ; Wed, 30 Mar 2011 02:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 PNPJeZKab+f7 for ; Wed, 30 Mar 2011 02:13:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 259A63A6B33 for ; Wed, 30 Mar 2011 02:13:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rV0-0005G4-8I; Wed, 30 Mar 2011 02:15: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:15:34 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/115#comment:1 Message-ID: <065.e2e1c6770340fa03cfa5dd7bae6cd084@trac.tools.ietf.org> References: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #115: claims in Section 7 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, 30 Mar 2011 09:13:56 -0000 #115: claims in Section 7 Changes (by jmh@…): * status: new => resolved * resolution: => fixed Comment: This has been clarified in -11 to make clear that some hardware has been demonstrated not to need modification to support LISP. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:19:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABBE33A6875 for ; Wed, 30 Mar 2011 02:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 6YvyYevCDCqU for ; Wed, 30 Mar 2011 02:19:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 918093A697A for ; Wed, 30 Mar 2011 02:19:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4ra7-0002bT-GW; Wed, 30 Mar 2011 02:20: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:20:51 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/112#comment:1 Message-ID: <065.e3fe6414dcf775ee9b0073a728202f19@trac.tools.ietf.org> References: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #112: use of re-encapsulation is underspecified 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, 30 Mar 2011 09:19:18 -0000 #112: use of re-encapsulation is underspecified Changes (by terry.manderson@…): * status: new => resolved * resolution: => fixed Comment: Re-escapsulation is a traffic engineering mechanism, describing this in draft-ietf-lisp is not the right place. At this stage the WG does not have a document that describes how to do traffic engineering. Perhaps in the future that document may come to life. Until it does there is no way forward for this ticket. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:19:39 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679363A6B33 for ; Wed, 30 Mar 2011 02:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 iPtK6DJY3YHW for ; Wed, 30 Mar 2011 02:19:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BD7BC3A6B0E for ; Wed, 30 Mar 2011 02:19:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4raX-0003CC-J3; Wed, 30 Mar 2011 02:21: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:21:17 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/112#comment:2 Message-ID: <065.6bc2e70868a1aa7d19927fd361e7eec3@trac.tools.ietf.org> References: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #112: use of re-encapsulation is underspecified 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, 30 Mar 2011 09:19:39 -0000 #112: use of re-encapsulation is underspecified Changes (by terry.manderson@…): * status: resolved => closed -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:22:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D96E28C119 for ; Wed, 30 Mar 2011 02:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 W+Sci9sQ5YKA for ; Wed, 30 Mar 2011 02:22:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E8DF628C113 for ; Wed, 30 Mar 2011 02:22:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rcv-0007Zm-9n; Wed, 30 Mar 2011 02:23: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:23:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/113#comment:5 Message-ID: <065.86041f7061cca9d590ee66389252a94c@trac.tools.ietf.org> References: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #113: inbound traffic engineering support with LISP 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, 30 Mar 2011 09:22:12 -0000 #113: inbound traffic engineering support with LISP Changes (by terry.manderson@…): * status: reopened => resolved * resolution: => fixed Comment: I don't see draft-ietf-lisp as the right place to describe how to perform traffic engineering. At this stage the WG does not have a document that describes how to do traffic engineering. Perhaps in the future that document may come to life. Until it does there is no way forward for this ticket. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:22:30 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF213A6A3A for ; Wed, 30 Mar 2011 02:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 3YGY0MXzON4w for ; Wed, 30 Mar 2011 02:22:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 302B028C123 for ; Wed, 30 Mar 2011 02:22:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rdF-0008D5-3w; Wed, 30 Mar 2011 02:24: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:24:05 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/113#comment:6 Message-ID: <065.851a1b97b7d5ba594bf1575a11d920c5@trac.tools.ietf.org> References: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <056.b29368296d1e29e9759ce0ee81e0c335@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #113: inbound traffic engineering support with LISP 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, 30 Mar 2011 09:22:30 -0000 #113: inbound traffic engineering support with LISP Changes (by terry.manderson@…): * status: resolved => closed -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:25:43 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCA43A6B38 for ; Wed, 30 Mar 2011 02:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 CioFyoBPmhh7 for ; Wed, 30 Mar 2011 02:25:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A36033A6AFB for ; Wed, 30 Mar 2011 02:25:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rgO-0005yO-0L; Wed, 30 Mar 2011 02:27: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:27:19 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/25#comment:2 Message-ID: <069.a4a61b59c78af048b0147c0c346d5a39@trac.tools.ietf.org> References: <060.d231c2fff311c375f62f929d7213d1c4@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <060.d231c2fff311c375f62f929d7213d1c4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #25: Map Server to ETR security has no automated key management 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, 30 Mar 2011 09:25:43 -0000 #25: Map Server to ETR security has no automated key management Changes (by terry.manderson@…): * priority: major => blocker Comment: The requirement for automated key management in an experimental draft has been raised with the INT and SEC ADs. The chairs believe that this is an item for future work. This item will be updated after a response comes from the ADs. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: blocker | Component: ms Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:32:56 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E35C28C116 for ; Wed, 30 Mar 2011 02:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 rip3IuWScWCO for ; Wed, 30 Mar 2011 02:32:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 44E0D28C111 for ; Wed, 30 Mar 2011 02:32:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rnG-0001IW-E8; Wed, 30 Mar 2011 02:34: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:34:26 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/47#comment:5 Message-ID: <066.c747cfbd43f5ee485c3aa38e4487a85a@trac.tools.ietf.org> References: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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, 30 Mar 2011 09:32:56 -0000 #47: Ambiguity on "MAP-replies" requirements (review by Y. Rekhter) Changes (by terry.manderson@…): * status: reopened => resolved * resolution: => fixed Comment: we believe #114 subsumed this ticket, now that #114 is closed. Doing the same here. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:33:06 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D0C28C120 for ; Wed, 30 Mar 2011 02:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 vsNjmwAEvdJP for ; Wed, 30 Mar 2011 02:33:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5897328C0E0 for ; Wed, 30 Mar 2011 02:33:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rnU-0001YC-FF; Wed, 30 Mar 2011 02:34: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:34:40 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/47#comment:6 Message-ID: <066.7f12d83f824b5d4cc3bd7dad01bc5f2c@trac.tools.ietf.org> References: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <057.d106700ac7dd9e5181d1df51e88b5585@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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, 30 Mar 2011 09:33:06 -0000 #47: Ambiguity on "MAP-replies" requirements (review by Y. Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:34:22 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146F93A6912 for ; Wed, 30 Mar 2011 02:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 48ECASXzgFhL for ; Wed, 30 Mar 2011 02:34:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A680B3A68CE for ; Wed, 30 Mar 2011 02:34:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4roh-0004Xp-2z; Wed, 30 Mar 2011 02:35: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:35:55 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/48#comment:8 Message-ID: <066.a0076e8b098e76acffac93075bb12ffd@trac.tools.ietf.org> References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 30 Mar 2011 09:34:22 -0000 #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) Changes (by terry.manderson@…): * status: reopened => resolved * resolution: => fixed Comment: We, as chairs, that #114 subsumed this ticket. Now that it is closed, doing the same here. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:34:43 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF5928C12C for ; Wed, 30 Mar 2011 02:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 YzwIK8HFCUl9 for ; Wed, 30 Mar 2011 02:34:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A88BA28C126 for ; Wed, 30 Mar 2011 02:34:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rp2-00052F-0L; Wed, 30 Mar 2011 02:36: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:36:15 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/48#comment:9 Message-ID: <066.0dec78f4446214ff6c79cc11b465bbbf@trac.tools.ietf.org> References: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <057.8523523dc5d63eadc78f4c87ce8cf0b1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dino@cisco.com, luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 30 Mar 2011 09:34:43 -0000 #48: MAP-Replies returning different contents for a given EID (review by Y, Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:37:14 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFF33A6A9D for ; Wed, 30 Mar 2011 02:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 e61aDb2nstUu for ; Wed, 30 Mar 2011 02:37:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1CDA93A6912 for ; Wed, 30 Mar 2011 02:37:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rrW-00029Z-Lu; Wed, 30 Mar 2011 02:38: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:38:50 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/15#comment:3 Message-ID: <069.6209bda54b41b5cf51d35868be47b390@trac.tools.ietf.org> References: <060.b4b15d03f6ba3bc357ace2e39ad3d053@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <060.b4b15d03f6ba3bc357ace2e39ad3d053@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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 List-Id: 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, 30 Mar 2011 09:37:15 -0000 #15: chairs to review normative and informative references Comment(by terry.manderson@…): Note to secretaries: Please review draft-ietf-lisp reference section for proper use of normative/informative references before submission to IESG occurs. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: editorial | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 02:38:30 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB1F3A6A9D for ; Wed, 30 Mar 2011 02:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 652ILnVlA-Gb for ; Wed, 30 Mar 2011 02:38:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5D6533A6912 for ; Wed, 30 Mar 2011 02:38:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4rsl-0004fj-SL; Wed, 30 Mar 2011 02:40: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, terry.manderson@icann.org X-Trac-Project: lisp Date: Wed, 30 Mar 2011 09:40:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lisp/trac/ticket/115#comment:2 Message-ID: <065.fcbfdafc244fe55989c35467f6569d70@trac.tools.ietf.org> References: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #115: claims in Section 7 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, 30 Mar 2011 09:38:30 -0000 #115: claims in Section 7 Changes (by terry.manderson@…): * status: resolved => closed -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From jesper@cisco.com Wed Mar 30 04:40:36 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91E728C0F9 for ; Wed, 30 Mar 2011 04:40:36 -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 7T984ZDkcMHt for ; Wed, 30 Mar 2011 04:40:35 -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 4E60528C0DB for ; Wed, 30 Mar 2011 04:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jesper@cisco.com; l=1872; q=dns/txt; s=iport; t=1301485334; x=1302694934; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=dewklA561NzYEL5qQTbaiVKzvIGXie8U7L+4Sk1uFFc=; b=fD5P17GF1kLSha6E78G+PSAHP12ynXvDfOY0kNfnGgO2bQhHThFl9yKw 23syjARxcjCEqy9Q4DNtJ+iJDPg21COa3HT2ifmo/o7wMNv7P7eMtXQZq mLIa0JXRpF9Ci8z5XSWpkBeV9B8DcNlmSgzbQ66ZagosAgzuIRdw+wcCz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgDALQWk02Q/khMgWdsb2JhbAClThQBARYmJaEbnFuFagSFOYdNg1U X-IronPort-AV: E=Sophos;i="4.63,268,1299456000"; d="scan'208";a="23786059" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 30 Mar 2011 11:41:51 +0000 Received: from [127.0.0.1] (gpk-lds-001.cisco.com [64.103.78.6]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2UBfpe6010160; Wed, 30 Mar 2011 11:41:51 GMT From: Jesper Skriver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 14:41:50 +0300 Message-Id: To: Luigi Iannone Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: lisp@ietf.org Subject: [lisp] Versioning, I don't think we need to disable source versioning when we have no destination version. 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, 30 Mar 2011 11:40:36 -0000 Luigi, draft-ietf-lisp-map-versioning-01 section 4.1 reads The other use of the Null Map-Version number is in the Map Records, which are part of the Map-Request, Map-Reply and Map-Register messages (defined in [I-D.ietf-lisp]). Map Records that have a Null Map-Version number indicate that there is no Map-Version number associated with the mapping. This means that LISP encapsulated packets, destined to the EID-Prefix the Map Record refers to, MUST NOT contain Map-Version numbers (i.e., V bit MUST always be 0). In other words, the Null Map-Version number signals to the ITR using the mapping that the Map-Versioning is not supported, or even if supported it MUST NOT be used for that specific EID-Prefix. Any value different from zero means that Map-Versioning is supported and MAY be used. I think that the use of "MUST NOT" is too strict here, even if an ETR = returned a Null Map-Version number in a Map Record to an ITR, there is = still value in using source versioning for traffic from the ITR to the = ETR. The ETR may be able to check the source version number, and use = versioning to update the reverse mapping. So I suggest changing this text to The other use of the Null Map-Version number is in the Map Records, which are part of the Map-Request, Map-Reply and Map-Register messages (defined in [I-D.ietf-lisp]). Map Records that have a Null Map-Version number indicate that there is no Map-Version number associated with the mapping. This means that LISP encapsulated packets, destined to the EID-Prefix the Map Record refers to, MUST either not contain any Map-Version numbers (V bit set to 0), or if it contains Map-Version numbers (V bit set to 1) then the destination Map-Version number MUST be set to the Null Map-Version number. /Jesper From damien.saucez@uclouvain.be Wed Mar 30 04:48:34 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120AE28C0DB for ; Wed, 30 Mar 2011 04:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 kTFgN9vJXUut for ; Wed, 30 Mar 2011 04:48:32 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 5CA333A6947 for ; Wed, 30 Mar 2011 04:48:32 -0700 (PDT) Received: from [130.104.228.23] (unknown [130.104.228.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 8FDACF28C0; Wed, 30 Mar 2011 13:49:51 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be 8FDACF28C0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1301485791; bh=VKqud07HKEPuSqDFRhob9HUJAucqDpSFi3zCMpdXMac=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=0fkUWSlrDpgQoXYY+eaeuBvGddC3bJNBeU5GuIOleNUdJYCcfGAvo6DDrnpQ4Ziiz azCeYOZS2vCoR8e5nStB8Z/8mJHLpuffCZAgfWr3BI/zLLL4zQ+jBdEUQY2f2DtIL7 wIPW55WfMTaPe6rYKaHvz1QtXgsN3Bzo1w2fnHSU= Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: Date: Wed, 30 Mar 2011 13:49:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3D246EAF-2824-4BED-A817-95A812201C44@uclouvain.be> References: To: Jesper Skriver X-Mailer: Apple Mail (2.1082) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 8FDACF28C0.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Versioning, I don't think we need to disable source versioning when we have no destination version. 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, 30 Mar 2011 11:48:34 -0000 Hello, On 30 Mar 2011, at 13:41, Jesper Skriver wrote: > Luigi, >=20 > draft-ietf-lisp-map-versioning-01 section 4.1 reads >=20 > The other use of the Null Map-Version number is in the Map Records, > which are part of the Map-Request, Map-Reply and Map-Register > messages (defined in [I-D.ietf-lisp]). Map Records that have a Null > Map-Version number indicate that there is no Map-Version number > associated with the mapping. This means that LISP encapsulated > packets, destined to the EID-Prefix the Map Record refers to, MUST > NOT contain Map-Version numbers (i.e., V bit MUST always be 0). In > other words, the Null Map-Version number signals to the ITR using = the > mapping that the Map-Versioning is not supported, or even if > supported it MUST NOT be used for that specific EID-Prefix. Any > value different from zero means that Map-Versioning is supported and > MAY be used. >=20 > I think that the use of "MUST NOT" is too strict here, even if an ETR = returned a Null Map-Version number in a Map Record to an ITR, there is = still value in using source versioning for traffic from the ITR to the = ETR. The ETR may be able to check the source version number, and use = versioning to update the reverse mapping. >=20 > So I suggest changing this text to >=20 > The other use of the Null Map-Version number is in the Map Records, > which are part of the Map-Request, Map-Reply and Map-Register > messages (defined in [I-D.ietf-lisp]). Map Records that have a Null > Map-Version number indicate that there is no Map-Version number > associated with the mapping. This means that LISP encapsulated > packets, destined to the EID-Prefix the Map Record refers to, MUST > either not contain any Map-Version numbers (V bit set to 0), or if > it contains Map-Version numbers (V bit set to 1) then the = destination > Map-Version number MUST be set to the Null Map-Version number. >=20 Ok, but before we have to check what it means for security Damien Saucez > /Jesper >=20 >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From trac+lisp@trac.tools.ietf.org Wed Mar 30 07:10:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136D33A6A1D for ; Wed, 30 Mar 2011 07:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 daN4K46OlTUW for ; Wed, 30 Mar 2011 07:10:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6A5B23A69A4 for ; Wed, 30 Mar 2011 07:10:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4w7W-0004OU-KT; Wed, 30 Mar 2011 07:11: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 14:11:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/112#comment:3 Message-ID: <065.f3a350edfe6c4be795acf265a84c4bb2@trac.tools.ietf.org> References: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #112: use of re-encapsulation is underspecified 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, 30 Mar 2011 14:10:03 -0000 #112: use of re-encapsulation is underspecified Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: From the last proposed resolution text: Re-encapsulation is a traffic engineering mechanism, describing this in draft- ietf-lisp is not the right place. At this stage the WG does not have a document that describes how to do traffic engineering. Perhaps in the future that document may come to life. Until it does there is no way forward for this ticket. Does the above mean that the only use for re-encapsulation is for traffic engineering ? If yes, and if indeed draft-ietf-lisp "is not the right place" for describing re-encapsulation as a traffic engineering mechanism, then all the references to re-encapsulation should be removed from the draft. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 07:18:05 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F363A6B5D for ; Wed, 30 Mar 2011 07:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 2jfmkj-UxBH3 for ; Wed, 30 Mar 2011 07:18:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 640B73A6A34 for ; Wed, 30 Mar 2011 07:18:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4wFH-0007JK-QE; Wed, 30 Mar 2011 07:19: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 14:19:39 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/115#comment:3 Message-ID: <065.6d6b508a6ee9fe869eb9b35aefadbbd3@trac.tools.ietf.org> References: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #115: claims in Section 7 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, 30 Mar 2011 14:18:05 -0000 #115: claims in Section 7 Changes (by yakov@…): * status: closed => reopened * resolution: fixed => Comment: -11 version still has the following: LISP is designed to be very hardware-based forwarding friendly. In order to close this comment the above sentence should be deleted. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: reopened Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 07:27:01 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DB63A67FC for ; Wed, 30 Mar 2011 07:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 ZdKIEMelrmEV for ; Wed, 30 Mar 2011 07:27:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 972E53A6B61 for ; Wed, 30 Mar 2011 07:27:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4wNu-0000Jm-G9; Wed, 30 Mar 2011 07:28: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 14:28:34 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/46#comment:7 Message-ID: <066.ad02766285adad2aca77db38f90de9c8@trac.tools.ietf.org> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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) 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, 30 Mar 2011 14:27:01 -0000 #46: Cache Thrashing (review by Y. Rekhter) Comment(by yakov@…): Here is the text that has been added: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. The above text failed to mention that cache sizing is an issue not just "during implementation", but during deployment as well. Moreover, the above text failed to mention that in the context of LISP, thrashing of the cache on a given ITR/PTR has non-local implications, as it could result in excessive volume of LISP control traffic, which in turn would further deteriorate the situation. Finally, the above failed to mention that being able to detect thrasing is necessary, but not sufficient - an implementation must be able to suppress thrasing. With all this in mind I would like to propose replacing the text quoted above with the following: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue to be kept in mind during both implementation and deployment. In the context of LISP, cache thrasing on the ITR/PTR could result in the ITR/PTR dropping data, thus negatively affecting connectivity. Moreover, it could also result in excessive volume of LISP control traffic, which could spread the detrimental effects of thrasing beyond the ITR/PTR and all the hosts that communicate through this ITR/PTR. Therefore, an implementation MUST provide instrumentation in place to detect thrashing of the cache, and MUST provide mechanism(s) to suppress thrasing. Specifications of such mechanisms are outside the scope of this document. Implementation experimentation will be used to determine which cache management strategies work best. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 07:39:16 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95CA3A6936 for ; Wed, 30 Mar 2011 07:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cT-Z4J9FkSCi for ; Wed, 30 Mar 2011 07:39:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 308313A687D for ; Wed, 30 Mar 2011 07:39:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4wZo-0007sQ-Qs; Wed, 30 Mar 2011 07:40: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 14:40:52 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/112#comment:4 Message-ID: <065.89cee84d66cdd8b64a6b3534bff45afe@trac.tools.ietf.org> References: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #112: use of re-encapsulation is underspecified 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, 30 Mar 2011 14:39:16 -0000 #112: use of re-encapsulation is underspecified Changes (by terry.manderson@…): * priority: major => trivial * type: technical => editorial -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: editorial | Status: reopened Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From jnc@mercury.lcs.mit.edu Wed Mar 30 07:42:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5CD3A6989 for ; Wed, 30 Mar 2011 07:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+72QzsWBtJM for ; Wed, 30 Mar 2011 07:42:17 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B5A0D3A6936 for ; Wed, 30 Mar 2011 07:42:17 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3D87418C0FE; Wed, 30 Mar 2011 10:43:56 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110330144356.3D87418C0FE@mercury.lcs.mit.edu> Date: Wed, 30 Mar 2011 10:43:56 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #46: Cache Thrashing (review 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, 30 Mar 2011 14:42:18 -0000 > From: "Joel M. Halpern" > While I like the theory you advance, I don't know how to build it in > practice. What size memory .. should I build in my device to meet the > MUST? What you say is of course true, but at the same time, I don't think it invalidates my basic point, that the only way to prevent cache thrashing in an application like this is to have a 'big enough' cache? Is there any reason not to say that, even if we don't have a number to put in? As Dino says, this is true now, in many other places: e.g. BGP 'won't work' without a large enough RIB to hold the entire table, but I don't believe the size is in any document. > I presume there is already some data. The simulations I mentioned were driven by very large traces of actual traffic from several large sites. Everyone who is seriously interested in this issue should read those papers. > I do not see that the document needs to spell out all of the history of > our problems True, but if we agree that i) thrashing is an issue (and I think we do all agree on that), and ii) the only fix to thrashing is a large enough cache (so far, I hear no dissent on that), I think the document ought to say both of those. Noel From yakov@juniper.net Wed Mar 30 07:51:26 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108DA3A6A1F for ; Wed, 30 Mar 2011 07:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.403 X-Spam-Level: X-Spam-Status: No, score=-106.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3ljcMBBcDQXh for ; Wed, 30 Mar 2011 07:51:25 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 6F9E43A6983 for ; Wed, 30 Mar 2011 07:51:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTZNDyn1xTUnzBdr6lkV0rdArM5UzSDQD@postini.com; Wed, 30 Mar 2011 07:53:04 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 30 Mar 2011 07:49:52 -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 p2UEpMv24056; Wed, 30 Mar 2011 07:51:22 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103301451.p2UEpMv24056@magenta.juniper.net> To: Eliot Lear In-Reply-To: <4D92464E.1060101@cisco.com> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> <066.78965594e2a0942ac8660a75b80688ef@trac.tools.ietf.org> <201103291714.p2THEIv41513@magenta.juniper.net> <4D92464E.1060101@cisco.com> X-MH-In-Reply-To: Eliot Lear message dated "Tue, 29 Mar 2011 22:51:26 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46015.1301496682.1@juniper.net> Date: Wed, 30 Mar 2011 07:51:22 -0700 From: Yakov Rekhter Cc: lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review 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, 30 Mar 2011 14:51:26 -0000 Eliot, > Hi Yakov, > > > Here is the text that has been added: > > > > Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, > > cache sizing and maintenance is an issue to be kept in mind during > > implementation. It is a good idea to have instrumentation in place > > to detect thrashing of the cache. Implementation experimentation > > will be used to determine which cache management strategies work > > best. > > > > The above text failed to mention that cache sizing is an issue not > > just "during implementation", but during deployment as well. > > I agree with this point. I believe actually the change for the above > text is to change "Implementation experimentation" simply to > "Experimentation" or "Deployment experience". > > > Moreover, the above text failed to mention that in the context of > > LISP, thrashing of the cache on a given ITR/PTR has non-local > > implications, as it could result in excessive volume of LISP control > > traffic, which in turn would further deteriorate the situation. > > I agree with this concern. The degenerative case one could imagine is a > cache of 1 entry, in which case packets to every separate site would > generate queries, presumably through the ALT. However... > > > Finally, the above failed to mention that being able to > > detect thrasing is necessary, but not sufficient - an implementation > > must be able to suppress thrasing. > > I agree with this point. However, I would suggest a different set of text: > > Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, > and that undersized caches could cause excessive control traffic, > implementations MUST have some form of cache management in place. > The specific management mechanisms are beyond the scope of this > specification. The text you proposed above is insufficient as (a) it failed to mention that undersized caches could lead to cache thrashing, (b) cache thrashing, in addition to excessive control traffic, could also result in dropping data (thus negatively affecting connectivity), and (c) the detrimental effects of excessive control traffic due to thrashing could spread beyond the ITR/PTR that experiences thrashing. Moreover, saying that an implementation must has "some form of cache management in place" is insufficinet, as what is needed is not just "some form" of cache management, but a mechanism that would allow to suppress thrashing. With all this in mind I would propose to augment the text you proposed above with the missing points. Here is the revised text: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, undersized caches could cause cache thrasing. Cache thrasing could result in the ITR/PTR dropping data, thus negatively affecting connectivity for all the hosts that communicate through this ITR/PTR. Moreover, cache thrasing could cause excessive control traffic, which could spread the detrimental effects of thrasing beyond the ITR/PTR that experiences the thrasing. Therefore, an implementation MUST have some form of cache management in place that would provide suppression of cache thrasing. The specific management mechanisms are beyond the scope of this specification. Experimentation and deployment experience will be used to determine which cache management strategies work best. If folks think that "MUST" in the above should be replaced with "SHOULD" or "RECOMMENDED", it would be fine with me. Yakov. From jmh@joelhalpern.com Wed Mar 30 07:57:48 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211963A6AA0 for ; Wed, 30 Mar 2011 07:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.842 X-Spam-Level: X-Spam-Status: No, score=-101.842 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 YH9+hTXoID5v for ; Wed, 30 Mar 2011 07:57:47 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 794883A6983 for ; Wed, 30 Mar 2011 07:57:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9F4354300DF; Wed, 30 Mar 2011 07:59:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [130.129.38.181] (dhcp-26b5.meeting.ietf.org [130.129.38.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id C178443004E; Wed, 30 Mar 2011 07:59:24 -0700 (PDT) Message-ID: <4D934547.3070000@joelhalpern.com> Date: Wed, 30 Mar 2011 10:59:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 References: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> <065.6d6b508a6ee9fe869eb9b35aefadbbd3@trac.tools.ietf.org> In-Reply-To: <065.6d6b508a6ee9fe869eb9b35aefadbbd3@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] #115: claims in Section 7 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, 30 Mar 2011 14:57:48 -0000 As chairs, Terry and I concluded that whether or not the protocol actually achieves the design goal, that statement does reflect a design goal of the designers. As such, the text is a statement of fact. The authors have clarified the later text that did overclaim the actuality. Given that, we intend to reclose this ticket. Yours, Joel On 3/30/2011 10:19 AM, lisp issue tracker wrote: > #115: claims in Section 7 > > Changes (by yakov@…): > > * status: closed => reopened > * resolution: fixed => > > > Comment: > > -11 version still has the following: > > > LISP is designed to be very hardware-based forwarding friendly. > > In order to close this comment the above sentence should be deleted. > From trac+lisp@trac.tools.ietf.org Wed Mar 30 08:07:45 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523813A6B68 for ; Wed, 30 Mar 2011 08:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 S6uo55q2dg+P for ; Wed, 30 Mar 2011 08:07:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 993073A6847 for ; Wed, 30 Mar 2011 08:07:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4x1N-0000EB-9r; Wed, 30 Mar 2011 08:09: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 15:09:21 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/112#comment:5 Message-ID: <065.af6a87fd499510c6ed5cd60c70200bee@trac.tools.ietf.org> References: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #112: use of re-encapsulation is underspecified 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, 30 Mar 2011 15:07:45 -0000 #112: use of re-encapsulation is underspecified Changes (by terry.manderson@…): * status: reopened => resolved * resolution: => fixed Comment: As chairs, Joel and I concluded that what was said in the draft about re- encapsualtion was adequate for a an experimental draft and did not need to be expanded to provide an in-depth description of traffic engineering. This ticket will be re-closed. My previous comment about the possibility for another document that addresses such traffic engineering concerns remains. -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: editorial | Status: resolved Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 08:07:57 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D914C3A6B73 for ; Wed, 30 Mar 2011 08:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 6nhzBbhApEwf for ; Wed, 30 Mar 2011 08:07:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9B8D73A6B72 for ; Wed, 30 Mar 2011 08:07:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4x1Z-0000EK-0L; Wed, 30 Mar 2011 08:09: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 15:09:32 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/112#comment:6 Message-ID: <065.b8b90e1d2d9c605061e442643d09c618@trac.tools.ietf.org> References: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <056.844e8bfd2de0805b00809cf0ab07f538@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #112: use of re-encapsulation is underspecified 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, 30 Mar 2011 15:07:57 -0000 #112: use of re-encapsulation is underspecified Changes (by terry.manderson@…): * status: resolved => closed -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: editorial | Status: closed Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 08:13:36 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B393A6B28 for ; Wed, 30 Mar 2011 08:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 zdMse--QJ04C for ; Wed, 30 Mar 2011 08:13:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 050863A6A1F for ; Wed, 30 Mar 2011 08:13:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4x73-0000VK-Ew; Wed, 30 Mar 2011 08:15: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 15:15:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/115#comment:4 Message-ID: <065.c4d2b549f29f70e59efeea1957e998c1@trac.tools.ietf.org> References: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #115: claims in Section 7 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, 30 Mar 2011 15:13:36 -0000 #115: claims in Section 7 Changes (by terry.manderson@…): * status: reopened => resolved * resolution: => fixed -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 08:13:47 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743353A6B73 for ; Wed, 30 Mar 2011 08:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 WCjS33MVcksD for ; Wed, 30 Mar 2011 08:13:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 897FF28C10D for ; Wed, 30 Mar 2011 08:13:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4x7E-0000x1-6k; Wed, 30 Mar 2011 08:15: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 15:15:24 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/115#comment:5 Message-ID: <065.fad96df2bbd1ecade3230d56473eb30c@trac.tools.ietf.org> References: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <056.33f18b6fa8b89d823961d93f653ef51b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #115: claims in Section 7 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, 30 Mar 2011 15:13:47 -0000 #115: claims in Section 7 Changes (by terry.manderson@…): * status: resolved => closed -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 08:16:52 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9087C3A6B82 for ; Wed, 30 Mar 2011 08:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 g2YkN2XqcrTD for ; Wed, 30 Mar 2011 08:16:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D10583A6B80 for ; Wed, 30 Mar 2011 08:16:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4xAD-0001um-Od; Wed, 30 Mar 2011 08:18: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 15:18:29 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:5 Message-ID: <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #27: ETR may claim a larger prefix than is delegated to it 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, 30 Mar 2011 15:16:52 -0000 #27: ETR may claim a larger prefix than is delegated to it Comment(by yakov@…): If the base LISP spec is not going to have additional mechanisms to address over-claiming, then I would suggest to add to the base LISP spec some text that would just describe the issue of over-claiming, and state that handling this issue is outside the scope of the document. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Wed Mar 30 08:28:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF0F3A68B8 for ; Wed, 30 Mar 2011 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 IQe-rxHFPVGU for ; Wed, 30 Mar 2011 08:28:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 014D53A6B65 for ; Wed, 30 Mar 2011 08:28:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4xLI-0001fl-GF; Wed, 30 Mar 2011 08:29: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, yakov@juniper.net X-Trac-Project: lisp Date: Wed, 30 Mar 2011 15:29:56 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/55#comment:2 Message-ID: <066.90d4e691bbb60cf24be44823715469e3@trac.tools.ietf.org> References: <057.cfd7e4056637dce0c518d9d74eaa3c20@trac.tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <057.cfd7e4056637dce0c518d9d74eaa3c20@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #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 List-Id: 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, 30 Mar 2011 15:28:18 -0000 #55: ETR failure and its implications on connectivity restoration time (review by Y. Rekhter) Comment(by yakov@…): The text that has been added on path liveness, etc... does not address the issue raised in this ticket, namely that with LISP connectivity restoration requires to propagate fault information from ETR all the way to ITR. To address the issue raised in this ticket I would propose to add the following to section 6.3: Restoring connectivity in the presence of faults at ETRs requires propagating fault information from the ETRs to the ITRs. This is in contrast to the current IP routing system, where restoring connectivity could be accomplished with a fairly limited scope of propagating fault information. The implication of these differences are outside the scope of this document. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From lear@cisco.com Wed Mar 30 09:01:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5C23A6932 for ; Wed, 30 Mar 2011 09:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 1miPPlpMT05o for ; Wed, 30 Mar 2011 09:01:40 -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 D7EA83A6A20 for ; Wed, 30 Mar 2011 09:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1988; q=dns/txt; s=iport; t=1301500997; x=1302710597; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JLclsmcGAeRdjUKLFg7JrK3js1FO4nRYONlxQove1uM=; b=fr4jjVk9rieuUh1vnBL5b0W5SQteW0fA2xMst3K1pm3eH02LVNRjD10O Cn5lsHVxNCf5MnJauUZ3xNKsm8tYUfwFZAW+zfUlSxLxX7q5T5fMRXWtx gsnCEFtc9JGooJvOsGrNo3mc3wFbP0uXWxJnQy2MO/pipZzLbfq3bYReg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8DAK1Tk02Q/khMgWdsb2JhbACERqEMFAEBFiYliHmYF4s9kSSBJ4NMdwSNBg X-IronPort-AV: E=Sophos;i="4.63,269,1299456000"; d="scan'208";a="23823119" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 30 Mar 2011 16:03:16 +0000 Received: from dhcp-10-61-106-153.cisco.com (dhcp-10-61-106-153.cisco.com [10.61.106.153]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2UG3Gn0001538; Wed, 30 Mar 2011 16:03:16 GMT Message-ID: <4D93541E.7020404@cisco.com> Date: Wed, 30 Mar 2011 18:02:38 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yakov Rekhter References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> <066.78965594e2a0942ac8660a75b80688ef@trac.tools.ietf.org> <201103291714.p2THEIv41513@magenta.juniper.net> <4D92464E.1060101@cisco.com> <201103301451.p2UEpMv24056@magenta.juniper.net> In-Reply-To: <201103301451.p2UEpMv24056@magenta.juniper.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review 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, 30 Mar 2011 16:01:40 -0000 Hi Yakov, On 3/30/11 4:51 PM, Yakov Rekhter wrote: > >> Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, >> and that undersized caches could cause excessive control traffic, >> implementations MUST have some form of cache management in place. >> The specific management mechanisms are beyond the scope of this >> specification. > The text you proposed above is insufficient as (a) it failed to > mention that undersized caches could lead to cache thrashing, Rather than use the term "cache thrashing", I chose instead to describe the effects of undersized caches, which is another way of saying... cache thrashing. And it's a bit more descriptive. I would also argue that it is important to be concise. > (b) cache thrashing, in addition to excessive control traffic, > could also result in dropping data (thus negatively affecting > connectivity), I think the above text captures this as well. > and (c) the detrimental effects of excessive > control traffic due to thrashing could spread beyond the ITR/PTR > that experiences thrashing. Control traffic has to go somewhere, right? > Moreover, saying that an implementation must has "some form > of cache management in place" is insufficinet, as what is needed > is not just "some form" of cache management, but a mechanism > that would allow to suppress thrashing. Fair enough. How about the following then: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, and that undersized caches could cause excessive control traffic, implementations MUST have some form of cache management in place that prevents excessive network control traffic. The specific management mechanisms are beyond the scope of this specification. This also keeps things concise. I also understand that others may be uncomfortable about a normative MUST. I understand those concerns and have thrashed (cough) both ways about that myself. Eliot From jnc@mercury.lcs.mit.edu Wed Mar 30 09:20:41 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDF83A6A4C for ; Wed, 30 Mar 2011 09:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry75a8p0lLcJ for ; Wed, 30 Mar 2011 09:20:39 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 08D193A6B8C for ; Wed, 30 Mar 2011 09:20:38 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9D41A18C0FE; Wed, 30 Mar 2011 12:22:17 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110330162217.9D41A18C0FE@mercury.lcs.mit.edu> Date: Wed, 30 Mar 2011 12:22:17 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #46: Cache Thrashing (review 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, 30 Mar 2011 16:20:41 -0000 > From: Yakov Rekhter > an implementation MUST have some form of cache management in place > that would provide suppression of cache thrasing. Do you know of any cache management strategy which will achieve this goal _other_ than simply having a big enough cache? (Or is the answer to that question proprietary? :-) If not, why can't we just simply say that, and we can drop all the "The specific management mechanisms ... work best." stuff? Noel PS: Someone pointed out "Revisiting Route Caching: The World Should Be Flat" to me, which is a nice piece of work (although it misunderstands LISP); it makes the observation that LRU works a lot better than LFU as a discard selection mechanism. From dino@cisco.com Wed Mar 30 09:53:46 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E9A3A6B89 for ; Wed, 30 Mar 2011 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_72=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 noVQzyEgbYwc for ; Wed, 30 Mar 2011 09:53:45 -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 4DEE43A6A66 for ; Wed, 30 Mar 2011 09:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1621; q=dns/txt; s=iport; t=1301504124; x=1302713724; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=dy2SUKXCbP0klIc7Qe8DKysRAgdQlbMYslFSoJSpi9Q=; b=Vd2xT+VKMGrAOD60wUtoMp1Xua25pxJ1g2+Op4voFvZ+va0n9RyEd7NA kWLkYAQHs4po24yb6K6fxBFix1ujf3Mcj/JLQN5Mpii01OtQl7AX3plR8 ow33AEr3DniFColXco1BEA9HYEf2gbKzLiHT7Np5GrfNRuIp5ogSe6K+L Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFhfk02rRDoI/2dsb2JhbAClUnehP5xXhWoEhT+HRw X-IronPort-AV: E=Sophos;i="4.63,269,1299456000"; d="scan'208";a="421047681" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 30 Mar 2011 16:55:24 +0000 Received: from dhcp-1789.meeting.ietf.org (sjc-vpn4-1016.cisco.com [10.21.83.247]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2UGtMWY025892; Wed, 30 Mar 2011 16:55:23 GMT Message-Id: <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> From: Dino Farinacci To: "lisp issue tracker" In-Reply-To: <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> 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: Wed, 30 Mar 2011 09:55:21 -0700 References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 30 Mar 2011 16:53:46 -0000 We did in -11. Here is the text at the end of section 12. There is a potential security risk implicit in the fact that ETRs generate the EID prefix to which they are responding. In theory, an ETR can claim a shorter prefix than it is actually responsible for. Various mechanisms to ameliorate or resolve this issue will be examined in the future, [LISP-SEC]. Dino On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: > #27: ETR may claim a larger prefix than is delegated to it > > > Comment(by yakov@=85): > > If the base LISP spec is not going to have additional mechanisms to > address over-claiming, then I would suggest to add to the base LISP =20= > spec > some text that would just describe the issue of over-claiming, and =20 > state > that handling this issue is outside the scope of the document. > > --=20 > ----------------------------------=20 > +----------------------------------------- > Reporter: hartmans-ietf@=85 | Owner: > Type: technical | Status: resolved > Priority: major | Component: draft-ietf-lisp > Severity: - | Resolution: fixed > Keywords: | > ----------------------------------=20 > +----------------------------------------- > > Ticket URL: = > > lisp > LISP WG document issues > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From trac+lisp@trac.tools.ietf.org Wed Mar 30 22:45:56 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25C53A6C0C for ; Wed, 30 Mar 2011 22:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 BOZU9ta1KYxO for ; Wed, 30 Mar 2011 22:45:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1149128C16B for ; Wed, 30 Mar 2011 22:45:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q5Ai0-00034n-Vb; Wed, 30 Mar 2011 22:46: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.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, jmh@joelhalpern.com X-Trac-Project: lisp Date: Thu, 31 Mar 2011 05:46:16 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/13#comment:3 Message-ID: <066.0a1e1b475234b8070ac8a5c7bf478620@trac.tools.ietf.org> References: <057.75f89d1aeb61c057c11462433095816f@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <057.75f89d1aeb61c057c11462433095816f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, jmh@joelhalpern.com, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@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] #13: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires Analysis 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: Thu, 31 Mar 2011 05:45:57 -0000 #13: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires Analysis Changes (by jmh@…): * status: new => resolved * resolution: => fixed Comment: The working group has agreed to use 0 UDP checksums. The 6man working group is in the process of advancing documents which will define conditions under which this is acceptable. The documents have been reviewed, and the LISP usage meets those conditions. -- -------------------------------+-------------------------------------------- Reporter: mrw@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: UDP checksums | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From jesper@cisco.com Thu Mar 31 00:30:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870EA28C238 for ; Thu, 31 Mar 2011 00:30: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 BJNRJMZY2Zho for ; Thu, 31 Mar 2011 00:30:39 -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 54D5728C22F for ; Thu, 31 Mar 2011 00:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jesper@cisco.com; l=2741; q=dns/txt; s=iport; t=1301556737; x=1302766337; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Q6+erBFw4eOWiGsFRYK4n3Slu6xOlg2OfkachH6jrvs=; b=d6iJOWjFJxlYFQlvp4Ud6hgtvm6E4brPozY5qBFAeTC0vMdBGqHBFFVr WLx2Cf+NXCMYLb9qwMOrKjsMkxbgGgI66RT8avYzmAOli65A24gKgiQR5 pBmKJlkYAZar7mVGKk2LcSqOxH8xzHYAJuD8ayRz2DmB7MkuEHRpCRxjk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoDAKotlE2Q/khNgWdsb2JhbAClTxQBARYmJYh5mWqcAoVrBIU7h1aDVQ X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="23897697" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 31 Mar 2011 07:32:02 +0000 Received: from [127.0.0.1] (gpk-lds-001.cisco.com [64.103.78.6]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2V7W2I9011129; Thu, 31 Mar 2011 07:32:02 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jesper Skriver In-Reply-To: <3D246EAF-2824-4BED-A817-95A812201C44@uclouvain.be> Date: Thu, 31 Mar 2011 10:32:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7509D007-4701-4ADF-BC36-559E6C29EF03@cisco.com> References: <3D246EAF-2824-4BED-A817-95A812201C44@uclouvain.be> To: Damien Saucez X-Mailer: Apple Mail (2.1082) Cc: lisp@ietf.org Subject: Re: [lisp] Versioning, I don't think we need to disable source versioning when we have no destination version. 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, 31 Mar 2011 07:30:40 -0000 Hi Damien, On 30 Mar 2011, at 14:49, Damien Saucez wrote: > Hello, >=20 > On 30 Mar 2011, at 13:41, Jesper Skriver wrote: >=20 >> Luigi, >>=20 >> draft-ietf-lisp-map-versioning-01 section 4.1 reads >>=20 >> The other use of the Null Map-Version number is in the Map Records, >> which are part of the Map-Request, Map-Reply and Map-Register >> messages (defined in [I-D.ietf-lisp]). Map Records that have a Null >> Map-Version number indicate that there is no Map-Version number >> associated with the mapping. This means that LISP encapsulated >> packets, destined to the EID-Prefix the Map Record refers to, MUST >> NOT contain Map-Version numbers (i.e., V bit MUST always be 0). In >> other words, the Null Map-Version number signals to the ITR using = the >> mapping that the Map-Versioning is not supported, or even if >> supported it MUST NOT be used for that specific EID-Prefix. Any >> value different from zero means that Map-Versioning is supported and >> MAY be used. >>=20 >> I think that the use of "MUST NOT" is too strict here, even if an ETR = returned a Null Map-Version number in a Map Record to an ITR, there is = still value in using source versioning for traffic from the ITR to the = ETR. The ETR may be able to check the source version number, and use = versioning to update the reverse mapping. >>=20 >> So I suggest changing this text to >>=20 >> The other use of the Null Map-Version number is in the Map Records, >> which are part of the Map-Request, Map-Reply and Map-Register >> messages (defined in [I-D.ietf-lisp]). Map Records that have a Null >> Map-Version number indicate that there is no Map-Version number >> associated with the mapping. This means that LISP encapsulated >> packets, destined to the EID-Prefix the Map Record refers to, MUST >> either not contain any Map-Version numbers (V bit set to 0), or if >> it contains Map-Version numbers (V bit set to 1) then the = destination >> Map-Version number MUST be set to the Null Map-Version number. >>=20 >=20 > Ok, but before we have to check what it means for security I don't think it should have any effect on security. If the ETR doesn't support versioning, it will ignore the version in the = LISP header regardless if the V bit is set or not. If the ETR does support versioning, it MAY verify that it has an up to = date reverse mapping by checking the source version number in the LISP = header against what it got cached. /Jesper >=20 > Damien Saucez >=20 >> /Jesper >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp /Jesper From luigi@net.t-labs.tu-berlin.de Thu Mar 31 02:12:01 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8F128C1C4 for ; Thu, 31 Mar 2011 02:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pd+bwFrePcqx for ; Thu, 31 Mar 2011 02:12:00 -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 61D4828C108 for ; Thu, 31 Mar 2011 02:12:00 -0700 (PDT) Received: from dhcp-26f4.meeting.ietf.org (dhcp-26f4.meeting.ietf.org [130.129.38.244]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id D76D87000204; Thu, 31 Mar 2011 11:13:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: <7509D007-4701-4ADF-BC36-559E6C29EF03@cisco.com> Date: Thu, 31 Mar 2011 11:13:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <560A33AD-F615-43AF-B2FB-53C86BE9E4D5@net.t-labs.tu-berlin.de> References: <3D246EAF-2824-4BED-A817-95A812201C44@uclouvain.be> <7509D007-4701-4ADF-BC36-559E6C29EF03@cisco.com> To: Jesper Skriver X-Mailer: Apple Mail (2.1084) Cc: lisp@ietf.org Subject: Re: [lisp] Versioning, I don't think we need to disable source versioning when we have no destination version. 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, 31 Mar 2011 09:12:02 -0000 Hi Jesper, As I said during the presentation, we ourselves were suspecting of = being too restrictive.=20 On the security side, I do not think there is any issue. If the ETR = does not support versioning there is no attack that can be mounted with = allowing to send the source map version. If the ETR does support = versioning and decides to verify the source map version, then we are in = normal map-version use case and existing security consideration apply. Thanks you very much for proposing text. Luigi On 31, Mar, 2011, at 9:32 , Jesper Skriver wrote: > Hi Damien, >=20 > On 30 Mar 2011, at 14:49, Damien Saucez wrote: >=20 >> Hello, >>=20 >> On 30 Mar 2011, at 13:41, Jesper Skriver wrote: >>=20 >>> Luigi, >>>=20 >>> draft-ietf-lisp-map-versioning-01 section 4.1 reads >>>=20 >>> The other use of the Null Map-Version number is in the Map Records, >>> which are part of the Map-Request, Map-Reply and Map-Register >>> messages (defined in [I-D.ietf-lisp]). Map Records that have a Null >>> Map-Version number indicate that there is no Map-Version number >>> associated with the mapping. This means that LISP encapsulated >>> packets, destined to the EID-Prefix the Map Record refers to, MUST >>> NOT contain Map-Version numbers (i.e., V bit MUST always be 0). In >>> other words, the Null Map-Version number signals to the ITR using = the >>> mapping that the Map-Versioning is not supported, or even if >>> supported it MUST NOT be used for that specific EID-Prefix. Any >>> value different from zero means that Map-Versioning is supported and >>> MAY be used. >>>=20 >>> I think that the use of "MUST NOT" is too strict here, even if an = ETR returned a Null Map-Version number in a Map Record to an ITR, there = is still value in using source versioning for traffic from the ITR to = the ETR. The ETR may be able to check the source version number, and use = versioning to update the reverse mapping. >>>=20 >>> So I suggest changing this text to >>>=20 >>> The other use of the Null Map-Version number is in the Map Records, >>> which are part of the Map-Request, Map-Reply and Map-Register >>> messages (defined in [I-D.ietf-lisp]). Map Records that have a Null >>> Map-Version number indicate that there is no Map-Version number >>> associated with the mapping. This means that LISP encapsulated >>> packets, destined to the EID-Prefix the Map Record refers to, MUST >>> either not contain any Map-Version numbers (V bit set to 0), or if >>> it contains Map-Version numbers (V bit set to 1) then the = destination >>> Map-Version number MUST be set to the Null Map-Version number. >>>=20 >>=20 >> Ok, but before we have to check what it means for security >=20 > I don't think it should have any effect on security. >=20 > If the ETR doesn't support versioning, it will ignore the version in = the LISP header regardless if the V bit is set or not. >=20 > If the ETR does support versioning, it MAY verify that it has an up to = date reverse mapping by checking the source version number in the LISP = header against what it got cached. >=20 > /Jesper >=20 >>=20 >> Damien Saucez >>=20 >>> /Jesper >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >=20 > /Jesper >=20 >=20 >=20 >=20 From yakov@juniper.net Thu Mar 31 08:10:25 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B677C3A69BE for ; Thu, 31 Mar 2011 08:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.109 X-Spam-Level: X-Spam-Status: No, score=-106.109 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 Yynwivgei3Gm for ; Thu, 31 Mar 2011 08:10:24 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id A1E2728C0FA for ; Thu, 31 Mar 2011 08:10:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTZSZvBT974U046YOQK98csqoRCZzaqNj@postini.com; Thu, 31 Mar 2011 08:12:04 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 31 Mar 2011 08:09:42 -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 p2VFBFv39780; Thu, 31 Mar 2011 08:11:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103311511.p2VFBFv39780@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Wed, 30 Mar 2011 09:55:21 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <3399.1301584275.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 08:11:15 -0700 From: Yakov Rekhter Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 31 Mar 2011 15:10:25 -0000 Dino, > We did in -11. Here is the text at the end of section 12. > = > There is a potential security risk implicit in the fact that ETRs > generate the EID prefix to which they are responding. In theory, an > ETR can claim a shorter prefix than it is actually responsible for. > Various mechanisms to ameliorate or resolve this issue will be > examined in the future, [LISP-SEC]. The text should elaborate a bit on what is exactly the "potential security risk", and specifically what are some of the implications of that risk. Also, replace "In theory" with "Thus" (as the ETR can do this not just "in theory", but in practice as well). = Yakov. > = > Dino > = > On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: > = > > #27: ETR may claim a larger prefix than is delegated to it > > > > > > Comment(by yakov@=85): > > > > If the base LISP spec is not going to have additional mechanisms to > > address over-claiming, then I would suggest to add to the base LISP = > > spec > > some text that would just describe the issue of over-claiming, and = > > state > > that handling this issue is outside the scope of the document. > > > > -- = > > ---------------------------------- = > > +----------------------------------------- > > Reporter: hartmans-ietf@=85 | Owner: > > Type: technical | Status: resolved > > Priority: major | Component: draft-ietf-lisp > > Severity: - | Resolution: fixed > > Keywords: | > > ---------------------------------- = > > +----------------------------------------- > > > > Ticket URL: > > > > lisp > > LISP WG document issues > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > = > = From dino@cisco.com Thu Mar 31 08:22:43 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58443A6B0E for ; Thu, 31 Mar 2011 08:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.184 X-Spam-Level: X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_72=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 lvQhIx4jsruP for ; Thu, 31 Mar 2011 08:22:42 -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 12E453A6AD7 for ; Thu, 31 Mar 2011 08:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2200; q=dns/txt; s=iport; t=1301585062; x=1302794662; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=glcVRXSkAgHD9ZnSUdrhzJuG/8k9bN+SoRVdTOpmSwU=; b=IdRgxPnK3Z4n+OdwYOIny9/cty6J6WGe6rlYxPPy9YglgVuDCKiiIyBw WmdaS36SR4hCoU6ysLPC4u0UBHZmG1bGf4+1zGmcCppDJ8SmG6/hngOoE FXz4N/2roy59RM1myPG2lM/9SJ9n6pCk4G1QnX2SMcb027+SGkQCwIwsG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGiclE2rRDoJ/2dsb2JhbAClTXeIeZo5nB2FawSFQYdQ X-IronPort-AV: E=Sophos;i="4.63,276,1299456000"; d="scan'208";a="673834505" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2011 15:24:21 +0000 Received: from dhcp-1789.meeting.ietf.org ([10.21.71.191]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2VFOJMb006821; Thu, 31 Mar 2011 15:24:20 GMT Message-Id: <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201103311511.p2VFBFv39780@magenta.juniper.net> 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, 31 Mar 2011 08:24:19 -0700 References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 31 Mar 2011 15:22:43 -0000 > Dino, > >> We did in -11. Here is the text at the end of section 12. >> >> There is a potential security risk implicit in the fact that ETRs >> generate the EID prefix to which they are responding. In =20 >> theory, an >> ETR can claim a shorter prefix than it is actually responsible =20 >> for. >> Various mechanisms to ameliorate or resolve this issue will be >> examined in the future, [LISP-SEC]. > > The text should elaborate a bit on what is exactly the "potential > security risk", and specifically what are some of the implications > of that risk. "ETR can claim a shorter prefix than it is actually responsible for". > Also, replace "In theory" with "Thus" (as the ETR can do this not just > "in theory", but in practice as well). In practice the implementation test mask-lengths and don't install =20 coarse routes. Dino > > Yakov. > >> >> Dino >> >> On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: >> >>> #27: ETR may claim a larger prefix than is delegated to it >>> >>> >>> Comment(by yakov@=85): >>> >>> If the base LISP spec is not going to have additional mechanisms to >>> address over-claiming, then I would suggest to add to the base LISP >>> spec >>> some text that would just describe the issue of over-claiming, and >>> state >>> that handling this issue is outside the scope of the document. >>> >>> --=20 >>> ---------------------------------- >>> +----------------------------------------- >>> Reporter: hartmans-ietf@=85 | Owner: >>> Type: technical | Status: resolved >>> Priority: major | Component: draft-ietf-lisp >>> Severity: - | Resolution: fixed >>> Keywords: | >>> ---------------------------------- >>> +----------------------------------------- >>> >>> Ticket URL: = >> :5 >>>> >>> lisp >>> LISP WG document issues >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >>