From vaf@cisco.com Mon Oct 4 09:21:38 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19693A7006 for ; Mon, 4 Oct 2010 09:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.134 X-Spam-Level: X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 a5jg5q52RDOW for ; Mon, 4 Oct 2010 09:21:38 -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 D52F73A7003 for ; Mon, 4 Oct 2010 09:21:37 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALucqUyrR7Hu/2dsb2JhbACiQ3GoMJwXhUcEhFE X-IronPort-AV: E=Sophos;i="4.57,279,1283731200"; d="scan'208";a="282701667" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 04 Oct 2010 16:22:28 +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 o94GMSTr010635; Mon, 4 Oct 2010 16:22:28 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 4239481006A; Mon, 4 Oct 2010 09:22:28 -0700 (PDT) Date: Mon, 4 Oct 2010 09:22:28 -0700 From: Vince Fuller To: Terry Manderson Message-ID: <20101004162227.GA52229@vaf-mac1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] IETF 79 request for agenda items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:21:38 -0000 On Mon, Sep 27, 2010 at 10:42:45PM -0700, Terry Manderson wrote: > Folks, > > Co-chair beret safely covering my receding hair line. > > It is again the time that we start to consider the Beijing IETF 79 even > though the preliminary agenda won't be released until mid next week. Hi Terry- The draft-ietf-lisp and draft-ietf-lisp-ms co-authors have identified a number of cases where it would be really helpful to have acknowledgement of Map-Register messages. To that end, we propose to add a new message type, called Map-Notify, that will add this capability. Can we have 15 minutes on the agenda for this? Thanks, --Vince (for other the draft co-authors, Dino, Dave, and Darrel) From jnc@mercury.lcs.mit.edu Tue Oct 5 08:08:16 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B060A3A6CAA for ; Tue, 5 Oct 2010 08:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.536, 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 IiPZ3wASaKHm for ; Tue, 5 Oct 2010 08:08:15 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id D24C83A6C7A for ; Tue, 5 Oct 2010 08:08:15 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 778376BE567; Tue, 5 Oct 2010 11:09:13 -0400 (EDT) To: lisp@ietf.org Message-Id: <20101005150913.778376BE567@mercury.lcs.mit.edu> Date: Tue, 5 Oct 2010 11:09:13 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] IETF 79 request for agenda items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 15:08:16 -0000 > From: Vince Fuller > we propose to add a new message type, called Map-Notify, that will add > this capability. To add to the information base for this decision, how many implementations are there which this will impact? I gather the OpenLISP implementation is no longer being maintained, and I further gather that the one Margaret was working on is no longer under development? Are there any others out there at the moment - at least, which people can talk about openly? Noel From luigi@net.t-labs.tu-berlin.de Tue Oct 5 09:39:59 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE253A6F59 for ; Tue, 5 Oct 2010 09:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.465, 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 dF+ATq2l0xwy for ; Tue, 5 Oct 2010 09:39: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 1C2573A6F8D for ; Tue, 5 Oct 2010 09:39:54 -0700 (PDT) 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 170D4700FB5E; Tue, 5 Oct 2010 18:40:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: <20101005150913.778376BE567@mercury.lcs.mit.edu> Date: Tue, 5 Oct 2010 18:40:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0ECDB601-70E9-4C2A-8A3F-FBBEDBEFA8D6@net.t-labs.tu-berlin.de> References: <20101005150913.778376BE567@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1081) Cc: lisp@ietf.org Subject: Re: [lisp] IETF 79 request for agenda items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 16:39:59 -0000 Hi, On Oct 5, 2010, at 17:09 , Noel Chiappa wrote: >> From: Vince Fuller >=20 >> we propose to add a new message type, called Map-Notify, that will = add >> this capability. >=20 > To add to the information base for this decision, how many = implementations > are there which this will impact? I gather the OpenLISP implementation = is no > longer being maintained, Not really. Since monday there is a new release of OpenLISP, just check: http://www.openlisp.org There is no mapping capabilities in the user space, but Lorand Jakab = (that already added v6 support to LIG) is working on that. Hence future releases will include lisp-ms features. Coming to the Map-Notify issue, I do not think that will be a big = problem to add this message. Luigi > and I further gather that the one Margaret was > working on is no longer under development? Are there any others out = there at > the moment - at least, which people can talk about openly? >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Tue Oct 5 09:50:44 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5778F3A6F79 for ; Tue, 5 Oct 2010 09:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.498, 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 iEIcoOf60-bx for ; Tue, 5 Oct 2010 09:50:43 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3B5A63A6F97 for ; Tue, 5 Oct 2010 09:50:20 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B2D086BE567; Tue, 5 Oct 2010 12:51:17 -0400 (EDT) To: lisp@ietf.org Message-Id: <20101005165117.B2D086BE567@mercury.lcs.mit.edu> Date: Tue, 5 Oct 2010 12:51:17 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] IETF 79 request for agenda items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 16:50:44 -0000 > From: Luigi Iannone >> I gather the OpenLISP implementation is no longer being maintained, > Not really. Since monday there is a new release of OpenLISP Ah, sorry, out of date information! Good to hear this.... Noel From hannu.flinck@nsn.com Thu Oct 7 09:28:08 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938DB3A6F74 for ; Thu, 7 Oct 2010 09:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-bWjI0GEsUl for ; Thu, 7 Oct 2010 09:28:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 2FD5B3A6CE4 for ; Thu, 7 Oct 2010 09:28:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o97GT9IF005275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 7 Oct 2010 18:29:09 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o97GT8gP028703 for ; Thu, 7 Oct 2010 18:29:09 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 18:28:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Oct 2010 19:28:53 +0300 Message-ID: <26E5D1C5D5365D47B147E5E62FC73585017F680F@FIESEXC035.nsn-intra.net> In-Reply-To: <4CA23B63.2050907@ac.upc.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Fwd: New Version Notification fordraft-jakab-lisp-deployment-00 Thread-Index: ActfP8YDwTCpIDQmRJChbcoX96CxkwG+d62A References: <4CA23B63.2050907@ac.upc.edu> From: "Flinck, Hannu (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 07 Oct 2010 16:28:54.0544 (UTC) FILETIME=[BBD32900:01CB663C] Subject: Re: [lisp] Fwd: New Version Notification fordraft-jakab-lisp-deployment-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:28:08 -0000 Hello Lorand, Thank you for a good draft that is comes for a clear need. I read the = draft with an interest. I have the following questions though. I am wondering why do you say in section 3.1.2 that colocating P-ITR = with the site's tunnel routers causes the downside of no decrease in = global DFZ state? Shouldn't P-ITR announce "certain aggregated EID = prefixes" as you write in section 3.1. Then, how is it that colocating = the P-ITRs with the xTRs will cause the down side. Or do you suggest = that the P-ITRs will start to advertise more specifics of EIDs when = colocated? And why would they do that? Shouldn't they announce EIDs at = level of the site they are colocated. Would here the techniques = described in section 2.4 be useful, i.e. apply LISP recursively if a = packet gets misrouted? =20 A second thing that strikes me is the emphasis on the role of CDNs. I = can see that CDNs might easily take a role in offering a mapping system = service, but for packet routing I'm not sure. DNS-based request routing = of CDNs is closer to mapping system functionality than P-ITR = functionality that needs packet routing based on BGP routing tables and = of course advertising "certain aggregated EID prefixes" into BGP core. Best regards Hannu=20 >-----Original Message----- >From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 >Behalf Of ext Lor=E1nd Jakab >Sent: Tuesday, September 28, 2010 22:01 >To: lisp@ietf.org >Subject: [lisp] Fwd: New Version Notification=20 >fordraft-jakab-lisp-deployment-00 > > > FYI. > >-------- Original Message -------- >Subject: New Version Notification for=20 >draft-jakab-lisp-deployment-00 >Date: Tue, 28 Sep 2010 11:48:22 -0700 (PDT) >From: IETF I-D Submission Tool >To: ljakab@ac.upc.edu >CC: acabello@ac.upc.edu, fcoras@ac.upc.edu,=20 >jordi.domingo@ac.upc.edu, >darlewis@cisco.com > > > >A new version of I-D, draft-jakab-lisp-deployment-00.txt has=20 >been successfully submitted by Lorand Jakab and posted to the=20 >IETF repository. > >Filename: draft-jakab-lisp-deployment >Revision: 00 >Title: LISP Network Element Deployment Considerations >Creation_date: 2010-09-28 >WG ID: Independent Submission >Number_of_pages: 16 > >Abstract: >This document discusses the different scenarios in which the=20 >LISP protocol may be deployed. Changes or extensions to other=20 >protocols needed by some of the scenarios are also highlighted. > =20 > =20 > > >The IETF Secretariat. > > > >_______________________________________________ >lisp mailing list >lisp@ietf.org >https://www.ietf.org/mailman/listinfo/lisp > From ljakab@ac.upc.edu Fri Oct 8 03:06:57 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5899E3A682F for ; Fri, 8 Oct 2010 03:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pme5yPCAyN8M for ; Fri, 8 Oct 2010 03:06:56 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by core3.amsl.com (Postfix) with ESMTP id DACA43A6826 for ; Fri, 8 Oct 2010 03:06:55 -0700 (PDT) Received: from [130.149.220.102] (unknown [130.149.220.102]) by gw.ac.upc.edu (Postfix) with ESMTP id 9A9CF6B02CA; Fri, 8 Oct 2010 12:07:58 +0200 (CEST) Message-ID: <4CAEED7E.9010504@ac.upc.edu> Date: Fri, 08 Oct 2010 12:07:58 +0200 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTech MIME-Version: 1.0 To: LISP WG References: <4CA23B63.2050907@ac.upc.edu> <26E5D1C5D5365D47B147E5E62FC73585017F680F@FIESEXC035.nsn-intra.net> In-Reply-To: <26E5D1C5D5365D47B147E5E62FC73585017F680F@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [lisp] Fwd: New Version Notification for draft-jakab-lisp-deployment-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 10:06:57 -0000 Hi Hannu, Many thanks for the feedback. See my replies inline. On 10/07/2010 06:28 PM, Flinck, Hannu (NSN - FI/Espoo) wrote: > Hello Lorand, > > Thank you for a good draft that is comes for a clear need. I read the draft with an interest. I have the following questions though. > > I am wondering why do you say in section 3.1.2 that colocating P-ITR with the site's tunnel routers causes the downside of no decrease in global DFZ state? Shouldn't P-ITR announce "certain aggregated EID prefixes" as you write in section 3.1. Suppose ISP1 has two stub AS clients C1 and C2 which have adjacent old PI address space (or new EID address space) that can be aggregated. Additionally, these clients are multihomed, with connectivity from ISP2 as well. Before migrating to LISP, both prefixes are present in the DFZ with their respective originating ASNs. Suppose both sites migrate LISP, and ISP1 offers them P-ITR service. Now the P-ITR can announce the aggregate, with ISP1's ASN, and we have a decrease in DFZ. Both C1 and C2 are still multihomed and receive traffic from other LISP sites through either ISP1 or ISP2 depending on their TE policy in the EID-to-RLOC mappings, but traffic from non-LISP sites has to transit ISP1, unless ISP2 also deploys P-ITR. It would still enter the client site on the ISP2 link, but ISP1 may not like the extra traffic, so especially in the early days of LISP deployment may not have strong incentives to deploy a P-ITR. This leads us to the solution in Section 3.1.2. > Then, how is it that colocating the P-ITRs with the xTRs will cause the down side. Or do you suggest that the P-ITRs will start to advertise more specifics of EIDs when colocated? And why would they do that? Shouldn't they announce EIDs at level of the site they are colocated. Continuing the previous example, if P-ITRs are deployed at C1 and C2, the original PI prefixes (or new EID prefixes) have to be announced separately, resulting in no decrease in the DFZ. So what I meant is not that they will disaggregate more, rather, they maintain the status quo. > Would here the techniques described in section 2.4 be useful, i.e. apply LISP recursively if a packet gets misrouted? What do you mean by the packet being misrouted? > A second thing that strikes me is the emphasis on the role of CDNs. I can see that CDNs might easily take a role in offering a mapping system service, but for packet routing I'm not sure. DNS-based request routing of CDNs is closer to mapping system functionality than P-ITR functionality that needs packet routing based on BGP routing tables and of course advertising "certain aggregated EID prefixes" into BGP core. Well, my point here was that if a CDN can get enough stub AS clients for its P-ITR service, which is completely orthogonal to the CDN service, the chances of prefix aggregation increase. For each CDN there would be a single (ever decreasing) set of prefixes in the DFZ, announced from each of the high number of geographically well distributed P-ITRs. The result is that any non-LISP site trying to reach on of the CDN's LISP clients would be able to do so with minimum path stretch. As I mentioned above, this is not actually related with the CDN service per se. I suggested CDNs, because they already have the necessary infrastructure (presence and connectivity in many PoPs, except the P-ITR routers) to get into this business. Any organization that could gain something from this scenario could do this (e.g., a large web search provider, with a similarly well distributed infrastructure), but I singled out CDNs, because they have a head start. I hope this answers your questions. Do you think more clarifying text would be needed? Best regards, -Lori > Best regards > Hannu > >> -----Original Message----- >> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On >> Behalf Of ext Loránd Jakab >> Sent: Tuesday, September 28, 2010 22:01 >> To: lisp@ietf.org >> Subject: [lisp] Fwd: New Version Notification >> fordraft-jakab-lisp-deployment-00 >> >> >> FYI. >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-jakab-lisp-deployment-00 >> Date: Tue, 28 Sep 2010 11:48:22 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: ljakab@ac.upc.edu >> CC: acabello@ac.upc.edu, fcoras@ac.upc.edu, >> jordi.domingo@ac.upc.edu, >> darlewis@cisco.com >> >> >> >> A new version of I-D, draft-jakab-lisp-deployment-00.txt has >> been successfully submitted by Lorand Jakab and posted to the >> IETF repository. >> >> Filename: draft-jakab-lisp-deployment >> Revision: 00 >> Title: LISP Network Element Deployment Considerations >> Creation_date: 2010-09-28 >> WG ID: Independent Submission >> Number_of_pages: 16 >> >> Abstract: >> This document discusses the different scenarios in which the >> LISP protocol may be deployed. Changes or extensions to other >> protocols needed by some of the scenarios are also highlighted. >> >> >> >> >> The IETF Secretariat. >> >> >> >> _______________________________________________ >> 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 ldunbar@huawei.com Tue Oct 5 17:49:34 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73FF3A70A4 for ; Tue, 5 Oct 2010 17:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JlkTjDGAt42 for ; Tue, 5 Oct 2010 17:49:32 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 16F343A6D87 for ; Tue, 5 Oct 2010 17:49:32 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9U0066AFO6GL@usaga01-in.huawei.com> for lisp@ietf.org; Tue, 05 Oct 2010 17:50:30 -0700 (PDT) Received: from L735042 (72-254-58-12.client.stsn.net [72.254.58.12]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9U00EECFO2IJ@usaga01-in.huawei.com> for lisp@ietf.org; Tue, 05 Oct 2010 17:50:30 -0700 (PDT) Date: Tue, 05 Oct 2010 19:50:37 -0500 From: Linda Dunbar To: lisp@ietf.org Message-id: <00bd01cb64f0$8037a490$cc03400a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_ZY4/c8ncJpGgabXiW9fkUA)" Thread-index: Actk8H3cUZo1ujXNRhm8VAXl7OE6JQ== X-Mailman-Approved-At: Sat, 09 Oct 2010 18:27:11 -0700 Subject: [lisp] Is LISP specifying a mechanizm to encapsulate an outer IP header over IP frame? 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, 06 Oct 2010 00:49:34 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ZY4/c8ncJpGgabXiW9fkUA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Reading through the "draft-ietf-list-08", I get the impression that LISP is very much like IEEE802.1ah MAC-in-MAC, i.e. specifying a mechanism for a gateway router (i.e. ITR) to encapsulate an outer IP header over an IP data frame and ETR to decapsulate the outer IP header. Is my understanding correct? Is there anything I missed? Appreciate some experts in the group to help me out. Thank you in advance. Linda Dunbar --Boundary_(ID_ZY4/c8ncJpGgabXiW9fkUA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Reading through the “draft-ietf-list-08”, I get the impression that LISP is very much like IEEE802.1ah MAC-in-MAC, i.e. specifying a mechanism for a gateway router (i.e. ITR) to encapsulate an outer IP header over an IP data frame and ETR to decapsulate the outer IP header.

 

Is my understanding correct? Is there anything I missed?

 

Appreciate some experts in the group to help me out.

 

Thank you in advance.

 

Linda Dunbar

--Boundary_(ID_ZY4/c8ncJpGgabXiW9fkUA)-- From jnc@mercury.lcs.mit.edu Sun Oct 10 06:16:31 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00F13A67F0 for ; Sun, 10 Oct 2010 06:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.437 X-Spam-Level: X-Spam-Status: No, score=-5.437 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJibR3gjBh9D for ; Sun, 10 Oct 2010 06:16:30 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id A08F33A67EE for ; Sun, 10 Oct 2010 06:16:30 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6F6716BE592; Sun, 10 Oct 2010 09:17:39 -0400 (EDT) To: lisp@ietf.org Message-Id: <20101010131739.6F6716BE592@mercury.lcs.mit.edu> Date: Sun, 10 Oct 2010 09:17:39 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Is LISP specifying a mechanizm to encapsulate an outer IP header over IP frame? 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, 10 Oct 2010 13:16:32 -0000 > From: Linda Dunbar > I get the impression that LISP is ... specifying a mechanism for a > gateway router (i.e. ITR) to encapsulate an outer IP header over an IP > data frame and ETR to decapsulate the outer IP header. > Is my understanding correct? Is there anything I missed? Well, it's correct so far as it goes, but it's very incomplete: it's rather like saying that an airplane is a device for burning fuel and creating thrust. Yeah, that's part of the picture (and a key part), but there's a lot more to it than that, like wings, etc (and we're also leaving out the _point_ of the whole effort, which is to move stuff around through the air). The architectural goal of LISP is to start to separate location and identity, for a whole host of reasons: things like provider independence, multi-homing, etc, etc. The overall way it does that is to interpose between the communicating hosts a cloud of boxes (the xTRs) whose job it is to i) augment the semantics of the packets emitted by hosts (which contain names from only one namespace, the LEIDS), and augment them with a second (the RLOCs), and ii) get those packets to the appropriate ETR, which can send it on the actual destination. The mechanisms it uses to do all this can be divided into two groups which match the division above: i) the stuff which, given an LEID, produces the appropriate RLOC, and ii) the stuff needed to succesfully gets packets from an ITR to an ETR. The second part of this is more work than it may look, because what LISP effectively does is create a new packet-switching layer on top of existing one, and so ITR-ETR communication runs into a lot of the 'classical' problems of packet switching: e.g. figuring out if the next-hop box is alive, etc, etc. And the fact that the fan-out (i.e. number of ITR-ETR links for any given xTR) is _much_ higher than in any classical packet-switching network makes this a considerably harder job, since a lot of the mechanisms used to do this in, e.g. OSPF, don't scale to a fan-out of thousands. Not that the first is not simple either - the system for finding and maintaining {LEID -> RLOC} bindings has to be efficient, secure and robust, and that means dealing with a host of issues, e.g. finding out when a binding which an ITR has cached has been superseded by a changed version. Etc, etc, etc... Noel From root@core3.amsl.com Mon Oct 11 12:30:24 2010 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DEF2A3A6B2B; Mon, 11 Oct 2010 12:30:22 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101011193022.DEF2A3A6B2B@core3.amsl.com> Date: Mon, 11 Oct 2010 12:30:22 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-09.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, 11 Oct 2010 19:30:24 -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-09.txt Pages : 80 Date : 2010-10-11 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-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-11122041.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 11 21:45:02 2010 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C67EA3A68C4; Mon, 11 Oct 2010 21:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012044501.C67EA3A68C4@core3.amsl.com> Date: Mon, 11 Oct 2010 21:45:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-lig-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: Tue, 12 Oct 2010 04:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Internet Groper (LIG) Author(s) : D. Farinacci, D. Meyer Filename : draft-ietf-lisp-lig-01.txt Pages : 18 Date : 2010-10-11 A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-lig-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-lig-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-11213934.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 11 21:45:02 2010 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5825D3A68C0; Mon, 11 Oct 2010 21:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012044502.5825D3A68C0@core3.amsl.com> Date: Mon, 11 Oct 2010 21:45:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-multicast-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 04:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP for Multicast Environments Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-multicast-04.txt Pages : 36 Date : 2010-10-11 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-multicast-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-11214111.I-D@ietf.org> --NextPart-- From jmh@joelhalpern.com Wed Oct 13 10:03:52 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B3B3A6876 for ; Wed, 13 Oct 2010 10:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.544 X-Spam-Level: X-Spam-Status: No, score=-101.544 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znOJWrB6Wi9G for ; Wed, 13 Oct 2010 10:03:51 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7D7C23A6AAF for ; Wed, 13 Oct 2010 10:03:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id BF3A43228BC7 for ; Wed, 13 Oct 2010 10:05:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [42.0.4.63] (unknown [129.174.97.34]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 87E8E3228384 for ; Wed, 13 Oct 2010 10:05:08 -0700 (PDT) Message-ID: <4CB5E6C2.1020601@joelhalpern.com> Date: Wed, 13 Oct 2010 13:05:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Deployment Document - P-ITR 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, 13 Oct 2010 17:03:52 -0000 First, my thanks to the document authors for getting a document together for us. Speaking purely as an individual participant, I would like to see a lot more discussion in the P-ITR section. In general, I am concerned about the costs and incentives for deploying P-ITRs. Some examples of where I am confused: One suggested deployment is that EID registars might run P-ITRs. At first glance this seems understandable. But I do not understand how the operational costs line up with the revenue. As an individual customer increases their usage of of P-ITR traffic, how does the EID Registrar get revenue to cover their increased costs? the document also suggests that CDNs might deploy P-ITRs. There may be some advantages to that, but I would really like to see better explanation. After all, the traffic for the CDN has already reached the CDN at the point it reaches the P-ITR. So I am not clear on how it helps the CDN customer traffic in a way that they can get paid for. (I also am not clear as to what set of prefixes the CDN would be advertising from its P-ITR.) The load balancing special case seems to be even more complex, although potentially significantly more persuasive. Thank you, Joel M. Halpern From jmh@joelhalpern.com Wed Oct 13 10:06:13 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4B23A67B7 for ; Wed, 13 Oct 2010 10:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.363 X-Spam-Level: X-Spam-Status: No, score=-101.363 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0eU5Y1QFDqx for ; Wed, 13 Oct 2010 10:06:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id E71823A6876 for ; Wed, 13 Oct 2010 10:06:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3FB2C3228384 for ; Wed, 13 Oct 2010 10:07:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [42.0.4.63] (unknown [129.174.97.34]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id E58973236DB4 for ; Wed, 13 Oct 2010 10:07:29 -0700 (PDT) Message-ID: <4CB5E74F.2080109@joelhalpern.com> Date: Wed, 13 Oct 2010 13:07:27 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Deployment: Map Resolvers 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, 13 Oct 2010 17:06:13 -0000 Again, speaking just as a participant... The document says that Map Resolvers would be deployed by ISPs. I had somehow gotten the impression that Map Resovlers would be deployed by EID assignment authorities, who would also be running the BGP routers taht participate in the ALT infrastructure. In particular, if Map Resolvers are run by ISPs that implies some coupling between ISP support and end customer usage of LISP, which seems to be something we had been avoiding. Yours, Joel From vaf@cisco.com Wed Oct 13 11:29:37 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04EC83A69F4 for ; Wed, 13 Oct 2010 11:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.289 X-Spam-Level: X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 Q7E2+9-XzTm3 for ; Wed, 13 Oct 2010 11:29:36 -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 E776E3A69CD for ; Wed, 13 Oct 2010 11:29:35 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMKXtUyrR7H+/2dsb2JhbAChUXGiZpxwhUgEhFI X-IronPort-AV: E=Sophos;i="4.57,326,1283731200"; d="scan'208";a="284470174" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 13 Oct 2010 18:30:53 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9DIUrLJ028234; Wed, 13 Oct 2010 18:30:53 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 662B7862F4F; Wed, 13 Oct 2010 11:30:52 -0700 (PDT) Date: Wed, 13 Oct 2010 11:30:52 -0700 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20101013183052.GA78337@vaf-mac1.cisco.com> References: <4CB5E74F.2080109@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CB5E74F.2080109@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] Deployment: Map Resolvers 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, 13 Oct 2010 18:29:37 -0000 On Wed, Oct 13, 2010 at 01:07:27PM -0400, Joel M. Halpern wrote: > Again, speaking just as a participant... > > The document says that Map Resolvers would be deployed by ISPs. > I had somehow gotten the impression that Map Resovlers would be deployed > by EID assignment authorities, who would also be running the BGP routers > taht participate in the ALT infrastructure. > > In particular, if Map Resolvers are run by ISPs that implies some > coupling between ISP support and end customer usage of LISP, which seems > to be something we had been avoiding. Map Resolvers don't have to be run by ISPs but it makes sense for an ISP to offer such a service to its customers. Since an ISP is topologically closest to its own customers, this makes sense for performance reasons. We do expect for Map Servers to be operated by Mapping Service Providers (MSPs) and that the EID assignment authorities will be MSPs. MSPs can certainly operate Map Resolvers as well though sites using them may be more topologically distant from an MSP than from its own ISP. Does this make sense? --Vince From jmh@joelhalpern.com Wed Oct 13 11:39:08 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393F13A6A0B for ; Wed, 13 Oct 2010 11:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.156 X-Spam-Level: X-Spam-Status: No, score=-101.156 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwY9+8o4oVlN for ; Wed, 13 Oct 2010 11:39:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id CDD103A69F5 for ; Wed, 13 Oct 2010 11:39:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 35AB23236DE7; Wed, 13 Oct 2010 11:40:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [42.0.4.63] (unknown [129.174.97.34]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id DB8493228384; Wed, 13 Oct 2010 11:40:23 -0700 (PDT) Message-ID: <4CB5FD15.2060600@joelhalpern.com> Date: Wed, 13 Oct 2010 14:40:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Vince Fuller References: <4CB5E74F.2080109@joelhalpern.com> <20101013183052.GA78337@vaf-mac1.cisco.com> In-Reply-To: <20101013183052.GA78337@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] Deployment: Map Resolvers 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, 13 Oct 2010 18:39:08 -0000 That makes sense. This seems to be a case where it is important to differentiate between necessity and capability. Anyone who can get the necessary business relationship with the ALT can, in principle, run a Map Resolver. Is it the case that any client can use any Map resolver that it has a suitable business relationship with? (Could there even be "open" resolvers?) However, any LISP site needs to be able to reliably get to some Map Resolver. It seems to me that this implies that MSPs need to run Map Resolvers, so that clients can use them if they do not have a resolver that they think will work better. Yours, Joel On 10/13/2010 2:30 PM, Vince Fuller wrote: > On Wed, Oct 13, 2010 at 01:07:27PM -0400, Joel M. Halpern wrote: >> Again, speaking just as a participant... >> >> The document says that Map Resolvers would be deployed by ISPs. >> I had somehow gotten the impression that Map Resovlers would be deployed >> by EID assignment authorities, who would also be running the BGP routers >> taht participate in the ALT infrastructure. >> >> In particular, if Map Resolvers are run by ISPs that implies some >> coupling between ISP support and end customer usage of LISP, which seems >> to be something we had been avoiding. > > Map Resolvers don't have to be run by ISPs but it makes sense for an ISP > to offer such a service to its customers. Since an ISP is topologically > closest to its own customers, this makes sense for performance reasons. > > We do expect for Map Servers to be operated by Mapping Service Providers > (MSPs) and that the EID assignment authorities will be MSPs. MSPs can > certainly operate Map Resolvers as well though sites using them may be > more topologically distant from an MSP than from its own ISP. > > Does this make sense? > > --Vince > From vaf@cisco.com Wed Oct 13 11:46:53 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4473A6AFC for ; Wed, 13 Oct 2010 11:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 RrNUfDa6WWYN for ; Wed, 13 Oct 2010 11:46:52 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7BED23A6A5B for ; Wed, 13 Oct 2010 11:46:52 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIKbtUyrR7Hu/2dsb2JhbAChUXGicJxyhUgEhFI X-IronPort-AV: E=Sophos;i="4.57,326,1283731200"; d="scan'208";a="268998244" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 13 Oct 2010 18:48:09 +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 o9DIm9Va026608; Wed, 13 Oct 2010 18:48:09 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 1BEC68631B3; Wed, 13 Oct 2010 11:48:09 -0700 (PDT) Date: Wed, 13 Oct 2010 11:48:09 -0700 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20101013184808.GA81061@vaf-mac1.cisco.com> References: <4CB5E74F.2080109@joelhalpern.com> <20101013183052.GA78337@vaf-mac1.cisco.com> <4CB5FD15.2060600@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CB5FD15.2060600@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] Deployment: Map Resolvers 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, 13 Oct 2010 18:46:53 -0000 On Wed, Oct 13, 2010 at 02:40:21PM -0400, Joel M. Halpern wrote: > That makes sense. This seems to be a case where it is important to > differentiate between necessity and capability. > > Anyone who can get the necessary business relationship with the ALT can, > in principle, run a Map Resolver. Is it the case that any client can use > any Map resolver that it has a suitable business relationship with? > (Could there even be "open" resolvers?) Yes, eys, and (yes). In fact, all of the Map Resolvers on the LISP pilot network could currently be described as "open" as they don't enforce any access controls. Map Servers, on the other hand, must be explicitly configured to accept Map Registrations from authorizes ETRs. > However, any LISP site needs to be able to reliably get to some Map > Resolver. It seems to me that this implies that MSPs need to run Map > Resolvers, so that clients can use them if they do not have a resolver > that they think will work better. Sure, that makes sense. I'd encourage the authors of the LISP Deployment document keep this discussion mind... --Vince From ljakab@ac.upc.edu Wed Oct 13 14:23:41 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB963A69DF for ; Wed, 13 Oct 2010 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBg6-itIN+L5 for ; Wed, 13 Oct 2010 14:23:40 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by core3.amsl.com (Postfix) with ESMTP id 628663A6998 for ; Wed, 13 Oct 2010 14:23:40 -0700 (PDT) Received: from [10.160.63.32] (tmo-108-32.customers.d1-online.com [80.187.108.32]) by gw.ac.upc.edu (Postfix) with ESMTP id BFEEA6B01CF for ; Wed, 13 Oct 2010 23:24:54 +0200 (CEST) Message-ID: <4CB623A6.9080900@ac.upc.edu> Date: Wed, 13 Oct 2010 23:24:54 +0200 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTech MIME-Version: 1.0 To: LISP WG References: <4CB5E6C2.1020601@joelhalpern.com> In-Reply-To: <4CB5E6C2.1020601@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Deployment Document - P-ITR 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, 13 Oct 2010 21:23:41 -0000 Hi Joel, On 10/13/2010 07:05 PM, Joel M. Halpern wrote: > First, my thanks to the document authors for getting a document > together for us. Thanks for the feedback! > > Speaking purely as an individual participant, I would like to see a > lot more discussion in the P-ITR section. > In general, I am concerned about the costs and incentives for > deploying P-ITRs. As is the case with other protocols that depend on viable transition mechanisms in order to be incrementally deployed, I think P-ITR placement, and, as you say, the associated costs and incentives could be crucial to the success of LISP. Our document, without being exhaustive, provided a few examples as a starting point. >From a theoretical point of view, there are three major deployment types for P-ITRs: - many P-ITRs for each destination prefix, close to the traffic source (the CDN example below); - few P-ITRs in the transit core (the EID registrar example); - many P-ITRs for each destination prefix, close to the traffic destination (xTR + BGP). Another thing that maybe should be considered while discussing P-ITRs is the LISP deployment progress (how many networks have migrated to LISP), because it has a heavy influence on the amount of P-ITR traffic. See replies to the concerns about the individual cases below: > Some examples of where I am confused: > One suggested deployment is that EID registars might run P-ITRs. At > first glance this seems understandable. But I do not understand how > the operational costs line up with the revenue. As an individual > customer increases their usage of of P-ITR traffic, how does the EID > Registrar get revenue to cover their increased costs? I agree that in the initial phase of LISP deployment this is scenario is unattractive for the EID registrars, except maybe for their smallest customers. We tried to avoid too much business case discussion in the draft (I've been told that IETF documents should avoid economics), but for example a new small customer may get P-ITR service up to a certain traffic and/or bandwidth limit, above which it would have to look for alternatives. Of course, the easiest way is xTR + BGP, but in the case of new Internet connectivity customers, who also wish to multihome, it defeats the whole purpose of LISP. > the document also suggests that CDNs might deploy P-ITRs. There may > be some advantages to that, but I would really like to see better > explanation. After all, the traffic for the CDN has already reached > the CDN at the point it reaches the P-ITR. So I am not clear on how > it helps the CDN customer traffic in a way that they can get paid for. > (I also am not clear as to what set of prefixes the CDN would be > advertising from its P-ITR.) The (admittedly unfortunate) use of "CDN" in the draft refers the company operating it, rather than the concept behind the method of efficiently delivering large amounts of data. We considered CDNs, because they are among those with the largest number of geographically well distributed PoPs. The CDN does not use the P-ITR for the traffic that it is the destination of. Rather, the company offers the P-ITR service to clients that are willing to pay for it. Then, they aggregate the prefixes of all of their clients, and announce the aggregates from all of their PoPs (anycast). This leads to a continuous decrease in the DFZ routing table. When a non-LISP site wishes to connect to any of their clients, it will use the closest P-ITR (in terms of BGP), thus minimizing path stretch. > The load balancing special case seems to be even more complex, > although potentially significantly more persuasive. All the cases are somewhat uncharted territory, so definitely more discussion is warranted. Best regards, -Lori > > Thank you, > Joel M. Halpern From jnc@mercury.lcs.mit.edu Wed Oct 13 15:07:55 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C913A69DF for ; Wed, 13 Oct 2010 15:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 z0FfynaXQQUt for ; Wed, 13 Oct 2010 15:07:53 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B2DD93A66B4 for ; Wed, 13 Oct 2010 15:07:53 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B6D566BE57A; Wed, 13 Oct 2010 18:09:10 -0400 (EDT) To: lisp@ietf.org Message-Id: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> Date: Wed, 13 Oct 2010 18:09:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Deployment Document - P-ITR 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, 13 Oct 2010 22:07:55 -0000 > From: Lorand Jakab > Another thing that maybe should be considered while discussing P-ITRs > is the LISP deployment progress (how many networks have migrated to > LISP), because it has a heavy influence on the amount of P-ITR traffic. It's not just the amount of PITR traffic that's a concern; for me, a possibly even bigger concern is the _potential_ increase in size of the 'legacy' DFZ routing table - i.e. the routing table which has to be prepared for the 'unconverted' part of the Internet, to allow legacy stuff to talk to LISP sites. (This has been a concern of mine for some years now...) The situation is complex, because it depends on all sorts of factors, including how much aggregability we get in the routing advertisements from PITRs into the 'legacy' DFZ; whether address space blocks are simply being converted from legacy (i.e. non-LISP) to LISP (which results in no change in the routing table size); etc, etc. It might grow, it might shrink, etc, etc. Alas, I'd really need a really big white-board to lay out all the scenarios... :-( > they aggregate the prefixes of all of their clients, and announce the > aggregates from all of their PoPs (anycast). This leads to a continuous > decrease in the DFZ routing table. Maybe... it all depends on whether any announced LISP blocks from those PITRs are next to each other in the namespace. If not -> no decrease... > I've been told that IETF documents should avoid economics Which might be a huge mistake when it comes to deployment documents, q.v. the recent discussion on the main IETF list. Noel From dino@cisco.com Thu Oct 14 05:14:38 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25FC3A6976 for ; Thu, 14 Oct 2010 05:14:38 -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 us6DYttuJZts for ; Thu, 14 Oct 2010 05:14:37 -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 582293A6951 for ; Thu, 14 Oct 2010 05:14:37 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJuRtkxAZnwM/2dsb2JhbAChIXGfBpxchUgEhFKFb4MDiCI X-IronPort-AV: E=Sophos;i="4.57,330,1283731200"; d="scan'208";a="170617246" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Oct 2010 12:15:56 +0000 Received: from [10.205.137.1] (rtp-vpn6-630.cisco.com [10.82.250.120]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9ECFs04006586; Thu, 14 Oct 2010 12:15:55 GMT Message-Id: From: Dino Farinacci To: Noel Chiappa In-Reply-To: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 14 Oct 2010 04:23:23 -0700 References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Deployment Document - P-ITR 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, 14 Oct 2010 12:14:38 -0000 >> they aggregate the prefixes of all of their clients, and announce the >> aggregates from all of their PoPs (anycast). This leads to a >> continuous >> decrease in the DFZ routing table. > > Maybe... it all depends on whether any announced LISP blocks from > those PITRs > are next to each other in the namespace. If not -> no decrease... I think this *could* be true for IPv4 prefixes. But with IPv6 PI allocated blocks, we could make the IPv6 core run really efficiently. Chairs, I would like to propose IANA to give us not a coarse address block for IPv6 EID space but a high-order byte code-point. Similar to using 0xff for IPv6 multicast and 0xfe for IPv6 link-local addressing. This has two benefits: (1) A very large address space where PITRs can advertise a single route into the DFZ. (2) A very fast method for ITRs and PITRs to tell that a destination is a LISP site to avoid asking the mapping database system for this answer. Thoughts? What would be the procedure to try to do this? Dino From jmh@joelhalpern.com Thu Oct 14 07:46:49 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6503A68DB for ; Thu, 14 Oct 2010 07:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 n705KjPEO+ZA for ; Thu, 14 Oct 2010 07:46:48 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 610133A6930 for ; Thu, 14 Oct 2010 07:46:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CA2B43236DC1; Thu, 14 Oct 2010 07:48:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-141.clppva.btas.verizon.net [71.161.51.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 141BD3236DC2; Thu, 14 Oct 2010 07:48:06 -0700 (PDT) Message-ID: <4CB71825.5030900@joelhalpern.com> Date: Thu, 14 Oct 2010 10:48:05 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dino Farinacci References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Deployment Document - P-ITR 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, 14 Oct 2010 14:46:49 -0000 A few clarifying questions (personal at this point in the process): If I understand right, we are talking about a block from which EIDs would be assigned, and which would not be used for actual routable addresses: 1) Why do we need a a very short code? As far as I can tell, we could use a /24, or worst case a /16. That would still leave plenty of remote for organizational delegation to get to assignment to sites of a suitable size block. 2) Do we think we can get away with not permitting folks to use their PI IPv6 assignments as EIDs? 3) For any definition of a single block for EIDs to give us the advantage you site, we have to assume that P-ITRs are actually going to advertise the entire EID space, not just a portion of it related to their customer set. That would be very nice, but does not match what I read in the deployment document. I would really need to see the cost coverage for that, as there is an even bigger disconnect than just the issue of increasing traffic without revenue that I asked about relative to EID registrars providing P-ITR services. Yours, Joel On 10/14/2010 7:23 AM, Dino Farinacci wrote: >>> they aggregate the prefixes of all of their clients, and announce the >>> aggregates from all of their PoPs (anycast). This leads to a continuous >>> decrease in the DFZ routing table. >> >> Maybe... it all depends on whether any announced LISP blocks from >> those PITRs >> are next to each other in the namespace. If not -> no decrease... > > I think this *could* be true for IPv4 prefixes. But with IPv6 PI > allocated blocks, we could make the IPv6 core run really efficiently. > > Chairs, I would like to propose IANA to give us not a coarse address > block for IPv6 EID space but a high-order byte code-point. Similar to > using 0xff for IPv6 multicast and 0xfe for IPv6 link-local addressing. > > This has two benefits: > > (1) A very large address space where PITRs can advertise a single route > into the DFZ. > > (2) A very fast method for ITRs and PITRs to tell that a destination is > a LISP site to > avoid asking the mapping database system for this answer. > > Thoughts? > > What would be the procedure to try to do this? > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Thu Oct 14 20:17:01 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091EF3A6A95 for ; Thu, 14 Oct 2010 20:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.458 X-Spam-Level: X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 D8UuRm6bjrsV for ; Thu, 14 Oct 2010 20:16:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E12873A6A91 for ; Thu, 14 Oct 2010 20:16:59 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAItkt0yrR7Ht/2dsb2JhbAChInGjQJxahUgEhFOFc4MD X-IronPort-AV: E=Sophos;i="4.57,333,1283731200"; d="scan'208";a="269903806" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 15 Oct 2010 03:18:20 +0000 Received: from [198.18.120.231] (tky-vpn-client-231-35.cisco.com [10.70.231.35]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9F3IGaF007579; Fri, 15 Oct 2010 03:18:18 GMT Message-Id: <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4CB71825.5030900@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: Thu, 14 Oct 2010 20:18:16 -0700 References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> <4CB71825.5030900@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Deployment Document - P-ITR 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, 15 Oct 2010 03:17:01 -0000 > A few clarifying questions (personal at this point in the process): > > If I understand right, we are talking about a block from which EIDs > would be assigned, and which would not be used for actual routable > addresses: Right. > 1) Why do we need a a very short code? As far as I can tell, we > could use a /24, or worst case a /16. That would still leave plenty > of remote for organizational delegation to get to assignment to > sites of a suitable size block. I don't want implementations to have to configure these addresses. Because as you add more, you'll have to change configurations and change ACLs in a lot of places. If you get a large enough space that is "well-known", the performance of the system will be better. > 2) Do we think we can get away with not permitting folks to use > their PI IPv6 assignments as EIDs? We can, but they may not aggregate well and the PITRs will have to inject more routes. IPv6 adoption is in its infancy so we can give sites which request a new EID-based PI prefix. > 3) For any definition of a single block for EIDs to give us the > advantage you site, we have to assume that P-ITRs are actually going > to advertise the entire EID space, not just a portion of it related > to their customer set. That would be very nice, but does not match > what I read in the Yes, that is the point. You want all the PITRs in the world, by default to be anycast servers for the EID space. > deployment document. I would really need to see the cost coverage > for that, as there is an even bigger disconnect than just the issue > of increasing traffic without revenue that I asked about relative to > EID registrars providing P-ITR services. How about this practical situation: (1) New site becomes LISP enabled with a block out of the well-known EID-prefix. (2) No PITRs have to change. Today, with IPv4 EID-prefixes, they are manually configured in the PITRs to inject into the underlying routing system. Or, maybe in the future, this gets automated by "redistributing ALT routes, that are first highly aggregated, then injected into the DFZ". The latter is scary and dangerous but automated. So choose your poison of manually configuring all PITRs with a new EID-prefix when sites go LISP versus the auto-redistribution risk. We could do it much better with IPv6 address allocations. Dino > > Yours, > Joel > > On 10/14/2010 7:23 AM, Dino Farinacci wrote: >>>> they aggregate the prefixes of all of their clients, and announce >>>> the >>>> aggregates from all of their PoPs (anycast). This leads to a >>>> continuous >>>> decrease in the DFZ routing table. >>> >>> Maybe... it all depends on whether any announced LISP blocks from >>> those PITRs >>> are next to each other in the namespace. If not -> no decrease... >> >> I think this *could* be true for IPv4 prefixes. But with IPv6 PI >> allocated blocks, we could make the IPv6 core run really efficiently. >> >> Chairs, I would like to propose IANA to give us not a coarse address >> block for IPv6 EID space but a high-order byte code-point. Similar to >> using 0xff for IPv6 multicast and 0xfe for IPv6 link-local >> addressing. >> >> This has two benefits: >> >> (1) A very large address space where PITRs can advertise a single >> route >> into the DFZ. >> >> (2) A very fast method for ITRs and PITRs to tell that a >> destination is >> a LISP site to >> avoid asking the mapping database system for this answer. >> >> Thoughts? >> >> What would be the procedure to try to do this? >> >> Dino >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> From jmh@joelhalpern.com Thu Oct 14 20:37:12 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1114C3A6874 for ; Thu, 14 Oct 2010 20:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 eX5V3xGBWEO1 for ; Thu, 14 Oct 2010 20:36:40 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 1D5983A6A11 for ; Thu, 14 Oct 2010 20:36:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C89BA3236DB1; Thu, 14 Oct 2010 20:37:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-141.clppva.btas.verizon.net [71.161.51.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 02A683228BE2; Thu, 14 Oct 2010 20:37:58 -0700 (PDT) Message-ID: <4CB7CC94.6090004@joelhalpern.com> Date: Thu, 14 Oct 2010 23:37:56 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dino Farinacci References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> <4CB71825.5030900@joelhalpern.com> <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> In-Reply-To: <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Deployment Document - P-ITR 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, 15 Oct 2010 03:37:12 -0000 Some comments on items 1 and last, in line... On 10/14/2010 11:18 PM, Dino Farinacci wrote: >> A few clarifying questions (personal at this point in the process): >> >> If I understand right, we are talking about a block from which EIDs >> would be assigned, and which would not be used for actual routable >> addresses: > > Right. > >> 1) Why do we need a a very short code? As far as I can tell, we could >> use a /24, or worst case a /16. That would still leave plenty of >> remote for organizational delegation to get to assignment to sites of >> a suitable size block. > > I don't want implementations to have to configure these addresses. > Because as you add more, you'll have to change configurations and change > ACLs in a lot of places. If you get a large enough space that is > "well-known", the performance of the system will be better. Sorry, I am not following this. Whether we get an 8 bit prefix or a 25 bit prefix to serve as a base for all EIDs seems to result in the same amount of configuration for devices which need this information. Getting a longer prefix would seem easier, and equally useful for EIDs. (Or conversely, we will need a much stronger argument to get a 4 bit type code than a 24 bit address prefix. Particularly for an experiment.) > >> 2) Do we think we can get away with not permitting folks to use their >> PI IPv6 assignments as EIDs? > > We can, but they may not aggregate well and the PITRs will have to > inject more routes. IPv6 adoption is in its infancy so we can give sites > which request a new EID-based PI prefix. > >> 3) For any definition of a single block for EIDs to give us the >> advantage you site, we have to assume that P-ITRs are actually going >> to advertise the entire EID space, not just a portion of it related to >> their customer set. That would be very nice, but does not match what I >> read in the > > Yes, that is the point. You want all the PITRs in the world, by default > to be anycast servers for the EID space. > >> deployment document. I would really need to see the cost coverage for >> that, as there is an even bigger disconnect than just the issue of >> increasing traffic without revenue that I asked about relative to EID >> registrars providing P-ITR services. > > How about this practical situation: > > (1) New site becomes LISP enabled with a block out of the well-known > EID-prefix. > (2) No PITRs have to change. I think my question must have been unclear. The deployment document suggests that EID registrars might run PITRs for their blocks. While I am concerned about traffic growth, they are selling a service directly related to what they are being paid for. To the degree that more PITR traffic is caused by more LISP users in their space, they ahve gotten more money for it. But, for someone to run PITRs that advertise the entire LISP EID space, someone has to pay for the increasing traffic load until LISP becomes pervasive. The fact that technically it is much cleaner if their are PITRs like this is nice, but won't pay anyones deployment costs. If we will get PITRs that do such advertising, then it is very clear that we want to have a single prefix for the whole EID space. Yours, Joel From dino@cisco.com Thu Oct 14 20:43:02 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16333A6A8B for ; Thu, 14 Oct 2010 20:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 z10lkjNgNilw for ; Thu, 14 Oct 2010 20:42:56 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 34D103A6A11 for ; Thu, 14 Oct 2010 20:42:56 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOhqt0yrRN+K/2dsb2JhbAChInGjFpxahUgEhFOFc4MD X-IronPort-AV: E=Sophos;i="4.57,333,1283731200"; d="scan'208";a="201199252" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 15 Oct 2010 03:44:16 +0000 Received: from [198.18.120.231] (tky-vpn-client-231-35.cisco.com [10.70.231.35]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9F3iDPw012072; Fri, 15 Oct 2010 03:44:14 GMT Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4CB7CC94.6090004@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: Thu, 14 Oct 2010 20:44:11 -0700 References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> <4CB71825.5030900@joelhalpern.com> <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> <4CB7CC94.6090004@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Deployment Document - P-ITR 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, 15 Oct 2010 03:43:03 -0000 > Some comments on items 1 and last, in line... > > On 10/14/2010 11:18 PM, Dino Farinacci wrote: >>> A few clarifying questions (personal at this point in the process): >>> >>> If I understand right, we are talking about a block from which EIDs >>> would be assigned, and which would not be used for actual routable >>> addresses: >> >> Right. >> >>> 1) Why do we need a a very short code? As far as I can tell, we >>> could >>> use a /24, or worst case a /16. That would still leave plenty of >>> remote for organizational delegation to get to assignment to sites >>> of >>> a suitable size block. >> >> I don't want implementations to have to configure these addresses. >> Because as you add more, you'll have to change configurations and >> change >> ACLs in a lot of places. If you get a large enough space that is >> "well-known", the performance of the system will be better. > > Sorry, I am not following this. Whether we get an 8 bit prefix or a > 25 bit prefix to serve as a base for all EIDs seems to result in the > same amount of configuration for devices which need this > information. Getting a longer prefix would seem easier, and equally > useful for EIDs. > (Or conversely, we will need a much stronger argument to get a 4 bit > type code than a 24 bit address prefix. Particularly for an > experiment.) We are not getting an 8-bit prefix assigned by IANA. We are spec'ing a well-known high-order byte that is permanently assigned by the IPv6 Addressing RFC. >>> 2) Do we think we can get away with not permitting folks to use >>> their >>> PI IPv6 assignments as EIDs? >> >> We can, but they may not aggregate well and the PITRs will have to >> inject more routes. IPv6 adoption is in its infancy so we can give >> sites >> which request a new EID-based PI prefix. >> >>> 3) For any definition of a single block for EIDs to give us the >>> advantage you site, we have to assume that P-ITRs are actually going >>> to advertise the entire EID space, not just a portion of it >>> related to >>> their customer set. That would be very nice, but does not match >>> what I >>> read in the >> >> Yes, that is the point. You want all the PITRs in the world, by >> default >> to be anycast servers for the EID space. >> >>> deployment document. I would really need to see the cost coverage >>> for >>> that, as there is an even bigger disconnect than just the issue of >>> increasing traffic without revenue that I asked about relative to >>> EID >>> registrars providing P-ITR services. >> >> How about this practical situation: >> >> (1) New site becomes LISP enabled with a block out of the well-known >> EID-prefix. >> (2) No PITRs have to change. > > I think my question must have been unclear. The deployment document > suggests that EID registrars might run PITRs for their blocks. > While I am concerned about traffic growth, they are selling a But non-registrars can run PITRs as well. And you can count on the data-plane SPs to do so more so then control-plane providers, like a registrar that may be an "MSP". > service directly related to what they are being paid for. To the > degree that more PITR traffic is caused by more LISP users in their > space, they ahve gotten more money for it. > > But, for someone to run PITRs that advertise the entire LISP EID > space, someone has to pay for the increasing traffic load until LISP > becomes pervasive. The fact that technically it is much cleaner if > their are PITRs like this is nice, but won't pay anyones deployment > costs. SPs want to attack traffic, that is how they justify cost. > If we will get PITRs that do such advertising, then it is very clear > that we want to have a single prefix for the whole EID space. Right. Dino > > Yours, > Joel From jmh@joelhalpern.com Thu Oct 14 21:03:02 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67A73A6A8E for ; Thu, 14 Oct 2010 21:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=-0.098, 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 ixDZudnE2QEa for ; Thu, 14 Oct 2010 21:03:00 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 3C5A83A6A8B for ; Thu, 14 Oct 2010 21:03:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id EADA63236DB4; Thu, 14 Oct 2010 21:04:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-141.clppva.btas.verizon.net [71.161.51.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 0B0673236DBB; Thu, 14 Oct 2010 21:04:19 -0700 (PDT) Message-ID: <4CB7D2C1.4040602@joelhalpern.com> Date: Fri, 15 Oct 2010 00:04:17 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dino Farinacci References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> <4CB71825.5030900@joelhalpern.com> <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> <4CB7CC94.6090004@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Deployment Document - P-ITR 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, 15 Oct 2010 04:03:02 -0000 I must be dense tonight. A fixed prefix is a fixed prefix. whether it is allocated by the IETF or IANA does not matter. And, as far as I can tell, for our purposes, whether it is 4 bits, 8 bits, or 25 bits does not matter. (If it were longer than 32 bits there might be some argument for it mattering.) Without regard to where we direct the request, the shorter a prefix we ask for, the more justification we will be asked to provide. With regard to the PITR deployment, I do not buy "ISPs want to attract traffic". At least not when it comes to traffic which they attract, but which they then have to hand back off, to someone else. Such traffic incurs costs. It is possible that the exchange costs with their peers will balance. But they have to have more traffic handling capacity inside to handle that. It costs money. So why are they going to run a service that costs money? A service which, if it has problems, will cause folks who are not their customers to complain about what they do to the traffic? If we believe this deployment of PITRs is likely (or necessary) then 1) We have to say so in the deployment document 2) I believe we will have to explain much more clearly what the incentives are for folks doing this. Yours, Joel On 10/14/2010 11:44 PM, Dino Farinacci wrote: >> Some comments on items 1 and last, in line... >> >> On 10/14/2010 11:18 PM, Dino Farinacci wrote: >>>> A few clarifying questions (personal at this point in the process): >>>> >>>> If I understand right, we are talking about a block from which EIDs >>>> would be assigned, and which would not be used for actual routable >>>> addresses: >>> >>> Right. >>> >>>> 1) Why do we need a a very short code? As far as I can tell, we could >>>> use a /24, or worst case a /16. That would still leave plenty of >>>> remote for organizational delegation to get to assignment to sites of >>>> a suitable size block. >>> >>> I don't want implementations to have to configure these addresses. >>> Because as you add more, you'll have to change configurations and change >>> ACLs in a lot of places. If you get a large enough space that is >>> "well-known", the performance of the system will be better. >> >> Sorry, I am not following this. Whether we get an 8 bit prefix or a 25 >> bit prefix to serve as a base for all EIDs seems to result in the same >> amount of configuration for devices which need this information. >> Getting a longer prefix would seem easier, and equally useful for EIDs. >> (Or conversely, we will need a much stronger argument to get a 4 bit >> type code than a 24 bit address prefix. Particularly for an experiment.) > > We are not getting an 8-bit prefix assigned by IANA. We are spec'ing a > well-known high-order byte that is permanently assigned by the IPv6 > Addressing RFC. > >>>> 2) Do we think we can get away with not permitting folks to use their >>>> PI IPv6 assignments as EIDs? >>> >>> We can, but they may not aggregate well and the PITRs will have to >>> inject more routes. IPv6 adoption is in its infancy so we can give sites >>> which request a new EID-based PI prefix. >>> >>>> 3) For any definition of a single block for EIDs to give us the >>>> advantage you site, we have to assume that P-ITRs are actually going >>>> to advertise the entire EID space, not just a portion of it related to >>>> their customer set. That would be very nice, but does not match what I >>>> read in the >>> >>> Yes, that is the point. You want all the PITRs in the world, by default >>> to be anycast servers for the EID space. >>> >>>> deployment document. I would really need to see the cost coverage for >>>> that, as there is an even bigger disconnect than just the issue of >>>> increasing traffic without revenue that I asked about relative to EID >>>> registrars providing P-ITR services. >>> >>> How about this practical situation: >>> >>> (1) New site becomes LISP enabled with a block out of the well-known >>> EID-prefix. >>> (2) No PITRs have to change. >> >> I think my question must have been unclear. The deployment document >> suggests that EID registrars might run PITRs for their blocks. While I >> am concerned about traffic growth, they are selling a > > But non-registrars can run PITRs as well. And you can count on the > data-plane SPs to do so more so then control-plane providers, like a > registrar that may be an "MSP". > >> service directly related to what they are being paid for. To the >> degree that more PITR traffic is caused by more LISP users in their >> space, they ahve gotten more money for it. >> >> But, for someone to run PITRs that advertise the entire LISP EID >> space, someone has to pay for the increasing traffic load until LISP >> becomes pervasive. The fact that technically it is much cleaner if >> their are PITRs like this is nice, but won't pay anyones deployment >> costs. > > SPs want to attack traffic, that is how they justify cost. > >> If we will get PITRs that do such advertising, then it is very clear >> that we want to have a single prefix for the whole EID space. > > Right. > > Dino > >> >> Yours, >> Joel > > From dino@cisco.com Thu Oct 14 21:27:17 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09CB3A6A83 for ; Thu, 14 Oct 2010 21:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.171 X-Spam-Level: X-Spam-Status: No, score=-10.171 tagged_above=-999 required=5 tests=[AWL=-0.172, 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 LrtlHdP4nycv for ; Thu, 14 Oct 2010 21:27: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 94ECF3A688A for ; Thu, 14 Oct 2010 21:27:16 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGt1t0yrR7H+/2dsb2JhbAChInGiZ5xdhUgEhFOFc4MD X-IronPort-AV: E=Sophos;i="4.57,334,1283731200"; d="scan'208";a="242735910" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 15 Oct 2010 04:28:37 +0000 Received: from [198.18.120.231] (sjc-vpn6-956.cisco.com [10.21.123.188]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9F4SavH000943; Fri, 15 Oct 2010 04:28:36 GMT Message-Id: <69BADFD9-1D12-4A89-9089-752068E75494@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4CB7D2C1.4040602@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: Thu, 14 Oct 2010 21:28:36 -0700 References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> <4CB71825.5030900@joelhalpern.com> <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> <4CB7CC94.6090004@joelhalpern.com> <4CB7D2C1.4040602@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Deployment Document - P-ITR 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, 15 Oct 2010 04:27:18 -0000 > I must be dense tonight. > A fixed prefix is a fixed prefix. whether it is allocated by the > IETF or IANA does not matter. And, as far as I can tell, for our > purposes, whether it is 4 bits, 8 bits, or 25 bits does not matter. > (If it were longer than 32 bits there might be some argument for it > mattering.) > Without regard to where we direct the request, the shorter a prefix > we ask for, the more justification we will be asked to provide. Yes, from the PITR's perspective when it originates an EID-prefix in the DFZ. No, for an ITR that wants to know, without asking externally, that a destination site is an LISP site. > With regard to the PITR deployment, I do not buy "ISPs want to > attract traffic". At least not when it comes to traffic which they > attract, but which they then have to hand back off, to someone They want to attrack traffic from their customers destined for LISP sites that are either their own customers or their peers customers. Note the idea of PITR deployment is to have them reside on the edges of the network, where the coarse EID-prefixes are sent "outward" and not into the core. So they reside in POPs and send the routes toward the PE routers. > else. Such traffic incurs costs. It is possible that the exchange > costs with their peers will The traffic is roughly on path. > balance. But they have to have more traffic handling capacity > inside to handle that. It costs They do not. Traffic that comes to them from their sources can be to LISP or non-LISP sites. The rate the PITRs get traffic is the rate the customer can inject traffic, regardless of the destination type. > money. So why are they going to run a service that costs money? A > service which, if it has problems, will cause folks who are not > their customers to complain about what they do to the traffic? They want to provide connectivity to their LISP customers, who want to multi-home. So the SP will want to have the PITR encapsulate to the ETRs that the LISP customer sites. > If we believe this deployment of PITRs is likely (or necessary) then > 1) We have to say so in the deployment document > 2) I believe we will have to explain much more clearly what the > incentives are for folks doing this. Agree. Dino > > Yours, > Joel > > On 10/14/2010 11:44 PM, Dino Farinacci wrote: >>> Some comments on items 1 and last, in line... >>> >>> On 10/14/2010 11:18 PM, Dino Farinacci wrote: >>>>> A few clarifying questions (personal at this point in the >>>>> process): >>>>> >>>>> If I understand right, we are talking about a block from which >>>>> EIDs >>>>> would be assigned, and which would not be used for actual routable >>>>> addresses: >>>> >>>> Right. >>>> >>>>> 1) Why do we need a a very short code? As far as I can tell, we >>>>> could >>>>> use a /24, or worst case a /16. That would still leave plenty of >>>>> remote for organizational delegation to get to assignment to >>>>> sites of >>>>> a suitable size block. >>>> >>>> I don't want implementations to have to configure these addresses. >>>> Because as you add more, you'll have to change configurations and >>>> change >>>> ACLs in a lot of places. If you get a large enough space that is >>>> "well-known", the performance of the system will be better. >>> >>> Sorry, I am not following this. Whether we get an 8 bit prefix or >>> a 25 >>> bit prefix to serve as a base for all EIDs seems to result in the >>> same >>> amount of configuration for devices which need this information. >>> Getting a longer prefix would seem easier, and equally useful for >>> EIDs. >>> (Or conversely, we will need a much stronger argument to get a 4 bit >>> type code than a 24 bit address prefix. Particularly for an >>> experiment.) >> >> We are not getting an 8-bit prefix assigned by IANA. We are >> spec'ing a >> well-known high-order byte that is permanently assigned by the IPv6 >> Addressing RFC. >> >>>>> 2) Do we think we can get away with not permitting folks to use >>>>> their >>>>> PI IPv6 assignments as EIDs? >>>> >>>> We can, but they may not aggregate well and the PITRs will have to >>>> inject more routes. IPv6 adoption is in its infancy so we can >>>> give sites >>>> which request a new EID-based PI prefix. >>>> >>>>> 3) For any definition of a single block for EIDs to give us the >>>>> advantage you site, we have to assume that P-ITRs are actually >>>>> going >>>>> to advertise the entire EID space, not just a portion of it >>>>> related to >>>>> their customer set. That would be very nice, but does not match >>>>> what I >>>>> read in the >>>> >>>> Yes, that is the point. You want all the PITRs in the world, by >>>> default >>>> to be anycast servers for the EID space. >>>> >>>>> deployment document. I would really need to see the cost >>>>> coverage for >>>>> that, as there is an even bigger disconnect than just the issue of >>>>> increasing traffic without revenue that I asked about relative >>>>> to EID >>>>> registrars providing P-ITR services. >>>> >>>> How about this practical situation: >>>> >>>> (1) New site becomes LISP enabled with a block out of the well- >>>> known >>>> EID-prefix. >>>> (2) No PITRs have to change. >>> >>> I think my question must have been unclear. The deployment document >>> suggests that EID registrars might run PITRs for their blocks. >>> While I >>> am concerned about traffic growth, they are selling a >> >> But non-registrars can run PITRs as well. And you can count on the >> data-plane SPs to do so more so then control-plane providers, like a >> registrar that may be an "MSP". >> >>> service directly related to what they are being paid for. To the >>> degree that more PITR traffic is caused by more LISP users in their >>> space, they ahve gotten more money for it. >>> >>> But, for someone to run PITRs that advertise the entire LISP EID >>> space, someone has to pay for the increasing traffic load until LISP >>> becomes pervasive. The fact that technically it is much cleaner if >>> their are PITRs like this is nice, but won't pay anyones deployment >>> costs. >> >> SPs want to attack traffic, that is how they justify cost. >> >>> If we will get PITRs that do such advertising, then it is very clear >>> that we want to have a single prefix for the whole EID space. >> >> Right. >> >> Dino >> >>> >>> Yours, >>> Joel >> >> From jmh@joelhalpern.com Fri Oct 15 05:56:17 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27943A6C93 for ; Fri, 15 Oct 2010 05:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 qKsl692zEmQO for ; Fri, 15 Oct 2010 05:56:17 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 2BE0C3A6A45 for ; Fri, 15 Oct 2010 05:56:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 99A693228478 for ; Fri, 15 Oct 2010 05:57:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-141.clppva.btas.verizon.net [71.161.51.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 30E953228415 for ; Fri, 15 Oct 2010 05:57:38 -0700 (PDT) Message-ID: <4CB84FC0.4060109@joelhalpern.com> Date: Fri, 15 Oct 2010 08:57:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: lisp@ietf.org References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> <4CB71825.5030900@joelhalpern.com> <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> <4CB7CC94.6090004@joelhalpern.com> <4CB7D2C1.4040602@joelhalpern.com> <69BADFD9-1D12-4A89-9089-752068E75494@cisco.com> In-Reply-To: <69BADFD9-1D12-4A89-9089-752068E75494@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] EID allocation / ALT base 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, 15 Oct 2010 12:56:17 -0000 The discussion of PITR deployment, and the creation of an EID base for IPv6, raised an interesting quesiton in my head. Do we need to specify who will function as the top in that case? If there is a single EID prefix, then it seems that someone has to be authorized to give out EIDs from that space. According to some rules. WHo do we give that job to? And if we give that job to someone, do they have to run some ALT routers, or does it suffice for them to require that all entities which receive direct allocations from that agency must run ALT routers and must peer with each other? (We have to ensure the ALT is a connected graph, I think.) Yours, Joel PS: Yes, these are operational considerations. But it seems that if we are going to want a common base for v6 EIDs (which seems a good idea to me personally) then we need to deal with this. From dino@cisco.com Fri Oct 15 08:01:25 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0506A3A6CB0 for ; Fri, 15 Oct 2010 08:01:25 -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 Ez+w8aZX3SoC for ; Fri, 15 Oct 2010 08:01:24 -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 062723A6AAD for ; Fri, 15 Oct 2010 08:01:24 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIsJuExAaMHG/2dsb2JhbAChInGjLZxUhUkEhFSFdoME X-IronPort-AV: E=Sophos;i="4.57,336,1283731200"; d="scan'208";a="284966561" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 15 Oct 2010 15:02:44 +0000 Received: from [172.16.228.108] (syd-vpn-client-255-177.cisco.com [10.66.255.177]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9FF1TVG026711; Fri, 15 Oct 2010 15:02:43 GMT Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4CB84FC0.4060109@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: Fri, 15 Oct 2010 07:56:01 -0700 References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> <4CB71825.5030900@joelhalpern.com> <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> <4CB7CC94.6090004@joelhalpern.com> <4CB7D2C1.4040602@joelhalpern.com> <69BADFD9-1D12-4A89-9089-752068E75494@cisco.com> <4CB84FC0.4060109@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 15 Oct 2010 15:01:25 -0000 > The discussion of PITR deployment, and the creation of an EID base > for IPv6, raised an interesting quesiton in my head. > Do we need to specify who will function as the top in that case? If > there is a single EID prefix, then it seems that someone has to be > authorized to give out EIDs from that space. According to some > rules. WHo do we give that job to? Joel, let me offer a suggestion. Can we put this as an agenda item for Beijing and have an open discussion about this? I think we all in the room, it will be a higher bandwidth channel for communication. > And if we give that job to someone, do they have to run some ALT > routers, or does it suffice for them to require that all entities > which receive direct allocations from that agency must run ALT > routers and must peer with each other? (We have to ensure the ALT is > a connected graph, I think.) Everything is decoupled. A PITR just needs two GRE tunnels to the ALT system to anywhere there is an ALT router. A PITR can also use a Map- Resolver as well so it is not required to be attached to the ALT. Who assigns EID-prefixes, who provides map-server services for EID- prefixes, who allocates PA-based RLOCs, and all independent from each other. That is the huge benefit the level of indirection brings. You can change anyone without changing the other. Dino > > Yours, > Joel > > PS: Yes, these are operational considerations. But it seems that if > we are going to want a common base for v6 EIDs (which seems a good > idea to me personally) then we need to deal with this. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Fri Oct 15 08:34:19 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4ABC3A6CE5 for ; Fri, 15 Oct 2010 08:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 jRJOIWn89FW4 for ; Fri, 15 Oct 2010 08:34:14 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 64F973A6981 for ; Fri, 15 Oct 2010 08:34:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 232803236DB5; Fri, 15 Oct 2010 08:35:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-141.clppva.btas.verizon.net [71.161.51.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 6FE623236DB2; Fri, 15 Oct 2010 08:35:34 -0700 (PDT) Message-ID: <4CB874C4.7010202@joelhalpern.com> Date: Fri, 15 Oct 2010 11:35:32 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dino Farinacci References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> <4CB71825.5030900@joelhalpern.com> <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> <4CB7CC94.6090004@joelhalpern.com> <4CB7D2C1.4040602@joelhalpern.com> <69BADFD9-1D12-4A89-9089-752068E75494@cisco.com> <4CB84FC0.4060109@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 15 Oct 2010 15:34:19 -0000 I agree that this needs more discussion. I sent the note to raise the issue, not expecting a quick or simple answer. (Terry will be chairing the session on Friday at the IETF meeting as I have to be on a plane back for family reasons.) I was not asking in this quesiton about who runs the PITRs. The decoupling there is useful and understandable. I was asking about the EID side. The ALT needs to be connected. Someone has to run ALT routers for any portion of the EID space that is allocated. And those routers have to have paths to each other. In the Internet, this works by accident by having enough BIG players to hold things together. The initial stage was handled by having a mandated central infrastructure. I see some land mines hidden in this space that could cause serious problems at the point where this starts to matter. (As a small experiment, it just works.) Yours, Joel On 10/15/2010 10:56 AM, Dino Farinacci wrote: >> The discussion of PITR deployment, and the creation of an EID base for >> IPv6, raised an interesting quesiton in my head. >> Do we need to specify who will function as the top in that case? If >> there is a single EID prefix, then it seems that someone has to be >> authorized to give out EIDs from that space. According to some rules. >> WHo do we give that job to? > > Joel, let me offer a suggestion. Can we put this as an agenda item for > Beijing and have an open discussion about this? I think we all in the > room, it will be a higher bandwidth channel for communication. > >> And if we give that job to someone, do they have to run some ALT >> routers, or does it suffice for them to require that all entities >> which receive direct allocations from that agency must run ALT routers >> and must peer with each other? (We have to ensure the ALT is a >> connected graph, I think.) > > Everything is decoupled. A PITR just needs two GRE tunnels to the ALT > system to anywhere there is an ALT router. A PITR can also use a > Map-Resolver as well so it is not required to be attached to the ALT. > > Who assigns EID-prefixes, who provides map-server services for > EID-prefixes, who allocates PA-based RLOCs, and all independent from > each other. That is the huge benefit the level of indirection brings. > You can change anyone without changing the other. > > Dino > >> >> Yours, >> Joel >> >> PS: Yes, these are operational considerations. But it seems that if we >> are going to want a common base for v6 EIDs (which seems a good idea >> to me personally) then we need to deal with this. >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > From jnc@mercury.lcs.mit.edu Fri Oct 15 12:23:00 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF153A6981 for ; Fri, 15 Oct 2010 12:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzCpVXrYvr7P for ; Fri, 15 Oct 2010 12:22:59 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id BE1C13A693E for ; Fri, 15 Oct 2010 12:22:59 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2DA726BE5CF; Fri, 15 Oct 2010 15:24:21 -0400 (EDT) To: lisp@ietf.org Message-Id: <20101015192421.2DA726BE5CF@mercury.lcs.mit.edu> Date: Fri, 15 Oct 2010 15:24:21 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] EID allocation / ALT base 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, 15 Oct 2010 19:23:00 -0000 > From: "Joel M. Halpern" > I see some land mines hidden in this space that could cause serious > problems at the point where this starts to matter. (As a small > experiment, it just works.) Indeed - and if LISP does become fairly widely deployed, and one wants to do some other things with it (e.g. decrease routing table sizes by not propogating EID routes in backbone areas entirely surrounded by LISP boxes, wherein only RLOC routes are actually needed), the picture can become even more complicated. Both ends of the process have relatively simple pictures, I think. (In the case above, at the end-state wherein we have only stub non-LISP areas left, then internal to those stub non-LISP areas one has 'default routes' which funnel all traffic toward both EIDs, and non-LISP sites - which have to have PETRs acting on their behalf - to the LISP xTRs at the stub boundary.) It's the cases in the middle that get complicated - and which are not too well explored. E.g. if one has large islands of LISP, but have not yet reached the 'core and legacy stubs' stage, the routing can be tricky if one wants to withdraw EID routes from within the islands. Oh well, I'm sure we'l work it out! Noel From jnc@mercury.lcs.mit.edu Fri Oct 15 13:28:12 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5DD3A69AD for ; Fri, 15 Oct 2010 13:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 TOc8oO6VTIf2 for ; Fri, 15 Oct 2010 13:28: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 67C7B3A63D2 for ; Fri, 15 Oct 2010 13:28:11 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CA3676BE5CF; Fri, 15 Oct 2010 16:29:32 -0400 (EDT) To: lisp@ietf.org Message-Id: <20101015202932.CA3676BE5CF@mercury.lcs.mit.edu> Date: Fri, 15 Oct 2010 16:29:32 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] EID allocation / ALT base 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, 15 Oct 2010 20:28:12 -0000 > From: "Joel M. Halpern" > If there is a single EID prefix, then it seems that someone has to be > authorized to give out EIDs from that space. According to some rules. > WHo do we give that job to? The IANA, and delegated from them to the RIRs? The mechanisms are all there already, why would we want to reinvent the wheel? > do they have to run some ALT routers, or does it suffice for them to > require that all entities which receive direct allocations from that > agency must run ALT routers and must peer with each other? How does DNS do it, for the top-level domains authorized by ICANN/IANA? There have to be root servers, etc. Again, something similar here, I would think. Noel From jmh@joelhalpern.com Fri Oct 15 14:08:24 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0213A6D1B for ; Fri, 15 Oct 2010 14:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 6OZ3K4wCsf-8 for ; Fri, 15 Oct 2010 14:08:23 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 036923A6BCC for ; Fri, 15 Oct 2010 14:08:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 6C0453236DB5; Fri, 15 Oct 2010 14:09:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-141.clppva.btas.verizon.net [71.161.51.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id D18B03236DB4; Fri, 15 Oct 2010 14:09:44 -0700 (PDT) Message-ID: <4CB8C314.5080902@joelhalpern.com> Date: Fri, 15 Oct 2010 17:09:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Noel Chiappa References: <20101015202932.CA3676BE5CF@mercury.lcs.mit.edu> In-Reply-To: <20101015202932.CA3676BE5CF@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] EID allocation / ALT base 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, 15 Oct 2010 21:08:24 -0000 Having IANA and the RIRs do the allocaiton of EIDs is one sensible strategy. My concern is that at the moment, there is nothing written down that says who will do it, according to what rules, etc. And since there has to be some relationship between those allocations and what gets advertised in the ALT (in terms of authority for information at least), it needs to be spelled out. (For IP addresses, the addresses are delegated to the entities who advertise them, at least in theory.) DNS does not have a connectednes problem. Conceptually, everyone "peers with" the well known roots (A-root, ...) Those devices all get their data from ICANN / IANA. The connectivity is then downwards, because each device knows the information about the delegations (with glue records for all sorts of itneresting problems.) But in the ALT, we have a BGP structure. The paragraph you quote from me is a sketch pointing at two possible ways to ensure that things connect. (This is, I think, quite separate from the lock-in issues which also have to be looked at. I.e. EID provider lockin / fee escalation. Although that is another story for another day.) Yours, Joel On 10/15/2010 4:29 PM, Noel Chiappa wrote: > > From: "Joel M. Halpern" > > > If there is a single EID prefix, then it seems that someone has to be > > authorized to give out EIDs from that space. According to some rules. > > WHo do we give that job to? > > The IANA, and delegated from them to the RIRs? The mechanisms are all there > already, why would we want to reinvent the wheel? > > > do they have to run some ALT routers, or does it suffice for them to > > require that all entities which receive direct allocations from that > > agency must run ALT routers and must peer with each other? > > How does DNS do it, for the top-level domains authorized by ICANN/IANA? There > have to be root servers, etc. Again, something similar here, I would think. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Sat Oct 16 05:47:28 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646103A6938 for ; Sat, 16 Oct 2010 05:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 cD4UXVyG9O3g for ; Sat, 16 Oct 2010 05:47:27 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8870E3A68D1 for ; Sat, 16 Oct 2010 05:47:27 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABo8uUyrR7Hu/2dsb2JhbAChM3Ggf5wXhUkEhFSFdoMF X-IronPort-AV: E=Sophos;i="4.57,339,1283731200"; d="scan'208";a="201802512" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 16 Oct 2010 12:48:51 +0000 Received: from [198.18.120.231] (sjc-vpn7-725.cisco.com [10.21.146.213]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9GCmoqN023160; Sat, 16 Oct 2010 12:48:51 GMT Message-Id: <3A10AABE-79D1-4A3C-B7C5-A51DCA633DC8@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4CB874C4.7010202@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, 16 Oct 2010 05:48:50 -0700 References: <20101013220910.B6D566BE57A@mercury.lcs.mit.edu> <4CB71825.5030900@joelhalpern.com> <6A0B34C8-E3E1-4142-9DDF-8DEEB88DFB9E@cisco.com> <4CB7CC94.6090004@joelhalpern.com> <4CB7D2C1.4040602@joelhalpern.com> <69BADFD9-1D12-4A89-9089-752068E75494@cisco.com> <4CB84FC0.4060109@joelhalpern.com> <4CB874C4.7010202@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 16 Oct 2010 12:47:28 -0000 > I was not asking in this quesiton about who runs the PITRs. The > decoupling there is useful and understandable. > I was asking about the EID side. The ALT needs to be connected. > Someone has to run ALT routers for any portion of the EID space that > is allocated. And those routers have to have paths to each other. > In the Internet, this works by accident by having enough BIG players > to hold things together. The initial stage was handled by having a > mandated central infrastructure. I see some land mines hidden in > this space that could cause serious problems at the point where this > starts to matter. (As a small experiment, it just works.) Agree, this needs discussion and hopefully on a non-Friday afternoon session. ;-) Dino From jnc@mercury.lcs.mit.edu Sat Oct 16 06:43:17 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E595C3A68B7 for ; Sat, 16 Oct 2010 06:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 UI8JIfsoYMxR for ; Sat, 16 Oct 2010 06:43:16 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id A72533A697C for ; Sat, 16 Oct 2010 06:43:16 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9C0376BE5E0; Sat, 16 Oct 2010 09:44:39 -0400 (EDT) To: lisp@ietf.org Message-Id: <20101016134439.9C0376BE5E0@mercury.lcs.mit.edu> Date: Sat, 16 Oct 2010 09:44:39 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] EID allocation / ALT base 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, 16 Oct 2010 13:43:18 -0000 > From: "Joel M. Halpern" > But in the ALT, we have a BGP structure. Hey, if LISP is a big success, I have a very strong feeling that we won't have the ALT around to worry about anyway... :-) The ALT was a really clever way to build a distributed mapping system without having to write a whole bunch of new code (by re-using GRE tunnels, BGP, etc), but it definitely has some aspects that make it not the best choice for a _large_ distributed mapping system... Noel From HeinerHummel@aol.com Sat Oct 16 07:53:01 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D783C3A6941 for ; Sat, 16 Oct 2010 07:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_50=0.001, 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 tBcKHUTi7t2u for ; Sat, 16 Oct 2010 07:53:00 -0700 (PDT) Received: from imr-db01.mx.aol.com (imr-db01.mx.aol.com [205.188.91.95]) by core3.amsl.com (Postfix) with ESMTP id A96293A67A3 for ; Sat, 16 Oct 2010 07:53:00 -0700 (PDT) Received: from imo-da01.mx.aol.com (imo-da01.mx.aol.com [205.188.169.199]) by imr-db01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o9GEsF5n031556; Sat, 16 Oct 2010 10:54:15 -0400 Received: from HeinerHummel@aol.com by imo-da01.mx.aol.com (mail_out_v42.9.) id l.c65.72751bb3 (55836); Sat, 16 Oct 2010 10:54:10 -0400 (EDT) Received: from smtprly-dd03.mx.aol.com (smtprly-dd03.mx.aol.com [205.188.84.131]) by cia-md06.mx.aol.com (v129.5) with ESMTP id MAILCIAMD064-d4094cb9bc90179; Sat, 16 Oct 2010 10:54:10 -0400 Received: from webmail-d007 (webmail-d007.sim.aol.com [205.188.181.24]) by smtprly-dd03.mx.aol.com (v129.4) with ESMTP id MAILSMTPRLYDD035-d4094cb9bc90179; Sat, 16 Oct 2010 10:54:08 -0400 References: <20101016134439.9C0376BE5E0@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu, lisp@ietf.org Date: Sat, 16 Oct 2010 10:54:08 -0400 X-AOL-IP: 95.91.18.180 In-Reply-To: <20101016134439.9C0376BE5E0@mercury.lcs.mit.edu> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CD3B591E93DA68_1E1C_14776_webmail-d007.sysops.aol.com" X-Mailer: AOL Webmail 32797-STANDARD Received: from 95.91.18.180 by webmail-d007.sysops.aol.com (205.188.181.24) with HTTP (WebMailUI); Sat, 16 Oct 2010 10:54:08 -0400 Message-Id: <8CD3B591E8CB645-1E1C-B93F@webmail-d007.sysops.aol.com> X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [lisp] EID allocation / ALT base 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, 16 Oct 2010 14:53:02 -0000 ----------MB_8CD3B591E93DA68_1E1C_14776_webmail-d007.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Who will OWN the ALT ? Cisco? Or the US-goverment? Imho, who will own the= ALT, will own the internet ! How many ALT-routers will be required?=20 what are the impications if this number is too big, resp. too small ? What= is the right size? Is the intention of LISP to cover just some share of the internet, or the= entire internet? Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Noel Chiappa An: lisp@ietf.org Cc: jnc@mercury.lcs.mit.edu Verschickt: Sa., 16. Okt. 2010, 15:44 Thema: Re: [lisp] EID allocation / ALT base > From: "Joel M. Halpern" > But in the ALT, we have a BGP structure. =20 Hey, if LISP is a big success, I have a very strong feeling that we won't have the ALT around to worry about anyway... :-) The ALT was a really clever way to build a distributed mapping system with= out having to write a whole bunch of new code (by re-using GRE tunnels, BGP, etc), but it definitely has some aspects that make it not the best choice= for a _large_ distributed mapping system... Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp =20 ----------MB_8CD3B591E93DA68_1E1C_14776_webmail-d007.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Who will= OWN the ALT ?  Cisco? Or the US-goverment? Imho, who will own the AL= T, will own the internet !

How many= ALT-routers will be required? 
what are= the impications if this number is too big, resp. too small ? What is the= right size?

Is the= intention of  LISP to cover just some share of the internet, or the= entire internet?

Heiner



----= -Urspr=C3=BCngliche Mitteilung-----
Von: Noel Chiappa <jnc@mercury.lcs.mit.edu>
An: lisp@ietf.org
Cc: jnc@mercury.lcs.mit.edu
Verschickt: Sa., 16. Okt. 2010, 15:44
Thema: Re: [lisp] EID allocation / ALT base

    > From: "Joel M. Halpern" <jmh@joelhalpern.com>

    > But in the ALT, we have a BGP structure. =20

Hey, if LISP is a big success, I have a very strong feeling that we won't
have the ALT around to worry about anyway... :-)

The ALT was a really clever way to build a distributed mapping system with=
out
having to write a whole bunch of new code (by re-using GRE tunnels, BGP,
etc), but it definitely has some aspects that make it not the best choice=
 for
a _large_ distributed mapping system...

    Noel
_______________________________________________
lisp mailing list
lisp@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/lisp
----------MB_8CD3B591E93DA68_1E1C_14776_webmail-d007.sysops.aol.com-- From jnc@mercury.lcs.mit.edu Sat Oct 16 08:10:45 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32B93A6A8B for ; Sat, 16 Oct 2010 08:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 FWhB-6TXBtSb for ; Sat, 16 Oct 2010 08:10:41 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1D9883A6A49 for ; Sat, 16 Oct 2010 08:10:29 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6CF486BE5E0; Sat, 16 Oct 2010 11:11:53 -0400 (EDT) To: lisp@ietf.org Message-Id: <20101016151153.6CF486BE5E0@mercury.lcs.mit.edu> Date: Sat, 16 Oct 2010 11:11:53 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] EID allocation / ALT base 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, 16 Oct 2010 15:10:45 -0000 > From: heinerhummel@aol.com > Who will OWN the ALT ? Who owns the DNS? Noel From dino@cisco.com Sat Oct 16 12:19:45 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB853A6B0D for ; Sat, 16 Oct 2010 12:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 7WWsDMTsWUJe for ; Sat, 16 Oct 2010 12:19: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 628643A6ADF for ; Sat, 16 Oct 2010 12:19:44 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAWYuUyrRN+K/2dsb2JhbAChKnGkZ5t6hUkEhFSFdoMF X-IronPort-AV: E=Sophos;i="4.57,340,1283731200"; d="scan'208";a="605120632" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2010 19:21:08 +0000 Received: from [192.168.5.190] (sjc-vpn6-89.cisco.com [10.21.120.89]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9GJL88V028979; Sat, 16 Oct 2010 19:21:08 GMT Message-Id: <7F4D34A8-B917-4534-B8F1-5C0CD9E98AFB@cisco.com> From: Dino Farinacci To: heinerhummel@aol.com In-Reply-To: <8CD3B591E8CB645-1E1C-B93F@webmail-d007.sysops.aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 16 Oct 2010 12:21:07 -0700 References: <20101016134439.9C0376BE5E0@mercury.lcs.mit.edu> <8CD3B591E8CB645-1E1C-B93F@webmail-d007.sysops.aol.com> X-Mailer: Apple Mail (2.936) Cc: jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 16 Oct 2010 19:19:45 -0000 > Who will OWN the ALT ? Cisco? Or the US-goverment? Imho, who will =20 > own the ALT, will own the internet ! The same question I'll ask you now, who owns the DNS system? The answer is the same. > How many ALT-routers will be required? How many DNS servers are needed to support 1 billion names? > what are the impications if this number is too big, resp. too =20 > small ? What is the right size? > > Is the intention of LISP to cover just some share of the internet, =20= > or the entire internet? What makes you think anyone can control how small or how large it =20 gets? You must assume entire. Dino > > Heiner > > > > -----Urspr=FCngliche Mitteilung----- > Von: Noel Chiappa > An: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Verschickt: Sa., 16. Okt. 2010, 15:44 > Thema: Re: [lisp] EID allocation / ALT base > > > From: "Joel M. Halpern" > > > But in the ALT, we have a BGP structure. > > Hey, if LISP is a big success, I have a very strong feeling that we =20= > won't > have the ALT around to worry about anyway... :-) > > The ALT was a really clever way to build a distributed mapping =20 > system without > having to write a whole bunch of new code (by re-using GRE tunnels, =20= > BGP, > etc), but it definitely has some aspects that make it not the best =20 > choice for > a _large_ distributed mapping system... > > 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 HeinerHummel@aol.com Sun Oct 17 00:14:23 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25803A67AD for ; Sun, 17 Oct 2010 00:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_50=0.001, 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 3CYdtPEy7Edc for ; Sun, 17 Oct 2010 00:14:20 -0700 (PDT) Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by core3.amsl.com (Postfix) with ESMTP id B3CB23A6A79 for ; Sun, 17 Oct 2010 00:14:19 -0700 (PDT) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id o9H7FU93025709; Sun, 17 Oct 2010 03:15:30 -0400 Received: from HeinerHummel@aol.com by imo-ma03.mx.aol.com (mail_out_v42.9.) id c.f2e.52a6ce7 (37129); Sun, 17 Oct 2010 03:15:27 -0400 (EDT) Received: from magic-m17.mail.aol.com (magic-m17.mail.aol.com [172.21.147.70]) by cia-ma02.mx.aol.com (v129.5) with ESMTP id MAILCIAMA023-91094cbaa28f384; Sun, 17 Oct 2010 03:15:27 -0400 From: HeinerHummel@aol.com Message-ID: <605ce.6f40aec1.39ebfc8f@aol.com> Date: Sun, 17 Oct 2010 03:15:27 EDT To: dino@cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_605ce.6f40aec1.39ebfc8f_boundary" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 95.91.18.180 X-AOL-SENDER: HeinerHummel@aol.com Cc: jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 17 Oct 2010 07:14:23 -0000 --part1_605ce.6f40aec1.39ebfc8f_boundary Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 16.10.2010 21:21:13 Westeurop=E4ische Sommerzeit schrei= bt =20 dino@cisco.com: > Who will OWN the ALT ? Cisco? Or the US-goverment? Imho, who will =20 > own the ALT, will own the internet ! The same question I'll ask you now, who owns the DNS system? The answer is the same. > How many ALT-routers will be required? How many DNS servers are needed to support 1 billion names? So why don't you just use DNS (LISP 2.0) instead of the ALT router? It =20 would be much faster if you get all the info by just one query! =20 Heiner --part1_605ce.6f40aec1.39ebfc8f_boundary Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <= FONT id=3Drole_document color=3D#000000 size=3D2 face=3DArial>
In einer eMail vom 16.10.2010 21:21:13 Westeurop=E4ische Sommerzeit= schreibt=20 dino@cisco.com:
> Who=20 will OWN the ALT ?  Cisco? Or the US-goverment? Imho, who will = ;=20
> own the ALT, will own the internet !

The same question= I'll=20 ask you now, who owns the DNS system?

The answer is the=20 same.

> How many ALT-routers will be required?

How many= DNS=20 servers are needed to support 1 billion names?

So why don't you just use DNS (LISP 2.0) instead of the ALT router?&n= bsp;It=20 would be much faster if you get all
the info by just one query!
 
Heiner
--part1_605ce.6f40aec1.39ebfc8f_boundary-- From dino@cisco.com Sun Oct 17 05:25:45 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5E83A6AC2 for ; Sun, 17 Oct 2010 05:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 clKPmXk4ANiC for ; Sun, 17 Oct 2010 05:25:44 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AEEA23A6A56 for ; Sun, 17 Oct 2010 05:25:44 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOuIukyrR7Ht/2dsb2JhbAChK3GlWJs/hUkEhFSFdoMF X-IronPort-AV: E=Sophos;i="4.57,342,1283731200"; d="scan'208";a="202045405" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 17 Oct 2010 12:26:53 +0000 Received: from [198.18.120.231] (sjc-vpn6-563.cisco.com [10.21.122.51]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9HCQqu0026683; Sun, 17 Oct 2010 12:26:52 GMT Message-Id: From: Dino Farinacci To: HeinerHummel@aol.com In-Reply-To: <605ce.6f40aec1.39ebfc8f@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 17 Oct 2010 05:26:52 -0700 References: <605ce.6f40aec1.39ebfc8f@aol.com> X-Mailer: Apple Mail (2.936) Cc: jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 17 Oct 2010 12:25:45 -0000 > In einer eMail vom 16.10.2010 21:21:13 Westeurop=E4ische Sommerzeit =20= > schreibt dino@cisco.com: > > Who will OWN the ALT ? Cisco? Or the US-goverment? Imho, who will > > own the ALT, will own the internet ! > > The same question I'll ask you now, who owns the DNS system? > > The answer is the same. > > > How many ALT-routers will be required? > > How many DNS servers are needed to support 1 billion names? > > So why don't you just use DNS (LISP 2.0) instead of the ALT router? =20= > It would be much faster if you get all > the info by just one query! > > Heiner Because when a mapping database entry changes in a set of ETRs, they =20 not only need to update all the ITR/PITR caches but the ALT-caches as =20= well since DNS is a "intermediate caching system". That makes the =20 mechanism difficult and non-scalable. Dino From HeinerHummel@aol.com Sun Oct 17 07:09:50 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0153A6A66 for ; Sun, 17 Oct 2010 07:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=1.877, BAYES_00=-2.599, GB_I_LETTER=-2, 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 y-aqHiXUuqk1 for ; Sun, 17 Oct 2010 07:09:49 -0700 (PDT) Received: from imr-da03.mx.aol.com (imr-da03.mx.aol.com [205.188.105.145]) by core3.amsl.com (Postfix) with ESMTP id 2BDEC3A6A5E for ; Sun, 17 Oct 2010 07:09:49 -0700 (PDT) Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imr-da03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o9HEAtWC018043; Sun, 17 Oct 2010 10:10:55 -0400 Received: from HeinerHummel@aol.com by imo-da03.mx.aol.com (mail_out_v42.9.) id c.ec5.8b5b5b2 (45495); Sun, 17 Oct 2010 10:10:53 -0400 (EDT) Received: from magic-d19.mail.aol.com (magic-d19.mail.aol.com [172.19.155.135]) by cia-mc08.mx.aol.com (v129.5) with ESMTP id MAILCIAMC082-b1b74cbb03ed12d; Sun, 17 Oct 2010 10:10:53 -0400 From: HeinerHummel@aol.com Message-ID: <12ebc4.2456ea8a.39ec5ded@aol.com> Date: Sun, 17 Oct 2010 10:10:53 EDT To: dino@cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_12ebc4.2456ea8a.39ec5ded_boundary" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 95.91.18.180 X-AOL-SENDER: HeinerHummel@aol.com Cc: jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 17 Oct 2010 14:09:50 -0000 --part1_12ebc4.2456ea8a.39ec5ded_boundary Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 17.10.2010 14:27:12 Westeurop=E4ische Sommerzeit schrei= bt =20 dino@cisco.com: > > So why don't you just use DNS (LISP 2.0) instead of the ALT router? =20 > It would be much faster if you get all > the info by just one query! > > Heiner Because when a mapping database entry changes in a set of ETRs, they =20 not only need to update all the ITR/PITR caches but the ALT-caches as =20 well since DNS is a "intermediate caching system". That makes the =20 mechanism difficult and non-scalable. Dino Right. And all of this is needed because you and all of the IETF experts= =20 (I like to exclude Dima) keep up sticking to an immensely miserable =20 paradigm, which says "the world needs to know where I am reachable". =20 I did point out multiple times: The postal network never maintains a knowledge database about where anyon= e=20 lives. And because post office PO-x doesn't do it, it doesn't inform post office= =20 PO-y for updating its database either. The postal service delivers the letter to the indicated destination bin.= =20 The postman throws the letter into the indicated mailbox (and doesn't care whether thereafter the right perso= n=20 will get to read it or not) or he returns it to the sender in case he=20 cannot find out the appropriate mailbox. This system works and has no scalability problems at all. =20 Although LISP employs some "mediator" it still sticks to the mentioned =20 paradigm instead of=20 kicking away the hereby caused problems. =20 Heiner =20 =20 --part1_12ebc4.2456ea8a.39ec5ded_boundary Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <= FONT id=3Drole_document color=3D#000000 size=3D2 face=3DArial>
In einer eMail vom 17.10.2010 14:27:12 Westeurop=E4ische Sommerzeit= schreibt=20 dino@cisco.com:
>
> So why don't you just use DN= S (LISP 2.0) instead of=20 the ALT router? 
> It would be much faster if you get all>=20 the info by just one query!
>
> Heiner

Because when= a=20 mapping database entry changes in a set of ETRs, they 
not only= need=20 to update all the ITR/PITR caches but the ALT-caches as 
well= since=20 DNS is a "intermediate caching system". That makes the 
mechani= sm=20 difficult and non-scalable.

Dino
Right. And all of this is needed because you and all of the IETF= =20 experts (I like to exclude Dima) keep up sticking to an immensely miserabl= e=20 paradigm, which says "the world needs to know where I am reachable".
 
I did point out multiple times:
The postal network never maintains a knowledge database about=20 where anyone lives.
And because post office PO-x doesn't do it, it doesn't inform po= st=20 office  PO-y for updating its database either.
The postal service delivers the letter to the indicated destination&n= bsp;=20 bin. The postman throws the letter into
the indicated mailbox (and doesn't care whether thereafter the right= person=20 will get to read it or not) or he returns it to the sender in case he cann= ot=20 find out the appropriate mailbox.
This system works and has no scalability problems at all.
   
Although LISP employs some "mediator" it still sticks to the mentione= d=20 paradigm instead of
kicking away the hereby caused problems.
 
Heiner
 
 
--part1_12ebc4.2456ea8a.39ec5ded_boundary-- From dino@cisco.com Sun Oct 17 08:41:30 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12163A69FF for ; Sun, 17 Oct 2010 08:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.539 X-Spam-Level: X-Spam-Status: No, score=-11.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, GB_I_LETTER=-2, 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 E7rE5yEM+mNU for ; Sun, 17 Oct 2010 08:41:28 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8AD363A6983 for ; Sun, 17 Oct 2010 08:41:27 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKO2ukyrRN+K/2dsb2JhbAChK3GnQ5tQhUkEhFSFdoMF X-IronPort-AV: E=Sophos;i="4.57,342,1283731200"; d="scan'208";a="202087023" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Oct 2010 15:42:54 +0000 Received: from [10.251.181.134] (sjc-vpn3-623.cisco.com [10.21.66.111]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9HFgri6013902; Sun, 17 Oct 2010 15:42:53 GMT Message-Id: <7D5776EC-0FCA-4EB8-845B-7066EC0170EC@cisco.com> From: Dino Farinacci To: HeinerHummel@aol.com In-Reply-To: <12ebc4.2456ea8a.39ec5ded@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 17 Oct 2010 08:42:45 -0700 References: <12ebc4.2456ea8a.39ec5ded@aol.com> X-Mailer: Apple Mail (2.936) Cc: jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 17 Oct 2010 15:41:31 -0000 > In einer eMail vom 17.10.2010 14:27:12 Westeurop=E4ische Sommerzeit =20= > schreibt dino@cisco.com: > > > > So why don't you just use DNS (LISP 2.0) instead of the ALT router? > > It would be much faster if you get all > > the info by just one query! > > > > Heiner > > Because when a mapping database entry changes in a set of ETRs, they > not only need to update all the ITR/PITR caches but the ALT-caches as > well since DNS is a "intermediate caching system". That makes the > mechanism difficult and non-scalable. > > Dino > Right. And all of this is needed because you and all of the IETF =20 > experts (I like to exclude Dima) keep up sticking to an immensely =20 > miserable paradigm, which says "the world needs to know where I am =20 > reachable". > > I did point out multiple times: > The postal network never maintains a knowledge database about where =20= > anyone lives. > And because post office PO-x doesn't do it, it doesn't inform post =20 > office PO-y for updating its database either. > The postal service delivers the letter to the indicated destination =20= > bin. The postman throws the letter into > the indicated mailbox (and doesn't care whether thereafter the right =20= > person will get to read it or not) or he returns it to the sender in =20= > case he cannot find out the appropriate mailbox. > This system works and has no scalability problems at all. The post office does not care about latency. LISP wants to provide for =20= good packet performance, so all packets between ITR/PITR to ETR are of =20= stretch 1. Dino > Although LISP employs some "mediator" it still sticks to the =20 > mentioned paradigm instead of > kicking away the hereby caused problems. > > Heiner > > From damien.saucez@uclouvain.be Mon Oct 18 02:47:48 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6283A6CFC for ; Mon, 18 Oct 2010 02:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.572, 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 z8EIGrjhbNT5 for ; Mon, 18 Oct 2010 02:47:47 -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 E7A2D3A6A77 for ; Mon, 18 Oct 2010 02:47:46 -0700 (PDT) Received: from sleipnier.dhcp.info.ucl.ac.be (sleipnier.dhcp.info.ucl.ac.be [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 B9E8EF26AB for ; Mon, 18 Oct 2010 11:48:50 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be B9E8EF26AB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1287395330; bh=g86XtbAOPxmDC26qMWoLDgOxc+mch4NK0kLRIUNb84E=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=dSM8eJK++Meel4vaYpRnGLWo2PS5RsqpzfacPQWLk639VnXtWUCRtkUWmi6T+hq8B nbpmoPHDD+LKWpzFtKkYOJZ2Piz5IydOV0eR7E0clTjGdpHXUiJeXNnapKvr8tyH6/ hfcTTq4FVxm2CETbEfX4uWui7zQi0CHmgf+GGTh8= From: Damien Saucez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Oct 2010 11:48:50 +0200 References: <20101018094554.0DCA43A6D49@core3.amsl.com> To: lisp@ietf.org Message-Id: <2642328C-51AE-4C55-B521-27BB06D2CA49@uclouvain.be> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: clamav-milter 0.96.2-exp at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: B9E8EF26AB.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Subject: [lisp] Fwd: New Version Notification for draft-saucez-lisp-iterable-mapping-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 09:47:49 -0000 FYI Damien Saucez Begin forwarded message: > From: IETF I-D Submission Tool > Date: 18 Oct 2010 11:45:54 GMT+02:00 > To: damien.saucez@uclouvain.be > Cc: olivier.bonaventure@uclouvain.be > Subject: New Version Notification for = draft-saucez-lisp-iterable-mapping-00 >=20 >=20 > A new version of I-D, draft-saucez-lisp-iterable-mapping-00.txt has = been successfully submitted by Damien Saucez and posted to the IETF = repository. >=20 > Filename: draft-saucez-lisp-iterable-mapping > Revision: 00 > Title: LISP Iterable Mappings > Creation_date: 2010-10-18 > WG ID: Independent Submission > Number_of_pages: 11 >=20 > Abstract: > The Mapping System is a key component of the Locator Identifier > Separation Protocol (LISP). In this document, we describe Iterable > Mappings allowing the mappings to point to Map-Server addresses > instead of ETR addresses. Iterable mappings open the possibility of > performing iterative queries that could be used to deploy mapping > systems without requiring overlays or to optimize current mapping > systems. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 From hannu.flinck@nsn.com Mon Oct 18 09:28:53 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738BE3A6D8A for ; Mon, 18 Oct 2010 09:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWFaHb6WdWty for ; Mon, 18 Oct 2010 09:28:52 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 379CD3A6AF9 for ; Mon, 18 Oct 2010 09:28:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9IGUHIs028985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Oct 2010 18:30:20 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9IGUGn5022128; Mon, 18 Oct 2010 18:30:17 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Oct 2010 18:30:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Oct 2010 19:30:02 +0300 Message-ID: <26E5D1C5D5365D47B147E5E62FC73585018CFD8E@FIESEXC035.nsn-intra.net> In-Reply-To: <20101015202932.CA3676BE5CF@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] EID allocation / ALT base Thread-Index: Actsp7Eu8cA+NGinRHuT9Zj7pQ+UkwB8NHwg References: <20101015202932.CA3676BE5CF@mercury.lcs.mit.edu> From: "Flinck, Hannu (NSN - FI/Espoo)" To: "Noel Chiappa" , X-OriginalArrivalTime: 18 Oct 2010 16:30:04.0111 (UTC) FILETIME=[B7D57DF0:01CB6EE1] Subject: Re: [lisp] EID allocation / ALT base 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, 18 Oct 2010 16:28:53 -0000 Hello, I think that building on top of "administratively aggregatable" allocation system of the EID space is going to lead to as rigid outcome as the current IANA and RIR allocated addressing solution is. It will have exactly the same drawbacks and limitations as the current one. Allocation boundaries will degenerate as the networks keep on evolving to meet the real life needs (many times unforeseeable new use cases). And suddenly the original optimal allocation scheme becomes a burden or even a show stopper. If the ALT routing systems scalability depends exactly on how the original aggregatable EID allocation was done and can not be touched after the allocation then we have a problem again. (You may optimistically think that this time we will get this alright since we have experienced this problem earlier, but I am afraid that the demand of addressable entities are highly unpredictable as it depends to far too many factors, not only on technology but economics etc.)=20 If EIDs were truly PI addresses as touted then binding them into aggregatable (or topological) allocations would restrict the applicability of the independence of these addresses, after the system starts to evolve.=20 The routing system would become more durable if we would allow reshuffling of EIDs with their aggregation points. After all, we still have RLOCs that aggregate independently from EIDs (ref. identifier locator separation). The xTRs cloud select with the help of Mapping Servers the "optimal" Map Server where to register its EIDs. This selection should be such that it facilitates locality as well as aggregation in a dynamic way. In fact, the question for resolving an EID into an RLOC is the one of which of the Mapping Servers know the locator of the EID or the locator of the one who knows the locator of the EID. This doesn't require any fixed allocation of EIDs or grouping of EIDs. (We wrote about this in our proposal for compact routing based mapping system. I would be happy to summarize that.) I would even go so far that the end systems cloud generate their own EIDs (self certified EID would be preferable) and try to register that into the mapping system that ensures that each registered EID is unique. In other words doesn't allow duplicate registrations in the mapping system. The issue of using EIDs in the intardomain routing is a separate issue, but easily solvable, ref. IPv6 autoconf. No real issue there. =20 =20 Best regards Hannu =20 >-----Original Message----- >From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 >Behalf Of Noel Chiappa >Sent: Friday, October 15, 2010 23:30 >To: lisp@ietf.org >Cc: jnc@mercury.lcs.mit.edu >Subject: Re: [lisp] EID allocation / ALT base > > > > From: "Joel M. Halpern" > > > If there is a single EID prefix, then it seems that=20 >someone has to be > > authorized to give out EIDs from that space. According=20 >to some rules. > > WHo do we give that job to? > >The IANA, and delegated from them to the RIRs? The mechanisms=20 >are all there already, why would we want to reinvent the wheel? > > > do they have to run some ALT routers, or does it suffice=20 >for them to > > require that all entities which receive direct=20 >allocations from that > > agency must run ALT routers and must peer with each other? > >How does DNS do it, for the top-level domains authorized by=20 >ICANN/IANA? There have to be root servers, etc. Again,=20 >something similar here, I would think. > > Noel >_______________________________________________ >lisp mailing list >lisp@ietf.org >https://www.ietf.org/mailman/listinfo/lisp > From root@core3.amsl.com Mon Oct 18 12:00:02 2010 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1A3F23A6DE0; Mon, 18 Oct 2010 12:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101018190002.1A3F23A6DE0@core3.amsl.com> Date: Mon, 18 Oct 2010 12:00:02 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-alt-05.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 19:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Alternative Topology (LISP+ALT) Author(s) : V. Fuller, et al. Filename : draft-ietf-lisp-alt-05.txt Pages : 28 Date : 2010-10-18 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-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-alt-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18114754.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 18 12:00:02 2010 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2D10A3A6E33; Mon, 18 Oct 2010 12:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101018190002.2D10A3A6E33@core3.amsl.com> Date: Mon, 18 Oct 2010 12:00:02 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-ms-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: Mon, 18 Oct 2010 19:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Author(s) : V. Fuller, D. Farinacci Filename : draft-ietf-lisp-ms-06.txt Pages : 14 Date : 2010-10-18 This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-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-ms-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18114812.I-D@ietf.org> --NextPart-- From vaf@cisco.com Mon Oct 18 12:52:53 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8533A6ABB for ; Mon, 18 Oct 2010 12:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 7DBeXiE63Nf4 for ; Mon, 18 Oct 2010 12:52:51 -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 866763A6B02 for ; Mon, 18 Oct 2010 12:52:51 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADpDvEyrRN+K/2dsb2JhbACTTI19caQnnFiFSQSEVA X-IronPort-AV: E=Sophos;i="4.57,346,1283731200"; d="scan'208";a="605959601" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 18 Oct 2010 19:54:20 +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 o9IJsKFx029476 for ; Mon, 18 Oct 2010 19:54:20 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 5ACD2896952; Mon, 18 Oct 2010 12:54:20 -0700 (PDT) Date: Mon, 18 Oct 2010 12:54:20 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20101018195420.GA87614@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-ms-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: Mon, 18 Oct 2010 19:52:53 -0000 FYI. There are no content changes to this version, only an update to the other draft references and a new version number to prevent expiration. One of the agenda items for the upcoming LISP-WG meeting will be a discussion of the need for a "Map-Notify" message, which would, among other functions, provide an acknowledgement mechanism for Map-Register events. That discussion may result in changes to LISP-MS that will be reflected in a future -07 version. --Vince (for the LISP-MS authors) ----- Forwarded message from IETF I-D Submission Tool ----- Date: Mon, 18 Oct 2010 11:48:12 -0700 (PDT) From: IETF I-D Submission Tool To: vaf@cisco.com Cc: dino@cisco.com Subject: New Version Notification for draft-ietf-lisp-ms-06 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0AAD4zvExAqmIgkWdsb2JhbACDH5APAQGNfRUBAQEBCQsKBxEFHaN8iiKSJYEigzN0BIRUhXY A new version of I-D, draft-ietf-lisp-ms-06.txt has been successfully submitted by Vince Fuller and posted to the IETF repository. Filename: draft-ietf-lisp-ms Revision: 06 Title: LISP Map Server Creation_date: 2010-10-18 WG ID: lisp Number_of_pages: 14 Abstract: This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. The IETF Secretariat. ----- End forwarded message ----- From vaf@cisco.com Mon Oct 18 12:58:22 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1C13A6BF8 for ; Mon, 18 Oct 2010 12:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.144 X-Spam-Level: X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 BFNK7lZaxc6C for ; Mon, 18 Oct 2010 12:58:22 -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 021AB3A6BB5 for ; Mon, 18 Oct 2010 12:58:21 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACREvEyrR7H+/2dsb2JhbACTTI19caQ4nFiFSQSEVA X-IronPort-AV: E=Sophos;i="4.57,346,1283731200"; d="scan'208";a="372122662" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 18 Oct 2010 19:59:51 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9IJxpwY011210 for ; Mon, 18 Oct 2010 19:59:51 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id B48CE896A03; Mon, 18 Oct 2010 12:59:50 -0700 (PDT) Date: Mon, 18 Oct 2010 12:59:50 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20101018195950.GB87614@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-05 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 19:58:22 -0000 FYI. There are no content changes to this version, only an update to the other draft references and a new version number to prevent expiration. Because there have been no functional changes to the -ALT spec since -04 was published in April and none are planned as a result of the upcoming WG meeting, it is probably time to consider Last Call for this document. --Vince (for the LISP+ALT co-authors) ----- Forwarded message from IETF I-D Submission Tool ----- Date: Mon, 18 Oct 2010 11:47:54 -0700 (PDT) From: IETF I-D Submission Tool To: vaf@cisco.com Cc: dino@cisco.com, dmm@cisco.com, darlewis@cisco.com Subject: New Version Notification for draft-ietf-lisp-alt-05 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0AAD4zvExAqmIgkWdsb2JhbACDH5APAQGNfRUBAQEBCQsKBxEFHaN8iiKSJYEigzN0BIRUhXY A new version of I-D, draft-ietf-lisp-alt-05.txt has been successfully submitted by Vince Fuller and posted to the IETF repository. Filename: draft-ietf-lisp-alt Revision: 05 Title: LISP Alternative Topology (LISP+ALT) Creation_date: 2010-10-18 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 jnc@mercury.lcs.mit.edu Tue Oct 19 19:04:37 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E451B3A6984 for ; Tue, 19 Oct 2010 19:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 LMRwpNlO3VY9 for ; Tue, 19 Oct 2010 19:04:33 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 9AE863A68C5 for ; Tue, 19 Oct 2010 19:04:33 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 670B76BE55D; Tue, 19 Oct 2010 22:06:04 -0400 (EDT) To: lisp@ietf.org Message-Id: <20101020020604.670B76BE55D@mercury.lcs.mit.edu> Date: Tue, 19 Oct 2010 22:06:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] EID allocation / ALT base 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, 20 Oct 2010 02:04:37 -0000 > From: "Flinck, Hannu (NSN - FI/Espoo)" > I think that building on top of "administratively aggregatable" > allocation system of the EID space is going to lead to as rigid outcome > as the current IANA and RIR allocated addressing solution is. > ... > Allocation boundaries will degenerate as the networks keep on evolving > to meet the real life needs (many times unforeseeable new use cases). Perhaps... but asking everyone to first renumber into some sort of optimal allocation scheme, and then stay there, is I think not workable. We just have to build a system that can deal with scattered allocations. > If the ALT routing systems scalability depends exactly on how the > original aggregatable EID allocation was done Your comment co-mingles two separate issues. One is aggregability of LEIDs in general for purposes of resolution (which I think is a concern); and the second is aggregability issues which are specific to ALT. The latter is not a concern to me, because I suspect we will want to replace the ALT long before LISP gets widely deployed (if LISP does get there), because the ALT has a number of issues. And needless to say, discarding the ALT means there is no need to 'solve' any ALT-specific problems. (As I keep saying, but people seem to keep not hearing, I think the ALT was a really clever way to build a distributed mapping system without having to write a whole bunch of new code, but it definitely has some aspects that make it not the best choice for a _large_ distributed mapping system. So I expect it to be replaced 'soon' - so why people keep paying any attention at all to its problems is completely beyond me. There is at least one design out there for an alternative - LISP-TREE - and the Barcelona guys did some great work, documented in their paper "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System", modelling various approaches, to give a lot of backup to why that design is a good direction to go. I don't think we'll wind up with that design exactly - using DNS has some issues - but something like that, yes.) > If EIDs were truly PI addresses as touted then binding them into > aggregatable (or topological) allocations would restrict the > applicability of the independence of these addresses As to the more interesting point, aggregability of LEIDs in general for purposes of resolution (i.e. looking up mappings), there are unvoidable fundamentals. The completely unrelated organizations A and B may already have been assigned LEID's E and E+1 by the RIRs, and the question is 'how do you aggregate them for {LEID->RLOC} binding lookup in a way that scales, but also has other good properties that people want, like not being tied into a single binding provider' (assuming, of course, that neither E not E+1 wants to renumber). We can do scaling, but at the cost of requiring the holder of E+1 to deal with the same registry as the holder of E - this is similar to the current DNS situation, where all holders of .COM DNS names have to deal with Verisign. (Effectively, albeit at one level of organizational remove; since they interact with registrars, who interact with the registry.) We have previously discussed (sorry, too lazy to find it in the WG archive) the possibility of allowing alternate registries, so that if you don't like registry A, you can deal with registry B (much as in the DNS you can specifiy more than one authoritative server for a given zone), but it's unclear whether we will need to do this - the Internet seems to work quite OK with only one registry for .COM. Yes, this means that LEID's have some aspect of 'connectedness' to totally unrelated LEID's, because of the 'aggregation' requirement. However, that's unavoidable - it's an artifact of the way the names are assigned. We have to be able to aggregate them in the _directory_, but that doesn't imply any properties other than that. I mean, abb.com and abc.com have nothing to do with one another either, right - even though they are 'next to' each other? The choice is simple, if painful: we have large namespace where we want to be able to do a directory (look up mappings, really), and we want that directory to be distributed (as opposed to one giant flat directory). So if we want to divide it up, to distribute the directory, _and_ we have to take what the _existing_ allocation of names in that namespace is, we wind up with a situation where unrelated things share a directory branch. Would you rather have a giant flat directory? > The routing system would become more durable if we would allow > reshuffling of EIDs with their aggregation points. I don't see how. The issue is simply 'how do we build a distributed resolution system, given names which may be contiguous in a namespace, but are otherwise unrelated'. That mapping step is completely unrelated to everything else. We need to make sure that the mapping system has the properties we need (in terms of speed, robustness, etc as well as user issues like cost, provider lock-in, etc), yes, but we simply need to work out what those required properties are, and then we can design the mapping system to meet them. > The xTRs cloud select with the help of Mapping Servers the "optimal" > Map Server where to register its EIDs. This selection should be such > that it facilitates locality as well as aggregation in a dynamic way. This seems to be in the context of ALT? Again, I suggest you look at something like LISP-TREE, to see how an alternative distributed mapping system would work, and then see if there is some part of your concern that's generic, and not ALT-specific. > In fact, the question for resolving an EID into an RLOC is the one of > which of the Mapping Servers know the locator of the EID or the locator > of the one who knows the locator of the EID. This doesn't require any > fixed allocation of EIDs or grouping of EIDs. (We wrote about this in > our proposal for compact routing based mapping system. ... ) It's certainly possibly to build a distributed mapping system in which any particular mapping can be on any arbitrary server, and there is some algorithm (along with data) to find it. I'm not sure we need - or want - to go in that direction, though. I'd want to see more discussion about what the advantages, and costs, are of such an approach. In particular, is it really that much more robust, and is any extra robustness worth what is certain to be a fair amount of extra complexity and overhead (and perhaps slowness too). > I would even go so far that the end systems cloud generate their own > EIDs (self certified EID would be preferable) and try to register that > into the mapping system that ensures that each registered EID is > unique. For LEID's which are either HIP EIDs, or perhap IPvp6 addresses, that might work. The IPv4 space is not big enough to do that, and very-high quality support of IPv4 is a necessity. (And no, I don't want to debate that point.) > In other words doesn't allow duplicate registrations in the mapping > system. It is one thing to find _a_ mapping _somewhere_ in a distributed database where mappings are kept on arbitrary servers, _if_ such a mapping exists. It's something entirely different to basically guarantee that there is no such mapping _anywhere_ in such a distributed database - at least without even more overhead, complexity, etc. > The issue of using EIDs in the intardomain routing is a separate issue, > but easily solvable ... No real issue there. I'm really at a loss to understand what you mean here, becase if LEID's are allocated without regard to actual network connection location, routing tables are going to grow even faster... Noel From vaf@cisco.com Wed Oct 20 00:01:01 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4092C3A69CA for ; Wed, 20 Oct 2010 00:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 5JP4U+i1FtTk for ; Wed, 20 Oct 2010 00:01:00 -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 37F073A63CA for ; Wed, 20 Oct 2010 00:01:00 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAQxvkytJV2Y/2dsb2JhbAChWHGjapwvhUoEhFWRIA X-IronPort-AV: E=Sophos;i="4.57,354,1283731200"; d="scan'208";a="172815610" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 20 Oct 2010 07:02:32 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o9K72V3h007859; Wed, 20 Oct 2010 07:02:32 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 15ACF8A5D1B; Wed, 20 Oct 2010 00:02:31 -0700 (PDT) Date: Wed, 20 Oct 2010 00:02:30 -0700 From: Vince Fuller To: Noel Chiappa Message-ID: <20101020070230.GA76872@vaf-mac1.cisco.com> References: <20101020020604.670B76BE55D@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101020020604.670B76BE55D@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.2.3i Cc: lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 20 Oct 2010 07:01:01 -0000 On Tue, Oct 19, 2010 at 10:06:04PM -0400, Noel Chiappa wrote: > > > From: "Flinck, Hannu (NSN - FI/Espoo)" > > > I think that building on top of "administratively aggregatable" > > allocation system of the EID space is going to lead to as rigid outcome > > as the current IANA and RIR allocated addressing solution is. > > ... > > Allocation boundaries will degenerate as the networks keep on evolving > > to meet the real life needs (many times unforeseeable new use cases). > > Perhaps... but asking everyone to first renumber into some sort of optimal > allocation scheme, and then stay there, is I think not workable. We just have > to build a system that can deal with scattered allocations. > > > > If the ALT routing systems scalability depends exactly on how the > > original aggregatable EID allocation was done > > Your comment co-mingles two separate issues. One is aggregability of LEIDs in > general for purposes of resolution (which I think is a concern); and the > second is aggregability issues which are specific to ALT. The latter is not a > concern to me, because I suspect we will want to replace the ALT long before > LISP gets widely deployed (if LISP does get there), because the ALT has a > number of issues. And needless to say, discarding the ALT means there is no > need to 'solve' any ALT-specific problems. People seem to be forgetting that the ALT is a logical/virtual network that is composed of tunnels. If a particular EID block needs to move, it is a fairly simple matter to reconfigure the tunnel topology or change the Map Server registration so that the EID block can still be aggregated; none of the underlying switching topology needs to be touched. Yes, moving an EID block from an ETR in Sydney to an ETR in London means that their will be additional latency between the London ETR and a Map Server (or other ALT aggregation point) near Australia but that additional latency is limited to a few hundred milliseconds and is only applicable when doing a database looking (sending a Map Request and receiving a Map Reply, which occurs only when an ITR needs to find the ETR for the first time). Once the EID-to-RLOC mapping has been learned by an ITR that needs to communicate with the ETR, there will be no added latency on the data path between them. --Vince From dino@cisco.com Wed Oct 20 11:01:27 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213853A68B0 for ; Wed, 20 Oct 2010 11:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.192 X-Spam-Level: X-Spam-Status: No, score=-10.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_42=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 o95q+0o9W-3P for ; Wed, 20 Oct 2010 11:01:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 009713A6879 for ; Wed, 20 Oct 2010 11:01:25 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,356,1283731200"; d="scan'208";a="607040566" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 20 Oct 2010 18:02:57 +0000 Received: from [172.28.174.36] (sjc-vpn7-1941.cisco.com [10.21.151.149]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9KI2vgN019743; Wed, 20 Oct 2010 18:02:57 GMT Message-Id: <17F20455-C6A5-45EF-906E-8F0A8475798C@cisco.com> From: Dino Farinacci To: Vince Fuller In-Reply-To: <20101020070230.GA76872@vaf-mac1.cisco.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, 20 Oct 2010 11:02:57 -0700 References: <20101020020604.670B76BE55D@mercury.lcs.mit.edu> <20101020070230.GA76872@vaf-mac1.cisco.com> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 20 Oct 2010 18:01:27 -0000 > On Tue, Oct 19, 2010 at 10:06:04PM -0400, Noel Chiappa wrote: >> >>> From: "Flinck, Hannu (NSN - FI/Espoo)" >> >>> I think that building on top of "administratively aggregatable" >>> allocation system of the EID space is going to lead to as rigid >>> outcome >>> as the current IANA and RIR allocated addressing solution is. >>> ... >>> Allocation boundaries will degenerate as the networks keep on >>> evolving >>> to meet the real life needs (many times unforeseeable new use >>> cases). >> >> Perhaps... but asking everyone to first renumber into some sort of >> optimal >> allocation scheme, and then stay there, is I think not workable. We >> just have >> to build a system that can deal with scattered allocations. >> >> >>> If the ALT routing systems scalability depends exactly on how the >>> original aggregatable EID allocation was done >> >> Your comment co-mingles two separate issues. One is aggregability >> of LEIDs in >> general for purposes of resolution (which I think is a concern); >> and the >> second is aggregability issues which are specific to ALT. The >> latter is not a >> concern to me, because I suspect we will want to replace the ALT >> long before >> LISP gets widely deployed (if LISP does get there), because the ALT >> has a >> number of issues. And needless to say, discarding the ALT means >> there is no >> need to 'solve' any ALT-specific problems. > > People seem to be forgetting that the ALT is a logical/virtual > network that > is composed of tunnels. If a particular EID block needs to move, it > is a > fairly simple matter to reconfigure the tunnel topology or change > the Map > Server registration so that the EID block can still be aggregated; > none of > the underlying switching topology needs to be touched. I'd like to add to what Vince is saying. If a site gets an EID-prefix allocation called A, that prefix will indicate where the site registers the EID-prefix. Remember, the ALT topology follows addressing, unlike the underlying network today. If that same site needs more EID address space later and gets an allocation called B, and B is not in a common power-of-2 block with A, then the site will register to another map-server that is aggregating for that B space. In this case, there is no tunnel rehoming on the ALT. I'd also like to mention that the "ALT" is a logical topology. It is spec'ed to run BGP over GRE tunnels. But the way we have implemented this, the ALT runs in another VRF. And that VRF can run over any physical interface, logical interface, tunnel, VLAN, etc. and any routing protocol can be used on those VRF-specific interfaces. We will find these flexible options will be used by enterprises who will want to run a private mapping database system. And one form of this is no ALT at all, just map-servers configured as map-resolvers. > Yes, moving an EID block from an ETR in Sydney to an ETR in London > means > that their will be additional latency between the London ETR and a Map > Server (or other ALT aggregation point) near Australia but that > additional > latency is limited to a few hundred milliseconds and is only > applicable when > doing a database looking (sending a Map Request and receiving a Map > Reply, > which occurs only when an ITR needs to find the ETR for the first > time). Once > the EID-to-RLOC mapping has been learned by an ITR that needs to > communicate > with the ETR, there will be no added latency on the data path > between them. And there are many both protocol and implementation techniques to reduce how often Map-Requests are sent to the mapping database system. Dino > > --Vince > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hannu.flinck@nsn.com Fri Oct 22 07:00:06 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DC428C0DD for ; Fri, 22 Oct 2010 07:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_42=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 jyG9N1XB4IbG for ; Fri, 22 Oct 2010 07:00:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id ED57F28C0D9 for ; Fri, 22 Oct 2010 07:00:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9ME1a3D019466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 16:01:38 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9ME1TUC020675; Fri, 22 Oct 2010 16:01:36 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 16:01:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2010 17:01:31 +0300 Message-ID: <26E5D1C5D5365D47B147E5E62FC7358501952CDA@FIESEXC035.nsn-intra.net> In-Reply-To: <17F20455-C6A5-45EF-906E-8F0A8475798C@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] EID allocation / ALT base Thread-Index: ActwgQ5+75DkOyxHT1y8oY/Ybf5dDwBbYL9Q References: <20101020020604.670B76BE55D@mercury.lcs.mit.edu><20101020070230.GA76872@vaf-mac1.cisco.com> <17F20455-C6A5-45EF-906E-8F0A8475798C@cisco.com> From: "Flinck, Hannu (NSN - FI/Espoo)" To: "ext Dino Farinacci" , "Vince Fuller" X-OriginalArrivalTime: 22 Oct 2010 14:01:33.0040 (UTC) FILETIME=[A212F700:01CB71F1] Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] EID allocation / ALT base 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, 22 Oct 2010 14:00:06 -0000 Dino, Vince and Noel I agree what Vince and Dino are saying. No issue there. This shows the flexibility of ALT.=20 And I agree with Noel that that we can not ask everyone to renumber first.=20 I have noted the temporary nature of ALT. However, the operational practices that ALT reuses (=3D ISPs know how to operate BGP) are not = that temporary I am afraid. This because that even if the new ways promise benefits it requires retraining and changes of the supporting systems.=20 Noel wrote: >We can do scaling, but at the cost of requiring the holder of=20 >E+1 to deal with the same registry as the holder of E - this=20 >is similar to the current DNS situation, where all holders of=20 >.COM DNS names have to deal with Verisign. In the example you give, yes, but it can not be generalized to a case where there are many unrelated organizations, not only some (like A and B in your example).=20 Let's have n (n is large) independent organizations picking up at random LEIDs. Now each LEIDs needs to be registered into the distributed database. All selections of the registers that hold a piece of content of the full distributed database can be independent from each other. For example, you may use hashing that randomizes the selection (this is what the DTHs do), or you may try to locate the most responsive one (maybe based on the closeness, say using anycast).=20 What I was pointing out was the selection of the registers if that is more descriptive word for what I called as "aggregation points"=20 Noel wrote: > > The routing system would become more durable if we would allow > > reshuffling of EIDs with their aggregation points. > >I don't see how. The issue is simply 'how do we build a=20 >distributed resolution system, given names which may be=20 >contiguous in a namespace, but are otherwise unrelated'. I think that Vince and Dino gave in their responses a good example how: Vince wrote: "If a particular EID block needs to move, it is a fairly simple matter to reconfigure the tunnel topology or change the Map Server registration so that the EID block can still be aggregated; none of the underlying switching topology needs to be touched." =20 I am noting that if you can move the EID blocks move them so that the mapping system will able to scale well. Compact routing is a very good bench mark for scalability both in terms of the size of the routing table as well as stretch. (Here need to refer to the RRG write up about the "Compact routing based mapping system" for the details at this point.) Finally I agree with Noel that "... discarding the ALT means there is no need to 'solve' any ALT-specific problems."=20 Best regards Hannu >-----Original Message----- >From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 >Behalf Of ext Dino Farinacci >Sent: Wednesday, October 20, 2010 21:03 >To: Vince Fuller >Cc: Noel Chiappa; lisp@ietf.org >Subject: Re: [lisp] EID allocation / ALT base > >> On Tue, Oct 19, 2010 at 10:06:04PM -0400, Noel Chiappa wrote: >>> >>>> From: "Flinck, Hannu (NSN - FI/Espoo)" >>> >>>> I think that building on top of "administratively aggregatable" >>>> allocation system of the EID space is going to lead to as rigid=20 >>>> outcome as the current IANA and RIR allocated addressing solution=20 >>>> is. >>>> ... >>>> Allocation boundaries will degenerate as the networks keep on=20 >>>> evolving to meet the real life needs (many times unforeseeable new=20 >>>> use cases). >>> >>> Perhaps... but asking everyone to first renumber into some sort of=20 >>> optimal allocation scheme, and then stay there, is I think not=20 >>> workable. We just have to build a system that can deal with=20 >scattered=20 >>> allocations. >>> >>> >>>> If the ALT routing systems scalability depends exactly on how the=20 >>>> original aggregatable EID allocation was done >>> >>> Your comment co-mingles two separate issues. One is=20 >aggregability of=20 >>> LEIDs in general for purposes of resolution (which I think is a=20 >>> concern); and the second is aggregability issues which are specific=20 >>> to ALT. The latter is not a concern to me, because I=20 >suspect we will=20 >>> want to replace the ALT long before LISP gets widely deployed (if=20 >>> LISP does get there), because the ALT has a number of issues. And=20 >>> needless to say, discarding the ALT means there is no need=20 >to 'solve'=20 >>> any ALT-specific problems. >> >> People seem to be forgetting that the ALT is a=20 >logical/virtual network=20 >> that is composed of tunnels. If a particular EID block needs=20 >to move,=20 >> it is a fairly simple matter to reconfigure the tunnel topology or=20 >> change the Map Server registration so that the EID block can=20 >still be=20 >> aggregated; none of the underlying switching topology needs to be=20 >> touched. > >I'd like to add to what Vince is saying. > >If a site gets an EID-prefix allocation called A, that prefix=20 >will indicate where the site registers the EID-prefix.=20 >Remember, the ALT topology follows addressing, unlike the=20 >underlying network today. > >If that same site needs more EID address space later and gets=20 >an allocation called B, and B is not in a common power-of-2=20 >block with A, then the site will register to another=20 >map-server that is aggregating for that B space. > >In this case, there is no tunnel rehoming on the ALT. > >I'd also like to mention that the "ALT" is a logical topology.=20 >It is spec'ed to run BGP over GRE tunnels. But the way we have=20 >implemented this, the ALT runs in another VRF. And that VRF=20 >can run over any physical interface, logical interface,=20 >tunnel, VLAN, etc. and any routing protocol can be used on=20 >those VRF-specific interfaces. We will find these flexible=20 >options will be used by enterprises who will want to run a=20 >private mapping database system. And one form of this is no=20 >ALT at all, just map-servers configured as map-resolvers. > >> Yes, moving an EID block from an ETR in Sydney to an ETR in London=20 >> means that their will be additional latency between the=20 >London ETR and=20 >> a Map Server (or other ALT aggregation point) near Australia=20 >but that=20 >> additional latency is limited to a few hundred milliseconds and is=20 >> only applicable when doing a database looking (sending a Map Request=20 >> and receiving a Map Reply, which occurs only when an ITR=20 >needs to find=20 >> the ETR for the first time). Once the EID-to-RLOC mapping has been=20 >> learned by an ITR that needs to communicate with the ETR, there will=20 >> be no added latency on the data path between them. > >And there are many both protocol and implementation techniques=20 >to reduce how often Map-Requests are sent to the mapping=20 >database system. > >Dino > >> >> --Vince >> _______________________________________________ >> 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 Oct 22 07:09:44 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D0C28C106 for ; Fri, 22 Oct 2010 07:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, J_CHICKENPOX_42=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 Q-rakc40AyL3 for ; Fri, 22 Oct 2010 07:09:43 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 448AF28C100 for ; Fri, 22 Oct 2010 07:09:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 8B8A732288FF; Fri, 22 Oct 2010 07:11:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-188.clppva.btas.verizon.net [71.161.50.188]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 64502322806E; Fri, 22 Oct 2010 07:11:20 -0700 (PDT) Message-ID: <4CC19B85.2050708@joelhalpern.com> Date: Fri, 22 Oct 2010 10:11:17 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Flinck, Hannu (NSN - FI/Espoo)" , lisp@ietf.org References: <20101020020604.670B76BE55D@mercury.lcs.mit.edu><20101020070230.GA76872@vaf-mac1.cisco.com> <17F20455-C6A5-45EF-906E-8F0A8475798C@cisco.com> <26E5D1C5D5365D47B147E5E62FC7358501952CDA@FIESEXC035.nsn-intra.net> In-Reply-To: <26E5D1C5D5365D47B147E5E62FC7358501952CDA@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] EID allocation / ALT base 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, 22 Oct 2010 14:09:44 -0000 You refer to an organization picking some random LEID. I do not believe that is contemplated. The following is what I understand to be our intentions. In IPv4, for organizations which have PI space, they can use that for LEIDs. However, the general case will be that organizations request an assignment of an LEID. That assignment will come with a (list of) ALT participants who can maintain the mapping information in the ALT for the provider. For the case where an organization has PI that they are using, they will either have to register with someone already handling the superblock in the ALT, or they will have to arrange (either by running, or paying someone to run) for suitable devices to handle that block in the ALT. In general, the structure is that the ALT structure will mirror the address allocation structure. Even in IPv4, it is presumed that the larger number of entities would use assigned EiDs rather than using their PIs. (If the only folks needing LISP were on the order of the current PI space we would not be needing to solve an address space GROWTH problem.) There are other cases, outside of the purview of the WG, where other ALT operational structures, such as privately operated sets for VPNs, will obtain. Yours, Joel On 10/22/2010 10:01 AM, Flinck, Hannu (NSN - FI/Espoo) wrote: > Dino, Vince and Noel > > I agree what Vince and Dino are saying. No issue there. This shows the > flexibility of ALT. > > And I agree with Noel that that we can not ask everyone to renumber > first. > I have noted the temporary nature of ALT. However, the operational > practices that ALT reuses (= ISPs know how to operate BGP) are not that > temporary I am afraid. This because that even if the new ways promise > benefits it requires retraining and changes of the supporting systems. > > Noel wrote: > >> We can do scaling, but at the cost of requiring the holder of >> E+1 to deal with the same registry as the holder of E - this >> is similar to the current DNS situation, where all holders of >> .COM DNS names have to deal with Verisign. > > In the example you give, yes, but it can not be generalized to a case > where there are many unrelated organizations, not only some (like A and > B in your example). > Let's have n (n is large) independent organizations picking up at random > LEIDs. Now each LEIDs needs to be registered into the distributed > database. All selections of the registers that hold a piece of content > of the full distributed database can be independent from each other. For > example, you may use hashing that randomizes the selection (this is what > the DTHs do), or you may try to locate the most responsive one (maybe > based on the closeness, say using anycast). > > What I was pointing out was the selection of the registers if that is > more descriptive word for what I called as "aggregation points" > > Noel wrote: > >> > The routing system would become more durable if we would allow >> > reshuffling of EIDs with their aggregation points. >> >> I don't see how. The issue is simply 'how do we build a >> distributed resolution system, given names which may be >> contiguous in a namespace, but are otherwise unrelated'. > > I think that Vince and Dino gave in their responses a good example how: > > Vince wrote: > > "If a particular EID block needs to move, it is a fairly simple matter > to reconfigure the tunnel topology or change the Map Server registration > so that the EID block can still be aggregated; none of the underlying > switching topology needs to be touched." > > > I am noting that if you can move the EID blocks move them so that the > mapping system will able to scale well. Compact routing is a very good > bench mark for scalability both in terms of the size of the routing > table as well as stretch. (Here need to refer to the RRG write up about > the "Compact routing based mapping system" for the details at this > point.) > > Finally I agree with Noel that "... discarding the ALT means there is no > need to 'solve' any ALT-specific problems." > > > Best regards > Hannu > > >> -----Original Message----- >> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On >> Behalf Of ext Dino Farinacci >> Sent: Wednesday, October 20, 2010 21:03 >> To: Vince Fuller >> Cc: Noel Chiappa; lisp@ietf.org >> Subject: Re: [lisp] EID allocation / ALT base >> >>> On Tue, Oct 19, 2010 at 10:06:04PM -0400, Noel Chiappa wrote: >>>> >>>>> From: "Flinck, Hannu (NSN - FI/Espoo)" >>>> >>>>> I think that building on top of "administratively aggregatable" >>>>> allocation system of the EID space is going to lead to as rigid >>>>> outcome as the current IANA and RIR allocated addressing solution >>>>> is. >>>>> ... >>>>> Allocation boundaries will degenerate as the networks keep on >>>>> evolving to meet the real life needs (many times unforeseeable new >>>>> use cases). >>>> >>>> Perhaps... but asking everyone to first renumber into some sort of >>>> optimal allocation scheme, and then stay there, is I think not >>>> workable. We just have to build a system that can deal with >> scattered >>>> allocations. >>>> >>>> >>>>> If the ALT routing systems scalability depends exactly on how the >>>>> original aggregatable EID allocation was done >>>> >>>> Your comment co-mingles two separate issues. One is >> aggregability of >>>> LEIDs in general for purposes of resolution (which I think is a >>>> concern); and the second is aggregability issues which are specific >>>> to ALT. The latter is not a concern to me, because I >> suspect we will >>>> want to replace the ALT long before LISP gets widely deployed (if >>>> LISP does get there), because the ALT has a number of issues. And >>>> needless to say, discarding the ALT means there is no need >> to 'solve' >>>> any ALT-specific problems. >>> >>> People seem to be forgetting that the ALT is a >> logical/virtual network >>> that is composed of tunnels. If a particular EID block needs >> to move, >>> it is a fairly simple matter to reconfigure the tunnel topology or >>> change the Map Server registration so that the EID block can >> still be >>> aggregated; none of the underlying switching topology needs to be >>> touched. >> >> I'd like to add to what Vince is saying. >> >> If a site gets an EID-prefix allocation called A, that prefix >> will indicate where the site registers the EID-prefix. >> Remember, the ALT topology follows addressing, unlike the >> underlying network today. >> >> If that same site needs more EID address space later and gets >> an allocation called B, and B is not in a common power-of-2 >> block with A, then the site will register to another >> map-server that is aggregating for that B space. >> >> In this case, there is no tunnel rehoming on the ALT. >> >> I'd also like to mention that the "ALT" is a logical topology. >> It is spec'ed to run BGP over GRE tunnels. But the way we have >> implemented this, the ALT runs in another VRF. And that VRF >> can run over any physical interface, logical interface, >> tunnel, VLAN, etc. and any routing protocol can be used on >> those VRF-specific interfaces. We will find these flexible >> options will be used by enterprises who will want to run a >> private mapping database system. And one form of this is no >> ALT at all, just map-servers configured as map-resolvers. >> >>> Yes, moving an EID block from an ETR in Sydney to an ETR in London >>> means that their will be additional latency between the >> London ETR and >>> a Map Server (or other ALT aggregation point) near Australia >> but that >>> additional latency is limited to a few hundred milliseconds and is >>> only applicable when doing a database looking (sending a Map Request >>> and receiving a Map Reply, which occurs only when an ITR >> needs to find >>> the ETR for the first time). Once the EID-to-RLOC mapping has been >>> learned by an ITR that needs to communicate with the ETR, there will >>> be no added latency on the data path between them. >> >> And there are many both protocol and implementation techniques >> to reduce how often Map-Requests are sent to the mapping >> database system. >> >> Dino >> >>> >>> --Vince >>> _______________________________________________ >>> 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 hannu.flinck@nsn.com Fri Oct 22 07:29:27 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D44128C0E8 for ; Fri, 22 Oct 2010 07:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_42=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 9u-gEWjIOGmt for ; Fri, 22 Oct 2010 07:29:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 960A93A68AB for ; Fri, 22 Oct 2010 07:29:25 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9MEV2g0029836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 16:31:02 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9MEV16f025012; Fri, 22 Oct 2010 16:31:02 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 16:31:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2010 17:31:00 +0300 Message-ID: <26E5D1C5D5365D47B147E5E62FC7358501952D10@FIESEXC035.nsn-intra.net> In-Reply-To: <4CC19B85.2050708@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] EID allocation / ALT base Thread-Index: Actx8wQcwOUXRrrNQvCWsXJvJxXu9gAALu+Q References: <20101020020604.670B76BE55D@mercury.lcs.mit.edu><20101020070230.GA76872@vaf-mac1.cisco.com> <17F20455-C6A5-45EF-906E-8F0A8475798C@cisco.com> <26E5D1C5D5365D47B147E5E62FC7358501952CDA@FIESEXC035.nsn-intra.net> <4CC19B85.2050708@joelhalpern.com> From: "Flinck, Hannu (NSN - FI/Espoo)" To: "ext Joel M. Halpern" , X-OriginalArrivalTime: 22 Oct 2010 14:31:02.0417 (UTC) FILETIME=[C0B47810:01CB71F5] Subject: Re: [lisp] EID allocation / ALT base 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, 22 Oct 2010 14:29:28 -0000 Hello Joel I know it is not contemplated. But it might be short sighted to build from hierarchically administrated allocation structure, though. =20 >In general, the structure is that the ALT structure will=20 >mirror the address allocation structure. Yes, this is fine as long as the allocations are based on virtual topology that can be changed (or more accurately the registrar/aggregation points can be changed) if and when the system takes off and starts to evolve. This is how I understood Vince's mail. =20 Best regards Hannu >-----Original Message----- >From: ext Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 >Sent: Friday, October 22, 2010 17:11 >To: Flinck, Hannu (NSN - FI/Espoo); lisp@ietf.org >Subject: Re: [lisp] EID allocation / ALT base > >You refer to an organization picking some random LEID. >I do not believe that is contemplated. >The following is what I understand to be our intentions. > >In IPv4, for organizations which have PI space, they can use=20 >that for LEIDs. However, the general case will be that=20 >organizations request an assignment of an LEID. That=20 >assignment will come with a (list of) ALT participants who can=20 >maintain the mapping information in the ALT for the provider. > >For the case where an organization has PI that they are using,=20 >they will either have to register with someone already=20 >handling the superblock in the ALT, or they will have to=20 >arrange (either by running, or paying someone to run) for=20 >suitable devices to handle that block in the ALT. > >In general, the structure is that the ALT structure will=20 >mirror the address allocation structure. Even in IPv4, it is=20 >presumed that the larger number of entities would use assigned=20 >EiDs rather than using their PIs. (If the only folks needing=20 >LISP were on the order of the current PI space we would not be=20 >needing to solve an address space GROWTH problem.) > >There are other cases, outside of the purview of the WG, where=20 >other ALT operational structures, such as privately operated=20 >sets for VPNs, will obtain. > >Yours, >Joel > >On 10/22/2010 10:01 AM, Flinck, Hannu (NSN - FI/Espoo) wrote: >> Dino, Vince and Noel >> >> I agree what Vince and Dino are saying. No issue there. This=20 >shows the=20 >> flexibility of ALT. >> >> And I agree with Noel that that we can not ask everyone to renumber=20 >> first. >> I have noted the temporary nature of ALT. However, the operational=20 >> practices that ALT reuses (=3D ISPs know how to operate BGP) are not=20 >> that temporary I am afraid. This because that even if the new ways=20 >> promise benefits it requires retraining and changes of the=20 >supporting systems. >> >> Noel wrote: >> >>> We can do scaling, but at the cost of requiring the holder of >>> E+1 to deal with the same registry as the holder of E - this >>> is similar to the current DNS situation, where all holders of .COM=20 >>> DNS names have to deal with Verisign. >> >> In the example you give, yes, but it can not be generalized=20 >to a case=20 >> where there are many unrelated organizations, not only some (like A=20 >> and B in your example). >> Let's have n (n is large) independent organizations picking up at=20 >> random LEIDs. Now each LEIDs needs to be registered into the=20 >> distributed database. All selections of the registers that hold a=20 >> piece of content of the full distributed database can be independent=20 >> from each other. For example, you may use hashing that=20 >randomizes the=20 >> selection (this is what the DTHs do), or you may try to locate the=20 >> most responsive one (maybe based on the closeness, say using=20 >anycast). >> >> What I was pointing out was the selection of the registers=20 >if that is=20 >> more descriptive word for what I called as "aggregation points" >> >> Noel wrote: >> >>> > The routing system would become more durable if we=20 >would allow >>> > reshuffling of EIDs with their aggregation points. >>> >>> I don't see how. The issue is simply 'how do we build a distributed=20 >>> resolution system, given names which may be contiguous in a=20 >>> namespace, but are otherwise unrelated'. >> >> I think that Vince and Dino gave in their responses a good=20 >example how: >> >> Vince wrote: >> >> "If a particular EID block needs to move, it is a fairly=20 >simple matter=20 >> to reconfigure the tunnel topology or change the Map Server=20 >> registration so that the EID block can still be aggregated; none of=20 >> the underlying switching topology needs to be touched." >> >> >> I am noting that if you can move the EID blocks move them=20 >so that the=20 >> mapping system will able to scale well. Compact routing is a=20 >very good=20 >> bench mark for scalability both in terms of the size of the routing=20 >> table as well as stretch. (Here need to refer to the RRG write up=20 >> about the "Compact routing based mapping system" for the details at=20 >> this >> point.) >> >> Finally I agree with Noel that "... discarding the ALT means=20 >there is=20 >> no need to 'solve' any ALT-specific problems." >> >> >> Best regards >> Hannu >> >> >>> -----Original Message----- >>> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org]=20 >On Behalf=20 >>> Of ext Dino Farinacci >>> Sent: Wednesday, October 20, 2010 21:03 >>> To: Vince Fuller >>> Cc: Noel Chiappa; lisp@ietf.org >>> Subject: Re: [lisp] EID allocation / ALT base >>> >>>> On Tue, Oct 19, 2010 at 10:06:04PM -0400, Noel Chiappa wrote: >>>>> >>>>>> From: "Flinck, Hannu (NSN - FI/Espoo)" >>>>> >>>>>> I think that building on top of "administratively aggregatable" >>>>>> allocation system of the EID space is going to lead to as rigid=20 >>>>>> outcome as the current IANA and RIR allocated addressing=20 >solution=20 >>>>>> is. >>>>>> ... >>>>>> Allocation boundaries will degenerate as the networks keep on=20 >>>>>> evolving to meet the real life needs (many times=20 >unforeseeable new=20 >>>>>> use cases). >>>>> >>>>> Perhaps... but asking everyone to first renumber into=20 >some sort of=20 >>>>> optimal allocation scheme, and then stay there, is I think not=20 >>>>> workable. We just have to build a system that can deal with >>> scattered >>>>> allocations. >>>>> >>>>> >>>>>> If the ALT routing systems scalability depends exactly=20 >on how the=20 >>>>>> original aggregatable EID allocation was done >>>>> >>>>> Your comment co-mingles two separate issues. One is >>> aggregability of >>>>> LEIDs in general for purposes of resolution (which I think is a=20 >>>>> concern); and the second is aggregability issues which=20 >are specific=20 >>>>> to ALT. The latter is not a concern to me, because I >>> suspect we will >>>>> want to replace the ALT long before LISP gets widely deployed (if=20 >>>>> LISP does get there), because the ALT has a number of issues. And=20 >>>>> needless to say, discarding the ALT means there is no need >>> to 'solve' >>>>> any ALT-specific problems. >>>> >>>> People seem to be forgetting that the ALT is a >>> logical/virtual network >>>> that is composed of tunnels. If a particular EID block needs >>> to move, >>>> it is a fairly simple matter to reconfigure the tunnel topology or=20 >>>> change the Map Server registration so that the EID block can >>> still be >>>> aggregated; none of the underlying switching topology needs to be=20 >>>> touched. >>> >>> I'd like to add to what Vince is saying. >>> >>> If a site gets an EID-prefix allocation called A, that prefix will=20 >>> indicate where the site registers the EID-prefix. >>> Remember, the ALT topology follows addressing, unlike the=20 >underlying=20 >>> network today. >>> >>> If that same site needs more EID address space later and gets an=20 >>> allocation called B, and B is not in a common power-of-2 block with=20 >>> A, then the site will register to another map-server that is=20 >>> aggregating for that B space. >>> >>> In this case, there is no tunnel rehoming on the ALT. >>> >>> I'd also like to mention that the "ALT" is a logical topology. >>> It is spec'ed to run BGP over GRE tunnels. But the way we have=20 >>> implemented this, the ALT runs in another VRF. And that VRF can run=20 >>> over any physical interface, logical interface, tunnel, VLAN, etc.=20 >>> and any routing protocol can be used on those VRF-specific=20 >>> interfaces. We will find these flexible options will be used by=20 >>> enterprises who will want to run a private mapping database system.=20 >>> And one form of this is no ALT at all, just map-servers=20 >configured as=20 >>> map-resolvers. >>> >>>> Yes, moving an EID block from an ETR in Sydney to an ETR in London=20 >>>> means that their will be additional latency between the >>> London ETR and >>>> a Map Server (or other ALT aggregation point) near Australia >>> but that >>>> additional latency is limited to a few hundred milliseconds and is=20 >>>> only applicable when doing a database looking (sending a=20 >Map Request=20 >>>> and receiving a Map Reply, which occurs only when an ITR >>> needs to find >>>> the ETR for the first time). Once the EID-to-RLOC mapping has been=20 >>>> learned by an ITR that needs to communicate with the ETR,=20 >there will=20 >>>> be no added latency on the data path between them. >>> >>> And there are many both protocol and implementation techniques to=20 >>> reduce how often Map-Requests are sent to the mapping database=20 >>> system. >>> >>> Dino >>> >>>> >>>> --Vince >>>> _______________________________________________ >>>> 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 hannu.flinck@nsn.com Fri Oct 22 07:41:31 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476403A6921 for ; Fri, 22 Oct 2010 07:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwYSO-8YOzKQ for ; Fri, 22 Oct 2010 07:41:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id C81EF3A6863 for ; Fri, 22 Oct 2010 07:41:24 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9MEh19A021372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 16:43:01 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9MEh040028136; Fri, 22 Oct 2010 16:43:01 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 16:43:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2010 17:42:58 +0300 Message-ID: <26E5D1C5D5365D47B147E5E62FC7358501952D23@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [lisp] EID allocation / ALT base Thread-Index: Actx92tyit6ZwGPdSpKdij8jPlMKuA== From: "Flinck, Hannu (NSN - FI/Espoo)" To: "Noel Chiappa" , X-OriginalArrivalTime: 22 Oct 2010 14:43:00.0490 (UTC) FILETIME=[6CB5B6A0:01CB71F7] Subject: Re: [lisp] EID allocation / ALT base 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, 22 Oct 2010 14:41:32 -0000 Hello Noel You wrote:=20 > > The issue of using EIDs in the intardomain routing is a=20 >separate issue, > > but easily solvable ... No real issue there. > >I'm really at a loss to understand what you mean here, because=20 >if LEID's are allocated without regard to actual network=20 >connection location, routing tables are going to grow even faster... > I hope we are not confusing each other too much here. What I wrote was just a reiteration on how the LISP base spec defines EID/LEID: "...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...." In this respect I am not sure what do you mean about saying that "the EIDs/LEIDS can not be allocated without regards to actual network connection location". If that is really the case then the above quotation is missleading and should be considered to be clarifier on the matter that the EID is bound to a "connection location". (Not sure what that is really, maybe locations of ETRs? The Locator set? ) =20 Regards Hannu From ljakab@ac.upc.edu Sun Oct 24 15:20:51 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B4E3A6774 for ; Sun, 24 Oct 2010 15:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yrwZ8oCNER2 for ; Sun, 24 Oct 2010 15:20:45 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by core3.amsl.com (Postfix) with ESMTP id A013D3A6452 for ; Sun, 24 Oct 2010 15:20:43 -0700 (PDT) Received: from [10.208.111.81] (tmo-109-33.customers.d1-online.com [80.187.109.33]) by gw.ac.upc.edu (Postfix) with ESMTP id 3A3356B002B; Mon, 25 Oct 2010 00:22:20 +0200 (CEST) Message-ID: <4CC4B192.3070509@ac.upc.edu> Date: Mon, 25 Oct 2010 00:22:10 +0200 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTech MIME-Version: 1.0 To: LISP WG Content-Type: multipart/mixed; boundary="------------040304070702090700050303" Subject: [lisp] Proposed changes to draft-jakab-lisp-deployment 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, 24 Oct 2010 22:20:51 -0000 This is a multi-part message in MIME format. --------------040304070702090700050303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit The cutoff for drafts is in about 24 hours, and I would like to post an updated version of the deployment draft before the meeting. See the attached diff for proposed changes, they reflect some of the recent discussions on the list. Please comment before the cutoff if you would like to change something. Thanks, -Loránd Jakab --------------040304070702090700050303 Content-Type: text/html; charset=ISO-8859-1; name="draft-jakab-lisp-deployment-00-01.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-jakab-lisp-deployment-00-01.htm" PGh0bWw+PGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPgo8dGl0bGU+d2RpZmYgZHJhZnQtamFr YWItbGlzcC1kZXBsb3ltZW50LTAwLnR4dCBkcmFmdC1qYWthYi1saXNwLWRlcGxveW1lbnQt MDEudHh0PC90aXRsZT48L2hlYWQ+PGJvZHk+CjxwcmU+Ck5ldHdvcmsgV29ya2luZyBHcm91 cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBKYWthYgpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4g Q2FiZWxsb3MtQXBhcmljaW8KSW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEYuIENvcmFzCkV4cGlyZXM6IEFwcmlsIDxz dHJpa2U+PGZvbnQgY29sb3I9InJlZCI+MSw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZv bnQgY29sb3I9ImdyZWVuIj4yOCw8L2ZvbnQ+PC9zdHJvbmc+IDIwMTEgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSi4gRG9taW5nby1QYXNjdWFsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFRlY2huaWNhbCBVbml2ZXJzaXR5IG9mIENhdGFsb25p YQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRC4gTGV3aXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0ZW1zCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQg Y29sb3I9InJlZCI+U2VwdGVtYmVyIDI4LDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiI+T2N0b2JlciAyNSw8L2ZvbnQ+PC9zdHJvbmc+IDIwMTAKCiAg ICAgICAgICAgICBMSVNQIE5ldHdvcmsgRWxlbWVudCBEZXBsb3ltZW50IENvbnNpZGVyYXRp b25zCiAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRyYWZ0 LWpha2FiLWxpc3AtZGVwbG95bWVudC0wMC50eHQ8L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAg ICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZHJhZnQtamFrYWItbGlz cC1kZXBsb3ltZW50LTAxLnR4dDwvZm9udD48L3N0cm9uZz4KCkFic3RyYWN0CgogICBUaGlz IGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBpbiB3aGljaCB0 aGUgTElTUAogICBwcm90b2NvbCBtYXkgYmUgZGVwbG95ZWQuICBDaGFuZ2VzIG9yIGV4dGVu c2lvbnMgdG8gb3RoZXIgcHJvdG9jb2xzCiAgIG5lZWRlZCBieSBzb21lIG9mIHRoZSBzY2Vu YXJpb3MgYXJlIGFsc28gaGlnaGxpZ2h0ZWQuCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBU aGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdp dGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5l dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5 IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFm dHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0 ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0 byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlz IEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDxzdHJpa2U+PGZvbnQgY29s b3I9InJlZCI+MSw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVu Ij4yOCw8L2ZvbnQ+PC9zdHJvbmc+IDIwMTEuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5 cmlnaHQgKGMpIDIwMTAgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBh cyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBU aGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdz IExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0 dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBk YXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3 IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciBy aWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVu dC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QK ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUg cHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBs aWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVj dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAzCiAgIDIuICBUdW5uZWwgUm91dGVycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAgIDIuMS4gIEN1c3RvbWVyIEVkZ2UgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAyLjIuICBQ cm92aWRlciBFZGdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA1CiAgICAgMi4zLiAgU3BsaXQgSVRSL0VUUiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgIDIuNC4gIEludGVyLVNlcnZpY2UgUHJv dmlkZXIgVHJhZmZpYyBFbmdpbmVlcmluZyAuIC4gLiAuIC4gLiAuIC4gIDgKICAgICAyLjUu ICBUdW5uZWwgUm91dGVycyBiZWhpbmQgTkFUICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA5CiAgICAgICAyLjUuMS4gIElUUiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAgICAgMi41LjIuICBFVFIgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgICAy LjYuICBTdW1tYXJ5IGFuZCBGZWF0dXJlIE1hdHJpeCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDEwCiAgIDMuICBQcm94eSBUdW5uZWwgUm91dGVycyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICAgIDMuMS4gIFAtSVRSICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAg ICAgIDMuMS4xLiAgRUlEIHJlZ2lzdHJhciBQLUlUUiBzZXJ2aWNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDEwCiAgICAgICAzLjEuMi4gIExJU1ArQkdQIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgICAgMy4xLjMuICBDb250 ZW50IERlbGl2ZXJ5IE5ldHdvcmsgUC1JVFIgc2VydmljZXMgIC4gLiAuIC4gLiAuIC4gMTEK ICAgICAgIDMuMS40LiAgQ29udGVudCBEZWxpdmVyeSBOZXR3b3JrIGxvYWQgYmFsYW5jaW5n ICAuIC4gLiAuIC4gLiAuIDExCiAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ My4xLjUuICBJU1AgUC1JVFIgc2VydmljZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTE8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgMy4yLiAgUC1FVFIgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxm b250IGNvbG9yPSJyZWQiPjExPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+MTI8L2ZvbnQ+PC9zdHJvbmc+CiAgIDQuICBNYXAtUmVzb2x2ZXJzIGFuZCBN YXAtU2VydmVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgIDQu MS4gIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+TWFwLVJlc29sdmVyczwvZm9udD48L3N0 cmlrZT4gIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5NYXAtU2VydmVycyAgLjwvZm9u dD48L3N0cm9uZz4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMwogICAgIDQuMi4gIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+TWFwLVNlcnZlcnMg IC48L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+TWFwLVJl c29sdmVyczwvZm9udD48L3N0cm9uZz4gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4xMzwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjE0PC9mb250Pjwvc3Ryb25nPgog ICA1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4xNDwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjE1PC9mb250Pjwvc3Ryb25nPgog ICA2LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4xNDwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjE1PC9mb250Pjwvc3Ryb25nPgog ICA3LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4xNDwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjE1PC9mb250Pjwvc3Ryb25nPgog ICA4LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4xNDwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjE1PC9mb250Pjwvc3Ryb25nPgog ICAgIDguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4xNDwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjE1PC9mb250Pjwvc3Ryb25nPgog ICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4xNTwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjE2PC9mb250Pjwvc3Ryb25nPgog ICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj4xNTwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPjE2PC9mb250Pjwvc3Ryb25nPgoK MS4gIEludHJvZHVjdGlvbgoKICAgVGhlIExvY2F0b3IvSWRlbnRpZmllciBTZXBhcmF0aW9u IFByb3RvY29sIGFkZHJlc3NlcyB0aGUgc2NhbGluZwogICBpc3N1ZXMgb2YgdGhlIGdsb2Jh bCBJbnRlcm5ldCByb3V0aW5nIHN5c3RlbSBieSBzZXBhcmF0aW5nIHRoZQogICBjdXJyZW50 IGFkZHJlc3Npbmcgc2NoZW1lIGludG8gRW5kcG9pbnQgSURlbnRpZmllcnMgKEVJRHMpIGFu ZAogICBSb3V0aW5nIExPQ2F0b3JzIChSTE9DcykuICBUaGUgbWFpbiBwcm90b2NvbCBzcGVj aWZpY2F0aW9uCiAgIFtJLUQuaWV0Zi1saXNwXSBkZXNjcmliZXMgaG93IHRoZSBzZXBhcmF0 aW9uIGlzIGFjaGlldmVkLCB3aGljaCBuZXcKICAgbmV0d29yayBlbGVtZW50cyBhcmUgaW50 cm9kdWNlZCwgYW5kIGRldGFpbHMgdGhlIHBhY2tldCBmb3JtYXRzIGZvcgogICB0aGUgZGF0 YSBhbmQgY29udHJvbCBwbGFuZXMuCgogICBXaGlsZSB0aGUgYm91bmRhcnkgYmV0d2VlbiB0 aGUgY29yZSBhbmQgZWRnZSBpcyBub3Qgc3RyaWN0bHkgZGVmaW5lZCwKICAgb25lIHdpZGVs eSBhY2NlcHRlZCBkZWZpbml0aW9uIHBsYWNlcyBpdCBhdCB0aGUgYm9yZGVyIHJvdXRlcnMg b2YKICAgc3R1YiBhdXRvbm9tb3VzIHN5c3RlbXMsIHdoaWNoIG1heSBjYXJyeSBhIHBhcnRp YWwgb3IgY29tcGxldGUKICAgZGVmYXVsdC1mcmVlIHpvbmUgKERGWikgcm91dGluZyB0YWJs ZS4gIFRoZSBpbml0aWFsIGRlc2lnbiBvZiBMSVNQCiAgIHRvb2sgdGhpcyBsb2NhdGlvbiBh cyBhIGJhc2VsaW5lIGZvciBwcm90b2NvbCBkZXZlbG9wbWVudC4gIEhvd2V2ZXIsCiAgIHRo ZSBhcHBsaWNhdGlvbnMgb2YgTElTUCBnbyBiZXlvbmQgb2YganVzdCBkZWNyZWFzaW5nIHRo ZSBzaXplIG9mIHRoZQogICBERlogcm91dGluZyB0YWJsZSwgYW5kIGluY2x1ZGUgaW1wcm92 ZWQgbXVsdGlob21pbmcgYW5kIGluZ3Jlc3MKICAgdHJhZmZpYyBlbmdpbmVlcmluZyAoVEUp IHN1cHBvcnQgZm9yIGVkZ2UgbmV0d29ya3MsIGFuZCBldmVuCiAgIGluZGl2aWR1YWwgaG9z dHMuICBUaHJvdWdob3V0IHRoZSBkcmFmdCB3ZSB3aWxsIHVzZSB0aGUgdGVybSBMSVNQCiAg IHNpdGUgdG8gcmVmZXIgdG8gdGhlc2UgbmV0d29ya3MvaG9zdHMgYmVoaW5kIGEgTElTUCBU dW5uZWwgUm91dGVyLgogICBXZSBmb3JtYWxseSBkZWZpbmUgaXQgYXM6CgogICBMSVNQIHNp dGU6ICBBIHNpbmdsZSBob3N0IG9yIGEgc2V0IG9mIG5ldHdvcmsgZWxlbWVudHMgaW4gYW4g ZWRnZQogICAgICBuZXR3b3JrIHVuZGVyIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIG9m IGEgc2luZ2xlIG9yZ2FuaXphdGlvbiwKICAgICAgZGVsaW1pdGVkIGZyb20gb3RoZXIgbmV0 d29yayBieSBMSVNQIFR1bm5lbCBSb3V0ZXIocykuCgogICBTaW5jZSBMSVNQIGlzIGEgcHJv dG9jb2wgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIGRpZmZlcmVudCBwdXJwb3NlcywgaXQKICAg aXMgaW1wb3J0YW50IHRvIGlkZW50aWZ5IHBvc3NpYmxlIGRlcGxveW1lbnQgc2NlbmFyaW9z IGFuZCB0aGUKICAgYWRkaXRpb25hbCByZXF1aWVyZW1lbnRzIHRoZXkgbWF5IGltcG9zZSBv biB0aGUgcHJvdG9jb2wKICAgc3BlY2lmaWNhdGlvbi4gIFRoZSBtYWluIHNwZWNpZmljYXRp b24gW0ktRC5pZXRmLWxpc3BdIG1lbnRpb25zCiAgIHBvc2l0aW9uaW5nIG9mIHR1bm5lbCBy b3V0ZXJzLCBidXQgd2l0aG91dCBhbiBpbi1kZXB0aCBkaXNjdXNzaW9uLgogICBUaGlzIGRv Y3VtZW50IGZpbGxzIHRoYXQgZ2FwLCBieSBleHBsb3JpbmcgdGhlIG1vc3QgY29tbW9uIGNh c2VzLgogICBXaGlsZSB0aGUgdGhlb3JldGljYWwgY29tYmluYXRpb25zIG9mIGRldmljZSBw bGFjZW1lbnRzIGFyZSBxdWl0ZQogICBudW1lcm91cywgdGhlIG1vcmUgcHJhY3RpY2FsIHNj ZW5hcmlvcyBhcmUgZ2l2ZW4gcHJlZmVyZW5jZSBpbiB0aGUKICAgZm9sbG93aW5nLgoKICAg RWFjaCBzdWJzZWN0aW9uIGNvbnNpZGVycyBhbiBlbGVtZW50IHR5cGUsIGRpc2N1c3Npbmcg dGhlIGltcGFjdCBvZgogICBkZXBsb3ltZW50IHNjZW5hcmlvcyBvbiB0aGUgcHJvdG9jb2wg c3BlY2lmaWNhdGlvbi4KCiAgIEZvciBkZWZpbml0aW9uIG9mIHRlcm1zLCBwbGVhc2UgcmVm ZXIgdG8gdGhlIGFwcHJvcHJpYXRlIGRvY3VtZW50cwogICAoYXMgY2l0ZWQgaW4gdGhlIHJl c3BlY3RpdmUgc2VjdGlvbnMpLgoKICAgQ29tbWVudHMgYW5kIGRpc2N1c3Npb25zIGFib3V0 IHRoaXMgbWVtbyBzaG91bGQgYmUgZGlyZWN0ZWQgdG8gdGhlCiAgIExJU1Agd29ya2luZyBn cm91cDogbGlzcEBpZXRmLm9yZy4KCjIuICBUdW5uZWwgUm91dGVycwoKICAgTElTUCBpcyBh IG1hcC1hbmQtZW5jYXAgcHJvdG9jb2wsIHdpdGggdGhlIG1haW4gZ29hbCBvZiBpbXByb3Zp bmcKICAgZ2xvYmFsIHJvdXRpbmcgc2NhbGFiaWxpdHkuICBUbyBhY2hpZXZlIGl0cyBnb2Fs LCBpdCBpbnRyb2R1Y2VzCiAgIHNldmVyYWwgbmV3IG5ldHdvcmsgZWxlbWVudHMsIGVhY2gg cGVyZm9ybWluZyBzcGVjaWZpYyBmdW5jdGlvbnMKICAgbmVjZXNzYXJ5IHRvIHNlcGFyYXRl IHRoZSBlZGdlIGZyb20gdGhlIGNvcmUuICBUaGUgZGV2aWNlIHRoYXQgaXMgdGhlCiAgIGdh dGV3YXkgYmV0d2VlbiB0aGUgZWRnZSBhbmQgdGhlIGNvcmUgaXMgY2FsbGVkIFR1bm5lbCBS b3V0ZXIgKHhUUiksCiAgIHBlcmZvcm1pbmcgb25lIG9yIGJvdGggb2YgdHdvIHNlcGFyYXRl IGZ1bmN0aW9uczoKCiAgIDEuICBFbmNhcHN1bGF0aW5nIHBhY2tldHMgb3JpZ2luYXRpbmcg ZnJvbSBhbiBlbmQgaG9zdCB0byBiZQogICAgICAgdHJhbnNwb3J0ZWQgb3ZlciBpbnRlcm1l ZGlhcnkgKHRyYW5zaXQpIG5ldHdvcmtzIHRvd2FyZHMgdGhlCiAgICAgICBvdGhlciBlbmQt cG9pbnQgb2YgdGhlIGNvbW11bmljYXRpb24KCiAgIDIuICBEZWNhcHN1bGF0aW5nIHBhY2tl dHMgZW50ZXJpbmcgZnJvbSBpbnRlcm1lZGlhcnkgKHRyYW5zaXQpCiAgICAgICBuZXR3b3Jr cywgb3JpZ2luYXRlZCBhdCBhIHJlbW90ZSBlbmQgaG9zdC4KCiAgIFRoZSBmaXJzdCBmdW5j dGlvbiBpcyBwZXJmb3JtZWQgYnkgYW4gSW5ncmVzcyBUdW5uZWwgUm91dGVyIChJVFIpLAog ICB0aGUgc2Vjb25kIGJ5IGFuIEVncmVzcyBUdW5uZWwgUm91dGVyIChFVFIpLgoKICAgU2Vj dGlvbiA4IG9mIHRoZSBtYWluIExJU1Agc3BlY2lmaWNhdGlvbiBbSS1ELmlldGYtbGlzcF0g aGFzIGEgc2hvcnQKICAgZGlzY3Vzc2lvbiBvZiB3aGVyZSBUdW5uZWwgUm91dGVycyBjYW4g YmUgZGVwbG95ZWQgYW5kIHNvbWUgb2YgdGhlCiAgIGFzc29jaWF0ZWQgYWR2YW50YWdlcyBh bmQgZGlzYWR2YW50YWdlcy4gIFRoaXMgc2VjdGlvbiBhZGRzIG1vcmUKICAgZGV0YWlsIHRv IHRoZSBzY2VuYXJpb3MgcHJlc2VudGVkIHRoZXJlLCBhbmQgcHJvdmlkZXMgYWRkaXRpb25h bAogICBzY2VuYXJpb3MgYXMgd2VsbC4KCjIuMS4gIEN1c3RvbWVyIEVkZ2UKCiAgIEFzIG1l bnRpb25lZCBpbiB0aGUgSW50cm9kdWN0aW9uLCBMSVNQIHdhcyBkZXNpZ25lZCB3aXRoIGRl cGxveW1lbnQKICAgYXQgdGhlIGNvcmUtZWRnZSBib3VuZGFyeSBpbiBtaW5kLCB3aGljaCBj YW4gYmUgYXBwcm94aW1hdGVkIGFzIHRoZQogICBzZXQgb2YgREZaIHJvdXRlcnMgYmVsb25n aW5nIHRvIG5vbi10cmFuc2l0IEFTZXMuICBGb3IgdGhlIHB1cnBvc2VzCiAgIG9mIHRoaXMg ZG9jdW1lbnQsIHdlIHdpbGwgY29uc2lkZXIgdGhpcyBib3VuZGFyeSB0byBiZSBjb25zaXN0 aW5nIG9mCiAgIHRoZSByb3V0ZXJzIGNvbm5lY3RpbmcgTElTUCBzaXRlcyB0byB0aGVpciB1 cHN0cmVhbXMuICBBcyBzdWNoLCB0aGlzCiAgIGlzIHRoZSBtb3N0IGNvbW1vbiBleHBlY3Rl ZCBzY2VuYXJpbyBmb3IgeFRScywgYW5kIHRoaXMgZG9jdW1lbnQKICAgY29uc2lkZXJzIGl0 IHRoZSByZWZlcmVuY2UgbG9jYXRpb24sIGNvbXBhcmluZyB0aGUgb3RoZXIgc2NlbmFyaW9z IHRvCiAgIHRoaXMgb25lLgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJU1Ax ICAgIElTUDIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArLS0tLSsgICstLS0tKwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgKy0tfHhUUjF8LS18eFRSMnwtLSsKICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICstLS0tKyAgKy0tLS0rICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg Q3VzdG9tZXIgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiB4VFJzIGF0IHRoZSBj dXN0b21lciBlZGdlCgogICBGcm9tIHRoZSBMSVNQIHNpdGUgcGVyc3BlY3RpdmUgdGhlIG1h aW4gYWR2YW50YWdlIG9mIHRoaXMgdHlwZSBvZgogICBkZXBsb3ltZW50IChjb21wYXJlZCB0 byB0aGUgb25lIGRlc2NyaWJlZCBpbiB0aGUgbmV4dCBzZWN0aW9uKSBpcwogICBoYXZpbmcg ZGlyZWN0IGNvbnRyb2wgb3ZlciBpdHMgaW5ncmVzcyB0cmFmZmljIGVuZ2luZWVyaW5nLiAg VGhpcwogICBtYWtlcyBpdCBpcyBlYXN5IHRvIHNldCB1cCBhbmQgbWFpbnRhaW4gYWN0aXZl L2FjdGl2ZSwgYWN0aXZlL2JhY2t1cCwKICAgb3IgbW9yZSBjb21wbGV4IFRFIHBvbGljaWVz LCB3aXRob3V0IGludm9sdmluZyB0aGlyZCBwYXJ0aWVzLgoKICAgQmVpbmcgdW5kZXIgdGhl IHNhbWUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCwgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9u CiAgIG9mIGFsbCBFVFJzIGNhbiBiZSBlYXNpbHkgc3luY2hyb25pemVkLCBiZWNhdXNlIHRo ZSBuZWNlc3NhcnkgY29udHJvbAogICB0cmFmZmljIGNhbiBiZSBhbGxvd2VkIGJldHdlZW4g dGhlIGxvY2F0b3JzIG9mIHRoZSBFVFJzLiAgQSBjb3JyZWN0CiAgIHN5bmNocm9ub3VzIGds b2JhbCB2aWV3IG9mIHRoZSByZWFjaGFiaWxpdHkgc3RhdHVzIGlzIHRodXMgYXZhaWxhYmxl LAogICBhbmQgdGhlIExvYy1TdGF0dXMtQml0cyBjYW4gYmUgc2V0IGNvcnJlY3RseSBpbiB0 aGUgTElTUCBkYXRhIGhlYWRlcgogICBvZiBvdXRnb2luZyBwYWNrZXRzLgoKICAgQnkgY2hv b3NpbmcgdGhlIGVuY2Fwc3VsYXRlIGxhc3QsIGRlY2Fwc3VsYXRlIGZpcnN0IHBvbGljeSwg ZXhpc3RpbmcKICAgaW50ZXJuYWwgbmV0d29yayBjb25maWd1cmF0aW9uIGRvZXMgbm90IG5l ZWQgdG8gYmUgbW9kaWZpZWQuCiAgIEZpcmV3YWxsIHJ1bGVzLCByb3V0ZXIgY29uZmlndXJh dGlvbnMgYW5kIGFkZHJlc3MgYXNzaWdubWVudHMgaW5zaWRlCiAgIHRoZSBMSVNQIHNpdGUg cmVtYWluIHVuY2hhbmdlZC4gIFRoaXMgaGVscHMgd2l0aCBpbmNyZW1lbnRhbAogICBkZXBs b3ltZW50IGFuZCBhbGxvd3MgYSBxdWljayB1cGdyYWRlIHBhdGggdG8gTElTUC4gIEZvciBs YXJnZXIgc2l0ZXMKICAgd2l0aCBtYW55IGV4dGVybmFsIGNvbm5lY3Rpb25zIGFuZCBjb21w bGV4IGludGVybmFsIHRvcG9sb2d5LCBpdCBtYXkKICAgaG93ZXZlciBtYWtlIG1vcmUgc2Vu c2UgdG8gYm90aCBlbmNhcHN1bGF0ZSBhbmQgZGVjYXBzdWxhdGUgYXMgc29vbgogICBhcyBw b3NzaWJsZSwgdG8gYmVuZWZpdCBmcm9tIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgSUdQIHRv IGNob29zZSB0aGUKICAgYmVzdCBwYXRoIChzZWUgU2VjdGlvbiAyLjMgZm9yIGEgZGlzY3Vz c2lvbiBvZiB0aGlzIHNjZW5hcmlvKS4KCiAgIEFub3RoZXIgdGhpbmcgdG8gY29uc2lkZXIg d2hlbiBwbGFjaW5nIHR1bm5lbCByb3V0ZXJzIGFyZSBNVFUgaXNzdWVzLgogICBTaW5jZSBl bmNhcHN1bGF0aW5nIHBhY2tldHMgaW5jcmVhc2VzIG92ZXJoZWFkLCB0aGUgTVRVIG9mIHRo ZSBlbmQtCiAgIHRvLWVuZCBwYXRoIG1heSBkZWNyZWFzZSwgd2hlbiBlbmNhcHN1bGF0ZWQg cGFja2V0cyBuZWVkIHRvIHRyYXZlbAogICBvdmVyIHNlZ21lbnRzIGhhdmluZyBjbG9zZSB0 byBtaW5pbXVtIE1UVS4gIFRyYW5zaXQgbmV0d29ya3MgYXJlCiAgIGtub3duIHRvIHByb3Zp ZGUgbGFyZ2VyIE1UVSB0aGFuIHRoZSB0eXBpY2FsIHZhbHVlIG9mIDE1MDAgYnl0ZXMgb2YK ICAgcG9wdWxhciBhY2Nlc3MgdGVjaG5vbG9naWVzIHVzZWQgYXQgZW5kIGhvc3RzIChlLmcu LCBJRUVFIDgwMi4zIGFuZAogICA4MDIuMTEpLiAgSG93ZXZlciwgcGxhY2luZyB0aGUgTElT UCByb3V0ZXIgYXQgdGhlIENFIGNvdWxkIHBvc3NpYmx5CiAgIGJyaW5nIHVwIE1UVSBpc3N1 ZXMsIGRlcGVuZGluZyBvbiB0aGUgbGluayB0eXBlIHRvIHRoZSBwcm92aWRlci4KCjIuMi4g IFByb3ZpZGVyIEVkZ2UKCiAgIFRoZSBvdGhlciBsb2NhdGlvbiBhdCB0aGUgY29yZS1lZGdl IGJvdW5kYXJ5IGZvciBkZXBsb3lpbmcgTElTUAogICByb3V0ZXJzIGlzIGF0IHRoZSBpbnRl cm5ldCBzZXJ2aWNlIHByb3ZpZGVyIGVkZ2UuICBUaGUgbWFpbiBpbmNlbnRpdmUKICAgZm9y IHRoaXMgY2FzZSBpcyB0aGF0IHRoZSBjdXN0b21lciBkb2VzIG5vdCBoYXZlIHRvIHVwZ3Jh ZGUgdGhlIENFCiAgIHJvdXRlcihzKSwgb3IgY2hhbmdlIHRoZSBjb25maWd1cmF0aW9uIG9m IGFueSBlcXVpcG1lbnQuCiAgIEVuY2Fwc3VsYXRpb24vZGVjYXBzdWxhdGlvbiBoYXBwZW5z IGluIHRoZSBwcm92aWRlcidzIG5ldHdvcmssIHdoaWNoCiAgIG1heSBiZSBhYmxlIHRvIHNl cnZlIHNldmVyYWwgY3VzdG9tZXJzIHdpdGggYSBzaW5nbGUgZGV2aWNlLiAgRm9yCiAgIGxh cmdlIElTUHMgd2l0aCBtYW55IHJlc2lkZW50aWFsL2J1c2luZXNzIGN1c3RvbWVycyBhc2tp bmcgZm9yIExJU1AKICAgdGhpcyBjYW4gbGVhZCB0byBpbXBvcnRhbnQgc2F2aW5ncywgc2lu Y2UgdGhlcmUgaXMgbm8gbmVlZCB0byB1cGdyYWRlCiAgIHRoZSBzb2Z0d2FyZSAob3IgaGFy ZHdhcmUsIGlmIGl0J3MgdGhlIGNhc2UpIGF0IGVhY2ggY2xpZW50J3MKICAgbG9jYXRpb24u ICBJbnN0ZWFkLCB0aGV5IGNhbiB1cGdyYWRlIHRoZSBzb2Z0d2FyZSAob3IgaGFyZHdhcmUp IG9uIGEKICAgZmV3IFBFIHJvdXRlcnMgc2VydmluZyB0aGUgY3VzdG9tZXJzLiAgVGhpcyBz Y2VuYXJpbyBpcyBkZXBpY3RlZCBpbgogICBGaWd1cmUgMi4KCiAgICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAg ICAgICAgfCAgIElTUDEgICB8ICAgICAgICB8ICAgICAgIElTUDIgICAgICAgfAogICAgICAg ICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICB8CiAg ICAgICAgICAgICAgICAgIHwgICstLS0tKyAgfCAgICAgICAgfCAgKy0tLS0rICArLS0tLSsg IHwKICAgICAgICAgICAgICAgICAgKy0tfHhUUjF8LS0rICAgICAgICArLS18eFRSMnwtLXx4 VFIzfC0tKwogICAgICAgICAgICAgICAgICAgICArLS0tLSsgICAgICAgICAgICAgICstLS0t KyAgKy0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8 ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwg ICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICArLS0mbHQ7W0N1c3RvbWVyXSZndDst LS0tKy0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiB4VFIg YXQgdGhlIFBFCgogICBXaGlsZSB0aGlzIGFwcHJvYWNoIGNhbiBtYWtlIHRyYW5zaXRpb24g ZWFzeSBmb3IgY3VzdG9tZXJzIGFuZCBtYXkgYmUKICAgY2hlYXBlciBmb3IgcHJvdmlkZXJz LCB0aGUgTElTUCBzaXRlIGxvb3NlcyBvbmUgb2YgdGhlIG1haW4gYmVuZWZpdHMKICAgb2Yg TElTUDogaW5ncmVzcyB0cmFmZmljIGVuZ2luZWVyaW5nLiAgU2luY2UgdGhlIHByb3ZpZGVy IGNvbnRyb2xzCiAgIHRoZSBFVFJzLCBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgd291bGQgYmUg bmVlZGVkIHRvIGFsbG93IGN1c3RvbWVycyB0bwogICBtb2RpZnkgdGhlaXIgbWFwcGluZyBl bnRyaWVzLgoKICAgVGhlIHByb2JsZW0gaXMgYWdncmF2YXRlZCB3aGVuIHRoZSBMSVNQIHNp dGUgaXMgbXVsdGlob21lZC4gIENvbnNpZGVyCiAgIHRoZSBzY2VuYXJpbyBpbiBGaWd1cmUg Mjogd2hlbmV2ZXIgYSBjaGFuZ2UgdG8gVEUgcG9saWNpZXMgaXMKICAgcmVxdWlyZWQsIHRo ZSBjdXN0b21lciBjb250YWN0cyBib3RoIElTUDEgYW5kIElTUDIgdG8gbWFrZSB0aGUKICAg bmVjZXNzYXJ5IGNoYW5nZXMgb24gdGhlIHJvdXRlcnMgKGlmIHRoZXkgcHJvdmlkZSB0aGlz IHBvc3NpYmlsaXR5KS4KICAgSXQgaXMgaG93ZXZlciB1bmxpa2VseSwgdGhhdCBib3RoIElT UHMgd2lsbCBhcHBseSBjaGFuZ2VzCiAgIHNpbXVsdGFub3VzbHksIHdoaWNoIG1heSBsZWFk IHRvIHVuY29uc2lzdGVudCBzdGF0ZSBmb3IgdGhlIG1hcHBpbmdzCiAgIG9mIHRoZSBMSVNQ IHNpdGUgKGUuZy4sIHdlaWdodHMgZm9yIHRoZSBzYW1lIHByaW9yaXR5IGRvbid0IHN1bSAx MDApLgogICBTaW5jZSB0aGUgZGlmZmVyZW50IHVwc3RyZWFtIElTUHMgYXJlIHVzdWFsbHkg Y29tcGV0aW5nIGJ1c2luZXNzCiAgIGVudGl0aWVzLCB0aGUgRVRScyBtYXkgZXZlbiBiZSBj b25maWd1cmVkIHRvIGNvbXBldGUsIGVpdGhlciB0bwogICBhdHRyYWN0IGFsbCB0aGUgdHJh ZmZpYyBvciB0byBnZXQgbm8gdHJhZmZpYy4gIFRoZSBmb3JtZXIgd2lsbCBoYXBwZW4KICAg aWYgdGhlIGN1c3RvbWVyIHBheXMgcGVyIHZvbHVtZSwgdGhlIGxhdHRlciBpZiB0aGUgY29u bmVjdGl2aXR5IGhhcyBhCiAgIGZpeGVkIHByaWNlLiAgQSBzb2x1dGlvbiBjb3VsZCBiZSB0 byBoYXZlIHRoZSBtYXBwaW5ncyBpbiB0aGUgTWFwLQogICBTZXJ2ZXIocyksIGFuZCBoYXZl IHRoZWlyIG9wZXJhdG9yIGdpdmUgY29udHJvbCBvdmVyIHRoZSBlbnRyaWVzIHRvCiAgIGN1 c3RvbWVyLCBtdWNoIGxpa2UgaW4gdG9kYXkncyBETlMuCgogICBBZGRpdGlvbmFsbHksIHNp bmNlIHhUUjEsIHhUUjIsIGFuZCB4VFIzIGFyZSBpbiBkaWZmZXJlbnQKICAgYWRtaW5pc3Ry YXRpdmUgZG9tYWlucywgbG9jYXRvciByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24gaXMgdW5s aWtlbHkKICAgdG8gYmUgZXhjaGFuZ2VkIGFtb25nIHRoZW0sIG1ha2luZyBpdCBkaWZmaWN1 bHQgdG8gc2V0IExvYy1TdGF0dXMtCiAgIEJpdHMgY29ycmVjdGx5IG9uIGVuY2Fwc3VsYXRl ZCBwYWNrZXRzLgoKICAgQ29tcGFyZWQgdG8gdGhlIGN1c3RvbWVyIGVkZ2Ugc2NlbmFyaW8s IGRlcGxveWluZyBMSVNQIGF0IHRoZQogICBwcm92aWRlciBlZGdlIG1pZ2h0IGhhdmUgdGhl IGFkdmFudGFnZSBvZiBkaW1pbmlzaGluZyBwb3RlbnRpYWwgTVRVCiAgIGlzc3VlcywgYmVj YXVzZSB0aGUgdHVubmVsIHJvdXRlciBpcyBjbG9zZXIgdG8gdGhlIGNvcmUsIHdoZXJlIGxp bmtzCiAgIHR5cGljYWxseSBoYXZlIGhpZ2hlciBNVFVzIHRoYW4gZWRnZSBuZXR3b3JrIGxp bmtzLgoKMi4zLiAgU3BsaXQgSVRSL0VUUgoKICAgSW4gYSBzaW1wbGUgTElTUCBkZXBsb3lt ZW50LCB4VFJzIGFyZSBsb2NhdGVkIGF0IHRoZSBib3JkZXIgb2YgdGhlCiAgIExJU1Agc2l0 ZSAoc2VlIFNlY3Rpb24gMi4xKS4gIEluIHRoaXMgc2NlbmFyaW8gcGFja2V0cyBhcmUgcm91 dGVkCiAgIGluc2lkZSB0aGUgZG9tYWluIGFjY29yZGluZyB0byB0aGUgRUlELiAgSG93ZXZl ciwgbW9yZSBjb21wbGV4CiAgIG5ldHdvcmtzIG1heSB3YW50IHRvIHJvdXRlIHBhY2tldHMg YWNjb3JkaW5nIHRvIHRoZSBkZXN0aW5hdGlvbiBSTE9DLgogICBUaGlzIHdvdWxkIGVuYWJs ZSB0aGVtIHRvIGNob29zZSB0aGUgYmVzdCBlZ3Jlc3MgcG9pbnQuCgogICBUaGUgTElTUCBz cGVjaWZpY2F0aW9uIHNlcGFyYXRlcyB0aGUgSVRSIGFuZCBFVFIgZnVuY3Rpb25hbGl0eSBh bmQKICAgY29uc2lkZXJzIHRoYXQgYm90aCBlbnRpdGllcyBjYW4gYmUgZGVwbG95ZWQgaW4g c2VwYXJhdGVkIG5ldHdvcmsKICAgZXF1aXBtZW50LiAgSVRScyBjYW4gYmUgZGVwbG95ZWQg Y2xvc2VyIHRvIHRoZSBob3N0IChpLmUuLCBhY2Nlc3MKICAgcm91dGVycykuICBUaGlzIHdh eSBwYWNrZXRzIGFyZSBlbmNhcHN1bGF0ZWQgYXMgc29vbiBhcyBwb3NzaWJsZSwgYW5kCiAg IHBhY2tldHMgZXhpdCB0aGUgbmV0d29yayB0aHJvdWdoIHRoZSBiZXN0IGVncmVzcyBwb2lu dC4gIEluIHR1cm4sCiAgIEVUUnMgY2FuIGJlIGRlcGxveWVkIGF0IHRoZSBib3JkZXIgcm91 dGVycyBvZiB0aGUgbmV0d29yaywgYW5kCiAgIHBhY2tldHMgYXJlIGRlY2Fwc3VsYXRlZCBh cyBzb29uIGFzIHBvc3NpYmxlLiAgQWdhaW4sIG9uY2UKICAgZGVjYXBzdWxhdGVkIHBhY2tl dHMgYXJlIHJvdXRlZCBhY2NvcmRpbmcgdG8gdGhlIEVJRCwgYW5kIGNhbiBmb2xsb3cKICAg dGhlIGJlc3QgcGF0aC4KCiAgIEluIHRoZSBmb2xsb3dpbmcgZmlndXJlIHdlIGNhbiBzZWUg YW4gZXhhbXBsZS4gIFRoZSBTb3VyY2UgKFMpCiAgIHRyYW5zbWl0cyBwYWNrZXRzIHVzaW5n IGl0cyBFSUQgYW5kIGluIHRoaXMgcGFydGljdWxhciBjYXNlIHBhY2tldHMKICAgYXJlIGVu Y2Fwc3VsYXRlZCBhdCBJVFJfMS4gIFRoZSBlbmNhcHN1bGF0ZWQgcGFja2V0cyBhcmUgcm91 dGVkCiAgIGluc2lkZSB0aGUgZG9tYWluIGFjY29yZGluZyB0byB0aGUgZGVzdGluYXRpb24g UkxPQywgYW5kIGNhbiBlZ3Jlc3MKICAgdGhlIG5ldHdvcmsgdGhyb3VnaCB0aGUgYmVzdCBw b2ludCAoaS5lLiwgY2xvc2VyIHRvIHRoZSBSTE9DJ3MgQVMpLgogICBPbiB0aGUgb3RoZXIg aGFuZCwgaW5ib3VuZCBwYWNrZXRzIGFyZSByZWNlaXZlZCBieSBFVFJfMSB3aGljaAogICBk ZWNhcHN1bGF0ZXMgdGhlbS4gIFRoZW4gcGFja2V0cyBhcmUgcm91dGVkIHRvd2FyZHMgUyBh Y2NvcmRpbmcgdG8KICAgdGhlIEVJRCwgYWdhaW4gZm9sbG93aW5nIHRoZSBiZXN0IHBhdGgu CgogICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAg ICAgICstLS0tLS0tKyAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsgICAgICAgICArLS0t LS0tLSsKICAgICAgfCAgICAgICB8IElUUl8xIHwtLS0tLS0tLS0rICAgICAgICAgfCBFVFJf MSB8LVJMT0NfQi0tfCBJU1BfQSB8CiAgICAgIHwgICAgICAgKy0tLS0tLS0rICAgICAgICAg fCAgICAgICAgICstLS0tLS0tKyAgICAgICAgICstLS0tLS0tKwogICAgICB8ICArLSsgICAg ICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgfAogICAgICB8ICB8U3wgICAgICAgIHwg ICAgSUdQICAgIHwgICAgICAgICAgICAgfAogICAgICB8ICArLSsgICAgICAgIHwgICAgICAg ICAgIHwgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICstLS0tLS0tKyAgICAgICAgIHwg ICAgICAgICArLS0tLS0tLSsgICAgICAgICArLS0tLS0tLSsKICAgICAgfCAgICAgICB8IElU Ul8yIHwtLS0tLS0tLS0rICAgICAgICAgfCBFVFJfMiB8LVJMT0NfQi0tfCBJU1BfQiB8CiAg ICAgIHwgICAgICAgKy0tLS0tLS0rICAgICAgICAgICAgICAgICAgICstLS0tLS0tKyAgICAg ICAgICstLS0tLS0tKwogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t KwoKICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDM6IFNwbGl0IElUUi9FVFIgU2NlbmFy aW8KCiAgIFRoaXMgc2NlbmFyaW8gaGFzIGEgc2V0IG9mIGltcGxpY2F0aW9uczoKCiAgIG8g IFRoZSBzaXRlIG11c3QgY2FycnkgYXQgbGVhc3QgcGFydGlhbCBCR1Agcm91dGVzIGluIG9y ZGVyIHRvIGNob29zZQogICAgICB0aGUgYmVzdCBlZ3Jlc3MgcG9pbnQsIGluY3JlYXNpbmcg dGhlIGNvbXBsZXhpdHkgb2YgdGhlIG5ldHdvcmsuCiAgICAgIEhvd2V2ZXIsIHRoaXMgaXMg dXN1YWxseSBhbHJlYWR5IHRoZSBjYXNlIGZvciBMSVNQIHNpdGVzIHRoYXQKICAgICAgd291 bGQgYmVuZWZpdCBmcm9tIHRoaXMgc2NlbmFyaW8uCgogICBvICBJbiBMSVNQLCBJVFJzIHNl dCB0aGUgcmVhY2hhYmlsaXR5IGJpdHMgd2hlbiBlbmNhcHN1bGF0aW5nIGRhdGEKICAgICAg cGFja2V0cy4gIEhlbmNlLCBJVFJzIG5lZWQgYSBtZWNoYW5pc20gdG8gYmUgYXdhcmUgb2Yg dGhlIGxpdmVuZXNzCiAgICAgIG9mIEVUUnMuCgogICBvICBJVFJzIGVuY2Fwc3VsYXRlIHBh Y2tldHMgYW5kIGluIG9yZGVyIHRvIGFjaGlldmUgZWZmaWNpZW50CiAgICAgIGNvbW11bmlj YXRpb25zLCB0aGUgTVRVIG9mIHRoZSBzaXRlIG11c3QgYmUgbGFyZ2UgZW5vdWdoIHRvCiAg ICAgIGFjY29tbW9kYXRlIHRoaXMgZXh0cmEgaGVhZGVyLgoKICAgbyAgSW4gdGhpcyBzY2Vu YXJpbywgZWFjaCBJVFIgaXMgc2VydmluZyBmZXdlciBob3N0cyB0aGFuIGluIHRoZSBjYXNl CiAgICAgIHdoZW4gaXQgaXMgZGVwbG95ZWQgYXQgdGhlIGJvcmRlciBvZiB0aGUgbmV0d29y ay4gIEl0IGhhcyBiZWVuCiAgICAgIHNob3duIHRoYXQgY2FjaGUgaGl0IHJhdGlvIGdyb3dz IGxvZ2FyaXRobWljYWxseSB3aXRoIHRoZSBhbW91bnQKICAgICAgb2YgdXNlcnMgW2NhY2hl XS4gIFRha2luZyB0aGlzIGludG8gYWNjb3VudCwgd2hlbiBJVFJzIGFyZQogICAgICBkZXBs b3llZCBjbG9zZXIgdG8gdGhlIGhvc3QgdGhlIGVmZmVjdGl2ZW5lc3Mgb2YgdGhlIG1hcHBp bmcgY2FjaGUKICAgICAgbWF5IGJlIGxvd2VyIChpLmUuLCB0aGUgbWlzcyByYXRpbyBpcyBo aWdoZXIpLiAgQW5vdGhlcgogICAgICBjb25zZXF1ZW5jZSBvZiB0aGlzIGlzIHRoYXQgdGhl IHNpdGUgd2lsbCB0cmFuc21pdCBhIGhpZ2hlciBhbW91bnQKICAgICAgb2YgTWFwLVJlcXVl c3RzLCBpbmNyZWFzaW5nIHRoZSBsb2FkIG9uIHRoZSBkaXN0cmlidXRlZCBtYXBwaW5nCiAg ICAgIGRhdGFiYXNlLiAgVGhpcyBjb3VsZCBiZSBzb2x2ZWQgYnkgc3luY2hyb25pemluZyBJ VFIgY2FjaGVzLCB2aWEKICAgICAgSUdQIG9yIG11bHRpY2FzdC4KCjIuNC4gIEludGVyLVNl cnZpY2UgUHJvdmlkZXIgVHJhZmZpYyBFbmdpbmVlcmluZwoKICAgV2l0aCBMSVNQLCB0d28g TElTUCBzaXRlcyBjYW4gcm91dGUgcGFja2V0cyBhbW9uZyB0aGVtIGFuZCBjb250cm9sCiAg IHRoZWlyIGluZ3Jlc3MgVEUgcG9saWNpZXMuICBUeXBpY2FsbHksIExJU1AgaXMgc2VlbiBh cyBhcHBsaWNhYmxlIHRvCiAgIHN0dWIgbmV0d29ya3MsIGhvd2V2ZXIgdGhlIExJU1AgcHJv dG9jb2wgY2FuIGFsc28gYmUgYXBwbGllZCB0bwogICB0cmFuc2l0IG5ldHdvcmtzIHJlY3Vy c2l2ZWx5LgoKICAgQ29uc2lkZXIgdGhlIHNjZW5hcmlvIGRlcGljdGVkIGluIEZpZ3VyZSA0 LiAgUGFja2V0cyBvcmlnaW5hdGluZyBmcm9tCiAgIHRoZSBMSVNQIHNpdGUgU3R1YjEsIGNs aWVudCBvZiBJU1BfQSwgd2l0aCBkZXN0aW5hdGlvbiBTdHViNCwgY2xpZW50CiAgIG9mIElT UF9CLCBhcmUgTElTUCBlbmNhcHN1bGF0ZWQgYXQgdGhlaXIgZW50cnkgcG9pbnQgaW50byB0 aGUgSVNQX0EncwogICBuZXR3b3JrLiAgVGhlIGV4dGVybmFsIElQIGhlYWRlciBub3cgaGFz IGFzIHRoZSBzb3VyY2UgUkxPQyBhbiBJUAogICBmcm9tIElTUF9BJ3MgYWRkcmVzcyBzcGFj ZSBhbmQgZGVzdGluYXRpb24gUkxPQyBmcm9tIElTUF9CJ3MgYWRkcmVzcwogICBzcGFjZS4g IE9uZSBvciBtb3JlIEFTZXMgc2VwYXJhdGUgSVNQX0EgZnJvbSBJU1BfQi4gV2l0aCBhIHNp bmdsZQogICBsZXZlbCBvZiBMSVNQIGVuY2Fwc3VsYXRpb24sIFN0dWI0IGhhcyBjb250cm9s IG92ZXIgaXRzIGluZ3Jlc3MKICAgdHJhZmZpYy4gIEhvd2V2ZXIsIElTUF9CIG9ubHkgaGFz IHRoZSBjdXJyZW50IHRvb2xzIChzdWNoIGFzIEJHUAogICBwcmVmaXggZGVhZ2dyZWdhdGlv bikgdG8gY29udHJvbCBvbiB3aGljaCBvZiBoaXMgb3duIHVwc3RyZWFtIG9yCiAgIHBlZXJp bmcgbGlua3Mgc2hvdWxkIHBhY2tldHMgZW50ZXIuICBUaGlzIGlzIGVpdGhlciBub3QgZmVh c2libGUgKGlmCiAgIGZpbmUtZ3JhaW5lZCBwZXItY3VzdG9tZXIgY29udHJvbCBpcyByZXF1 aXJlZCwgdGhlIHZlcnkgc3BlY2lmaWMKICAgcHJlZml4ZXMgbWF5IG5vdCBiZSBwcm9wYWdh dGVkKSBvciBpbmNyZWFzZXMgREZaIHRhYmxlIHNpemUuCgogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgXy4tLS4KICAgIFN0dWIxIC4uLiAgICstLS0tLS0tKyAgICAgICwt JycgICAgIGAtLS4gICAgICArLS0tLS0tLSsgICAuLi4gU3R1YjMKICAgICAgICAgICAgIFwg IHwgICBSX0ExfC0tLS0sJyAgICAgICAgICAgICBgLiAtLS18Ul9CMSAgIHwgIC8KICAgICAg ICAgICAgICAtLXwgICBSX0EyfC0tLSggICAgIFRyYW5zaXQgICAgICkgICB8ICAgICAgIHwt LQogICAgU3R1YjIgLi4uLyAgfCAgIFJfQTN8LS0tLS0uICAgICAgICAgICAgICwnIC0tLXxS X0IyICAgfCAgXC4uLiBTdHViNAogICAgICAgICAgICAgICAgKy0tLS0tLS0rICAgICAgYC0t LiAgICAgXy4tJyAgICAgICstLS0tLS0tKwogICAgICAgICAgLi4uICAgICBJU1BfQSAgICAg ICAgICAgIGAtLScnICAgICAgICAgICAgSVNQX0IgICAgIC4uLgoKICAgICAgICAgICAgICAg RmlndXJlIDQ6IEludGVyLVNlcnZpY2UgcHJvdmlkZXIgVEUgc2NlbmFyaW8KCiAgIEEgc29s dXRpb24gZm9yIHRoaXMgaXMgdG8gYXBwbHkgTElTUCByZWN1cnNpdmVseS4gIElTUF9BIGFu ZCBJU1BfQgogICBtYXkgcmVhY2ggYSBiaWxhdGVyYWwgYWdyZWVtZW50IHRvIGRlcGxveSB0 aGVpciBvd24gcHJpdmF0ZSBtYXBwaW5nCiAgIHN5c3RlbS4gIElTUF9BIHRoZW4gZW5jYXBz dWxhdGVzIHBhY2tldHMgZGVzdGluZWQgZm9yIHRoZSBwcmVmaXhlcyBvZgogICBJU1BfQiwg d2hpY2ggYXJlIGxpc3RlZCBpbiB0aGUgc2hhcmVkIG1hcHBpbmcgc3lzdGVtLiAgTm90ZSB0 aGF0IGluCiAgIHRoaXMgY2FzZSB0aGUgcGFja2V0IGlzIGRvdWJsZS1lbmNhcHN1bGF0ZWQu ICBJU1BfQidzIEVUUiByZW1vdmVzIHRoZQogICBvdXRlciwgc2Vjb25kIGxheWVyIG9mIExJ U1AgZW5jYXBzdWxhdGlvbiBmcm9tIHRoZSBpbmNvbWluZyBwYWNrZXQsCiAgIGFuZCByb3V0 ZXMgaXQgdG93YXJkcyB0aGUgb3JpZ2luYWwgUkxPQywgdGhlIEVUUiBvZiBTdHViNCwgd2hp Y2ggZG9lcwogICB0aGUgZmluYWwgZGVjYXBzdWxhdGlvbi4KCiAgIElmIElTUF9BIGFuZCBJ U1BfQiBhZ3JlZSB0byBzaGFyZSBhIHByaXZhdGUgZGlzdHJpYnV0ZWQgbWFwcGluZwogICBk YXRhYmFzZSwgYm90aCBjYW4gY29udHJvbCB0aGVpciBpbmdyZXNzIFRFIHdpdGhvdXQgdGhl IG5lZWQgb2YKICAgZGlzYWdncmVnYXRpbmcgcHJlZml4ZXMuICBJbiB0aGlzIHNjZW5hcmlv IHRoZSBwcml2YXRlIGRhdGFiYXNlCiAgIGNvbnRhaW5zIFJMT0MtdG8tUkxPQyBiaW5kaW5n cy4gIFRoZSBjb252ZXJnZW5jZSB0aW1lIG9uIHRoZSBURQogICBwb2xpY2llcyB1cGRhdGVz IGlzIGZhc3QsIHNpbmNlIElTUHMgb25seSBoYXZlIHRvIHVwZGF0ZS9xdWVyeSBhCiAgIG1h cHBpbmcgdG8vZnJvbSB0aGUgZGF0YWJhc2UuCgogICBUaGUgbWFpbiBkaXNhZHZhbnRhZ2Vz IG9mIHRoaXMgZGVwbG95bWVudCBjYXNlIGFyZToKCiAgIDEuICBFeHRyYSBMSVNQIGhlYWRl ciBpcyBuZWVkZWQuICBUaGlzIGluY3JlYXNlcyB0aGUgcGFja2V0IHNpemUgYW5kLAogICAg ICAgZm9yIGVmZmljaWVudCBjb21tdW5pY2F0aW9ucywgaXQgcmVxdWlyZXMgdGhhdCB0aGUg TVRVIGJldHdlZW4KICAgICAgIGJvdGggSVNQcyBjYW4gYWNjb21vZGF0ZSBkb3VibGUtZW5j YXBzdWxhdGVkIHBhY2tldHMuCgogICAyLiAgVGhlIElTUCBJVFIgbXVzdCBlbmNhcHN1bGF0 ZSBwYWNrZXRzIGFuZCB0aGVyZWZvcmUgbXVzdCBrbm93IHRoZQogICAgICAgUkxPQy10by1S TE9DIGJpbmRpbmcuICBUaGVzZSBiaW5kaW5ncyBhcmUgc3RvcmVkIGluIGEgbWFwcGluZwog ICAgICAgZGF0YWJhc2UgYW5kIG1heSBiZSBjYWNoZWQgaW4gdGhlIElUUidzIG1hcHBpbmcg Y2FjaGUuICBDYWNoZQogICAgICAgbWlzc2VzIGxlYWQgdG8gYW4gZXh0cmEgbG9va3VwIGxh dGVuY3ksIHVubGVzcyBORVJECiAgICAgICBbSS1ELmxlYXItbGlzcC1uZXJkXSBpcyB1c2Vk IGZvciB0aGUgbG9va3Vwcy4KCiAgIDMuICBUaGUgb3BlcmF0aW9uYWwgb3ZlcmhlYWQgb2Yg bWFpbnRhaW5pbmcgdGhlIHNoYXJlZCBtYXBwaW5nCiAgICAgICBkYXRhYmFzZS4KCjIuNS4g IFR1bm5lbCBSb3V0ZXJzIGJlaGluZCBOQVQKCjIuNS4xLiAgSVRSCgogICBQYWNrZXRzIGVu Y2Fwc3VsYXRlZCBieSBhbiBJVFIgYXJlIGp1c3QgVURQIHBhY2tldHMgZnJvbSBhIE5BVAog ICBkZXZpY2UncyBwb2ludCBvZiB2aWV3LCBhbmQgdGhleSBhcmUgaGFuZGxlZCBsaWtlIGFu eSBVRFAgcGFja2V0LAogICB0aGVyZSBhcmUgbm8gYWRkaXRpb25hbCByZXF1aXJlbWVudHMg Zm9yIExJU1AgZGF0YSBwYWNrZXRzLgoKICAgTWFwLVJlcXVlc3RzIHNlbnQgYnkgYW4gSVRS LCB3aGljaCBjcmVhdGUgdGhlIHN0YXRlIGluIHRoZSBOQVQgdGFibGUKICAgaGF2ZSBhIGRp ZmZlcmVudCA1LXR1cGxlIGluIHRoZSBJUCBoZWFkZXIgdGhhbiB0aGUgTWFwLVJlcGx5CiAg IGdlbmVyYXRlZCBieSB0aGUgYXV0aG9yaXRhdGl2ZSBFVFIuICBTaW5jZSB0aGUgc291cmNl IGFkZHJlc3Mgb2YgdGhpcwogICBwYWNrZXQgaXMgZGlmZmVyZW50IGZyb20gdGhlIGRlc3Rp bmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHJlcXVlc3QKICAgcGFja2V0LCBubyBzdGF0ZSB3aWxs IGJlIG1hdGNoZWQgaW4gdGhlIE5BVCB0YWJsZSBhbmQgdGhlIHBhY2tldCB3aWxsCiAgIGJl IGRyb3BwZWQuICBUbyBhdm9pZCB0aGlzLCB0aGUgTkFUIGRldmljZSBoYXMgdG8gZG8gdGhl IGZvbGxvd2luZzoKCiAgIDEuICBTZW5kIGFsbCBVRFAgcGFja2V0cyB3aXRoIHNvdXJjZSBw b3J0IDQzNDIsIHJlZ2FyZGxlc3Mgb2YgdGhlCiAgICAgICBkZXN0aW5hdGlvbiBwb3J0LCB0 byB0aGUgUkxPQyBvZiB0aGUgSVRSLiAgVGhlIG1vc3Qgc2ltcGxlIHdheSB0bwogICAgICAg YWNoaWV2ZSB0aGlzIGlzIGNvbmZpZ3VyaW5nIDE6MSBOQVQgbW9kZSBmcm9tIHRoZSBleHRl cm5hbCBSTE9DCiAgICAgICBvZiB0aGUgTkFUIGRldmljZSB0byB0aGUgSVRSJ3MgUkxPQyAo Q2FsbGVkICJETVoiIG1vZGUgaW4KICAgICAgIGNvbnN1bWVyIGJyb2FkYmFuZCByb3V0ZXJz KS4KCiAgIDIuICBSZXdyaXRlIHRoZSBJVFItQUZJIGFuZCAiT3JpZ2luYXRpbmcgSVRSIFJM T0MgQWRkcmVzcyIgZmllbGRzIGluCiAgICAgICB0aGUgcGF5bG9hZC4KCjIuNS4yLiAgRVRS CgogICBBbiBFVFIgcGxhY2VkIGJlaGluZCBOQVQgaXMgcmVhY2hhYmxlIGZyb20gdGhlIG91 dHNpZGUgYnkgdGhlCiAgIEludGVybmV0LWZhY2luZyBsb2NhdG9yIG9mIHRoZSBOQVQgZGV2 aWNlLiAgSXQgbmVlZHMgdG8ga25vdyB0aGlzCiAgIGxvY2F0b3IgKGFuZCBjb25maWd1cmUg YSBsb29wYmFjayBpbnRlcmZhY2Ugd2l0aCBpdCksIHNvIHRoYXQgaXQgY2FuCiAgIHVzZSBp dCBpbiB0aGUgTWFwLVJlcGxpZXMuICBUaHVzIHN1cHBvcnQgZm9yIGR5bmFtaWMgbG9jYXRv cnMgZm9yIHRoZQogICBtYXBwaW5nIGRhdGFiYXNlIGlzIG5lZWRlZCBpbiBMSVNQIGVxdWlw bWVudC4gIEV4aXN0aW5nIG1lY2hhbmlzbXMKICAgdXNlZCBmb3IgdXBkYXRpbmcgZHluYW1p YyBETlMgY2FuIGJlIHVzZWQgdG8gYXV0b21hdGUgdGhlIHByb2Nlc3MuCgoyLjYuICBTdW1t YXJ5IGFuZCBGZWF0dXJlIE1hdHJpeAoKICAgICAgICAgIEZlYXR1cmUgICAgICAgICAgICAg ICAgICAgICAgICAgQ0UgICAgUEUgICAgU3BsaXQgICBSZWMuCiAgICAgICAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAg ICAgICAgQ29udHJvbCBvZiBpbmdyZXNzIFRFICAgICAgICAgICAgeCAgICAgLSAgICAgIHgg ICAgICB4CiAgICAgICAgICBObyBtb2RpZmljYXRpb25zIHRvIGV4aXN0aW5nCiAgICAgICAg ICAgICBpbnQuIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgICB4ICAgICB4ICAgICAgLSAgICAg IC0KICAgICAgICAgIExvYy1TdGF0dXMtQml0cyBzeW5jICAgICAgICAgICAgIHggICAgIC0g ICAgICB4ICAgICAgeAogICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5Obzwv Zm9udD48L3N0cmlrZT4KICAgICAgICAgIE1UVS9QTVRVRCBpc3N1ZXMgPHN0cm9uZz48Zm9u dCBjb2xvcj0iZ3JlZW4iPm1pbmltaXplZDwvZm9udD48L3N0cm9uZz4gICAgICAgLSAgICAg eCAgICAgIC0gICAgICB4CgozLiAgUHJveHkgVHVubmVsIFJvdXRlcnMKCjMuMS4gIFAtSVRS CgogICBQcm94eSBJbmdyZXNzIFR1bm5lbCBSb3V0ZXJzIChQLUlUUnMpIGFyZSBwYXJ0IG9m IHRoZSBMSVNQL25vbi1MSVNQCiAgIHRyYW5zaXRpb24gbWVjaGFuaXNtLCBhbGxvd2luZyBu b24tTElTUCBzaXRlcyB0byByZWFjaCBMSVNQIHNpdGVzLgogICBUaGV5IGFubm91bmNlIGNl cnRhaW4gYWdncmVnYXRlZCBFSUQgcHJlZml4ZXMgaW50byB0aGUgZ2xvYmFsIEJHUAogICBy b3V0aW5nIHRhYmxlcyB0byBhdHRyYWN0IHRyYWZmaWMgZnJvbSBub24tTElTUCBzaXRlcyB0 b3dhcmRzIEVJRHMgaW4KICAgdGhlIGNvdmVyZWQgcmFuZ2UuICBUaGV5IGRvIHRoZSBtYXBw aW5nIHN5c3RlbSBsb29rdXAsIGFuZAogICBlbmNhcHN1bGF0ZSByZWNlaXZlZCBwYWNrZXRz IHRvd2FyZHMgdGhlIGFwcHJvcHJpYXRlIEVUUi4gIE5vdGUgdGhhdAogICBmb3IgdGhlIHJl dmVyc2UgcGF0aCBMSVNQIHNpdGVzIGNhbiByZWFjaCBub24tTElTUCBzaXRlcyBzaW1wbHkg YnkKICAgbm90IGVuY2Fwc3VsYXRpbmcgdHJhZmZpYy4gIFNlZSBbSS1ELmlldGYtbGlzcC1p bnRlcndvcmtpbmddIGZvciBhCiAgIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIFAtSVRSIGZ1 bmN0aW9uYWxpdHkuCgogICBBIExJU1Agc2l0ZSBuZWVkcyBhbiBpbnRlcndvcmtpbmcgbWVj aGFuaXNtIHRvIGNvbW11bmljYXRlIHdpdGggbm9uLQogICBMSVNQIHNpdGVzLiAgQSBQLUlU UiBjYW4gZnVsZmlsbCB0aGlzIHJvbGUsIGVuYWJsaW5nIGVhcmx5IGFkb3B0ZXJzCiAgIHRv IHNlZSB0aGUgYmVuZWZpdHMgb2YgTElTUC4KCjMuMS4xLiAgRUlEIHJlZ2lzdHJhciBQLUlU UiBzZXJ2aWNlcwoKICAgRUlEIHJlZ2lzdHJhcnMgYXJlIGluIGEgZ29vZCBwb3NpdGlvbiB0 byBvZmZlciBQLUlUUiBzZXJ2aWNlcyB3aGVuCiAgIGFsbG9jYXRpbmcgRUlEIHByZWZpeGVz LCB1bmxlc3MgdGhlIHJlZ2lzdHJhbnQgd2FudHMgdG8gZGVwbG95IGl0J3MKICAgb3duIFAt SVRSIGluZnJhc3RydWN0dXJlLiAgU2luY2UgdGhlIHJlZ2lzdHJhciBpcyBhbHJlYWR5IHBy b3ZpZGluZwogICBNYXAtU2VydmVyIHNlcnZpY2VzLCBwdWJsaXNoaW5nIHJlZ2lzdGVyZWQg cHJlZml4ZXMgaW50byB0aGUgbWFwcGluZwogICBzeXN0ZW0sIHRoZXkgY2FuIGFubm91bmNl IGFuIGFnZ3JlZ2F0ZSBvZiB0aGVpciBhbGxvY2F0ZWQgRUlEIHJhbmdlCiAgIGludG8gdGhl IERGWi4gIFRoaXMgd2F5IHRoZSBQLUlUUiBmdW5jdGlvbiBjYW4gYmUgY29sb2NhdGVkIHdp dGggdGhlCiAgIE1TIGFuZCB0aGUgbnVtYmVyIG9mIHByZWZpeGVzIGFkdmVydGl6ZWQgdG8g dGhlIERGWiByZWR1Y2VkLiAgT24gdGhlCiAgIG90aGVyIGhhbmQsIGF0IHRoZSBlYXJseSBz dGFnZXMgb2YgdGhlIHRyYW5zaXRpb24gdGhpcyBtYXkgaW1wbHkgYQogICBzaWduaWZpY2Fu dCBwb3J0aW9uIG9mIGEgTElTUCBzaXRlJ3MgdHJhZmZpYyBhbHdheXMgZ29pbmcgdGhyb3Vn aCB0aGUKICAgUC1JVFIsIHdoaWNoIG1heSBub3QgYmUgYWNjZXB0YWJsZSBmb3IgdGhlIHJl Z2lzdHJhci4KCjMuMS4yLiAgTElTUCtCR1AKCiAgIEF0IHRoZSBvdGhlciBleHRyZW1lIGV4 aXN0cyB0aGUgcG9zc2liaWxpdHkgdG8gY29sb2NhdGUgdGhlIFAtSVRSCiAgIGZ1bmN0aW9u IHdpdGggdGhlIHNpdGUncyB0dW5uZWwgcm91dGVyKHMpLiAgVGhpcyB3b3VsZCBlZmZlY3Rp dmVseQogICBrZWVwIHRvZGF5J3MgZnVuY2lvbmFsaXR5IGZvciBjb21tdW5pY2F0aW9ucyB3 aXRoIGxlZ2FjeSBzaXRlcywgYW5kCiAgIGFkZGluZyB0aGUgYmVuZWZpdHMgb2YgTElTUCBm b3IgY29tbXVuaWNhdGlvbnMgd2l0aCBvdGhlciBlYXJseQogICBhZG9wdGVycy4gIFRoZSBk b3duc2lkZSBpcyBubyBkZWNyZWFzZSBpbiBnbG9iYWwgREZaIHN0YXRlLgoKICAgSG93ZXZl ciwgaW4gdGhpcyBjYXNlIHRoZSBQLUlUUiBpcyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5LCBz aW5jZQogICBwYWNrZXRzIHJlYWNoaW5nIHRoZSBzaXRlIGJvcmRlciBuZWVkIG5vIGVuY2Fw c3VsYXRpb24gdG8gcmVhY2ggdGhlCiAgIG5ldHdvcmsuCgozLjEuMy4gIENvbnRlbnQgRGVs aXZlcnkgTmV0d29yayBQLUlUUiBzZXJ2aWNlcwoKICAgVGhlIG1haW4gZGlzYWR2YW50YWdl IG9mIHVzaW5nIFAtSVRScyBpcyBwYXRoIHN0cmV0Y2ggKHVubGVzcwogICBjb2xvY2F0ZWQg d2l0aCB0aGUgeFRScykuICBQYWNrZXRzIGZyb20gbm9uLUxJU1Agc2l0ZXMgZ29pbmcgdGhy b3VnaAogICB0aGUgUC1JVFIgbWF5IHRha2UgYSBzdWJvcHRpbWFsIHJvdXRlLiAgQmVjYXVz ZSBvZiB0aGlzLCBsYXJnZQogICBjb250ZW50IHByb3ZpZGVycyBtYXkgaGF2ZSB0aGUgaW5j ZW50aXZlIHRvIGRlcGxveSBnZW9ncmFwaGljYWxseQogICBkaXZlcnNlIFAtSVRScywgYW5u b3VuY2luZyB0aGVpciBFSUQgcHJlZml4IHdpdGggYW55Y2FzdC4gIEV4aXN0aW5nCiAgIGNv bnRlbnQgZGVsaXZlcnkgbmV0d29ya3MgKENETnMpIGNvdWxkIGxldmVyYWdlIHRoZWlyIGV4 aXN0aW5nCiAgIGluZnJhc3RydWN0dXJlIHRvIGFkZCB0aGlzIHNlcnZpY2UgdG8gdGhlaXIg cG9ydGZvbGlvLCBzbyB0aGF0CiAgIGluZGVwZW5kZW50IGNvbnRlbnQgcHJvdmlkZXJzIGNv dWxkIGFsc28gb2ZmZXIgaW1wcm92ZWQgbGF0ZW5jaWVzIHRvCiAgIHRoZWlyIHVzZXJzLiAg V2l0aCB0aGlzIHNlcnZpY2UgaW4gcGxhY2UgYSBuZXcgTElTUCBzaXRlIG5lZWQgbm90CiAg IGRlcGxveSBpdCdzIG93biBQLUlUUiwgYnV0IHJhdGhlciBwYXkgZm9yIHRoZSBzZXJ2aWNl IGFuZCBoYXZlIGxvdwogICBwYXRoIHN0cmV0Y2guCgozLjEuNC4gIENvbnRlbnQgRGVsaXZl cnkgTmV0d29yayBsb2FkIGJhbGFuY2luZwoKICAgSW4gYWRkaXRpb24gdG8gcHJvdmlkaW5n IFAtSVRSIHNlcnZpY2VzIHRvIHRoaXJkIHBhcnRpZXMsIENETnMgY2FuCiAgIGxldmVyYWdl IHRoZSBpbXByb3ZlbWVudCBicm91Z2h0IGJ5IExJU1AgZm9yIHRoZWlyIG93biBhZHZhbnRh Z2UuICBCeQogICBkZXBsb3lpbmcgUC1JVFJzIGluIHN0cmF0ZWdpYyBsb2NhdGlvbnMsIHRy YWZmaWMgZW5naW5lZXJpbmcgY291bGQgYmUKICAgaW1wcm92ZWQgYmV5b25kIHdoYXQgaXMg Y3VycmVudGx5IG9mZmVyZWQgYnkgRE5TLCBieSBhZGp1c3RpbmcKICAgcGVyY2VudGFnZXMg b2YgdHJhZmZpYyBmbG93IHRvIGNlcnRhaW4gZGF0YSBjZW50ZXJzLCBkZXBlbmRpbmcgb24K ICAgdGhlaXIgbG9hZC4gIFRoaXMgY2FuIGJlIGFjaGlldmVkIGJ5IHNldHRpbmcgdGhlIGFw cHJvcHJpYXRlCiAgIHByaW9yaXRpZXMsIHdlaWdodHMgYW5kIGxvYy1zdGF0dXMtYml0cyBp biBtYXBwaW5ncy4gIEFuZCBzaW5jZSB0aGUKICAgUC1JVFJzIGFyZSBjb250cm9sbGVkIGJ5 IHRoZSBDRE4gb3BlcmF0b3JzLCBjaGFuZ2VzIGNhbiB0YWtlIHBsYWNlCiAgIGluc3RhbnRh bmVvdXNseS4KCjxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj4zLjEuNS4gIElTUCBQLUlU UiBzZXJ2aWNlcwoKICAgSW4gYWxsIHRoZSBhYm92ZSBjYXNlcywgdGhlIGNsaWVudCBmb3Ig UC1JVFIgc2VydmljZXMgd2FzIGEgbmV3IExJU1AKICAgc2l0ZSwgd2lzaGluZyB0byBlbnN1 cmUgZ2xvYmFsIHJlYWNoYWJpbGl0eSBvZiBpdHMgYWxsb2NhdGVkIEVJRAogICBzcGFjZSBm cm9tIG5vbi1MSVNQIG5ldHdvcmtzLiAgT24gdGhlIGZsaXAgc2lkZSwgSVNQcyBjYW4gYWxz bwogICBwcm92aWRlIFAtSVRSIHNlcnZpY2VzIHRvIHRoZWlyIG5vbi1MSVNQIGN1c3RvbWVy cy4gIFRvIGRvIHRoYXQgdGhleQogICBhbm5vdW5jZSBhbiBhZ2dyZWdhdGUgb2YgYWxsIGtu b3duIEVJRCBwcmVmaXhlcyBkb3duc3RyZWFtIHRvIHRoZWlyCiAgIGN1c3RvbWVycy4gIFRo aXMgZGVwbG95bWVudCBzY2VuYXJpbyBoYXMgbm8gZGlyZWN0IGVmZmVjdCBvbiB0aGUgREZa CiAgIHNpemUuCgogICBBZGRpdGlvbmFsbHksIHRoZXkgY2FuIHNlbGVjdCBmcm9tIHRoZXNl IGFnZ3JlZ2F0ZXMgdGhlIEVJRCBwcmVmaXhlcwogICBvZiB0aGVpciBMSVNQIGN1c3RvbWVy cywgYW5kIGFubm91bmNlIHRoZW0gdXBzdHJlYW0uCgogICBOb3RlIHRoYXQgdGhlIGFib3Zl IGRvZXMgbm90IGluY3JlYXNlIHRoZSB0cmFmZmljIG9mIHRoZSBwcm92aWRlcjoKICAgY3Vz dG9tZXJzIHVzaW5nIGV4dGVybmFsIFAtSVRScyB3b3VsZCBzdGlsbCB1c2UgdGhlIElTUCBu ZXR3b3JrIGZvcgogICB0cmFuc2l0LCBhbmQgaXQgZG9lc24ndCBhdHRyYWN0IG5vbi1jdXN0 b21lciB0cmFmZmljLiAgVHJhZmZpYyBmb3IKICAgdGhlaXIgTElTUCBjdXN0b21lcnMgaGFz IHRvIHRyYXZlcnNlIHRoZSBwcm92aWRlciBhcyB3ZWxsLiAgT24gdGhlCiAgIG90aGVyIGhh bmQsIGJ5IG9mZmVyaW5nIGEgUC1JVFIsIHRoZSBJU1AgZW5zdXJlcyB0aGF0IGFsbCBvZiBp dHMgbm9uLQogICBMSVNQIGN1c3RvbWVycyBjYW4gcmVhY2ggYW55IExJU1Agc2l0ZSwgd2l0 aCBtaW5pbWFsIChpZiBhbnkpIHBhdGgKICAgc3RyZWNoLCByZWdhcmRsZXNzIG9mIHRoZSBx dWFsaXR5IG9mIFAtSVRScyBzZXJ2aWNlcyBjb250cmFjdGVkIGJ5CiAgIGRlc3RpbmF0aW9u IHNpdGVzLiAgQWRkaXRpb25hbGx5LCB0aGV5IGVuc3VyZSByZWFjaGFiaWxpdHkgZm9yIHRo ZWlyCiAgIExJU1AgY3VzdG9tZXJzIGFzIHdlbGwsIHBvdGVudGlhbGx5IGFnZ3JlZ2F0aW5n IHByZWZpeGVzIGZyb20gc2V2ZXJhbAogICBjdXN0b21lcnMsIGFuZCBhdm9pZGluZyB0aGUg TElTUCtCR1Agc2NlbmFyaW8uCgogICBGb3IgcGVyZm9ybWFuY2UgcmVhc29ucywgYW5kIHRv IHNpbXBsaWZ5IFAtSVRSIG1hbmFnZW1lbnQsIGl0IGlzCiAgIGRlc2lyYWJsZSB0byBtaW5p bWl6ZSB0aGUgbnVtYmVyIG9mIG5vbi1hZ2dyZWdhYmxlIEVJRCBwcmVmaXhlcy4gIEluCiAg IElQdjYgdGhpcyBjYW4gYmUgZWFzaWx5IGFjaGlldmVkIGlmIGEgbGFyZ2UgcGJsb2NrIGlz IHJlc2VydmVkIGFzCiAgIExJU1AgRUlEIHNwYWNlLjwvZm9udD48L3N0cm9uZz4KCjMuMi4g IFAtRVRSCgogICBJbiBjb250cmFzdCB0byBQLUlUUnMsIFAtRVRScyBhcmUgbm90IHJlcXVp cmVkIGZvciB0aGUgY29ycmVjdAogICBmdW5jdGlvbmluZyBvZiBhbGwgTElTUCBzaXRlcy4g IFRoZXJlIGFyZSB0d28gY2FzZXMsIHdoZXJlIHRoZXkgY2FuCiAgIGJlIG9mIGdyZWF0IGhl bHA6CgogICBvICBMSVNQIHNpdGVzIHdpdGggdW5pY2FzdCByZXZlcnNlIHBhdGggZm9yd2Fy ZGluZyAodVJQRikKICAgICAgcmVzdHJpY3Rpb25zLCBhbmQKCiAgIG8gIExJU1Agc2l0ZXMg d2l0aG91dCBuYXRpdmUgSVB2NiBjb21tdW5pY2F0aW5nIHdpdGggTElTUCBub2RlcyB3aXRo CiAgICAgIElQdjYtb25seSBsb2NhdG9ycy4KCiAgIEluIHRoZSBmaXJzdCBjYXNlLCB1UlBG IGZpbHRlcmluZyBpcyBhcHBsaWVkIGF0IHRoZWlyIHVwc3RyZWFtIFBFCiAgIHJvdXRlci4g IFdoZW4gZm9yd2FyZGluZyB0cmFmZmljIHRvIG5vbi1MSVNQIHNpdGVzLCBhbiBJVFIgZG9l cyBub3QKICAgZW5jYXBzdWxhdGUgcGFja2V0cywgbGVhdmluZyB0aGUgb3JpZ2luYWwgSVAg aGVhZGVycyBpbnRhY3QuICBBcyBhCiAgIHJlc3VsdCwgcGFja2V0cyB3aWxsIGhhdmUgRUlE cyBpbiB0aGVpciBzb3VyY2UgYWRkcmVzcy4gIFNpbmNlIHdlIGFyZQogICBkaXNjdXNzaW5n IHRoZSB0cmFuc2l0aW9uIHBlcmlvZCwgd2UgY2FuIGFzc3VtZSB0aGF0IGEgcHJlZml4CiAg IGNvdmVyaW5nIHRoZSBFSURzIG9yaWdpbmF0ZWQgZnJvbSB0aGUgTElTUCBzaXRlIGlzIGFk dmVydGl6ZWQgdG8gdGhlCiAgIGdsb2JhbCByb3V0aW5nIHRhYmxlcyBieSBhIFAtSVRSLCBh bmQgdGhlIFBFIHJvdXRlciBoYXMgYSByb3V0ZQogICB0b3dhcmRzIGl0LiAgSG93ZXZlciwg aXQgd2lsbCBub3QgYmUgb24gdGhlIGludGVyZmFjZSB0b3dhcmRzIHRoZSBDRQogICByb3V0 ZXIsIHNvIG5vbi1lbmNhcHN1bGF0ZWQgcGFja2V0cyB3aWxsIGZhaWwgdVJQRiBjaGVja3Mu CgogICBUbyBhdm9pZCB0aGlzIGZpbHRlcmluZywgdGhlIGFmZmVjdGVkIElUUiBlbmNhcHN1 bGF0ZXMgcGFja2V0cwogICB0b3dhcmRzIHRoZSBsb2NhdG9yIG9mIHRoZSBQLUVUUiBmb3Ig bm9uLUxJU1AgZGVzdGluYXRpb25zLiAgTm93IHRoZQogICBzb3VyY2UgYWRkcmVzcyBvZiB0 aGUgcGFja2V0cywgYXMgc2VlbiBieSB0aGUgUEUgcm91dGVyIGlzIHRoZSBJVFIncwogICBs b2NhdG9yLCB3aGljaCB3aWxsIG5vdCBmYWlsIHRoZSB1UlBGIGNoZWNrLiAgVGhlIFAtRVRS IHRoZW4KICAgZGVjYXBzdWxhdGVzIGFuZCBmb3J3YXJkcyB0aGUgcGFja2V0cy4KCiAgIFRo ZSBzZWNvbmQgdXNlIGNhc2UgaXMgSVB2NC10by1JUHY2IHRyYW5zaXRpb24uICBTZXJ2aWNl IHByb3ZpZGVycwogICB1c2luZyBvbGRlciBhY2Nlc3MgbmV0d29yayBoYXJkd2FyZSwgd2hp Y2ggb25seSBzdXBwb3J0cyBJUHY0IGNhbgogICBzdGlsbCBvZmZlciBJUHY2IHRvIHRoZWly IGNsaWVudHMsIGJ5IHByb3ZpZGluZyBhIENQRSBkZXZpY2UgcnVubmluZwogICBMSVNQLCBh bmQgUC1FVFIocykgZm9yIGFjY2Vzc2luZyBJUHY2LW9ubHkgbm9uLUxJU1Agc2l0ZXMgYW5k IExJU1AKICAgc2l0ZXMsIHdpdGggSVB2Ni1vbmx5IGxvY2F0b3JzLiAgUGFja2V0cyBvcmln aW5hdGluZyBmcm9tIHRoZSBjbGllbnQKICAgTElTUCBzaXRlIGZvciB0aGVzZSBkZXN0aW5h dGlvbnMgd291bGQgYmUgZW5jYXBzdWxhdGVkIHRvd2FyZHMgdGhlCiAgIFAtRVRSJ3MgSVB2 NCBsb2NhdG9yLiAgVGhlIFAtRVRSIGlzIGluIGEgbmF0aXZlIElQdjYgbmV0d29yaywKICAg ZGVjYXBzdWxhdGluZyBhbmQgZm9yd2FyZGluZyBwYWNrZXRzLiAgRm9yIG5vbi1MSVNQIGRl c3RpbmF0aW9uLCB0aGUKICAgcGFja2V0IHRyYXZlbHMgbmF0aXZlbHkgZnJvbSB0aGUgUC1F VFIuICBGb3IgTElTUCBkZXN0aW5hdGlvbnMgd2l0aAogICBJUHY2LW9ubHkgbG9jYXRvcnMs IHRoZSBwYWNrZXQgd2lsbCBnbyB0aHJvdWdoIGEgUC1JVFIsIGluIG9yZGVyIHRvCiAgIHJl YWNoIGl0cyBkZXN0aW5hdGlvbi4KCiAgIEZvciBtb3JlIGRldGFpbHMgb24gUC1FVFJzIHNl ZSB0aGUgW0ktRC5pZXRmLWxpc3AtaW50ZXJ3b3JraW5nXQogICBkcmFmdC4KCiAgIFAtRVRS cyBjYW4gYmUgZGVwbG95ZWQgYnkgSVNQcyB3aXNoaW5nIHRvIG9mZmVyIHZhbHVlLWFkZGVk IHNlcnZpY2VzCiAgIHRvIHRoZWlyIGN1c3RvbWVycy4gIEFzIGlzIHRoZSBjYXNlIHdpdGgg UC1JVFJzLCBQLUVUUnMgdG9vIG1heQogICBpbnRyb2R1Y2UgcGF0aCBzdHJldGNoLiAgQmVj YXVzZSBvZiB0aGlzIHRoZSBJU1AgbmVlZHMgdG8gY29uc2lkZXIKICAgdGhlIHRyYWRlb2Zm IG9mIHVzaW5nIHNldmVyYWwgZGV2aWNlcywgY2xvc2UgdG8gdGhlIGN1c3RvbWVycywgdG8K ICAgbWluaW1pemUgaXQsIG9yIGZldyBkZXZpY2VzLCBmYXJ0aGVyIGF3YXkgZnJvbSB0aGUg Y3VzdG9tZXJzLAogICBtaW5pbWl6aW5nIGNvc3QgaW5zdGVhZC4gIENETnMgY2FuIGFsc28g bGV2ZXJhZ2UgdGhlaXIgZXhpc3RpbmcKICAgaW5mcmFzdHJ1Y3R1cmUsIG9mZmVyaW5nIHBh aWQgUC1FVFJzIGFjY2Vzcy4KCiAgIFNpbmNlIHRoZSBkZXBsb3ltZW50IGluY2VudGl2ZXMg Zm9yIFAtSVRScyBhbmQgUC1FVFJzIGFyZSBkaWZmZXJlbnQsCiAgIGl0IGlzIGxpa2VseSB0 aGV5IHdpbGwgYmUgZGVwbG95ZWQgaW4gc2VwYXJhdGUgZGV2aWNlcywgZXhjZXB0IGZvcgog ICB0aGUgQ0ROIGNhc2UsIHdoaWNoIG1heSBkZXBsb3kgYm90aCBpbiBhIHNpbmdsZSBkZXZp Y2UuCgogICBJbiBhbGwgY2FzZXMsIHRoZSBleGlzdGFuY2Ugb2YgYSBQLUVUUiBpbnZvbHZl cyBhbm90aGVyIHN0ZXAgaW4gdGhlCiAgIGNvbmZpZ3VyYXRpb24gb2YgYSBMSVNQIHJvdXRl ci4gIENQRSByb3V0ZXJzLCB3aGljaCBhcmUgdHlwaWNhbGx5CiAgIGNvbmZpZ3VyZWQgYnkg REhDUCwgc3RhbmQgdG8gYmVuZWZpdCBtb3N0IGZyb20gUC1FVFJzLiAgVG8gZW5hYmxlCiAg IGF1dG9jb25maWd1cmF0aW9uIG9mIHRoZSBQLUVUUiBsb2NhdG9yLCBhIERIQ1Agb3B0aW9u IHdvdWxkIGJlCiAgIHJlcXVpcmVkLgoKICAgQXMgYSBzZWN1cml0eSBtZWFzdXJlLCBhY2Nl c3MgdG8gUC1FVFJzIHNob3VsZCBiZSBsaW1pdGVkIHRvCiAgIGxlZ2l0aW1hdGUgdXNlcnMg YnkgZW5mb3JjaW5nIEFDTHMuCgo0LiAgTWFwLVJlc29sdmVycyBhbmQgTWFwLVNlcnZlcnMK CjQuMS4gIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+TWFwLVJlc29sdmVycwoKICAgQSBN YXAtUmVzb2x2ZXIgYSBpcyBhIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgY29tcG9uZW50IHdo aWNoIGFjY2VwdHMKICAgTElTUCBlbmNhcHN1bGF0ZWQgTWFwLVJlcXVlc3RzLCB0eXBpY2Fs bHkgZnJvbSBhbiBJVFIsIGFuZCBmaW5kcyB0aGUKICAgYXBwcm9wcmlhdGUgRUlELXRvLVJM T0MgbWFwcGluZyBieSBlaXRoZXIgY29uc3VsdGluZyBpdHMgY2FjaGUgb3IgYnkKICAgY29u c3VsdGluZyB0aGUgZGlzdHJpYnV0ZWQgbWFwcGluZyBkYXRhYmFzZS4gIFRoZSBNYXAtUmVz b2x2ZXIgaXMKICAgZGVmaW5lZCBpbiBbSS1ELmlldGYtbGlzcC1tc10uCgogICBNYXAtUmVz b2x2ZXJzIHdpbGwgYmUgdHlwaWNhbGx5IHByb3ZpZGVkIGJ5IElTUHMsIHdoaWNoIGFsc28g ZGVmaW5lCiAgIHRoZSBhY2Nlc3MgcG9saWN5IHRoZSBkZXZpY2UuICBJbiBtZWRpdW0gb3Ig bGFyZ2Utc2l6ZSBBU2VzIElUUnMgbXVzdAogICBiZSBjb25maWd1cmVkIHdpdGggdGhlIFJM T0Mgb2YgYSBNYXAtUmVzb2x2ZXIsIG9wZXJhdGlvbiB3aGljaCBjYW4gYmUKICAgZG9uZSBt YW51YWxseS4gIEhvd2V2ZXIsIGluIFNtYWxsIE9mZmljZSBIb21lIE9mZmljZSAoU09ITykg c2NlbmFyaW9zCiAgIGEgbWVjaGFuaXNtIGZvciBhdXRvY29uZmlndXJhdGlvbiBzaG91bGQg YmUgcHJvdmlkZWQuCgo0LjIuPC9mb250Pjwvc3RyaWtlPiAgTWFwLVNlcnZlcnMKCiAgIFRo ZSBNYXAtU2VydmVyIGxlYXJucyBFSUQtdG8tUkxPQyBtYXBwaW5nIGVudHJpZXMgZnJvbSBh bgogICBhdXRob3JpdGF0aXZlIHNvdXJjZSBhbmQgcHVibGlzaGVzIHRoZW0gaW4gdGhlIGRp c3RyaWJ1dGVkIG1hcHBpbmcKICAgZGF0YWJhc2UuICA8c3RyaWtlPjxmb250IGNvbG9yPSJy ZWQiPlRoZSBNYXAtU2VydmVyIGxlYXJucyB0aGVzZTwvZm9udD48L3N0cmlrZT4gIDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj5UaGVzZTwvZm9udD48L3N0cm9uZz4gZW50cmllcyA8 c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+YXJlIGxlYXJuZWQ8L2ZvbnQ+PC9zdHJvbmc+ IHRocm91Z2ggYXV0aGVudGljYXRlZAogICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPk1h cC1SZWdpc3RlcjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4i Pk1hcC0KICAgUmVnaXN0ZXI8L2ZvbnQ+PC9zdHJvbmc+IG1lc3NhZ2VzIHNlbnQgYnkgYXV0 aG9yaXRhdGl2ZSBFVFJzLiAgQWxzbywgdXBvbiByZWNlcHRpb24KICAgb2YgYSBNYXAtUmVx dWVzdCwgdGhlIE1hcC1TZXJ2ZXIgdmVyaWZpZXMgdGhhdCB0aGUgZGVzdGluYXRpb24gRUlE CiAgIG1hdGNoZXMgYW4gRUlELXByZWZpeCA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ Zm9yPC9mb250Pjwvc3Ryb25nPiB3aGljaCA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ aXQ8L2ZvbnQ+PC9zdHJvbmc+IGlzIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+YW5ub3Vu Y2luZzwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPnJlc3Bv bnNpYmxlIGZvcjwvZm9udD48L3N0cm9uZz4gYW5kIHRoZW4KICAgPHN0cmlrZT48Zm9udCBj b2xvcj0icmVkIj5yZS1lbmNhcHN1bGF0ZXM8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZv bnQgY29sb3I9ImdyZWVuIj5yZS0KICAgZW5jYXBzdWxhdGVzPC9mb250Pjwvc3Ryb25nPiBh bmQgZm9yd2FyZHMgaXQgdG8gYSBtYXRjaGluZyBFVFIuICA8c3RyaWtlPjxmb250IGNvbG9y PSJyZWQiPlRoZTwvZm9udD48L3N0cmlrZT4gIE1hcC1TZXJ2ZXIKICAgPHN0cm9uZz48Zm9u dCBjb2xvcj0iZ3JlZW4iPmZ1bmN0aW9uYWxpdHk8L2ZvbnQ+PC9zdHJvbmc+IGlzCiAgIDxz dHJpa2U+PGZvbnQgY29sb3I9InJlZCI+ZGVmaW5lZDwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRlc2NyaWJlZCBpbiBkZXRhaWw8L2ZvbnQ+PC9zdHJv bmc+IGluIFtJLUQuaWV0Zi1saXNwLW1zXS4KCiAgIFRoZSBNYXAtU2VydmVyIDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+Y2FuIGJlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPSJncmVlbiI+aXM8L2ZvbnQ+PC9zdHJvbmc+IHByb3ZpZGVkIGJ5IDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+dGhlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSJncmVlbiI+TWFwcGluZyBTZXJ2aWNlIFByb3ZpZGVycyAoTVNQcykuPC9mb250Pjwv c3Ryb25nPiAgRUlEIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+cmVnaXN0cmFyPC9mb250 Pjwvc3RyaWtlPgogICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+YXNzaWdubWVudCBh dXRob3JpdGllcyBjYW4gYmUgTVNQcyB0aGVtc2VsdmVzLDwvZm9udD48L3N0cm9uZz4gb3Ig PHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmRlbGVnYXRlIHRoaXMKICAgc2VydmljZSB0 bzwvZm9udD48L3N0cm9uZz4gdGhpcmQgcGFydGllcy4gIEZvciBpbnN0YW5jZSwgYSBMSVNQ IHNpdGUgKGkuZS4sIElTUCkKICAgcmVxdWVzdHMgYSBQcm92aWRlciBJbmRlcGVuZGVudCAo UEkpIHNldCBvZiBhZGRyZXNzZXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj50bzwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPmZyb208L2ZvbnQ+PC9z dHJvbmc+IGFuIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+RUlELXJlZ2lzdHJhcjwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iPkVJRAogICByZWdpc3Ry YXI8L2ZvbnQ+PC9zdHJvbmc+IChpLmUuLCBSSVBFKS4gIFRoaXMgcmVnaXN0cmFyIDxzdHJv bmc+PGZvbnQgY29sb3I9ImdyZWVuIj4oaWYgaXQgaXMgYW4gTVNQIGFzIHdlbGwpIG9yCiAg IGFuIGF1dGhvcml6ZWQgdGhpcmQgcGFydHkgTVNQPC9mb250Pjwvc3Ryb25nPiBjb25maWd1 cmVzIGl0cyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPm93biBNYXAtU2VydmVyPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+TWFwLVNlcnZlcihzKTwv Zm9udD48L3N0cm9uZz4gdG8gcHVibGlzaAogICB0aGlzIHByZWZpeCBpbiB0aGUgZGlzdHJp YnV0ZWQgbWFwcGluZyBkYXRhYmFzZSBhbmQgc3RhcnRzCiAgIGVuY2Fwc3VsYXRpbmcgYW5k IGZvcndhcmRpbmcgTWFwLVJlcXVlc3RzIHRvIHRoZSBFVFJzIG9mIHRoZSBBUy4KICAgVGhl c2UgRVRScyByZWdpc3RlciB0aGlzIHByZWZpeCBhdCB0aGUgPHN0cmlrZT48Zm9udCBjb2xv cj0icmVkIj5NYXAtU2VydmVyPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSJncmVlbiI+TWFwLVNlcnZlcihzKTwvZm9udD48L3N0cm9uZz4gdGhyb3VnaCBwZXJpb2Rp YwogICBhdXRoZW50aWNhdGVkIE1hcC1SZWdpc3RlciBtZXNzYWdlcy4gIEluIHRoaXMgY29u dGV4dCB0aGVyZSBpcyBhIG5lZWQKICAgZm9yIG1lY2hhbmlzbXMgdG86CgogICBvICBDb25m aWd1cmUgRUlEIHByZWZpeChlcykgc2hhcmVkIGtleXMgYmV0d2VlbiB0aGUgRVRScyBhbmQg dGhlIEVJRC0KICAgICAgcmVnaXN0cmFyIE1hcC1TZXJ2ZXIuCgogICBvICBDb25maWd1cmUg dGhlIGFkZHJlc3Mgb2YgdGhlIE1hcC1TZXJ2ZXIgaW4gdGhlIEVUUiBvZiB0aGUgQVMuCgog ICBUaGUgTWFwLVNlcnZlciBwbGF5cyBhIGtleSByb2xlIGluIHRoZSByZWFjaGFiaWxpdHkg b2YgdGhlIEVJRC0KICAgcHJlZml4ZXMgaXQgaXMgc2VydmluZy4gIE9uIHRoZSBvbmUgaGFu ZCBpdCBpcyBwdWJsaXNoaW5nIHRoZXNlCiAgIHByZWZpeGVzIGludG8gdGhlIGRpc3RyaWJ1 dGVkIG1hcHBpbmcgZGF0YWJhc2UgYW5kIG9uIHRoZSBvdGhlciBoYW5kCiAgIGl0IGlzIGVu Y2Fwc3VsYXRpbmcgYW5kIGZvcndhcmRpbmcgTWFwLVJlcXVlc3RzIHRvIHRoZSBFVFJzCiAg IGF1dGhvcml0YXRpdmUgZm9yIHRoZXNlIHByZWZpeGVzLiAgVXBvbiB0aGUgZmFpbHVyZSBv ZiBhIE1hcC1TZXJ2ZXIsCiAgIElUUnMgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBzZXQgb2Yg RUlELXByZWZpeGVzIHdpbGwgYmUgdW5hYmxlIHRvCiAgIHJlYWNoIGFueSBvZiB0aGUgYWZm ZWN0ZWQgRUlELXByZWZpeGVzLiAgVGhlIG9ubHkgZXhjZXB0aW9uIGFyZSB0aGUKICAgSVRS cyB0aGF0IGNvbnRhaW4gaW4gdGhlaXIgbWFwIGNhY2hlIHRoZSBFSUQtdG8tUkxPQyBtYXBw aW5ncy4gIEluCiAgIHRoaXMgY2FzZSBJVFJzIGNhbiByZWFjaCBFVFJzIHVudGlsIHRoZSBl bnRyeSBleHBpcmVzICh0eXBpY2FsbHkgMjQKICAgaG91cnMpLiAgRm9yIHRoaXMgcmVhc29u IHJlZHVuZGFudCBNYXAtU2VydmVyIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+c2VydmVy PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+ZGVwbG95bWVu dHM8L2ZvbnQ+PC9zdHJvbmc+IGFyZQogICBkZXNpcmFibGUgYW5kIHRoZSBMSVNQIHNwZWNp ZmljYXRpb24gc2hvdWxkIGRlc2NyaWJlIGFwcHJvcHJpYXRlCiAgIG1lY2hhbmlzbXMuCgo8 c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+NC4yLiAgTWFwLVJlc29sdmVycwoKICAgQSBN YXAtUmVzb2x2ZXIgYSBpcyBhIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgY29tcG9uZW50IHdo aWNoIGFjY2VwdHMKICAgTElTUCBlbmNhcHN1bGF0ZWQgTWFwLVJlcXVlc3RzLCB0eXBpY2Fs bHkgZnJvbSBhbiBJVFIsIGFuZCBmaW5kcyB0aGUKICAgYXBwcm9wcmlhdGUgRUlELXRvLVJM T0MgbWFwcGluZyBieSBlaXRoZXIgY29uc3VsdGluZyBpdHMgY2FjaGUgb3IgYnkKICAgY29u c3VsdGluZyB0aGUgZGlzdHJpYnV0ZWQgbWFwcGluZyBkYXRhYmFzZS4gIE1hcC1SZXNvbHZl cgogICBmdW5jdGlvbmFsaXR5IGlzIGRlc2NyaWJlZCBpbiBkZXRhaWwgW0ktRC5pZXRmLWxp c3AtbXNdLgoKICAgQW55b25lIHdpdGggYWNjZXNzIHRvIHRoZSBkaXN0cmlidXRlZCBtYXBw aW5nIGRhdGFiYXNlIGNhbiBwcm92aWRlCiAgIE1hcC1SZXNvbHZlciBzZXJ2aWNlLiAgSW4g dGhlIGNhc2Ugb2YgQUxULCBhIEJHUCBwZWVyaW5nIHNlc3Npb24gd2l0aAogICB0aGUgQUxU IG92ZXJsYXkgaXMgcmVxdWlyZWQuCgogICBUaGUgTVNQIHByb3ZpZGluZyB0aGUgTWFwLVNl cnZlcihzKSBmb3IgYSBMSVNQIHNpdGUgc2hvdWxkIGFsc28KICAgcHJvdmlkZSBhY2Nlc3Mg dG8gTWFwLVJlc29sdmVyKHMpIGZvciB0aGUgdXNlIG9mIHRoYXQgc2l0ZSwgdW5sZXNzCiAg IHRoZXkgcHJlZmVyIG90aGVyIGFsdGVybmF0aXZlcy4KCiAgIEhvd2V2ZXIsIE1hcC1SZXNv bHZlcnMgd2lsbCBiZSB0eXBpY2FsbHkgcHJvdmlkZWQgYnkgSVNQcyBiZWNhdXNlIG9mCiAg IHBlcmZvcm1hbmNlIHJlYXNvbnM6IHRoZXkgYXJlIHRvcG9sb2dpY2FsbHkgY2xvc2VyIHRv IHRoZSBMSVNQIHNpdGUuCiAgIFRoZSB1c2Ugb2YgdGhlaXIgcmVzb2x2ZXIgY2FuIGJlIHJl c3RyaWN0ZWQgdG8gdGhlaXIgY2xpZW50cywgb3IgdGhleQogICBjYW4gYWRvcHQgYW4gIm9w ZW4gdG8gYWxsIiBwb2xpY3kuCgogICBJbiBtZWRpdW0gdG8gbGFyZ2Utc2l6ZSBBU2VzIElU UnMgbXVzdCBiZSBjb25maWd1cmVkIHdpdGggdGhlIFJMT0Mgb2YKICAgYSBNYXAtUmVzb2x2 ZXIsIG9wZXJhdGlvbiB3aGljaCBjYW4gYmUgZG9uZSBtYW51YWxseS4gIEhvd2V2ZXIsIGlu CiAgIFNtYWxsIE9mZmljZSBIb21lIE9mZmljZSAoU09ITykgc2NlbmFyaW9zIGEgbWVjaGFu aXNtIGZvcgogICBhdXRvY29uZmlndXJhdGlvbiBzaG91bGQgYmUgcHJvdmlkZWQuPC9mb250 Pjwvc3Ryb25nPgoKNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBTZWN1cml0eSBp bXBsaWNhdGlvbnMgb2YgTElTUCBkZXBsb3ltZW50cyBhcmUgdG8gYmUgZGlzY3Vzc2VkIGlu IGEKICAgc2VwYXJhdGUgZG9jdW1lbnQuCgo2LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAg VGhpcyBtZW1vIGluY2x1ZGVzIG5vIHJlcXVlc3QgdG8gSUFOQS4KCjcuICBBY2tub3dsZWRn ZW1lbnRzCgogICBUaGlzIGRyYWZ0IGluY2x1ZGVzIG1hdGVyaWFsIGluc3BpcmVkIGJ5IHBy ZXZpb3VzIHdvcmsgZnJvbSBEYXJyZWwKICAgTGV3aXMgYW5kIE1hcmdhcmV0IFdhc3Nlcm1h biwgcHJlc2VudGVkIGF0IElFVEY3Ni4gIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5U aGUgYXV0aG9ycyB3b3VsZAogICBsaWtlIHRvIHRoYW5rPC9mb250Pjwvc3Ryb25nPiBEYW1p ZW4gPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5TYXVjZXogYW5kPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+U2F1Y2V6LDwvZm9udD48L3N0cm9uZz4g THVpZ2kgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5JYW5ub25lPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiI+SWFubm9uZSwgSm9lbCBIYWxwZXJuLCBW aW5jZQogICBGdWxsZXIsIERpbm8gRmFyaW5hY2NpLCBhbmQgZXZlcnlvbmUgZWxzZSB3aG88 L2ZvbnQ+PC9zdHJvbmc+IHByb3ZpZGVkIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+aGVs cGZ1bCBjb21tZW50cy48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Imdy ZWVuIj5pbnB1dC48L2ZvbnQ+PC9zdHJvbmc+Cgo4LiAgUmVmZXJlbmNlcwoKOC4xLiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJLUQuaWV0Zi1saXNwXQogICAgICAgICAgICAgIEZh cmluYWNjaSwgRC4sIEZ1bGxlciwgVi4sIE1leWVyLCBELiwgYW5kIEQuIExld2lzLAogICAg ICAgICAgICAgICJMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wgKExJU1ApIiwKICAg ICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiPmRyYWZ0LWlldGYtbGlzcC0w NzwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJn cmVlbiI+ZHJhZnQtaWV0Zi1saXNwLTA5PC9mb250Pjwvc3Ryb25nPiAod29yayBpbiBwcm9n cmVzcyksIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+QXByaWw8L2ZvbnQ+PC9zdHJpa2U+ IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5PY3RvYmVyPC9mb250Pjwvc3Ryb25nPiAy MDEwLgoKICAgW0ktRC5pZXRmLWxpc3AtaW50ZXJ3b3JraW5nXQogICAgICAgICAgICAgIExl d2lzLCBELiwgTWV5ZXIsIEQuLCBGYXJpbmFjY2ksIEQuLCBhbmQgVi4gRnVsbGVyLAogICAg ICAgICAgICAgICJJbnRlcndvcmtpbmcgTElTUCB3aXRoIElQdjQgYW5kIElQdjYiLAogICAg ICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCI+ZHJhZnQtaWV0Zi1saXNwLWlu dGVyd29ya2luZy0wMDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiI+ZHJhZnQtaWV0Zi1saXNwLWludGVyd29ya2luZy0wMTwvZm9u dD48L3N0cm9uZz4gKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIDxzdHJpa2U+ PGZvbnQgY29sb3I9InJlZCI+TWF5IDIwMDkuPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAg ICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5BdWd1c3QgMjAxMC48L2ZvbnQ+PC9z dHJvbmc+CgogICBbSS1ELmlldGYtbGlzcC1tc10KICAgICAgICAgICAgICBGdWxsZXIsIFYu IGFuZCBELiBGYXJpbmFjY2ksICJMSVNQIE1hcCBTZXJ2ZXIiLAogICAgICAgICAgICAgIDxz dHJpa2U+PGZvbnQgY29sb3I9InJlZCI+ZHJhZnQtaWV0Zi1saXNwLW1zLTA1PC9mb250Pjwv c3RyaWtlPgogICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIj5kcmFm dC1pZXRmLWxpc3AtbXMtMDY8L2ZvbnQ+PC9zdHJvbmc+ICh3b3JrIGluIHByb2dyZXNzKSwg PHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIj5BcHJpbDwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0iZ3JlZW4iPk9jdG9iZXI8L2ZvbnQ+PC9zdHJvbmc+IDIwMTAuCgo4 LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELmxlYXItbGlzcC1uZXJkXQog ICAgICAgICAgICAgIExlYXIsIEUuLCAiTkVSRDogQSBOb3Qtc28tbm92ZWwgRUlEIHRvIFJM T0MgRGF0YWJhc2UiLAogICAgICAgICAgICAgIGRyYWZ0LWxlYXItbGlzcC1uZXJkLTA4ICh3 b3JrIGluIHByb2dyZXNzKSwgTWFyY2ggMjAxMC4KCiAgIFtjYWNoZV0gICAgSnVuZywgSi4s IFNpdCwgRS4sIEJhbGFrcmlzaG5hbiwgSC4sIGFuZCBSLiBNb3JyaXMsICJETlMKICAgICAg ICAgICAgICBwZXJmb3JtYW5jZSBhbmQgdGhlIGVmZmVjdGl2ZW5lc3Mgb2YgY2FjaGluZyIs IDIwMDIuCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIExvcmFuZCBKYWthYgogICBUZWNobmlj YWwgVW5pdmVyc2l0eSBvZiBDYXRhbG9uaWEKICAgQy9Kb3JkaSBHaXJvbmEsIHMvbgogICBC QVJDRUxPTkEgIDA4MDM0CiAgIFNwYWluCgogICBFbWFpbDogbGpha2FiQGFjLnVwYy5lZHUK CiAgIEFsYmVydCBDYWJlbGxvcy1BcGFyaWNpbwogICBUZWNobmljYWwgVW5pdmVyc2l0eSBv ZiBDYXRhbG9uaWEKICAgQy9Kb3JkaSBHaXJvbmEsIHMvbgogICBCQVJDRUxPTkEgIDA4MDM0 CiAgIFNwYWluCgogICBFbWFpbDogYWNhYmVsbG9AYWMudXBjLmVkdQoKICAgRmxvcmluIENv cmFzCiAgIFRlY2huaWNhbCBVbml2ZXJzaXR5IG9mIENhdGFsb25pYQogICBDL0pvcmRpIEdp cm9uYSwgcy9uCiAgIEJBUkNFTE9OQSAgMDgwMzQKICAgU3BhaW4KCiAgIEVtYWlsOiBmY29y YXNAYWMudXBjLmVkdQogICBKb3JkaSBEb21pbmdvLVBhc2N1YWwKICAgVGVjaG5pY2FsIFVu aXZlcnNpdHkgb2YgQ2F0YWxvbmlhCiAgIEMvSm9yZGkgR2lyb25hLCBzL24KICAgQkFSQ0VM T05BICAwODAzNAogICBTcGFpbgoKICAgRW1haWw6IGpvcmRpLmRvbWluZ29AYWMudXBjLmVk dQoKICAgRGFycmVsIExld2lzCiAgIENpc2NvIFN5c3RlbXMKICAgMTcwIFRhc21hbiBEcml2 ZQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0CiAgIFVTQQoKICAgRW1haWw6IGRhcmxld2lzQGNp c2NvLmNvbQo8L3ByZT4KPC9ib2R5PjwvaHRtbD4= --------------040304070702090700050303--