From dino@cisco.com Fri May 1 23:43:41 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8D923A67DD for ; Fri, 1 May 2009 23:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 ZM78FHIyouHy for ; Fri, 1 May 2009 23:43:41 -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 E73B53A6774 for ; Fri, 1 May 2009 23:43:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,282,1238976000"; d="scan'208";a="161229200" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 02 May 2009 06:45:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n426j5Yi028196 for ; Fri, 1 May 2009 23:45:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n426j5ck019077 for ; Sat, 2 May 2009 06:45:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 23:45:05 -0700 Received: from [192.168.1.2] ([10.21.150.28]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 23:45:04 -0700 Message-Id: <92AA28FA-2CEF-4E30-8234-BBCE324810E2@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Fri, 1 May 2009 23:45:04 -0700 References: <20090502063805.89B033A68A8@core3.amsl.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 02 May 2009 06:45:04.0870 (UTC) FILETIME=[8677D860:01C9CAF1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=980; t=1241246705; x=1242110705; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Fwd=3A=20New=20Version=20Notification=20for=20d raft-farinacci-lisp-lig-00=20 |Sender:=20; bh=nDijCHKfilrgxNgc7IhQbw0v+AWIhwb6eCgeSSf90sU=; b=CGHKv5Ng32NcK0Ikyz5ICNGkK75yebPOcgatVRRb6vjd3odjvea0PbuECY J/EAr/hlyswOTuOdiZPl2G7H1ldhCqPxwfD9OWeyP0CbUMi3alSMYxf5sxqQ fabh9j/lwZ3AYQn4TL7Z8Pxm9E2caZ5p2tV9PzUOuRV9m0iWQYWcg=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [lisp] Fwd: New Version Notification for draft-farinacci-lisp-lig-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: Sat, 02 May 2009 06:43:41 -0000 Hi lispers, Dave and I just posted this ID. Please have a look and comment. Thanks. We have this deployed on the test network and have been using it for a couple of weeks. Thanks, Dino Begin forwarded message: > From: IETF I-D Submission Tool > Date: May 1, 2009 11:38:05 PM PDT > To: dino@cisco.com > Cc: dmm@cisco.com > Subject: New Version Notification for draft-farinacci-lisp-lig-00 > > > A new version of I-D, draft-farinacci-lisp-lig-00.txt has been > successfuly submitted by Dino Farinacci and posted to the IETF > repository. > > Filename: draft-farinacci-lisp-lig > Revision: 00 > Title: LISP Internet Groper (LIG) > Creation_date: 2009-05-01 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > A simple tool called the LISP Internet Groper or 'lig' can be used to > query the LISP mapping database. This draft describes how it works. > > > > The IETF Secretariat. > > From aihua9@gmail.com Sun May 10 20:18:19 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DA93A6A10 for ; Sun, 10 May 2009 20:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_84=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 mHM74UWTbUTz for ; Sun, 10 May 2009 20:18:19 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 2AA023A684E for ; Sun, 10 May 2009 20:18:19 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so2179538qwe.31 for ; Sun, 10 May 2009 20:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=u2VobwR8qsQv+av9/N9iELXkj0bEzHGQBlqpIP0MwBs=; b=vrdf6f7+n/KJbXCOQjoVjjrbOP7vFxgqsVIeWWFTfCta9JOIgyEKomfrsx/esYQyWM Ouyab53PydryyKutMglCETFj2keCdwL+DvnHi+N+soALnzPZBUjBzb/tmW/9ZxcDr6VA aBrEOyXoT1ySH8ULdLWyzcxZB4v0k+QPi7QdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wi9olmOfqibryd0RCGNLTXPS7xWbmfPxEbvMXyVn+gNP6EzXdJYyesFs0zPs8rWR3/ BzIofK6N7/QQ7wTduRUu74sibsd+4eht32gapqueSwifsKM07Mzr4f5ceLDGh+MyfxeR IWwJR8063y1tdv1TXGeEJHI5xGpXjZD9Uul1g= MIME-Version: 1.0 Received: by 10.220.74.4 with SMTP id s4mr10250297vcj.18.1242011987644; Sun, 10 May 2009 20:19:47 -0700 (PDT) Date: Mon, 11 May 2009 11:19:47 +0800 Message-ID: From: aihua zhang To: lisp@ietf.org Content-Type: multipart/alternative; boundary=0016362851fc54909804699a7340 Subject: [lisp] ALT problem X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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 May 2009 03:18:20 -0000 --0016362851fc54909804699a7340 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, When using ALT to route Map-Request Message in the internet,this message may be transfered between different ISP Network. here, comes the problem if intermediate network doesn't support ALT and if they do,at the different ISP network edge how they use ALT router connect to each other an= d get agreement? --=20 Best regards! Sincerely, aiHua Zhang State Key Lab. of Networking Technology Research Institute, BeiJing University of Posts and Telecommunications, 100876, P.R.China Email =A3=BAaihua9@bupt.edu.cn --0016362851fc54909804699a7340 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi,
 
   When using ALT to route Map-Request Message in the intern= et,this message may be transfered between different ISP Network. here,= comes the problem if intermediate network doesn't support AL= T and if they do,at the different ISP network edge how they use A= LT router connect to each other and get agreement?  

--
Best regards!

Sincerely,
aiHua Zhang
State Key Lab. of Networking Technology Research Institute, BeiJing Univer= sity of Posts and Telecommunications, 100876, P.R.China
Email =A3=BAaihua9@bupt.edu.cn<= br> --0016362851fc54909804699a7340-- From dino@cisco.com Sun May 10 20:52:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146A73A6BDD for ; Sun, 10 May 2009 20:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.943 X-Spam-Level: X-Spam-Status: No, score=-5.943 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_84=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 KbG2XWTfZkc1 for ; Sun, 10 May 2009 20:52:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3D5233A69E8 for ; Sun, 10 May 2009 20:52:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,326,1238976000"; d="scan'208";a="75348884" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 11 May 2009 03:53:58 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4B3rwGj012339; Sun, 10 May 2009 20:53:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4B3rwSi017071; Mon, 11 May 2009 03:53:58 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 May 2009 20:53:58 -0700 Received: from dhcp64-134-231-120.fpsm.nyc.wayport.net ([10.21.88.109]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 May 2009 20:53:58 -0700 Message-Id: <355A2F67-6936-4509-9827-65B6B87731BB@cisco.com> From: Dino Farinacci To: aihua zhang In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Sun, 10 May 2009 20:53:57 -0700 References: X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 11 May 2009 03:53:58.0638 (UTC) FILETIME=[1D08E8E0:01C9D1EC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1205; t=1242014038; x=1242878038; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20ALT=20problem |Sender:=20; bh=rQZUbyLw/F5/t2eZH3aQW7opK2bjkcV7ob29xprZ8Tk=; b=qmOadb4xZ5BtJgWFCleGHtAZbgsFzkItCllqMq/si4fBOCSp52hcjSEwgk J9FEPD4IwQOYT+Rb4ZksmzknbqaTEIIVrWcsDjyVTV6Urb7XV8mK5yOa7O09 8XVmR2TzM/; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] ALT problem X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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 May 2009 03:52:29 -0000 > When using ALT to route Map-Request Message in the internet,this > message may be transfered between different ISP Network. here, comes > the problem if intermediate network doesn't support ALT and if they > do,at the different ISP network edge how they use ALT router connect > to each other and get agreement? Let's say we have 5 ISPs, name them A-E. Let's say an ALT router is configured in ISP A and peers with an ALT router in ISP C which then peers with another ALT router in ISP E. What is connecting A to C and C to E are GRE tunnels. So all GRE traffic from ALT router A to ALT router C will be transited by ISP B and all GRE traffic from ALT router C to ALT router E will be transited by ISP D. Therefore, ISP B and D do not have to participate in ALT. Note, that the ALT topology is a logical topology and two ALT routers can be connected together as long as each side has a routable address. Also note, the BGP peering addresses are the address *on the tunnel interface* so they don't have to be routable because each end of the BGP peering connection believes the other side is directly connected (via the GRE tunnel interface). Dino From hartmans@mit.edu Wed May 20 08:58:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64AF03A6B40 for ; Wed, 20 May 2009 08:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9wiRW0En8FK for ; Wed, 20 May 2009 08:58:34 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 987363A694F for ; Wed, 20 May 2009 08:58:34 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 47CB8415C; Wed, 20 May 2009 12:00:07 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Wed, 20 May 2009 12:00:07 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Adopting WG drafts X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List 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 May 2009 15:58:35 -0000 Hi. I'll be sending out individual mail to editors, but I wanted to let the WG know that Darrel and I are ready to move the drafts named in our charter as WG drafts. Editors should rename their drafts to draft-ietf-lisp-draftname-00.txt and submit through the draft submission tool. If the tool asks you whether this version replaces an existing draft, it is important to say yes and to fill in the name of the existing drafts. The versions of the drafts listed in our charter are the starting points. It would be best if the 00 version you submit matched the version listed in the charter. If you have made changes since then, please explicitly call these changes out in mail to lisp@ietf.org. The version listed in the charter is the text the WG has adopted. That means we need a rough consensus of the working group to change that text. Changes made after adoption require a rough consensus. This distinction becomes important if we can't get agreement; in that case, we're left with the text in the version called out in the charter/adopted by the WG. From hartmans@mit.edu Tue May 26 06:41:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81CCD3A6B09 for ; Tue, 26 May 2009 06:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF9vikYyqXMz for ; Tue, 26 May 2009 06:41:20 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id A78EB3A6A2B for ; Tue, 26 May 2009 06:41:20 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B97F7415C; Tue, 26 May 2009 09:30:34 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Tue, 26 May 2009 09:30:34 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Chairs seeking nominations for WG secretary--respond by June 5 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 26 May 2009 13:41:27 -0000 The chairs are seeking nominations for the position of LISP WG secretary. Self nominations are encouraged. The WG secretary will: 1) Assist the chairs in running the mailing list. 2) Make sure that minutes of LISP meetings are produced in a timely manner, either by producing them or finding volunteers and coordinating the results. 3) Work with chairs and document authors to keep the LISP issue tracker up to date, describing issues and their resolutions. There is a large administrative component to this job. However, this job also is a great way to learn about LISP and Internet technology. The secretary will be able to practice and build this understanding through descriptions in the minutes and descriptions of issues and their resolutions. This job is an excellent way to become involved in the community and to be part of successfully building a new Internet technology. This is also a great way to learn about and become involved in the IETF process. The secretary will be listed on the WG web page. The secretary needs to plan to attend most LISP working group meetings, needs to be interested in active participation in the working group, and will need to become familiar with the LISP documents and discussions. Good communication and organizational skills are critical to success. From dino@cisco.com Tue May 26 08:46:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707583A69CE for ; Tue, 26 May 2009 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.083 X-Spam-Level: X-Spam-Status: No, score=-4.083 tagged_above=-999 required=5 tests=[AWL=-2.385, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, 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 ERV9OjEWgBoU for ; Tue, 26 May 2009 08:46:24 -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 6A1283A67EF for ; Tue, 26 May 2009 08:46:19 -0700 (PDT) X-Files: rfcdiff-12-to-00.html, rfcdiff-multicast-01-00.html : 124328, 63577 X-IronPort-AV: E=Sophos;i="4.41,252,1241395200"; d="html'217?scan'217,208,217";a="190280231" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 May 2009 15:48:00 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4QFm0YV017481 for ; Tue, 26 May 2009 08:48:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4QFm08E020618 for ; Tue, 26 May 2009 15:48:00 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 May 2009 08:48:00 -0700 Received: from [192.168.1.2] ([10.21.125.14]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 May 2009 08:47:59 -0700 Message-Id: <39638C38-8205-4E41-975B-6C871814ABDD@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-5-905190840 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 08:47:59 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 26 May 2009 15:47:59.0637 (UTC) FILETIME=[5874D450:01C9DE19] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=192720; t=1243352880; x=1244216880; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Internet-Draft=20working=20group=20submissions |Sender:=20; bh=wbbveiCiD9q4Ph+x+yn3s9dV2NGvNVAMWGea99ymXVk=; b=ZrMrOpdaPTSCusrTV1JFr7JbbibXAnzmi8vWOEPYt4bhELz6p6Zu37bdBn WzUTrSsw6um3ruoIxoKmh1QXhg13ERnObymwZjSpSKulFPrflvvxM4dtiVeA XL3ZNeMCeV; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [lisp] Internet-Draft working group submissions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 26 May 2009 15:46:35 -0000 --Apple-Mail-5-905190840 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I just did this: draft-farinacci-lisp-12.txt -> draft-ietf-lisp-00.txt draft-farinacci-lisp-multicast-01.txt -> draft-ietf-lisp- multicast-00.txt The diffs are attached. I am planning on updating each to -01 this week based on comments I have received as well as clarifying details learned from implementation experience. Thanks, Dino --Apple-Mail-5-905190840 Content-Disposition: attachment; filename=rfcdiff-12-to-00.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-12-to-00.html" Content-Transfer-Encoding: 7bit wdiff draft-farinacci-lisp-12.txt draft-ietf-lisp-00.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: September 3, November 27, 2009                                      D. Lewis
                                                           cisco Systems
                                                           March 2,
                                                            May 26, 2009

                 Locator/ID Separation Protocol (LISP)
                      draft-farinacci-lisp-12.txt
                         draft-ietf-lisp-00.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on September 3, November 27, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

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

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

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  Tunneling Details  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 18
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 20
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 21
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 21
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 23
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 23
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 25
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 25
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 27
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 28
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 30
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 31
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 33
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 34
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 37
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 37
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 38
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 39
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 41
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 42
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 43
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 43
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 44
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 45
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 46
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 46
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 46
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 48
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 48
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 48
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 48
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 50
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 51
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 52
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 53
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 55
     14.2. Informative References . . . . . . . . . . . . . . . . . . 56
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 59
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60

1.  Requirements Notation

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

2.  Introduction

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

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

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

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

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

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

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

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

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

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

   Some of the design goals of this proposal include:

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

   2.  Minimize required changes to Internet infrastructure.

   3.  Be incrementally deployable.

   4.  Require no router hardware changes.

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

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

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

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

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

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

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

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

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

3.  Definition of Terms

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Address Family Indicator (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI] for details.

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

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

4.  Basic Overview

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

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

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

   Some basic rules governing LISP are:

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

   o  EIDs are always IP addresses assigned to hosts.

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

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

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

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

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

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

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

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

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

4.1.  Packet Flow Sequence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.  Tunneling Details

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

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

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

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

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

5.1.  LISP IPv4-in-IPv4 Header Format

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

5.2.  LISP IPv6-in-IPv6 Header Format

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

5.3.  Tunnel Header Field Descriptions

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

   OH Header:  is the outer header prepended by an ITR.  The address
      fields contain RLOCs obtained from the ingress router's EID-to-
      RLOC cache.  The IP protocol number is "UDP (17)" from [RFC0768].

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

   UDP Checksum:  this field field MUST be transmitted as 0 and ignored
      on receipt by the ETR.  Note, even when the UDP checksum is
      transmitted as 0 an intervening NAT device can recalculate the
      checksum and rewrite the UDP checksum field to non-zero.  For
      performance reasons, the ETR MUST ignore the checksum and MUST not
      do a checksum computation.

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

   S: this is the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

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

   LISP Nonce:  is a 32-bit value that is randomly generated by an ITR.
      It is used to test route-returnability when xTRs exchange
      encapsulated data packets with the SMR bit set, Data-Probe, Map-
      Request, or Map-Reply messages.

   When doing Recursive Tunneling:

   o  The OH header Time to Live field (or Hop Limit field, in case of
      IPv6) MUST be copied from the IH header Time to Live field.

   o  The OH header Type of Service field (or the Traffic Class field,
      in the case of IPv6) SHOULD be copied from the IH header Type of
      Service field.

   When doing Re-encapsulated Tunneling:

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

   o  The new OH header Type of Service field SHOULD be copied from the
      stripped OH header Type of Service field.

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

5.4.  Dealing with Large Encapsulated Packets

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

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

5.4.1.  A Stateless Solution to MTU Handling

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

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

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

   3.  Calculate: S + H = L.

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

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

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

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

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

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

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

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

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

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

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

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

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

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

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

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

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

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

6.1.1.  LISP Packet Type Allocations

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

       Reserved:                        0    b'0000'
       LISP Map-Request:                1    b'0001'
       LISP Map-Reply:                  2    b'0010'
       LISP Map-Register:               3    b'0011'
       LISP-CONS Open Message:          8    b'1000'
       LISP-CONS Push-Add Message:      9    b'1001'
       LISP-CONS Push-Delete Message:   10   b'1010'
       LISP-CONS Unreachable Message    11   b'1011'

6.1.2.  Map-Request Message Format

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

   Packet field descriptions:

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

   Locator Reach Bits:  These bits MUST be set to 0 on transmission and
      ignored on receipt.  They cannot be used for indicating
      reachability because the Map-Request does not have the EID-prefix
      for the sending site so the receiver of the Map-Request cannot
      know what mapping entry to associate the reachability with.
      However, when Mapping Data is provided in the Map-Reply Record
      field, and the receiver of the Map-Request is configured to accept
      the mapping data, the R-bit per locator entry in the EID-prefix
      record is used to denote reachability.

   Nonce:  A 4-byte random value created by the sender of the Map-
      Request.

   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.  See other control-specific documents
      [CONS] for TCP-based Map-Requests.

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

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

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

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

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

   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.

   Originating ITR RLOC Address:  Used to give the ETR the option of
      returning a Map-Reply in the address-family of this locator.

   EID mask-len:  Mask length for EID prefix.

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

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

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

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

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

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the later 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  In
   all cases, the UDP source port number for the Map-Request message is
   a randomly allocated 16-bit value and the UDP destination port number
   is set to the well-known destination port number 4342.  A successful
   Map-Reply updates the cached set of RLOCs associated with the EID
   prefix range.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4341 when sent from an ITR to a Map-Resolver.  Details on
   encapsulated Map-Reqeusts and Map-Resolvers can be found in
   [LISP-MS].

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

6.1.4.  Map-Reply Message Format

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

   Packet field descriptions:

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

   Locator Reach Bits:  Refer to Section 5.3.  This field MUST be set to
      0 on transmission and ignored on receipt.  The locator
      reachability is encoded as the R-bit in each locator entry of each
      EID-prefix record.

   Nonce:  A 4-byte value set in a Data-Probe packet or a Map-Request
      that is echoed here in the Map-Reply.

   Type:   2 (Map-Reply)
   Reserved:  Set to 0 on transmission and ignored on receipt.

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

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

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

   EID mask-len:  Mask length for EID prefix.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set by the ETR.  See [CONS] for TCP-based Map-Replies.

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

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

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

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

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

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

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

   R: when this bit is set, the locator is known to be reachable from
      the Map-Reply sender's perspective.  When there is a single
      mapping record in the message, the R-bit for each locator must
      have a consistent setting with the bitfield setting of the 'Loc
      Reach Bits' field in the early part of the header.  When there are
      multiple mapping records in the message, the 'Loc Reach Bits'
      field is set to 0.

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

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

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

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

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

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

   The addresses for a encapsulated data packets or Map-Request message
   are swapped and used for sending the Map-Reply.  The UDP source and
   destination ports are swapped as well.  That is, the source port in
   the UDP header for the Map-Reply is set to the well-known UDP port
   number 4342.

6.1.6.  Map-Register Message Format

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

   The message is sent in a UDP with a destination UDP port 4342 and a
   randomly selected UDP port number.  Before an IPv4 or IPv6 network
   layer header is prepended, an AH header is prepended to carry
   authentication information.  The format conforms to the IPsec
   specification [RFC2402].  The Map-Regiter message will use transport
   mode by setting the IP protocol number field or the IPv6 next-header
   field to 51.

   The AH header from [RFC2402] is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Next Header   |  Payload Len  |          RESERVED             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Security Parameters Index (SPI)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Sequence Number Field                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                Authentication Data (variable)                 |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Next Header field is set to UDP.  The SPI field is set to 0
   (since no Security Association or Key Exchange protocol is being
   used).  The Sequece Number is a randomly chosen value by the sender.
   The Authentication Data is 16 bytes and holds a MD5 HMAC.

   The Map-Register message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |x|                     Locator Reach Bits                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3 |              Reserved                 | Record Count  |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  |A|        Reserved             |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved            |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |           Unused Flags      |R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The definition of each field of the Map-Register can be found in the
   Map-Reply section.

6.2.  Routing Locator Selection

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

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

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

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

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

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

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The Map-Reply and the database mapping service does not
   provide any reachability status for Locators.  This is done outside
   of the mapping service.  See next section for details.

6.3.  Routing Locator Reachability

   There are 4 methods for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator reachability is determined by an ETR by examining the
       Loc-Reach-Bits from a LISP header of a encapsulated data packet
       which is provided by an ITR when an ITR encapsulates data.

   2.  Locator unreachability is determined by an ITR by receiving ICMP
       Network or Host Unreachable messages.

   3.  Locator unreachability can also be determined by an BGP-enabled
       ITR when there is no prefix matching a Locator address from the
       BGP RIB.

   4.  Locator unreachability is determined when a host sends an ICMP
       Port Unreachable message.  This occurs when an ITR may not use
       any methods of interworking. one which is describe in [INTERWORK]
       and the encapsulated data packet is received by a host at the
       destination non-LISP site.

   5.  Locator reachability is determined by receiving a Map-Reply
       message from a ETR's Locator address in response to a previously
       sent Map-Request.

   6.  Locator reachability can also be determined by receiving packets
       encapsulated by the ITR assigned to the locator address.

   When determining Locator reachability by examining the Loc-Reach-Bits
   from the LISP encapsulate data packet, an ETR will receive up to date
   status from the ITR closest to the Locators at the source site.  The
   ITRs at the source site can determine reachability when running their
   IGP at the site.  When the ITRs are deployed on CE routers, typically
   a default route is injected into the site's IGP from each of the
   ITRs.  If an ITR goes down, the CE-PE link goes down, or the PE
   router goes down, the CE router withdraws the default route.  This
   allows the other ITRs at the site to determine one of the Locators
   has gone unreachable.

   The Locators listed in a Map-Reply are numbered with ordinals 0 to
   n-1.  The Loc-Reach-Bits in a LISP Data Message are numbered from 0
   to n-1 starting with the least significant bit numbered as 0.  So,
   for example, if the ITR with locator listed as the 3rd Locator
   position in the Map-Reply goes down, all other ITRs at the site will
   have the 3rd bit from the right cleared (the bit that corresponds to
   ordinal 2).

   When an ETR decapsulates a packet, it will look for a change in the
   Loc-Reach-Bits value.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator that has just gone
   unreachable.  It can start using the Locator again when the bit that
   corresponds to the Locator goes from 0 to 1.  Loc-Reach-Bits are
   associated with a locator-set per EID-prefix.  Therefore, when a
   locator becomes unreachable, the loc-reach-bit that corresponds to
   that locator's position in the list returned by the last Map-Reply
   will be set to zero for that particular EID-prefix.

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

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

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

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

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

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

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

   When an ETR is decapsulating packets, it can be sure that the path
   from the encapsulating ITR is available.  The ETR can assume the path
   from the ETR to the ITR is also reachable.  Even if there is
   asymmetric routing in the core, the first-hop and last-hop ASes will
   be the same for both directions of traffic since the locator
   addresses are out of the PA blocks of each.  However, the assumption
   may not always be valid, so this mechanism should be used as a best-
   effort indication that a working path exists between the sites.  In
   the event of unidirectional traffic from an ITR to an ETR, an ITR
   should not conclude that a locator is unreachable since it is not
   receiving packets, but use alternate mechanisms described above to
   determine reachability.

6.4.  Routing Locator Hashing

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

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

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

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

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

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

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

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

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

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

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

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

6.5.1.  Clock Sweep

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

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

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

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

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

6.5.2.  Solicit-Map-Request (SMR)

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

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

   An SMR message is simply a bit set in an encapsulated data packet
   (and a Map-Request message).  When an ETR at a remote site
   decapsulates a data packet that has the SMR bit set, it can tell that
   a new Map-Request message is being solicited.  Both the xTR that
   sends the SMR message and the site that acts on the SMR message MUST
   be rate-limited.

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

   1.  When the database mappings in an ETR change, the ITRs at the site
       begin to set the SMR bit in packets they encapsulate to the sites
       they communicate with.

   2.  A remote xTR which decapsulates a packet with the SMR bit set
       will schedule sending a Map-Request message to the source locator
       address of the encapsulated packet.  The nonce in the Map-Request
       is copied from the nonce in the encapsulated data packet that has
       the SMR bit set.

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

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

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

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

7.  Router Performance Considerations

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

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

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

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

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

8.  Deployment Scenarios

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

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

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

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

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

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

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

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

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

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

8.1.  First-hop/Last-hop Tunnel Routers

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

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

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

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

8.2.  Border/Edge Tunnel Routers

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

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

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

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

8.3.  ISP Provider-Edge (PE) Tunnel Routers

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

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

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

9.  Traceroute Considerations

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

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

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

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

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

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

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

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

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

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

9.1.  IPv6 Traceroute

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

9.2.  IPv4 Traceroute

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

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

9.3.  Traceroute using Mixed Locators

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

10.  Mobility Considerations

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

10.1.  Site Mobility

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

10.2.  Slow Endpoint Mobility

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

10.3.  Fast Endpoint Mobility

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.4.  Fast Network Mobility

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

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

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

11.  Multicast Considerations

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

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

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

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

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

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

12.  Security Considerations

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

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

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

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

13.  Prototype Plans and Status

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

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

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

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

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

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

   Here is a rough set of milestones:

   1.  This draft will be the draft for interoperable implementations to
       code against.  Interoperable implementations will be ready
       beginning of 2009.

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

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

   4.  Implement the LISP Multicast draft [MLISP].

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

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

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

   As of this writing the following accomplishments have been achieved:

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

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

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

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

   5.   Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and
        Andrew Partan continue to test all the features described above
        on a dual-stack infrastructure.

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

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

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

   9.   We have started deploying Map-Resolvers and Map-Servers on the
        pilot network to gather experience with [LISP-MS].

   10.  A cisco IOS implementation is underway which currently supports
        IPv4 encapsulation and decapsulation features.

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

14.  References

14.1.  Normative References

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

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

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

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

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

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

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

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

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

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

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

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

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

14.2.  Informative References

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   [SHIM6]    Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt (work in
              progress), October 2006.

Appendix A.  Acknowledgments

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

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

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
   Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
   Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
   Lezama, Attilla De Groot, and Parantap Lahiri.

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

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

Authors' Addresses

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

   Email: dino@cisco.com

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

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

   Email: dmm@cisco.com

   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com
--Apple-Mail-5-905190840 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-5-905190840 Content-Disposition: attachment; filename=rfcdiff-multicast-01-00.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-multicast-01-00.html" Content-Transfer-Encoding: 7bit wdiff draft-farinacci-lisp-multicast-01.txt draft-ietf-lisp-multicast-00.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                                 J. Zwiebel
Expires: May 30, November 27, 2009                                      cisco Systems                                     S. Venaas
                                                                 Uninett
                                                       November
                                                           cisco Systems
                                                            May 26, 2008 2009

                    LISP for Multicast Environments
                 draft-farinacci-lisp-multicast-01.txt
                    draft-ietf-lisp-multicast-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

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

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

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

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

   This Internet-Draft will expire on May 30, November 27, 2009.

Copyright Notice

   Copyright (C) The (c) 2009 IETF Trust (2008). and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

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

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Source Addresses versus Group Addresses  . . . . . . . . . . . 12
   6.  Locator Reachability Implications on LISP-Multicast  . . . . . 13
   7.  Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14
   8.  LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16
     8.1.  ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
     8.2.  ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
     8.3.  Replication Locations  . . . . . . . . . . . . . . . . . . 17
   9.  LISP-Multicast Interworking  . . . . . . . . . . . . . . . . . 18
     9.1.  LISP and non-LISP Mixed Sites  . . . . . . . . . . . . . . 18
       9.1.1.  LISP Source Site to non-LISP Receiver Sites  . . . . . 19
       9.1.2.  Non-LISP Source Site to non-LISP Receiver Sites  . . . 20
       9.1.3.  Non-LISP Source Site to Any Receiver Site  . . . . . . 21
       9.1.4.  Unicast LISP Source Site to Any Receiver  Sites  . . . 21
       9.1.5.  LISP Source Site to Any Receiver Sites . . . . . . . . 22
     9.2.  LISP Sites with Mixed Address Families . . . . . . . . . . 22
     9.3.  Making a Multicast Interworking Decision . . . . . . . . . 24
   10. Considerations when RP Addresses are Embedded in Group
       Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 26
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     14.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 32

1.  Requirements Notation

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

2.  Introduction

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

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

   This specification will address the following scenarios:

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

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

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

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

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

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

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

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

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

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

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

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

3.  Definition of Terms

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

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

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

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

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

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

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

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

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

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

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

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

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

   mPTR:   this is a multicast PTR that is responsible for advertising a
      very coarse EID prefix which non-LISP and uLISP sites can target
      their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP
      source multicast sites can send multicast packets using source
      addresses from the EID namespace. mPTRs act as Proxy ETRs for
      supporting multicast routing in a LISP infrastructure.

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

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

4.  Basic Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.  Source Addresses versus Group Addresses

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

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

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

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

6.  Locator Reachability Implications on LISP-Multicast

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

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

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

7.  Multicast Protocol Changes

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

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

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

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

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

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

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

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

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

8.  LISP-Multicast Data-Plane Architecture

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

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

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

8.1.  ITR Forwarding Procedure

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

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

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

8.2.  ETR Forwarding Procedure

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

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

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

8.3.  Replication Locations

   Multicast packet replication can happen in the following topological
   locations:

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

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

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

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

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

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

9.  LISP-Multicast Interworking

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

9.1.  LISP and non-LISP Mixed Sites

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

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

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

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

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

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

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

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

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

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

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

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

9.1.1.  LISP Source Site to non-LISP Receiver Sites

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

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

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

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

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

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

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

   The existence of mPTRs in the core allows LISP source multicast site
   ITRs to encapsulate multicast packets so the state built between the
   ITRs and the mPTRs is (S-RLOC,G) state.  Then the mPTRs can
   decapsulate packets and forward natively to the non-LISP and uLISP
   receiver multicast sites.

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

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

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

9.1.3.  Non-LISP Source Site to Any Receiver Site

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

9.1.4.  Unicast LISP Source Site to Any Receiver  Sites

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

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

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

9.1.5.  LISP Source Site to Any Receiver Sites

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

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

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

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

   So the solution space options are:

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

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

9.2.  LISP Sites with Mixed Address Families

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

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

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

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

   1.  LISP-Multicast IPv4 Site

   2.  LISP-Multicast IPv6 Site

   3.  LISP-Multicast Dual-Stack Site

   4.  uLISP IPv4 Site

   5.  uLISP IPv6 Site

   6.  uLISP Dual-Stack Site

   7.  non-LISP IPv4 Site

   8.  non-LISP IPv6 Site

   9.  non-LISP Dual-Stack Site

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

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

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

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

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

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

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

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

   o  All LISP sites on a multicast distribution tree must share a
      common address family which is determined by the source site's
      locator-set in its LISP database mapping entry.  All receiver
      multicast sites will use the best RLOC priority controlled by the
      source multicast site.  This is true when the source site is
      either LISP-Multicast or uLISP capable.  This means that priority-
      based policy modification is prohibited.

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

9.3.  Making a Multicast Interworking Decision

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

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

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

10.  Considerations when RP Addresses are Embedded in Group Addresses

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

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

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

11.  Taking Advantage of Upgrades in the Core

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

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

12.  Security Considerations

   Refer to the [LISP] specification.

13.  Acknowledgments

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

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

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

14.  References

14.1.  Normative References

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

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

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

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

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

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

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

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

14.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
              Topology (LISP-ALT)", draft-fuller-lisp-alt-02.txt (work
              in progress), April 2008.

   [INTWORK]  Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
              with IPv4 and IPv6", draft-lewis-lisp-interworking-00.txt
              (work in progress), December 2007.

   [JOIN-ATTR]
              Wijnands, IJ. and A. Boers, "Format for using TLVs in PIM
              messages", draft-ietf-pim-join-attributes-03.txt (work in
              progress), May 2007.

   [LISP]     Farinacci, D., Fuller, V., Oran, Meyer, D., and D. Meyer, Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-10.txt
              draft-ietf-lisp-00.txt (work in progress), May 2009.

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

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

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

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dino@cisco.com

   Dave Meyer
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   John Zwiebel
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: jzwiebel@cisco.com

   Stig Venaas
   Uninett
   Abels gate 5, 4th Floor
   N-7465, Trondheim
   Norway
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: Stig.Venaas@uninett.no

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA). stig@cisco.com
--Apple-Mail-5-905190840 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-5-905190840-- From darlewis@cisco.com Tue May 26 11:08:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F4628C1D2 for ; Tue, 26 May 2009 11:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.174 X-Spam-Level: X-Spam-Status: No, score=-5.174 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 yDn8P8fPSHWo for ; Tue, 26 May 2009 11:08:19 -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 CA94E28C163 for ; Tue, 26 May 2009 11:08:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,253,1241395200"; d="scan'208";a="164635135" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 26 May 2009 18:09:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4QI9vCD012162 for ; Tue, 26 May 2009 11:09:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4QI9vUi004615 for ; Tue, 26 May 2009 18:09:57 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 May 2009 11:09:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 May 2009 11:09:56 -0700 Message-ID: In-Reply-To: <39638C38-8205-4E41-975B-6C871814ABDD@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Internet-Draft working group submissions Thread-Index: AcneGWy4XHVFyXErSTShEPVekIOdEgAE0K4w References: <39638C38-8205-4E41-975B-6C871814ABDD@cisco.com> From: "Darrel Lewis (darlewis)" To: "Dino Farinacci (dino)" , X-OriginalArrivalTime: 26 May 2009 18:09:57.0044 (UTC) FILETIME=[2D39FF40:01C9DE2D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=742; t=1243361397; x=1244225397; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20Internet-Draft=20working=20gro up=20submissions |Sender:=20; bh=K0E0uoSfcCrOZiiRYBxAN7IGaNXrkMDOtRzyqiyoTmY=; b=kYnBlWdyuWcXv5boWL3haIt9pLzphwTDJfXInuwjfZOWzQEUTZ7KiB9uST Xl8XWDmo9208INzHfkq0VXEo7GLgmoyTH2ts5QeSkN8NJHZ8WYBoqRWbpszj 3CWXjeD349; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [lisp] Internet-Draft working group submissions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 26 May 2009 18:08:20 -0000 >=20 > I just did this: >=20 > draft-farinacci-lisp-12.txt -> draft-ietf-lisp-00.txt > draft-farinacci-lisp-multicast-01.txt -> draft-ietf-lisp-=20 > multicast-00.txt >=20 > The diffs are attached. I am planning on updating each to -01=20 > this week based on comments I have received as well as=20 > clarifying details learned from implementation experience. >=20 > Thanks, > Dino >=20 >=20 Thanks Dino, Could I ask that all the other authors submiting WG documents also send a brief description of the outstanding work they expect to be adding to the draft to the list? It need not be overly detailed but it will help the chairs guage the completeness of the documents. Thank you, -Darrel From darlewis@cisco.com Tue May 26 11:20:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E5628C275 for ; Tue, 26 May 2009 11:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.421, 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 N4CW702IaTBZ for ; Tue, 26 May 2009 11:20:11 -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 2D1CF3A6BB2 for ; Tue, 26 May 2009 11:20:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,253,1241395200"; d="scan'208";a="77801054" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 26 May 2009 18:21:53 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4QILrkX029340; Tue, 26 May 2009 11:21:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4QILrTe019111; Tue, 26 May 2009 18:21:53 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 May 2009 11:21:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 May 2009 11:21:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-lisp-interworking-00 Thread-Index: AcneLbF6i5Y9zLtvQyaoQv/EGY8uPgAABjHw From: "Darrel Lewis (darlewis)" To: X-OriginalArrivalTime: 26 May 2009 18:21:53.0102 (UTC) FILETIME=[D807C6E0:01C9DE2E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2141; t=1243362113; x=1244226113; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-ietf-lisp-interworking-00=20 |Sender:=20; bh=zVXr3P1mMfDZQNN6Ws7m2RgDJyjHiwlTa4MvCZpWlvc=; b=Sn8pXBAT/1KAeYAUpA4lmJtK1aErUpvNMyHU+kiOK8nrO1OuPbvy98qpuS AJ9euTuWUncgt+a9BLjFRC5gJEmRxwikqwPKXMdUo80QvkCLCFLanNVr/p2c avOqfm+Xsl; Authentication-Results: sj-dkim-2; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [lisp] FW: New Version Notification for draft-ietf-lisp-interworking-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 18:20:17 -0000 Submitted this new WG item today. It is based on the draft-lewis-lisp-interworking-02.txt Future work expected to be reflected later versions this draft include: -Clarifying edits based on comments received -LISP Interworking in the Broadband NAT environments -Evaluate PTR scaling (caching, hw implementation) implications -Add Reference to lisp-multicast Interworking (the above list was described at the SF WG/BOF meeting) -Darrel -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Tuesday, May 26, 2009 11:12 AM To: Darrel Lewis (darlewis) Cc: David Meyer (dmm); Dino Farinacci (dino); Vince Fuller (vaf) Subject: New Version Notification for draft-ietf-lisp-interworking-00=20 A new version of I-D, draft-ietf-lisp-interworking-00.txt has been successfuly submitted by Darrel Lewis and posted to the IETF repository. Filename: draft-ietf-lisp-interworking Revision: 00 Title: Interworking LISP with IPv4 and IPv6 Creation_date: 2009-05-26 WG ID: lisp Number_of_pages: 15 Abstract: This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP [LISP]) to interoperate with Internet sites not running LISP. A fundamental property of LISP- speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IP addresses, routes for them are not carried in the global routing system so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces two such mechanisms: the first uses a new network element, the LISP Proxy Tunnel Router (PTR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts while the second adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. =20 The IETF Secretariat. From root@core3.amsl.com Tue May 26 09:15:01 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6725F28C290; Tue, 26 May 2009 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090526161501.6725F28C290@core3.amsl.com> Date: Tue, 26 May 2009 09:15:01 -0700 (PDT) X-Mailman-Approved-At: Tue, 26 May 2009 11:34:51 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-multicast-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 16:15:08 -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-00.txt Pages : 31 Date : 2009-05-26 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-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-multicast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-26090455.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue May 26 09:45:01 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D2F8C3A6AC1; Tue, 26 May 2009 09: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: <20090526164501.D2F8C3A6AC1@core3.amsl.com> Date: Tue, 26 May 2009 09:45:01 -0700 (PDT) X-Mailman-Approved-At: Tue, 26 May 2009 11:34:51 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-00.txt Pages : 60 Date : 2009-05-26 This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-26094144.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue May 26 11:15:01 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9882C3A6E6C; Tue, 26 May 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090526181501.9882C3A6E6C@core3.amsl.com> Date: Tue, 26 May 2009 11:15:01 -0700 (PDT) X-Mailman-Approved-At: Tue, 26 May 2009 11:34:51 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-interworking-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 18:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : Interworking LISP with IPv4 and IPv6 Author(s) : D. Lewis, et al. Filename : draft-ietf-lisp-interworking-00.txt Pages : 15 Date : 2009-05-26 This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP [LISP]) to interoperate with Internet sites not running LISP. A fundamental property of LISP- speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IP addresses, routes for them are not carried in the global routing system so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces two such mechanisms: the first uses a new network element, the LISP Proxy Tunnel Router (PTR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts while the second adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-interworking-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-26111150.I-D@ietf.org> --NextPart-- From dino@cisco.com Tue May 26 11:50:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566913A7129 for ; Tue, 26 May 2009 11:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 vUYqPSVqwm1a for ; Tue, 26 May 2009 11:50:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 24DF53A6D05 for ; Tue, 26 May 2009 11:50:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,253,1241395200"; d="scan'208";a="310966754" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 May 2009 18:51:48 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4QIpmZG006540 for ; Tue, 26 May 2009 11:51:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4QIpmZr023670 for ; Tue, 26 May 2009 18:51:48 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 May 2009 11:51:47 -0700 Received: from [192.168.1.2] ([10.21.125.14]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 May 2009 11:51:47 -0700 Message-Id: From: Dino Farinacci To: Darrel Lewis (darlewis) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 11:51:47 -0700 References: <39638C38-8205-4E41-975B-6C871814ABDD@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 26 May 2009 18:51:47.0379 (UTC) FILETIME=[0580B830:01C9DE33] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1060; t=1243363908; x=1244227908; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Internet-Draft=20working=20gro up=20submissions |Sender:=20; bh=LGgJuf5rVblDubhn1MTSb4zQHf2YYUkmkrfJAfq7jWk=; b=LqxTvfYPjk3uE5cuA/3/7qb/Jx/2Ee95yXroCJQl4XVZMeWjtmZdbCJZcj 3OqETwOlBa8+RoqBR+vxJIPLOWCWjiwLkQQzbfIyUuNyazZ94FqzeCzTfp3r 3RCMVL1iBB; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Internet-Draft working group submissions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 26 May 2009 18:50:37 -0000 > It need not be overly detailed but it will help the chairs guage the > completeness of the documents. Here are mine for both the main spec and multicast spec. They are terse, but will have more detail by end of week. Dino ------------------------------------------------------------------------------- o Talk about /24 and /25 overlapping EID-prefixes in main LISP spec. o PIM unicast joins encapsulate in LISP header with port 4341. o Change EID to LEID. o Have a look at Templin's spec on MTU. o Fix "Map-Request" typo "Reserved". o Fix this: Map-Requests can also be LISP encapsulated using UDP destination port 4341 when sent from an ITR to a Map-Resolver. Details on encapsulated Map-Reqeusts and Map-Resolvers can be found in [LISP-MS]. Add Map-Server to ETR direction too. o Spec out map-requesting a map-cache entry before removing it because of timeout. o Add a "proxy-reply" bit in the Map-Register. o Spec out action bits. o Resolve multicast comments from Yiqun. ------------------------------------------------------------------------------- From root@core3.amsl.com Tue May 26 14:45:01 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8D88E28C262; Tue, 26 May 2009 14: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: <20090526214501.8D88E28C262@core3.amsl.com> Date: Tue, 26 May 2009 14:45:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-ms-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Author(s) : D. Farinacci, V. Fuller Filename : draft-ietf-lisp-ms-00.txt Pages : 13 Date : 2009-05-26 This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-ms-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-26143535.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue May 26 14:45:01 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8590228C25E; Tue, 26 May 2009 14: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: <20090526214501.8590228C25E@core3.amsl.com> Date: Tue, 26 May 2009 14:45:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-alt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Alternative Topology (LISP+ALT) Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-alt-00.txt Pages : 26 Date : 2009-05-26 This document describes a method of building an alternative, logical topology for managing Endpoint Identifier to Routing Locator mappings using the Locator/ID Separation Protocol. The logical network is built as an overlay on the public Internet using existing technologies and tools, specifically the Border Gateway Protocol and the Generic Routing Encapsulation. An important design goal for LISP+ALT is to allow for the relatively easy deployment of an efficient mapping system while minimizing changes to existing hardware and software. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-alt-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-alt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-26143430.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue May 26 15:15:01 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 555263A69D7; Tue, 26 May 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090526221501.555263A69D7@core3.amsl.com> Date: Tue, 26 May 2009 15:15:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-alt-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, 26 May 2009 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Alternative Topology (LISP+ALT) Author(s) : V. Fuller, et al. Filename : draft-ietf-lisp-alt-01.txt Pages : 26 Date : 2009-05-26 This document describes a method of building an alternative, logical topology for managing Endpoint Identifier to Routing Locator mappings using the Locator/ID Separation Protocol. The logical network is built as an overlay on the public Internet using existing technologies and tools, specifically the Border Gateway Protocol and the Generic Routing Encapsulation. An important design goal for LISP+ALT is to allow for the relatively easy deployment of an efficient mapping system while minimizing changes to existing hardware and software. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-alt-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-alt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-26150046.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue May 26 15:15:01 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5D2133A6834; Tue, 26 May 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090526221501.5D2133A6834@core3.amsl.com> Date: Tue, 26 May 2009 15:15:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-ms-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, 26 May 2009 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Author(s) : V. Fuller, D. Farinacci Filename : draft-ietf-lisp-ms-01.txt Pages : 13 Date : 2009-05-26 This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-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-ms-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-26150121.I-D@ietf.org> --NextPart-- From jnc@mercury.lcs.mit.edu Tue May 26 15:19:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61B828C254 for ; Tue, 26 May 2009 15:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 W88XlQAPmqKK for ; Tue, 26 May 2009 15:19:25 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id EBEA83A6D63 for ; Tue, 26 May 2009 15:19:24 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 57F7F6BE624; Tue, 26 May 2009 18:20:57 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090526222057.57F7F6BE624@mercury.lcs.mit.edu> Date: Tue, 26 May 2009 18:20:57 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] I-D Action:draft-ietf-lisp-alt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 22:19:25 -0000 > From: Internet-Drafts@ietf.org > "This document describes a method of building an alternative, logical > topology for managing Endpoint Identifier to Routing Locator mappings > using the Locator/ID Separation Protocol." This strikes me as a non-optimal description of what LISP-ALT is. What it is is a _mapping subsystem_ - but that's not all all obvious from this first sentence. (The rest of the abstract is fine.) How about something like: "This document describes a subsystem for providing Endpoint Identifier to Routing Locator mappings for the Locator/ID Separation Protocol. It does this by building an alternative, logical topology which is used for both announcing the availability of EID to RLOC mappings, and forwarding requests for those mappings to an entity which is authoritative for them." Only slightly longer, but much more informative, I think. Noel From HeinerHummel@aol.com Wed May 27 01:56:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972013A6CF5 for ; Wed, 27 May 2009 01:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_20=-0.74, 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 A8snvJnH20az for ; Wed, 27 May 2009 01:56:24 -0700 (PDT) Received: from imr-d04.mx.aol.com (imr-d04.mx.aol.com [205.188.157.42]) by core3.amsl.com (Postfix) with ESMTP id A494B3A6D09 for ; Wed, 27 May 2009 01:56:12 -0700 (PDT) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-d04.mx.aol.com (v107.10) with ESMTP id RELAYIN1-24a1d007f382; Wed, 27 May 2009 04:57:35 -0400 Received: from HeinerHummel@aol.com by imo-ma03.mx.aol.com (mail_out_v40_r1.5.) id 9.d49.481308b3 (39331); Wed, 27 May 2009 04:57:33 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Wed, 27 May 2009 04:57:33 EDT To: jnc@mercury.lcs.mit.edu, lisp@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1243414653" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 64.12.78.138 Subject: Re: [lisp] I-D Action:draft-ietf-lisp-alt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 08:56:25 -0000 -------------------------------1243414653 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable A minor comment wrt alternative logical topology: Newcomers won't understand, why "alternative" is part of the name.While I= prefer to keep the name ALT, it wouldn't be bad to give some explanation/excusion at the beginning. Heiner In einer eMail vom 27.05.2009 00:21:13 Westeurop=E4ische Normalzeit schrei= bt jnc@mercury.lcs.mit.edu: > From: Internet-Drafts@ietf.org > "This document describes a method of building an alternative, logical > topology for managing Endpoint Identifier to Routing Locator mappings > using the Locator/ID Separation Protocol." This strikes me as a non-optimal description of what LISP-ALT is. What it= is is a _mapping subsystem_ - but that's not all all obvious from this first sentence. (The rest of the abstract is fine.) How about something like: "This document describes a subsystem for providing Endpoint Identifier to Routing Locator mappings for the Locator/ID Separation Protocol. It does this by building an alternative, logical topology which is used for both announcing the availability of EID to RLOC mappings, and forwarding requests for those mappings to an entity which is authoritativ= e for them." Only slightly longer, but much more informative, I think. Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp -------------------------------1243414653 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
A minor comment wrt alternative logical topology:
 
Newcomers won't understand, why "alternative" is part of the name.Whi= le I prefer to keep the name ALT, it wouldn't be bad to give some explanation/excusion at the beginning.
 
Heiner
 
 
In einer eMail vom 27.05.2009 00:21:13 Westeurop=E4ische Normalzeit= schreibt jnc@mercury.lcs.mit.edu:
  > From: Internet-Drafts@ietf.org

    > "This docu= ment describes a method of building an alternative, logical
   = > topology for managing Endpoint Identifier to Routing Locator mappings
    > using the Locator/ID Separation Protocol."

This strikes me as a non-optimal description of what= LISP-ALT is. What it is
is a _mapping subsystem_ - but that's not all= all obvious from this first
sentence. (The rest of the abstract is fine.)

How about something like:

  "This document des= cribes a subsystem for providing Endpoint Identifier
  to Routing Locat= or mappings for the Locator/ID Separation Protocol.
  It does this= by building an alternative, logical topology which is used
  for bo= th announcing the availability of EID to RLOC mappings, and
  forwa= rding requests for those mappings to an entity which is authoritative
 = ; for them."

Only slightly longer, but much more informative, I think.

    Noel
_______________________________________________
lisp mailing= list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
<= /FONT>
 
 -------------------------------1243414653-- From olivier.bonaventure@uclouvain.be Wed May 27 05:57:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F36F3A687B for ; Wed, 27 May 2009 05:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 vxIifcMDhGC3 for ; Wed, 27 May 2009 05:57:08 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 04A923A685F for ; Wed, 27 May 2009 05:57:07 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B56B4E8B84 for ; Wed, 27 May 2009 14:57:30 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be B56B4E8B84 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1243429050; bh=yp5gYLgLl/BNg2iW2X4QslzoXh9a9CXC607JhEZE2sw=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=o2i2mpNuhBMDoBR9ZMhLjBoJoc6yzDXrII5FQTNUk/eGqySytsfsSltI9hMms4gtu YTvlzyVLa0dwQz1btA1ty4gZfuUthpzZ/U7OGVc29l3pvX6c2KvA5MINY2ZZuyryXj AQ3iWwThnmZf5xAa0lqVoilLziPHHhqtnvS73R5c= Message-ID: <4A1D38B7.3020705@uclouvain.be> Date: Wed, 27 May 2009 14:57:27 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: lisp@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: B56B4E8B84.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 12:57:09 -0000 Hello, The LISP header is defined in draft-ietf-lisp-00.txt as follows +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L / |S| Locator Reach Bits | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S \ | Nonce | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This LISP header is used for both encapsulated data packets and also or Map-Request and Map-Reply messages. An ETR can used the UDP destination port to determine whether the received packet is a data encapsulated packet (UDP destination port set to 4341) or a control packet (UDP destination port set to 4342). However, not all fields of the LISP header are useful for both data and control packets. For example, the S bit and the loc-reach bits are not used for Map-Request packets, while there is no utilisation of the Nonce for data encapsulated packets in draft-ietf-lisp-00, except for data probes. We thus have an 8 bytes overhead in all data encapsulated packets while currently 32 bits of this header is not used by most data encapsulated packets. It might be useful to consider a different structure for the LISP header used in data encapsulated packets and the LISP header used in control packets or define some utilisation of the Nonce field in all data encapsulated LISP packets. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From Fred.L.Templin@boeing.com Wed May 27 06:23:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835993A6CED for ; Wed, 27 May 2009 06:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.442, 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 mH9KyIBxiI4c for ; Wed, 27 May 2009 06:23:30 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 86E5A3A68DE for ; Wed, 27 May 2009 06:23:30 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RDN8RW018859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 06:23:08 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RDN7qq012892; Wed, 27 May 2009 06:23:07 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RDN38s012762; Wed, 27 May 2009 06:23:07 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 06:23:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 06:23:04 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4A1D38B7.3020705@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: AcneyuSRPHOJA4PrQZWjZs+NVh5V1gAAtibw References: <4A1D38B7.3020705@uclouvain.be> From: "Templin, Fred L" To: , X-OriginalArrivalTime: 27 May 2009 13:23:07.0106 (UTC) FILETIME=[45B79C20:01C9DECE] Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:23:31 -0000 Oliver, > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Sent: Wednesday, May 27, 2009 5:57 AM > To: lisp@ietf.org > Subject: [lisp] Comments about the LISP header >=20 > Hello, >=20 > The LISP header is defined in draft-ietf-lisp-00.txt as follows >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > L / |S| Locator Reach Bits | > I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > S \ | Nonce | > P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > This LISP header is used for both encapsulated data packets and also or > Map-Request and Map-Reply messages. An ETR can used the UDP destination > port to determine whether the received packet is a data encapsulated > packet (UDP destination port set to 4341) or a control packet (UDP > destination port set to 4342). >=20 > However, not all fields of the LISP header are useful for both data and > control packets. For example, the S bit and the loc-reach bits are not > used for Map-Request packets, while there is no utilisation of the Nonce > for data encapsulated packets in draft-ietf-lisp-00, except for data > probes. >=20 > We thus have an 8 bytes overhead in all data encapsulated packets while > currently 32 bits of this header is not used by most data encapsulated > packets. >=20 > It might be useful to consider a different structure for the LISP header > used in data encapsulated packets and the LISP header used in control > packets or define some utilisation of the Nonce field in all data > encapsulated LISP packets. Good idea. For example, LISP could instead use the SEAL header for data packets. That would eliminate the UDP header as well. As you observe, the control packets could remain as UDP/LISP if desired, and need not be formatted the same as for data packets. Fred fred.l.templin@boeing.com =20 >=20 > Olivier >=20 >=20 > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From olivier.bonaventure@uclouvain.be Wed May 27 06:24:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CF53A6D15 for ; Wed, 27 May 2009 06:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz08z+62W14Q for ; Wed, 27 May 2009 06:24:02 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id A4AFF3A6D01 for ; Wed, 27 May 2009 06:24:02 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 702F51C57E9 for ; Wed, 27 May 2009 14:57:24 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp3.sgsi.ucl.ac.be 702F51C57E9 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1243429044; bh=/EUoI07YjaFEYpuJxbUQcZOZlkF4xl1rFkrdcukHAzg=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=oIOe8eotBaR9vEAfiQwTiGjXwXixfOKsixOxiQYV7VuAFIETum2pFK7kQdl7eOoB8 CyNhh64gD22w3fZN1zxgCzSkcMAWP0DUAAlzzEY0tvcFiJCveA1Cy6Nh2+Ibfqr2G2 KPjGKjr3mYQja0RPZou0qksaHSdhnZ3QA5Qywj40= Message-ID: <4A1D38B3.2020902@uclouvain.be> Date: Wed, 27 May 2009 14:57:23 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: lisp@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 702F51C57E9.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [lisp] On the two usages of Map-Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:24:03 -0000 Hello, In the LISP architecture, the mapping system is used for two related but different purposes : Discovery usage : This is the first usage of the Map-Request messages. When an ITR needs to send a packet towards an EID for which it does not knw any mapping, it will send a mapping request through the mapping system and will receive a Map-Reply message that provides the mapping that it can insert in its mapping cache. Update usage : This is the second usage of Map-Request messages. Even if the ITR already knows a mapping for a given EID, it may need to send Map-Request messages to one or several of the ETRs that are responsible for this EID. Typical examples include updating the mapping upon expiration of the mapping lifetime, verification of the reachability of a remote ETR, reaction to reception of a packet containing the SMR bit set, ... I think that in the discussion about the mapping systems that it would be useful to distinguish between these two roles of the LISP Map-Request messages because there two usages can be potentially different. For example, Map-Request used for update will likely be more frequent than Map-Requests used for Discovery, Map-Requests used for update may include additional information compared to the Map-Request that are used for discovery, Map-Requests used for update could have a shorter retransmission timer than Map-Request used for discovery, ... Another example is the rate limit imposed on Map-Request. The current draft recommends : "Map-Requests MUST be rate-limited. It is recommended that a Map-Request for the same EID-prefix be sent no more than once per second." This is an important requirement for Map-Requests that are used for discovery. However, Map-Requests that are used for update could have a different rate-limit. For example, when sending Map-Requests to update the mapping of an EID prefix reachable via two RLOCs, then it could be acceptable to send a Map-Request to both RLOCs at the same time. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From jnc@mercury.lcs.mit.edu Wed May 27 06:26:32 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8853A687B for ; Wed, 27 May 2009 06:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 GJ2ouK7KMk7C for ; Wed, 27 May 2009 06:26:31 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 610A13A67AA for ; Wed, 27 May 2009 06:26:31 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 54FEE6BE590; Wed, 27 May 2009 09:26:17 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> Date: Wed, 27 May 2009 09:26:17 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:26:32 -0000 > From: Olivier Bonaventure > not all fields of the LISP header are useful for both data and control > packets. ... there is no utilisation of the Nonce for data encapsulated > packets .. except for data probes. > ... > It might be useful to consider a different structure for the LISP > header used in data encapsulated packets and .. in control packets or > define some utilisation of the Nonce field in all data encapsulated > LISP packets. There has been some offline discussion about using the nonce field to piggyback RLOC reachability testing on user data traffic, because detecting reachability failures is a definite concern. I.e. just because an ETR E is up, and is exchanging traffic with other nodes, there may be something in the network - perhaps a misconfigured access control setting somewhere - that prevents traffic directly from from ITR I to ETR E from getting to ETR E. This sort of thing would cause mysterious packet black-holing, if there is a specific mechanism to detect it - but explicit pinging (such as routers use to detect that their neighbours are up) is felt to be too much overhead, as the xTR fanout is likely to be much larger. Piggybacking reachability detection on user data traffic is not a perfect solution, but it seems that it might be a useful tool, when combined with a number of other techniques. Noel From Fred.L.Templin@boeing.com Wed May 27 06:33:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2283A687B for ; Wed, 27 May 2009 06:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 fVhCeqHJoGPp for ; Wed, 27 May 2009 06:33:39 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 70B593A685F for ; Wed, 27 May 2009 06:33:39 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RDYHqH015496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 08:34:19 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RDYH01003269; Wed, 27 May 2009 08:34:17 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RDXump002642; Wed, 27 May 2009 08:34:16 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 06:34:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 06:34:14 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC0DD8@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acnezv7/nS8EwxsLTTivLe7IORggHQAAEYXg References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 27 May 2009 13:34:15.0932 (UTC) FILETIME=[D45E5BC0:01C9DECF] Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:33:40 -0000 Noel, > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Wednesday, May 27, 2009 6:26 AM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] Comments about the LISP header >=20 >=20 > > From: Olivier Bonaventure >=20 > > not all fields of the LISP header are useful for both data and control > > packets. ... there is no utilisation of the Nonce for data encapsulated > > packets .. except for data probes. > > ... > > It might be useful to consider a different structure for the LISP > > header used in data encapsulated packets and .. in control packets or > > define some utilisation of the Nonce field in all data encapsulated > > LISP packets. >=20 > There has been some offline discussion about using the nonce field to > piggyback RLOC reachability testing on user data traffic, because detecting > reachability failures is a definite concern. >=20 > I.e. just because an ETR E is up, and is exchanging traffic with other nodes, > there may be something in the network - perhaps a misconfigured access > control setting somewhere - that prevents traffic directly from from ITR I to > ETR E from getting to ETR E. This sort of thing would cause mysterious packet > black-holing, if there is a specific mechanism to detect it - but explicit > pinging (such as routers use to detect that their neighbours are up) is felt > to be too much overhead, as the xTR fanout is likely to be much larger. Maybe I am misunderstanding, but how can ITR I know that the path to ETR E is down without testing it? It doesn't seem feasible that some 3rd party observer could know anything about I->E path characteristics, for example. You also cite explicit pinging overhead, but if the ping is piggybacked on top of ordinary data packets the overhead is perhaps not so much. Fred fred.l.templin@boeing.com =20 > Piggybacking reachability detection on user data traffic is not a perfect > solution, but it seems that it might be a useful tool, when combined with a > number of other techniques. >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Wed May 27 06:43:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18AA3A7027 for ; Wed, 27 May 2009 06:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 vhit+m+SpQ97 for ; Wed, 27 May 2009 06:43: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 155103A6F8E for ; Wed, 27 May 2009 06:43:53 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 27C476BE590; Wed, 27 May 2009 09:44:40 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090527134440.27C476BE590@mercury.lcs.mit.edu> Date: Wed, 27 May 2009 09:44:40 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:43:53 -0000 > From: "Templin, Fred L" > how can ITR I know that the path to ETR E is down without testing it? Without sending _some_ packets across it, it can't, as far as I can see. > if the ping is piggybacked on top of ordinary data packets the overhead > is perhaps not so much. Exactly; that's why there's been some thinking recently about piggybacking reachability detection on user data traffic. Noel From scott.brim@gmail.com Wed May 27 08:08:21 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425203A6E13 for ; Wed, 27 May 2009 08:08:21 -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=[AWL=0.300, 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 dY4KLNttTxQY for ; Wed, 27 May 2009 08:08:14 -0700 (PDT) Received: from mail-qy0-f180.google.com (mail-qy0-f180.google.com [209.85.221.180]) by core3.amsl.com (Postfix) with ESMTP id E99D43A6DA2 for ; Wed, 27 May 2009 08:08:13 -0700 (PDT) Received: by qyk10 with SMTP id 10so1026715qyk.29 for ; Wed, 27 May 2009 08:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IdBMNanA9neZja0t73klSqV2HK8awaqjGshXRYst0QA=; b=Lh4PNlLE+LnIpw6HNCsiJxdSmFPpznu1SC9Yi5ke4awWOUU0KzujTACBBbXJODQ6Zo oPiWh/S0jPAyqSQMWf1IzVIR+EhUPpcHRqneSJpUSeA53gXi2NespUiWQ5zuJ1hMmJm/ IGRfnFHKP3wLiUowKr+QdM6h/+XswAe7IXNBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NTxIrOwY6e6LsaMJIjY+WDRkCBFHnQqZDnv3kZWe/knDTsYRSD+Bgbo2vRh71pMTmc 1ZpMNInSUNp0wo12a4i8l9hkNC1+XA9fQPvgSwA7sM/xQ0WYUvqX1lRY6CXZ3bDC9SsW TayOWDa82bjqwnMTlkQGNneifBdjdbBMayS4w= Received: by 10.229.82.10 with SMTP id z10mr97849qck.83.1243436959342; Wed, 27 May 2009 08:09:19 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 8sm194443ywg.23.2009.05.27.08.09.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 May 2009 08:09:17 -0700 (PDT) Message-ID: <4A1D579C.1000900@gmail.com> Date: Wed, 27 May 2009 11:09:16 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Noel Chiappa References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> In-Reply-To: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 15:08:21 -0000 Noel Chiappa allegedly wrote on 05 27 2009 9:26 AM: > There has been some offline discussion about using the nonce field to > piggyback RLOC reachability testing on user data traffic, because detecting > reachability failures is a definite concern. What if traffic leaves site A via xTR 1 and enters site B via xTR 2 ... but the return traffic leaves B via xTR 3 and enters A via xTR 4? Then the xTR that sends the reachability request will never see the returned ACK. From jnc@mercury.lcs.mit.edu Wed May 27 08:14:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B063A6ED1 for ; Wed, 27 May 2009 08:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJH72IWiTzFZ for ; Wed, 27 May 2009 08:14:57 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 28AE73A6B30 for ; Wed, 27 May 2009 08:14:57 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8EC026BE590; Wed, 27 May 2009 11:15:40 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090527151540.8EC026BE590@mercury.lcs.mit.edu> Date: Wed, 27 May 2009 11:15:40 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 15:14:58 -0000 > From: Scott Brim > What if traffic leaves site A via xTR 1 and enters site B via xTR 2 ... > but the return traffic leaves B via xTR 3 and enters A via xTR 4? Then > the xTR that sends the reachability request will never see the returned > ACK. Hence my prior comment: >> Piggybacking reachability detection on user data traffic is not a >> perfect solution, but it seems that it might be a useful tool, when >> combined with a number of other techniques. Before we start fine-tuning the mechanism-set, though, I think we need to get some practical experience - see how often that scenario happens IRL, etc. Noel From jmh@joelhalpern.com Wed May 27 08:21:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDDA63A68C0 for ; Wed, 27 May 2009 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9h3emyWeSiZP for ; Wed, 27 May 2009 08:21:42 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id 42F723A67FD for ; Wed, 27 May 2009 08:21:42 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id 7FA9FA39FC for ; Wed, 27 May 2009 08:22:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7072F4303D3 for ; Wed, 27 May 2009 08:21:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id F2D5B4303CF for ; Wed, 27 May 2009 08:21:50 -0700 (PDT) Message-ID: <4A1D5A8D.90306@joelhalpern.com> Date: Wed, 27 May 2009 11:21:49 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: <20090527151540.8EC026BE590@mercury.lcs.mit.edu> In-Reply-To: <20090527151540.8EC026BE590@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 15:21:43 -0000 Conversely, this seems to introduce two design problems simultaneously. 1) including a feature we don't know the use for. 2) Having a header with significant difficulty in changing it, when we are still experimenting with what needs to be in the header. Joel Noel Chiappa wrote: > > From: Scott Brim > > > What if traffic leaves site A via xTR 1 and enters site B via xTR 2 ... > > but the return traffic leaves B via xTR 3 and enters A via xTR 4? Then > > the xTR that sends the reachability request will never see the returned > > ACK. > > Hence my prior comment: > > >> Piggybacking reachability detection on user data traffic is not a > >> perfect solution, but it seems that it might be a useful tool, when > >> combined with a number of other techniques. > > Before we start fine-tuning the mechanism-set, though, I think we need to > get some practical experience - see how often that scenario happens IRL, > etc. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From olivier.bonaventure@uclouvain.be Wed May 27 08:59:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393F53A7090 for ; Wed, 27 May 2009 08:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 A4GMVsB87bS1 for ; Wed, 27 May 2009 08:59:49 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 36E7C3A705B for ; Wed, 27 May 2009 08:59:49 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id A84EBE8C22; Wed, 27 May 2009 17:59:44 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be A84EBE8C22 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1243439984; bh=uIqvl/sohjwM26GrXFb0iwMgTrp1SigvHt7zG1uP5aw=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=h0RVpH5B4Vw06jw66juLA6Ny5670d4OlpRToD5Z8axN9NpyJyAP+4cUEVDZ4Mdcch dSO11FJ0vODsMxbU5uUSmfThryhB974r7oyhxXFIOZ2pQHI2el/JunhuVUQbhTJzUu B3u2VQ9MdGTyPuo7e7cr/7vGNVROEed7I6XR6d2U= Message-ID: <4A1D636D.6080005@uclouvain.be> Date: Wed, 27 May 2009 17:59:41 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Templin, Fred L" References: <4A1D38B7.3020705@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: A84EBE8C22.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 15:59:50 -0000 Fred, >> >> We thus have an 8 bytes overhead in all data encapsulated packets > while >> currently 32 bits of this header is not used by most data encapsulated >> packets. >> >> It might be useful to consider a different structure for the LISP > header >> used in data encapsulated packets and the LISP header used in control >> packets or define some utilisation of the Nonce field in all data >> encapsulated LISP packets. > > Good idea. For example, LISP could instead use the SEAL > header for data packets. I'm not convinced that all the mechanisms placed in SEAL are necessary for LISP. > That would eliminate the UDP header as well. The main benefit of the UDP header is that LISP encapsulated packets appear as "normal" packets on today's Internet, including middleboxes. There are too many devices today that drop packets because they do not carry tcp, udp or other well known protocols. This is annoying, but we have to live with this :-( > As you observe, the control packets > could remain as UDP/LISP if desired, and need not be > formatted the same as for data packets. Control packets could have a different format than data encapsulated packets indeed. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From dmm@1-4-5.net Wed May 27 09:00:19 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6D728C142 for ; Wed, 27 May 2009 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 3UgepOcksqEu for ; Wed, 27 May 2009 09:00:18 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 1B91C28C134 for ; Wed, 27 May 2009 09:00:18 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n4RFqqds009417; Wed, 27 May 2009 08:52:52 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n4RFqq7j009416; Wed, 27 May 2009 08:52:52 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 27 May 2009 08:52:52 -0700 From: David Meyer To: Scott Brim Message-ID: <20090527155252.GA9369@1-4-5.net> References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> <4A1D579C.1000900@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <4A1D579C.1000900@gmail.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:00:19 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2009 at 11:09:16AM -0400, Scott Brim wrote: > Noel Chiappa allegedly wrote on 05 27 2009 9:26 AM: > > There has been some offline discussion about using the nonce field to > > piggyback RLOC reachability testing on user data traffic, because detec= ting > > reachability failures is a definite concern. >=20 > What if traffic leaves site A via xTR 1 and enters site B via xTR 2 ... > but the return traffic leaves B via xTR 3 and enters A via xTR 4? Then > the xTR that sends the reachability request will never see the returned A= CK. There are various ways to solve the "square routing" problem (such as observing the ratio of outgoing SYNs to ACKs).=20 Dave --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkodYdQACgkQORgD1qCZ2KfHmQCfRunKjf5ILaN11gUI1G2hIOY6 NXEAmwdH13CtRVEPEcuyueOpmv5Byq// =QITu -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From olivier.bonaventure@uclouvain.be Wed May 27 09:11:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2773A6882 for ; Wed, 27 May 2009 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 nCAdDIs1-L1S for ; Wed, 27 May 2009 09:11:16 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 905633A6ECF for ; Wed, 27 May 2009 09:10:53 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 521CBF210A; Wed, 27 May 2009 18:12:41 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be 521CBF210A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1243440761; bh=6OBAYuQwapWmUueEZZidtN9HnlV/otlIouVlTqZyjwk=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=rEoF3vZ2tQKRx3zkWRekWyIutUHRoeMrjMdnpo1Uu0gp0nQLirdpxx5B/IS4KUukZ 7X9CPBtW4VkB9DtXKxem303Z3KeNF3WFUdrN6CK7Wjx2XreVPnWM95A1qwv8yctq1a nMCxyNRZAVrS9rkeMNCzueF9HRRot7wiHFLJ0UNo= Message-ID: <4A1D666F.3050603@uclouvain.be> Date: Wed, 27 May 2009 18:12:31 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Noel Chiappa References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> In-Reply-To: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 521CBF210A.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:11:18 -0000 Noel, > > From: Olivier Bonaventure > > > not all fields of the LISP header are useful for both data and control > > packets. ... there is no utilisation of the Nonce for data encapsulated > > packets .. except for data probes. > > ... > > It might be useful to consider a different structure for the LISP > > header used in data encapsulated packets and .. in control packets or > > define some utilisation of the Nonce field in all data encapsulated > > LISP packets. > > There has been some offline discussion about using the nonce field to > piggyback RLOC reachability testing on user data traffic, because detecting > reachability failures is a definite concern. > > I.e. just because an ETR E is up, and is exchanging traffic with other nodes, > there may be something in the network - perhaps a misconfigured access > control setting somewhere - that prevents traffic directly from from ITR I to > ETR E from getting to ETR E. This sort of thing would cause mysterious packet > black-holing, if there is a specific mechanism to detect it - but explicit > pinging (such as routers use to detect that their neighbours are up) is felt > to be too much overhead, as the xTR fanout is likely to be much larger. > > Piggybacking reachability detection on user data traffic is not a perfect > solution, but it seems that it might be a useful tool, when combined with a > number of other techniques. I think that another question that we will need to answer also is whether reachability is sufficient. For example, consider a site one ITR that is sending packets towards and EID served by two ETRs : ETR1 and ETR2. Both ETR1 and ETR2 are reachable from ITR, but the path between ITR and ETR1 is heavily congested or uses a low quality wireless link, leading to 30% packet losses while the path towards ETR2 is not congested at all. Will ITR use both paths since they are reachable or should it try to detect the packet losses and avoid the lossy path ? Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From Fred.L.Templin@boeing.com Wed May 27 09:15:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF333A70E4 for ; Wed, 27 May 2009 09:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429, 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 jLW2g59bZf8a for ; Wed, 27 May 2009 09:15:39 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 6FFFD3A6F45 for ; Wed, 27 May 2009 09:15:39 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RFGpq2018211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 08:16:52 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RFGpWa007129; Wed, 27 May 2009 10:16:51 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RFGhhS006830; Wed, 27 May 2009 10:16:51 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 08:16:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 08:16:49 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC0E8E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4A1D579C.1000900@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne3ThLs6ElgtVnT32ZUyTcT8QBTQAACWEA References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> <4A1D579C.1000900@gmail.com> From: "Templin, Fred L" To: "Scott Brim" , "Noel Chiappa" X-OriginalArrivalTime: 27 May 2009 15:16:50.0315 (UTC) FILETIME=[28AAADB0:01C9DEDE] Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:15:40 -0000 > -----Original Message----- > From: Scott Brim [mailto:scott.brim@gmail.com] > Sent: Wednesday, May 27, 2009 8:09 AM > To: Noel Chiappa > Cc: lisp@ietf.org > Subject: Re: [lisp] Comments about the LISP header >=20 > Noel Chiappa allegedly wrote on 05 27 2009 9:26 AM: > > There has been some offline discussion about using the nonce field to > > piggyback RLOC reachability testing on user data traffic, because detecting > > reachability failures is a definite concern. >=20 > What if traffic leaves site A via xTR 1 and enters site B via xTR 2 ... > but the return traffic leaves B via xTR 3 and enters A via xTR 4? Then > the xTR that sends the reachability request will never see the returned ACK. Huh? xTR2 simply sends an ACK back to xTR1 within locator space (not eid space). The test is unidirectional, but the network is connected so xTR2 can reach xTR1 along the reverse path within locator space. Fred fred.l.templin@boeing.com > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Wed May 27 09:16:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473DD3A698B for ; Wed, 27 May 2009 09:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 bPoGAg1Ep2Hj for ; Wed, 27 May 2009 09:16:46 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id AA7E23A6F75 for ; Wed, 27 May 2009 09:16:16 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 635AE6BE590; Wed, 27 May 2009 12:17:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090527161758.635AE6BE590@mercury.lcs.mit.edu> Date: Wed, 27 May 2009 12:17:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:16:47 -0000 > From: "Joel M. Halpern" > Conversely, this seems to introduce two design problems simultaneously. > 1) including a feature we don't know the use for. Well, actually, from an architectural point of view, I quite like it. The _protocol_ mechanism is very simple and cheap. The algorithms to use it inside the nodes can change over time, and in a trivially interoperable way. It reminds me perfectly of TCP retransmission, where we were able to first experiment with, and then incrementally deploy VJCC, with zero hassle - because it had exactly these properties. Ensuring mutual reachabilty is a Big Deal in routing protocols. The problem is going to factorially worse for us, because our communicating boxes are not going to be on the same physical network, but on either side of the internetwork. And if you come at the problem from the fundaments, having some simple, cheap and flexible mechanism that piggybacks on existing traffic seems like a really good tool to have in your toolkit... Noel From Fred.L.Templin@boeing.com Wed May 27 09:26:46 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D361A28C1B5 for ; Wed, 27 May 2009 09:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 yD+t4JgwYnBR for ; Wed, 27 May 2009 09:26:45 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id B7A3528C201 for ; Wed, 27 May 2009 09:26:13 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RGRToZ005511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 09:27:29 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RGRTxf020024; Wed, 27 May 2009 09:27:29 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RGRSWa020013; Wed, 27 May 2009 09:27:28 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 09:27:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 09:27:27 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4A1D636D.6080005@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5FnDNJ7446c8R9SCupesshndJgAAgXLA References: <4A1D38B7.3020705@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> <4A1D636D.6080005@uclouvain.be> From: "Templin, Fred L" To: X-OriginalArrivalTime: 27 May 2009 16:27:28.0975 (UTC) FILETIME=[071ADDF0:01C9DEE8] Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:26:46 -0000 Oliver, > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Sent: Wednesday, May 27, 2009 9:00 AM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] Comments about the LISP header >=20 > Fred, > >> > >> We thus have an 8 bytes overhead in all data encapsulated packets > > while > >> currently 32 bits of this header is not used by most data encapsulated > >> packets. > >> > >> It might be useful to consider a different structure for the LISP > > header > >> used in data encapsulated packets and the LISP header used in control > >> packets or define some utilisation of the Nonce field in all data > >> encapsulated LISP packets. > > > > Good idea. For example, LISP could instead use the SEAL > > header for data packets. >=20 > I'm not convinced that all the mechanisms placed in SEAL are necessary > for LISP. SEAL has 8 "control" bits, of which at least the "Acknowledgment Requested" and "Report Fragmentation" bits are required. Four other control bits (the M bit and the 3-bit SEG field) are used for segmentation and reassembly, but it may well be that LISP will not want to use these under many circumstances which is absolutely fine and consistent with the SEAL architecture. Finally, the 'Y' bit is used by the ETR to tell the ITR whether/not it is willing to reassemble. That leaves only one bit as unused among the 8 control bits. =20 > > That would eliminate the UDP header as well. >=20 > The main benefit of the UDP header is that LISP encapsulated packets > appear as "normal" packets on today's Internet, including middleboxes. > There are too many devices today that drop packets because they do not > carry tcp, udp or other well known protocols. This is annoying, but we > have to live with this :-( I have some doubts that this is actually a problem. For example, ip-proto-41 seems to work fine for 6to4 and others. ip-proto-4 also for RFC2003 and its kin. GRE also seems to get through. There will also be no NAT traversal in the interdomain core. So, I don't see it as unrealistic that a new IP protocol would get through most paths and could be easily enabled to get through the other paths. > > As you observe, the control packets > > could remain as UDP/LISP if desired, and need not be > > formatted the same as for data packets. >=20 > Control packets could have a different format than data encapsulated > packets indeed. Correct. Fred fred.l.templin@boeing.com >=20 > Olivier >=20 >=20 > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium From Fred.L.Templin@boeing.com Wed May 27 09:41:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3683A688C for ; Wed, 27 May 2009 09:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 eYgNtB2-T628 for ; Wed, 27 May 2009 09:41:24 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id E86AC3A6E92 for ; Wed, 27 May 2009 09:41:19 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RGfmiJ019993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 May 2009 09:41:53 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RGfmpL007958; Wed, 27 May 2009 11:41:48 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RGfib0007748; Wed, 27 May 2009 11:41:47 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 09:41:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 09:41:45 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC0F68@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4A1D666F.3050603@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5gT2I9/vY4tiQ42edVtEezrK1gAA57zQ References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu> <4A1D666F.3050603@uclouvain.be> From: "Templin, Fred L" To: , "Noel Chiappa" X-OriginalArrivalTime: 27 May 2009 16:41:46.0273 (UTC) FILETIME=[06182910:01C9DEEA] Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:41:26 -0000 Oliver, > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Sent: Wednesday, May 27, 2009 9:13 AM > To: Noel Chiappa > Cc: lisp@ietf.org > Subject: Re: [lisp] Comments about the LISP header >=20 > Noel, > > > From: Olivier Bonaventure > > > > > not all fields of the LISP header are useful for both data and control > > > packets. ... there is no utilisation of the Nonce for data encapsulated > > > packets .. except for data probes. > > > ... > > > It might be useful to consider a different structure for the LISP > > > header used in data encapsulated packets and .. in control packets or > > > define some utilisation of the Nonce field in all data encapsulated > > > LISP packets. > > > > There has been some offline discussion about using the nonce field to > > piggyback RLOC reachability testing on user data traffic, because detecting > > reachability failures is a definite concern. > > > > I.e. just because an ETR E is up, and is exchanging traffic with other nodes, > > there may be something in the network - perhaps a misconfigured access > > control setting somewhere - that prevents traffic directly from from ITR I to > > ETR E from getting to ETR E. This sort of thing would cause mysterious packet > > black-holing, if there is a specific mechanism to detect it - but explicit > > pinging (such as routers use to detect that their neighbours are up) is felt > > to be too much overhead, as the xTR fanout is likely to be much larger. > > > > Piggybacking reachability detection on user data traffic is not a perfect > > solution, but it seems that it might be a useful tool, when combined with a > > number of other techniques. >=20 > I think that another question that we will need to answer also is > whether reachability is sufficient. >=20 > For example, consider a site one ITR that is sending packets towards and > EID served by two ETRs : ETR1 and ETR2. Both ETR1 and ETR2 are reachable > from ITR, but the path between ITR and ETR1 is heavily congested or uses > a low quality wireless link, leading to 30% packet losses while the path > towards ETR2 is not congested at all. Will ITR use both paths since they > are reachable or should it try to detect the packet losses and avoid the > lossy path ? OK, so here's a good use for the SEAL sequence number. If the ETR tracks the SEAL sequence numbers it sees from a particular ITR it can report back the %packet loss when the ITR asks for an acknowledgement. Would something like that help? Fred fred.l.templin@boeing.com >=20 > Olivier >=20 >=20 > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From darlewis@cisco.com Wed May 27 10:15:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502E73A694C for ; Wed, 27 May 2009 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, 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 eUfE2b5JT+mm for ; Wed, 27 May 2009 10:14:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7E0163A6C65 for ; Wed, 27 May 2009 10:14:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,260,1241395200"; d="scan'208";a="311651320" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 May 2009 17:16:42 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4RHGgw3028471; Wed, 27 May 2009 10:16:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4RHGgwe025064; Wed, 27 May 2009 17:16:42 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 10:16:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 10:16:40 -0700 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5FnDNJ7446c8R9SCupesshndJgAAgXLAAAHNr0A= References: <4A1D38B7.3020705@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com><4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> From: "Darrel Lewis (darlewis)" To: "Templin, Fred L" , X-OriginalArrivalTime: 27 May 2009 17:16:42.0199 (UTC) FILETIME=[E75D1670:01C9DEEE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1793; t=1243444602; x=1244308602; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20Comments=20about=20the=20LISP= 20header |Sender:=20; bh=FZZf0m3bPjoeSNF81FkZfvBU+mdOUHQlzz19MhID0ZM=; b=L1Q3jSKc3B3777RbqVMk3a0EKvfhsujZgi2XDjYw7w2PCiZYiP+Sz4hehB S9HUrC8rSi1yymX+uPHA3FtzOGnMcx3La2WBu24pTmMPCLuLsKQhBnmE/R/f XYBTjyopZi; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:15:00 -0000 =20 > --> > The main benefit of the UDP header is that LISP=20 > encapsulated packets=20 > > appear as "normal" packets on today's Internet, including=20 > middleboxes. > > There are too many devices today that drop packets because=20 > they do not=20 > > carry tcp, udp or other well known protocols. This is=20 > annoying, but we=20 > > have to live with this :-( >=20 > I have some doubts that this is actually a problem. For=20 > example, ip-proto-41 seems to work fine for 6to4 and others. > ip-proto-4 also for RFC2003 and its kin. GRE also seems to=20 > get through. There will also be no NAT traversal in the=20 > interdomain core. So, I don't see it as unrealistic that a=20 > new IP protocol would get through most paths and could be=20 > easily enabled to get through the other paths. >=20 Fred, Just three short short points about why LISP utilizes a UDP header. First I'll note that my netgear router at home refuses to NAT on anything besides TCP and UDP. Early implementations of LISP that required the ALT to extend to the xTR would not work through this device. Second, many enterprise firewalls are configured to deny IP protocols that aren't explicitly allowed, so piggy backing on a known protocol has some benefits. Finally, Link Aggregation schemes for core routers use 5 tuple hashes which include s-port and d-port fields of udp/tcp protocols. ISP operators early in the specification processes provided explicit and animated feedback saying that UDP encapsulation was a critical feature. -Darrel -------------------------------------------- All IETF attendees have conflicts of interest. The only difference between them is that some admit it. I myself deny it. --Darrel Lewis (with apologies to H.L. Mencken) -------------------------------------------- From darlewis@cisco.com Wed May 27 10:21:21 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3A93A6C8C for ; Wed, 27 May 2009 10:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=0.316, 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 VcLJ2QD5Ck4j for ; Wed, 27 May 2009 10:21:20 -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 05F203A67EC for ; Wed, 27 May 2009 10:21:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,260,1241395200"; d="scan'208";a="169580393" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 27 May 2009 17:21:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4RHM1c6015240; Wed, 27 May 2009 10:22:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4RHM1xu008491; Wed, 27 May 2009 17:22:01 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 10:22:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 10:22:00 -0700 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC0F68@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5gT2I9/vY4tiQ42edVtEezrK1gAA57zQAAFTdxA= References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu><4A1D666F.3050603@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F68@XCH-NW-7V2.nw.nos.boeing.com> From: "Darrel Lewis (darlewis)" To: "Templin, Fred L" , , "Noel Chiappa" X-OriginalArrivalTime: 27 May 2009 17:22:01.0242 (UTC) FILETIME=[A5872FA0:01C9DEEF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1115; t=1243444921; x=1244308921; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20Comments=20about=20the=20LISP= 20header |Sender:=20; bh=wJz7evADEh42TGivnZLBT4XVg7Mnps/ZIcIRmNTUrjg=; b=Xe9cOvVzooVO+H/wR3FCkM3LQq9F5/IHVJGPu0FhzuUtVAq4xgw7yLoK34 ES9wbMbIiSfjDuwy9IslsCxIrriZE/tS+W7VD9VeW6O8IZNXWFQcaujj+nwZ xQxvxg9zirAvrG5ZwljQ37UA4RvxKYfvaMApkJ176cssiixRyxVPw=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:21:21 -0000 > > For example, consider a site one ITR that is sending packets towards > and > > EID served by two ETRs : ETR1 and ETR2. Both ETR1 and ETR2 are > reachable > > from ITR, but the path between ITR and ETR1 is heavily congested or > uses > > a low quality wireless link, leading to 30% packet losses while the > path > > towards ETR2 is not congested at all. Will ITR use both paths since > they > > are reachable or should it try to detect the packet losses and avoid > the > > lossy path ? >=20 > OK, so here's a good use for the SEAL sequence number. If the=20 > ETR tracks the SEAL sequence numbers it sees from a=20 > particular ITR it can report back the %packet loss when the=20 > ITR asks for an acknowledgement. Would something like that help? >=20 I can't see how requiring an ETR to keep state for all the ITRs that send it data is scalable. =20 -Darrel -------------------------------------------- All IETF attendees have conflicts of interest. The only difference between them is that some admit it. I myself deny it. --Darrel Lewis (with apologies to H.L. Mencken) -------------------------------------------- From Fred.L.Templin@boeing.com Wed May 27 10:27:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D6B3A677D for ; Wed, 27 May 2009 10:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.412, 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 eWnCDchSNppi for ; Wed, 27 May 2009 10:27:57 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 497EB3A6452 for ; Wed, 27 May 2009 10:27:57 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RHPr06018555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 10:25:53 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RHPr73025281; Wed, 27 May 2009 10:25:53 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RHPopg025159; Wed, 27 May 2009 10:25:52 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 10:25:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 10:25:49 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5FnDNJ7446c8R9SCupesshndJgAAgXLAAAHNr0AAAGe40A== References: <4A1D38B7.3020705@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com><4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Darrel Lewis (darlewis)" , X-OriginalArrivalTime: 27 May 2009 17:25:51.0105 (UTC) FILETIME=[2E897F10:01C9DEF0] Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:27:58 -0000 Hi Darrel, I appreciate your comments; see below for follow-up: > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Wednesday, May 27, 2009 10:17 AM > To: Templin, Fred L; Olivier.Bonaventure@uclouvain.be > Cc: lisp@ietf.org > Subject: RE: [lisp] Comments about the LISP header >=20 >=20 >=20 > > --> > The main benefit of the UDP header is that LISP > > encapsulated packets > > > appear as "normal" packets on today's Internet, including > > middleboxes. > > > There are too many devices today that drop packets because > > they do not > > > carry tcp, udp or other well known protocols. This is > > annoying, but we > > > have to live with this :-( > > > > I have some doubts that this is actually a problem. For > > example, ip-proto-41 seems to work fine for 6to4 and others. > > ip-proto-4 also for RFC2003 and its kin. GRE also seems to > > get through. There will also be no NAT traversal in the > > interdomain core. So, I don't see it as unrealistic that a > > new IP protocol would get through most paths and could be > > easily enabled to get through the other paths. > > >=20 > Fred, >=20 > Just three short short points about why LISP utilizes a UDP header. >=20 > First I'll note that my netgear router at home refuses to NAT on > anything besides TCP and UDP. Early implementations of LISP that > required the ALT to extend to the xTR would not work through this > device. There are no NATs in the DFZ. > Second, many enterprise firewalls are configured to deny IP protocols > that aren't explicitly allowed, so piggy backing on a known protocol has > some benefits. There are no enterprise firewalls in the DFZ. > Finally, Link Aggregation schemes for core routers use 5 tuple hashes > which include s-port and d-port fields of udp/tcp protocols. ISP > operators early in the specification processes provided explicit and > animated feedback saying that UDP encapsulation was a critical feature. These schemes would therefore have to do deep packet inspection to pick up the 5-tuples from ip-proto-4, ip-proto-41, GRE and the like. How unrealistic would it be for them to also accommodate a new IP protocol? I see the point that perhaps this is pushing things too far down the road beyond the experimentation phase at the current time. But once the experimenting gives way to full-scale operation, I don't see it as so much of a problem for network administrators to sync up with a new IP protocol. Fred fred.l.templin@boeing.com >=20 > -Darrel >=20 > -------------------------------------------- > All IETF attendees have conflicts of interest. The only difference > between them is that some admit it. I myself deny it. --Darrel Lewis > (with apologies to H.L. Mencken) > -------------------------------------------- From hartmans@mit.edu Wed May 27 10:48:07 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0879B3A6825 for ; Wed, 27 May 2009 10:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDZtueUtl2Nd for ; Wed, 27 May 2009 10:48:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 88C123A6A77 for ; Wed, 27 May 2009 10:48:03 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ACEFA415C; Wed, 27 May 2009 13:49:02 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090527161758.635AE6BE590@mercury.lcs.mit.edu> From: Sam Hartman Date: Wed, 27 May 2009 13:49:02 -0400 In-Reply-To: <20090527161758.635AE6BE590@mercury.lcs.mit.edu> (Noel Chiappa's message of "Wed\, 27 May 2009 12\:17\:58 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:48:07 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: "Joel M. Halpern" Conversely, this >> seems to introduce two design problems simultaneously. 1) >> including a feature we don't know the use for. Noel> Well, actually, from an architectural point of view, I quite Noel> like it. Noel> The _protocol_ mechanism is very simple and cheap. The Noel> algorithms to use it inside the nodes can change over time, Noel> and in a trivially interoperable way. It reminds me Noel> perfectly of TCP retransmission, where we were able to first Noel> experiment with, and then incrementally deploy VJCC, with Noel> zero hassle - because it had exactly these properties. So, from this discussion it sounds like you believe that the protocol bits are simple enough that we can look at them today? If I am understanding you correctly, can I get you to write up specific text proposing such a mechanism or find someone else to do so? Once we have have a specific proposal, we'll be in a better position to evaluate it. From darlewis@cisco.com Wed May 27 10:50:19 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924C028C134 for ; Wed, 27 May 2009 10:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.318 X-Spam-Level: X-Spam-Status: No, score=-6.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 x6SwA7ahmSq8 for ; Wed, 27 May 2009 10:50:17 -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 7874828C0D8 for ; Wed, 27 May 2009 10:50:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,260,1241395200"; d="scan'208";a="311676153" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 May 2009 17:50:55 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4RHot5B018325; Wed, 27 May 2009 10:50:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4RHot5H000217; Wed, 27 May 2009 17:50:55 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 10:50:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 10:50:53 -0700 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5FnDNJ7446c8R9SCupesshndJgAAgXLAAAHNr0AAAGe40AAAdgOg References: <4A1D38B7.3020705@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com><4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com> From: "Darrel Lewis (darlewis)" To: "Templin, Fred L" , X-OriginalArrivalTime: 27 May 2009 17:50:54.0692 (UTC) FILETIME=[AEBEAA40:01C9DEF3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2516; t=1243446655; x=1244310655; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20Comments=20about=20the=20LISP= 20header |Sender:=20; bh=oMBhBiehdR+JJOkHAWT9q9YVDEF482Z8/l9T8vdVVaM=; b=k13rOkhTx0h1SazWQNRKhd6d8nUJ7/5UMfMSoM98OXsA9e0QJcyM9yTBqC auGnFA4dLmoAbYrZXyDfnmK8Hyh64QRwciCg56pSrlllkH/JqwgIJkrekMNG L/lpCxRs3g; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:51:25 -0000 > > Just three short short points about why LISP utilizes a UDP header. > >=20 > > First I'll note that my netgear router at home refuses to NAT on=20 > > anything besides TCP and UDP. Early implementations of LISP that=20 > > required the ALT to extend to the xTR would not work through this=20 > > device. >=20 > There are no NATs in the DFZ. Yes, but LISP xTRs can (and have in the existing prototype network) been deployed within broadband sites. >=20 > > Second, many enterprise firewalls are configured to deny IP=20 > protocols=20 > > that aren't explicitly allowed, so piggy backing on a known protocol > has > > some benefits. >=20 > There are no enterprise firewalls in the DFZ. =20 As an aside: you might be surprised, considering the number of firewalls that wireless operators are deploying. But my serious response is that LISP xTRs can (and have in the existing network) been deployed deep within enterprise networks. While I d believe that the 'sweet' spot for most deployments will be the CPE router, even this co-location raises questions about the ordering of features implemented in conjunction with the XTR. >=20 > > Finally, Link Aggregation schemes for core routers use 5=20 > topple hashes=20 > > which include s-port and d-port fields of udp/tcp protocols. ISP=20 > > operators early in the specification processes provided=20 > explicit and=20 > > animated feedback saying that UDP encapsulation was a critical > feature. >=20 > These schemes would therefore have to do deep packet=20 > inspection to pick up the 5-tuples from ip-proto-4,=20 > ip-proto-41, GRE and the like. How unrealistic would it be=20 > for them to also accommodate a new IP protocol? The vast majority of these LAg implementations are hard coded into asics. Since something like 99%+ of the traffic in the core is ip protocol 6 and 17, SPs have asked their vendors to provide detailed features around those I protocols. If you did manage to convince someone that adding support for a different protocol would be a useful feature, it would still take a minimum of 2-5 years to see wide scale deployment. And all this assumes the protocol in question is amenable to 'flow' identification (GRE for instance, is not). -Darrel=20 -------------------------------------------- All IETF attendees have conflicts of interest. The only difference between them is that some admit it. I myself deny it. --Darrel Lewis (with apologies to H.L. Mencken) -------------------------------------------- From darlewis@cisco.com Wed May 27 10:52:12 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64CEB3A677D for ; Wed, 27 May 2009 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 uZmWkcx+aXJa for ; Wed, 27 May 2009 10:52:11 -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 8BABD3A67AE for ; Wed, 27 May 2009 10:52:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,260,1241395200"; d="scan'208";a="169595204" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 27 May 2009 17:52:18 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4RHqIWK021638; Wed, 27 May 2009 10:52:18 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4RHqI7Z016942; Wed, 27 May 2009 17:52:18 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 10:52:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 10:52:17 -0700 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC0FEE@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5gT2I9/vY4tiQ42edVtEezrK1gAA57zQAAFTdxAAAFAUMAAA47nw References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu><4A1D666F.3050603@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F68@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC0FEE@XCH-NW-7V2.nw.nos.boeing.com> From: "Darrel Lewis (darlewis)" To: "Templin, Fred L" , , "Noel Chiappa" X-OriginalArrivalTime: 27 May 2009 17:52:17.0969 (UTC) FILETIME=[E061BA10:01C9DEF3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=683; t=1243446738; x=1244310738; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20Comments=20about=20the=20LISP= 20header |Sender:=20; bh=MNW+cklyVGLo3oRqaNo7q7eG9Vrdz1bSbEuR8rEkRiY=; b=bfw61nagjlxNPAJVI7YHvLsNwX79sDLi2Mak5RFCKoDU2WMOGGFIFCpWUN QLQmC95aFf2ZJAgu1fWjnG+Yptaxvy9JkpsNUH0GRw8Zh0hUV2XuyxzPMJMp lDgNTWcxPC; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:52:12 -0000 Fred, > > > > > > OK, so here's a good use for the SEAL sequence number. If the ETR=20 > > > tracks the SEAL sequence numbers it sees from a particular ITR it=20 > > > can report back the %packet loss when the ITR asks for an=20 > > > acknowledgement. Would something like that help? > > > > >=20 > > I can't see how requiring an ETR to keep state for all the=20 > ITRs that=20 > > send it data is scalable. >=20 > This need not be phrased as a requirement; ETRs that can't=20 > keep state can simply inform the ITR of this deficiency in its acks. >=20 But sending ack's in the first place implies you kept enoug state to know who to send the ack to! -Darrel From hartmans@mit.edu Wed May 27 10:53:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200523A6D62 for ; Wed, 27 May 2009 10:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vz0iD7B2dQ4 for ; Wed, 27 May 2009 10:53:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 463F93A6C76 for ; Wed, 27 May 2009 10:53:30 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2CC00415C; Wed, 27 May 2009 13:54:31 -0400 (EDT) To: "Templin\, Fred L" References: <4A1D38B7.3020705@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> <4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> From: Sam Hartman Date: Wed, 27 May 2009 13:54:31 -0400 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> (Fred L. Templin's message of "Wed\, 27 May 2009 09\:27\:27 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:53:31 -0000 >>>>> "Fred" == Templin, Fred L writes: >> I'm not convinced that all the mechanisms placed in SEAL are >> necessary for LISP. Fred> SEAL has 8 "control" bits, of which at least the Fred> "Acknowledgment Requested" and "Report Fragmentation" bits Fred> are required. Four other control bits (the M bit and the Fred> 3-bit SEG field) are used for segmentation and reassembly, Fred> but it may well be that LISP will not want to use these Fred> under many circumstances which is absolutely fine and Fred> consistent with the SEAL architecture. Finally, the 'Y' bit Fred> is used by the ETR to tell the ITR whether/not it is willing Fred> to reassemble. That leaves only one bit as unused among the Fred> 8 control bits. Fred, it's my understanding that the PMTU handling issue you have raised is still open. It sounds like most of these facilities are only needed if the working group concludes you are correct and that a more advanced PMTU handling strategy is required. Or put another way, would you agree with me that the WG as a whole has not yet come to agree that these facilities are needed in LISP? It's my understanding that the PMTU issue has not been discussed in this context--the working group--although it has been discussed in other contexts in the past. As such, it's very much open until we have that discussion and come to consensus. From Fred.L.Templin@boeing.com Wed May 27 11:18:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCDE3A716E for ; Wed, 27 May 2009 11:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 TbIVQJLIlGxE for ; Wed, 27 May 2009 11:18:38 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 481CC3A6D7A for ; Wed, 27 May 2009 11:18:04 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RIJZeo015406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 13:19:36 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RIJZkT016856; Wed, 27 May 2009 11:19:35 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RIJXM2016730; Wed, 27 May 2009 11:19:35 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 11:19:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 11:19:32 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5FnDNJ7446c8R9SCupesshndJgAAgXLAAAHNr0AAAGe40AAAdgOgAAGHsPA= References: <4A1D38B7.3020705@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com><4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Darrel Lewis (darlewis)" , X-OriginalArrivalTime: 27 May 2009 18:19:33.0647 (UTC) FILETIME=[AF5261F0:01C9DEF7] Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:18:39 -0000 Darrel, A number of your comments regarding deployment scenarios are somewhat surprising to me, since my understanding was that LISP would deploy on DFZ routers. RANGER already has the deployment scenarios for enterprise networks covered. Respecting enterprise boundaries has clean architectural benefits. Tunneling through NATs and firewalls has drawbacks. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Wednesday, May 27, 2009 10:51 AM > To: Templin, Fred L; Olivier.Bonaventure@uclouvain.be > Cc: lisp@ietf.org > Subject: RE: [lisp] Comments about the LISP header >=20 >=20 > > > Just three short short points about why LISP utilizes a UDP header. > > > > > > First I'll note that my netgear router at home refuses to NAT on > > > anything besides TCP and UDP. Early implementations of LISP that > > > required the ALT to extend to the xTR would not work through this > > > device. > > > > There are no NATs in the DFZ. >=20 > Yes, but LISP xTRs can (and have in the existing prototype network) been > deployed within broadband sites. >=20 > > > > > Second, many enterprise firewalls are configured to deny IP > > protocols > > > that aren't explicitly allowed, so piggy backing on a known protocol > > has > > > some benefits. > > > > There are no enterprise firewalls in the DFZ. >=20 > As an aside: you might be surprised, considering the number of firewalls > that wireless operators are deploying. >=20 > But my serious response is that LISP xTRs can (and have in the existing > network) been deployed deep within enterprise networks. While I d > believe that the 'sweet' spot for most deployments will be the CPE > router, even this co-location raises questions about the ordering of > features implemented in conjunction with the XTR. >=20 > > > > > Finally, Link Aggregation schemes for core routers use 5 > > topple hashes > > > which include s-port and d-port fields of udp/tcp protocols. ISP > > > operators early in the specification processes provided > > explicit and > > > animated feedback saying that UDP encapsulation was a critical > > feature. > > > > These schemes would therefore have to do deep packet > > inspection to pick up the 5-tuples from ip-proto-4, > > ip-proto-41, GRE and the like. How unrealistic would it be > > for them to also accommodate a new IP protocol? >=20 > The vast majority of these LAg implementations are hard coded into > asics. Since something like 99%+ of the traffic in the core is ip > protocol 6 and 17, SPs have asked their vendors to provide detailed > features around those I protocols. If you did manage to convince > someone that adding support for a different protocol would be a useful > feature, it would still take a minimum of 2-5 years to see wide scale > deployment. And all this assumes the protocol in question is amenable > to 'flow' identification (GRE for instance, is not). >=20 > -Darrel >=20 > -------------------------------------------- > All IETF attendees have conflicts of interest. The only difference > between them is that some admit it. I myself deny it. --Darrel Lewis > (with apologies to H.L. Mencken) > -------------------------------------------- From Fred.L.Templin@boeing.com Wed May 27 11:19:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D1C3A6EA7 for ; Wed, 27 May 2009 11:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 3Y6t2oyN9Pef for ; Wed, 27 May 2009 11:19:36 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 7C8913A6D64 for ; Wed, 27 May 2009 11:19:36 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RILHZT016561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 13:21:17 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RILHKo012259; Wed, 27 May 2009 13:21:17 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RILFHk012182; Wed, 27 May 2009 13:21:17 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 11:21:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 11:21:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC1071@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5gT2I9/vY4tiQ42edVtEezrK1gAA57zQAAFTdxAAAFAUMAAA47nwAAD+5AA= References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu><4A1D666F.3050603@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F68@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC0FEE@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Darrel Lewis (darlewis)" , , "Noel Chiappa" X-OriginalArrivalTime: 27 May 2009 18:21:17.0030 (UTC) FILETIME=[ECF16060:01C9DEF7] Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:19:37 -0000 Darrel, > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Wednesday, May 27, 2009 10:52 AM > To: Templin, Fred L; Olivier.Bonaventure@uclouvain.be; Noel Chiappa > Cc: lisp@ietf.org > Subject: RE: [lisp] Comments about the LISP header >=20 > Fred, >=20 > > > > > > > > OK, so here's a good use for the SEAL sequence number. If the ETR > > > > tracks the SEAL sequence numbers it sees from a particular ITR it > > > > can report back the %packet loss when the ITR asks for an > > > > acknowledgement. Would something like that help? > > > > > > > > > > I can't see how requiring an ETR to keep state for all the > > ITRs that > > > send it data is scalable. > > > > This need not be phrased as a requirement; ETRs that can't > > keep state can simply inform the ITR of this deficiency in its acks. > > >=20 > But sending ack's in the first place implies you kept enoug state to > know who to send the ack to! No it doesn't; sending an ack is no different than sending an ICMP, and all that is needed for that is the packet that triggered the ICMP. Fred fred.l.templin@boeing.com >=20 > -Darrel From Fred.L.Templin@boeing.com Wed May 27 11:26:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40DD23A6C56 for ; Wed, 27 May 2009 11:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.396, 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 xurp+05RAv+r for ; Wed, 27 May 2009 11:26:36 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id B71C33A6CF4 for ; Wed, 27 May 2009 11:26:34 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RHSF8r019989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 10:28:15 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RHSFTZ029594; Wed, 27 May 2009 10:28:15 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RHSDaL029501; Wed, 27 May 2009 10:28:14 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 10:28:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 10:28:11 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC0FEE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5gT2I9/vY4tiQ42edVtEezrK1gAA57zQAAFTdxAAAFAUMA== References: <20090527132617.54FEE6BE590@mercury.lcs.mit.edu><4A1D666F.3050603@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F68@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Darrel Lewis (darlewis)" , , "Noel Chiappa" X-OriginalArrivalTime: 27 May 2009 17:28:13.0389 (UTC) FILETIME=[83584FD0:01C9DEF0] Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:26:37 -0000 Darrel, > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Wednesday, May 27, 2009 10:22 AM > To: Templin, Fred L; Olivier.Bonaventure@uclouvain.be; Noel Chiappa > Cc: lisp@ietf.org > Subject: RE: [lisp] Comments about the LISP header >=20 >=20 > > > For example, consider a site one ITR that is sending packets > towards > > and > > > EID served by two ETRs : ETR1 and ETR2. Both ETR1 and ETR2 are > > reachable > > > from ITR, but the path between ITR and ETR1 is heavily congested or > > uses > > > a low quality wireless link, leading to 30% packet losses while the > > path > > > towards ETR2 is not congested at all. Will ITR use both paths since > > they > > > are reachable or should it try to detect the packet losses and avoid > > the > > > lossy path ? > > > > OK, so here's a good use for the SEAL sequence number. If the > > ETR tracks the SEAL sequence numbers it sees from a > > particular ITR it can report back the %packet loss when the > > ITR asks for an acknowledgement. Would something like that help? > > >=20 > I can't see how requiring an ETR to keep state for all the ITRs that > send it data is scalable. This need not be phrased as a requirement; ETRs that can't keep state can simply inform the ITR of this deficiency in its acks. Fred fred.l.templin@boeing.com >=20 > -Darrel >=20 > -------------------------------------------- > All IETF attendees have conflicts of interest. The only difference > between them is that some admit it. I myself deny it. --Darrel Lewis > (with apologies to H.L. Mencken) > -------------------------------------------- From Fred.L.Templin@boeing.com Wed May 27 11:30:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BB93A714E for ; Wed, 27 May 2009 11:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.391, 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 Lx0AJ96hqIKD for ; Wed, 27 May 2009 11:30:07 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id E49563A7168 for ; Wed, 27 May 2009 11:30:06 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RIVcpZ024715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 11:31:39 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RIVcHn000099; Wed, 27 May 2009 13:31:38 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RIVTBJ029774; Wed, 27 May 2009 13:31:38 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 11:31:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 11:31:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC108E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne9DLMlriT73koTnKk2QrW/4bU2QAA8XWg References: <4A1D38B7.3020705@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com><4A1D636D.6080005@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Sam Hartman" X-OriginalArrivalTime: 27 May 2009 18:31:36.0026 (UTC) FILETIME=[5DE4ABA0:01C9DEF9] Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:30:09 -0000 Sam, > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, May 27, 2009 10:55 AM > To: Templin, Fred L > Cc: Olivier.Bonaventure@uclouvain.be; lisp@ietf.org > Subject: Re: [lisp] Comments about the LISP header >=20 > >>>>> "Fred" =3D=3D Templin, Fred L = writes: > >> I'm not convinced that all the mechanisms placed in SEAL are > >> necessary for LISP. >=20 > Fred> SEAL has 8 "control" bits, of which at least the > Fred> "Acknowledgment Requested" and "Report Fragmentation" bits > Fred> are required. Four other control bits (the M bit and the > Fred> 3-bit SEG field) are used for segmentation and reassembly, > Fred> but it may well be that LISP will not want to use these > Fred> under many circumstances which is absolutely fine and > Fred> consistent with the SEAL architecture. Finally, the 'Y' bit > Fred> is used by the ETR to tell the ITR whether/not it is willing > Fred> to reassemble. That leaves only one bit as unused among the > Fred> 8 control bits. >=20 >=20 > Fred, it's my understanding that the PMTU handling issue you have > raised is still open. It sounds like most of these facilities are > only needed if the working group concludes you are correct and that a > more advanced PMTU handling strategy is required. >=20 > Or put another way, would you agree with me that the WG as a whole has > not yet come to agree that these facilities are needed in LISP? It seemed to me that we were gravitating toward a position that the MTU reporting mechanism of SEAL is desirable but not all xTRs will want to implement the SEAL segmentation capability. That is perfectly OK, and consistent with the SEAL architecture. So, if one of the ITR/ETR does not want to implement SEAL segmentation then that capability will not be used. If both ends implement it, then the capability can be used if needed. > It's my understanding that the PMTU issue has not been discussed in > this context--the working group--although it has been discussed in > other contexts in the past. As such, it's very much open until we > have that discussion and come to consensus. It should be pointed out that SEAL is about much more than just MTU handling. The SEAL ID extension also provides a packet identifying tag that is beneficial for many reasons, and can be used instead of the LISP nonce. SEAL also already has built-in liveness testing piggybacked on the data messages, which is exactly what Noel was asking for. Fred fred.l.templin@boeing.com From hartmans@mit.edu Wed May 27 11:45:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0159E3A715B for ; Wed, 27 May 2009 11:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR+j6PjKuCT8 for ; Wed, 27 May 2009 11:45:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4234C3A6E32 for ; Wed, 27 May 2009 11:45:33 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 13762415C; Wed, 27 May 2009 14:46:35 -0400 (EDT) To: "Templin\, Fred L" References: <4A1D38B7.3020705@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> <4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC108E@XCH-NW-7V2.nw.nos.boeing.com> From: Sam Hartman Date: Wed, 27 May 2009 14:46:35 -0400 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC108E@XCH-NW-7V2.nw.nos.boeing.com> (Fred L. Templin's message of "Wed\, 27 May 2009 11\:31\:34 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:45:34 -0000 >>>>> "Templin," == Templin, Fred L writes: Templin,> It seemed to me that we were gravitating toward a Templin,> position that the MTU reporting mechanism of SEAL is Templin,> desirable but not all xTRs will want to implement the Templin,> SEAL segmentation capability. That is perfectly OK, and Templin,> consistent with the SEAL architecture. Interesting. I had not seen that, which probably simply means I missed the discussion. Comments from others welcome. From darlewis@cisco.com Wed May 27 12:19:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB643A6DCE for ; Wed, 27 May 2009 12:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 tE7-Svto8yzF for ; Wed, 27 May 2009 12:19:51 -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 7BE3E3A696E for ; Wed, 27 May 2009 12:19:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,261,1241395200"; d="scan'208";a="190951264" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 27 May 2009 19:19:58 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4RJJwRC026842; Wed, 27 May 2009 12:19:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4RJJw0B025247; Wed, 27 May 2009 19:19:58 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 12:19:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 12:19:57 -0700 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5FnDNJ7446c8R9SCupesshndJgAAgXLAAAHNr0AAAGe40AAAdgOgAAGHsPAAAWeDsA== References: <4A1D38B7.3020705@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com><4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> From: "Darrel Lewis (darlewis)" To: "Templin, Fred L" , X-OriginalArrivalTime: 27 May 2009 19:19:58.0386 (UTC) FILETIME=[1FD5A920:01C9DF00] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1204; t=1243451998; x=1244315998; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20Comments=20about=20the=20LISP= 20header |Sender:=20; bh=Ua8Fdn2S6G2N5+xbhaOq+UKJyeZfUxD234I1QCmpLM0=; b=mzuRLVZLTObETowSEDekhLgRS1vtFavXXvYWALgat87ErUPV5YbSsGYhJ8 Qff0hYf/1Wto7BCFeRX6OdbrbGSUwJMs38D6+KgiaPsAUzX7sXKjxDpQUuLt ybOsZ7MdKv4uPd9+8OG8lw7lT1M8evZRK9FiNVn1PPv/UahqlLeKA=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 19:19:52 -0000 Hi Fred, >=20 > A number of your comments regarding deployment scenarios are=20 > somewhat surprising to me, since my understanding was that=20 > LISP would deploy on DFZ routers. RANGER already has the=20 > deployment scenarios for enterprise networks covered. I don't recall the LISP drafts (specifically draft-ietf-lisp-00.txt) restricting the placement of xTRs to any particular place in a network's topology. Some placement choices seem to have inherent drawbacks, while others have interesting benefits.=20 I'm not sure how LISP relates to RANGER, in that none of the LISP drafts seem to reference or discuss coexisting or interacting with RANGER. I'm also not aware of any implementations of RANGER that LISP implementations could or have experimented/interoperated with. >=20 > Respecting enterprise boundaries has clean architectural=20 > benefits. Tunneling through NATs and firewalls has drawbacks. Yet but these devices exist, and as Olivier mentioned, we should perhaps consider how LISP is going to interact with them. I personally would not be in favor of constraining the topological placement of xTRs due to arbitrary architectural concerns. -Darrel From dmm@1-4-5.net Wed May 27 12:57:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FE63A6DC2 for ; Wed, 27 May 2009 12:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 Qxd40lScm4Vy for ; Wed, 27 May 2009 12:56:59 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 738B33A6E2D for ; Wed, 27 May 2009 12:56:16 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n4RJvqSe014963; Wed, 27 May 2009 12:57:52 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n4RJvq61014962; Wed, 27 May 2009 12:57:52 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 27 May 2009 12:57:52 -0700 From: David Meyer To: "Templin, Fred L" Message-ID: <20090527195752.GA14915@1-4-5.net> References: <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 19:57:00 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Fred, > A number of your comments regarding deployment scenarios > are somewhat surprising to me, since my understanding was > that LISP would deploy on DFZ routers.=20 This is a misunderstanding on your part. We can thought from day one that one of the sweet spots for LISP is the CPE.=20 > RANGER already has the deployment scenarios for enterprise > networks covered.=20 I'm not sure about the relevance of that statement. Could you clarify? =09 > Respecting enterprise boundaries has clean architectural > benefits. Tunneling through NATs and firewalls has drawbacks. Perhaps, but again, what is your point? Dave --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkodm0AACgkQORgD1qCZ2Kd3bACfdcA2tOt1fphc1tGnCKZwDDTV SDgAn0Wzag0YThuxJQS8nkMjncVQAO1w =n8qm -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From dmm@1-4-5.net Wed May 27 13:01:30 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84FF3A7186 for ; Wed, 27 May 2009 13:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 TteCIO1XBL3Z for ; Wed, 27 May 2009 13:01:29 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id DBD9E28C10E for ; Wed, 27 May 2009 13:01:25 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n4RK2ioh015045; Wed, 27 May 2009 13:02:44 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n4RK2ims015044; Wed, 27 May 2009 13:02:44 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 27 May 2009 13:02:44 -0700 From: David Meyer To: "Templin, Fred L" Message-ID: <20090527200244.GB14915@1-4-5.net> References: <39C363776A4E8C4A94691D2BD9D1C9A105FC108E@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc" Content-Disposition: inline In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC108E@XCH-NW-7V2.nw.nos.boeing.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 20:01:30 -0000 --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2009 at 11:31:34AM -0700, Templin, Fred L wrote: > Sam, >=20 > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: Wednesday, May 27, 2009 10:55 AM > > To: Templin, Fred L > > Cc: Olivier.Bonaventure@uclouvain.be; lisp@ietf.org > > Subject: Re: [lisp] Comments about the LISP header > >=20 > > >>>>> "Fred" =3D=3D Templin, Fred L writes: > > >> I'm not convinced that all the mechanisms placed in SEAL are > > >> necessary for LISP. > >=20 > > Fred> SEAL has 8 "control" bits, of which at least the > > Fred> "Acknowledgment Requested" and "Report Fragmentation" bits > > Fred> are required. Four other control bits (the M bit and the > > Fred> 3-bit SEG field) are used for segmentation and reassembly, > > Fred> but it may well be that LISP will not want to use these > > Fred> under many circumstances which is absolutely fine and > > Fred> consistent with the SEAL architecture. Finally, the 'Y' bit > > Fred> is used by the ETR to tell the ITR whether/not it is willing > > Fred> to reassemble. That leaves only one bit as unused among the > > Fred> 8 control bits. > >=20 > >=20 > > Fred, it's my understanding that the PMTU handling issue you have > > raised is still open. It sounds like most of these facilities are > > only needed if the working group concludes you are correct and that a > > more advanced PMTU handling strategy is required. > >=20 > > Or put another way, would you agree with me that the WG as a whole has > > not yet come to agree that these facilities are needed in LISP? >=20 > It seemed to me that we were gravitating toward a position > that the MTU reporting mechanism of SEAL is desirable but > not all xTRs will want to implement the SEAL segmentation > capability. That is perfectly OK, and consistent with the > SEAL architecture. First, what is "gravitating"? Please provide a definition. Second, if you mean some kind of quasi-consensus (as implied about), I observe no evidence of such "consensus". As such, can you please support this assertion? Thanks, Dave --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkodnGQACgkQORgD1qCZ2KfAHgCfUlHDyZdJyrAcxoHKPbv+grI9 V5AAni8LDPqdMTwOtjbP9BBu8abDeGSr =6PLP -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc-- From Fred.L.Templin@boeing.com Wed May 27 13:06:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20E13A694A for ; Wed, 27 May 2009 13:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 Veup8uRUAjfT for ; Wed, 27 May 2009 13:06:19 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 8F4673A6E92 for ; Wed, 27 May 2009 13:06:02 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RK6waP018049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 15:06:59 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RK6wmc021683; Wed, 27 May 2009 13:06:58 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RK6tod021510; Wed, 27 May 2009 13:06:58 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 13:06:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 13:06:54 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC1156@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acne5FnDNJ7446c8R9SCupesshndJgAAgXLAAAHNr0AAAGe40AAAdgOgAAGHsPAAAWeDsAACJ4sg References: <4A1D38B7.3020705@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com><4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Darrel Lewis (darlewis)" , X-OriginalArrivalTime: 27 May 2009 20:06:55.0395 (UTC) FILETIME=[AEE71F30:01C9DF06] Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 20:06:20 -0000 Darrel, > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Wednesday, May 27, 2009 12:20 PM > To: Templin, Fred L; Olivier.Bonaventure@uclouvain.be > Cc: lisp@ietf.org > Subject: RE: [lisp] Comments about the LISP header >=20 > Hi Fred, >=20 > > > > A number of your comments regarding deployment scenarios are > > somewhat surprising to me, since my understanding was that > > LISP would deploy on DFZ routers. RANGER already has the > > deployment scenarios for enterprise networks covered. >=20 > I don't recall the LISP drafts (specifically draft-ietf-lisp-00.txt) > restricting the placement of xTRs to any particular place in a network's > topology. Some placement choices seem to have inherent drawbacks, while > others have interesting benefits. >=20 > I'm not sure how LISP relates to RANGER, in that none of the LISP drafts > seem to reference or discuss coexisting or interacting with RANGER. It's certainly not for lack of my waving the RANGER documents in front of peoples' faces. Please see also the latest in the series on RANGER Scenarios: http://tools.ietf.org/html/draft-russert-rangers > I'm > also not aware of any implementations of RANGER that LISP > implementations could or have experimented/interoperated with. RANGER is an architecture; VET, SEAL and ISATAP are its constituent mechanisms. VET, SEAL and ISATAP are implemented: http://osprey67.com/seal http://osprey67.com/vet http://isatap.com > > Respecting enterprise boundaries has clean architectural > > benefits. Tunneling through NATs and firewalls has drawbacks. >=20 > Yet but these devices exist, and as Olivier mentioned, we should perhaps > consider how LISP is going to interact with them. I personally would > not be in favor of constraining the topological placement of xTRs due to > arbitrary architectural concerns. Very simple - put the xTRs on enterprise border routers, and you have clean delineation of enterprise boundaries. Fred fred.l.templin@boeing.com >=20 > -Darrel From Fred.L.Templin@boeing.com Wed May 27 13:19:05 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2C83A6A65 for ; Wed, 27 May 2009 13:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.381, 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 Q6l5XAPW4CPq for ; Wed, 27 May 2009 13:19:04 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 4635B3A70FE for ; Wed, 27 May 2009 13:19:04 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RKKGc8026698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 15:20:16 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RKKFEh000291; Wed, 27 May 2009 13:20:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RKKFJr000287; Wed, 27 May 2009 13:20:15 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 13:20:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 13:20:05 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC116E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090527195752.GA14915@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: AcnfBXKLyuUxiZusSuSdcmb+KVh6cgAAUWtw References: <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> <20090527195752.GA14915@1-4-5.net> From: "Templin, Fred L" To: "David Meyer" X-OriginalArrivalTime: 27 May 2009 20:20:06.0300 (UTC) FILETIME=[8651A5C0:01C9DF08] Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 20:19:05 -0000 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Wednesday, May 27, 2009 12:58 PM > To: Templin, Fred L > Cc: Darrel Lewis (darlewis); Olivier.Bonaventure@uclouvain.be; lisp@ietf.org > Subject: Re: [lisp] Comments about the LISP header >=20 > Fred, >=20 > > A number of your comments regarding deployment scenarios > > are somewhat surprising to me, since my understanding was > > that LISP would deploy on DFZ routers. >=20 > This is a misunderstanding on your part. We can thought > from day one that one of the sweet spots for LISP is the > CPE. Hey - that's RANGER's space! VET already has the mechanisms needed for operation on a CPE router, including the ability for CPEs to discover ISP border routers that can get out of the ISP network. SEAL has the mechanisms for ensuring that home network devices will see a robust MTU even if the tunnel overhead eats into the physical link MTU. And, ISATAP already has the all-important Potential Router List (PRL) discovery mechanism. These tools, plus consistent site administration practices, is all that is necessary.=20 > > RANGER already has the deployment scenarios for enterprise > > networks covered. >=20 > I'm not sure about the relevance of that statement. Could > you clarify? Noel has asked that we consider in later phases moving the xTR all the way out to the end systems. Such end systems can be considered as enterprises unto themselves. (Think about a laptop computer with its attached devices as an example.) RANGER's enterprise-within-enterprise framework therefore recurses from the smallest end system out to the global Internet. None of this stuff is new; it all harkens back to the ROAD group work, NIMROD, and even as far back as the Cerf and Pouzin work on CATENET. > > Respecting enterprise boundaries has clean architectural > > benefits. Tunneling through NATs and firewalls has drawbacks. >=20 > Perhaps, but again, what is your point? The point is that with RANGER (and maybe also LISP) we now have a restoration of architectural principles for the Internet at-hand. No more hacking around with chewing-gum and baling-wire point solutions; this is stuff is mainstream and offers the whole package. Fred fred.l.templin@boeing.com=20 > Dave From Fred.L.Templin@boeing.com Wed May 27 13:23:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8253A715B for ; Wed, 27 May 2009 13:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 fSR-wWXM3KGj for ; Wed, 27 May 2009 13:23:30 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id C71283A70FE for ; Wed, 27 May 2009 13:23:30 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RKOcCf007521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 May 2009 13:24:39 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RKOcXN010371; Wed, 27 May 2009 13:24:38 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RKOb5j010332; Wed, 27 May 2009 13:24:38 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 13:24:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 13:24:32 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC1179@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090527200244.GB14915@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: AcnfBhuFHVvG9yA8RSS7jYs8w3hSEwAAoe9A References: <39C363776A4E8C4A94691D2BD9D1C9A105FC108E@XCH-NW-7V2.nw.nos.boeing.com> <20090527200244.GB14915@1-4-5.net> From: "Templin, Fred L" To: "David Meyer" X-OriginalArrivalTime: 27 May 2009 20:24:32.0634 (UTC) FILETIME=[2510FDA0:01C9DF09] Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 20:23:31 -0000 Dave, > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Wednesday, May 27, 2009 1:03 PM > To: Templin, Fred L > Cc: Sam Hartman; Olivier.Bonaventure@uclouvain.be; lisp@ietf.org > Subject: Re: [lisp] Comments about the LISP header >=20 > On Wed, May 27, 2009 at 11:31:34AM -0700, Templin, Fred L wrote: > > Sam, > > > > > -----Original Message----- > > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > > Sent: Wednesday, May 27, 2009 10:55 AM > > > To: Templin, Fred L > > > Cc: Olivier.Bonaventure@uclouvain.be; lisp@ietf.org > > > Subject: Re: [lisp] Comments about the LISP header > > > > > > >>>>> "Fred" =3D=3D Templin, Fred L writes: > > > >> I'm not convinced that all the mechanisms placed in SEAL are > > > >> necessary for LISP. > > > > > > Fred> SEAL has 8 "control" bits, of which at least the > > > Fred> "Acknowledgment Requested" and "Report Fragmentation" bits > > > Fred> are required. Four other control bits (the M bit and the > > > Fred> 3-bit SEG field) are used for segmentation and reassembly, > > > Fred> but it may well be that LISP will not want to use these > > > Fred> under many circumstances which is absolutely fine and > > > Fred> consistent with the SEAL architecture. Finally, the 'Y' bit > > > Fred> is used by the ETR to tell the ITR whether/not it is willing > > > Fred> to reassemble. That leaves only one bit as unused among the > > > Fred> 8 control bits. > > > > > > > > > Fred, it's my understanding that the PMTU handling issue you have > > > raised is still open. It sounds like most of these facilities are > > > only needed if the working group concludes you are correct and that a > > > more advanced PMTU handling strategy is required. > > > > > > Or put another way, would you agree with me that the WG as a whole has > > > not yet come to agree that these facilities are needed in LISP? > > > > It seemed to me that we were gravitating toward a position > > that the MTU reporting mechanism of SEAL is desirable but > > not all xTRs will want to implement the SEAL segmentation > > capability. That is perfectly OK, and consistent with the > > SEAL architecture. >=20 > First, what is "gravitating"? Please provide a > definition. Second, if you mean some kind of > quasi-consensus (as implied about), I observe no evidence > of such "consensus". As such, can you please support this > assertion? There was discussion, yes - and even some innuendos tossed around about april-fools-day drafts and the like. You can go back and look through the archives for the earlier discussions if you'd like - as far as I can tell, its all good. Fred fred.l.templin@boeing.com=20 >=20 >=20 > Thanks, >=20 > Dave From olivier.bonaventure@uclouvain.be Wed May 27 13:31:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCEAA3A6DAD for ; Wed, 27 May 2009 13:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8WAFR6njTWH for ; Wed, 27 May 2009 13:31:42 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 3F64D3A68D7 for ; Wed, 27 May 2009 13:31:40 -0700 (PDT) Received: from mbpobo.local (ip-83-134-213-16.dsl.scarlet.be [83.134.213.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id AACF1F206F; Wed, 27 May 2009 22:33:29 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be AACF1F206F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1243456409; bh=+U/g400e8tXcZGj4AMHBWBu8e1Gzu1EOqnFISjFQDGY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VQDi7uM/6sK+xEqnsO9+CcqHfm8xkHzrzm0mAiN5NYZ57qj3Eb6f+3viiKP1ERW7b UyN37LDd1dg2V5eV7W2JMAqoCzf8N1pKFuCemXRMseqYsE7WrILjwZ8/kXgvGaSxub UDi7kxi4Bsyu8DvCEvCxX+ANh7TpKa2DTS0y/Jtk= Message-ID: <4A1DA38B.3070901@uclouvain.be> Date: Wed, 27 May 2009 22:33:15 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Noel Chiappa References: <20090527151540.8EC026BE590@mercury.lcs.mit.edu> In-Reply-To: <20090527151540.8EC026BE590@mercury.lcs.mit.edu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: AACF1F206F.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 20:31:43 -0000 Noel, > > From: Scott Brim > > > What if traffic leaves site A via xTR 1 and enters site B via xTR 2 ... > > but the return traffic leaves B via xTR 3 and enters A via xTR 4? Then > > the xTR that sends the reachability request will never see the returned > > ACK. > > Hence my prior comment: > > >> Piggybacking reachability detection on user data traffic is not a > >> perfect solution, but it seems that it might be a useful tool, when > >> combined with a number of other techniques. > > Before we start fine-tuning the mechanism-set, though, I think we need to > get some practical experience - see how often that scenario happens IRL, > etc. The RIPE TTM service could be a good way to evaluate the evolution of reachability among pairs of routers. RIPE TTM implements the measurements defined by the IPPM wg and the testbox are hosted by ISPs, mainly in Europe. RIPE TTM uses one way delay measurements with GPS clocks. Compared to traditionnal ping measurements, this has the advantage of showing when one direction between two testbox is working while the other is not. On IPv4 testboxes, it seems that only one pair suffers from unidirectionnal failures : tt7 to tt111 reports 100% losses http://www.ripe.net/ttm/Plots/plots.cgi?ipv=4&url=map_index.cgi&base=tt111&src=tt07&dst=tt111 while the opposite direction shows only very few losses http://www.ripe.net/ttm/Plots/plots.cgi?ipv=4&url=map_index.cgi&base=tt07&src=tt111&dst=tt07 Concerning IPv6, the situation is worse and there are more pairs of tesboxes with unidirectionnal reachability only. http://www.ripe.net/ttm/Plots/summary.cgi?ipv=6&sortfield=marked+cells&sortkey=relative+change&sortorder=descending&format=html&threshold=+40.0&unit=percent&boxname=tt07&file=weeksummary.xml This is likely because IPv6 is not currently considered by all owners of testboxes as a production service like IPv4. It could be interesting to study the RIPE TTM data to see whether the failure of a unidirectionnal path is frequent and how long it lasts. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From hartmans@mit.edu Wed May 27 13:41:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56583A6A80 for ; Wed, 27 May 2009 13:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+o9T5K3e09G for ; Wed, 27 May 2009 13:41:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 61B5E3A68C4 for ; Wed, 27 May 2009 13:40:55 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 513F6415C; Wed, 27 May 2009 16:42:36 -0400 (EDT) To: "Darrel Lewis \(darlewis\)" References: <4A1D38B7.3020705@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> <4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> From: Sam Hartman Date: Wed, 27 May 2009 16:42:36 -0400 In-Reply-To: (Darrel Lewis's message of "Wed\, 27 May 2009 12\:19\:57 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Templin, Fred L" , Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 20:41:18 -0000 >>>>> "Darrel" == Darrel Lewis (darlewis) writes: Darrel> Hi Fred, >> >> A number of your comments regarding deployment scenarios are >> somewhat surprising to me, since my understanding was that LISP >> would deploy on DFZ routers. RANGER already has the deployment >> scenarios for enterprise networks covered. Darrel> I don't recall the LISP drafts (specifically Darrel> draft-ietf-lisp-00.txt) restricting the placement of xTRs Darrel> to any particular place in a network's topology. Some Darrel> placement choices seem to have inherent drawbacks, while Darrel> others have interesting benefits. Darrel> I'm not sure how LISP relates to RANGER, in that none of Darrel> the LISP drafts seem to reference or discuss coexisting or Darrel> interacting with RANGER. I'm also not aware of any Darrel> implementations of RANGER that LISP implementations could Darrel> or have experimented/interoperated with. No, but our charter limits us to LISP as a solution to the global route scaling problem. In our meeting before the LISP WG at San Francisco, I stated my interpretation that the broad band use case falls outside of our charter and those around the table agreed. You were one of the people there. So, I do not believe that we're designing LISP to work on broad band routers. That doesn't mean we should go wrip out parts of LISP that makes that possible or even that such things are undesirable. It simply means that "we need that for broad band," is not a justification within the context of this WG. "That's there for broad band," may be a statement of historical fact. I think the issues surrounding LISP and enterprises are more complicated. It's not clear to me whether designing LISP to run behind enterprise firewalls is within our charter or not. I'd ask people making arguments based on enterprise firewalls to carefully consider how their argument affects LISP as a solution to the global route scaling problem. Concerns about load balancing in the DFZ clearly are within scope. From Fred.L.Templin@boeing.com Wed May 27 13:49:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E0B3A6BFF for ; Wed, 27 May 2009 13:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.927 X-Spam-Level: X-Spam-Status: No, score=-5.927 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMCHA5DFky63 for ; Wed, 27 May 2009 13:49:09 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 5C0E03A69CD for ; Wed, 27 May 2009 13:49:09 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RKobfA016152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 13:50:37 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RKoaKj017460; Wed, 27 May 2009 15:50:37 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RKoRal017239; Wed, 27 May 2009 15:50:36 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 13:50:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 13:50:32 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC11BB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: AcnfC60UoAWLoxvZTn2buhwlVT3cKQAALZzA References: <4A1D38B7.3020705@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com><4A1D636D.6080005@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Sam Hartman" , "Darrel Lewis (darlewis)" X-OriginalArrivalTime: 27 May 2009 20:50:32.0882 (UTC) FILETIME=[C70BF120:01C9DF0C] Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 20:49:10 -0000 Sam, > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, May 27, 2009 1:43 PM > To: Darrel Lewis (darlewis) > Cc: Templin, Fred L; Olivier.Bonaventure@uclouvain.be; lisp@ietf.org > Subject: Re: [lisp] Comments about the LISP header >=20 > >>>>> "Darrel" =3D=3D Darrel Lewis (darlewis) = writes: >=20 > Darrel> Hi Fred, > >> > >> A number of your comments regarding deployment scenarios are > >> somewhat surprising to me, since my understanding was that LISP > >> would deploy on DFZ routers. RANGER already has the deployment > >> scenarios for enterprise networks covered. >=20 > Darrel> I don't recall the LISP drafts (specifically > Darrel> draft-ietf-lisp-00.txt) restricting the placement of xTRs > Darrel> to any particular place in a network's topology. Some > Darrel> placement choices seem to have inherent drawbacks, while > Darrel> others have interesting benefits. >=20 > Darrel> I'm not sure how LISP relates to RANGER, in that none of > Darrel> the LISP drafts seem to reference or discuss coexisting or > Darrel> interacting with RANGER. I'm also not aware of any > Darrel> implementations of RANGER that LISP implementations could > Darrel> or have experimented/interoperated with. >=20 > No, but our charter limits us to LISP as a solution to the global > route scaling problem. In our meeting before the LISP WG at San > Francisco, I stated my interpretation that the broad band use case > falls outside of our charter and those around the table agreed. You > were one of the people there. No fear - we have been prosecuting our case for RANGER in the CPE routers on the v6ops list (and maybe also behave to a more limited extent). Making good headway, and we seem to be popping up on various radar screens. Fred fred.l.templin@boeing.com > So, I do not believe that we're designing LISP to work on broad band > routers. That doesn't mean we should go wrip out parts of LISP that > makes that possible or even that such things are undesirable. It > simply means that "we need that for broad band," is not a > justification within the context of this WG. "That's there for broad > band," may be a statement of historical fact. >=20 > I think the issues surrounding LISP and enterprises are more > complicated. It's not clear to me whether designing LISP to run > behind enterprise firewalls is within our charter or not. I'd ask > people making arguments based on enterprise firewalls to carefully > consider how their argument affects LISP as a solution to the global > route scaling problem. >=20 > Concerns about load balancing in the DFZ clearly are within scope. From dino@cisco.com Wed May 27 14:44:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7163A6CE5 for ; Wed, 27 May 2009 14:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZQEvh2y3cdB for ; Wed, 27 May 2009 14:44:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B117E3A6A31 for ; Wed, 27 May 2009 14:44:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,261,1241395200"; d="scan'208";a="191018887" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 May 2009 21:45:50 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4RLjom9013892; Wed, 27 May 2009 14:45:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4RLjoPJ011334; Wed, 27 May 2009 21:45:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 14:45:50 -0700 Received: from dhcp-171-71-55-144.cisco.com ([171.71.55.144]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 14:45:49 -0700 Message-Id: <26B4A485-E921-48CC-8C4C-3052D0A99E2E@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A1D5A8D.90306@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 14:45:49 -0700 References: <20090527151540.8EC026BE590@mercury.lcs.mit.edu> <4A1D5A8D.90306@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 27 May 2009 21:45:49.0739 (UTC) FILETIME=[800C27B0:01C9DF14] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=439; t=1243460750; x=1244324750; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Comments=20about=20the=20LISP= 20header |Sender:=20; bh=sEJoe+ptPPEdZ3RrUF4CJdC8ntlQ6BG0yIcpsVL3VWY=; b=I67JB2doGYh9Unl4yq5NB+Eos1o3jq++3spDd62WXyGxXyJ/fgeaHz9OzX 5OAKM/Ifhd4d4DXdjm5z7ypIXvzA6+hjA6Bdc7F9YhXeDIoM9D+AdzUTUdTL iG0mSnLSqc; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 21:44:08 -0000 > Conversely, this seems to introduce two design problems > simultaneously. > 1) including a feature we don't know the use for. > 2) Having a header with significant difficulty in changing it, when > we are still experimenting with what needs to be in the header. Well, before anyone suggests this, we are not going to TLV the data header. So we have to live with changes. Or, conversely, don't make any changes. Dino From darlewis@cisco.com Wed May 27 15:04:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857093A6E8D for ; Wed, 27 May 2009 15:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 I9gHzkmGsBFz for ; Wed, 27 May 2009 15:04:35 -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 BAFB23A6E2F for ; Wed, 27 May 2009 15:04:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,261,1241395200"; d="scan'208";a="165019481" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 May 2009 22:06:18 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4RM6ICn012339; Wed, 27 May 2009 15:06:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4RM6IeM021949; Wed, 27 May 2009 22:06:18 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 15:06:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 15:06:17 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: AcnfC6zc6kfIJFsDQPiqEeD73xoh0wACczow References: <4A1D38B7.3020705@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com><4A1D636D.6080005@uclouvain.be><39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A105FC0FE7@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A105FC106E@XCH-NW-7V2.nw.nos.boeing.com> From: "Darrel Lewis (darlewis)" To: "Sam Hartman" X-OriginalArrivalTime: 27 May 2009 22:06:18.0160 (UTC) FILETIME=[5C3E5300:01C9DF17] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1444; t=1243461978; x=1244325978; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20Comments=20about=20the=20LISP= 20header |Sender:=20; bh=PNn7ixRIA4q5KlMrNqtY6vsr8lXDRwut+oYqUIzNQNk=; b=M/lMGL8+MFmDA0Qd8IHT0bqWewA+Yyutxp6Tq5vu8Zwhtir82SZCbLjPAG bD/5btBjQNT3jza0aV5nSsajz6/bVwwr0cJf8eJDXHpxJWN/OI5zBpsDK11q VUruYIpJ3G; Authentication-Results: sj-dkim-2; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Templin, Fred L" , Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 22:04:36 -0000 Sam, > So, I do not believe that we're designing LISP to work on=20 > broad band routers. That doesn't mean we should go wrip out=20 > parts of LISP that makes that possible or even that such=20 > things are undesirable. It simply means that "we need that=20 > for broad band," is not a justification within the context of=20 > this WG. "That's there for broad band," may be a statement=20 > of historical fact. >=20 I was merely stating for the record the reasons LISP designers chose UDP as an encapsulation format. Firewall traversal (due to default/typical policies or inherent capabilities of the FW) and core link aggregation are the two major reasons. > I think the issues surrounding LISP and enterprises are more=20 > complicated. It's not clear to me whether designing LISP to=20 > run behind enterprise firewalls is within our charter or not.=20 > I'd ask people making arguments based on enterprise=20 > firewalls to carefully consider how their argument affects=20 > LISP as a solution to the global route scaling problem. To me, LISP Network Elements' (ITRs and ETRs) location behind or in front of site firewalls is local site decision. There are pro's and cons to both choices. Since in either use case LISP would be removing the need for advertising site PI space into the DFZ (the route scaling problem). So I don't feel its relevant to the charter one way or the other. -Darrel From dino@cisco.com Wed May 27 23:53:56 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B403A6C1C for ; Wed, 27 May 2009 23:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 0TziDrs-faHX for ; Wed, 27 May 2009 23:53:50 -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 3930D3A6C0C for ; Wed, 27 May 2009 23:53:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,263,1241395200"; d="scan'208";a="36388395" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 28 May 2009 06:55:15 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4S6tEOH007844; Wed, 27 May 2009 23:55:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n4S6tEYw018510; Thu, 28 May 2009 06:55:14 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 23:55:14 -0700 Received: from [192.168.1.2] ([10.21.146.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 23:55:14 -0700 Message-Id: <75605CFE-3DF9-4C71-9FA2-FD2D5DECDA8A@cisco.com> From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <4A1D38B3.2020902@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 23:55:13 -0700 References: <4A1D38B3.2020902@uclouvain.be> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 28 May 2009 06:55:14.0298 (UTC) FILETIME=[4074ADA0:01C9DF61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2955; t=1243493714; x=1244357714; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20On=20the=20two=20usages=20of=2 0Map-Requests |Sender:=20; bh=faMqqyswe5r5ShWf+BzwrQK1k8uQzxqKRaXxdiqWR70=; b=O3v6RnbW7oiNc6yob4AYhwEdXLu9S0vPkhtjrdpMVau0xfUW8MgaVMjP3n AfD/XfvN/yR2RXSktnInm/tfUg/SOsYbqVI2yEDFlLf/bKn7wCG6Vbbk6Sr/ L9PsijsbqD; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] On the two usages of Map-Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 06:53:56 -0000 > In the LISP architecture, the mapping system is used for two related > but > different purposes : > > Discovery usage : This is the first usage of the Map-Request messages. > When an ITR needs to send a packet towards an EID for which it does > not > knw any mapping, it will send a mapping request through the mapping > system and will receive a Map-Reply message that provides the mapping > that it can insert in its mapping cache. Right. > Update usage : This is the second usage of Map-Request messages. > Even if > the ITR already knows a mapping for a given EID, it may need to send > Map-Request messages to one or several of the ETRs that are > responsible > for this EID. Typical examples include updating the mapping upon > expiration of the mapping lifetime, verification of the reachability > of > a remote ETR, reaction to reception of a packet containing the SMR bit > set, ... Yes, but if an ITR wants to send a Map-Request as a keepalive or to find more recent mapping, it can do so by sending to the locator address of one of the ETRs. So this doesn't directly use the mapping system. Likewise, SMRs are from ETR to ITR so they too don't use the mapping system directly. > I think that in the discussion about the mapping systems that it would > be useful to distinguish between these two roles of the LISP Map- > Request > messages because there two usages can be potentially different. For > example, Map-Request used for update will likely be more frequent than > Map-Requests used for Discovery, Map-Requests used for update may For the same mapping entry? I don't think that is true, but you may have another more application for it. > include additional information compared to the Map-Request that are > used > for discovery, Map-Requests used for update could have a shorter > retransmission timer than Map-Request used for discovery, ... Another > example is the rate limit imposed on Map-Request. The current draft > recommends : "Map-Requests MUST be rate-limited. It is recommended > that > a Map-Request for the same EID-prefix be sent no more than once per > second." This is an important requirement for Map-Requests that are > used > for discovery. However, Map-Requests that are used for update could > have > a different rate-limit. For example, when sending Map-Requests to > update the mapping of an EID prefix reachable via two RLOCs, then it > could be acceptable to send a Map-Request to both RLOCs at the same > time. I don't know what you mean exactly by using a Map-Request for an update. Do you mean in response to SMRs? If so, the rate-limiting is happening on the SMR source. Dino > > > > Olivier > > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Wed May 27 23:56:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7083A6935 for ; Wed, 27 May 2009 23:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 OcAgHv3tcRFj for ; Wed, 27 May 2009 23:56:19 -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 BBF093A6895 for ; Wed, 27 May 2009 23:56:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,263,1241395200"; d="scan'208";a="191196388" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 May 2009 06:58:01 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4S6w2D0019052; Wed, 27 May 2009 23:58:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4S6w2Za006495; Thu, 28 May 2009 06:58:02 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 23:58:02 -0700 Received: from [192.168.1.2] ([10.21.146.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 23:58:02 -0700 Message-Id: From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <4A1D38B7.3020705@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 23:58:01 -0700 References: <4A1D38B7.3020705@uclouvain.be> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 28 May 2009 06:58:02.0266 (UTC) FILETIME=[A4928FA0:01C9DF61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1229; t=1243493882; x=1244357882; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Comments=20about=20the=20LISP= 20header |Sender:=20; bh=sMVR2R/sWioqae2GW9iP3t4/8loboHGDbGO8o/wrKgM=; b=UA0nVtOJuvWDt5w6OtflcIKrRIbqOHNTm0OGxuMurlu/Lug6z8J8D6Hq+2 4lNRfBriZxxrq56wKiCbnIz9AmQS0AgKEnI1LVBZfyDiuxID//Pf88JnsrOF NUPi9C7TjL; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 06:56:20 -0000 > However, not all fields of the LISP header are useful for both data > and > control packets. For example, the S bit and the loc-reach bits are not > used for Map-Request packets, while there is no utilisation of the > Nonce > for data encapsulated packets in draft-ietf-lisp-00, except for data > probes. This format was chosen to make for ease of parsing by using common code for all cases. And we are leaving it open for some future use of the fields you say aren't used. > We thus have an 8 bytes overhead in all data encapsulated packets > while > currently 32 bits of this header is not used by most data encapsulated > packets. If we have learned from L2TP deployment, ISPs requested that a cookie appear in every data packet for some form of security (weak I might add but it's something). So the nonce in data packets could be used for the same purpose. > It might be useful to consider a different structure for the LISP > header > used in data encapsulated packets and the LISP header used in control > packets or define some utilisation of the Nonce field in all data > encapsulated LISP packets. You have to provide a more compelling reason to change it. Dino From dino@cisco.com Thu May 28 00:06:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5E83A6B76 for ; Thu, 28 May 2009 00:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 JIyp+OuZEmM8 for ; Thu, 28 May 2009 00:06:33 -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 C1E0E3A6A5D for ; Thu, 28 May 2009 00:06:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,263,1241395200"; d="scan'208";a="169833841" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 28 May 2009 07:08:16 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4S78GJA029735; Thu, 28 May 2009 00:08:16 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4S78Gbh016047; Thu, 28 May 2009 07:08:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 May 2009 00:08:16 -0700 Received: from [192.168.1.2] ([10.21.146.19]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 00:08:16 -0700 Message-Id: <9C42EBC1-2B76-4C3E-969B-93D985F2678E@cisco.com> From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 00:08:16 -0700 References: <4A1D38B7.3020705@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> <4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 28 May 2009 07:08:16.0457 (UTC) FILETIME=[12A8AB90:01C9DF63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=508; t=1243494496; x=1244358496; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Comments=20about=20the=20LISP= 20header |Sender:=20; bh=aZE8h2dW2DCT8FEHjqZ0SC40sxB/Q+Y9GmOWC418pOM=; b=flbeLVGQDYkkDAVeFVT4IBHdjDwXsKTajlujxxBdyYu8+MK/unqQQHURnu /6EBlgXqn3g7Np9q0zpeOyK63OfMASt/8Q9PIyLcX5wXzNaW8Q35pDKFDwMZ yvqi4RlxvP; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 07:06:34 -0000 > I have some doubts that this is actually a problem. For > example, ip-proto-41 seems to work fine for 6to4 and others. > ip-proto-4 also for RFC2003 and its kin. GRE also seems to > get through. There will also be no NAT traversal in the > interdomain core. So, I don't see it as unrealistic that > a new IP protocol would get through most paths and could > be easily enabled to get through the other paths. There is one large ISP that says it is a problem. So we should believe them. Dino From Fred.L.Templin@boeing.com Thu May 28 04:53:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9554C3A6D8A for ; Thu, 28 May 2009 04:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.362, 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 wHBJAFRjzX86 for ; Thu, 28 May 2009 04:53:51 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id B1A123A6D09 for ; Thu, 28 May 2009 04:53:51 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4SBt7LS021000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2009 06:55:08 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4SBt7iS003845; Thu, 28 May 2009 04:55:07 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4SBt7bs003840; Thu, 28 May 2009 04:55:07 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 04:55:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 04:55:04 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC13B0@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <9C42EBC1-2B76-4C3E-969B-93D985F2678E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: AcnfYxOYcI3gTajZQP2vtOBh4RBCIwAJ4OaA References: <4A1D38B7.3020705@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> <4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <9C42EBC1-2B76-4C3E-969B-93D985F2678E@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 28 May 2009 11:55:07.0411 (UTC) FILETIME=[252FD630:01C9DF8B] Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 11:53:52 -0000 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Thursday, May 28, 2009 12:08 AM > To: Templin, Fred L > Cc: Olivier.Bonaventure@uclouvain.be; lisp@ietf.org > Subject: Re: [lisp] Comments about the LISP header >=20 > > I have some doubts that this is actually a problem. For > > example, ip-proto-41 seems to work fine for 6to4 and others. > > ip-proto-4 also for RFC2003 and its kin. GRE also seems to > > get through. There will also be no NAT traversal in the > > interdomain core. So, I don't see it as unrealistic that > > a new IP protocol would get through most paths and could > > be easily enabled to get through the other paths. >=20 > There is one large ISP that says it is a problem. So we should believe > them. Maybe so, but we're talking about a fundamental evolution of the Internet architecture here - one that might actually bring about IPv6 transition as a side effect. I would think advocating that ISPs like this begin to transition wouldn't be such an insurmountable order - else, how do new protocols like ip-proto-4, ip-proto-41, GRE, etc. ever get adopted? Fred fred.l.templin@boeing.com=20 =20 > Dino From jnc@mercury.lcs.mit.edu Thu May 28 04:56:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45653A6CB4 for ; Thu, 28 May 2009 04:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 z8WRK-wOK2ZR for ; Thu, 28 May 2009 04:56:52 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1114A3A6967 for ; Thu, 28 May 2009 04:56:51 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 118D36BE59A; Thu, 28 May 2009 07:58:34 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090528115834.118D36BE59A@mercury.lcs.mit.edu> Date: Thu, 28 May 2009 07:58:34 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 11:56:52 -0000 > From: "Templin, Fred L" > we're talking about a fundamental evolution of the Internet > architecture here - one that might actually bring about IPv6 transition > as a side effect. I would think advocating that ISPs like this begin to > transition wouldn't be such an insurmountable order - else, how do new > protocols like ip-proto-4, ip-proto-41, GRE, etc. ever get adopted? We've got enough problems without tilting at extraneous windmills... Noel From Fred.L.Templin@boeing.com Thu May 28 05:02:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830213A6DEB for ; Thu, 28 May 2009 05:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 klcC2RvBIC51 for ; Thu, 28 May 2009 05:02:50 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 8EB833A68DB for ; Thu, 28 May 2009 05:02:33 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4SC486T003273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 May 2009 05:04:14 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4SC48Wx028823; Thu, 28 May 2009 07:04:08 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4SC477P028818; Thu, 28 May 2009 07:04:07 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 05:04:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 05:04:06 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC13B4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090528115834.118D36BE59A@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acnfi6ORTrbzMZ1uQRakdHaZEZcwMgAACWuw References: <20090528115834.118D36BE59A@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 28 May 2009 12:04:07.0734 (UTC) FILETIME=[673E9560:01C9DF8C] Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 12:02:51 -0000 Noel, > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Thursday, May 28, 2009 4:59 AM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] Comments about the LISP header >=20 >=20 > > From: "Templin, Fred L" >=20 > > we're talking about a fundamental evolution of the Internet > > architecture here - one that might actually bring about IPv6 transition > > as a side effect. I would think advocating that ISPs like this begin to > > transition wouldn't be such an insurmountable order - else, how do new > > protocols like ip-proto-4, ip-proto-41, GRE, etc. ever get adopted? >=20 > We've got enough problems without tilting at extraneous windmills... It doesn't have to be done today - this stuff is all going as experimental for now, right? Clearly others have had success socializing a new IP protocol in the past and I don't see why this should be different. 8 bytes per packet is a significant savings. One other point - ICMPs are only required to carry 8 bytes of the packet in error beyond the IP header. That's only enough to pick up the UDP header and not the LISP nonce. Fred fred.l.templin@boeing.com =20 >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Thu May 28 05:53:22 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A423A6E61 for ; Thu, 28 May 2009 05:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kEYY5slDSvk for ; Thu, 28 May 2009 05:53:22 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id E2E723A6E5E for ; Thu, 28 May 2009 05:53:21 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 397DE6BE567; Thu, 28 May 2009 08:54:50 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090528125456.397DE6BE567@mercury.lcs.mit.edu> Date: Thu, 28 May 2009 08:54:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 12:53:22 -0000 > From: "Templin, Fred L" > ICMPs are only required to carry 8 bytes of the packet in error beyond > the IP header. That's only enough to pick up the UDP header and not the > LISP nonce. Which has indeed already proven slightly painful on occasion. But there is no perfect solution, when dealing with a large, installed base. Noel From Fred.L.Templin@boeing.com Thu May 28 06:09:01 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61BDF3A6E08 for ; Thu, 28 May 2009 06:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350, 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 pY-xDNPPoZzh for ; Thu, 28 May 2009 06:09:00 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 8AA663A696C for ; Thu, 28 May 2009 06:09:00 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4SDAZYs014683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 08:10:35 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4SDAY6N004141; Thu, 28 May 2009 06:10:34 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4SDAQ4O003718; Thu, 28 May 2009 06:10:34 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 06:10:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 06:10:31 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC13D5@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090528125456.397DE6BE567@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: Acnfk4icds2af3ExQjyogi/v1KyOSQAAaGmA References: <20090528125456.397DE6BE567@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 28 May 2009 13:10:32.0314 (UTC) FILETIME=[AE3D3DA0:01C9DF95] Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 13:09:01 -0000 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Thursday, May 28, 2009 5:55 AM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] Comments about the LISP header >=20 >=20 > > From: "Templin, Fred L" >=20 > > ICMPs are only required to carry 8 bytes of the packet in error beyond > > the IP header. That's only enough to pick up the UDP header and not the > > LISP nonce. >=20 > Which has indeed already proven slightly painful on occasion. Right. > But there is no perfect solution, when dealing with a large, installed base. Maybe not perfect, but pretty darned close. And it only costs 4 bytes sandwiched between the inner- and outer IP headers. (Hey - it even puts the IPv6 header on a quadword alignment when IPv6 is used as the inner!) Fred fred.l.templin@boeing.com >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Thu May 28 07:11:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168043A6E75 for ; Thu, 28 May 2009 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74r28FnVOrRW for ; Thu, 28 May 2009 07:11:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4E4AE3A6E91 for ; Thu, 28 May 2009 07:11:31 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 39E58415C; Thu, 28 May 2009 10:13:11 -0400 (EDT) To: lisp@ietf.org References: <4A1D38B7.3020705@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0DC5@XCH-NW-7V2.nw.nos.boeing.com> <4A1D636D.6080005@uclouvain.be> <39C363776A4E8C4A94691D2BD9D1C9A105FC0F4F@XCH-NW-7V2.nw.nos.boeing.com> <9C42EBC1-2B76-4C3E-969B-93D985F2678E@cisco.com> From: Sam Hartman Date: Thu, 28 May 2009 10:13:11 -0400 In-Reply-To: <9C42EBC1-2B76-4C3E-969B-93D985F2678E@cisco.com> (Dino Farinacci's message of "Thu\, 28 May 2009 00\:08\:16 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 14:11:54 -0000 >>>>> "Dino" == Dino Farinacci writes: >> I have some doubts that this is actually a problem. For >> example, ip-proto-41 seems to work fine for 6to4 and others. >> ip-proto-4 also for RFC2003 and its kin. GRE also seems to get >> through. There will also be no NAT traversal in the interdomain >> core. So, I don't see it as unrealistic that a new IP protocol >> would get through most paths and could be easily enabled to get >> through the other paths. Dino> There is one large ISP that says it is a problem. So we Dino> should believe them. Speaking as an individual, I have found that more harm than good comes from believing singular unnamed parties who claim that "something is a problem and will choose to discount statements like this in my personal analysis. It's indistinguishable from FUD. I'm not stating a general opinion on UDP encapsulation, simply stating that I personally find this style of argument highly objectionable. My objections do not extend to: * Reasonably complete explanations that hide the identity of a party or network for business reasons * Claims made with sufficient detail they can be independently verified * Surveys of communities where I can evaluate the methodology even if I cannot see the input data From mrw@lilacglade.org Thu May 28 07:37:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23353A6EFA for ; Thu, 28 May 2009 07:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 m5A309GfW341 for ; Thu, 28 May 2009 07:37:26 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 8EE7C28C278 for ; Thu, 28 May 2009 07:36:01 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id x0Mz1b0060b6N64A72dZLv; Thu, 28 May 2009 14:37:33 +0000 Received: from lilac.sandstorm.net ([69.33.111.74]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id x2dJ1b0021cMU3H8P2dMzs; Thu, 28 May 2009 14:37:30 +0000 Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <26B4A485-E921-48CC-8C4C-3052D0A99E2E@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 28 May 2009 10:37:16 -0400 References: <20090527151540.8EC026BE590@mercury.lcs.mit.edu> <4A1D5A8D.90306@joelhalpern.com> <26B4A485-E921-48CC-8C4C-3052D0A99E2E@cisco.com> X-Mailer: Apple Mail (2.930.4) Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 14:37:27 -0000 Hi Dino, On May 27, 2009, at 5:45 PM, Dino Farinacci wrote: >> Conversely, this seems to introduce two design problems >> simultaneously. >> 1) including a feature we don't know the use for. >> 2) Having a header with significant difficulty in changing it, when >> we are still experimenting with what needs to be in the header. > > Well, before anyone suggests this, we are not going to TLV the data > header. So we have to live with changes. Or, conversely, don't make > any changes. I'm not sure who "we" are in the sentence above... The WG could decide to define a TLV-format header if the WG thought there was a good reason to do that. At the moment, though, I don't think that anyone has suggested changing the header to a TLV format. I think that what Joel suggested (indirectly) was that we add a version number to the header. I do think it makes sense to add a version number field to the LISP data header, and to all other LISP headers, so that we will have a well-defined way to change the headers later if that is necessary. This is, IMO, good engineering practice. It would also allow us to remove the overhead of any fields in the LISP data header that have no defined use now, as they could be added in new versions of the header later, if/when we decide that we need them for a defined purpose. The LISP data header is currently fixed-length, so I don't think there is any need for a header length field in this version. A length could be added in a future version, though, if we ever decide to define a variable-length LISP data header. Margaret From Fred.L.Templin@boeing.com Thu May 28 08:09:21 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71FD3A6F14 for ; Thu, 28 May 2009 08:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 EqKfdGyftkk1 for ; Thu, 28 May 2009 08:09:20 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 21BC03A6DCA for ; Thu, 28 May 2009 08:09:20 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4SFAh5a023726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2009 08:10:43 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4SFAhTQ017946; Thu, 28 May 2009 08:10:43 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4SFAgWJ017918; Thu, 28 May 2009 08:10:43 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 08:10:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 08:10:41 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC14BC@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Comments about the LISP header Thread-Index: AcnfohfKxcDIjrS+RqSuCl3uBjiUhAAA/RWQ References: <20090527151540.8EC026BE590@mercury.lcs.mit.edu><4A1D5A8D.90306@joelhalpern.com><26B4A485-E921-48CC-8C4C-3052D0A99E2E@cisco.com> From: "Templin, Fred L" To: "Margaret Wasserman" , "Dino Farinacci" X-OriginalArrivalTime: 28 May 2009 15:10:43.0265 (UTC) FILETIME=[784D0B10:01C9DFA6] Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 15:09:21 -0000 Margaret, > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Thursday, May 28, 2009 7:37 AM > To: Dino Farinacci > Cc: lisp@ietf.org > Subject: Re: [lisp] Comments about the LISP header >=20 >=20 > Hi Dino, >=20 > On May 27, 2009, at 5:45 PM, Dino Farinacci wrote: >=20 > >> Conversely, this seems to introduce two design problems > >> simultaneously. > >> 1) including a feature we don't know the use for. > >> 2) Having a header with significant difficulty in changing it, when > >> we are still experimenting with what needs to be in the header. > > > > Well, before anyone suggests this, we are not going to TLV the data > > header. So we have to live with changes. Or, conversely, don't make > > any changes. >=20 > I'm not sure who "we" are in the sentence above... The WG could > decide to define a TLV-format header if the WG thought there was a > good reason to do that. At the moment, though, I don't think that > anyone has suggested changing the header to a TLV format. I think > that what Joel suggested (indirectly) was that we add a version number > to the header. Sounds reasonable. If we had only 32 bits to work with, how many would we need to encode a version number. Is 2bits enough? Fred fred.l.templin@boeing.com =20 > I do think it makes sense to add a version number field to the LISP > data header, and to all other LISP headers, so that we will have a > well-defined way to change the headers later if that is necessary. > This is, IMO, good engineering practice. It would also allow us to > remove the overhead of any fields in the LISP data header that have no > defined use now, as they could be added in new versions of the header > later, if/when we decide that we need them for a defined purpose. >=20 > The LISP data header is currently fixed-length, so I don't think there > is any need for a header length field in this version. A length > could be added in a future version, though, if we ever decide to > define a variable-length LISP data header. >=20 > Margaret >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Thu May 28 08:15:11 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8983A6B03 for ; Thu, 28 May 2009 08:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 5NAk24-EMQIR for ; Thu, 28 May 2009 08:15: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 1EF7B3A6A36 for ; Thu, 28 May 2009 08:15:10 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3F00C6BE59A; Thu, 28 May 2009 11:16:53 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090528151653.3F00C6BE59A@mercury.lcs.mit.edu> Date: Thu, 28 May 2009 11:16:53 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 15:15:11 -0000 > From: Margaret Wasserman > a well-defined way to change the headers later if that is necessary. I've been thinking _very_ hard, for some years now, about making sure LISP is 'developable' (i.e. it can change and grow in a way that is both reasonably easily interoperable with installed base, but without putting limits on where we can go). Q.v. my big go-round with Sam at charter time about whether or not adding 'hooks' for future enhancements was in-scope. So I am _more_ than sympathetic to your goals. Having said that... > I do think it makes sense to add a version number field to the LISP > data header I'd thought about that, but I think using a different UDP port would do the same thing, and without overhead. If we ever define a LISP-specific data carriage protocol, a version number might be useful there, but such a prototocol is out-of-scope for the WG for the moment (and I see no pressing reason to bring it in-scope). > and to all other LISP headers Again, I'm not sure that a version-number brings us much. There is already an ability to add new control-types, and if we change the syntax on any control message, or add new ones, we can do it that way. And again, there's always the 'different UDP port' technique... Noel From mrw@lilacglade.org Thu May 28 08:44:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E3C3A6E55 for ; Thu, 28 May 2009 08:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 iZ3GSfm4MLE8 for ; Thu, 28 May 2009 08:44:34 -0700 (PDT) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id EF74C28C1B0 for ; Thu, 28 May 2009 08:44:28 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id x31M1b02N0S2fkCAD3mDU7; Thu, 28 May 2009 15:46:13 +0000 Received: from lilac.sandstorm.net ([69.33.111.74]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id x3m01b00h1cMU3H8V3m3Mg; Thu, 28 May 2009 15:46:10 +0000 Message-Id: <6B3CBA65-FD96-4E1A-A257-90DCF4420212@lilacglade.org> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090528151653.3F00C6BE59A@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 v930.4) Date: Thu, 28 May 2009 11:45:59 -0400 References: <20090528151653.3F00C6BE59A@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.930.4) Cc: lisp@ietf.org Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 15:44:35 -0000 On May 28, 2009, at 11:16 AM, Noel Chiappa wrote: >> I do think it makes sense to add a version number field to the LISP >> data header > > I'd thought about that, but I think using a different UDP port would > do the > same thing, and without overhead. I agree that using a different UDP port for extensibility would be better, if that option is available. It has been my understanding, though, that using additional UDP or TCP ports for extensibility is "frowned upon", because of concerns that the TCP/UDP port numbers space is limited. I can't find any actual documentation to that effect, though. So, if we think that using additional UDP ports would be the best extensibility mechanism for LISP (which I could be convinced that it is), I think we should just make a note of that in the spec. > If we ever define a LISP-specific data carriage protocol, a version > number > might be useful there, but such a prototocol is out-of-scope for the > WG for > the moment (and I see no pressing reason to bring it in-scope). > >> and to all other LISP headers > > Again, I'm not sure that a version-number brings us much. There is > already an > ability to add new control-types, and if we change the syntax on any > control > message, or add new ones, we can do it that way. And again, there's > always the > 'different UDP port' technique... I can live with that, assuming we document this as our plan for future modifications/extensibility. Margaret From jnc@mercury.lcs.mit.edu Thu May 28 09:03:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EB428C24D for ; Thu, 28 May 2009 09:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 XPs6Qb+0H3y3 for ; Thu, 28 May 2009 09:03: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 B513E3A69B3 for ; Thu, 28 May 2009 09:03:41 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 80C7B6BE5CD; Thu, 28 May 2009 12:05:22 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090528160522.80C7B6BE5CD@mercury.lcs.mit.edu> Date: Thu, 28 May 2009 12:05:22 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 16:03:42 -0000 > From: Sam Hartman Noel> The _protocol_ mechanism is very simple and cheap. The Noel> algorithms to use it inside the nodes can change over time, Noel> and in a trivially interoperable way. > it sounds like you believe that the protocol bits are simple enough > that we can look at them today? Very close, yes. (I've been thinking about this for a while, since the issue of reachability was flagged as a problem a while back.) There are a couple of _really_ minor technical protocol issues I'd like to think through, so the proposal that comes up is fully baked, but that should only take a few days. > From: "Darrel Lewis (darlewis)" > Link Aggregation schemes for core routers use 5 tuple hashes which > include s-port and d-port fields of udp/tcp protocols. ISP operators > early in the specification processes provided explicit and animated > feedback saying that UDP encapsulation was a critical feature. Indeed; since our goal is to get something actually deployed widely, my take would be 'anything the people who are going to actually deploy it ask for, we should do, if it is at all feasible'. So if there's not a huge technical downside to option A as opposed to B, and the people who are actually going to deploy prefer A, A is what we do... Noel From jnc@mercury.lcs.mit.edu Thu May 28 09:53:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83BB3A6FED for ; Thu, 28 May 2009 09:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 KK7rYsSGY0A2 for ; Thu, 28 May 2009 09:53:51 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 144F03A6DA2 for ; Thu, 28 May 2009 09:53:50 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 65D3A6BE5CD; Thu, 28 May 2009 12:55:27 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090528165527.65D3A6BE5CD@mercury.lcs.mit.edu> Date: Thu, 28 May 2009 12:55:27 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments about the LISP header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 16:53:51 -0000 > From: Margaret Wasserman > if we think that using additional UDP ports would be the best > extensibility mechanism for LISP (which I could be convinced that it > is), I think we should just make a note of that in the spec. I'm not sure it's wise to go quite that far. See, I think exactly what we do in the future, if we need to make changes, will depend a lot on what the situation is. E.g. if LISP does not catch on, not a problem, there is no need to worry about it! :-) And if all the ISPs are using it, maybe a new data-handling protocol would be better. Etc, etc. But I have no idea what the detailed future will look like, so I don't know how the various factors will weigh in together. How about we just recognize that there are a number of potential ways to handle that issue, and it's not necessarily possible to say now which will be best then, and then place it down for the moment? Less is more... :-) Noel From vaf@cisco.com Thu May 28 11:08:32 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF313A6D2E for ; Thu, 28 May 2009 11:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 tNIs9-XJs2d9 for ; Thu, 28 May 2009 11:08:30 -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 B68263A6C5C for ; Thu, 28 May 2009 11:08:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,266,1241395200"; d="scan'208";a="191505974" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 May 2009 18:10:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4SIAAZl003013; Thu, 28 May 2009 11:10:10 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4SIAAuu023171; Thu, 28 May 2009 18:10:10 GMT Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [127.0.0.1]) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Debian-4) with ESMTP id n4SI75WC007883; Thu, 28 May 2009 11:07:05 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n4SI75cT007880; Thu, 28 May 2009 11:07:05 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Thu, 28 May 2009 11:07:05 -0700 From: Vince Fuller To: Noel Chiappa Message-ID: <20090528180704.GA7799@vaf-lnx1> References: <20090526222057.57F7F6BE624@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090526222057.57F7F6BE624@mercury.lcs.mit.edu> User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1115; t=1243534210; x=1244398210; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Re=3A=20[lisp]=20I-D=20Action=3Adraft-ietf-lisp -alt-00.txt |Sender:=20; bh=AGlTFUrF2/D8TN3inzxPXFJfywWwWPkZrokyEy4Dr4I=; b=fvu5sZRSeV5/93EvpTDAvFOemX6BV76HfLmX6e77znrCl8KGQO7n592oiD LkTliSwfSy3vz43MV+s9jc45Eln9Mo/H6x5z7PG+hGN8ej6QhauzYU9jVSyf LvvwAbagVq; Authentication-Results: sj-dkim-3; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] I-D Action:draft-ietf-lisp-alt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 18:08:32 -0000 On Tue, May 26, 2009 at 06:20:57PM -0400, Noel Chiappa wrote: > > From: Internet-Drafts@ietf.org > > > "This document describes a method of building an alternative, logical > > topology for managing Endpoint Identifier to Routing Locator mappings > > using the Locator/ID Separation Protocol." > > This strikes me as a non-optimal description of what LISP-ALT is. What it is > is a _mapping subsystem_ - but that's not all all obvious from this first > sentence. (The rest of the abstract is fine.) > > How about something like: > > "This document describes a subsystem for providing Endpoint Identifier > to Routing Locator mappings for the Locator/ID Separation Protocol. > It does this by building an alternative, logical topology which is used > for both announcing the availability of EID to RLOC mappings, and > forwarding requests for those mappings to an entity which is authoritative > for them." > > Only slightly longer, but much more informative, I think. Looks reasonable to me. I'll incorporate the revised text into the -02 draft. --Vince From dino@cisco.com Thu May 28 11:09:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C733A6B63 for ; Thu, 28 May 2009 11:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 388dzuHdRL0x for ; Thu, 28 May 2009 11:09:45 -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 44CF83A68A0 for ; Thu, 28 May 2009 11:09:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,266,1241395200"; d="scan'208";a="312442578" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 28 May 2009 18:11:24 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4SIBOAo015226 for ; Thu, 28 May 2009 11:11:24 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4SIBOok024586 for ; Thu, 28 May 2009 18:11:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 May 2009 11:11:24 -0700 Received: from [192.168.1.2] ([10.21.146.19]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 11:11:24 -0700 Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 11:11:23 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 28 May 2009 18:11:24.0514 (UTC) FILETIME=[B6305C20:01C9DFBF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1081; t=1243534284; x=1244398284; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Can=20I=20get=20opinions? |Sender:=20; bh=Mmh31NHw82ObQqNUPHJxYfQme7HUX6xSwCbdFtthF48=; b=HHUCUGwaTH9j8hquBKK+PbiVo43zOdURYmpAavoCVuBnMma49BOrdZg7ir TtNvD67iBy2iMAexjX2zy+lAJxJ1Fz4Dwgdxy91dBzT1dUJ9JYdSChNHuEov 5eUEt7FLMvhHNXy/5eUHyJJTLynAvbd7WNVpy1sJD8lVyVmZkJmHk=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 18:09:52 -0000 Since the list has brought up packet formats, I would like to suggest this packet format change for draft-ietf-lisp-02.txt (about to release draft-ietf-lisp-01.txt): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L / | Locator Reach Bits | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S \ |S|E|rsvd-flags | Nonce | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The E-bit is for the echo-nonce idea that Andrew Partan and Noel Chiappa came up with. We will document it relatively soon. I'm doing an implementation of it right now to see how it works. What we get from the previous version: 1) 32 loc-reach-bits rather than 31. 2) Set aside flag bits for future use. 3) Settling for a 24-bit nonce rather than a 32-bit nonce. But this is only in the data packet header and not in the nonce that is carried in UDP port 4342. That nonce remains at 32 bits. Comments? Dino From vaf@cisco.com Thu May 28 11:14:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080403A6E3A for ; Thu, 28 May 2009 11:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxHzuaiKXoz1 for ; Thu, 28 May 2009 11:14:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 63A5E3A6FDB for ; Thu, 28 May 2009 11:14:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,266,1241395200"; d="scan'208";a="191509391" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 May 2009 18:15:44 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4SIFiRq007097; Thu, 28 May 2009 11:15:44 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n4SIFhNS017366; Thu, 28 May 2009 18:15:43 GMT Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [127.0.0.1]) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Debian-4) with ESMTP id n4SICdIW008230; Thu, 28 May 2009 11:12:39 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n4SICdOB008227; Thu, 28 May 2009 11:12:39 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Thu, 28 May 2009 11:12:39 -0700 From: Vince Fuller To: HeinerHummel@aol.com Message-ID: <20090528181239.GB7799@vaf-lnx1> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=867; t=1243534544; x=1244398544; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Re=3A=20[lisp]=20I-D=20Action=3Adraft-ietf-lisp -alt-00.txt |Sender:=20; bh=31e7wjHay2HLsxyqdtpGpr2kBmCE8kEk622pCTfEnqA=; b=fli+TCl0gdRyqh9WPOwTeDo3ogZZszHn1f8l2JIIe4G4/srJVGrhpclK94 jhzUFKLEk2boS1YGEdhg+P10rGiwk6+2T9sv8Y/1vl18YhJM6ARWZllxXf/8 bzlX4NmL9K; Authentication-Results: sj-dkim-2; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] I-D Action:draft-ietf-lisp-alt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 18:14:26 -0000 On Wed, May 27, 2009 at 04:57:33AM -0400, HeinerHummel@aol.com wrote: > > A minor comment wrt alternative logical topology: > > Newcomers won't understand, why "alternative" is part of the name.While I > prefer to keep the name ALT, it wouldn't be bad to give some > explanation/excusion at the beginning. "Alternative Logical Topology" is used to distinguish the LISP+ALT infrastructure from existing, BGP-based global routing system. I would think that the normative reference to BGP-4 in the LISP+ALT document should make it clear that familiarity with the BGP-based global routing system is a prerequisite for understanding it. Does the list believe that the document needs a more explicit reference to writings about the BGP-based global routing topology? Any suggestions for an appropriate URL beyond the BGP-4 protocol spec? --Vince From HeinerHummel@aol.com Thu May 28 11:35:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3465B3A6AD7 for ; Thu, 28 May 2009 11:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD6zEM48T3mN for ; Thu, 28 May 2009 11:35:25 -0700 (PDT) Received: from imr-m06.mx.aol.com (imr-m06.mx.aol.com [64.12.138.200]) by core3.amsl.com (Postfix) with ESMTP id 50F3F3A6CF7 for ; Thu, 28 May 2009 11:35:25 -0700 (PDT) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-m06.mx.aol.com (v107.10) with ESMTP id RELAYIN1-24a1ed9b3340; Thu, 28 May 2009 14:36:35 -0400 Received: from HeinerHummel@aol.com by imo-ma03.mx.aol.com (mail_out_v40_r1.5.) id c.d3a.436c598f (65097); Thu, 28 May 2009 14:36:27 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 28 May 2009 14:36:27 EDT To: vaf@cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1243535787" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 64.12.78.138 Cc: lisp@ietf.org Subject: Re: [lisp] I-D Action:draft-ietf-lisp-alt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 18:35:26 -0000 -------------------------------1243535787 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 28.05.2009 20:16:01 Westeurop=E4ische Normalzeit schrei= bt vaf@cisco.com: On Wed, May 27, 2009 at 04:57:33AM -0400, HeinerHummel@aol.com wrote: > > A minor comment wrt alternative logical topology: > > Newcomers won't understand, why "alternative" is part of the name.While= I > prefer to keep the name ALT, it wouldn't be bad to give some > explanation/excusion at the beginning. "Alternative Logical Topology" is used to distinguish the LISP+ALT infrastructure from existing, BGP-based global routing system. I would think that the normative reference to BGP-4 in the LISP+ALT document should make it clear that familiarity with the BGP-based global routing system is a prerequisite for understanding it. Does the list believe that the document needs a more explicit reference= to writings about the BGP-based global routing topology? Any suggestions for= an appropriate URL beyond the BGP-4 protocol spec? --Vince Really? I thought LISP/ALT were the alternative to LISP/CONS. Heiner -------------------------------1243535787 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 28.05.2009 20:16:01 Westeurop=E4ische Normalzeit= schreibt vaf@cisco.com:
On Wed, May 27, 2009 at 04:57:33AM -0400, HeinerHummel@aol.com wrote:
> > A minor comment wrt alternative logical topology:
>
> Newco= mers won't understand, why "alternative" is part of the name.While I
>= prefer to keep the name ALT, it wouldn't be bad to give some
> explanation/excusion at the beginning.

"Alternative Logical Topol= ogy" is used to distinguish the LISP+ALT
infrastructure from existing, BGP= -based global routing system.

I would think that the normative reference= to BGP-4 in the LISP+ALT document
should make it clear that familiarity= with the BGP-based global routing
system is a prerequisite for understandi= ng it.

Does the list believe that the document needs a more explicit= reference to
writings about the BGP-based global routing topology? An= y suggestions for an
appropriate URL beyond the BGP-4 protocol spec?

    --Vince
Really? I thought LISP/ALT were the alternative to LISP/CONS.
Heiner
 -------------------------------1243535787-- From menth@informatik.uni-wuerzburg.de Thu May 28 11:41:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0556C3A68D4 for ; Thu, 28 May 2009 11:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWaTOMGz3C8w for ; Thu, 28 May 2009 11:41:45 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 613743A692D for ; Thu, 28 May 2009 11:41:04 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id EA970A07AC; Thu, 28 May 2009 20:42:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DDCA5A07AB; Thu, 28 May 2009 20:42:46 +0200 (CEST) Received: from [192.168.1.2] (f050243136.adsl.alicedsl.de [78.50.243.136]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A45CEA06E8; Thu, 28 May 2009 20:42:46 +0200 (CEST) Message-ID: <4A1EDB27.1090206@informatik.uni-wuerzburg.de> Date: Thu, 28 May 2009 20:42:47 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Vince Fuller References: <20090528181239.GB7799@vaf-lnx1> In-Reply-To: <20090528181239.GB7799@vaf-lnx1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: lisp@ietf.org Subject: Re: [lisp] I-D Action:draft-ietf-lisp-alt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 18:41:51 -0000 Hi Vince, I find it good style if important names are motivated. Telling the reader that "alternative" in ALT is understood with respect to the existing BGP topology clarifies the matter. Otherwise, readers can only guess, also if they know about BGP. For instance, in the PCN WG we have motivated the name PCN in the first paragraph of the introduction: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-11.txt This information does not harm and helps newcomers to get familiar with the name PCN. Regards, Michael Vince Fuller schrieb: > On Wed, May 27, 2009 at 04:57:33AM -0400, HeinerHummel@aol.com wrote: > >> A minor comment wrt alternative logical topology: >> >> Newcomers won't understand, why "alternative" is part of the name.While I >> prefer to keep the name ALT, it wouldn't be bad to give some >> explanation/excusion at the beginning. >> > > "Alternative Logical Topology" is used to distinguish the LISP+ALT > infrastructure from existing, BGP-based global routing system. > > I would think that the normative reference to BGP-4 in the LISP+ALT document > should make it clear that familiarity with the BGP-based global routing > system is a prerequisite for understanding it. > > Does the list believe that the document needs a more explicit reference to > writings about the BGP-based global routing topology? Any suggestions for an > appropriate URL beyond the BGP-4 protocol spec? > > --Vince > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/8888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From dmm@1-4-5.net Thu May 28 12:04:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D973A6FA2 for ; Thu, 28 May 2009 12:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQF-VIusSXJw for ; Thu, 28 May 2009 12:04:39 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id BDB1E28C328 for ; Thu, 28 May 2009 12:03:03 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n4SJ4dfX005012; Thu, 28 May 2009 12:04:39 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n4SJ4d9D005011; Thu, 28 May 2009 12:04:39 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 28 May 2009 12:04:39 -0700 From: David Meyer To: HeinerHummel@aol.com Message-ID: <20090528190439.GA4977@1-4-5.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: Re: [lisp] I-D Action:draft-ietf-lisp-alt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 19:04:40 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Heiner, > Really? I thought LISP/ALT were the alternative to LISP/CONS. LISP+ALT is just one of many designs that have been explored. In that sense its an alternative "design". Dave --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoe4EcACgkQORgD1qCZ2Kc9mwCbBBi8qLPFRI/hg2LxWiR7DJtT ycsAn3/wlmwh0+FvCj6RbmxQPhCf6d6H =/0FA -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From jmh@joelhalpern.com Thu May 28 12:54:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBB43A6C8C for ; Thu, 28 May 2009 12:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Vix77mmNUjp for ; Thu, 28 May 2009 12:54:38 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5F3453A6BFF for ; Thu, 28 May 2009 12:54:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0A3F443401B; Thu, 28 May 2009 12:56:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 69CC3434017; Thu, 28 May 2009 12:56:21 -0700 (PDT) Message-ID: <4A1EEC62.5080102@joelhalpern.com> Date: Thu, 28 May 2009 15:56:18 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dino Farinacci References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 19:54:39 -0000 Looks like an improvement to me. Joel Dino Farinacci wrote: > Since the list has brought up packet formats, I would like to suggest > this packet format change for draft-ietf-lisp-02.txt (about to release > draft-ietf-lisp-01.txt): > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > L / | Locator Reach Bits | > I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > S \ |S|E|rsvd-flags | Nonce | > P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The E-bit is for the echo-nonce idea that Andrew Partan and Noel Chiappa > came up with. We will document it relatively soon. I'm doing an > implementation of it right now to see how it works. > > What we get from the previous version: > > 1) 32 loc-reach-bits rather than 31. > 2) Set aside flag bits for future use. > 3) Settling for a 24-bit nonce rather than a 32-bit nonce. But this is > only in the data packet header and not in the nonce that is carried in > UDP port 4342. That nonce remains at 32 bits. > > Comments? > > Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Thu May 28 13:03:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537D13A6DE0 for ; Thu, 28 May 2009 13:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Igi95T9+pJI for ; Thu, 28 May 2009 13:03: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 A6AB13A6C46 for ; Thu, 28 May 2009 13:03:15 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 85CDB6BE54F; Thu, 28 May 2009 16:04:51 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> Date: Thu, 28 May 2009 16:04:51 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 20:03:16 -0000 > From: "Joel M. Halpern" > Looks like an improvement to me. I expect that Dino was particularly concerned that a change of this sort might present a problem for someone who's already implementing stuff, so if there's anyone in that boat, it would be important to hear from them while this is still being tossed around as an idea. Noel From damien.saucez@uclouvain.be Thu May 28 13:10:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5B53A6F7D for ; Thu, 28 May 2009 13:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+lm2NRr-VuB for ; Thu, 28 May 2009 13:10:32 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 332133A6F42 for ; Thu, 28 May 2009 13:10:32 -0700 (PDT) Received: from mimir2.dhcp.info.ucl.ac.be (unknown [88.197.225.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 31745EB586; Thu, 28 May 2009 22:12:11 +0200 (CEST) Message-ID: <4A1EF019.6000505@uclouvain.be> Date: Thu, 28 May 2009 22:12:09 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Noel Chiappa References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> In-Reply-To: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 31745EB586.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 20:10:38 -0000 looks better. As we are talking about changing the header, it would be the perfect time to discuss versioning again, isn't it? Or at least to discuss on the mailing list what we would really see in the headers. Noel, I think that functionalities in the protocol are more important than implementation issues. I hope we will not limit the changes in the protocol just because of "legacy" code. Damien Saucez Noel Chiappa wrote: > > From: "Joel M. Halpern" > > > Looks like an improvement to me. > > I expect that Dino was particularly concerned that a change of this sort > might present a problem for someone who's already implementing stuff, so if > there's anyone in that boat, it would be important to hear from them while > this is still being tossed around as an idea. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Thu May 28 13:23:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F400F3A6D93 for ; Thu, 28 May 2009 13:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 BlkCLbVyuZbL for ; Thu, 28 May 2009 13:23:51 -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 36C4E3A6BA1 for ; Thu, 28 May 2009 13:23:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,267,1241395200"; d="scan'208";a="170143839" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 28 May 2009 20:25:33 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4SKPYK2006763; Thu, 28 May 2009 13:25:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4SKPYbj013461; Thu, 28 May 2009 20:25:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 13:25:34 -0700 Received: from [192.168.1.218] ([10.21.147.66]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 13:25:33 -0700 Message-Id: <93D735CB-36E8-42C4-8880-0EC666DE2B16@cisco.com> From: Dino Farinacci To: Damien Saucez In-Reply-To: <4A1EF019.6000505@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 13:25:33 -0700 References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1EF019.6000505@uclouvain.be> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 28 May 2009 20:25:34.0066 (UTC) FILETIME=[74188520:01C9DFD2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1222; t=1243542334; x=1244406334; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Can=20I=20get=20opinions? |Sender:=20; bh=5wfUaBEIojnBdO3HKVxcqB+JID+NIF/VY9nS2OD3eMA=; b=e7rBghhVroB8OjKnPlwhT/aSJdD3URHVGO/OZINn0SmODIrbNMNHEEhItF 3T1GYdLUsVFiswg6Ooo/PpEZ1MOxSLr6eeAK3OcBRlRZ+cQyZpUKQj7lc5R0 gaeRygB26MXJqvfbhNtDohpLOIxClOGhgwXb6A4W2A1BF0F+ekDhY=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 20:23:52 -0000 > looks better. > > As we are talking about changing the header, it would be the perfect > time to discuss versioning again, isn't it? Or at least to discuss > on the mailing list what we would really see in the headers. Well, that is a big change. ;-) Dino > Noel, I think that functionalities in the protocol are more > important than implementation issues. I hope we will not limit the > changes in the protocol just because of "legacy" code. > > Damien Saucez > > Noel Chiappa wrote: >> > From: "Joel M. Halpern" >> >> > Looks like an improvement to me. >> >> I expect that Dino was particularly concerned that a change of this >> sort >> might present a problem for someone who's already implementing >> stuff, so if >> there's anyone in that boat, it would be important to hear from >> them while >> this is still being tossed around as an idea. >> >> 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 luigi@net.t-labs.tu-berlin.de Thu May 28 13:36:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D96D3A696C for ; Thu, 28 May 2009 13:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGs2j1U7exD0 for ; Thu, 28 May 2009 13:36:45 -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 8AAB23A6A7D for ; Thu, 28 May 2009 13:36:45 -0700 (PDT) Received: from [192.168.2.101] (p4FC24BAF.dip.t-dialin.net [79.194.75.175]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id E1BC1708EBA5; Thu, 28 May 2009 22:38:25 +0200 (CEST) Message-Id: <512C9404-BB44-4732-8655-5C2BBECAB963@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Damien Saucez In-Reply-To: <4A1EF019.6000505@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 22:38:25 +0200 References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1EF019.6000505@uclouvain.be> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 20:36:52 -0000 On May 28, 2009, at 22:12 , Damien Saucez wrote: > looks better. > > As we are talking about changing the header, it would be the perfect > time to discuss versioning again, isn't it? Or at least to discuss > on the mailing list what we would really see in the headers. > > Noel, I think that functionalities in the protocol are more > important than implementation issues. I hope we will not limit the > changes in the protocol just because of "legacy" code. > On this I totally agree with Damien. Even if we struggle in keeping the pace of the official LISP dev team (and we are getting closer ;-) ), this is the time to introduce (deep) changes for the sake of a better protocol, not the time to be conservative on legacy code. From my point of view (and I already pointed out this to Dino in some mails exchanged while talking about versioning) radical changes are not a big deal now. If it is worth.. the sooner the better ;-) Luigi > Damien Saucez > > Noel Chiappa wrote: >> > From: "Joel M. Halpern" >> >> > Looks like an improvement to me. >> >> I expect that Dino was particularly concerned that a change of this >> sort >> might present a problem for someone who's already implementing >> stuff, so if >> there's anyone in that boat, it would be important to hear from >> them while >> this is still being tossed around as an idea. >> >> 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 vaf@cisco.com Thu May 28 13:41:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90343A6D68 for ; Thu, 28 May 2009 13:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZAsvfbQe1to for ; Thu, 28 May 2009 13:41:18 -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 59FCD3A6964 for ; Thu, 28 May 2009 13:40:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,267,1241395200"; d="scan'208";a="312536863" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 May 2009 20:42:39 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4SKgd05009460 for ; Thu, 28 May 2009 13:42:39 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4SKgd4G029197 for ; Thu, 28 May 2009 20:42:39 GMT Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [127.0.0.1]) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Debian-4) with ESMTP id n4SKdZB4018604 for ; Thu, 28 May 2009 13:39:35 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n4SKdYMW018601 for lisp@ietf.org; Thu, 28 May 2009 13:39:34 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Resent-From: Vince Fuller Resent-Date: Thu, 28 May 2009 13:39:34 -0700 Resent-Message-ID: <20090528203934.GA18228@vaf-lnx1> Resent-To: lisp@ietf.org Date: Thu, 28 May 2009 13:35:28 -0700 From: Vince Fuller To: Michael Menth Message-ID: <20090528203528.GA17654@vaf-lnx1> References: <20090528181239.GB7799@vaf-lnx1> <4A1EDB27.1090206@informatik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1EDB27.1090206@informatik.uni-wuerzburg.de> User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1025; t=1243543359; x=1244407359; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Re=3A=20[lisp]=20I-D=20Action=3Adraft-ietf-lisp -alt-00.txt |Sender:=20; bh=OQijmSOneUKUpJIfEKwLudtdTh3VCSQyaOTXfmHJiDc=; b=DdrnhhDO7hgjAD5eTsljjDDdlUlDuIQUkyhmJ32I+lzABZsC+SxKCxXNYX n6/VcFUiFjWj0vPPaydO9L/tyMG2s54WmJI3H4Lung8UT/3HyKz2JSRDTEnu Upt0NlGnVy; Authentication-Results: sj-dkim-4; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] I-D Action:draft-ietf-lisp-alt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 20:41:26 -0000 On Thu, May 28, 2009 at 08:42:47PM +0200, Michael Menth wrote: > Hi Vince, > > I find it good style if important names are motivated. Telling the > reader that "alternative" in ALT is understood with respect to the > existing BGP topology clarifies the matter. Otherwise, readers can only > guess, also if they know about BGP. > > For instance, in the PCN WG we have motivated the name PCN in the first > paragraph of the introduction: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-11.txt > This information does not harm and helps newcomers to get familiar with > the name PCN. OK, I will add text in the Introduction section to more explicitly define that "Alternative Logical Topology" is to distinguish between the LISP+ALT infrastructure and the BGP-based global routing system. I'll include this change with others pending for the -02 draft, which I plan to publish in a week or two, depending on how many other suggested changes are received. Thanks, --Vince From jnc@mercury.lcs.mit.edu Thu May 28 13:44:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE243A6E18 for ; Thu, 28 May 2009 13:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 AxzoMavGjO4J for ; Thu, 28 May 2009 13:44:03 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 5B9D43A69F6 for ; Thu, 28 May 2009 13:44:03 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B2C926BE5CD; Thu, 28 May 2009 16:45:45 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090528204545.B2C926BE5CD@mercury.lcs.mit.edu> Date: Thu, 28 May 2009 16:45:45 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 20:44:08 -0000 > From: Damien Saucez > As we are talking about changing the header, it would be the perfect > time to discuss versioning again, isn't it? On this particular point, I don't see that anything has changed from my prior analysis to Margaret - we have a number of ways to make a change (if the need for one arises), and to try and chose one now would be to make a choice with limited data. > discuss on the mailing list what we would really see in the headers. This I can see. Did you have any particular thoughts/suggestions? (I have one from Olivier in my overflowing emailbox, which I have yet to respond to... :-) > I think that functionalities in the protocol are more important than > implementation issues. On this we sort of agree, because this whole 'make changes' issue is something I have been musing about recently. Here are a few things I said to the LISP authors recently: Right now we're in a place where we can do 'flag days' - just change stuff around. Once we have an installed base, we can't do that any more, we have to go the 'interoperable' route. However, more protocols have died through freezing too soon than just about anything else. (Tuba, etc, etc.) Look at the early history of IP - the incompatible changes from 'IP'v2 to IPv2.5 to IPv3 were very significant - and that effort was dealing with a _lot_ more installed test base, and many more implementations and implementors. It was that willingness to keep changing things _for a long time into the early life of the protocol_ that is a large part of IPv4's success. So I am very much in sympathy with your basic thought. However... LISP has been around for a couple of years now, and people out in the world are starting to wake up to it. The ability to add an additional binding layer is something that a lot of people are very interested in. What that means is that there is now an open 'window of opportunity' to get LISP actually deployed and into significant use, and in my opinion we should _not_ take a chance on throwing away that window, by tinkering for an extended period of time. > I hope we will not limit the changes in the protocol just because of > "legacy" code. As far as I know, right at the moment there is no significant 'legacy code base' to worry about. The list of implementations (that I know of) is fairly short. Noel From Fred.L.Templin@boeing.com Thu May 28 14:13:05 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A493A6D85 for ; Thu, 28 May 2009 14:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.257 X-Spam-Level: X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 HpWwo1uaXbOg for ; Thu, 28 May 2009 14:13:05 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 082563A6EE7 for ; Thu, 28 May 2009 14:13:04 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4SLEeg2011741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 14:14:41 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4SLEetD028877; Thu, 28 May 2009 14:14:40 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4SLEasq028745; Thu, 28 May 2009 14:14:40 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 14:14:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 14:14:38 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC17FC@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Can I get opinions? Thread-Index: AcnfwF1KY4v2okTRTC6VkQKNnZFGKQAFqI6A References: From: "Templin, Fred L" To: "Dino Farinacci" , X-OriginalArrivalTime: 28 May 2009 21:14:39.0903 (UTC) FILETIME=[4FF392F0:01C9DFD9] Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 21:13:05 -0000 OK, so here is something like what I would propose for SEAL: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER|A|R| RSVD | Next Header | ID Extension | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where VER=3D0 means that there is no segmentation and reassembly capability, and VER=3D1 means that segmentation and reassembly are implemented. (VER=3D2,3 are reserved for future use.) When VER=3D0, the ITR sets the 'A' bit to request an explicit acknowledgement from the ETR, and sets the 'R' bit to permit the ETR to report fragmentation. When VER=3D1, the 'RSVD' bits are redefined to support the segmentation and reassembly capability. LISP xTRs connected to the DFZ would set VER=3D0. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Thursday, May 28, 2009 11:11 AM > To: lisp@ietf.org > Subject: [lisp] Can I get opinions? >=20 > Since the list has brought up packet formats, I would like to suggest > this packet format change for draft-ietf-lisp-02.txt (about to release > draft-ietf-lisp-01.txt): >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > L / | Locator Reach Bits | > I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > S \ |S|E|rsvd-flags | Nonce | > P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The E-bit is for the echo-nonce idea that Andrew Partan and Noel > Chiappa came up with. We will document it relatively soon. I'm doing > an implementation of it right now to see how it works. >=20 > What we get from the previous version: >=20 > 1) 32 loc-reach-bits rather than 31. > 2) Set aside flag bits for future use. > 3) Settling for a 24-bit nonce rather than a 32-bit nonce. But this is > only in the data packet header and not in the nonce that is carried in > UDP port 4342. That nonce remains at 32 bits. >=20 > Comments? >=20 > Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Thu May 28 14:32:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D89A3A689B for ; Thu, 28 May 2009 14:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHRHrD-zxJcp for ; Thu, 28 May 2009 14:32:32 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id D89523A68E3 for ; Thu, 28 May 2009 14:32:26 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 30DBE415C; Thu, 28 May 2009 17:34:06 -0400 (EDT) To: Luigi Iannone References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1EF019.6000505@uclouvain.be> <512C9404-BB44-4732-8655-5C2BBECAB963@net.t-labs.tu-berlin.de> From: Sam Hartman Date: Thu, 28 May 2009 17:34:06 -0400 In-Reply-To: <512C9404-BB44-4732-8655-5C2BBECAB963@net.t-labs.tu-berlin.de> (Luigi Iannone's message of "Thu\, 28 May 2009 22\:38\:25 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 28 May 2009 21:32:37 -0000 By versioning, are we talking about the sort of versioning that Margaret discussed today, or are we talking about versioning of map entries as discussed at the last IETF? From damian.lezama@hotmail.com Thu May 28 21:49:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBC43A6E2E for ; Thu, 28 May 2009 21:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, 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 ZYIVxZBauz5U for ; Thu, 28 May 2009 21:49:24 -0700 (PDT) Received: from col0-omc2-s3.col0.hotmail.com (col0-omc2-s3.col0.hotmail.com [65.55.34.77]) by core3.amsl.com (Postfix) with ESMTP id 93FC73A6A3C for ; Thu, 28 May 2009 21:49:24 -0700 (PDT) Received: from COL110-DS22 ([65.55.34.73]) by col0-omc2-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 21:51:08 -0700 X-Originating-IP: [24.87.27.71] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: "'Noel Chiappa'" , References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> In-Reply-To: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> Date: Thu, 28 May 2009 21:51:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acnfz5UhJ0lmwRUWRf+gXKEwj3FCtAARKJxg Content-Language: en-us X-OriginalArrivalTime: 29 May 2009 04:51:08.0432 (UTC) FILETIME=[14C97100:01C9E019] Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 04:49:26 -0000 Hi, We have a prototype implementation. I strongly agree that it's a non sense restricting LISP progress because of current code at this point... That said, I noticed that now we have a different header for control and data packets. And I think this is an inconsistency in the draft: "the R-bit for each locator must have a consistent setting with the bitfield setting of the 'Loc Reach Bits' field in the early part of the header" Because it looks like reach bits are not being used in control messages anymore (set to 0 always since draft 11). What makes me think that the first 4 bytes of the control messages are never used, and now the header is already different, so I think maybe the draft should be updated accordingly (mark as unused or figure out something to put there:). BTW: which is the max number of locators allowed in a record? We considered it 31 (because of 31 reachability bits). Should we consider 32 as limit now? Shouldn't it be explicit in the draft? (is it there but I missed it?) Regards, Damian > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of > Noel Chiappa > Sent: Thursday, May 28, 2009 1:05 PM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] Can I get opinions? > > > From: "Joel M. Halpern" > > > Looks like an improvement to me. > > I expect that Dino was particularly concerned that a change of this > sort > might present a problem for someone who's already implementing stuff, > so if > there's anyone in that boat, it would be important to hear from them > while > this is still being tossed around as an idea. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Thu May 28 21:49:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AA83A6E41 for ; Thu, 28 May 2009 21:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mKMkDCVT73l for ; Thu, 28 May 2009 21:49:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6D7403A6E3A for ; Thu, 28 May 2009 21:49:34 -0700 (PDT) X-Files: rfcdiff-lisp-00-01.html, rfcdiff-lisp-multicast-00-01.html : 132012, 66060 X-IronPort-AV: E=Sophos;i="4.41,269,1241395200"; d="html'217?scan'217,208,217";a="312752738" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 May 2009 04:51:18 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4T4pIjD025798 for ; Thu, 28 May 2009 21:51:18 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4T4pIRM028053 for ; Fri, 29 May 2009 04:51:18 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 May 2009 21:51:17 -0700 Received: from [192.168.1.2] ([10.21.68.193]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 21:51:17 -0700 Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-92--1022495991 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 21:51:16 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 May 2009 04:51:17.0483 (UTC) FILETIME=[1A2E83B0:01C9E019] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=202788; t=1243572678; x=1244436678; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20New=20ID=20updates |Sender:=20; bh=3GD3ZvceWIrXY1B5pm+LnwaNQ8glzzB9Gfka76nzwTM=; b=pBhW758YWo2VbJ7aCSCiMTmtpWelwKmKYKUpIyEshZ6HACmgsHhWmO681U MpHhG/MEVsct5Wqjr7xbHg+GUk+R2eN60h7TPALWPQv5re1bAO/qQ/qniRDn IjWQmPmvJJ; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [lisp] New ID updates X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 04:49:51 -0000 --Apple-Mail-92--1022495991 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I just posted draft-ietf-lisp-01.txt and draft-ietf-lisp- multicast-01.txt. You can find the html-based diffs attached. Thanks, Dino --Apple-Mail-92--1022495991 Content-Disposition: attachment; filename=rfcdiff-lisp-00-01.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-00-01.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-00.txt draft-ietf-lisp-01.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: November 27, 29, 2009                                      D. Lewis
                                                           cisco Systems
                                                            May 26, 28, 2009

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-00.txt
                         draft-ietf-lisp-01.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on November 27, 29, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

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

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

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  Tunneling Details  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 18
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 20
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 21
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 21 22
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 23
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 23
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 25
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 25
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 27
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 28
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 30 31
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 31 32
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 33 34
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 34 35
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 37
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 37 38
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 38 39
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 39
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 41
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 42
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 43
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 43
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 44
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 45
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 46
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 46
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 46
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 48
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 48
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 48
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 48
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 50
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 51
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 52
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 53
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 56
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 55 56
     14.2. Informative References . . . . . . . . . . . . . . . . . . 56 57
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 59 60
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 61

1.  Requirements Notation

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

2.  Introduction

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

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

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

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

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

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

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

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

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

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

   Some of the design goals of this proposal include:

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

   2.  Minimize required changes to Internet infrastructure.

   3.  Be incrementally deployable.

   4.  Require no router hardware changes.

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

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

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

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

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

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

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

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

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

3.  Definition of Terms

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Address Family Indicator (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI] for details.

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

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

4.  Basic Overview

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

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

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

   Some basic rules governing LISP are:

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

   o  EIDs are always IP addresses assigned to hosts.

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

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

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

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

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

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

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

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

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

4.1.  Packet Flow Sequence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.  Tunneling Details

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

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

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

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

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

5.1.  LISP IPv4-in-IPv4 Header Format

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

5.2.  LISP IPv6-in-IPv6 Header Format

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

5.3.  Tunnel Header Field Descriptions

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

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

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

   UDP Checksum:  this field field MUST be transmitted as 0 and ignored
      on receipt by the ETR.  Note, even when the UDP checksum is
      transmitted as 0 an intervening NAT device can recalculate the
      checksum and rewrite the UDP checksum field to non-zero.  For
      performance reasons, the ETR MUST ignore the checksum and MUST not
      do a checksum computation.

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

   S: this is the Solicit-Map-Request (SMR) bit.  See section
      Section 6.5.2 for details.

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

   LISP Nonce:  is a 32-bit value that is randomly generated by an ITR.
      It is used to test route-returnability when xTRs exchange
      encapsulated data packets with the SMR bit set, Data-Probe, Map-
      Request, or Map-Reply messages.

   When doing Recursive Tunneling:

   o  The OH header Time to Live field (or Hop Limit field, in case of
      IPv6) MUST be copied from the IH header Time to Live field.

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

   When doing Re-encapsulated Tunneling:

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

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

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

   When the Type of Service code-points indicate the use of ECN
   according to [RFC3168], the full-functionality option for simple
   tunnels will be used when ITR encapsulating and ETR decapsulating.
   Therefore, the Congestion Experience (CE) bit will be preserved when
   a packet traveres a LISP tunnel.

5.4.  Dealing with Large Encapsulated Packets

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

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

5.4.1.  A Stateless Solution to MTU Handling

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

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

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

   3.  Calculate: S + H = L.

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

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

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

   When the outer header encapsulation uses an IPv4 header the DF bit is
   always set to 0.

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

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

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

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

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

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

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

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

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

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

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

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

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

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

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

6.1.1.  LISP Packet Type Allocations

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

       Reserved:                        0    b'0000'
       LISP Map-Request:                1    b'0001'
       LISP Map-Reply:                  2    b'0010'
       LISP Map-Register:               3    b'0011'
       LISP-CONS Open Message:          8    b'1000'
       LISP-CONS Push-Add Message:      9    b'1001'
       LISP-CONS Push-Delete Message:   10   b'1010'
       LISP-CONS Unreachable Message    11   b'1011'

6.1.2.  Map-Request Message Format

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

   Packet field descriptions:

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

   Locator Reach Bits:  These bits MUST be set to 0 on transmission and
      ignored on receipt.  They cannot be used for indicating
      reachability because the Map-Request does not have the EID-prefix
      for the sending site so the receiver of the Map-Request cannot
      know what mapping entry to associate the reachability with.
      However, when Mapping Data is provided in the Map-Reply Record
      field, and the receiver of the Map-Request is configured to accept
      the mapping data, the R-bit per locator entry in the EID-prefix
      record is used to denote reachability.

   Nonce:  A 4-byte random value created by the sender of the Map-
      Request.

   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.  See other control-specific documents
      [CONS] for TCP-based Map-Requests.

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

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

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

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

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

   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.

   Originating ITR RLOC Address:  Used to give the ETR the option of
      returning a Map-Reply in the address-family of this locator.

   EID mask-len:  Mask length for EID prefix.

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

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

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

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

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

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the later 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  In
   all cases, the UDP source port number for the Map-Request message is
   a randomly allocated 16-bit value and the UDP destination port number
   is set to the well-known destination port number 4342.  A successful
   Map-Reply updates the cached set of RLOCs associated with the EID
   prefix range.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4341 when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests
   are LISP encapsulated the same way from a Map-Server to an ETR.
   Details on encapsulated Map-Reqeusts Map-Requests and Map-Resolvers can be found
   in [LISP-MS].

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

6.1.4.  Map-Reply Message Format

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

   Packet field descriptions:

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

   Locator Reach Bits:  Refer to Section 5.3.  This field MUST be set to
      0 on transmission and ignored on receipt.  The locator
      reachability is encoded as the R-bit in each locator entry of each
      EID-prefix record.

   Nonce:  A 4-byte value set in a Data-Probe packet or a Map-Request
      that is echoed here in the Map-Reply.

   Type:   2 (Map-Reply)
   Reserved:  Set to 0 on transmission and ignored on receipt.

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

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

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

   EID mask-len:  Mask length for EID prefix.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set by the ETR.  See [CONS] for TCP-based Map-Replies.

   ACT:  This 3-bit field describes negative Map-Reply actions.  These
      bits are used only when the 'Locator Count' field is set to 0.
      The action bits are encoded only in Map-Reply messages.  The
      actions defined are used by an ITR or PTR when a destination EID
      matches a negative mapping cache entry.  The current assigned
      values are:

      (0) No action:  No action is being conveyed by the sender of the
         Map-Reply message.

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

      (2) Drop:  The packet is dropped silently.

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

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

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

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

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

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

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

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

   R: when this bit is set, the locator is known to be reachable from
      the Map-Reply sender's perspective.  When there is a single
      mapping record in the message, the R-bit for each locator must
      have a consistent setting with the bitfield setting of the 'Loc
      Reach Bits' field in the early part of the header.  When there are
      multiple mapping records in the message, the 'Loc Reach Bits'
      field is set to 0.

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

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

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

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

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

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

   The addresses for a encapsulated data packets or Map-Request message
   are swapped and used for sending the Map-Reply.  The UDP source and
   destination ports are swapped as well.  That is, the source port in
   the UDP header for the Map-Reply is set to the well-known UDP port
   number 4342.

6.1.6.  Map-Register Message Format

   The usage details of the Map-Register message

   Map-Reply records can be found in
   specification [LISP-MS]. have an empty locator-set.  This section solely defines the message
   format.

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

6.1.6.  Map-Register Message Format

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

   The message is sent in a UDP with a destination UDP port 4342 and a
   randomly selected UDP port number.  Before an IPv4 or IPv6 network
   layer header is prepended, an AH header is prepended to carry
   authentication information.  The format conforms to the IPsec
   specification [RFC2402].  The Map-Regiter Map-Register message will use transport
   mode by setting the IP protocol number field or the IPv6 next-header
   field to 51.

   The AH header from [RFC2402] is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Next Header   |  Payload Len  |          RESERVED             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Security Parameters Index (SPI)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Sequence Number Field                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                Authentication Data (variable)                 |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Next Header field is set to UDP.  The SPI field is set to 0
   (since no Security Association or Key Exchange protocol is being
   used).  The Sequece Sequence Number is a randomly chosen value by the sender.
   The Authentication Data is 16 bytes and holds a MD5 HMAC.

   The Map-Register message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |x|                     Locator Reach Bits                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3 | |P|            Reserved                 | Record Count  |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  |A| ACT |  Reserved             |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved            |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |           Unused Flags      |R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

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

   Locator Reach Bits:  Refer to Section 5.3.  This field MUST be set to
      0 on transmission and ignored on receipt.  The definition locator
      reachability is encoded as the R-bit in each locator entry of each
      EID-prefix record.

   Nonce:  The Nonce field is set to 0 in Map-Register messages.

   Type:   3 (Map-Register)

   P: This is the Proxy-Map-Reply bit.  When set to 1, the ETR sending a
      Map-Register is asking the Map-Server to send non-authoritative
      Map-Replies on behalf of the ETR.

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

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

   The definition of the rest of the Map-Register can be found in the
   Map-Reply section.

6.2.  Routing Locator Selection

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

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

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

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

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

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

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The Map-Reply and the database mapping service does not
   provide any reachability status for Locators.  This is done outside
   of the mapping service.  See next section for details.

6.3.  Routing Locator Reachability

   There are 4 methods for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator reachability is determined by an ETR by examining the
       Loc-Reach-Bits from a LISP header of a encapsulated data packet
       which is provided by an ITR when an ITR encapsulates data.

   2.  Locator unreachability is determined by an ITR by receiving ICMP
       Network or Host Unreachable messages.

   3.  Locator unreachability can also be determined by an BGP-enabled
       ITR when there is no prefix matching a Locator address from the
       BGP RIB.

   4.  Locator unreachability is determined when a host sends an ICMP
       Port Unreachable message.  This occurs when an ITR may not use
       any methods of interworking. one which is describe in [INTERWORK]
       and the encapsulated data packet is received by a host at the
       destination non-LISP site.

   5.  Locator reachability is determined by receiving a Map-Reply
       message from a ETR's Locator address in response to a previously
       sent Map-Request.

   6.  Locator reachability can also be determined by receiving packets
       encapsulated by the ITR assigned to the locator address.

   When determining Locator reachability by examining the Loc-Reach-Bits
   from the LISP encapsulate data packet, an ETR will receive up to date
   status from the ITR closest to the Locators at the source site.  The
   ITRs at the source site can determine reachability when running their
   IGP at the site.  When the ITRs are deployed on CE routers, typically
   a default route is injected into the site's IGP from each of the
   ITRs.  If an ITR goes down, the CE-PE link goes down, or the PE
   router goes down, the CE router withdraws the default route.  This
   allows the other ITRs at the site to determine one of the Locators
   has gone unreachable.

   The Locators listed in a Map-Reply are numbered with ordinals 0 to
   n-1.  The Loc-Reach-Bits in a LISP Data Message are numbered from 0
   to n-1 starting with the least significant bit numbered as 0.  So,
   for example, if the ITR with locator listed as the 3rd Locator
   position in the Map-Reply goes down, all other ITRs at the site will
   have the 3rd bit from the right cleared (the bit that corresponds to
   ordinal 2).

   When an ETR decapsulates a packet, it will look for a change in the
   Loc-Reach-Bits value.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator that has just gone
   unreachable.  It can start using the Locator again when the bit that
   corresponds to the Locator goes from 0 to 1.  Loc-Reach-Bits are
   associated with a locator-set per EID-prefix.  Therefore, when a
   locator becomes unreachable, the loc-reach-bit that corresponds to
   that locator's position in the list returned by the last Map-Reply
   will be set to zero for that particular EID-prefix.

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

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

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

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

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

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

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

   When an ETR is decapsulating packets, it can be sure that the path
   from the encapsulating ITR is available.  The ETR can assume the path
   from the ETR to the ITR is also reachable.  Even if there is
   asymmetric routing in the core, the first-hop and last-hop ASes will
   be the same for both directions of traffic since the locator
   addresses are out of the PA blocks of each.  However, the assumption
   may not always be valid, so this mechanism should be used as a best-
   effort indication that a working path exists between the sites.  In
   the event of unidirectional traffic from an ITR to an ETR, an ITR
   should not conclude that a locator is unreachable since it is not
   receiving packets, but use alternate mechanisms described above to
   determine reachability.

6.4.  Routing Locator Hashing

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

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

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

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

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

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

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

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

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

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

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

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

6.5.1.  Clock Sweep

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

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

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

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

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

6.5.2.  Solicit-Map-Request (SMR)

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

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

   An SMR message is simply a bit set in an encapsulated data packet
   (and a Map-Request message).  When an ETR at a remote site
   decapsulates a data packet that has the SMR bit set, it can tell that
   a new Map-Request message is being solicited.  Both the xTR that
   sends the SMR message and the site that acts on the SMR message MUST
   be rate-limited.

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

   1.  When the database mappings in an ETR change, the ITRs at the site
       begin to set the SMR bit in packets they encapsulate to the sites
       they communicate with.

   2.  A remote xTR which decapsulates a packet with the SMR bit set
       will schedule sending a Map-Request message to the source locator
       address of the encapsulated packet.  The nonce in the Map-Request
       is copied from the nonce in the encapsulated data packet that has
       the SMR bit set.

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

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

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

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

7.  Router Performance Considerations

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

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

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

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

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

8.  Deployment Scenarios

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

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

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

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

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

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

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

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

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

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

8.1.  First-hop/Last-hop Tunnel Routers

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

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

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

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

8.2.  Border/Edge Tunnel Routers

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

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

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

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

8.3.  ISP Provider-Edge (PE) Tunnel Routers

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

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

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

9.  Traceroute Considerations

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

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

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

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

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

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

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

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

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

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

9.1.  IPv6 Traceroute

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

9.2.  IPv4 Traceroute

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

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

9.3.  Traceroute using Mixed Locators

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

10.  Mobility Considerations

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

10.1.  Site Mobility

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

10.2.  Slow Endpoint Mobility

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

10.3.  Fast Endpoint Mobility

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.4.  Fast Network Mobility

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

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

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

11.  Multicast Considerations

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

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

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

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

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

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

12.  Security Considerations

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

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

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

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

13.  Prototype Plans and Status

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

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

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

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

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

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

   Here is a rough set of milestones:

   1.  This draft will be the draft for interoperable implementations to
       code against.  Interoperable implementations will be ready
       beginning of 2009.

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

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

   4.  Implement the LISP Multicast draft [MLISP].

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

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

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

   As of this writing the following accomplishments have been achieved:

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

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

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

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

   5.   Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and
        Andrew Partan continue to test all the features described above
        on a dual-stack infrastructure.

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

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

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

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

   10.  A cisco IOS implementation is underway which currently supports
        IPv4 encapsulation and decapsulation features.

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

   12.  A Linux implementation of LIG has been made available and
        supported by Dave Meyer.  It can be run on any Linux system
        which resides in either a LISP site or non-LISP site.  See [LIG]
        for details.

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

14.  References

14.1.  Normative References

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

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

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

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

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

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

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

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

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

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

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

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

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

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

14.2.  Informative References

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

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

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

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

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

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

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

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

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

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

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

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-fuller-lisp-ms-00.txt
              draft-ietf-lisp-ms-01.txt (work in progress),
              March May 2009.

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

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

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

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

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

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

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

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

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

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

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

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

   [SHIM6]    Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt (work in
              progress), October 2006.

Appendix A.  Acknowledgments

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

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

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
   Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
   Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
   Lezama, Attilla De Groot, and Parantap Lahiri. Lahiri, and David Black.

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

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

Authors' Addresses

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

   Email: dino@cisco.com

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

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

   Email: dmm@cisco.com

   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com
--Apple-Mail-92--1022495991 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-92--1022495991 Content-Disposition: attachment; filename=rfcdiff-lisp-multicast-00-01.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-multicast-00-01.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-multicast-00.txt draft-ietf-lisp-multicast-01.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                                 J. Zwiebel
Expires: November 27, 29, 2009                                     S. Venaas
                                                           cisco Systems
                                                            May 26, 28, 2009

                    LISP for Multicast Environments
                    draft-ietf-lisp-multicast-00.txt
                    draft-ietf-lisp-multicast-01.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on November 27, 29, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

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

Table of Contents

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

1.  Requirements Notation

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

2.  Introduction

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

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

   This specification will address the following scenarios:

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

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

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

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

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

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

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

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

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

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

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

   Also, the current version of this specification does not describe
   multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
   descriptions in [LISP].

3.  Definition of Terms

   The terminology in this section is consistent with the definitions in
   [LISP] but is extended specifically to deal with the application of
   the terminology to multicast routing.

   LISP-Multicast:   a reference to the design in this specification.
      That is, when any site that is participating in multicast
      communication has been upgraded to be a LISP site, the operation
      of control-plane and data-plane protocols is considered part of
      the LISP-Multicast architecture.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source address field of the first (most inner) LISP
      header of a multicast packet.  The host obtains a destination
      group address the same way it obtains one today, as it would when
      it is a non-LISP site.  The source EID is obtained via existing
      mechanisms used to set a host's "local" IP address.  An EID is
      allocated to a host from an EID prefix block associated with the
      site the host is located in.  An EID can be used by a host to
      refer to another host, as when it joins an SSM (S-EID,G) route
      using IGMP version 3 [RFC4604].  LISP uses Provider Independent
      (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs.
      Note that EID blocks may be assigned in a hierarchical manner,
      independent of the network topology, to facilitate scaling of the
      mapping database.  In addition, an EID block assigned to a site
      may have site-local structure (subnetting) for routing within the
      site; this structure is not visible to the global routing system.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an ingress
      tunnel router (ITR), the router in the multicast source host's
      site that encapsulates multicast packets.  It is the output of a
      EID-to-RLOC mapping lookup.  An EID maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically-aggregatable
      blocks that are assigned to a site at each point to which it
      attaches to the global Internet; where the topology is defined by
      the connectivity of provider networks, RLOCs can be thought of as
      Provider Assigned (PA) addresses.  Multiple RLOCs can be assigned
      to the same ITR device or to multiple ITR devices at a site.

   Ingress Tunnel Router (ITR):   a router which accepts an IP multicast
      packet with a single IP header (more precisely, an IP packet that
      does not contain a LISP header).  The router treats this "inner"
      IP destination multicast address opaquely so it doesn't need to
      perform a map lookup on the group address because it is
      topologically insignificant.  The router then prepends an "outer"
      IP header with one of its globally-routable RLOCs as the source
      address field.  This RLOC is known to other multicast receiver
      sites which have used the mapping database to join a multicast
      tree for which the ITR is the root.  In general, an ITR receives
      IP packets from site end systems on one side and sends LISP-
      encapsulated multicast IP packets out all external interfaces
      which have been joined.

      An ITR would receive a multicast packet from a source inside of
      its site when 1) it is on the path from the multicast source to
      internally joined receivers, or 2) when it is on the path from the
      multicast source to externally joined receivers.

   Egress Tunnel Router (ETR):   a router that is on the path from a
      multicast source host in another site to a multicast receiver in
      its own site.  An ETR accepts a PIM Join/Prune message from a site
      internal PIM router destined for the source's EID in the multicast
      source site.  The ETR maps the source EID in the Join/Prune
      message to an RLOC address based on the EID-to-RLOC mapping.  This
      sets up the ETR to accept multicast encapsulated packets from the
      ITR in the source multicast site.  A multicast ETR decapsulates
      multicast encapsulated packets and replicates them on interfaces
      leading to internal receivers.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality can be at the
      CE router.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP header.  An ITR
      prepends headers and an ETR strips headers.  A LISP encapsulated
      multicast packet will have an "inner" header with the source EID
      in the source field; an "outer" header with the source RLOC in the
      source field: and the same globally unique group address in the
      destination field of both the inner and outer header.

   (S,G) State:   the formal definition is in the PIM Sparse Mode
      [RFC4601] specification.  For this specification, the term is used
      generally to refer to multicast state.  Based on its topological
      location, the (S,G) state resides in routers can be either
      (S-EID,G) state (at a location where the (S,G) state resides) or
      (S-RLOC,G) state (in the Internet core).

   (S-EID,G) State:   refers to multicast state in multicast source and
      receiver sites where S-EID is the IP address of the multicast
      source host (its EID).  An S-EID can appear in an IGMPv3 report,
      an MSDP SA message or a PIM Join/Prune message that travels inside
      of a site.

   (S-RLOC,G) State:   refers to multicast state in the core where S is
      a source locator (the IP address of a multicast ITR) of a site
      with a multicast source.  The (S-RLOC,G) is mapped from (S-EID,G)
      entry by doing a mapping database lookup for the EID prefix that
      S-EID maps to.  An S-RLOC can appear in a PIM Join/Prune message
      when it travels from an ETR to an ITR over the Internet core.

   uLISP Site:   a unicast only LISP site according to [LISP] which has
      not deployed the procedures of this specification and therefore,
      for multicast purposes, follows the procedures from Section 9.

   mPTR:   this is a multicast PTR that is responsible for advertising a
      very coarse EID prefix which non-LISP and uLISP sites can target
      their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP
      source multicast sites can send multicast packets using source
      addresses from the EID namespace. mPTRs act as Proxy ETRs for
      supporting multicast routing in a LISP infrastructure.

   Mixed Locator-Sets:   this is a locator-set for a LISP database
      mapping entry where the RLOC addresses in the locator-set are in
      both IPv4 and IPv6 format.

   Unicast Encapsulated PIM Join/Prune Message:   this is a standard PIM
      Join/Prune message (encapsulated in an IP header (LISP encapsulated with protocol number 103) destination UDP port
      4341) which is sent by ETRs at multicast receiver sites to an ITR
      at a multicast source site.  This message is sent periodically as
      long as there are interfaces in the oif-list for the (S-EID,G)
      entry the ETR is joining for.

4.  Basic Overview

   LISP, when used for unicast routing, increases the site's ability to
   control ingress traffic flows.  Egress traffic flows are controlled
   by the IGP in the source site.  For multicast, the IGP coupled with
   PIM can decide which path multicast packets ingress.  By using the
   traffic engineering features of LISP, a multicast source site can
   control the egress of its multicast traffic.  By controlling the
   priorities of locators from a mapping database entry, a source
   multicast site can control which way multicast receiver sites join to
   the source site.

   At this point in time, we don't see a requirement for different
   locator-sets, priority, and weight policies for multicast than we
   have for unicast.

   The fundamental multicast forwarding model is to encapsulate a
   multicast packet into another multicast packet.  An ITR will
   encapsulate multicast packets received from sources that it serves in
   another LISP multicast header.  The destination group address from
   the inner header is copied to the destination address of the outer
   header.  The inner source address is the EID of the multicast source
   host and the outer source address is the RLOC of the encapsulating
   ITR.

   The LISP-Multicast architecture will follow this high-level protocol
   and operational sequence:

   1.  Receiver hosts in multicast sites will join multicast content the
       way they do today, they use IGMP.  When they use IGMPv3 where
       they specify source addresses, they use source EIDs, that is they
       join (S-EID,G).  If the S-EID is a local multicast source host.
       If the multicast source is external to this receiver site, the
       PIM Join/Prune message flows toward the ETRs, finding the
       shortest exit (that is the closest exit for the Join/Prune
       message but it is the closest entrance for the multicast packet
       to the receiver).

   2.  The ETR does a mapping database lookup for S-EID.  If the mapping
       is cached from a previous lookup (from either a previous Join/
       Prune for the source multicast site or a unicast packet that went
       to the site), it will use the RLOC information from the mapping.
       The ETR will use the same priority and weighting mechanism as for
       unicast.  So the source site can decide which way multicast
       packets egress.

   3.  The ETR will build two PIM Join/Prune messages, one that contains
       a (S-EID,G) entry that is unicast to the ITR that matches the
       RLOC the ETR selects, and the other which contains a (S-RLOC,G)
       entry so the core network can create multicast state from this
       ETR to the ITR.

   4.  When the ITR gets the unicast Join/Prune message (see Section 3
       for formal definition), it will process (S-EID,G) entries in the
       message and propagate them inside of the site where it has
       explicit routing information for EIDs via the IGP.  When the ITR
       receives the (S-RLOC,G) PIM Join/Prune message it will process it
       like any other join it would get in today's Internet.  The S-RLOC
       address is the IP address of this ITR.

   5.  At this point there is (S-EID,G) state from the joining host in
       the receiver multicast site to the ETR of the receiver multicast
       site.  There is (S-RLOC,G) state across the core network from the
       ETR of the multicast receiver site to the ITR in the multicast
       source site and (S-EID,G) state in the source multicast site.
       Note, the (S-EID,G) state is the same S-EID in each multicast
       site.  As other ETRs join the same multicast tree, they can join
       through the same ITR (in which case the packet replication is
       done in the core) or a different ITR (in which case the packet
       replication is done at the source site).

   6.  When a packet is originated by the multicast host in the source
       site, it will flow to one or more ITRs which will prepend a LISP
       header by copying the group address to the outer destination
       address field and insert its own locator address in the outer
       source address field.  The ITR will look at its (S-RLOC,G) state,
       where S-RLOC is its own locator address, and replicate the packet
       on each interface a (S-RLOC,G) joined was received on.  The core
       has (S-RLOC,G) so where fanout occurs to multiple sites, a core
       router will do packet replication.

   7.  When either the source site or the core replicates the packet,
       the ETR will receive a LISP packet with a destination group
       address.  It will also decapsulate packets because it has
       receivers for the group.  Otherwise, it would have not received
       the packets because it would not have joined.  The ETR
       decapsulates and does a (S-EID,G) lookup in its multicast FIB to
       forward packets out one or more interfaces to forward the packet
       to internal receivers.

   This architecture is consistent and scalable with the architecture
   presented in [LISP] where multicast state in the core operates on
   locators and multicast state at the sites operates on EIDs.

   Alternatively, [LISP] does present a mechanism where (S-EID,G) state
   can reside in the core through the use of RPF-vectors [RPFV] in PIM
   Join/Prune messages.  However, this will require EID state in core as
   well as the use of RPF-vector formatted Join/Prune messages which are
   not the default implementation choice.  So we choose a design that
   can allow the separation of namespaces as unicast LISP provides.  It
   will be at the expense of creating new (S-RLOC,G) state when ITRs go
   unreachable.  See Section 5 for details.

   However, we have some observations on the algorithm above.  We can
   scale the control plane but at the expense of sending data to sites
   which may have not joined the distribution tree where the
   encapsulated data is being delivered.  For example, one site joins
   (S-EID1,G) and another site joins (S-EID2,G).  Both EIDs are in the
   same multicast source site.  Both multicast receiver sites join to
   the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the
   ITR.  The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the
   site.  The ITR receives (S-RLOC,G) joins and populates the oif-list
   state for it.  Since both (S-EID1,G) and (S-EID2, G) map to the one
   (S-RLOC,G) packets will be delivered by the core to both multicast
   receiver sites even though each have joined a single source-based
   distribution tree.  This behavior is a consequence of the many-to-one
   mapping between S-EIDs and a S-RLOC.

   There is a possible solution to this problem which reduces the number
   of many-to-one occurrences of (S-EID,G) entries aggregating into a
   single (S-RLOC,G) entry.  If a physical ITR can be assigned multiple
   RLOC addresses and these addresses are advertised in mapping database
   entries, then ETRs at receiver sites have more RLOC address options
   and therefore can join different (RLOC,G) entries for each (S-EID,G)
   entry joined at the receiver site.  It would not scale to have a one-
   to-one relationship between the number of S-EID sources at a source
   site and the number of RLOCs assigned to all ITRs at the site, but we
   can reduce the "n" to a smaller number in the "n-to-1" relationship.
   And in turn, reduce the opportunity for data packets to be delivered
   to sites for groups not joined.

5.  Source Addresses versus Group Addresses

   Multicast group addresses don't have to be associated with either the
   EID or RLOC namespace.  They actually are a namespace of their own
   that can be treated as logical with relatively opaque allocation.
   So, by their nature, they don't detract from an incremental
   deployment of LISP-Multicast.

   As for source addresses, as in the unicast LISP scenario, there is a
   decoupling of identification from location.  In a LISP site, packets
   are originated from hosts using their allocated EIDs, those addresses
   are used to identify the host as well as where in the site's topology
   the host resides but not how and where it is attached to the
   Internet.

   Therefore, when multicast distribution tree state is created anywhere
   in the network on the path from the any multicast receiver to a multicast
   source, EID state is maintained at the source and receiver multicast
   sites, and RLOC state is maintained in the core.  That is, a
   multicast distribution tree will be represented as a 3-tuple of
   {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the
   3-tuple is the state stored in routers from the source to one or more
   ITRs in the source multicast site, the second element of the 3-tuple
   is the state stored in routers downstream of the ITR, in the core, to
   all LISP receiver multicast sites, and the third element in the
   3-tuple is the state stored in the routers downstream of each ETR, in
   each receiver multicast site, reaching each receiver.  Note that
   (S-EID,G) is the same in both the source and receiver multicast
   sites.

   The concatenation/mapping from the first element to the second
   element of the 3-tuples is done by the ITR and from the second
   element to the third element is done at the ETRs.

6.  Locator Reachability Implications on LISP-Multicast

   Multicast state as it is stored in the core is always (S,G) state as
   it exists today or (S-RLOC,G) state as it will exist when LISP sites
   are deployed.  The core routers cannot distinguish one from the
   other.  They don't need to because it is state that RPFs against the
   core routing tables in the RLOC namespace.  The difference is where
   the root of the distribution tree for a particular source is.  In the
   traditional multicast core, the source S is the source host's IP
   address.  For LISP-Multicast the source S is a single ITR of the
   multicast source site.

   An ITR is selected based on the LISP EID-to-RLOC mapping used when an
   ETR propagates a PIM Join/Prune message out of a receiver multicast
   site.  The selection is based on the same algorithm an ITR would use
   to select an ETR when sending a unicast packet to the site.  In the
   unicast case, the ITR can change on a per-packet basis depending on
   the reachability of the ETR.  So an ITR can change relatively easily
   using local reachability state.  However, in the multicast case, when
   an ITR goes unreachable, new distribution tree state must be built
   because the encapsulating root has changed.  This is more significant
   than an RPF-change event, where any router would typically locally
   change its RPF-interface for its existing tree state.  But when an
   encapsulating LISP-Multicast ITR goes unreachable, new distribution
   state must be rebuilt and reflect the new encapsulator.  Therefore,
   when an ITR goes unreachable, all ETRs that are currently joined to
   that ITR will have to trigger a new Join/Prune message for (S-RLOC,G)
   to the new ITR as well as send a unicast encapsulated Join/Prune
   message telling the new ITR which (S-EID,G) is being joined.

   This issue can be mitigated by using anycast addressing for the ITRs
   so the problem does reduce to an RPF change in the core, but still
   requires a unicast encapsulated Join/Prune message to tell the new
   ITR about (S-EID,G).  The problem with this approach is that the ETR
   really doesn't know when the ITR has changed so the new anycast ITR
   will get the (S-EID,G) state only when the ETR sends it the next time
   during its periodic sending procedures.

7.  Multicast Protocol Changes

   A number of protocols are used today for inter-domain multicast
   routing:

   IGMPv1-v3, MLDv1-v2:   These protocols do not require any changes for
      LISP-Multicast for two reasons.  One being that they are link-
      local and not used over site boundaries and second they advertise
      group addresses that don't need translation.  Where source
      addresses are supplied in IGMPv3 and MLDv2 messages, they are
      semantically regarded as EIDs and don't need to be converted to
      RLOCs until the multicast tree-building protocol, such as PIM, is
      received by the ETR at the site boundary.  Addresses used for IGMP
      and MLD come out of the source site's allocated addresses which
      are therefore from the EID namespace.

   MBGP:   Even though MBGP is not a multicast routing protocol, it is
      used to find multicast sources when the unicast BGP peering
      topology and the multicast MBGP peering topology are not
      congruent.  When MBGP is used in a LISP-Multicast environment, the
      prefixes which are advertised are from the RLOC namespace.  This
      allows receiver multicast sites to find a path to the source
      multicast site's ITRs.  MBGP peering addresses will be from the
      RLOC namespace.

   MSDP:   MSDP is used to announce active multicast sources to other
      routing domains (or LISP sites).  The announcements come from the
      PIM Rendezvous Points (RPs) from sites where there are active
      multicast sources sending to various groups.  In the context of
      LISP-Multicast, the source addresses advertised in MSDP will
      semantically be from the EID namespace since they describe the
      identity of a source multicast host.  It will be true that the
      state stored in MSDP caches from core routers will be from the EID
      namespace.  An RP address inside of site will be from the EID
      namespace so it can be advertised and reached by internal unicast
      routing mechanism.  However, for MSDP peer-RPF checking to work
      properly across sites, the RP addresses must be converted or
      mapped into a routable address that is advertised and maintained
      in the BGP routing tables in the core.  MSDP peering addresses can
      come out of either the EID or a routable address namespace.  And
      the choice can be made unilaterally because the ITR at the site
      will determine which namespace the destination peer address is out
      of by looking in the mapping database service.

   PIM-SSM:   In the simplest form of distribution tree building, when
      PIM operates in SSM mode, a source distribution tree is built and
      maintained across site boundaries.  In this case, there is a small
      modification to the operation of the PIM protocol (but not to any
      message format) to support taking a Join/Prune message originated
      inside of a LISP site with embedded addresses from the EID
      namespace and converting them to addresses from the RLOC namespace
      when the Join/Prune message crosses a site boundary.  This is
      similar to the requirements documented in [MNAT].

   PIM-Bidir:   Bidirectional PIM is typically run inside of a routing
      domain, but if deployed in an inter-domain environment, one would
      have to decide if the RP address of the shared-tree would be from
      the EID namespace or the RLOC namespace.  If the RP resides in a
      site-based router, then the RP address is from the EID namespace.
      If the RP resides in the core where RLOC addresses are routed,
      then the RP address is from the RLOC namespace.  This could be
      easily distinguishable if the EID address were well-known address
      allocation block from the RLOC namespace.  Also, when using
      Embedded-RP for RP determination [RFC3956], the format of the
      group address could indicate the namespace the RP address is from.
      However, refer to Section 10 for considerations core routers need
      to make when using Embedded-RP IPv6 group addresses.  When using
      Bidir-PIM for inter-domain multicast routing, it is recommended to
      use staticly configured RPs so core routers think the Bidir group
      is associated with an ITR's RLOC as the RP address and site
      routers think the Bidir group is associated with the site resident
      RP with an EID address.  With respect to DF-election in Bidir PIM,
      no changes are required since all messaging and addressing is
      link-local.

   PIM-ASM:   The way ASM mode of PIM, the most popular form of PIM, is
      deployed in the Internet today is by having shared-trees within a
      site and using source-trees across sites.  By the use of MSDP and
      PIM-SSM techniques described above, we can get multicast
      connectivity across LISP sites.  Having said that, that means
      there are no special actions required for processing (*,G) or
      (S,G,R) Join/Prune messages since they all operate against the
      shared-tree which is site resident.  Just like with ASM, there is
      no (*,G) in the core when LISP-Multicast is in use.  This is also
      true for the RP-
      mapping RP-mapping mechanisms Auto-RP and BSR.

   Based on the protocol description above, the conclusion is that there
   are no protocol message format changes, just a translation function
   performed at the control-plane.  This will make for an easier and
   faster transition for LISP since fewer components in the network have
   to change.

   It should also be stated just like it is in [LISP] that no host
   changes, whatsoever, are required to have a multicast source host
   send multicast packets and for a multicast receiver host to receive
   multicast packets.

8.  LISP-Multicast Data-Plane Architecture

   The LISP-Multicast data-plane operation conforms to the operation and
   packet formats specified in [LISP].  However, encapsulating a
   multicast packet from an ITR is a much simpler process.  The process
   is simply to copy the inner group address to the outer destination
   address.  And to have the ITR use its own IP address (its RLOC), and
   as the source address.  The process is simpler for multicast because
   there is no EID-to-RLOC mapping lookup performed during packet
   forwarding.

   In the decapsulation case, the ETR simply removes the outer header
   and performs a multicast routing table lookup on the inner header
   (S-EID,G) addresses.  Then the oif-list for the (S-EID,G) entry is
   used to replicate the packet on site-facing interfaces leading to
   multicast receiver hosts.

   There is no Data-Probe logic for ETRs as there can be in the unicast
   forwarding case.

8.1.  ITR Forwarding Procedure

   The following procedure is used by an ITR, when it receives a
   multicast packet from a source inside of its site:

   1.  A multicast data packet sent by a host in a LISP site will have
       the source address equal to the host's EID and the destination
       address equal to the group address of the multicast group.  It is
       assumed the group information is obtained by current methods.
       The same is true for a multicast receiver to obtain the source
       and group address of a multicast flow.

   2.  When the ITR receives a multicast packet, it will have both S-EID
       state and S-RLOC state stored.  Since the packet was received on
       a site-facing interface, the RPF lookup is based on the S-EID
       state.  If the RPF check succeeds, then the oif-list contains
       interfaces that are site-facing and external-facing.  For the
       site-facing interfaces, no LISP header is prepended.  For the
       external-facing interfaces a LISP header is prepended.  When the
       ITR prepends a LISP header, it uses its own RLOC address as the
       source address and copies the group address supplied by the IP
       header the host built as the outer destination address.

8.1.1.  Multiple RLOCs for an ITR

   Typically, an ITR will have a single RLOC address but in some cases
   there could be multiple RLOC addresses assigned from either the same
   or different service providers.  In this case when (S-RLOC,G) Join/
   Prune messages are received for each RLOC, there is a oif-list
   merging action that must take place.  Therefore, when a packet is
   received from a site-facing interface that matches on a (S-EID,G)
   entry, the interfaces of the oif-list from all (RLOC,G) entries
   joined to the ITR as well as the site-facing oif-list joined for
   (S-EID,G) must be part be included in packet replication.  In
   addition to replicating for all types of oif-lists, each oif entry
   must be tagged with the RLOC address, so encapsulation uses the outer
   source address for the RLOC joined.

8.2.  ETR Forwarding Procedure

   The following procedure is used by an ETR, when it receives a
   multicast packet from a source outside of its site:

   1.  When a multicast data packet is received by an ETR on an
       external-facing interface, it will do an RPF lookup on the S-RLOC
       state it has stored.  If the RPF check succeeds, the interfaces
       from the oif-list are used for replication to interfaces that are
       site-facing as well as interfaces that are external-facing (this
       ETR can also be a transit multicast router for receivers outside
       of its site).  When the packet is to be replicated for an
       external-facing interface, the LISP encapsulation header are not
       stripped.  When the packet is replicated for a site-facing
       interface, the encapsulation header is stripped.

   2.  The packet without a LISP header is now forwarded down the
       (S-EID,G) distribution tree in the receiver multicast site.

8.3.  Replication Locations

   Multicast packet replication can happen in the following topological
   locations:

   o  In an IGP multicast router inside a site which operates on S-EIDs.

   o  In a transit multicast router inside of the core which operates on
      S-RLOCs.

   o  At one or more ETR routers depending on the path a Join/Prune
      message exits a receiver multicast site.

   o  At one or more ITR routers in a source multicast site depending on
      what priorities are returned in a Map-Reply to receiver multicast
      sites.

   In the last case the source multicast site can do replication rather
   than having a single exit from the site.  But this only can occur
   when the priorities in the Map-Reply are modified for different
   receiver multicast site so that the PIM Join/Prune messages arrive at
   different ITRs.

   This policy technique, also used in [ALT] for unicast, is useful for
   multicast to mitigate the problems of changing distribution tree
   state as discussed in Section 6.

9.  LISP-Multicast Interworking

   This section will describe the multicast corollary to [INTWORK] which
   describes the interworking of multicast routing among LISP and non-
   LISP sites.

9.1.  LISP and non-LISP Mixed Sites

   Since multicast communication can involve more than two entities to
   communicate together, the combinations of interworking scenarios are
   more involved.  However, the state maintained for distribution trees
   at the sites is the same regardless of whether or not the site is
   LISP enabled or not.  So most of the implications are in the core
   with respect to storing routable EID prefixes from either PA or PI
   blocks.

   Before we enumerate the multicast interworking scenarios, we must
   define 3 deployment states of a site:

   o  A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it
      does today.  The addresses for the site are globally routable.

   o  A site that deploys LISP for unicast routing.  The addresses for
      the site are not globally routable.  Let's define the name for
      this type of site as a uLISP site.

   o  A site that deploys LISP for both unicast and multicast routing.
      The addresses for the site are not globally routable.  Let's
      define the name for this type of site as a LISP-Multicast site.

   We will not consider a LISP site enabled for multicast purposes only
   but do consider a uLISP site as documented in [INTWORK].  In this
   section we don't discuss how a LISP site sends multicast packets when
   all receiver sites are LISP-Multicast enabled; that has been
   discussed in previous sections.

   The following scenarios exist to make LISP-Multicast sites interwork
   with non-LISP-Multicast sites:

   1.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of non-LISP sites and uLISP sites.

   2.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of non-LISP sites and uLISP sites.

   3.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of LISP sites, uLISP sites, and
       non-LISP sites.

   4.  A uLISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

   5.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

9.1.1.  LISP Source Site to non-LISP Receiver Sites

   In the first scenario, a site is LISP capable for both unicast and
   multicast traffic and as such operates on EIDs.  Therefore there is a
   possibility that the EID prefix block is not routable in the core.
   For LISP receiver multicast sites this isn't a problem but for non-
   LISP or uLISP receiver multicast sites, when a PIM Join/Prune message
   is received by the edge router, it has no route to propagate the
   Join/Prune message out of the site.  This is no different than the
   unicast case that LISP-NAT in [INTWORK] solves.

   LISP-NAT allows a unicast packet that exits a LISP site to get its
   source address mapped to a globally routable address before the ITR
   realizes that it should not encapsulate the packet destined to a non-
   LISP site.  For a multicast packet to leave a LISP site, distribution
   tree state needs to be built so the ITR can know where to send the
   packet.  So the receiver multicast sites need to know about the
   multicast source host by its routable address and not its EID
   address.  When this is the case, the routable address is the
   (S-RLOC,G) state that is stored and maintained in the core routers.
   It is important to note that the routable address for the host cannot
   be the same as an RLOC for the site.  Because we want the ITRs to
   process a received PIM Join/Prune message from an external-facing
   interface to be propagated inside of the site so the site-part of the
   distribution tree is built.

   Using a globally routable source address allows non-LISP and uLISP
   multicast receiver to join, create, and maintain a multicast
   distribution tree.  However, the LISP multicast receiver site will
   want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
   Prune message is received on a site-facing interface.  It does this
   because it wants to find a (S-RLOC,G) entry to Join in the core.  So
   we have a conflict of behavior between the two types of sites.

   The solution to this problem is the same as when an ITR wants to send
   a unicast packet to a destination site but needs determine if the
   site is LISP capable or not.  When it is not LISP capable, the ITR
   does not encapsulate the packet.  So for the multicast case, when ETR
   receives a PIM Join/Prune message for (S-EID,G) state, it will do a
   mapping table lookup on S-EID.  In this case, S-EID is not in the
   mapping database because the source multicast site is using a
   routable address and not an EID prefix address.  So the ETR knows to
   simply propagate the PIM Join/Prune message to a external-facing
   interface without converting the (S-EID,G) because it is an (S,G)
   where S is routable and reachable via core routing tables.

   Now that the multicast distribution tree is built and maintained from
   any non-LISP or uLISP receiver multicast site, the way packet
   forwarding model is performed can be explained.

   Since the ITR in the source multicast site has never received a
   unicast encapsulated PIM Join/Prune message from any ETR in a
   receiver multicast site, it knows there are no LISP-Multicast
   receiver sites.  Therefore, there is no need for the ITR to
   encapsulate data.  Since it will know a priori (via configuration)
   that its site's EIDs are not routable, it assumes that the multicast
   packets from the source host are sent by a routable address.  That
   is, it is the responsibility of the multicast source host's system
   administrator to ensure that the source host sends multicast traffic
   using a routable source address.  When this happens, the ITR acts
   simply as a router and forwards the multicast packet like an ordinary
   multicast router.

   There is an alternative to using a LISP-NAT scheme just like there is
   for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
   (PTRs).  This can work the same way for multicast routing as well,
   but the difference is that non-LISP and uLISP sites will send PIM
   Join/Prune messages for (S-EID,G) which make their way in the core to
   PTRs.  Let's call this use of a PTR as a "Multicast PTR" (or mPTR).
   Since the PTRs advertise very coarse EID prefixes, they draw the PIM
   Join/Prune control traffic making them the target of the distribution
   tree.  To get multicast packets from the LISP source multicast sites,
   the tree needs to be built on the path from the mPTR to the LISP
   source multicast site.  To make this happen the mPTR acts as a "Proxy
   ETR" (where in unicast it acts as a "Proxy ITR").

   The existence of mPTRs in the core allows LISP source multicast site
   ITRs to encapsulate multicast packets so the state built between the
   ITRs and the mPTRs is (S-RLOC,G) state.  Then the mPTRs can
   decapsulate packets and forward natively to the non-LISP and uLISP
   receiver multicast sites.

9.1.2.  Non-LISP Source Site to non-LISP Receiver Sites

   Clearly non-LISP multicast sites can send multicast packets to non-
   LISP receiver multicast sites.  That is what they do today.  However,
   discussion is required to show how non-LISP multicast sites send
   multicast packets to uLISP receiver multicast sites.

   Since uLISP receiver multicast sites are not targets of any (S,G)
   state, they simply send (S,G) PIM Join/Prune messages toward the non-
   LISP source multicast site.  Since the source multicast site, in this
   case has not been upgraded to LISP, all multicast source host
   addresses are routable.  So this case is simplified to where a uLISP
   receiver multicast site looks to the source multicast site as a non-
   LISP receiver multicast site.

9.1.3.  Non-LISP Source Site to Any Receiver Site

   When a non-LISP source multicast site has receivers in either a non-
   LISP/uLISP site or a LISP site, one needs to decide how the LISP
   receiver multicast site will attach to the distribution tree.  We
   know from Section 9.1.2 that non-LISP and uLISP receiver multicast
   sites can join the distribution tree, but a LISP receiver multicast
   site ETR will need to know if the source address of the multicast
   source host is routable or not.  We showed in Section 9.1.1 that an
   ETR, before it sends a PIM Join/Prune message on an external-facing
   interface, does a EID-to-RLOC mapping lookup to determine if it
   should convert the (S,G) state from a PIM Join/Prune message received
   on a site-facing interface to a (S-RLOC,G).  If the lookup fails, the
   ETR can conclude the source multicast site is a non-LISP site so it
   simply forwards the Join/Prune message (it also doesn't need to send
   a unicast encapsulated Join/Prune message because there is no ITR in
   a non-LISP site and there is namespace continuity between the ETR and
   source).

9.1.4.  Unicast LISP Source Site to Any Receiver  Sites

   In the last section, it was explained how an ETR in a multicast
   receiver site can determine if a source multicast site is LISP-
   enabled by looking into the mapping database.  When the source
   multicast site is a uLISP site, it is LISP enabled but the ITR, by
   definition is not capable of doing multicast encapsulation.  So for
   the purposes of multicast routing, the uLISP source multicast site is
   treated as non-LISP source multicast site.

   Non-LISP receiver multicast sites can join distribution trees to a
   uLISP source multicast site since the source site behaves, from a
   forwarding perspective, as a non-LISP source site.  This is also the
   case for a uLISP receiver multicast site since the ETR does not have
   multicast functionality built-in or enabled.

   Special considerations are required for LISP receiver multicast sites
   since they think the source multicast site is LISP capable, the ETR
   cannot know if ITR is LISP-Multicast capable.  To solve this problem,
   each mapping database entry will have a multicast 2-tuple (Mpriority,
   Mweight) per RLOC.  When the Mpriority is set to 255, the site is
   considered not multicast capable.  So an ETR in a LISP receiver
   multicast site can distinguish whether a LISP source multicast site
   is LISP-Multicast site from a uLISP site.

9.1.5.  LISP Source Site to Any Receiver Sites

   When a LISP source multicast site has receivers in LISP, non-LISP,
   and uLISP receiver multicast sites, it has a conflict about how it
   sends multicast packets.  The ITR can either encapsulate or natively
   forward multicast packets.  Since the receiver multicast sites are
   heterogeneous in their behavior, one packet forwarding mechanism
   cannot satisfy both.  However, if a LISP receiver multicast site acts
   like a uLISP site then it could receive packets like a non-LISP
   receiver multicast site making all receiver multicast sites have
   homogeneous behavior.  However, this poses the following issues:

   o  LISP-NAT techniques with routable addresses would be required in
      all cases.

   o  Or alternatively, mPTR deployment would be required forcing coarse
      EID prefix advertisement in the core.

   o  But what is most disturbing is that when all sites that
      participate are LISP-Multicast sites but then a non-LISP or uLISP
      site joins the distribution tree, then the existing joined LISP
      receiver multicast sites would have to change their behavior.
      This would create too much dynamic tree-building churn to be a
      viable alternative.

   So the solution space options are:

   1.  Make the LISP ITR in the source multicast site send two packets,
       one that is encapsulated with (S-RLOC,G) to reach LISP receiver
       multicast sites and another that is not encapsulated with
       (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.

   2.  Make the LISP ITR always encapsulate packets with (S-RLOC,G) to
       reach LISP-Multicast sites and to reach mPTRs that can
       decapsulate and forward (S-EID,G) packets to non-LISP and uLISP
       receiver multicast sites.

9.2.  LISP Sites with Mixed Address Families

   A LISP database mapping entry that describes the locator-set,
   Mpriority and Mweight per locator address (RLOC), for an EID prefix
   associated with a site could have RLOC addresses in either IPv4 or
   IPv6 format.  When a mapping entry has a mix of RLOC formatted
   addresses, it is an implicit advertisement by the site that it is a
   dual-stack site.  That is, the site can receive IPv4 or IPv6 unicast
   packets.

   To distinguish if the site can receive dual-stack unicast packets as
   well as dual-stack multicast packets, the Mpriority value setting
   will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format
   details.

   If you consider the combinations of LISP, non-LISP, and uLISP sites
   sharing the same distribution tree and considering the capabilities
   of supporting IPv4, IPv6, or dual-stack, the number of total
   combinations grows beyond comprehension.

   Using some combinatorial math, we have the following profiles of a
   site and the combinations that can occur:

   1.  LISP-Multicast IPv4 Site

   2.  LISP-Multicast IPv6 Site

   3.  LISP-Multicast Dual-Stack Site

   4.  uLISP IPv4 Site

   5.  uLISP IPv6 Site

   6.  uLISP Dual-Stack Site

   7.  non-LISP IPv4 Site

   8.  non-LISP IPv6 Site

   9.  non-LISP Dual-Stack Site

   Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to
   illustrate some combinatorial math below.

   When 1 site talks to another site, the combinatorial is (9 2), when 1
   site talks to another 2 sites, the combinatorial is (9 3).  If sum
   this up to (9 9), we have:

   (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =

     36  +   84  +  126  +  126  +   84  +   36  +   9   +   1

   Which results in the total number of cases to be considered at 502.

   This combinatorial gets even worse when you consider a site using one
   address family inside of the site and the xTRs use the other address
   family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4
   RLOCs).

   To rationalize this combinatorial nightmare, there are some
   guidelines which need to be put in place:

   o  Each distribution tree shared among sites will either be an IPv4
      distribution tree or an IPv6 distribution tree.  Therefore, we can
      avoid head-end replication by building and sending packets on each
      address family based distribution tree.  Even though there might
      be an urge to do multicast packet translation from one address
      family format to the other, it is a non-viable over-complicated
      urge.

   o  All LISP sites on a multicast distribution tree must share a
      common address family which is determined by the source site's
      locator-set in its LISP database mapping entry.  All receiver
      multicast sites will use the best RLOC priority controlled by the
      source multicast site.  This is true when the source site is
      either LISP-Multicast or uLISP capable.  This means that priority-
      based policy modification is prohibited.

   o  When the source site is not LISP capable, it is up to how
      receivers find the source and group information for a multicast
      flow.  That mechanism decides the address family for the flow.

9.3.  Making a Multicast Interworking Decision

   This Multicast Interworking section has shown all combinations of
   multicast connectivity that could occur.  As you might have already
   concluded, this can be quite complicated and if the design is too
   ambitious, the dynamics of the protocol could cause a lot of
   instability.

   The trade-off decisions are hard to make and we want the same single
   solution to work for both IPv4 and IPv6 multicast.  It is imperative
   to have an incrementally deployable solution for all of IPv4 unicast
   and multicast and IPv6 unicast and multicast while minimizing (or
   eliminating) both unicast and multicast EID namespace state.

   Therefore the design decision to go with PTRs for unicast routing and
   mPTRs for multicast routing seems to be the sweet spot in the
   solution space so we can optimize state requirements and avoid head-
   end data replication at ITRs.

10.  Considerations when RP Addresses are Embedded in Group Addresses

   When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a
   technique exists to embed the unicast address of an RP in a IPv6
   group address [RFC3956].  When routers in end sites process a PIM
   Join/Prune message which contain an embedded-RP group address, they
   extract the RP address from the group address and treat it from the
   EID namespace.  However, core routers do not have state for the EID
   namespace, need to extract an RP address from the RLOC namespace.

   Therefore, it is the responsibility of ETRs in multicast receiver
   sites to map the group address into a group address where the
   embedded-RP address is from the RLOC namespace.  The mapped RP-
   address is obtained from a EID-to-RLOC mapping database lookup.  The
   ETR will also send a unicast (*,G) Join/Prune message to the ITR so
   the branch of the distribution tree from the source site resident RP
   to the ITR is created.

   This technique is no different than the techniques described in this
   specification for translating (S,G) state and propagating Join/Prune
   messages into the core.  The only difference is that the (*,G) state
   in Join/Prune messages are mapped because they contain unicast
   addresses encoded in an Embedded-RP group address.

11.  Taking Advantage of Upgrades in the Core

   If the core routers are upgraded to support [RPFV] and [JOIN-ATTR], [RFC5496],
   then we can pass EID specific data through the core without,
   possibly, having to store the state in the core.

   By doing this we can eliminate the ETR from unicasting unicast encapsulating PIM
   Join/Prune messages to the source site's ITR.

   However, this solution is restricted to a small set of workable cases
   which would not be good for general use of LISP-Multicast.  In
   addition to slow convergence properties, it is not being recommended
   for LISP-Multicast.

12.  Mtrace Considerations

   Mtrace functionality must be consistent with unicast traceroute
   functionality where all hops from multicast receiver to multicast
   source are visible.

   The design for mtrace for use in LISP-Multicast environments is to be
   determined but should build upon the mtrace version 2 specified in
   [MTRACE].

13.  Security Considerations

   Refer to the [LISP] specification.

13.

14.  Acknowledgments

   The authors would like to gratefully acknowledge the people who have
   contributed discussion, ideas, and commentary to the making of this
   proposal and specification.  People who provided expert review were
   Scott Brim, Greg Shepherd, and Dave Oran.  Other commentary from
   discussions at Summer 2008 Dublin IETF were Toerless Eckert and
   Ijsbrand Wijnands.

   We would also like to thank the MBONED working group for constructive
   and civil verbal feedback when this draft was presented at the Fall
   2008 IETF in Minneapolis.  In particular, good commentary came from
   Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
   Ron Bonica, and Lenny Guardino.

   An expert review of this specification was done by Yiqun Cai and
   Liming Wei. We thank them for their detailed comments.

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [MLISP] was converted into this IETF LISP
   working group draft.

14.

15.  References

14.1.

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

14.2.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

15.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
              Topology (LISP-ALT)", draft-fuller-lisp-alt-02.txt draft-ietf-lisp-alt-01.txt (work in
              progress), April 2008. May 2009.

   [INTWORK]  Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
              with IPv4 and IPv6", draft-lewis-lisp-interworking-00.txt
              (work in progress), December 2007.

   [JOIN-ATTR]
              Wijnands, IJ. and A. Boers, "Format for using TLVs in PIM
              messages", draft-ietf-pim-join-attributes-03.txt draft-ietf-lisp-interworking-00.txt
              (work in progress), May 2007. 2009.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-00.txt
              draft-ietf-lisp-01.txt (work in progress), May 2009.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-farinacci-lisp-multicast-01.txt (work in progress),
              November 2008.

   [MNAT]     Wing, D. and T. Eckert, "Multicast Requirements for a
              Network Address (and  port) Translator (NAT)",
              draft-ietf-behave-multicast-07.txt (work in progress),
              June 2007.

   [MTRACE]   Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
              Version 2: Traceroute Facility for IP Multicast",
              draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
              March 2009.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),
              February 2008.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dino@cisco.com

   Dave Meyer
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   John Zwiebel
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: jzwiebel@cisco.com

   Stig Venaas
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: stig@cisco.com
--Apple-Mail-92--1022495991 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-92--1022495991-- From root@core3.amsl.com Thu May 28 22:00:05 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 308FA3A6E3A; Thu, 28 May 2009 22:00:04 -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: <20090529050005.308FA3A6E3A@core3.amsl.com> Date: Thu, 28 May 2009 22:00:04 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 05:00:05 -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-01.txt Pages : 61 Date : 2009-05-28 This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-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-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-28214651.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu May 28 22:00:06 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 621D53A6CEA; Thu, 28 May 2009 22:00:04 -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: <20090529050005.621D53A6CEA@core3.amsl.com> Date: Thu, 28 May 2009 22:00:05 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-multicast-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 05:00:06 -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-01.txt Pages : 33 Date : 2009-05-28 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-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-multicast-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-28214746.I-D@ietf.org> --NextPart-- From dino@cisco.com Thu May 28 22:16:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594B03A6BDB for ; Thu, 28 May 2009 22:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 tyaM--0u-Cb0 for ; Thu, 28 May 2009 22:16:25 -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 DD45D3A6938 for ; Thu, 28 May 2009 22:16:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,269,1241395200"; d="scan'208";a="312759412" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 May 2009 05:18:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4T5I60K022163; Thu, 28 May 2009 22:18:06 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4T5I6pY012406; Fri, 29 May 2009 05:18:06 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 22:18:06 -0700 Received: from [192.168.1.2] ([10.21.68.193]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 22:18:05 -0700 Message-Id: <9A759E60-95EE-42A4-BABB-46872FB58934@cisco.com> From: Dino Farinacci To: Damian Lezama In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 22:18:05 -0700 References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 May 2009 05:18:06.0119 (UTC) FILETIME=[D900E370:01C9E01C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2139; t=1243574286; x=1244438286; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Can=20I=20get=20opinions? |Sender:=20; bh=fE+Wo0JBmvUSTrKfAQYcvTsy7wZJx0YfpfwllwPUIZQ=; b=txj18dcjLwj7cOZSO+0x8hL+KLMwe9kb9fYY8ZbvILNUAhDcnnnZ/OKrib MmyrlBxS35itw3gpsbuuituE/MyL10KlQJjncIC7JZoi+FR/2Go8CHkz0e2p MFS3HQ5Sej; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Noel Chiappa' , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 05:16:26 -0000 If we agree to the data-plane format, we can set the first 4-bytes to reserved per your comment below. Dino On May 28, 2009, at 9:51 PM, Damian Lezama wrote: > Hi, > > We have a prototype implementation. I strongly agree that it's a non > sense > restricting LISP progress because of current code at this point... > > That said, I noticed that now we have a different header for control > and > data packets. And I think this is an inconsistency in the draft: > "the R-bit for each locator must > have a consistent setting with the bitfield setting of the 'Loc > Reach Bits' field in the early part of the header" > Because it looks like reach bits are not being used in control > messages > anymore (set to 0 always since draft 11). > What makes me think that the first 4 bytes of the control messages > are never > used, and now the header is already different, so I think maybe the > draft > should be updated accordingly (mark as unused or figure out > something to put > there:). > > BTW: which is the max number of locators allowed in a record? We > considered > it 31 (because of 31 reachability bits). Should we consider 32 as > limit now? > Shouldn't it be explicit in the draft? (is it there but I missed it?) > > Regards, > Damian > >> -----Original Message----- >> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On >> Behalf Of >> Noel Chiappa >> Sent: Thursday, May 28, 2009 1:05 PM >> To: lisp@ietf.org >> Cc: jnc@mercury.lcs.mit.edu >> Subject: Re: [lisp] Can I get opinions? >> >>> From: "Joel M. Halpern" >> >>> Looks like an improvement to me. >> >> I expect that Dino was particularly concerned that a change of this >> sort >> might present a problem for someone who's already implementing stuff, >> so if >> there's anyone in that boat, it would be important to hear from them >> while >> this is still being tossed around as an idea. >> >> Noel >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From luigi@net.t-labs.tu-berlin.de Fri May 29 00:06:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87AD3A6E74 for ; Fri, 29 May 2009 00:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 zet7xhIxwLGV for ; Fri, 29 May 2009 00:06:17 -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 2D1933A6C0D for ; Fri, 29 May 2009 00:05:45 -0700 (PDT) Received: from dyn106.net.t-labs.tu-berlin.de (dyn106.net.t-labs.tu-berlin.de [130.149.220.106]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 5EFBB705A774; Fri, 29 May 2009 09:07:27 +0200 (CEST) Message-Id: From: Luigi Iannone To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 29 May 2009 09:07:26 +0200 References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1EF019.6000505@uclouvain.be> <512C9404-BB44-4732-8655-5C2BBECAB963@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 07:06:17 -0000 On May 28, 2009, at 23:34 , Sam Hartman wrote: > By versioning, are we talking about the sort of versioning that > Margaret discussed today, or are we talking about versioning of map > entries as discussed at the last IETF? Map versioning as discussed at the last IETF. Cheers Luigi From damien.saucez@uclouvain.be Fri May 29 00:23:30 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23793A6C09 for ; Fri, 29 May 2009 00:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdAtvZr1uqDK for ; Fri, 29 May 2009 00:23:29 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 9BB7C3A6B42 for ; Fri, 29 May 2009 00:23:29 -0700 (PDT) Received: from mimir2.dhcp.info.ucl.ac.be (unknown [130.104.228.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 56AAB1C57D4; Fri, 29 May 2009 09:24:18 +0200 (CEST) Message-ID: <4A1F8DA1.8040108@uclouvain.be> Date: Fri, 29 May 2009 09:24:17 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Damian Lezama References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 56AAB1C57D4.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: 'Noel Chiappa' , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 07:23:30 -0000 Damian Lezama wrote: > Hi, > > We have a prototype implementation. I strongly agree that it's a non sense > restricting LISP progress because of current code at this point... > > That said, I noticed that now we have a different header for control and > data packets. And I think this is an inconsistency in the draft: > "the R-bit for each locator must > have a consistent setting with the bitfield setting of the 'Loc > Reach Bits' field in the early part of the header" > Because it looks like reach bits are not being used in control messages > anymore (set to 0 always since draft 11). > What makes me think that the first 4 bytes of the control messages are never > used, and now the header is already different, so I think maybe the draft > should be updated accordingly (mark as unused or figure out something to put > there:). > > BTW: which is the max number of locators allowed in a record? We considered > it 31 (because of 31 reachability bits). Should we consider 32 as limit now? > Shouldn't it be explicit in the draft? (is it there but I missed it?) > I personally believe that you should not have a limit in the number of the RLOCs in the reply (except the size of UDP segment). And consider the 31(32) first best RLOCs in the R bits. You have thus to know the order of the RLOCs in the Rbits, this is an open question that you also have when you limit the number. What if you have removed an RLOC and that a correspondent is still using an old mapping (e.g., the position of the RLOCs is not the same in the two mappings as you do not have the same number of RLOCs)? It seems to be a major issue of the R bits (in addition to the big security hole). Versioning has been thought to avoid these problems. Yes I try to sell versioning! ;-) Cheers, Damien Saucez > > Regards, > Damian > > >> -----Original Message----- >> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of >> Noel Chiappa >> Sent: Thursday, May 28, 2009 1:05 PM >> To: lisp@ietf.org >> Cc: jnc@mercury.lcs.mit.edu >> Subject: Re: [lisp] Can I get opinions? >> >> > From: "Joel M. Halpern" >> >> > Looks like an improvement to me. >> >> I expect that Dino was particularly concerned that a change of this >> sort >> might present a problem for someone who's already implementing stuff, >> so if >> there's anyone in that boat, it would be important to hear from them >> while >> this is still being tossed around as an idea. >> >> 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 dino@cisco.com Fri May 29 10:50:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635283A6A39 for ; Fri, 29 May 2009 10:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCBXqcVp9zz7 for ; Fri, 29 May 2009 10:50:17 -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 541603A6C33 for ; Fri, 29 May 2009 10:50:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,272,1241395200"; d="scan'208";a="313137948" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 May 2009 17:51:19 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4THpJ5C016824; Fri, 29 May 2009 10:51:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4THpJKQ025724; Fri, 29 May 2009 17:51:19 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 10:51:19 -0700 Received: from [192.168.1.2] ([10.21.85.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 10:51:19 -0700 Message-Id: <2B9F303A-3636-4A5E-9C88-D6BC3829A76A@cisco.com> From: Dino Farinacci To: Damien Saucez In-Reply-To: <4A1F8DA1.8040108@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 29 May 2009 10:51:18 -0700 References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1F8DA1.8040108@uclouvain.be> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 May 2009 17:51:19.0263 (UTC) FILETIME=[123766F0:01C9E086] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1457; t=1243619479; x=1244483479; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Can=20I=20get=20opinions? |Sender:=20; bh=tPZ1tHV+tEp6c58hTssRDTNUkSxYaGuBW30pv4U+m2E=; b=PvwM0mco8uj0grl8xAvACPFJJGbe/vyhcj70PmZCGmoxI/k1vfffv0aVV1 XJOrZ/8kEt7+7F7KVLBTPp+rUbWx/9VVjV8aJTiRjQZHhQSLJaFJLbDqJAFC McbztTJFRPmAQW6RiKLSmlXqFgmtPJv7iLZZg80C+ifRrCgzl5a2I=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Noel Chiappa' , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 17:50:18 -0000 > I personally believe that you should not have a limit in the number > of the RLOCs in the reply (except the size of UDP segment). And > consider the 31(32) first best RLOCs in the R bits. You have thus to > know the order of the RLOCs in the Rbits, this is an open question > that you also have when you limit the number. What if you have > removed an RLOC and that a correspondent is still using an old > mapping (e.g., the position of the RLOCs is not the same in the two > mappings as you do not have the same number of RLOCs)? It seems to > be a major issue of the R bits (in addition to the big security > hole). Versioning has been thought to avoid these problems. Yes I > try to sell versioning! ;-) Damien, the spec indicates ways to deal with this. A removed RLOC from an RLOC-set can simply be marked down with a loc-reach-bit so any ITRs which have an old mapping instance cached, can just stop using it. We have tested this in our implementation. Adding an RLOC to the end of a list is simple by having an ITR notice that a loc-reach-bit is set for an RLOC it doesn't have. So it can then go request a new Map-Reply. We have not tested this. As for the loc-reach-bits and security, there is no reason that an ITR can take the change as advisement and then send a Map-Request to solicit a reply which will tell you if the loc-reach-bit change is authoritative and legit. Dino From dino@cisco.com Fri May 29 11:08:44 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B122828C0D7 for ; Fri, 29 May 2009 11:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqwfHkNkobU4 for ; Fri, 29 May 2009 11:08:44 -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 31E7D3A6C1E for ; Fri, 29 May 2009 11:08:41 -0700 (PDT) X-Files: Picture 5.png, Picture 6.png, Picture 7.png, Picture 8.png, Picture 9.png, Picture 10.png : 36515, 34395, 32468, 23304, 20586, 48679 X-IronPort-AV: E=Sophos;i="4.41,272,1241395200"; d="png'150?scan'150,208,150";a="45557233" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 May 2009 18:08:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4TI8rNg008580; Fri, 29 May 2009 14:08:53 -0400 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4TI8rGC023062; Fri, 29 May 2009 18:08:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 11:08:52 -0700 Received: from [192.168.1.2] ([10.21.85.124]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 11:08:51 -0700 Message-Id: From: Dino Farinacci To: Dino Farinacci In-Reply-To: <2B9F303A-3636-4A5E-9C88-D6BC3829A76A@cisco.com> Content-Type: multipart/mixed; boundary=Apple-Mail-102--974640808 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 29 May 2009 11:08:51 -0700 References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1F8DA1.8040108@uclouvain.be> <2B9F303A-3636-4A5E-9C88-D6BC3829A76A@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 May 2009 18:08:52.0093 (UTC) FILETIME=[85C082D0:01C9E088] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=271689; t=1243620537; x=1244484537; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Can=20I=20get=20opinions? |Sender:=20 |To:=20Dino=20Farinacci=20; bh=/c32dLzGyjI6haW0QgaOBp3qPw4SejH0VgX4P4DFM9g=; b=PiPtjQ/NO8cyoclNbcPufiXxXZdUAt3qAsxo+uXWl205WsR5UXkLfVEw6O kV2gP1TTMqzQQTM9eTIfd5ghD7Y2ycm0ugeFCQ7EH25Bef0UL5nxr59Ijh4e ys0CbtBOeU; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 'Noel Chiappa' , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 18:08:44 -0000 --Apple-Mail-102--974640808 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit And I presented this at the Dublin LISP BOF. See the pertinent slides enclosed. Dino --Apple-Mail-102--974640808 Content-Disposition: inline; filename="Picture 5.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 5.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAUAAAADuCAIAAADHk0nXAAAABGdBTUEAANkDQtZPoQAADzZpQ0NQ Q29sb3IgTENEAAB4nJWXCTxUX/vAz52VwVhCQgwhighZy0627HtFzDC2YYxdtkREEbIUiVIqWdpR IUIlLbaSImuRJEt2896hfr/f/30/7+f9/M/nM/d+73Oe8zznnufMee4DACfBlUr1RQAAKH5BNKv9 OgQHRycCtgegARtgAoqAzZUYSNW2sDAF/7X96gYQ494hw7BFOVbfGv36gvAlyiiCR0b3yH8ft97w NNghAJA0zNzkDdZisNsG2zA4NIgaBLMng4meriSYI2GWptlY6cJ8jWGHvMFVDHbb4GcMDiGSGWPf A4Dh8iN5+QGAnYBZg+QeSIS7GX5JpEAiBeYzACB0KBR/2D5HJyyXJFJp8FiOFZjFGOuyMWX3AADU dgPAnP23zBueawUNAP7Fv2XbWQDgDQWg/B96M1brawXxvg70UJBfF0GsOgCg++j0GQl4bhkArKbT 6cuX6PTVywAgPwJQ70sMpoX8Xi8IagPgfz1vvPPvhoQdMgIsAmhgAopD7EFCyFW0GMYb+4rZhQXN 2o1/ytHA9ZF7erPCFpJAydZxwk5RmliJxIAU+041mf2ySru3KmAVJ5XaVW6rndrrqCGiOapdoGul t2pwwVDZ6IWJo2mnma15g6W81TnrZVtHuxoHvKOLU+XB2cOKzjSXq0f63DiJBqRA9wseDeRRL5y3 lI+BrzMlxO+0fyG1IqCO9iZwIOhnCAjFhwmFy0UoHd1ydDKyISo7OiDGMFY0dvXYh7iHxwviYxO8 TlgnaibJnhRJ5k1hO4U+RT+9mrqWRk+HMpCZmLOYs8tZg9nNOaW5GedCz7vlWeZrXJApELrIUYgq XCiauPT5cldxy5Waq5UlF66dvh55w7fU/qZWmWQ5e/laJbiFvc1yB3+X7R7rfZYH2Af0qtnqsZq+ h28ePXlcWXuxLrk+9IlHg22j3tM9TeLNfC1szxDPFp6PvahvTXpp2oZve/3qzGvzN/g3z9/Gt2u2 L3ZUdHp0be3q6E55p/Nu4X1Zj9sHvg+ve0983Pdx9lNln3s/a/+5z2KfywZUB5oHbQaHhoKHscO5 I9Ij9aPWo6Nfwr+yfr04Jj/2dNx6fOhb0AR6IvO7yPeKSfXJph9WPz5PeU/N/IyYRkyfmuGdKZyV nC2fk5+790v216V5tnmP+doFlgX9heiFqoWfi6TFvqXOlai1FDqdsYNBJISAziC0kNzINfQ2zCFs NbM6rp01BU/kMOZS49bhdeKL4i8SbBGaFBHaZiJO2h4vdXZnoIzYrmdyAfL8Cg17vJTxKjfUdNQ/ 7KNorGgl6bDppuijDSL3fzGyM75nyn3Az6zRgtfS2+q29bztPrsQ+wqHIadNB/UOUQ7nOTe6jLpi 3MSIuiQX9zCPVPIVz0der70HfGYoTH5C/vJU44BDtJDAM0FFwUkh7qF7wzaHzYV3RNw6mh5JjbKL VosRikXFThzrjqs/XhqfnRB3wi/RKcnwpHKyeApXCv3Ut9NdqXVpl88kpvtmWGUqnxXOwmXNZPfl vMi9f674fHpeTL7vBccC/YvyhcJFuKJZeDe0Fd+9knc1vsTzmtN1jxtHS5Nuni8rLi+reFzZdOvl 7Vd33t7tvvf+fs+Dnqre6vc1PQ/7Hg08Hq39UTf3BDSwNQo83dEk27y1ebHl9bPi5xEvLFulXoKX 3W03Xx1/7fRG9i3y7bv20o6YTusu8a7Z7rp3p9879Uj0TH2o6o37aPgJ++l+H6mfs7/+s/+A8EDb YMSQ1NC74eMju0a6R6O+iH15/tVvjHOsctxy/Oe31IkdE83fXb8vT6b/kPzRMOUwNfEzZppr+tqM xkz7rNvsz7ljvzh+FcyLzecv8C0ULu5e7FxKXyavEFfj1/LoBLoDPY3esh5/HmAMzkEQFADNIVKR e1EA1YvuwPQyAWZpXChLC5s4Ppl9iTOAa4Tbkad1swpfMT9OgCxYK8QibEHIFenftl3MW/y6xJCk gJT5juidpdLtMr9keeXkd5vI2ymQFal7QpUilSNVIlTD1Wjqnnvd95E0PDQ9tFy0nXSsdE31tPUV DET2cxgCw0mjHuNGk3LT3AOxZh7m5hYqlmJWeKtF62GbN7a1dsX2EQ7GjjyOg063DsYeMj8seHjc ucbl5BE7V3HXWbcGYjrpiLu0+6JHMznd08VL2mvBu9HntK8dRYDS5XfCX86/hxoXIBHQRgsO5A+s C3IPZg6uCLENWQotCjMKmw7PizCMmDt6OdI6ChNVE02JEYvpjc06Zh3HHvfyeHK8XgJIqD1xNFE5 cSap4iQleUfyl5TiU26nhU73pualOZ0RONObnpfhnCmSOXz2WpZPtmIOIudt7sVz/ue18jbljeQ/ uJBS4HZRtZCzcLyo6VLR5bhi0hX9q9tLmEu+X+u4XnOjCN5lQWXO5UYVypXbbrHfBren7wzd7bnX dr/xwYOqu9WlNVceFj7Ke5xbm1OXWX/6SXJDYuOJp7FN4c3BLdRnHs89XkS0Zr4sabv/qub1kzdP 3ta3P+/o6vzUNfOO/71xz/EPzz4qfCrvNx5AD44OL31xG2f/Ljv1ZS5j+Qoj/hu5j9EwSgBkGQBg 9xoAq+sApJvBqY4D3iBwrrZgA8BGFSA+SgLEtTkABSr8lT/4gDw4ADxANMgG5aAZfAKzECskCqlB FpAnFAPlQOVQM9QPLSA4EJIIHcQhRAjiDKIU0YwYRNCRAkgVpC0yCJmJvIPsQM6geFDKKCdUFOoy 6jlqGi2I3o8ORF9Ev0QvYiQx9phETBVmDCuItcCewD7GzjJJM3kwXWLqYxZkPsicz9yP24bzwlXi Fll0WTJYBljlWBNYP7DJsZ1kG8Zr4wvxa+xH2Js5ZDjOcgJOKucAlw1X2ya9TXXce7mredR56nj3 87ZvPrz5G1/UFs4t1/l1+fsEogRFBJu2+gpxCT0SJhN4CE0iQaLiooPbmsVuixdJJG8PlyRL2e/Q 2yknTZBhkfm1a0D2hdyd3fnyxxUoirZ71JVElXHKsyp9qq1qteote3v3TWpCWlu0pXRUdQ/ouejT DBL25xqWGzUZfzJZPrDFbI+5s0WCZaXVBxtOW0O7BPunDqOO9IOEQ9qHPZ2zXOqPTLlJEEmkYvcR 8k7PEK8mH15ff0qTPz81KKA1UCIoNvhdqFzYyfCho7SobdGDsVfi/OLVT/Akzp3sSmk+XZVWkX41 syirJKfs3K28qguNFxuL+oszSg7e4LvZURF7W/Fu/4NzNTaPuev6Gx41nXkW3Up9dfRtcGf6u4cf PvUhB4yGS76e+J49F7youPRu+ftKz+rVtaL184MX7AYm6/HPAZXgGfgMFiBOSArShhzhMyUZugw9 hrqhKQQOIYbQQDgiguDo30Q8R4wiUUhRpBbSBRmDLEDWIwdRKNR2lDHKH5WNqkf9QAujLdHx6Afo bxgCxg5zCvMUs4JVwgZgy7ETTDuYvJlKmSaZdzOHMD/GoXHmuDzcVxYlliSWXtZdrCdY+9lU2bLZ 5vC2+Cp2fvZj7N847DgaOBU5S7gEubI2cWxK4WblTuHB82TxCvGWblbd/IzvIN/UlpP82/hrBQ4J rAkWbdXfOiaUKqws3EdIEVEU6RdN2eYspikuKYGXmN3eJ9kidXdH/s4k6RAZ4i5LWS052d2i8twK zIqQ4vyeH0rjyl9VxlQn1Wb3ovfxaezU1NJy0PbROaZ7Xu+W/kuDEUPISNhY08TVNOnATbNuC5Sl gtUR6xybdjsW+wMOYY7xTpkHSw/VHv7ovHKE11XN7QgxlfTYfZws6Gnllezd4AtRNPxC/e9Qp2iS gWQ4L/aEcoWZhCdE9Ee6Rc3HpB3bHlcX75CwmJh3Uj154FRq6t607+mFmfZZW7JHcsvPR+fbFsgX 4ovWiiWvulzLuNFUBlXo3Dp+58192aqMh4jH4fXYhrNNSi19LzLaXN4Ita90jb5/2lvWVz3QPNz/ Ne1bz2T+1JfpztnAuYX5u+vxFwfmIAwUghb4K5ILUoIOQbHQFagV+ongQ2giyIg0RDViGMmB1ED6 Ii8gX6EQ8D/cD3UNNYQWRRPRV9BfMTKYQMxDLBprhS3CTjPpM+UxzTAfYC7FseD8cJ0se1lusgqw prFh2GLZ1vCx7Aj2ZI7NHJc4ZTirufZzfdwUwM3CfYVHn+crb/pm9c2jfDlbTPgh/hqBEEFlwYWt D4WihPUILIRukYuiPtvMxPaJK0rs2C4quVVKcMfWnULS22V27VKTNZJz3E2VT1K4qti4Z1gZp6Ko SlTLU5/f56XxWYukPaJL04cMsg2ljZpNXEyXzNIsJC0fWZvYfLbzt19zTDjIdajQWcWl1ZXoRicV eWiRh7ySfRR8B/1SqKoBI4G5wfohc2HXIg5HoqKKY4xjJ+My4hUTPiYePymW3HzKJ5UtrSzdMGPg bHS2UM7Dc7bnf+anFuy82FDkemm5OOuqUkn7dXIp+ua5coWK1ltetxfuZt2XfvC0+nDN7KOUWsm6 50/Ijdinxc3mLYvPC1pN2xCvLrwReFvQsaOzrpv8nqmnutfnE76v/LP9wMQQZXh41PpL9Rj3uMW3 4xNl35sn3/7onGr+eW/6zIzvrPTst7mCX4a/pueTFgQXKhZlF28siS0VLCOWPZZfrOxaSVx5uyqw 6r5asbq0dmCtmi5Bz2DEf6NeWm84XX9ffxrBVFfvfxR3/99G8Q3+44ML/rH6uZmZ/+av1CALm/VT CIClwBBrffgO5yyIw8PLwOg3E0iueiYwC8IsF+Gpa8awAbOpB83AamMs5ODtamwBMx5mP3c/W+sN +1Ak1Xe9xmVwKjVIx2o94wGo0D1Q/49OVYSnjf3vsS9owVa261/VcG3p429i9dvXCsld7/fcEEx+ vmamG34RfF5BRuu1LMy7gAFwhasxMnAHMsAU6AK931cCLCfA5A/3uoNAWG94Xe+Plt36s9e/jZKB T2WGvZD1MT5gFGaKi1ccDbb1f60TYcvBwBfWCwY0uVK5MbmVv3QYXn3XPf+RmPyH5I+dv3W9AAm+ /9P+upzhnXLbIyTXP1zNzhMlgZJH7UHpoPahNFCqgIDiRfEDGZQiSgWljdJEqcN9qq8mHkz85Wdj fdz+ek+TP3OGr37/sWbEf8wGbNTv6985cAzy4xnUmLUQ++97Lcg9bL1G1vWnhtO8yJ5BBG0q1ddd mmDkR9wlTZCXk1MF/wKDW3gdwfXxVwAAAAlwSFlzAAALEwAACxMBAJqcGAAAACJ0RVh0U29mdHdh cmUAUXVpY2tUaW1lIDcuNiAoTWFjIE9TIFgpAD5Cch0AAAAHdElNRQfZBR0SCAEzCir1AAAgAElE QVR4nOxdBXgURxue87vc5eKuhITgEJJAsOCuf5HiUlqkxUoplEILFCktFJeiLR7cimsIDhEiRIi7 3+Vcd/+Z3cvlEkKQQpO0+z55LrOzI9/szDv6zQwNx3FAgQKF+gl6bQtAgQKF9wdFYAoU6jEoAlOg UI9BEZgChXoMisAUKNRjUASmQKEegyIwBQr1GBSBKVCox6AITIFCPQZFYAoU6jEoAlOgUI9BEZgC hXoMisAUKNRjUASmQKEegyIwBQr1GBSBKVCox6AITIFCPQZFYAoU6jEoAlOgUI9BEZgChXoMisAU KNRjUASmQKEegyIwBQr1GLT6ci70nbslXYNtalsKCh8BGJb8QpKWo9bogLU9u2UrSz6bVtsy1Rsw a1uAapCXJS8S6R2c2Ht2ZA+a7NHSjfVjv8hLRdjwrxTfTXarHZlw7OYtUbceNh+5x4JtWJf5vwmu nvaV8uX8xrSjMZqDe3yZ/2TBxvU3b4m797D5SHFO6B/xovC1jcfmYy06NGR/nJgRRPmKmBRNcEfL jxfFP4O6ReDM2NJPJqWZ2oRnJZzc3aJlYzokcGmOTAPAR8zV1+PXebHHw7Qcs6x7oa1pH41FIwIi YeIPh5Y9Pt+KUR4LrlL8dKgUGvZcTJs+sMHHivsVfDk25kmS3r1J4emDTT5G+OLiCvZyeTSBAH1X uRRTqJDN02fpHRo2esugEl/IXLz5gndpt3sNjIe/Sw57D/W1eAeh6x7qEIEjDiZN3SStYllcipUq 9D6eAISBAhmGYbUzbPfyFIAwEcObWShVOgh5HyUOvc5QdeXpCotETvZW5NPzC6WkYd8e2cS+OO+f aoUb2nKeJCl4bniJUmfD+/DlxNGNnpuBjf/JYoAvnU6DHOabmXH1Wo2kTKpQ4Tze2yazJKZ47OQM OBh89MSPSX9bX3AwVgKzlVmiw4Rv76sOoq4QOONZDslej2as1T8IOBy2OFL++U8yDoumVqi5VrDd 1TkI6BiGg9r43MPnePUZX1Qkltmacz9SFCXpCqP5ZancSODbEWLSgGVrVEolz9zsIwlQBd9sbjK5 MK9MobH+COxFICZfzPg074ZeptY2tnbvFAyTRdboeKFY7mwteEtfV5+1ycpIByxBvWYvqCOz0Ooy 1bDp+dDg5cdeu9TcE8LNtfVg3x+/s1q1mM/hVfSa6e/7uW+cK4jJ0ZJmvUYvFmvfNQRzazsvrwYM ogOd+7Ls5CVDwwgwXCzWvJ9UpkiLLzGa74crjeZL19VGs0LztmJLc+Xb9+TV4OD37TlpIn3NgVjb OzXw9CC/ePzT0sthEsMLPf4eH7AKaIw3Z6WqVHEgpNDwgAP4nVEXrDIEDob6RaN6J5Fobh4N3Jzf rbKA0Cp1+3dmdwgKDwiIULwizD+POtECfzsxDv1j09Ys4rt4eHLKs3bwcEPdTBZtNpem1+p3rk3e fVYGH3sOt1/zXaU5rfC7JV99m64jiiXPnLlxh69/Y9Rg6iSK71ZkA5B9917zORPjI1MMBffmPT8L rrEKw+9dL9nzR05skg4+jJnmNO8LZ2PI57a+XH1c/uhua1KywaOT4W/bQObNvbnbTspJNztPNvf3 5Bi9yEtVp0Ly/jwikqhwayfWstU+HVrU1Pe+c0IEf6F/yNekJ2p8LEBx6TXQFhpwmFE6UCpTudhU GrPdvZQ/78cc0mznxlm33qdZAyTDrPEJsWUgsJs+6ZZmw04Usm8H4Z5NPmTPNPF2wZ59+XuOF+/8 2W3l8oysYlQSV25p1Le9uTHkPT+82PdMf/9yCzLJ42egDn7bW40Prk49dMNQYZ280crTsqIISfIV x47kHThRptTizl6cn1b7tPau+CBVQFKx5gmFTr3RSNW1GQ1/oVy4toi0nLrce+oAC+g/oG2kqePh g1NJw4NHfmwmvW+HcAs/y2NbvE4dTPt5i4h8df52a2dzBjSM7B3BCrQ5vMqjQh4dtvzruIsPDUlz 8uXt2OLras0wOjh7MGPlpmKTCPGw5+l9/DxrSsDHR+23wMrskgfZyLBzp4Wtowvn9RUz1wx06RhF shfixsnCbw+kG98uHBE+bR5iL42OioVSqps2Li4qQ2Uawoi+sSR7yTjmr0kg7WHmwQp17qIMyF46 8UmO7MwLCAgv0xsmWq5ekOgV+hephlEq6X331y9J9jKIXJ42PFapNdTJiReTu/SO27yvFLIXClOa p509+UXAoPgavkNIHIqrc2cU/ct0fZkaBRUTgsjJsKIDVKuA7AKFqZcvBoaT7KUTSS7KUk8cEavW I4+SMuRgxqcFJHuRSA8knQPDyQTJxERwMt20WWkkeyGWzEo6FiY2Bn4tTKkp0iSkZ5kmeeWkBJK9 5FcaPTBajxk+0bW9id0Hxu88IobshcLkpqo/HxUbMDb5dektK0XxNrAFCoW+oED19GHxujVJg7pF ws9+9J4hi8nSeWFbNsleJlFX7FqaLFYi+astKTD3s7OQzMUakPJYHNA2gmQvWVN89lU80XPXp5bi ibdL0/PKSF84hrUNiiTZS+ZmXqJyaO8oqc6Qui6dI4zs5ZnRBERV/OS5GtQ2ap/Aq5cj+lraMq34 LKFZ9RW2DqDMPruPYAsTbNthMS4YZWb0qTItUYB2ro6/SZDru5+FISFWp047kB7pqlz4yxSwyMcC WDCsGYePWh09gkaYkXc1IpkG5l5wB1SXOzdiHjhkCb0fP2bdwhG533c7lczArPLuLflI1tuXCfpv 3Wd55IhhvJpTjAiQG1c0dikqGTOXmIccszp23ObAPqLZzFNk5uRX/xUwQ/fvk8/48FeVo5MQQW09 i3592nP9ibfJSRW9xDmToyOJwH7eYmGa5Bw4tIOptC53x6PDz7Vzu5B82nclhfjaLGM4M78X7Nlj 0b8pKuBr56fKtYYiW0qSCDfQmwwvLBP97jlgSX5ArQbPLkGZcu9Y1vc7kIcla4THjlkdP26zayPR mCeW5RRWDA1MkUGEv3CCODg4asCAuBmzMkJOSvOkKLrflqWIZYgbLclInyHLtTvRd7ZikN+5EFYh j5+0PhZidfigIWlHQ6xg1CFHrTj8SotD/Kas/Qctl4wlihYOdJDBGqJap6MEkG5+/uI58Z926IhV yDGbUyfsfInni6GoVRdnyeRK9Fl6jTeDGXrggP2xrfbwsbMf6w2DkI+P2u9C34hEtelPG81d3F1f 5ybmvqHgmtsy9m4X2jm6tFutO9QpQYfhIqXOnk/bfRo1TfN+tQj0Fbq72NO0MPsLoI0ZG2WbTlZR 7g/tELq4uAq4cFwdDiSYSil/fq1EBUuIHWPjSnMXNw8OC5URNkBD3Aa2NERZGiAramMPOL3csHqb pYeTtZOdFQoNjjxlqIYYMxEV80kLzbu3Fbo7EzUBgBkdRajNVD9sSn1gGFHb8A3UkuhQUOFpyP23 4zm4JzZlu+pJvE6DA2K5RHs/BiVq+RYLX08rdycboIZfoIAGu8h0JKa9CwOU6t268X6bwXV0cTXj sHcuT5+2tGTvRtm4npiNgyGWPw5a2dlaOdhZtT4ArgeEa/V4RkFRU1dUOsm23lihGlm485CVq6O9 raUAJRkDKokI2AkWrUUj1WXbLFt7WLg62iIBhHAY/wImGXt12Ep+kcprwM6udE8vhpsTA3K0ZSAL J+rlqPK3kxcKGzqaw5x1dIgU5WKlMoJ4NEZDby+gh3kdi57Y/IbuDlViad6P9+Nkrqu7h3VZITiU y3FCmauVIO8cvrEF151+jsFcPhpi6eTixtLov5yalEi8aOiC3ChlZEtLa+vN9vDyYhH+wu5aqjQ4 A9Qyap3AOMktRw6dw3xzd2DjNqGdq6c5mw60qO5TKnCdRp94A83WsG0ZQQ0YHi6o8Bk7Fgx2pUnj cd+YW1raEOw1xo99sxrRc+HXAit7F5K9EAlE49ZESCP7joaeq+GpHFYMb0cOwd6K0DCZnGy6+voz 3QzsBXgZioJlz2DQq//gl6+QUzUMJt/a30EUXoDvu61e0jwD2fHo5myW4xBrsD0l/q5GJtNYm7Oj 9qKuqZknq5kzF7G3PMksNo3ORTOxTA6SNLgP292zATnR2tjPDtJQV6KXyeXc8iVTC2sbRzvDoNrJ hpZZgueJFU2JipRsm2j0SkXUqQXbisch2GsEpheVQbIyzehN7WgkeyGkhSjJXC8Wi8kCr8fx49Zs DofJhF+GzmSxOBwOm8WGj5Uc8en9AtjuZM6Wf+gKI6P8k1ZXU/w4meflhRbPnYKctvyicGiA5s40 SlTozMxoDC7q7xSGo76xtSdbIWIt+P7FkxQdkXDwzWoLB3PkwNpZgKYhAL5qqXjV0nAGk7Fpd6Og Fua8f2hBoCbUOoHJj05jMN4siX8friWHh9hbDtgb0qp1GXGosDX0ZPJtXAwvGIYSQKMhx3KRjnzs 247paFN14Z4c9rm70q0EJlNQxC+LVmnWuwp/f9tg7uTkWDW0dMOomyu0M7qOv4SGcJ4+DBZPWG3S jlxBSei9SGBnxQ/ubB5+UhJ5RD5UgdbVeg3k8gRWHHLxWalXKiSwH5LwBLUJ7dqwLOzKBWAxTZNs ZoNmvXA4Gi2fJirXmcW1Op2VpYFU5WswpAP0WyCp1CukMyrVqst/4Hu4OYPKKIhBVZaFFY1nXdGH ir2MqqQ2HVgcbk3FnMZgubpUDbAKJn3BF1rZv/69IYHaatS6aGyCoiTa92ho+g6WES6R4xnx6OOL 0zRTpiOZYSXYdzRv/ABY1GDfCvXGORacp0+ajBuVlJWnlyuBXqefOTl+wiKP2cNsa5b8H0Ctj4FJ puGvjiXuH0/r2i/O1MaCR7d3djI8EMTXwhZYa1hxgZ1TS6Gxaa2ULkkx2czTuJwq7K3Ic7ZJra9M JxdgaHQ6vTrXhpreiUvjsSvVO6UyY4B0vllFO//9ASSkDZ9uJqhukK9Xkl20SX50Dos5eCRq0qWl eoUKhTZ4CMfBRkBn0S0JAcNMlothkgVmRgEIQ+V5nfhYnVFqSGaD9CYFvZImPGFkVy4R5Q4M+WNF ZzIqr+Rpyqd5mHS6ecX3B0uOoG/uZk3jcGtqgatUEJVhCNnPj2lrWWkCP606HUy9vtoppder+tOA jpjww4gEkZn67UrhoUOW00Y5NvDyItlbLqjZoWOtLl/2gaPu3kQ9cODnDJHsAywf/k3UOoFBkDuS YeykYuOgCNPoxv0vas6vpbIi1f2XOaaOK8oOh2CCDtdrVM3ao35yao5OV1ENGNKl0Jl0q7gM81eU qLR6PVlFxyZWZEbfMQSBBbAxq6S4Wank0iG9q/YaSsV6C3eSophCa5CmKC4/uwiZhfZwmFDNzGnm TXKBhMYkZlbNvUz3bNAcDP1dmq0ziu7KUdQst+2LEvI4TquvSB9KsqYMx/WVKkPjoHvVzJdIhjZc NqOiqoL9F4NJI88SoQxoZV+pSNBM13kYdAazqiarRqO3a4qEKSrQqdSGyKKuZpHhOljR2X9bdUzI qRAYdtThb1qWzuT9+5dhBjGR7dkYJYprTj9+3KpPR2cvLy9HOyv4QpFRNGBgdBlWXgnQaGYCIRx1 rz7Whk/kfGFJ0XtH/aFQ+wResxkt9mol+naB4YsWJ48eEtW2w/OELFQK/XpynZgoq/KJKRSugGY6 9CH/aXVal26o56Yp0K/ZiAaNOo3ul4WG9aFH0aiDbPBFx1kmZZccHOfKNX9uQjMfm5ZLzt0RJ0SK OgWEy4lmR2BNp9EqUbRqZW5Cb1JtNyVZTxcKyDnqqdNSM3KVp/7I6jcxh6S+vQuj2pWPi5dRo8q2 hj10sn6htS+ncOAwnrnQ0Oue0QFVDbHPNKUKndf/UCugfKndfQQN1rVK7Y9fEb0VHM+QiIwhRx2V /bQ6fefO3Ckjo29ko0+6fAaXz6/oVc5bkLtla86mtekBHdAXc2rDZnMq1XG4aXtNw2n0iuaU7C6n iHGmrbUdqnbxabMScvJV+7ekfb7YoH1hZUF7XQkjO9Yl6rdQhjDJBR9zJEBKmObVhlWre8WqRsik uJ5Y9nPwd4RpVkmxcXMUEbE6uUyXmlS29bf04GGZBfna0GcpAYHhAQHhB04WvkxTvIwt2/hzipyI i/aa+bl/ErU+BgYCV4uzB9yHTkAzt9evGtblAJf24yphCw+2h6c7fDpbiL6Uhw+DY1IcmrABHLzE l+HNAOOr4fxtJ+WXjxbDP9PAty+TjOmLW5GrJgpca9I6WfCBSg4KxNqgjg26BIpCn2pWzE8hX42e yz+6Vs7h0hhcQ2lmGyZ1yGJDCAFLtkmfbWAgbf1TvFCCazBwLKxl187RBcnqYYNfINcMMD6Qvv8R xhfQqp20zCKaQQc7Bkto6LON+Nzm4S+o0ho7gG1haSBw56lO4FgyUGGy0iJrM6d+7diXH2v2b8yB f6ahfTNO9OiJO2mGze+lc6XGV21Gm7lasfgchq5c0SszQb0/wbCyxbGgb/iOb+dgmMglNEeMXWhC cB0MsKKfEuRLO5mIp5eg+eTTl3x79k/MiFIOGYjqERaXNsgDP50I2OzXErh1Y+aDBN3UTwvI9QJT 9JzhumaKg7HHo9NXLCJ0bsE8HQnkalyhB3zD1zSwiMV8WzrR2cgnrMx16MujWvjCqUb9hiVp8tQL ZlVauG47kNfcjkHm/uY1WZtNXrkHc9msmkYH/wxqn8AQrk3tnjy2vHMxOTJVb2lJ7xLMhW2fhY2j TXmP987dVhs2J3RrUmnANHme7eLfij3MAewmT/6ucdceyRO/kUCGwnHr1z+Zt/ZgTJ4o1uKgqETk 5mHJN6O1+7TSbIqDO7soSeNmiQrobztaFGVl7flDTOPQRo4wo2H6owDw+TRu+br0g8ct4lOyaeWl cVAr5uMS3HQw2H+ew8ax+R62NI0WM+ex7j3zv38j4WqY1qsxK7gde+9XqGKysqq+M9m7Be9muHrU HL6dtSG9wSM8BVtLO4zjO5tzjINSuoWFJROU6YFOhwr0im0tRtxMmrlchpLMAD+sFXrbMSZNEGE0 vEBkUISw7s5trdZmFOEuDZkzJ/Oh/A083U2jnj6Fc+WmFn7AGfPMfZzpto6uZuU93kePmiWm5TLK +yxtPBlii0r1T/uRVqdXlzZxgMMQnGcvuPek9Y2/EsMi9S3acPybMX8eiToCNczTbt7fpGPnGHV1 o0iVUiRR2AjNmLO6sfY81lmYFNIOY2zoh6Q2FnS5SscnO7JweMqjwabUrPKEOZtFA/bVr/KwHWyu XdCJlXLjlISlh/mDJ363LiSs+k2lIxYOh002G9SFDUdJnp7uD566/bnhxd4zWj2aFgRMFm31egsX K7qba9UpzH8edWtDv16Hvh6dQJVXOLGeyKhsLy8TSTU0x/LJBuhdqVLAURnPzIzLRQspBXm5Qht7 NNWEY1KZXCAwNx3TFeRm6Rlmzg6GDiuOY3AYDUt51uW0EcvL2vbirVzqa82tvhDIZVI2l88yWfqS iwuLJWp3dzdjDHq9DrbTkAP9e0QWS/Ddx6z8KivuG6GQiMQKrbNjpZUSpULJ5ZlVUjbEsZSUdI65 hWu5zJDMKqUC1hpmfD6Xw4ZpyMnOtnNyWb80/uRVld9YwbaZDclxMJ3BYJazUSeWBfVEK50nz3u6 2AlxYraaVU17gpsM/HG5TMbhCZgmwwBJSZ5Ijrm7u1SsqBI5CCMKDIyAjweOWTV9TZIBWoDSZWZk iSUw39AcOMxbFosGOz4sJvBo4EXGo5TL6CyYsgoSqxWSgmKxm7u7yYfBc3NyrewcKs0p4vqsrBw7 J1cuq/pOAJnqKpbwe2rUGmhPZzJZTJap7r1Wo4GZrtJo4DjC0kLI4dTKxtaqqBMtsBEM5mvlodHp rzKJb2HFN3mE3gWCSus0Dk7lSxQ0urm5OagMB+dKqtQw11hEZs9cj7T2A3qwha9hL4paUDU0vqV9 ZRUggCgDySlSQPbCRwv6a3tcZkIrs6oLTDRYDVV1R6Mj1QUTwGImMDeZWqfRXNwqJQp+NmZNS3TV 8rbiran51SQLbZyElU9JYRI5mBdn6LdzGTVt3oKieXq9YYczj191gxHHTOjuXuVj0ZxdXKo4AzQG JHkNIb/KXkB8T+ZrFq5ZbLaldZ07E6ZuEbhW8OxmSY4CtPbj29uyFGLNxiWJBVLEt65eb7E2/Sow 7My5EltHVrMmfDMuPeF52edfISXPlgN4XD7/jb4/LHjCf2SvnF539oLY3pnVtDGfw6JFPiydvQDN aHScKDC3qt/b5es+KAKD6QvTX7WcvVxoZv4+562UpYpXrcqsYskS0L6fyLWzta7Wy8dDAw96zdt9 WJwPUAAKo4pWrsytYmlmz5g9gGUt/KfrrP8aan8ZqdZx51rToKZG3UswdDT38FGr4JbmjqY6km8N C2/rDYvM7Mv1bAX29BXrhIf3WTo4ub5mLPZR0MkXMcffhV7thj2mBTlbxqy2G/musPd3/OErrnX5 GRp27oxfNln8uVXo4ubxFnt+Kfwt1K1JrNoCptep1BoM06OpFAaDw+Eya9IQejPUapVep9djGGQI HJnzuB/rHI8aIJeIpErM0aH6YRuO6/PyCmztHdjMD6OQr1apiBSjJMNhJJf72p3AFD4gKAJToFCP QXWhKVCox6AITIFCPQZFYAoU6jEoAlOgUI9BEZgChXoMisAUKNRjUASmQKEegyIwBQr1GBSBKVCo x6AITIFCPQZFYAoU6jEoAlOgUI9BEZgChXoMisAUKNRjUASmQKEegyIwBQr1GBSBKVCox6hlAus1 ylcth/cILMHQqZ+vOyvE20kYX6j64MJcOrhm/YnYL//XM6VQXvkNnp5d9faA1wFTZps7NHzdW71a NrpvB5i0yFwFDDbpZeq7i4nZc8212Puco4KVxY9bfvI9PFKos6hdAmvNOWbrLsdXsfXWv+w5/5Y5 HdxPl1bnC9dplHnFiupe/S0smbDIzNlix9mbHFalsxrz7u5t4Ob5loGUJEbJVK+9tO7bbuYhV7Mi ouNaO5tJUp/6NvKRat/xfh2duEgte4W/Ohot8I1eXxxflyyq/Qv1KHxA1CaBW9LYsP19HHqhiv3n P+yI2rDCy9ftzPGr1XrU69/xHqu3QyQAYxqgS0mcrSodyOYU/DmOV+op5GWmvS4QOotp8fqzVDc8 BBl4ll+LpjQAhF5tcVxv/q5nVaLrXSyY9CrHPUJaPnuzX62Ky3rzEXa49sP3bih8LOAfGPpjx7K1 +je7Sw4LgbH/Prcnq9nINzqe0LYVdGxmZbfz+kscx9wswM245EYNPe3tHWKLVIQTTVPfhgKBwK2B T0qxoiT2BrB2H97cF/qydhhCBhJxZnsDD3d3D88NZyMIC2UDVyfkxdO7TKGFz+fPXtBrZGfPXq4S +9NdXw6euRIatOqShh6GGwDWhxWYulEXRDk72FhYWHp7Ojo0bEbYqUzDVxVEt2rVEnr0aeTj2aBh qQ7PfHSiiX9n6G7roO49x03xcETHR36+/QbhV9vEpwH06+ji/ii5BH1WrRpGLRRaeHl7AzMH0w/c jgsMJ8azgKWrPxL45EYXR3t7R5cHeWpTIWO2jRE6NnCxt2YwWB17fEtaaqVZ7k52MC5Pb18R+gyo cX+Sr3hjplCoC/jABD72S4y//7OOX2W8ySFqQgfOPq/OvPzGSiTlwT7oJjVfdP7Izh83nCUJDHgg +NMZXwxqA5xh84h72QJXn+65RSW2AtaGc1HFzy+TNEtOR4NMDY5f/W0ANFx7Ep8QcZ2M0dWc22PU jyUlhY0A6Lz0Yg0CXF81sGHf6ThRspsEj8jIEx39ecaFWJHRgVaG7gdc/uf5tMSoxkLg4tsCWjay 5qPwS4vI8CWpYXO+ngmdbdiw4ezZ8zocT7r5O8/aGbpcP6gbtHdv+1nGkz0AuEKbic1dLXyHFotE E4NaNewHo0a3mY2ZvSQ7O21wcAtg7oqZiCcryYt8GgYdvHiZkpZbisvRHatfrtm1YtxQJtfGlOqQ wPDVzqNn0uIfozroegq0dAJg/ILfxKXFbjbcb345D21KcjMx0wgo1GF8YAJnRBX36BFx9YW6Zmfz x/Yy7QVkampyDB1suZ9lYoEI7NlqCjS9eHgQgEGqdNgJF5CvrDmwcS4piEDd8uJy70ridq97L0vh o16aAgAHx9EQ+vq5Q/CXzeFlSJQ1CLBmULe+0xdBgy8hrbtvmyuPE00dPA7ZIBD6k+bLaxf4tpzz mvA1prXVrV3LrZ3doeHngV1gRwFZ6XIJB8hZQvgt8kavkKfp0uxYOpdMIC5KDLVw8a32K5Fdkd+6 A2vvrwgj6vaXqSso/OKP8V0WHifNKfd2ANBPlXUDcDwvH9qEEubonS2pMSco1D184DGweyubGzf8 ejep+eI2bN3h661HTkvMQL3QZkyw51xSzcFO8neqYrM3ZC38NUPXhV3IfR4OvDoS1jSuAPUmi7Jf 0G0bGE801xME9rFHr+LvHgc27kCRCIDn4LGzzz1IVqsU7uY1HbwOE0MOORNwXFyQ2dKd27edr9Rk GilHlEH3NVZJOIariPDdYfgnQhNfFz6j/O6w+wrxwM8mI5OWuBdbA38tmrYduHzXdfh9Pg3wUMhy WcaD5nGA1Xiv9MN7YNS3fctjqAS3gCCgN/hlMniwz10QG2lllj5i5sqHiQV43ksX4vrs2b3b5Mu1 gEK9wD9fZ0QcWgDQ/dgGfPG/AM+AvjW4h46HLkPtRk7cnQGfbC4fA6ORYV4C6g9r80Lhrxw+Y3pr PnvlvtDY878Ymyn46nIGmpqatvUmrpcIuAyrhrC1ROX49JNU6EAlzmAw6HBQ+jqsRy3wQq28oFGT ZoTYqHDHyisc5MfeBDTa4xwpfGUpNCO60NWGX6kFDi1vgQd2bzX2y92EHbpTV0X4nbfnJrLQy83N OHFidNn3z0fvQYtxHa2BwPXVHi4ob4GjNg8BTAE0/7lqKhDYmrqUxmzjtsEc3IoAACAASURBVBqh 1OHy0jQOAGtDUzEZumT0YToaDkjzotl0FjR4wdivJteQIxTqDmqBwLN6txv2xU7joygBdnc9a3Av L0o1Tp1uPn4FFmpbALLkqGeoLkODT5kOn9WvA+mgb4/WgNc2+fo683IC+wvBumtZ0oJEARf1SNf8 usipWTtof/3sn8Za7Ocdh2oQ4MrP08d9/adOKTK6d2joV8XNoa0/kq8adehg5d4Y2ty5eLhq+NpS UwIn3Djo4DoOGgb3Dhg30yAAdFCkw1Ni7hr9Tlu0Dton3T9EPjp7eMD+9qu1jaEKI9DI04F0HJct NXUDCWwM9vNlhiy4fWyd0XLjcTSFhmGvr8wo1DH8565WObZi5k8X8+IenaqFuHHFxEkL9u/fWgtR U/iX4j9CYHznth1evk2APLf30HH7w4sntKlzNzVToPAe+I8QGAxtTDuHhnvg8K3oMd1a1LY4FCh8 GPxXCEyBwr8S1G4kChTqMSgCVwOsrvZK1NqPogROof6ifhC4LPVuYl7VnUl+tEoK/eunBEbKAcDL Bo1Z8HfiksXu777g+Lv5wTG5+p2ohSnV76EpoeCy276rH1lZ2btH9FroNMo6Wrf9V1EPCIxpZVbe Xb/bVpVUUZUfU6OfEZsAzfr16fj3IpS/2UllZDw+7uQw4e3dK5JPBI5e/K6xvBdwT2dL8Ydrtlf0 MruT887fh8LHQz0gcIdmXl1Hjjy75Qz5qJPn9O3du/+gOUYHo/v37d2nX0oa8OTDFidTxqADTMax dAv5YXDzpk2js1HTLclN+GTI4C++XVUpaHXZwP59+vQdnCdTvxqvoiirX58+g4YsIh8Tbx9p0yZg 4ODpZBO0eMjgnj17X3iavHvd/OFTf5LLTnTq2DFLrgda6aAB/fr0H6QHQFXwfPHKiwuGDOrUsbNU a2i6Ts/r3mfEt3GXD3bs0ImMdUT/fv0HTKwS+/HNS3v06rlya3Xr1Zhm+NCBffoNJLf26jTitm39 e/TqL1IjFa7Le1b37NXz+58P6GS5nToFixWgb3Cnr9cgFY65Qwb36dMnW4oa/wH9P8mJudKtS/Cq LddMw85Pfty9cxCdRltz8B58vH5oXY8ePQZPR9VNl06dtt8F04b07Ny1Z405RuEfRO3qkTy8W3zx StHDxyLla3YgZj08x+SYyeRlpKh6tQjQGPtOXlj93RQA3KCFgMuatHrnxd2bSAfyxAN+o5eTSosA +J7fMmXQ1ytf3jvJ4vJvPAmf1LvxqC93lIeN6DNvxW+7vh3UeWGIMUZpzLYu80NwPdK+/PKbtb5s 1m+n7mvESQDwE7PzZ00ekSPXBvtatu7/WfzTcwB4l+amnNj3M5vHDwu9qcNxTwAGTp79vyCv9vN3 5YYdgIFMmjnf0c4yPFNiCL/g5V9ntgObjmFhYUirjM/pOWLewHYt/Yd8Z5Rh+efBZoJmCYnPAVLk NgI2fUgDrCUAHQeP+3xIYKNB00i9zr0XHh/49Yd9FxNDVgwFwCsiJhJa6jDt3dvXrM1ZR66Evswu XdSzGfDqsmD2RCBEux3R57H2u3BiU9O+E0y+N6oCFiw+WBB5cP3ZsPgzv5vbOL5MT3O2Yl2Pyo99 HLZghOfEdSFhTxP+ds5T+DCoZQJ/8knMyJGx8PdKRnXqe1jFsRsMANJkWM7zCxb9DAyEBNbLC4x1 UDBhSDwwZ/zK33G0HwDAEBWpZ5sPnT/FD4QWovC/6dth3u7HpPu0Myu8B86Ghos/9PzhYpQxTlnE hh7fHc+89XuTrsPgozzhj7afrV8yc2j/lTcMLjTZgOVIGBJA67nwf1nqU565BZJXmQzYpJYl5H9H SGDfjv3gQ0rE/UrJUycA7+Hof1keKb+mJNrWO8D43pioyjUs7EoEYjBpDDuC1UpYQ2U+PWYm9KjB o7MNP1msIZlJ2jAJA3xUajEcV71IK/ims+EjX4kvtbVAWz56TV6sw/DpfRuv2vUHfGzQqCmpU31i Ub/Vd9OqySkKtYRKZ8f88zh1qnkNbwsfnwegEWQlNPcPbrb3asyMRgzsQXiFC3rFEMB4ioROr8dU EiBwNShQM0FBJPC2Q09nrjzYtqWxwZmmuKGXPTQ07NQrXMcyhpP28Klf6zZ0epmZGdpTJc3NcHV3 V2fKJn9qULcGmB4IiG39LFdA7qSHfXbikBsajQWEZoRVCfDyhv/YbDTT5uXXAVQCA8hFBp8ENDKJ Gb/mLVzQUQ5o3JhGYwAWk5i+kwAHJ41KxQr+oSZfNKBW6IBFRQKNI2JiEpDTxNN+3V3cqA9dJEZd D6GAd3jcRDqDtWPNCZxge7FYbmvJB2xQmCl7g5wU/knUdg1SEyb2bjpq01XSHLlzgXmbkbAPDWX2 atLKQsAlhe8l4Nk4efq42cJHKWqBp41evg1TZQNzN+RNngR4gU/PrmOyLBs6IobcyS7X+Sda6U6d OxOEczRGGrNtzPyQUFyPNtO29veHhTy+UJnz6BRgcjp37sRhMW4moj0J/u07+boIAdpsjEvSn7F4 5qT3BlC8pq2h/YWIdNgCt+jWv5qEqZLIzjCO6e2EnAZNW/IAOBBeZHw/shVw8W0T2AptQH6aX75X GbbbjcfD/zB0V58WPA5zxdF7OhUSJrB9RzdL83Ez988NBg7erdu1aQYtL6fLoGMXW8GjFDE0LBve HNi623M5/b/cgJO7l3RVNzUlnf2FKxAGBAbAMXDI4+ykm/sBg90uqL2HI6dpv3nQwemlA/r9evf9 c5TCh0adJrBGVelgF5mS3DCHJcXHFZRKJaJS0j4z5WVqVq5aVWnnTVz8S9Jw4x7qHutUcqlcE+DC zzLZsq6WiR89CVfp8SuXbhot9SqxXIOOltGpFQ+fPTOOztXS4nsPnxRLiLMKMO3DR48KxYq4h7e1 hJ/rYbEG/5ju0f2HGYVoxKtTFj2ISas2affDK4aRT8OfJWeXVnEQHf4wIbNQlJFQShz3QwadXUge A4I9vv8oMT3fYIvpb4XeS0rLIx9jIx6+SM2R5KXlSVFSI8Juast5Gvv04ZMow2e5duFitaduFGan 3rlzJ19s+PI6rTI2Nr6kzPAoL04vVVF7leoQ/hOqlLf37yuz9pLl3Bw/YxeOv+0BsRQo1H3Ug2Wk vw9nH6e/jux8nMLWYBR7Kfyr8J9ogSlQ+LfiP9ECU6Dwb0U9I7BGp69tEWoBSkU1F9BQeAPwt9Ug 1Wo1JuZ6dppfPSBw3N3Lw4cPs6PR1AVPbL383y+QXV+NjM3/kGr9NWNM18BcSdVLTHC9VqoylKo9 y6bdTpa8XWAaM777uwpQUlzyRjer/C3upbzPNwkOGlizg7uHVx6OKIYGTKdSaD56nRt7ecvvD6vO bgzq6b+OPMOhHDq1QvPKeLE07jSbzSFyBRfwOAJLm19PxXxEWT84ansa/A3YuHA4FDI8EZ07q9Tm AVuf9wsnM+KmQvPPrX/cO7BB/YpyaOz5X/w7f0+aUx9fFb3tGcxqAGzfVYC3yVmhGTtT+haXaLyC PfvO1OygJC2qgFjyu75q4CjDgZsfEbLC5NxXDvZeP6jbl7vDTG1+Xzn+871xlV3pbQB4moMWyVSi vLpPh1dRpyWWpNyC37RMgxYstRo1rs2z8Q68fui3jh06ZpSiAqKRi4PbB7Xv0ClDpPzzu6GbnmS3 bOLb0n8q4RtbN/ez4ODgJ8mF8GFx1y4ytf7Mz6Pmb77YpmXTJq3bkVFsXjwHuglNKDSN99ah9W3b Bo6fthqafew4j59eauztPWlmSCU3B34ODAzsPAodoS7LiXNq5E8sq+rtzdHpkF2CgxE9dZLOHdoR iiId53w+vJG7C5cvaNWqlUitXz57lBTH72+f+v35SL8WTZu0HE4Gu3v5XCjPlXDTqy0qCNyvY4cO HQeV26v8WjVv498uXYoqpv3zZwQGtp3/2yEcF7XyQ/2U1q1bDfkRqcFMGtEffiNSf2Vwt45R1w60 8Wu9/GxCVho69RbXyTt3DCI0ytoZo2zbyH7d73906thxx/mH8HH8p4MyUx+3DWgzbNxm+Nhlykbk SAs9tg/q0AmmVFUcP2byn3O7Brdq1bpYhYX8Mk2E4wN7BbtbWght7Fq19pvTqUN+GbGErpN06mlM AsJnXYKDgoLS0Vt1j35Dz25e6OfX6nK04eYavThu9voj0BAUNAB+4Z0zJt2IF2EaaYegtm3bBd2M Rh/q+o455CH+xZlR8Ov1HzwHIwi8MzSzS3DnzsGfoVh6+7nbm7EtvaEwxopclgELWDA0SEuyNqye D/juXbp0yZGh9xODO0Opcoi19I4d+2VGnPX381u57fprimqtoZYJfPlc3p8Hcy5fK5JX1xKM7Oy4 eMe9imctqiNZHM+V80d0nP6LTp4PH1fsu7SkbcuJ8/cc3zQVPm49fdddiFSyPAGYvXxtTOR9UK76 W1Cmhg0CNKzeeRH+5su0/u5Ww79dGxv1mMcCpeXqEnfXDwLAOzohARDa1BbmPGi49egeMG9oFOTl 9aPm1g7pObk+TrwjoenQZkQgCB6x2s2WP2XZXljqoBeJDh/e3rXnhKWlEvEnY6aX5KReOrjStYnf 84insHj19AJpKjzh6k/Q5Y+7zrawBSLi5ocxM5a8iH5SuSkgCax3MecOmbZy2pBuPp0mQtumdsIl W08+vnbq+51PP+vTxKVVt8Sk5+QNFeHPHtsD8CjqeZFM09PRul3/Tzcvm2zhjXS/rABo6Nf17K7l Lh6GvsCsft7BoxeXKjTDRk81RtleyAfshkdOoR1gMGcau1oBy6ZXr58lTsxFat7QDezWj5z707zh QT6jF5N32cxb+ktAiwZXXpR81RbEyPH81IRT6yf59Rnx/Hn0X7MHAldUQeyYM8DedbQxolmBDUDz oVt+WQD4DXAd6vZ3+OSrXbO6frX4giHPc0NB47Gliagql6l0zZx4D7MVDQBYuvFi1LV9ADSAbpZ2 Ac+kePb9HQB4PoiKWzmpe5fvL5AX1kz9cQ38hdV9VkribwumOHZd+vTpc2PsBz/3nHMwFBoiQk99 OWVokwFfHTt2QqLBoFTcNiORVAIfsvAAxy4PLm9vOfSrdynd/wRqmcBTpyXMnpU0bWpCWG41DG7M BsWm1lrIWB78ry+LbPrpD/d3rWzUGe1GWB0c+P2fTzZ8HiRohO4K6+gGktPDOU7ehB84uhHiRB7A jFkzsJtt8EjyMbUgn1C0hsEq2ARXScBXKUVyvLwXas5jrTx2s0o/9qex/rNX/MoAIKBzT1KfSadG us0DZv2CHog9GDDAZdPRhUxcvjCXaHxgKfcO6ESG4EvoYF5a2hfYob1Bo5qD+PxMYDjvXk8msxww NHut0rAfSytOIs6sh5Z25Q505gAUqzFcVwwErqbh43olBwCictSQ8kMCK5CKmDSzhFRrw7d/P4oc TGUUVei9fW5hfvRBGjR86Q8iZYjAUUijU/c8IRtXRYN28zBlOuD6lIvnB5Pm6N0cPuS+jNUSG0tI tbiMS+u7jJ1OhglrybMRWTCinIqxQ8UWCzaadSoBHCsM7fHIF8mN+mcqALy2fDvI2dk2tACpYeOa PGDj+Wm3JgBYH7zwArroB7tpMN/bNNz3BF3B88eUVutuvYQEDhz0DU4I87IAZWjoruXuow6YFrCj X7Q5+iiNNBcmXOy3+m4VqViVNn6o0/JEeB1DLU9i7fzdd9Nmn993+nZyqkYSDka/HIGa2ZLUBzQa TVOcSbNyg490Du9FfKoKw1h2MBdBi25cjImJcnPWnSKuSgNAJRYLOEh9P+PyRuBs2EgAU5ulkY/8 dDb5iGGQcujGlvzku5rK15BwuUbVfxzDsNF9gglzxQEgdDorZM8d2LV/evd6SnouplcyOVZDZnx2 cctCma7i3pPFW87BSP9aP9U5AG0qpjHpamXF1CgMrig9Zel+w0EFGmKqGVrmPz4OrH0rpNGVAUsL tIeBgFJcwuVCVipAi+GkjV5PMJ5FAwwhoOPlEgKJHt1FCr0xaADXy2gCc/IVE9pwBW7WhitUv1h+ EAr54vQqj3bzjXE2D6YXZsPvg4eFA9IhC12DymjpS+ziYGA0OgcQx+3rNXl0jwbIjoG+j5N3M3J/ DJmdNA5dVmaYzDuzuN3QNm62bQY5V2ysoJH5BeXTkD7Q5amALXSwNDNus+HQQeqstRdvHV75+/pf mQGzkaeS9JG//gXH2sM6WOiIbSTQm16pdLcwhzk2ee/zYF/bW7LStv0+ga+gxAVSdAgBncHEirNN 8hnk58e8yM0FVVEhlbZ8lpfY+MH2dLR8xXEto5Z3I9WMa88vOzRzmmbGUSjUd2IyZSUxFjZo/wDg uILoE51GRMVNb+7puSY3O5Pusnx1Dydyp42di9tTmW9Jeryzq2teTg7wGW4M0IXNyyIMgwF4lsFt 5xRq7+RclJ9nGumuUcDb1cmGj77MrugyOtrwhBMXJBUZ3Uxb9POSQz3c3d3lZfkO7cZZ3P9j1C8X jy7of9ZVbGfZQSm9DQg/LBbT0clZUVYC+qPD3DGdTqkxEBj+g/yydvNMJWR2921+JhrF6ODkXAjl cQqq8ikYHH5DR3NLOwdFceHRBCnsKrun7HBwPo8pytTgU1tna2cbRzOmBkhEpTBYGD4doOuNuOz/ uTlaW1gBrXzUqr/IoKpcrMRisaCQKkkp6LHGaGktABPGBP34GaPM0cf91TICG122YytpgpWdk6S0 4EBoEgDJpu/V5XueMI1GJDccltBn6SOwjHbozFFTl+s/86fzLfka2cj521+JxoDuze1EHj3dmvQ4 2s3nyIMkwHTsDsCk3u1m85g5ufkpZXoVEd3JHSs8WjiZcxHl+HSGWiZt2tQDxfspuBT5smNDOx2u xZIqTc6PXrbVreven/6HqviSnETYozJKxRBYmamlk5YffJ1UdQW13AN4E/Q6rVRasUtBrjJ0v548 joS/WqU4Mjpaq9M/eRKpEBeRva6MF9FiYgpYLBYrMq60HrbA6F1ZVihTo86yKDlSokTOJeIyaUE8 7PyaRpqWFJuYlq0qK86RqLOSE8lO8rPQSlOaep06KSlZ9Mq1hlk5aPYFIzb6aJTS8KdPE1KyDe90 yog4w+wUpidm5hRiBXGZcmF6UjGxa0JSVqYqeOLZbohJkFhGVi5piomNScut6MVFhD+Lf5lJmhPj YjJyihQlmeTFkHHPHhudJcRExyUZ4r1341YVgbVqORTS6IDEgdEWf9yKKS4m54bwyIdhWtPXhm0Q +shnkZkFaKuTXi15aLptw7hPQiuNTzNMR5VGHAaWLfBXkBQd+Tw+nQzwzq17rzooSIkiP86hgweM I6rC3IzU1Gw9Vik6rVopV6idASgsU+vU5VmjFeVL0HhBLS1NLpSbhozp1AIAwpKQhOn3d6y+WpGE xAqp8Hu379bZ61brOoHfD6qSlGUrVp0/ccLJmr/9VGz1jjDpsp9Wnjh5uBEAv1x8jZt/EFp58dLl K8+cONHMw+brtaG1K8wEC/MjYakfNswBvu6L94a92d37Yu+WX3/fu2/5gmksnu3bL45lE5fsvM9i Wt1Ane5Cvzc4Vq4Cmvr81avH77zo1OI1WhA0gQ0Tv3rl9qYHiX3bN/pnBawGTJ6lNRe7ePXq2iOh /To0q11hJi5uxXUw/7Bhcho2/G5ypw8bpimC/f02HzzNsmuoURS92XU5XNp9gtfn7QD1fjNDmVxl wa/pdt/6i9LCQmt7+w8YoFius+T/O6vs/yzqgSqlEWfXL+oxfBJhVDx7iSYPMXWppYD3AVX1lAUJ VlbO7+RFJ82PyvwYSpq4m6tjGTEXlB13z2CnybG1c3nHcORR6ejsEVwvtxKwfr9Tr/QEKbwRtd2H fwdo5eIcEVqrVKacdOz1NbLC0BKu9g3+3gn6hxEpb+NOJsojp8oiji9u12fGu0aj0b1RasyMBcSE q2+7gL9yDO4jn8e/Tfg6texlOpqbUbw87DLwB4OtHuknv60GJ4X6gDpNYEwj9fdCtUybPpMgVw7N G7/1Qe7yJhW1j5wg8IYln0Hz+mPo1Mji5EfkqyU7jsNHNy5YOXcMfOy94nZ5qPryaksJQCNx0n0z SxsbS6RK+DhHVpryGDRfDN/JChLIcH79C2nPbv7uC2hmsX2K5Zobxw0X/Db54mjHNl5GYcrU5VOV mPazXuiwvjm7kDoRALxtq2bCxyFT1hqT5glAyPa50PKn1Wj1tefoTaT+QKFCRyhdOBsJbFrb6ktj mvZAZ2ViqiLyOL2V+87Dx32/fg3NQocGBUq9NDuaOFgSCL2CFpksJ5NaGgHu1iEPs3EK/xbUaQJP 6t9i9Nq/FGWFcNyWI9cvmt5vyclk9EL3ErSejAwEgTlmzaSpN21bdIPkNAcgMksSd32XlTPSxHIA oNfERekPTzo3mFceKqSHPfqvzQKgua40HhbuQSvPXljS//Ofr+Y8vwjAUPjSD4BD93Mwnfppmujs 8n4sTkucmCzIEqlhmA+zpBqF+PpztLpTFH6qZfdKyr3HF/ZimwlxXM0gegfQl6DNXF32Ne8e44xu IO8ZLLubvw5l8wQqeTKhEoi6ywpYUemKiCOvK1rgA9/23P0CLYooMq65tx0MDUI+5+DNlzANd56m p11fAdg8Uv8pW4d3AmDp/gcYhu09fI5IZgIIrFAAPPxF829+vfgxMotCraBOExi2H472NpChkUno ALcvB7Q4m0o0JOXnM+KYEhK4TKvXlcRaNOqoU8lhM2nBZTv5thPJ0IIoJBv6h+k1FScwGpQKycOZ S+NDAc9KR+ybGfvl7hdXd4Pumwj1wOZGMXq28QrNRGvRZAv50/h2AE0aC5Ua1IUueHKqytGTXADE RGwDW1qlEncJlaHONqY22Q7lCkCpWhd3dcWELXdwg9pmOYG12cAxCD5yGUBCrG/sm9tzezRa/s2+ +XvQkLGYssh07DMRgIgstBjbAqB9FPEXiQ4Cg30gLAe9VsWB5hVKzgc/azFk/uq/nzUU6gjq9CQW 7FMuDAmFZbCljWTr+VBoA6mKXjBtQVYKcqCSQToKmHSGuU1ZVj6hA6d9nlGYm/Ao6vRaMREIsqPR WQyjIiRszsk3KO2lhWm21o0YhF6UREXo2TGY6ElI3qWGpRVC6mrjMg0aPGq1bvL6a/DDbRnvM3bX M2jDt7MtEVW6maUzALeSkfdH0SKniglyGptVoa8JYxKyGdaOjc9dRrcoeAKgJOSRazCDziaux/SA R+SPlYf740jDflcMKXciwpNTd2nZBSoA4otRdO42IF8JJI69oXgJZ1cvmk1c18S0A+lJxnjzc/Te djWdxU2hfqFOE/jo/q1fd29Oo9EYNo28bBtYmPM5TIIDatgEoXGeToP0bFEaWLZAmcJgm00b29/T wRJ6GbTshCVRyrGqodI+beo4efJkGqcRSE62sfdg0JC6desufSWiLJa5pZXADNYJsztZwEBGjPh0 yuc7d6yduWvmUCcnJxcHsOTQodH/GwBfzdgVNW8wWq2VFeb36dPDNILDifc+aSSEbjp8s+V1C1xO AEDR+Q6+ZZfQ1qg2viBDSZsf1MiOx6CxXEA+Esk4/C1JTxaaIwVirpWQQRcwzOwmDOvKpCFM+3HD zvQb4/3coDlMbzlw4I/t/BtBc+NB8wcMGIs8o+OvBcZ4tz5J6zmwQ1VpKNRb1Pt14PfB6NHg6FEw ZAjo2BE0bgx27gRffw0uXQJOTsDNDfzyCwgJAfv2AYUCLFoERowAU6YAWFOEh4PJk8HmzWDMGJCZ Ca5fB4cOgalTUQjBwWDpUnD37rsKgut1kanFbXwcP0YqX8XdY8u6fL4Tl+a92SmFeoL/JIH/k8AU eQy+s0StN2fX6W4XhXcCRWAKFOoxqMqYAoV6DIrAFCjUY9RpAuPo5q661cPPTEv5BwSSiEoLi0o/ eLDJiYl162tS+Nuo0wSePMCfwaAzmRYzN136IAF+0tnn91tpfyMAvKNfI9HbHhhuwIPzR/Xvwpvd S6ZZWNvMmbng3aJ5M/Q+jRurXllVqxm3zxz7gBJoxVnPP8rGj/8walOL5E34YljQb1czCtJjOWzm wB8OvepA+44bscV56Zq/tXcbc7MAJe+4eQJ+5NRi+ZvdlaNfU/6jgjfvONBo3/WY63JNr3cBeK/N Dyp5SXJe2av2D//8qsvwue8eHoXXok4TePrwzpDAhNFwJuOzi7vIeufIrfC8yDPODYN4XDYAdu0a u0LLPBXSYDyxZSk02zih8x+hbQGxxwDaFEg07RtaFOnwAwsH9l/4GxEM0pdWi7P6tvGGDzO+324S uXZaP6Tw4Nyyq9x4wW45gTGtop8/Osnt+2Po6AyVOIeUavxKdILx/tULiSe7yJycipoS6TNiMz9B Kh+ffLUMOutjDXb8thg+ug5YbIx18ljyjEhrO5ehuDbTt/fEFp7o7nJYaRQnPSY2KVjkoGMmtdBN /y6tAOBN6x8IbY/ernRk+fLpI6Elj99IrDTWNwYCYxpJkC86zW99KNrYJC80HGc1d/dt+Lhp4TTi yTm52OS0t4BFUPiJPdFJXROXrMfRubPg1yUz4GPDiXtM4028cIT0Ye/aHT7OHIK2UwisHBQ43tzH yRjeq3eLU3g/1DKB506LHjI86utvE1Jl1eTo0DYO+8LiHoTe4LDoTu3m6jX5gMXF9NpDi4d0GLW4 JO4mLApNFp9xhIVvxaktM7sO2/hMU/wIAPMyLT7cyWJPdNmw7i2+XnNRlhNBN0PHrLSwBVlq/PLu WdBjdqmiqxso1kEm0K7GoIPdTfsjU4YGNukzAfIEHQBZIZqBwIuHtGzZZSDkPgs2UBjeHYCf/0Kb EJ/EpN07+gOb6wLNQU1d7qSga76HABBfgAwnV8w0cw2CBhs2M7ZIDdng2aozhmsAu5cxguTENI5R DFU0FOl2fMH89iBBrhUC8Mf9lLt7Vrj5tiClte/7FYzar/3C5GNfkUnyOAAAIABJREFUtxj5ozGQ XbOCrB26kW5K5FUJPLKdZ7+Jc1WSXBpx9m1bGGwY2p8UmVJ4YeNkgSXatiE040TnIbXznuXbmNaO 6mvRpD+mkbHptFyZrgUAbQeMV8sKAedTDMO0Wq1ajbTOmznxtv0VrtOpTt2Ijj8626HbdLm4EJL4 QhZ6W/DwQLshFTs6KPx91DKBn0WIszIUEeGianu2Pcv36o3ehU4VK3hyks5gMWGRHTRLq8dE8aFO PmjLga8tKNbisdd2CW0WXVrsPfanHdAy5tKawRsiMekLwGy19csOw9fcx4kGGRbHfXN6gH6byfBf JIULHcizlJWQUMaom6O9imjbHqvSfmO9Iw+I9TgDABnx3MyFn6dWE7v/DPh+bPAfsWjjQYC3bUQh OksNEjguDxF4ckfGqWTUl/5fU4/zEYVB5YFodZUS72tK4IAvUKw6nUaRT9YvemkqcS40IicU8Ku2 IFlF7H9g9DaG0Laxy9N8BemmrOKKFxVq+jCk/k5wEuNzGGItTHXFbTUT+7S+mIpENeexksWo79yz XMiuvvTrmchfO6FZTJa0RTmxdXps7BDDGZopWvzSju8AOtSW8VKOz/Zw5vGRFue+C5Fk+LlhB9oO rjjVncLfRy1PYvn7Wbi68/zaWLKqE4TGBDezFQ//+vPo1GD/EUsBnYaZOYnV+ojzm5fPnZien2LG Qb1HvoVNukjj6N5Iq9nu3bTP7Ttx0HLXou1D+/nQBE0aMZ/P3P7g2EKDAjCMJynm0f6NnwNCTVqk wRVyNTRsnTUBuFecnqWHA1cJBmgsBh0oKmatcLUS8OnAH4B7aeiQ8dQcuQ0bB2w5+To5Iw/HlOce vIRmrrl5SQmy920FMiWIPA7OLc9cQPsfHmXke3miE4bJDRZMxutzQYWc0BkMOgMxAfYW4q5ftRB6 Eie7toTv3JsFhEFJmI5Af63CF66LzSgmjVpt+YElGLp3j0UDcLQQnafUKiVKtV7AxABPZBA+pxTH 1HdjsskYpYTMXo1BOnE1oqW1+7XbLwCmfq5Q2VrzjMIz6LRDZx+ShcmLCVx7zIKGa7uXd207E0bc beYyWMtM6uPTpx86417o7JxfRN20+EFRq9XHGzCum8/tbPJwUKWHvTChTDdpYGdS7MABo4tiLroQ nclOAT5HH+ZpRMlMnjl89Haxgg4sbQPJQI6vmOjXbTJp9rXiqNDuvC4bItEUy2eDWq27mjFzXH/o Pqh7X6sWg41Rn/ljFRkRnU7fei7CYIvphMSkTvIDwxnL83ejy3L2zjccPd1h4KLi5Duk2c2R23o8 GtzC0MNSSqFBnh9Pvuo1Ctm3BkBSXaorMkURBfwqzvpYNIncMiFIQzeSGY4lOLz+89Hbo/HK/f+0 e9vIiLxcwYBNtw22erRjCfp8enI3+faXC+gszvXT+5GPA8dtyIs5Q5p93Okd56EZgS4AZBAH1YpT 75OvhnyBbp/wJbYuvgpztqFcrbyTgetKnchzvAH4egk6eCDn3h+Nuw97Q65TeBf8G1Qp85KjrRq2 5NLe7LIG5IRt67/62fPLf3wgod4fE4Z+duDsvrd0rCgr0AocLBhvdknhX4l/A4H/DspS7lp6d+nV qdP1e/eORhSO8rOrbYkoUHgH/NcJDDueudnZCpXazsn133o8LYV/MSgCU6BQj1GnVSkpUKBQMygC U6BQj1FHCbzji455IlUlK31JrzHzakmcOg1LS0uR4h03WFD4t6CWCexgzjv8LPtV+y/3PEgTy0xt csOO3ohApytOp9EajfntYwizZ803eZrqX5XGXqHRWNW/ez38aLRZex6+kxcajRZTon0XH7qysjKt 7h03GVH4t6A2Cbx8SMtCmer2xWvVvrU1MzN91Gm0Hq5IG367sixq/5yPIc/Vw+s3nE+u9pV1875J yek1e5eWlVaZD7yZm7Hx8/YVz5hOLK1eD0kqNqhDJSWktLB555qCwn8WH57Aubmqt5nXLsuMWHY+ plVDl7O3Hxktr57Y3rZt22nzV0Izm4lkk5WkjxnSvVOnngdOhpjxOdDmwPbfSqWooYSNlagghcNi 0mgB5A0kamnxplVLFyxY9OxFTpXo8hKetmvsH9yz3+1nsfAx+cBU2rjNm+ZPgoFsOf0Ck8RCw8lY sHa8DzSUKHTfTBxRVpr/xbAe8FGqxaTZz8/dNMj56MpRv8Z+A0dMeJlH7JHSKtYvmw2dCS1ttp+P M4105++/kzuBEx/e8nCxoTFYVs4tTB1gOtXaRTOQXyvrIy9gjwPbexjpQu1eNcHVc8HpnUtoNMcX LyMGdA/sNmwWCgpXQsfPH176bNzYPcf+qpLGopTnwX5+fp16nbkT9RY5QOFfgQ+r2HXs52h//2cB czLf6BJGzRXMViefNcqwpqcrk807d+NuS3QyM7oDAdOj49QbjFp09o+VdBroO30h6fHQ/VTj6tfw 7/a50GmH7ucUJqBTXUd//es1QlUw1kTTryztKeT7ql1/Hd/0IxldzDZ0YRKTzT358yKelRO0Cdm/ vxUDNJu+4nQIugbeE4VNbzB6rhmX+ShZHHH0exvvAOgs8cQSQGedDY1YPGkIGdS4tnZQ7NColGaN PFbuvV4ljS+VuKIkHRq6jZymkOVwuI5VHLA4ZmGR6V/39/rlahaOS8kwf185HhoYgMkizsFu5NsL /t5JKsRxCSC0O4dP/Ax+kC2Xk4h9haBIotErM6FhyvKDt0K2o69HXWH238AHJvDDk+mQwMvPVLOZ 2xT3DyyDhcytgTud6AGU4OgiMz4dpJQSerc6VEwVevzg/PHtBo4ivawZ2HX690dxotDfSykiDT7N 0b17ndp4f//nk25CdtcFhlt/4CupyfbERQMs3WedeHB6qxmXDTzb4eUEzlVoNUUvANeGdLtwuH/n 784aQ/jtJNIx9jPnJZeoQpZMbxiANhg3sGXuuPXyl++mIrl7oQqltyfgC1zajpmve2VDFSC27JTl hkND42bNrjxOfNWBlYvnmOkLDV6VkSSBd61Bm3LzpZqB3Vt9tmA/TtzV9MPph+SOIqkGyTunk1+/ 6d+TBC5VaGeO7t59/I9xoQdtCG2U+nvlPIV3wgfuQgcN83j2zP/HocKanXWcsMzCp+WYsVOu33tm D8CxsDxcp5ZjwNWK0IWnGdSaHxflNWg/kTSzaRW6zhqFHl1FApkc+RNAPWcpbK1uSzSbf0TbEnDp C/grMFGNjn6myNwyosMnPx04dwNPQz3hBxeOgJYznHhMeXERMFWiNpn5Hj4QdXcjJIqG1hw4KmUg ATCpRDCju8/mY9GPX6Tj19ZAB+djir+f/5n61jomg1aorHpXMaSX0KnNgyvHu7Rt3redb59pS03f amTFC78Yd+vUTgbN3HTmCtdrnNwnOghY3fnWcjXaVzS5H7hxOwkANIigs5DEXYP4qemlAEMbnhgM en5e7rNzP7Xu++WSg3c+fL5SqKuohYzOfbQH/hYmPV+z4sfu7f379my088fvaEyeJZsxZ9cF+Cr+ EdqpL1PrBzVrEbJxthwtkej/TEpOLzUM7ThcBim5PXHdPNdCmB711AOAdevD4OPwbsMAsDCNsamf 0L7NVAwvGNa7880j6z/95g8GG3Tp3QW+EjjYAaVURQxVtdJC8Pr76zHUYNIFQvnsdSeyUx+2beK+ dtbg8xEvD1998v3Sn6Jy9ZYsEJtW9cAnWCHFhZ7xCBr0+76Qh3uWR9yqONwLU0uOnru5cOmKvEI4 UpClmExvSQtyGS7o3pbGQfz4VHQLVNDgMQ+PXyffFpZIcb167v4of7+KW45cbBztGg3SKCRzh3eJ ObOvz/RNb58jFOox/vlG/5Purdr+b6bxMf7c9+R9n5Kk0+TNR4CO/qUXoY2EjnYGKvIFvBYDvsSJ u//upxSTnUkyhGXdAwOHzc6Lv0XO3tr7+QG6j2mMGmm2JTEBBtCYk3c1QbTrExA8PwS906HDH4tl aNP+wuFtOs0+Q3qBlhmqihBOrZjtHYB2zEvTr3LK7yjjC63zS1JMpozNyBGAEUxiz90kB2uji97/ 22x8K0mtmL2DI2FkpYqFgcD/v6+a4Ow+BRoyrq0Hnn2hoSD6IJleoxdzSzt05aEiD/ZYpOjQH4W1 oHzens3ddOvF388pCnUftaELjaKlmfZb9Xo9g4FYgWN6tUbLYnNouJ7OMLSGGrUKB3QOh41hOJ1e 4U+lUnG5aMCHadUqHc2Mx0Z9Tz0mijxu97/deNatKtGq1ZDzdDaHjYLA9DpAZxKhicVlFpYW6HwZ jQpncliEpUwiFggtXye/Wq2m0RlsNot4wpQKJQ5oZnyz1+1o1KhhslC6OOxKS0QwvQqlCtDoZjye 6ReB9lqMxmbSMXHywl2P1y4YC63Ss0WebjZoVlyn42IYk8UqT5eaw+EYI4LZCeP5e3srKdQb/Hs2 M2Slpli7efKB2tXVuf3QNSd2Tq9tiT4KIIFhq272ZocU/hP49xC4jY9rZDJa/u3Q5393rpz+typD QAIriXEEBQrg30RgChT+g6CWGyhQqMegCEyBQj1GPSGwpkis/GA75o4sHxapeH/vAtoHm+LVKUpp tMEfKrSjy6bOPZr0oUJ7Ha4u77v7eny1r0Z09csWV9rPtXfHwbcLVUujIbWZP2cG3smR/10RX4Hd u594OK0RLaNE9WZ3tY16QGAc03IFTnM3H/1QAYb/dZpmsv0O10pob+Lks4OLA4IXk2YHANQfSBKl NIdUKfsgyFKJwMe/zNHZyux5Rkq1r06GRgFmpRL152HylE89mnuracujQQ+tMPHZux6w+et3w2aE vKzZTfG7Z9iul+Dtb8b0taYV1tKO7HpA4L1fdmfxzff/cRuatWVZwsBF6SmJ8alId78w5e6U7Y+S 4mLTs/NJx2XFWVeuXEvORPf6XF89OjajZO/mX0/eiSXfxkc8Db3/CHCAp8AQuLw469jZK9Bw5MDh lELEpdyUxAcPHmhNMi/8zpXz15IKCs4eOnyE3F3E0KqeR0WUKQ3FLi7y4bXrt8WKSo2PTim9ce1a eEwiNKsyQlcdf3zr7KGVGwxXB0mK8m7dugX7FaBDcNUE41qvgH6FGc+/+/prDbHRV1aad+3atYQM NMce9egB/FWXpYvlWoDro+Kr2f+oUysePXiQlmvYoijKTli3/ve03KLKsWARcXmleRnHjoRoCGrF ht+7cTu0TKYyfqt7jyLUhAC4Trlj46bQp+iqFybfpoWTZ3Zaclx8Nfc8lpXknjtzPqdUSj7+eTQE 10lDjp2A5uOHDkenmNy3BIV/cu/hs+dVtU8JiAtyYS7ItQbS57yM3rJ1e3ahGKAtXOqHd+88i0nC cXDp5Im4yIgruw4fCjkFX+nVipvXrj2OiCXU5oBWJQu9detFemGVwJVS0a1bN5Izkf3C/g0zxfKN K5Y+eCkql+rBvSdIKV3AZxu9yMuKNy+fB6uhVKIuyEqJvnbtRm6pBGDaQ4dCikQg5P/tnQVYVNnb wM8UPTRIhwFYCCaCia5du+raq2us3Y3YomKB2IqigIAgIhjYYmEDgrR0DzVM9/3OuTMMY+zuf3dx lf3u7+EZzr339D3viZlz3jc07NHrrC8V5SvzTbeR/DkCBpI9nlgiz2r5u5sAtINuEwDm+T56FrUR Xdl4wDs3P7D4delwJD0bFgov09jYicGogEPGL4H9FAzbvYMN6OK5crQnUNnrzyr/sGb1Ynhnu8+O 1BLW5d3ToVtPj67jMEGZh2dxwTMndNc1tdqx1Uskw1oDgPaM2NnJs7Rl9mBDG8dzh7w+qUw1Knn9 odN9HcGsE8m8dDQQGTj2gp9MDGOmI5udvv4H4KfrsqjPCi0fk9UX9tP87XA4Kxv1XOExVwy0wd1U 1ObYGGZG1xy35WLF60i7Hk12lXzXT1gemiVPulMnZO4EmXjBamAnffla9CfZE7IUzXq4Z9djiZXb rODEoteJAxsBBRl2sjXRApZ9lw71cOjeF8Nk9nTqb9tO/+BqfjGLlRE4l05X7HWv/Tjf8pvH/PfB Ci9DthM5APSUiZhbvFbD+2u27rr79oPSM11DrZPH4CmeHRyXRmIYnDYjKzm+g8HjUk7l82Do38Oj G4mqCaPhfLiN3u+1KDIy5iTRUqd0HLmyBwA+8ekRJ/09enYyaTVk3bodMLiWOnXaxoOjXcGA9THw 3aoDsGzrHjxTvZTpSsrvw3i2+aGtpgIMc3a0hI5xi9aSNNGZFjcTDRePgVOGdYM9FafRpo6wvgS2 qym/7Z85olN0LjsrEpmPCQ06CtCGIMGOzeuMdcHs1ZuDr7388wbd3HxjAe7W7Y38LzTri0Y7Je1t DNE5AvwlMIQYpyxDQ0cPPmC8DbPt82PhywjQ1Qde3ghY5jkpYLoRuJH0prcLkmmeDJsBm1nvqZjc jJCIpWzBvT/ptmRC7UYDSKDxGNMnzb3qVXRb/DQSBArwupM3MCmXptjbqPcw6JARAH2nrlP6z74w e/TW89MGop4ltYKXewkpA4IRr/UAb9mYs5NVfA6y1VCVHjd4841PCy2qgJ6LORJORmC32YeW/Oi6 6+rTft3Qtucarvjn1iCtvp5sDZP90Xf5hNl7HynD7cMFOPPsrO4TkPGEC3umLwrOHOzc6sjNt0o/ o0aNGjZs2JChs0W4AMOJxpuHlwtYaMC8FnrQWE+zm8fGurzHAFhDz3GbF/ddfbU2Mxp0mqSMAQow AE6wB/Sb55bKwebMmjZixIghQ4ZU4Weyi9moIl9fPWgzPRQTpIN2CpsYAD8fqoyk9PpWE7fZ0HFm Ya/DKUxVAX5YyhnkahMYnysPVVDNH+Ksf+5VmTzgyR/dBsxEth1nwolPJbJsEb9/Tee5l6Cj+Lav +8xtC4eiDvru+4q7PqNm4sYi8Xj6K5PW1VYPf5yjfMVO1gYD52/BD3VpSWQcYDO4MQhNaYqVXYGG 1q69+txNLsAfkZMfXW1nYmDT2UPuoUe7VnI7WP8+v795/1/hzZtuf/CUV/omsxi7effRoIHuo3q3 jk4smNkBLpFQ1ZPIgCrDyGpacD4E0EqABHiAXQtGjvslJDAi8YeuXL6oigVijso7YCAVN61R1D9L CAP44pGEZnM6X1wOk2FfqxhhoHhtmz8CyND3YHikDdsin6azhK3oVOhF3tmIOIJr25f7HPbHHjzl cbg5ddVTdgeTFDHBKa5IH9/8SKJ8YcWHiXnAuJu1NoWLLA/Brkeyd+b00+GRj4b34AvFvUYP8166 oOvCB++8PO/HgzPvopQBq3Nz3eZYZvo/HjAC2RalUqkUbfWsSv4pd2eln1MnTwISVUdfF0iRxiIq CXQbMB7IkHtPxMu3BdXWeuo1OfdAH2Q61NRJBySDsuSE9d7LlDGkJT1ZdvYQGbV+UmI+y3fPAYFU pqmlaYg3JXkZ+UK+4kgZq2mCjKmsSljV5SPHI0kz79IjH94WlAAnJ3iZcA9M06eymbWuXRV2qkgU UkUec2oPC/llTY3EbcxQ6HAaqohKivYyoO+9JHxR4oX97lu2YLfu87icmCIRzd7gC9UL52Kd7JSX Molkz5aNigsJnEUbfR5Ex8xRKuTciPD7wdWehwRYNm21f8Sz9K7tzERSoEZBxZaKv5FWo2/SbfyP /Dah96jF/nJ37IKfHYb+JuGgdeC0uYvg59rzL2twgz0LFqHLhFLe81OzoONieIRnb2ezNgPgpPDW +woMt6BZKZE56at1HzJp9Qw0sa7/KB2xnhqox4fgkVZ6wGPKIHMT84FLVX005N4zxg/0Y02Ds1iT CmqFsu4muu0GzQkPDdRSByfxI8QIVhr05h8Y4r10HIVmcGNT14VH0GhwaonHxrvliccnwaenTx9B L8ADmQUtzUqu5is6fEltErDFR3tmErCfdO3QeqBhFHbp8i/DTHXNJqTdOgEDcQSS9mY0oKavmsn1 E7qFZjXIkz56aBcUTxEc4ka4A/u+cbGXPnnX8hFYeWkFQL/RM0MvIPPLvjfQqa8rN+LdHAxM2nQT 1KLjmWExsYO62CyPzD02VO/0zTQY5OLBWX23PFKNE3oz7zZo/841cPhCNQxHYGQVWfEon8Fr8lqL XtzNWzdxk8HjMWEWaIvWLGPh8pItODpvLLDuvGX2BIq6KbLAOKaHfaeeV6PPQ0l5HbkeAIdbN5Ee iGEbY2GQpyGbHZxXoTi5+fDmrmPn9nqh09psBlrH7j1y+pN2PslBx3nE7MsX/OHNl3Uie2Nqaq1Q nkO+WKqnrdZ/ypppQ9G4opwynJ3brv+UhaeO7pO3nF+dLICNZ0R4qLM96Dv2LPTQ29kmLpmBfQu+ awFm131UKeU1dVCANXToSe9Sy5nI6iUS4D7rU98lK81YC5hlwefPfyirge6iVzEsAXoH0QdWy+c3 j65fjb37hMMu/yShhVNmKd2Be7buPnL506zwK7z9FWf9y8qr5A6/ZbO5+Ct+9/JBaGiU+FOj1cLQ 4OBnr5ERbYxbllWK5swFL+PuFKFTVuya0nMXwgWYtICB5oFt4diiEvJS3H25Y8GWIFQobk1gYHBG QbU8Wvv2y+C/zKv7D8W/U02v4O0T+WkoVnnmVm9vBl9xP+PRtU3eu6pYElXPMjF37JLDqndSX9wK C7sqkHcjgsqtPj5VTP7GebgECqvXb/S6+RxXSCCuF+N+2KU5gQ9yVGNg5KWVZCffunWvKRWpok62 zpsq/Lh66ooydu45xJLIxoyZB3utB6+RgfKMZ7fktfgs7uJ2r+1Kz6/uhO/evkuA60woTnm0+9BR TCZZsD0EXtZkv770uqLRo/jSxeAHTxXWTDEJL/jcuTwGPz07XzXpa6HHToZfZ5V/uJ5T/+ByiFx5 idfUGfJy3b4SdjfxXU3ee5X8yqLPH1m7dlMFU1GnZXkp58+H1TQops1Be9Z/XLv/Hi1sKyW/MtPI oTePxZRfFr2+YreqAHuy+tvm6h8jMnOdWJkc+62zQdDyaAE/I6lC0dAiATPlpQadbuZo+g3z00yo EdJL8PdoYSMwAQGBKi1sBCYgIFCFEGACghZMCxDg9IdXxowZM27eMiZuAagm5eKA9ZGqHnp1sKj4 S9ZIGtH6x8cSfLb6/8MYPufA7NGH75Y0e7SfcHqe64PiLx8bcOvYRqD6qyYm3bmlOVXkcSqSDakU EqlVM8b5Vzm4w/cbpt6MfO8C7D3O02X4dHt3d0N+qYE27X29UMiv/GTLPrOqgvS3FvI2//hYQsLz TzVv/XMKxFzw9b+YsDKhvyyq/uKjlxn5JBXdYzKp5NELeTElJJK+9K9kzbUVqfSzvnWuS9flYQ8x rOqv5bhZefAs4fObQeP1D0W+/F+C21oa3c2sb+Y8/S2+awGueBPqcydZLOAd3rDhXOiV/asmzx53 VPlUKuZfiQi7dPUmbFL6aqrhZCf89gQcD+ZK8B3tvIaosNDYWw/kG9yrPqSs37D1TsIbhV8e89q1 2EKGwpDa7euXg4JC8quQdtik+3FSIevc6WN3XqMDCUkvbo9xs//k3NIGnwP4fywr+dWdO3caeCKA ifTM2hSm3Fk4Z049DzXehvKCyMjI7FKk/jI94RqQ8oLPnrz2GG0zqCvJOh8UFP/41ReLz68tj4qM TMlWHADITry90Xv3y3cfnbyRiXk37mWnJz70O+SPlONistjIkOCL4ZX1qESYTHojOjLyynWuCO2I kvKqvTduirp2H1YEVdOwt53Js4d37z1+/XnSealPThw7lVmKLGOQyNSNuw9KeRUBR2HlNxw9eDCp oFLps6Y0d9daZB0mg4eq923ivaCgC68yCzCZ+NBB/2IGOHLQLzzuYdM7LS25xACDbaTJmUUAt4YD K+dlOnIXZr/hSSWXL54LvHhf6T/h2JJbbwr8fTYduHBDfuf+9bgrVxXaea3buOS9f7bot0Xcz/ZB pbx8CHPyPB0dnDq7+qc7yejUh6CuiEQaCR2rtuxG9SPhRQQd1SeRRk/3O+1/MOSW6Hrsaf+jyLKH VMA8H3Q++tpNMQbf4Ptha6LjQgJWbNgFq9xn9yEOmxN8LOBk+M1PU/33+TY/P/9vTB/YesbJZ8rL pHCv7n29ShMP9Mc1wsLMW830mqCl8UkpJg9zcRn444mt80FnPwxDs27Xn7e7AbDjRjqGISlKSEoC +D4bR3kVODrKY9g6s5++Vds7l47JL93wh1sPwNnjT+HeaLPXgzcfjNB+eiVQSNBu2H5IkavWyQNr 8YCKM0mbp3YYt2Y3uxgJ6tixSOM8G8Pw4xVg2ca9AAziFKDOPubhEztjcDS+aafBoukD/W8XidhI n3u/fop9YwIW2o776s2DTwrbkK8QP7duDtGpNVOQc0xwgBcAbTEMb9SOk3/r1mHgtEUYhmYbJ2Kf ujka3y7i3N4xVtkGPt6Xphhhr4SiLV/lEkzIKUV7iaWsg77b4R3/U6c/4JtPIFIhmoRPmB3gNbP3 ufcNRZfQjst78ZfxTErOBOyzMgbzNh+IfpjZGHfjCdsOHWZ5BWFiVMbOY5CVjNdlvF0zUJX3wXXf KzMTsxztA+3ZH5mqEEhkPdub4wc6gZ67nzKrvlt/BQOOqRah7Po2eP/+vWuKqLio9kQs1E2ce12J HxdxbAzeP+tZSLdRUx6EnZo+WL3TD5OOBV7CZOg8yRrfSDcXhxFT9so3/AHg0scOxOWzzxw9qqer PXbK2tArD/7ntvy1+F4OM1z80mGGQa3Bs8omVcubf+nvMTeiAhdgUekDB8/x8vvGH7VpJD/Kw0bH R/casxxtxpyM732f95PbrP1XlV6h4G4Kuo/JhFqNxxISgvbrQ7GZhmymwNb0uooLG2JAyMMz6+fQ 1NW7u/dn8VWMDglSQacl4ppkYNFZfgM1F7xRlnAlvPyrUIKPLB74675E+GhEv45BT8qgOD4p58CW 73f2+u45HptjX3o4oz3AleymaJfgAnxv7/ihq+Lg5bo5P2zgPWndAAAenklEQVSNybPTA3EpCotT MhG7b9++7u693XrPggKspqkDJxcJcaEMTg2gm1w8sEJTnTr+1zNpsScMzN2h/2NjBi06/uRJ9B7g sVaZCi7AvWDAdRO65PKwfv36enh4uLm51eJnEgT4fqjY/Qv7rIrlVj4GLmuVBRSobDgT89GOGoeO zleeZcmfJtyNsTPSN2vjLPfg2cUqoVTFSpUiEi15HFHeC7u4oRMgITM7rfG9DgV46Wl07mL/gaNK zxt7OYHuP8kj5whQdwxrSlibQ9Oky2/ezGXiAjbmefDSPn1QEQ4/LrM01rl9J66tuYmRlUJD+Km5 aPtqyN1cvI3kA+th8g7OwsZ+zppdcj8ZgXNnHwqFjsz7F+ij140dhlT/33pdXvgKdUkCqcxr0cid cairXW5rcSJe2St9S77rwwxmdk4XA2PcN6Gql7ILdgY/qhEmZPmP69VzDbeeoU5SzP8/mtRKGaDT DOXCoIYpdXPvCx1OyDwYKK6o85oyTOm3GArwLE846SU1Hks4ePfDB47ISJsiN7jbwRTpb106fQAA Ayat330qYLeuphqmukDlShtKSpxaW6HA70KBvids1EDLwkqLwkdWyACjNM9zkfwsAaaGny91MdeG nytmj/RJ2LV/8pTwa5eeDurO4ULvCkWazNLSju1NSqLShvziikpHwjR0NQobgJuDpaK8NO3o6GgS iaJFp0vK31Go6ABF/9HTgLQasKtvFmuVM3l6VOnb6FN0j1+hfzs3jXQyqMhNCzh6SpnxtOTHvk9T kLUYGSmtjHv1crQEkNQ11HVVWkRFAwsdd4Bwmo6CqJaeqqEnFfFfPYrp7eHExh8s2xJ44012BzsT KGsaVPRuRL9/kL+Sx6L3QYcSpA1ATQ9VtYtHG/gpP+App5orObJ3R+MVWpLQkP4OgK9lUMzD2+rV ooPJ6t0n+lwZJqDR1PX1dX0xbJXXsciEZFcHC54E0FjZ8wMvOdrpnzx3bPpgPxSTUIZvgpDlZ6dO +mnstFa9L67xBBQglNsBkYjYNw91Ox5+JT5BxOcUv6wH3Xeq498LyK15wXyIpb9jS/rf5bteAweG XTruPbnD0CnHAg5QdVvP333aSA2QKTSZTKbfaWzx/agJCzYNdtCoVjVpRLHUzw5Z7XPUa86PJNL4 yWuGeU2aGhkRvO0uWLrvzvL+/fp36RQWdgG+/oJaARQaTRiERNXQBDUC2QAbo6Q8ZkzoCT1tytEw NM1WNj3of8vBM1VlJQBof5RFPXWjLgOznsbvPxKg7zID2FhiEgGgISHQNHF6//zdhPmbZ3Q13e+9 9ObjwkmuxqpxDhk7TSCuKMl998vINub2Q5viJJFlmGzM+lOr+1nv27bWN/DJGk+L/b2dTJ1/CD5/ HG+4JBMTE2NjQy31j5XnUkxgR8Koarh4yo9M03yn5Vh8eVlEVORi/4fxF464e05f5kq/EBbWydb4 8MOy2vx6Nzt08saotV3s7UwDExSlLp0uj6ldv7Gb18xbsCvmpu9oJJf6TXpspdImgby5umPvn+Yk 4stL2JxX9midml/19M6VHg7k/mORAR1Ys0Xln5ibaeoAJs+e9vTAuICAA7Ouvp8/re8X20CxTKKm hU5uwdGwiAcsddQGzVnV1tChr9d1pR4PLR04r46iatBhGaD0wjsL3Z3Ti6peJ1x3b0927HlQzcgp IOxFVm7hs3D/Wx9q8TA0ZsEbmppG7J1HrAaOlIGkkW5ukVuEFln2rgOgEEtqy7yXz9bUMucLGoA5 OtjUWdfy8W2kUMHKkVyLf0Hw7fnWU4A/50rIqW3b9laxFGdZBDX51VzFJvKb0VdeZRQUF374KACb ja1Zg93FLX3GxEB3XHQ0VpSHublhVVWVb55j48ZhBQWYUIjt34+dOIGJxdjz59j06VhDQ937NMzO TlhUAt3YggXovlSKhYRg27bdjAgR5edjgwerJtW4WV+Wl5cvYb3sOhUdK4+KiZc/3eB7Hn5WZL3w 27WLjy+do3avVg0uEbMjI69k5Vep3vzw+ql8OdFQ8t7P15fVOLlOf3TjwP6Aet5HhgclvKoleyNU 77x7fjsu7r4I9yWsL/I7dozNF/ls88XrrmrvAf9XWegsh0RQL886M//d7dQy1RgYRTnFmUkPHz5t KqZMMW329drwid3DOzEhPj6+yl3+1WU5UVGx1UzFC4o758f8dG0kJpF1lNNwdnX+2eN+HHxhkhh3 qgb7FEZ2Yh0XRfEs2LdBiCox8PTxmIR0+dOYmId4LfCXL9/2ScDayryoqKtV9XzVmyIBuwZ/E1L8 XER5ztudO3bcf5WleNyQlZDWaBlXJr1+JSrxNbJQI+KxkoqY0FGT8TzsHjrRkXc/5APj06XBN+G/ uJWypgYYo7EOFBbK9WYABgMYGgIqFfB4QCIBurhCifJyYIGfMi0tBVZoDgzq6oCWFtDQACIR4HBQ EEhxMbDBz6ZWVgJTUzSFgo90dFTSk1bXc00M6E6Wur9si/ea1+ffKynB/3v+iwL87yKs+TB6wqwS Rt24qfN8vFd+12sSgv8c37kAy0RSkhqFsNRFQPBlvusB41X4jvEzA/5iICmb31xaXwkIvne+awGW cav/av54OWH95/xHtrkSEPwp37UAKyl7Eeveu7e3X5z8ct8v49t36DxvlWKH/UgP997ufTKruOfn dfcYvTr5ylGXLq5oFGYXeLi7T16J9Npxa3K8It/9OnGka9c/+uWZgKBl0QIEmFWWYtV73JKVa8+s GpvOkla8Pbc+5ENCQrwGNxMTc9SoZMfxy+Z1bT1vls/EvTFHTx0Cxt0uBF+gcKtJuq0nzF+RGXNw 47UsXu2HPZNcDDpMsGAnFX0Xv8ATEDQH3/hnrD/k8fEFo6efiF7bc2kY0va4Y8kYryi0lT+pmCn3 UPwyChgNh44r3otGed9EtwTpwGkG/J/5+CwwQ9v0Xl9YPWCUDyPrhnw/YGHO+29UGgKC5ue7HoEL M9i6nRw0NfW08BMLtdWM1q3Rb7PmhuhnWJlUKpHKgAnaqGjjrIepyVUQ0wAL7UZWp2oDQ7TPqvhN jVY7ZMwBaKBtRrbtOn6bwhAQfAW+8V7oP0UGwMAVgSMMbYNbmVRUYbIIQ9cLy82N9K1N9UpKyiQ8 BsiaZGsbUV1ZKqZ3BJtHAZkIlKPdcHbdR4KMyeYWpysrKjiSIN6H+G9dFAKC5ue7/h1YyG2QqtG1 aGQRpzYju7CDazc1fMZQV1ZYVNXQwdlZnUoCUn5Keq6TU8f0t2+69UbGh1Kyil2c8L1TmCg9LcPO oaO2Bk0q4mYxxB2t9L9pgQgImpnvWoAJCAj+mO96DUxAQPDHEAJMQNCCIQSYgKAFQwgwQixsMdun eTz+t87CV4GH72AX83mqNzFMLPv6X9FIxX9LKfH3wXctwD91NV4e0GQ0aEp3/buFvD/w/3fBLE10 Kn5f88v3hFBb2/GvhsnPK2rGHNSWFfwlzbJK9P5ICzdPW6s7/Gevpc0VNpkUPj61TcTzgr+T2F9h VFfj5DrpFx952JAqVaVbxunR7Qe5szC/OWv1b/NdC7C2kXHA8nG8xvZi59Jr67bor5AOiUZT44m+ /Ap/B0ws+RP/Mlxbxz/JVnPRpq3d3wiF/U7+27TvmF7K/hsRsv4HP2UfX8oaSr5gAb25MTIyruYI vvgIdjn6qmqLyDrLG/V12bexU/UJq0v6L8wWPuO7FmAyEP22fLqunpW8Yrq0ai3OR/pBB3l0tbS0 +nHDUVhvTm1s4dwrdPfqKzkNUhHPxnaeagyDe7Vv1cps3Ul8Fwe72MbaysbWRW41ft1gdxOTVqOn IiWmgETSZqfb2tquPH1HHnB0XxsrK6u1/jEoko42yfFnLCzM55xDlq/7drfRUlcztHZSphLkNTwk G00NxvY0KxeBhrIUKwszKoW6wgdpM3x41tvS0tLWY6xqxnrbqyfeOmFkZLQ08DG8rPvwysrS0trG tp4nyr9/fMHqG0AmtLVGv2Z7zRhQ8qUpnpONjY2tR+MV38zM1MLSuoiDyrZzxECY+SW+IezqNHML pArP3Nx8/HZUtLl93aytrd9Wwnm4rJ2dzf3zO2C5dsRmq8bMq8m0sjSH+Z+77gK83PGrPcz/yBmr 4PjfysycxREM7NrWwu0X1SCLfh4CU9x+DiWhrq4R5r/EyNDwcT5Sff7hRTR8ZGv/0XvBk6mytbG2 tnH6ncHvI3KfXoLZnrgjSn65e/4PJiamg+btVfXDyo7dF/hkiK2NuXlrEZpOyWD8VlbWIS+K0WNB LZ5cmwo+UlsXvnUhjMGxw48Y0kFGa6vTYGdrO2TNmc+TXrVouoWFxaYzj/FqLr9wNUbELVTW6g/r rgNhubWVBayuAaO2/HlJmp1vu5MzJqL02KnimLhKjvQLT+UakpeN6dhh4FisUS+0v4djnykrykty AFIfK9NWpxSzRI46oP/IPYy3Z0CfXcrgwcNcugyfU1mat2K9L5+JzLdfvvds6fhem65k1r+HTbMb o6ZywyqkpMrCCKmqCww9Bajm8HKMg9WoBQeLs1/C1iiSIuv1rV37P4w7T9dbvqBTu8E/r65lNkyd u1yZ0G89QUI10tvkog1KBajtnA66zyx5fjwmoeBJjKauQVFFpYsdPfBOk+6uwa2hL5O0jCT8FaDB 6cm73NPznQYuPpsR49t91OSq90incZ1IpgcAp0mRKxworDGZSJNKXrjtzG9D3PtMXIlhMmNNtWNR j17ejj5+NdOzvUG7/pMK89/B+GVSSVpaiiEA7zIzmXyJb18H4DQ8KvQoUDPCZEI12CcOmhR7fEOP fvtVah3l/8jpW8yy137ht+6dWqXR5eeKqjKYjZQ6SVZGxkAdrZOXEwpKmvR4Delq3q3PL4WZSM21 fNDWs3JIenoJOG/ilScCHfvkjOyALTOQcukmkELps1duBywbMe7IK/yyE9aoO1bpKWA4iHiWz8xA Kt2v3bujTqO8KmK+CzlkbNO+vr521eKlqq0m/+pO6M0/CJndYbBFLsZ0r2NRqY/C8BpG3euRi7GR 238eue8+p+gBnM9V1NbuWLOYJ5FNH4hWJYfPnqWRAevjduhhDX6Yta64KFdDjXo3uUJY9cqs80BM JoO1aoLXqlx3/5b9UczK95sOnf+Dpv6V+MYCvGJljtfGvJUrc15UfkGCF+MCjMkk9jTqtHWhb3AB hgPzpqWo+1/sjZqdg67W08xcDQMjc2fP9c4g9n15Y2jUsTP4imjv75s2zOc6dKwZ1ykqFwlMcglT mRAU4NC7WXjbNYSXsLEu+XUMAJqLV0XCSyjAXBidSFBSKwhaho882iYpRSxl8AU9QSoHOaBU8jCs myPqnjv0GSWQYn5ze8/esB3OwvoMGatqob4tHNnu5clEKCcF1/e27zkSjrZmDj2r2QJx9Ru9jj/8 1hFYGZJf5JcCDQeVcHDu2ppTmSnvecU1SbA9CTnlANgonuMaydliGSYuB8Zd5Pdg/nEdc0gyyxuQ +jhtNOVDAixECuFYVQ1N3+FVirFeHdDI79hrCKy8fgDs2bsRXo6eoNAaN1ePfjP5IyV48szwGPlA oV4bZLKk7Kp0OHe55j18of+jRm/9lUFyQle5LTwIHWcWe/gl12EYE/an8rAcYZMA7+0HIl4Ubp4y dOKKy/Dy0lzbUzfTxnUEiQylGu2mqS8U4OFLUfdd8D4F70eMpnp0UdOkB93PKbjq4/zzGvjoxubB ux8XjB7kevB6ljKV6Z6Oi3fEQoeOBrVOhI1qp4iwqE4ABViuno/55vDiM9eqXkV38RwlD9VaUatY fxfUGdt17s1RUfn/r/GNp9B+h9r57G596FC7Xq2+kJOGMtyqCImSLxLHHpn925YYDMA1kYxtOgBm 3X/TvLe5dVsmGPRp326j3/WKvCzfVJJnO6XJLNRe6TT0xQmPx5OIaw1bIV12pu2cxPj3VUa66KiD UAD7ZkzI53r0aoMveerkgdUGLoZt0m+7Z1kDaiJU2G3Q1K0M1X/aeRwmnRG1aYhnb2U+dfV0MqoV LYmMSR+/K4J+LFlZey8kkim0mIhknlT25HZMwpMkZZAaOIcf1FquYpVEUctMSX3JElVkv8x5m0g2 dm5IvxuYZxi5ZsDejQvG/DqtqUbEdcDMlExGalZhUEZenr6+LrIz4DxKXmQBvpKnkEmAaqDUukql AXxmjapCLJMBmYgLFEtLMrKZTjfVVVM2iFYU2YMkpLu8I6Vi09H7sKbOlxtDeYgL3/DqHVq/6OiS mNwvfJWoriNXSQsnqDQnOhkvmYSmTSlKQesOKb9eRaMukIqq9QzRrMfKpYcQZk5UCdraK3JLaWoJ bx4DayNtE7K6lIw6pkdRteZmegIuaENHfvhcDkxWmXOUB3V0365jF/zrstoJu0OEPNaETqQ6VpUO /rrt3foJuTKpWNTREZmJlwiRPZjywuyJc9BXUyQSqYYtupajiNDGQB00Zvrwam9jTZRhGSb7uFax 68+RnsqRbdXGLwn9vFq+Ov9eX/HXgXMbNALjSEVo0tWj34HEY79CYdLV1aVSwJrwNFkVsrvDl2Fd URvSVQ2+tQNQU9fUpcN6t2Iz3kNvenp68A3bdx1QfGsroKjp6SGRhjNSOgnU49pPAW5nZGdnRyoV JoFa5L1cNhzB+I2ZgHd0dOgaajQ7uHxq5NGFnSQKTUsTNZHnd0JIJDJdl04mkQ7cL2gofAsbBl1X V0Od0m7AZGWQdviojkmRUYh6MVqVaevQdbS18CaCWcAhdVawjIVsJsV/aGgqkqgImLnBsVRHk6ap rQPLklAKhwGpPg3o0HU11WhOzhtgEE0tug6uS7kOD2ROAqX4YJF4YDigqmnQqP1+XCcfgVXMTCgo e3kVtmM6nU4mkzZfy8m4DpeFJLy2KSMnn0YvxYh+5maGapA+bYGWjq62JjoxVtggkjcqIQvZLsOk YnnRPm1sMrbydSAhFGaBthOwzyw/TADgcW61lJ2LVzuSH6kMexCwnEyhwneHuluVQQ+OwOPW7FZe ena1o6K3jw6u5VVVqySnVp0UBsgwBjjTAvk1fGcyyMfrR4+uFfasQLVobtaAQlHT0UZvFuar6lV4 54Ej5I9syahWWaWoU4PVRSGTx5x4+1l1fnW+awEuzngnUJlZS0QC+dsV8jkVFVUiseJZaibS5cuu KKrifqyDeMAALCiI5eODeXsjBdGTJzOuxmJ79mCzZqGnkydDt+hGPHLAp9DPkSPQPwqVm4tt2ICt WCEpr8CGDUO6o+H9FSuw+Hhs7lzGhQuYnx8KpUJtVXkFoy717UuYJx6rPjc3t56tkHqZTFJRUcnh CT/yz6iUO3KyMvEGK2NUVdbVK6bl1YXZ8rI9f/jq4yqR1dQr5LmopLimgad8kJeXV1ElF1ispLio lsnh1lfKq6MgJ1vpjVFWUlikmAC/T0n7YrXz2UyY/7pGRdwSEb+yokIgUsgKt7pEIP50vVNSVFjL 4rHKC0RSWWVljbzYmRn4WCaTwuB8kZTD/UhFs5jPLSwqge8zLQ1mT1bP4uDV+JGKbF5DrVzxtojP LioskCm1SdczigoKJDLVRQnsDJmV9WzVOyxmbRVDoWpaLOQXFhXDtUX6e1QbAjYzv6BIIEYxiEWK V8OrLuGLPpoHC/g8PpddX1P7eS0V5SpGaiGX9SE3t4bJ+dzPvwBxmIGAoAXzXf+MREBA8McQAkxA 0IIhBJiAoAVDCDABQQuGEGACghYMIcAEBC0YQoAJCFowhAATELRgCAEmIGjBEAJMQNCCIQSYgKAF QwgwAUELhhBgAoIWDCHABAQtGEKACQhaMIQAExC0YAgBJiBowRACTEDQgiEEmICgBUMIMAFBC4YQ YAKCFgwhwAQELRhCgAkIWjCEABMQtGAIASYgaMEQAkxA0IIhBJiAoAVDCDABQQuGEGACghYMIcAE BC2Y5hRgGZu7PaAcOtKulmzc+GHb9sIaCRDWcnb7FF5/yr7kk96nb9LpeGajb+mQgcmDR6ZmlyMb 0JcCiubPzzwSwih9WzNmZIqHR/Kx+Hq5x5MbciS4CdQdh8o+SbHXgJQm66hSaVKxuBmL8/XBNm/K 27Qpb69v+RD3pO7d38K/lcuzvL3zNnnn7dxVPHtS6oB+ST/+nC5oNG0//uf3txIbVKN4fLmggYuX WsxbuS0v/nC+VPbn9mLXrM5ZtSJr1YZ8xbVM0r17yufBfL1yZ8zJ5AMQeDh/yJCUa0mchhLWsKHJ a7yLASZduyJz8YaC/4fGaUvf1fjsLkouEK4e97aBKdi0s1R+f3j3ZMlnngOP5p+7hsyLsyvY/Qal yT7z8A9pTgGWCMRl1Rzo6DzOUljHdR8JpIwqj6HZniPIdHJdxmtBxGX7kC15Qrk4AqyODa6cNt5z IudFTHF0OmvHLuPUuPL7qfW2g7QCg2wm91BE+/IemytGBY+7Xh16sujx7Vq2QFZXzg2LqKJQkIny WzdqP5SJLpwtXTwzPalMVJDWcPNWXTOW66tBWrFE+/bthmEjMLEI3H3Q/vZtpz17LNwtxa16kKZP U8stER883OrgAXOJQCQPUEuT3ThfNHh4OiYU5lWKU17Ucvni6CtVN5+x4FOJSGTZSaOBxb37sDYs ouYPEt653fTxc966VTqRkTUSnuhptgC+jgd3UaXlpij6TSAUGHQEkweQjt3IDb7PiYi0374sd9BP ucfOmPHz6o/vz+VaUIRP6/LrhF+3kr4zmPkNExeWjB1DETUwMDHgCCSugwC/nn8xvKqaiglFsuvX awurmgaSt4ksZi0XOm6fq+I1SJrdGnezjsBQMqWKaLW0KGaWeq0sTM1MKZvX1axexiyvAz+NzveY pU1uSlM2bHyFqTrtrF/1wa2WrUxMHMzUmGxxUhx3s1dJYWNDyoKNC/7DxEa2lKuBNalVDM8+qUPG ZXXpxNXSIg3om9ygVrd8a/bQvoAsAUaisumr8095F4S/Km3Gon0lDI2NAYXUuZMlm4RN/Clr2rQc Ek3bxVWPI6TZ25uRSGDn3urFG0upmmpy/xra5COnnSdZC1++LH2RXHLjfGlFvYhsLDiz/UNqJRwp wf71FWKp0Mur6MnVYgZTIA+Vk8F+8aKOI2lsOxjQ1NEnUWHqJvuOllXnsYNjUV1FnC8NulUzdX5B eR2KCqhrlL0W7g8XjLHR6DlOw1BfDwgwGp1sZ2XWmU6j25GSYznvBUCT+v9rFaZvo62vC1asYGwM QD0Xt0YY8YDz0/AMF1cefJUT3ZMLssqm/JqpHGnXTtQxsdaAjvHr7L5Gfpqz9tkVYm1jcn05J4sh EfKxonR++t2CVcc7XA5xIAFJNY/0MNF1zyInGpnUGIJ0YIfZg6sc29bg/D0xr6oh8jm/q6lanxn6 ly+7dGtnIPc0xgwklQlPr/ow0BM15Alj2sJRF2CktrbmMhnAZNio/lbQ0crGFLZ4G1MjYR2255yB uYFpMxbtK8FmS2BB0nN4QJNy+67rrVuu6jQKfCWMfMWwdj6offxFZw1FhSl6x6BUjMqT1LDIQhGm QaO6dLSQYCSuUDFKkyrYs9bS9dVJfJnCv7GBgK7LrGfUyi/3eqU/K2RraJKoMFq+VCaRGhhR4f1T oZ2PeRf1maxlYaiJ/PHYL2qlKxeZWDtZJJxi12ZX69pR9FmyYgEWncJnZotW+ZnvnUR7nlr+L1XW 98G+OWkX4l3PHrZkpbKEGBCLZTIqEEiAna0lfMoAwKqb1oJxdKVcFZSI65hInAUc+IKwZp9CU7Zt 29ZccZEpIPZSVVktR0/CUTMAmEhk18UgIaIoJYe1cLmBu4uOmYOeWlOPQRJx67kk8Vov8zHTWpe+ Kb2VyNy0w9xSX4ejJulir6f05zHRLPJwNrUdZd5ku+tBjHqsYcEq/XkTTMOulvbsRlu/0Pp8eLGD CcnFvRVTyPLwsHS0FLxME3RyACYGOs1VtK/E5fDcPv3UGrhsDzu1PUdK7txjDB1qom2koWsgtDHX TbnFGPSjiTqN2uidzExjHAksnz2fPnBEu+SH5TINUs++Bm+fVPUZodHf1UImZg3or2faxZQk4nVo raNpAgzpWjCYJl3b1MRAD3dDernp7VyR3Xe8jruLkZO54FFag1Vbzc72oHt3k9AzFf77belaaMQA NJqmlEUhi1lS7oxhxtee1Cxf1mrhUrvo4NwRM7Qn/NwmMa60Wpc2cpCVljr1i6X7T9LZXff04ZzC GuGa9aatrdUtOxu2onNW/WYbHF7Yz0Nt3842j+/VGtqCtm0NKSTU76aWMDUxoUMH44J3dW07yrSM aIZ0jWbMDwlr9ln512R697d+j11MtCjfOiP/RUTshbtLjm/rQPpzrwTfCy1MgAHMLYloYF8LqVRK oRCdY0uipQkwAQGBCv+/vkIkIPiPQQgwAUELhhBgAoIWDCHABAQtGEKACQhaMIQAExC0YAgBJiBo wRACTEDQgiEEmICgBfN/7/lrfmuDAIsAAAAASUVORK5CYII= --Apple-Mail-102--974640808 Content-Disposition: inline; filename="Picture 6.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 6.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAUAAAADwCAIAAAD+Tyo8AAAABGdBTUEAANkDQtZPoQAADzZpQ0NQ Q29sb3IgTENEAAB4nJWXCTxUX/vAz52VwVhCQgwhighZy0627HtFzDC2YYxdtkREEbIUiVIqWdpR IUIlLbaSImuRJEt2896hfr/f/30/7+f9/M/nM/d+73Oe8zznnufMee4DACfBlUr1RQAAKH5BNKv9 OgQHRycCtgegARtgAoqAzZUYSNW2sDAF/7X96gYQ494hw7BFOVbfGv36gvAlyiiCR0b3yH8ft97w NNghAJA0zNzkDdZisNsG2zA4NIgaBLMng4meriSYI2GWptlY6cJ8jWGHvMFVDHbb4GcMDiGSGWPf A4Dh8iN5+QGAnYBZg+QeSIS7GX5JpEAiBeYzACB0KBR/2D5HJyyXJFJp8FiOFZjFGOuyMWX3AADU dgPAnP23zBueawUNAP7Fv2XbWQDgDQWg/B96M1brawXxvg70UJBfF0GsOgCg++j0GQl4bhkArKbT 6cuX6PTVywAgPwJQ70sMpoX8Xi8IagPgfz1vvPPvhoQdMgIsAmhgAopD7EFCyFW0GMYb+4rZhQXN 2o1/ytHA9ZF7erPCFpJAydZxwk5RmliJxIAU+041mf2ySru3KmAVJ5XaVW6rndrrqCGiOapdoGul t2pwwVDZ6IWJo2mnma15g6W81TnrZVtHuxoHvKOLU+XB2cOKzjSXq0f63DiJBqRA9wseDeRRL5y3 lI+BrzMlxO+0fyG1IqCO9iZwIOhnCAjFhwmFy0UoHd1ydDKyISo7OiDGMFY0dvXYh7iHxwviYxO8 TlgnaibJnhRJ5k1hO4U+RT+9mrqWRk+HMpCZmLOYs8tZg9nNOaW5GedCz7vlWeZrXJApELrIUYgq XCiauPT5cldxy5Waq5UlF66dvh55w7fU/qZWmWQ5e/laJbiFvc1yB3+X7R7rfZYH2Af0qtnqsZq+ h28ePXlcWXuxLrk+9IlHg22j3tM9TeLNfC1szxDPFp6PvahvTXpp2oZve/3qzGvzN/g3z9/Gt2u2 L3ZUdHp0be3q6E55p/Nu4X1Zj9sHvg+ve0983Pdx9lNln3s/a/+5z2KfywZUB5oHbQaHhoKHscO5 I9Ij9aPWo6Nfwr+yfr04Jj/2dNx6fOhb0AR6IvO7yPeKSfXJph9WPz5PeU/N/IyYRkyfmuGdKZyV nC2fk5+790v216V5tnmP+doFlgX9heiFqoWfi6TFvqXOlai1FDqdsYNBJISAziC0kNzINfQ2zCFs NbM6rp01BU/kMOZS49bhdeKL4i8SbBGaFBHaZiJO2h4vdXZnoIzYrmdyAfL8Cg17vJTxKjfUdNQ/ 7KNorGgl6bDppuijDSL3fzGyM75nyn3Az6zRgtfS2+q29bztPrsQ+wqHIadNB/UOUQ7nOTe6jLpi 3MSIuiQX9zCPVPIVz0der70HfGYoTH5C/vJU44BDtJDAM0FFwUkh7qF7wzaHzYV3RNw6mh5JjbKL VosRikXFThzrjqs/XhqfnRB3wi/RKcnwpHKyeApXCv3Ut9NdqXVpl88kpvtmWGUqnxXOwmXNZPfl vMi9f674fHpeTL7vBccC/YvyhcJFuKJZeDe0Fd+9knc1vsTzmtN1jxtHS5Nuni8rLi+reFzZdOvl 7Vd33t7tvvf+fs+Dnqre6vc1PQ/7Hg08Hq39UTf3BDSwNQo83dEk27y1ebHl9bPi5xEvLFulXoKX 3W03Xx1/7fRG9i3y7bv20o6YTusu8a7Z7rp3p9879Uj0TH2o6o37aPgJ++l+H6mfs7/+s/+A8EDb YMSQ1NC74eMju0a6R6O+iH15/tVvjHOsctxy/Oe31IkdE83fXb8vT6b/kPzRMOUwNfEzZppr+tqM xkz7rNvsz7ljvzh+FcyLzecv8C0ULu5e7FxKXyavEFfj1/LoBLoDPY3esh5/HmAMzkEQFADNIVKR e1EA1YvuwPQyAWZpXChLC5s4Ppl9iTOAa4Tbkad1swpfMT9OgCxYK8QibEHIFenftl3MW/y6xJCk gJT5juidpdLtMr9keeXkd5vI2ymQFal7QpUilSNVIlTD1Wjqnnvd95E0PDQ9tFy0nXSsdE31tPUV DET2cxgCw0mjHuNGk3LT3AOxZh7m5hYqlmJWeKtF62GbN7a1dsX2EQ7GjjyOg063DsYeMj8seHjc ucbl5BE7V3HXWbcGYjrpiLu0+6JHMznd08VL2mvBu9HntK8dRYDS5XfCX86/hxoXIBHQRgsO5A+s C3IPZg6uCLENWQotCjMKmw7PizCMmDt6OdI6ChNVE02JEYvpjc06Zh3HHvfyeHK8XgJIqD1xNFE5 cSap4iQleUfyl5TiU26nhU73pualOZ0RONObnpfhnCmSOXz2WpZPtmIOIudt7sVz/ue18jbljeQ/ uJBS4HZRtZCzcLyo6VLR5bhi0hX9q9tLmEu+X+u4XnOjCN5lQWXO5UYVypXbbrHfBren7wzd7bnX dr/xwYOqu9WlNVceFj7Ke5xbm1OXWX/6SXJDYuOJp7FN4c3BLdRnHs89XkS0Zr4sabv/qub1kzdP 3ta3P+/o6vzUNfOO/71xz/EPzz4qfCrvNx5AD44OL31xG2f/Ljv1ZS5j+Qoj/hu5j9EwSgBkGQBg 9xoAq+sApJvBqY4D3iBwrrZgA8BGFSA+SgLEtTkABSr8lT/4gDw4ADxANMgG5aAZfAKzECskCqlB FpAnFAPlQOVQM9QPLSA4EJIIHcQhRAjiDKIU0YwYRNCRAkgVpC0yCJmJvIPsQM6geFDKKCdUFOoy 6jlqGi2I3o8ORF9Ev0QvYiQx9phETBVmDCuItcCewD7GzjJJM3kwXWLqYxZkPsicz9yP24bzwlXi Fll0WTJYBljlWBNYP7DJsZ1kG8Zr4wvxa+xH2Js5ZDjOcgJOKucAlw1X2ya9TXXce7mredR56nj3 87ZvPrz5G1/UFs4t1/l1+fsEogRFBJu2+gpxCT0SJhN4CE0iQaLiooPbmsVuixdJJG8PlyRL2e/Q 2yknTZBhkfm1a0D2hdyd3fnyxxUoirZ71JVElXHKsyp9qq1qteote3v3TWpCWlu0pXRUdQ/ouejT DBL25xqWGzUZfzJZPrDFbI+5s0WCZaXVBxtOW0O7BPunDqOO9IOEQ9qHPZ2zXOqPTLlJEEmkYvcR 8k7PEK8mH15ff0qTPz81KKA1UCIoNvhdqFzYyfCho7SobdGDsVfi/OLVT/Akzp3sSmk+XZVWkX41 syirJKfs3K28qguNFxuL+oszSg7e4LvZURF7W/Fu/4NzNTaPuev6Gx41nXkW3Up9dfRtcGf6u4cf PvUhB4yGS76e+J49F7youPRu+ftKz+rVtaL184MX7AYm6/HPAZXgGfgMFiBOSArShhzhMyUZugw9 hrqhKQQOIYbQQDgiguDo30Q8R4wiUUhRpBbSBRmDLEDWIwdRKNR2lDHKH5WNqkf9QAujLdHx6Afo bxgCxg5zCvMUs4JVwgZgy7ETTDuYvJlKmSaZdzOHMD/GoXHmuDzcVxYlliSWXtZdrCdY+9lU2bLZ 5vC2+Cp2fvZj7N847DgaOBU5S7gEubI2cWxK4WblTuHB82TxCvGWblbd/IzvIN/UlpP82/hrBQ4J rAkWbdXfOiaUKqws3EdIEVEU6RdN2eYspikuKYGXmN3eJ9kidXdH/s4k6RAZ4i5LWS052d2i8twK zIqQ4vyeH0rjyl9VxlQn1Wb3ovfxaezU1NJy0PbROaZ7Xu+W/kuDEUPISNhY08TVNOnATbNuC5Sl gtUR6xybdjsW+wMOYY7xTpkHSw/VHv7ovHKE11XN7QgxlfTYfZws6Gnllezd4AtRNPxC/e9Qp2iS gWQ4L/aEcoWZhCdE9Ee6Rc3HpB3bHlcX75CwmJh3Uj154FRq6t607+mFmfZZW7JHcsvPR+fbFsgX 4ovWiiWvulzLuNFUBlXo3Dp+58192aqMh4jH4fXYhrNNSi19LzLaXN4Ita90jb5/2lvWVz3QPNz/ Ne1bz2T+1JfpztnAuYX5u+vxFwfmIAwUghb4K5ILUoIOQbHQFagV+ongQ2giyIg0RDViGMmB1ED6 Ii8gX6EQ8D/cD3UNNYQWRRPRV9BfMTKYQMxDLBprhS3CTjPpM+UxzTAfYC7FseD8cJ0se1lusgqw prFh2GLZ1vCx7Aj2ZI7NHJc4ZTirufZzfdwUwM3CfYVHn+crb/pm9c2jfDlbTPgh/hqBEEFlwYWt D4WihPUILIRukYuiPtvMxPaJK0rs2C4quVVKcMfWnULS22V27VKTNZJz3E2VT1K4qti4Z1gZp6Ko SlTLU5/f56XxWYukPaJL04cMsg2ljZpNXEyXzNIsJC0fWZvYfLbzt19zTDjIdajQWcWl1ZXoRicV eWiRh7ySfRR8B/1SqKoBI4G5wfohc2HXIg5HoqKKY4xjJ+My4hUTPiYePymW3HzKJ5UtrSzdMGPg bHS2UM7Dc7bnf+anFuy82FDkemm5OOuqUkn7dXIp+ua5coWK1ltetxfuZt2XfvC0+nDN7KOUWsm6 50/Ijdinxc3mLYvPC1pN2xCvLrwReFvQsaOzrpv8nqmnutfnE76v/LP9wMQQZXh41PpL9Rj3uMW3 4xNl35sn3/7onGr+eW/6zIzvrPTst7mCX4a/pueTFgQXKhZlF28siS0VLCOWPZZfrOxaSVx5uyqw 6r5asbq0dmCtmi5Bz2DEf6NeWm84XX9ffxrBVFfvfxR3/99G8Q3+44ML/rH6uZmZ/+av1CALm/VT CIClwBBrffgO5yyIw8PLwOg3E0iueiYwC8IsF+Gpa8awAbOpB83AamMs5ODtamwBMx5mP3c/W+sN +1Ak1Xe9xmVwKjVIx2o94wGo0D1Q/49OVYSnjf3vsS9owVa261/VcG3p429i9dvXCsld7/fcEEx+ vmamG34RfF5BRuu1LMy7gAFwhasxMnAHMsAU6AK931cCLCfA5A/3uoNAWG94Xe+Plt36s9e/jZKB T2WGvZD1MT5gFGaKi1ccDbb1f60TYcvBwBfWCwY0uVK5MbmVv3QYXn3XPf+RmPyH5I+dv3W9AAm+ /9P+upzhnXLbIyTXP1zNzhMlgZJH7UHpoPahNFCqgIDiRfEDGZQiSgWljdJEqcN9qq8mHkz85Wdj fdz+ek+TP3OGr37/sWbEf8wGbNTv6985cAzy4xnUmLUQ++97Lcg9bL1G1vWnhtO8yJ5BBG0q1ddd mmDkR9wlTZCXk1MF/wKDW3gdwfXxVwAAAAlwSFlzAAALEwAACxMBAJqcGAAAACJ0RVh0U29mdHdh cmUAUXVpY2tUaW1lIDcuNiAoTWFjIE9TIFgpAD5Cch0AAAAHdElNRQfZBR0SCAatbr9WAAAgAElE QVR4nOxdBWAURxee87ucxd0hkCDBgrt7cS/Fobhbi5ZixSnuBYoWd3cJkAQCcXf3c9t/ZvcsF0EK JOm/X+lldnZ85s17MztvHgXDMECCBImqCWpFF4AECRJfDpKASZCowiAJmASJKgySgEmQqMIgCZgE iSoMkoBJkKjCIAmYBIkqDJKASZCowiAJmASJKgySgEmQqMIgCZgEiSoMkoBJkKjCIAmYBIkqDJKA SZCowiAJmASJKgySgEmQqMIgCZgEiSoMkoBJkKjCIAmYBIkqDJKASZCowiAJmASJKgySgEmQqMKg VIlrZf0fpNvWtfawpld0QUh8fYjy5a+f5cQkKpQA1K4naNbUkkmr6DJVHVQ6Apbky56/LGALmIG3 syLlzB1r3YFc5NcyAjBp9x/UFbAqpm+DH6ZHSJmDult+01yu74k9H6Q6sLdGMV+N8oeeIfXa2q9a ZP9NczdB3LucpxHqkYNtv03yaj+/t2W+pFJev2pI+TYZE4AdGqVkDehs8S0z+R6oRDxNmisdMTA0 sbCYZ8J0gZujOXIpNHkZmQJXh+9fMJVYOXZeCnQ4etNaegi/US7KHNGyA3nQcepe8tCOznr/rYui U7PUqf+kTJls4SBkfaPcS2LQuHj4y/GhDqxr/fVTxzTGT85uNFsbikKGJUSri2RwzsKi4+K9PNw/ MbFjx9L7DLYTsD6V5PUdal+9+rfr0O+DykLA4kxJ2x5hhNvWnqoUa/KKkFsjhwRN8D0oKWjKjP8t QTejOwspmSpgg+UA8K36++b5TMJx7FJB//bOTN3uxPPnEsIRl5TsIKz2jXIvidr2tIhcTW1uIYZZ U746N6QwiL/HT1pwWHQmg8nhcJhMhkIul0qlCoWCwvjUqSr0UMi2XbJ7IbmH19X6xGISHZql/rYd +n1QKQgYU2v01HvmDJJqLK2sO3WMQq+AXsKnVNiWG4Vy8V7DhPg4nqXdt8vk8fU8wpHxXC4SSSwF ZsRjrEwb4H4c1qzO92uCv67WT06Io3Isvj71GoMC3Fxd9U9mZmbmFp8n1nLNmQDIkpPV+RKVhdmn jefv0qHfB5ViF7pzqyD8L+X4KQtrB2dPT09zoeDx/To7dgopFOMSfiEHVmQXTpoRrX9MS5XKFJ+9 8ndz97DSEdXcGREJBdrC5GXJsnOVX1YwYzxO0jsxiUxLteqMLL3vi5dKlfpTi719ZeSKvRllvRWl S4YOD1N8rDmd3Twcbc0J94r5Ee8yVIRbnK9Iz1R8Ykn+Da4fS9hyTNcCSk1KirRkGEdfDvyl0YFK ofqsxI079NORly4ePSTEzy8A/pNWjERYDBXPgQNvJufj43/rfqGVta2AwyT8zQSsZk2rG8LhK5xj WxP2nMqWqwCLQ9t90dfXykDekqyiST/HhCWoicfWXSzXr/Zg4tyj/48x6dmaPTcSbaJUa49qGZ1f b7s9yw1LzbiAnD/3ZzwPlKo0wNqBOW1Z9V6NOcQrpUTZpn2w7xCnvXPQNpLoQ9yj56LoBaG7F7j+ MCSKCMO2YD69U9eoWtipncmXH+VGxqJRVcePt39nDQatHF6mJsrNYgG5HMTmSJ3xzaMtc9MA3kkw lYxbctUyFZPG0MeRF0hnzYh+HaKlpfotBTu2eLFhk6hkR68UAZa4m6d6+47MyBSUdocfbP5YpuV1 i0aERReABwFxry8pL95EaxWeA3PPAW9vO0PinVoFWDS3OrvBHbpliRlXH4gehYfc/Me7c4cQiRzN IzQm9dHj+my6oVK3TqSeupb9PgJ1Z/U6Zhs31nC2/simY/ncfdm2bPg7vDt91ayEl+Hant1+vm4L V6YsObdV3zh9yJwPiu6dQgj3S/8GFIWiaeuQ+sOc902xmD45wv+DtomuPqpvz6URHdrwJ+edUw0c ODe+cMLUmIQMLVG6+Zht2+PtzNUWUCVXLl8cfeuxxLh4QSEJLeq6lV/Bb40K58DYxCWIUTQeynW1 5duY88oMyABrp6dvO46oF0IuVY/tGiRRajv11aXkNt0jCeq1tUWN/uR2bo/RoRqcY5nhUuD9E7kE 9Zpbocc3VzLScsVE9MVT3g+aFP/4jVRFAUwGyE5TrJgc6tc/gngrLZTDfAKuZmTno/5jMNGsV5iq 1FIvGwkJsjzFlpvxRHh5gdzPL3Dj4UxIvSwOYNDAhzei5k0D/3pYfIPOCJI4NFIBnQKpF5UtQFuw 67GIGLqPJaYStcSIycS+zmrZMZSgXjsHVKO3zwo79QxGTBrDm0WumbY4jaBeVP3LWR3GhxMcXFyA fn+dnEtQL4QoTfFjz+B0kU6UwBT5MhD3Mi8xLR8g/oboUC5St2z5AVEvA8BntULzy19RRIJqhRpy pF83p0HqpbMAmw6iP0j6dnu7eH9mGTXW0klirOr+3Zwzp9K3bowbP/5DsyaIsz2J0dIbwV7m/RhL UC8f55dzhn9QajCGgMksLV2ePS0pPRfDR8nbk8lNWr8nqJeYmf4+gwQxokP9L6QTHYraP62oy8Ao SL1wpFhbo8ZMCJP07RAkJUQeTN2sZTBBvTQGpVlrJrErk5DyPcSQ8lHBBJzmj3cwBczqz3RyLPeL hUjzBm0cgqUbhGdOazceQmMR8YsziqasQg7nRky4hN6z12asN3rbyJuSU4AIwhNnfbFhapjRn8fM D+y1qs1FAZLzUe7Hf4u680oBqfDoCYuzp61On7U7tgOXGxNFKdlo+CoJgRYOAQ0adiwXPvwtSkNu 5y6cM0ctFvRFBPboH7EG/ybXr+MH+Cu0pcLCnDhuffac3bSWqACvAlNEytJl4KPb0cwisKa2wkfl +xA0M6nlqkJ8hIzoqt3RyS3UypAapWrw5ETosKpGh7ns3mm9ZCAbPjraUpIzxYDBJoLB4fjTbB4M 8MdiNPYL34ojM0XQ4aqTPAR2tL9PWcAAfJxWVm/UChRAiU8kNK1kwLBCFVQUocKb+7HO/G2xdQVq osenZTKcVEa0QN+E2DzK6TMWp05Ynz5n91s/lGJscGaerBRBU5qUSzgW/1K0YFH8HxtTjp/KfftW rsLDnjsdQzQT3ksgDE5uDMqJMxZH/kYjRCXHkjOLaALe42c+58/bnDsjgJ5mnoyz/1jBx6O7LG2t hKIsw0w3cBpqgZ98UBdQMDRzmHQoxLDhkfC3TnPW6dMWBw7ZX75kh2QtNRYbhZj8u4vpeGuC5duF p05Y/rLQYf9eOwsLah1PWoUL0RUsQp+5hjiPmTOTw7EsW8BU612HjlvY2ljZWwmrgwA4l6qUqCdW jsKHnSVj80IuXNjQqJQX4YgybdxoluZo6H9Qadt53O9COy7P3dWuhk9+yBtVrhR9zdh+GTHGvUct LG3t7c3RQE8XQQ6Vr/9IXpCC+KGVG40YVaK4fCI1x5qMzeM57p4e7DYp4KJUnasWq7CC54koby51 /w6hk4sbi4F4V1EOml/cbah4gqXU88F7lIVjc/bcLqynk3M/PFUWiFWJ5yPxbBgMNhcvD0jPKKzh hGb/rQOD0Ss+bfdavqubO51GPZ8eDj2EtRhOdlx9soePWQgEQhcHK09P4LI2AK6yn79Mq/mDV/Xa DJCstGzP2TOZ7ezmxqTR7l7Padol/uVNee4ClaUZXZqGuA3PUju/yzLF+jT3LjBzdfewoRWhIuWq pUqlPLGQ2GA4dMDcztGFx0bc7kU+mpKs+RRNaQcNNCq18SODAXzq0XzrM71c6FZWVBtbKtFGBboA J/82t7N3FJjBiSkTYEAhhq0hoLPMXF1docADpyZJpobDtbC30c7s+bqIc1cLWvkKnO3tWrUNPhim 5FhQ9R1q40HXlUyaAmvDpC6bzXX38MiPze4zMhGfKSksfD7NzUfTAZVKEWUyXFu4oR61B9evWqkA rcIl2Aom4Lj3aKYfv9DMzpr/0cDtR/H4PAGkXqCTHEQiJC/ez0YdsXsT197ZjYZ3PbE1wedStCsw oqN41K41GJ6uxTYe5YnpkIbNXekWbBpBvRCpiWjkWDZmsRiofTQ4F3J2odEYqD/Vug2wVct5zu7u xl0I8153EMXtPoLLtXYiqBfiH0RcoJojjcUovcdj8BE3eSDTpSZcU+ViUrW0KH/8NjSKxoxgC8yt WnNSnkhBeKKyTUNUnxMpqAwLlvIs7Z3p+CgiPoJaWlKNe5TLobs6WhHuiQMYS88pU/I1UAjg2cJQ Sr+GdAcXdyYenWYJg8VjKo0kP8fSzA7Dq2xuQaWyEe/VqLRV3vW3hb2TK51qNAdh2PUbaJ+pdh8e 19yaoF5U5RCUgqsPg1va2Rs67kk3o5w8asPnmTFZTDqNRqXRiF9q8Y1v5xZsOlOAU68hV4OTZVbS TwdKUy+miwPq8brjfffXjxVaopFDdKibu7ZD3x+Kgb9DxpmFPAMTRgQU4MsIni110yahwBJx4mY9 LMHObI0a2/R7NvzH4dFnrfAc0I7PKJnhd0cFzyAKGWp1SzMKg/7xI1aTezLdnYsdKpCjgYX3GwUI zShmujN43k7FIirxTZeOPThm5qZSesobJFI6OtK4Vo56zw8PEPdo1pLBZnH0nnA5zWAh6oh6gtaN LEu6kM1iUk3ZaUE+GhyNG9PtBIYvmQT/srOjMkuTMsRhqYTDAZWfKsD75F6QVshs14huwWUMHIeG 6dkbcpnRRnRNV6q5mXYl6GTzkQZU4fNOtghTqTUcS3xi0lBAiW9Eao2BN8IIbC6qRWoomkroHKo1 A3BZppN+RgySgzp1oduYG2bhXAmSenx86OzShlhOLJq4mUwKhW1hbW0l4PPNzMzYLBadTqeWKNKq WRyTfi8OPLy01LUJxdzW0OMN/DwhDDUF2g4NeoAKc3a3aOW2XEi9lo60ZesFh3ZaeLk62uJzOseO //B29c7tmZYClJdUpFo7L/LAo7yyi/T9UMEE7FYDzWLb95g2f1psoZ9fwPUA488GFBrdcNaGWOLk FOrkM/S92EAwDs4ooH6oEwTcoSvT3sJAkBDBiYaDpDyufj7Ftt9ByXvaUJhMw2Bl0DEidOgrNEU3 aM7gmRcbVRIFkhZ16RlGYVGyVhLks0tfJKyZjziYmSudzkBlqEm0yVJ8e4lDM2OjjT3vdmh+yQuQ i0WGjVA1ZuABltaoK1UmazIj8TUzE7mFbIreLzxEhWl0D5galADkzWq8EZOiUIPYO9MYApPjnHh8 YgqlUmi6VRBcouci4QjYCUqvMqbrGzavnAMbRJEoPBrDJBWFqgS5qjG1prQtpbJPCjN1HUpEgy3n 6Eo7cMJi33bLDi1cPT3cBVwDz+dZCtduqHv5ao0rVxx6NkJz5Z65sUXSr/D58F+iggn4p2FIvMl9 JXsYY6DVtSOCeg9Gy9pDW6KLt5ChM+rggnBEBhTutFXIKTKEbdUNTZyxH4r1sy3XUFm+Exr6/gFK 19ZoCyQ0QCmRaUfwPzuideEpxcUCCsWIOVgIqTzd4DP3QGxQLMEkCrWtFaL5U3sNZNazrzZBDq10 metNEcq6QS0GW4BmhEXDDHxs0lKelQVaMlg6aAXF4HSRfnYIDDcMWZ8GaLQlPJEbV9kwetXy3f4o lxbedAbd0A4atZbiF7dHi2qeFxSoi9WZZiRicAQ0SwttMdgW2mBypdqlNvLcOl+k1k0HnZu/IxzC MgQray9UWrkC+/ghEQacF0zbTS43nm6+eBmo7dBug9EUWa0Za+tGYR0vT3d3Vx4H9WzAxSjIRWRG JwDZZjwHB8eVe+sRj+lGX+krChVMwA7N7BrhO74Lh4Z26vKuZ/e3sMnORaAG4zjQ1qzkIprFd6qA WbG+boOP8oAglVKFTWiFunDGxNz4PNSvd04k9F2JhNaHV6UFUuRDDCupxjCYXKzQAEq/LcPMLZG4 rdQMGRQSHVP088j3645oP/YIOMWEucR4tQr/akXME3I5pl/PmtmjfSNVoaYoN/+PHR7QHflGNmp+ 3LsXmZ3aBUl0A4xGKa21MU2RGBXQrR7dUoAmArceLvqXLdypPFyIpbAYHHwY376EROs/+qOHPb/l BySj4ry7m9J7OtopjY9UZhpNZMNH5gweEjpsWGiTph8IHy97ip6dJd+WDB0aBt/26hp0R4TafPo0 M76lQazIzdEo5Cg1glxUco1+PcvgakX37Hxx/zH452WRcujP0SGBOb26vi3QZcEs4xgXC9/WVksx iVheagAD1BiVavhgRGyfR+aVZKyffTInLkbboc69a8IMYl7Kx0wqvHQ3Oy9Hfuticv8fgif9jkZC WGiUX5OAps0D56+JfRVUcOdCct+ewUQKFb6DBSp8Ewti750Gi8a+u/tek59r2PofOoHbvzPTzsEZ jjZJAr6l5ESj0AwijWcdKyicZj+XK+Tysatr7W8bDKW5gZ2LK7iosCcRGb3rO7LYlCIlptEY0q9f Cw6gPI1GI1Nrztyt1aVTaEGGcugQtOsrdKQ1oanvJMEVmraHOOYoXytLKiEwNm3L3B2mgEtFpUa3 C8nQSuZqhZTOtdmxymba0qyQB7njHiBi6/aT2c2jiCFTmcbbMFpgKg1BcE3r0rWdQaF7sEGcDB1W 4TD0Z6JBU3PqwyzNm2AlrEv7RXXNbwXli7FJfYOLJafBLgUmTmyrPTKtkmGxOtGGxqYcP2puZe9s HDw9RZGuc/8wkdvQmSVkIxplClFRuVwKhrPoGrUZeFEB5HxankrTFrZILKMyWRcOufQbm5QYVDhq Ihr0Pu3ZSU9lIiWsShkbPSw0AcBV+aCeESVfLtpXfWBDIf4VC3E/jcZA5B0aU4++1sRmIBlcd4SE 6FaKRlPKKqBUEB2KvvfqRIarp6r3GhotzlOtXZyw1ijk9OUCcwGPDQplSuzB+Tz4T/9q8EI+y4wL KhoVT8Bw8bTucIPM5LRb9/IZLFCzDlNoRuHyhXY22u1Ts+qO29fLhG5AYGU4d+5a17ymK828IUum kJtbCl/719+5MTw4WqVSA896jOG92YpMxpzl2TYsxL1Xz7I7dDfX0ejDv3tTCyE3raYfSypXm5tz Hr6q5/84NjRR7VGN4eZA+2UwIjy6boA4+TpeO68RqxQcnAnWGe/TPCi0RxfjcwQUXy9GSqGGTkWD qVl312dthBcupsLh3qgxk8+mEQTMZJcymikMerv6zGSlxoFleHvodI0lG+JnzuA6uhq21jaer9G4 dbiLB01UIOJb8+8+anhsV9izt4hHOnjRxwzhUCTMWfMyq1tSlLoV5uYNvJfPlGIlaNSSWac6XWjl IDQzFJvbgv1TbZCUhVlYUXt2YbPYbGcnbXZ0K8s711R5YpFAgMa6a2fnVpcL2wzgGLE5Sov6zOA4 lbUZonAXX9tXz7lXryTlirF6DZlCLv3HB6jl6Ywyt9Yunqk+emJMZn4pnJNP1eoYjOjNLeIXC9D+ R/tLkWktq1NVakzXQfSaHjT3lixjSVvgwrE2p3h245TcpQMlOhTCsrrw6Ys6D27GX7mrgMydRqd0 /oEFBxiXJ7CztX7yyvr0gagHr5W5eRqMSnFyo48fb8bnsJxsK14RotLpA38WsjKzrG1t9F0EmaxE IoGzvhkbiZ0alTy3UGZtiVpZrVIB/AOFPq5GrczIzLSzdyqxkQygGA9/T5yxqGG0aWkChVLFZBSb /lKSk4U2DrwSX02yP+R2Gx0HBIyr5z3tyzhqlp2RwbeyYRmtTuH6VYNRqMWlNLW8MCUj38nVlWYI hcEqAwqNi39lwTTqjMxce3sbogpnzlp7epRy1u/mscgl24qcu5gdX+bFY3/qJC5XKFnMYnNQWmoK R2BlzjOVLNRyVdOW7+Ci/9I/zk52ZW4gwyomJyVrYLfpOCEFB43BdnbUfu2DEhaTVWyjS1aUnSNS OzkU+xyYmZFha1fMB6aanpFhZ+9Qsn/Lh1KhgO1Op5fSLKLCArlSSaOzzIUf/+r5fVAJOPC/gI2t jfEjbHcuz0AhVDrL2lLb97QS/UGlMRwcnEAJBF5KIRx0ankn3U2oF8LJ2bnUkCtnxsPffjPMuMwy Pxxa25VQi6FQSo48Gkvg6iooHorC5RoEOQqVBqm3nGKb4nNmb1aJ8js4ltKAEBv7I8G+SXcYo5RV gx6wii5GqkilwoR6Idh8a6cS5GNbogHhYHBw+BLtcUbpZzQReAJh2Wd9KwZVm4C/AuSyOYuTfRqY de9syWNT9+9MOn0BHaoYs1poafcl92/cP550LUjRqZd5kwZ8ZZFiyeK4twWISgbWoXI4308d/1Ng 5/B1dmEiX2Tt/aewZSdBqyYCoFCvXBbvn4GqPKwHU2he8avE/zb+3wk48WHq48cF8N/ebWl6T9dG zO5eVCGnzJm4HBw5lx2apHn0KN/Yc+hsPpvDo3+mLPfvUQoTN4KVNYVG/wo0fPNC2qNHSpMqdx7N dbHklDzoQuLr4v+dgF27em6UR56+LCvCz4TZudJ+HM4x59Hd3N2+bOgdvVB/18aQl8FqjQZtoDRs zujTjc1kcZydvtHlUqWjd2NmYHqZJ+0bNLW1tha3r0YrdY/nczHjD1/+zpCH/io1XuVaDehD+nLo DJaLi+PHI5P4d6jam1hfExgGaQ4uKanUryNYajRq2LRUWnlKwN8U+TmZXAvbMg5fw+oqs3MkNtZf cx8V343CYANSvu0tHiQMIAmYBIkqjMpwmIQECRJfCJKASZCowiAJmASJKgySgEmQqMIgCZgEiSoM koBJkKjCIAmYBIkqDJKASZCowiAJmASJKgySgEmQqMIgCZgEiSoMkoBJkKjCIAmYBIkqDJKASZCo wiAJmASJKgySgEmQqMIgCZgEiSoMkoBJkKjCIAmYBIkqDJKASZCowqgAAp45st+E6fP2HT+XmVv4 HbLTqKTvwmO/UeJHx9egUFp+o8Q/CxHv38lMrQN/BDGnZlAozb5iGaY0rzf3j3NfMUESH8X3J2D5 9uMXD+zYNGnkQDsrIa/OD986v2cbBtT3qVaa7eevgILUKADKs8DyibiyaKBvr/H/JgVv3/qz9z75 rChv7l0C4EusT5SZYG4qFXzJbfgkvhjfn4CRfZ2zMSIMw26eOyAOuWJbZ+A3za/14msFIlklH1bv Q3LfX3v0b1IoKijYPbVtMS9MUz5HjninBt5lWh77EmA03mdZZiLxr/H9CRjlKMcNK3ftPy7y/oGs kHOENXtMljdryqQxY8cuWbFTiV9WnfD6PIXF1QD52BGDfpq4XF6UOm3S+Ak/z9Sbi8Vk+b8vXjBj 1pyQ1CL4+Oz4rqmr9uteyoYM/RH+SQ++d+1VDHTkRDyhmNlrVPl9u7St79c2pkBrLlgpKfhz+bKl S5e+DDFYVzEAUy7/ddG4ceN+3bavfHoQZ8Uvmj9n1rwFaQUGe7Y5sW86tWvZrVef4zef6xJUrVz6 K0zwl827YSuIMyO69/zh1vtIAKJ79+jWf/A4ItS9f47OnD59+Z8niUeVJG/OnIVALV04d0avXr0+ 5JqKFH9s2Kh3b1y3vLaTHYVKM7dzASVw+sjO8ePHz5j3S3KaukGD6oSnRpK1bOG8mXPmRWWKcQ81 hULJVimmjh7o7e176cV7bTBR6qSxY8aOn7Bl99lSG4HBBYvmzRzUf8CyfVfwCNLp02aoDVePq6dO nlwoUx/5qR+FU7fc5iTxacC+IjSaRo3ewH+PQqRlB0LU+ihDQTwk+V+Aj/nQpUbjhm/u0LxZUyqV AtrOhX6ht/ZThUwbCw5Tb4DPElnrGPzzDhRZSRjj4VjxkQm8bIny6vyx+hrd+m0w4d7eHf7tBB3J AVeINCwcXG0ETK9GraBn0LVD0MfZq3ZjvwYUAH5cc9S4rCopMhRMpdGbt2zBAqDVsMkmldEnnhl6 H09byMIt4qrxt2oZiu5co37zpg2hIzBJpJZrl/3NW7TgAFC7Xc/C5Lf169V1sIIVZNSv38DPrymM OK5XExTRDVnu6zV7A/TJin1GRBRYODrwgLDXgeIFEcFXCTLUB0Swug2aLJo9ErCt1MXD9a3lAd82 aOTniJtkGLZ8J4qcHoZH4glw68EqvOxEOjQ6o7aLgGjJwpQP0OHkWatZE1Qdt1mXTVqjsRcyEWjG c/Br3Ag6Wg3/RSNOQIUZtZkIEHhuGwCU+Bxp2I1VjbuNLXuQkPhUfFUCVsoJAt53raDMMArUo6+i ooJeP3Z1RAswumcz6L2qng+NURc6spI+QApgNJgI3RF3jiH6YXIw3HxEzWnHoKNXax+PNsOhA9EO YBKpQrY+ePtDDENGpbe+yoI+NW1A4wEzoaMH9Or4G3SkBl7DY5hB97klk4Ue9TUqFP7n388RifA5 jLEbjhsXdlhrL0i9hBsS05T9T0xqs7UzpMWl0OELScuhNuEJJ4I/7qUgz5rOdGZT4/Bz+9SDjJFw V4PEufo64b6zuhcAnoRbXYjY3apzodAddnQyQTzZOAFP3IaKOpZJFfY5WKwcImTOE9GvGkkih+6+ lckVpTS+Ogm+TZFon2z4lOErEQHju3AsfUtO+ydWOxEQdZeFQqcGw3rDzmJ3g6/Cn6OdKq9RR02S hwQ8YsFfhFsWdxmGSVdhpxZ3gY74fDmRppmlQykFI/Gl+KoEjGHxoQUnz2Qo1WUGUKS+NOb/6/ae 1uD+NV3MR05Z6GxtgfjDwNkyBUoi9f11SMuZEiWGE/A/sWjoXf21B2A0IljEwsMPiWSXNwWgA6LS MS1cbD39MAwJw48SxdCnJ3T13wgdkff2QGdULpIOzi35GVh4iVIQVUiJEmAqNg1sOxNkXFrIjyZu 1xKtGyTgfaYE3B/GbwbzRTLzpWgtZXR3B60XXdSo5XAmOvkg3jg8FBWGrbtPuKHw2ut3LQHHXd2o n4xuruoGJQ1tBA2SMqQ6AlbgRVUppEpN8XLgBIyTrFrfto5u1U1KWxS8E4D6+kdHK+7KPffgvAsD 73yRRnhOrw+EQyB7RwLR0A03kJcMJS7Hu2DnmeMWuJXgYYv/xEoAEvD6swL96eIAACAASURBVO/0 jzDYw2SxWlEII1g1nRv78DBqf6mqZEQSX4yvvAZ28xEMHWRbjs1KKgdKjuBdeMDAjkjKWjR/dmga Ev/kMsWxg1ub9x1TIFMFnt3Mwm1yFWRlARrNgqM1ofgiNAP+1mreEigDCB9XKwvCER4JatR0h47l a9Zkxr7t6e0AQMM2Lmh/GObXtrYPdKTEZACWjaeFzuQ0BSgLsuBfNm6IS1aQKlODBvWKLRrhQtPN U+vj6AIwjakdKeOKuttwCEdGJvD0dIQLCkhMTfyKJQg5vkcNN21beQJMrZV4cYtq2mWtWgWJR1sv oERV1tvVJox10hhsU0uleAvhwaiwU1VK2ZObf6cmRDu3WWUcSp4N65tpKDydHpkRQbi97LWWq2Pj QC0fD6BAvHrb7G5GsdGWwdTBP45esEKmVJ9YMw18BCi8hRmTyuCfntw9x39Tz7ELBfZ1qrPREuPD ubVWzvU/lgKJT8D3njFwEVqMO/MSAhzwldj9kIyeNVyAa8O4dLgc1mQmRjgLwdKLIXANDJhcgtk0 huQ6Hsls0gTIltE6DREl8MoRy989Rgvp+1E5eEAtCzr3PJbIEO1xIyaJPdq3EvCcidQebJoNpTm5 GA3TvVeeyooyq+Gx4DLVuLCNhMCjTmvo0MhFdZyFLQdPMqkNjNJw+t/QAZfmdk495Ur1uQOIZhIh 09SozBmgc/8lMEe1QvTr9PGR2dIOVsCxWgOUoELcyMOyVuvuRDoJ1zfr+6Io9iYq1fkApVxcx4IP HDtjOg5cJvPCmSQUACL9L0xZtlUqVyqk4mGtPa2cXIsFUyPBZPTqw0qV6u3DS9DdZ+FW6O2Jqu5b JFM+vnwAuqJg98jDASGTo1jJ0B1eoHKGfxr0yRHJMI066g3aM4/MKtZcftWte4xenF1QJC3KbQJL Duz1r3j4FHPQP4N4fHt8ZgWMvf8ivnsjyhDNFBp5WFvwufYeyGHO008r1vaOUIYOuQ2FLqYEF8jH NAAOruORC58C4pFYLWbSaUR4rwaGpeaZhe2AbhsJYrA5R9hvG3SE3PgTCLQEnPnmNDGAtnfRfnqp 5t0LMsGY/GJLx3dXluiLJDQXlBxz0KfrciRnJr05rg85dP5q4m3a80MG+8sMbliaJOrpbkOCQkOC 8dc3GSc+sbP+YwwjMhfRUXZM+QSMdqGglHv/1DLj2Xn3q3STgCfm9tK/teCzGE3QTlJB6hu9QdAm 3frhAfMALrrrq/kiTSrOiBGaGb7H1fBtbJJ4Yy/DNySGmTAuV6Z/1bJhNcByK6v4JL4YFTALyuXy Ml/JpFKpRKHUD1RNkYjg1timuX0GrLtHuB/fuUvQoUatKiwoKCgUF0tFo5HJStvC0ajFEqneHRkd RzjVahWEvAAJq3lK00hqpbKoqFCKJ5iZkWnyVimXqTXa9ahapSgsguWVFYuuUmZnZuQXijRGPkYJ 6ghMo8rOzjOOKBEVFeblqdQaXZ3U8clppVSqBFRKRX5+fl5egUJV+lYEDCAWi+UKFWoFXeFRSxbC 4kv0wWAYvTs+JlJXEEwqQVCVljhsSA1qfBjE9DMEnB7mH3j2KeUn8Vkg7QNrsaaF968vIjT4UCPx dXH71yZd17yWazAm2bhfG/SPB/nvIvPtIbsG4/SP+54nkgPsW2DQ1neePX8jqfdb4P+dA8eEv333 IVpD5/Xr241W0YX5r+LEhpVtxy5wsuJUdEH+g/h/J2ASJKo0SH1gEiSqMEgCJkGiCqNqELDmI4px ZcSSJlAo7l+5KJ+G16dXtx59rJwAf21Zejc43cQzMSH+K5bB/97V1atX7z107kvajkQVQWUn4PTQ 5xQKhUajwV9rJ7eygp35tec/gab0oCrKBEBeavhvjRxJ/ruLN8oJsG7L7gJF8W1ZdZ6buwehWakR xbnUaVtaPOBNoahLfVEcy4Z3atal3/79++dMHELzHvKJxSZR5VCpCTj1/TWH2i1PvY5WqdRymTQ+ IryskBGvru+5GPg9y1Y+KNjH2B6mYdKKNz7NQqlQELd7qCTZySGRpcaLQPoAH80/Z9XJeyE5kvj4 eLFSDiLOPEgQf1K5SVQ1VGoCfud/m87mDmxUjUajMllsHk/7HWJCh5YWNjbVfHzvhWao88Mhc152 F9xb1RM6zrzJLDWpi2t/8alRvVZ9vyKFloGNbO0Hw7vU8H0dm2sSeGjdmimFWY3q1IAB7sUhXYsd Y4ZZ29g4uVefsv4qEWbb8uku9vaeXrVOPImGj2pJpocND4Zv0a4rzEBD0QAKe/q4Ed41a4yb/3up Rdo7b6STrdDSyuVSADpeiklSmzRDKpL1PGxYru2g8AFTs60+XB/+wfqRFJ45dPiYQZGEJUdThLxz u1YeHh5dey8u1m6HfgU1+9Uyx7UbKLR2dRzPXH31ya1OokqhAk+BFWRLXjzJ8X+RExZRqDBVkEOQ 5Cbpy8mzcnjwAR08nNauoaOXb0p61vafagLQEvp8ePduck3gOWZDSMh749PC8oxXxHn69Ge7YAor N/45sG1dALygz1+/j2Sb2+dLJBtWzD12PcAkX0KBaN6Ov/q18lx9OfbDlQ3w0f997N1DKwEQwgAL h/sCYH7L/8OW4a6gzjTo08AeNB+yQJSfPfCHngUq7PqhWXgaltt2/l5qI3s7WwBLj9svg64eWQsD JOTJFdnviMSzkmMfX9kPgFXIh7DkXCNtAaU4wN8fBv7naUDQW6Qt7OdsYeNa8/KF4zQALjxP0Ae8 MNO3Tt95+scebWqPmLL/8/qGRBVBRRLw2L6BLVoFtG0b2KjRm70PReWEVClEw+tVB4CpwG9neRIW 2qYOoo8dl7XHa2/91ge0/80kljjxCbDwgQ5XR8v+83ZDh6IQqeMoCO3iMMOtA0mBD6dOmTBgQO/W rVur8bfLLidC/6NrFwalo2Xpwecf5o5sAB09hozC8AAX36JrA9Y3BJ2WXpMk3APAzDhrRMAUamaR gggMf3Pfn5s0adKAvn3bd0I3eHi7WFzGU4Bo6Gyz8eTL7Hc3gNBZG1+ZVtbcCmegs1GEMgjS3SfO T6/zFIzdbLiK4NLsFh4/zNE/tqllM2WHqSYzif8GKvIo5cELDcoPIFcoWEyk/kJjcP8OfHOCZq7A L9NqW8d3+LLD2PvRxUKXWBmK0jMBDb8jRibr3KU9SgfXXiL2jgZ4C/Qhneo2W7LUm06ncQUCYlHR rz1iwyMXrSMC/Ny2TvW2wzHMsMzuVg9dB9d6+MA7BSA9PNK+SSeT3PmCsTY8rSZvAQAWdXouX9KU xuTwcaUrdEmQTrvYk6I7A1aoKr9Bitc3Ff6Y407bhhTjFXPnaXPiqg0EYBPx+Dg0a2GXep+RMomq g8q7BlblBLFZnPc5hJq7arBXLcAScpg0SDc/zjp8bNlo6NvAins1OBs6ZDmp5dzu2oUnXPQjOvO8 cji6a4qYtFafewN/Ix6f/mPfUwqdZW9vZ21tzWGWcn1lU0gnjj+F3vkbumd4ewzYFQzX4ltvoQui XryOfbLzsJWbbXrQHWKbaF7/HukSDU6Rhn2jBMTFWQ7OTra2lvosrtxHKrVhDw+dT0rv3QXXbufq 5lOVsqy64Et8PHkOuo9u950wlaxowvnCTq1a6cNwPNFNIb1GQskf69gCySrdvPhltg6JKo2KFgHK w+p5Y/TldPfulilGK9y0sNt2Os/uY2YTa+dbv3UDvstNosfd3cWv0RJ3ij2J+48ZgnQR0hgMfXxZ n/KZR4EmEaFnUJHhUSnLaSTQ3qpn2aSLRIOdP7yGeGQ07Ah/c5XYusl9tMnZ1MqWaY7/8kPjX+4Q 0btagvHHwk2y8PV21uVPP3rvPfSRpLzh2XnqsixThPYB4GSEVp/68uHfiCTajVpiEiw15J6+gsHJ eSWSIfEfAXkWmgSJKozKK0KTIEHioyAJmASJKgySgEmQqMIgCZgEiSoMkoBJkKjCqLwErFEpFSpN cnTEd9gmh3nl5+cr1cVySk5MJJ7TUxKIMshl6LCIRCr79JRVCpmihNlemNe/Ku7XgEouFsnK/Nr8 /4lSv8hU8q80lZeAj/4yybdVTxcv76tBqQAonRwdnZ1dvX18atXyqV7d083NvVYd36+SkSo/hMZg WlhYLLyEjAB5VfOIQIcUgYubWzYa4SoHZ/esIgV0sDlmBenRXDPOpyj0EZgxutvYHQ+KZVeUDPP6 ujq621o07jhv/8fDGWHnUMd+a+581VJ8HVT39Ij/FNUpTZ6HZ7XPTTw+4Jq9OZ9CobhW85bgvcil UDgcDgUHlUpFJ27UCdDNYTJ1nl/B/vO3Q+Ul4EGTfooIeHN2vO+PM/YBQN+1b9+BA/u2btmyc9/+ 6jZZiYkJQ6fs+CoZrZq72LNeVzj7bu5fGz6OGDzYnl1KMGniIwA8Yv1PAND206+/K0pPtxKYG/vI i4r+ZYFLotWEsSM7N/ysKFSdncSSwNRyOHDzPn2WKg1nZvn6jV3zBRGHDBxszfqEcBTO4IFay9LS 2AsUysdnc1X2Sw+/XjM3Hc5KTxTnJHecicZPWwCmn36VhZCZnVeIiJWG1M7DEpOgV0ZGhkzx9fvr a6KCD5KUi9FT5ijlWQt2XzP2XDEcjlT++0zD1eGRQS9v3LyVmEGcN1L7v0Enqx7cOH3+utb0WXJM +LMX/vLS7jnXqNXD23kOXnM1Li6euOQ8RnfhO2ycTKSMgLhwRoE88Oj02l1HnV3cedBh02NVeBYh N2/ezsjXXoauUkhu3rz5/E1I97q8Tbe0ekKR71/fu/cg9v09otlDAl/B33f+jw4fPkyoYikkuRdv 3Hj66q1eMys56v2aX+fA8M8y0QEyUW7arq3rbQBovey+ce4FGQmEObjZPyPjFX8f3Lt773nTmmpU 9y4e/qFdXQCcMNwwaqel2oaV5Gc9f/YsV4wu3I8NfHj4HDqm9uf+Q6cv3i6lyXCEvn44d+Iw1DK4 bbhiJdco9u8/OK2DlWuzfgf278+UGNo99u2dOWvu5aQkBAaHED6Z0cFFMlVqbChsBOJS/egYg1rV +8BXAcHa1s5NiswTK7NTomHIIjkMq4lNRDfd//3XwQNb5gFgf+jAgUfBaf6Pn+qj58YGZxcVu2df KtMaFejrZNNqErLXYQfAsp0Hu3dp49e4+eUX0fhLdAnE3nXLmzVr1qb78AJJicv+KxMqNQGXRMT5 lbBxP2QZDC/M792KzmT71KxBpYAd1z9gSq0+sI2zK0Env3ZGj3w2EwA3k9RUMpF+IuPxhM/SRbCL 9ZOaCQGXU6rOLXwAYNasgQ4nv08RFSS8hg4X92p8BjrbfCsBGUrqwTMDbH41T1f9vFkDd9CEVnQa 9Wl0fn7UC/joVdPHRsAC7kgi2DYGKXtU8/KxFTBmn4nID0bmYBxcPNp6OPGFQ4wLIOSb/XktGNMt 13iWDlCG2HjLyDCimlD1EPr26AF0ZpO7LEO2Ed+cR8acrHC7kFEFij2TfZwdkRFmZxc3D8/upda3 U1047Bk+9RrSaZSXsQXFSl69r0aa4eHmZk6jAQ7f3cP94LssfcQzG0cTJWQyaNY+baHPWCF+SJvJ trXgdNwSRFhFxNDEKjfnAMBG6iCetWdDn9/a+KGQdIaTDbfF0muy1IfAvAEMWM/H094Gyjh0D3f3 hk22Mqhg5dHHKDONkk0HK489LlF89ZF1E2FKL6Jz9C320/RFq8cNhQ4024hDUBsKLXf9dcK3uj0x 31VaVCQBTxjytnmzgObNA1q2DNx8p+ij4ZXiXAoAu298MPLLgW0tV6rDHx+mUigbD7/GtWrBoaBs DO+bwkSkP5SYLcaQqUBwOUZimqZS2cEdXI/T5a6INybgdB0Bp+WXScCp95BCb6FcpZYgW4eFaqx3 bfrI7cS4UVsCECfBCjOR8THCTsqjI78C0J1Iv2F7ZC3N0dLsaWReTxd63/XIdoyXDaS+FkSAoRvP ylUalUIOo67rJQDU/nliqQaO7uIWXPlmzCOPozDdcISBf+pap9eS64ZmCkEG0yLjkqCbsHsCCbjl ImShGy4H5h5BGtGtGnj1nboMhdaoIEGE5ZZZZZjU+qsoikwigVUqXvL2RJjQw1NotUeZRLx+aBaT zZWp1GoVsr0kRlMPJFMX2DIHprVsv+4VJo8k2v/upkFEi8lSAonLj1s39oJsVqHSPFnbo/nCSykP 9gHH1tp0ZRGEWUaIa6ugLI0sMMc83Q4MtmP1UHPZSEB/kZilr8t7nTWc3gD03fuBsIes1NqSQZsV KeXN3hWMiiTgkDcFL18VBAYWPHiQl5pftk1hHarx4JAfbewjif5HwLaxhQsXJufUQzSk9GrxBN6c /5PFFRDusQ3A8fCCkEMjdUyXS/h38oRMUqeNrIg1JmBEv2q0Y1xQqvyNY2Vj52ajV6GAUkTARSpM AECeLnhNABJkWOyzPaChVl0ZmVwEPxDpxxiZEBIgW6RoET5k7loJLg+/ObqL0E6yrYaoQpQaYsVH q3MWV4gVB5/DPPYIEjDS3DoTjeryY/uaxgQMxdrxPVsT1d56Ak0ucLAuh0xbkaKv77VfWnf7eSHu VEF2HJJT5rA9uHQGkVSjNtNNSi7VzSwRR2cC75EmEWHdOXyhvnnfSxABbzr50hACt4oI//bngXF7 iUlQQfhAAp63/rI+YPK9PcBeR8DyKKPFoAYOk2ELjsCFRvvpl0wKYMMDXo1alGY4C2FqEzBsV7CJ ZyUn4IrcxKrVSNC0saBBA0G7duYOwo+UZOvkdjEKrvL1IWNPjZpSKMs6dCcUk0uGtG24c/1Ok1gC G3OVUmuE93YQsBeyao3R25U3yM9R0aa36nw63Hyo8VloQ4jK4kIxXaUBbgBsuaW1uwslhMgMKc/K DQQuI4qRk5cNRQHirfGtdjAJ55bDYLFObVyUEngjvkBRb8RktNST5WfGPAiTAJZNjexCSPHqBvyC 4fvemxSDztDurA2qhhSnWEK++J1xGNr+q4ge/I/PmTV8OgoAWw/+x0BK0cRNeqduZgo49siFgfL1 kkevRKtHUdr7gMd/5quKlTzu+SVYchhGJc0uLwk5anA3jmkj6FGzFnj6AIkt0oxIvLClgaXTvlQb l5dycu30k3+MzgKMG5t7GwdXpj/IEvEj3zxjGHn+uXYj4dCI03e+AiN71wTKvBNXHhOe4TfXw1+7 UnRMKw0qaub4PCjQjZOW9SbPnzVr5IjB3Tp1atm69YT5G+EbSzhchTZz50xlwt4U2CmyinFgTEVQ aSNnS8ARWpeadkdP8JfObq0JB0YzrxINtXI4sCIFfYyZu+bP7k2doGPXlXd3diIbn50HDCOu8Loa WQQZIAu/wq5nQ199s8PfWCMOvG12V+gzauqs1vWtoOMgfqllyw4/tHVDiofJMjGsn0OdRsN6ozX9 8mvxxmXgcxgnXsTomRXErp+H1GnbQx9gQX+YL2fUhAmQO3FtOkIfuBReceMddPR2sYZ+vRuhQRpd SFxJhDjwkxjDjSXTJ8/WuyNPok21XgOH1sIrIlablvxsMFpbIg5s1t6krXDpQwtLW7TOhxx4c2kc OC/mKXS0bo/2mZv2HI6VwoF3AQ9d+sU4sLbvHJqMM8ldHHWq2NBvMg32Lr4E91y/BtmRNbdqj3co 2mXsMvTnCUOQrui8A3dK6/bKgipCwJh84cKFK1as2Lx5874jR06dOnv2778PnNfeZRX46NqWLVtD Ygjbn0WuNRoUi6pRzxgzatK0ZWUlXQ2AO3EGU5pwVUw49u4/g/9Vb991uPzCibPix48ff+HhOyzn 7dpT+OJQnLt27dr7L8Mzk6L1Atv1M0e279gnxzQvAyLhY9da5iaynFyaBWOdOHeLeCxIjxo18scR Y2dnFREBRUtmThgwYGhATEk7o9oyb125jnCkvj7fZcBG4xA3j+/t1avX5n0XiMd3d06KZNpYRzYs G97nhyKZ4UKxhrU89bu3qY/WAkYL46TC/e8NGjRo6oK1uoWiackhVJlBU9dcNCklJGA2l//08dNn eAtA7Bri8jwyyziMUqUthqogaeqMn/ec1e5CnV3c+fLrpGIhDRsBKt+2w/T+6gK0kC5ucrYcqLes mDmsc+dTtwxXo8ny00cNH9auQ5dMaZkmmSsJSH1goFTIGcxP+fL4fwp7Ife3c68mdqr975MKu32g 0cB5ksJvexBtWv+2F6O5ycHXv2kulQT/1+ZFCZDUWz7SC0RlLFQ/G19kYOOzcffC4ylXo75HTpUA JAcm8f2gUcpjMmRezsJvmkti5AfXGnW+aRaVByQBkyBRhVF5z0KTIEHioyAJmASJKowqQMBKaeHt Gzdu3r2fV6Q1NZgaeM3Bu6lJsGdbR03Zff5f5mVBoRR9vY2W6g6CwBTJV0uucsOPQjl0q0zrc6UB 69u5Ywld6S/B/JHt99z8pKyb+rX7CvlVJlR2Aj68diLTTNh/yE9D+vW2FLDbTURmivJSQlRq054/ tvVufpaphdHPRT4AhV9Nyx1TKaQpmf8vZgED0CZzWSe4lBRKCWupqrxLd19+yvZ2MwpFVu5GzcOX HxJzy9SO1ANTRL0KIL5gYQ6W3Azpv1OYrByo1AQccm3P2F/2X3yXJirMKigSF2UFPdq/ICi5dJJg AOBt513S/6O7dF9lG0+jVkeHBpvc6aFWf46plI8B06iIomo0ZRUYUypVeMjvZtMbE+ekRSZmfCyY AoDHpn4U/U+xBEtG9kf6BuUmT6X6ermWUjiNSmPUYrL4N/WH9CJeKeWS+FRRySilQi6TvA0O/cTA 3xsVeYrkY+ACMHDNQ2MfHpt+4kXsh8vrrav7ET6/TBkmFPAtbewYDPqWS6Y2Ftp7IhNHlnbO/jHo fJ84N97DxYEnEHj5tCECPD88m44+BbPbd12P4Z0dFhPs6eZsY+uQWUicYVf5eHnweDw7R9dH4ejM kL2NVWDAdWc7KxgPKT1hkho6JcHpZ0KNMte4CMHloKga1dxtbO0+ZGmPNh1fM81KKLS0tp255uTF 3dOqNfyJ8G9nyd/zEp3obOLpYsbjObi4mahOTRfy5x86a2+ODv8tv0kozUp8alSzsrKqVRfpeOR8 uAvsvQfWqYlXuY9pa2rQTUBcvtDG2prLZTLNbKBf9P2/YGH4fIFPHV/4mBt6u17bH/rVrUWnUa0d xqIMChI8XZ2trG3mrzdVMJ7oW4dGmDhmNCWabv91ZGJCKcrwru4OS9Vr8lr4WJ8FuIRZCzqwrdHO EF+VAymvjo83nUazdXInjE209XGdtwlpKecnvgGA9frYCkA3nFzOLq6ZO6mPD+wXaztnFh3cjUEJ ZLy76OJob2PncOB2KNFiU7cdIFps4ZU4ItalzTOpBNtCh0eZxgnOay8YfAApKudHXqVzakHH40OL rPhMY0ppW90N9o6to8vbrGKaxhWFiiTg3DTRzavpd26mvwnKkytM9b6UWUEl5hcNj039+wkiYEfv JvD53obRwLxmUFjM0xvHYeA9d8KMQ+9aMoTv4CWSyf7asfqGf5Q8Pw6GGbVkY04WMguWq8IUEuS4 +DQ2Kfz5T5MWYDpWPH3dzs4A9FuDTt6Oq+VoXmdoTn7BjC4tXduNwHSWu09cvg1X4cEizM3Jqlrj 7jHJ2f5/rzj2IsW4tJCAAQ90Hj1/8Y+tgB2isSPrRgNgdu9N2OUVPUH1XtkRDwGVKYV8QhIP0xRr kJJwsz7jcvPyZnT35AuHGVdnPK4622nEmpsHfjET1IY+dW34jjUaPH98C85BZx7GIvuGOJLTkFnW kjo3KXHRL54/eYYbeVpzORxTI93po5f9MxPDaAC8Sy4KufIH9KnWY0Js7BMAGmBKdBlFu1GLb/6N tEQKjJJKfP0PoLOvPnytlmd1GzwNMyJgOwDY1fs+u49yeRQnKsrJCAlG1omjExJTswsNSSACBl1G LUjNyJ7XvTVbWB361XQ2X3n0BXRkhl9Dva9WROFW3c8GhOkvWiCwaEQbZ5+mUQmpVw5thgH802Ti VGStavKSTft/n0Somhm3GAAu2mwVsoiwUHMWOHY3MC4+0TjNlnBmvJ+MEapO7u3VMqSPsWLTWZlc 1asT0gDtUd3Jt0P/7Nz8jSNrEzqhFY6KJOCJ/YPatAvs3BmZFz342NS8aOabiyY2O9WKIjjOXscX +h/7zbMBMnrkV93m4DPtBQ6OVtx7ITnG4WHr3403JLt3zWgbD0IBTas1vqado1uP302idJ6IfN7v Hd52wWlCPSA84L6AixQTDj2LhqWAjsv+qONPbflVjGEdnW0Qx7N3PXMvqHgNEAE710ZEmBR6AYDe RPo7H6eiuD/VxU34oung7zeJq39qY12/t1qKxvSjO+c87QHgCJ4lFTvPOwINRzfoiPf/B1fKK4CB CYLYVBuZF80IvILYlK4iUgw79PPoQf36tm/Vos3gGfp0mvs41O45FTpOT3Vz7Dd/wzJkyrhW085Q QA88+QuLXw0PJV+84fCHmztpTEtiZu0g1Js1RUh5e42YLBat2qzS5XgxMEGS+ADSLxFmSNeGk3Vm TQGhGWIMFVyOclXaeVtJ9Ii3s8X6s0jFQkvAOLoDsCUo1yS2G5SVCrQHleGUkSbHjm8cw+F56bMr 1LaYM9FiJswAjpaTz2NN0mwDwK5gdK8LImDn9hp5HqHh1WfU9ByJSqNCe6gPHl2vDeUtOvN2eBZW CVCRRyn3nqtfzluBswMAEjkGWLp10qllI9SA7efGv3m2kEpDvlJxnpud4ViPXGm65uzoxtW7syPD 7Tr8jDu115Ste5i6+/lwkyiHd/yK/qjAo4dvgLIVHGS1m/Zbu//K/NEd8feI5Dwc0f0VQ2Yh4913 kzLF+Zkrlswe3LFBTIHMU1DsYOauv5FaOYsKxbArhM+PrWC9QKOevcApWFrK052jWvlNtAaP973N UogRx+s2YNLaA49mDmpjUrCrGtXvp49AR1F+PloqypD6MWF00Mwd4NjOAQAAIABJREFUtUZWcijd uY6VLrwKAyM2bOou0nA4DC5fa53w78VNX8RLsVB0HdTz+8rUsL27PvjkKjALnaDKt7PA/zLXzBv9 6OBqgRWPaH6mRbHCONbrAZf9D2+c/GHQuCcfIp6e2oPCUOj5SYnA2osIQ6NTKeUo4tG4hhWv7i+F CtTYJy3g0wCw5hruJlOqsZyYKGbbOXofKt5ii/fv0LZYSZTYw6KYAbXRFiaFaQ5niPC3T3v17mvl +lCV8hJ6du85YvH268vGdP+UQn4PVPQMUh7qokbkJ+UjpbvNS8bC0j5MRkzgxoZ51f1aQce0FvUY LHfoyPhwjUIBe24UE6Fh+GW4qlrQ5R2rdj/5Z+M0qqULmvGlaNMlUor91gywzBBPlhdlOrrXJKIk 4Eub9EeroPBI+EzZeRN5qcUsJv0dfpfh+yTtDR5wVrYxN8e5CJo77iUbyxH4GjgQ6Ujlp74mmhpy 1o7rr0LH0dn9qPR6KJokx9ARKiQarD6CbnVSiLOZNJBudJWPkM8hZNSUoCuAbqbCB/q6C28VknxY 9zNBycZbA/DVtXhToSYv4AD0vx9FMGks+NBoQGXk46L2i6MLaYzGkAPrU0DhwyE7paRIFamvz8GI xqucRf3qRuWiltrZs51n2xFEjteDUjB5MnRcicnHCqIgCQVlKfXlKaEVD2mF8joCySND2nnD1Tt0 +Pq4dpmwFDpeX9mqH5xeiAObXtjStZ4dyw/pS4acQzeivEiT+p/aDCiMfJnq6vqhRFy9riJqMTSj GeBgzj75wpQDz+0ELNsiFa5Hh5dCDhxwfu3aM/7wMTUICoP2sLMFAMxahxZWaqWMT6c8i6p4s4+V moBhM03ubfjee+qO9raEY79PbdCK0PZUtmtUnXjbmstds++pcfSk4CerVq3i8ZBB7fCEVI1SUh/d fcWDnnVr2DfqvFSjVjrjDGfRokUD5m2FUVq1aqVVUVMl7d+/H/5Ni3t78uRJIotLN+8TQq9Ip3kH U7hx5YK2eOevq9TGK3m1NQBxIpSeSoIrFauw6KDb2srUR/w8Gt+mcnWwXHv8EREnPeIuT1ffxVuP GSdnLuAeuoX2ZmQ5MZDbSTTY04t/EiF7z9kB/WPubrTQkV9jIdhwu9gCT16Qajxx84Vol+uP2cP0 Pu/jM4Mv/GpMwBDbftEG2HXR39h/39Qh+og3A9C6ETpexedDx529WjY4ZslpfXiAi/TFYWB2Fp6N cnHFvcKkZyW5SwcA1r82FaFVslxfJ20wexveuSAo0Kon6AbLvcA0osW2nXmjazEgMWpNRyuz4w+i TdLMiHxuyNu5bRwueBOYsQnt4WXHv7TU+6zZ+/FLZL49/tNnoVeuBEOGgIsXgVwO6uEm6t+9AywW 6NsXnEYXxIGFC8F6dOUC6NMHPHwICgpAzZrA3Bz4+yPPSZPA3r3IMXMm2LYNObp2BW/fgowM4OYG 3N3Bo0fF3hLhly///hX9RCgUKiazyuifKdQYk/Z1tKC+JHelmsn49OuDKwz/aQImQeK/jkp9kIME CRLlgyRgEiSqMCo1AbtQKO8rWhdAJspLypH+20QK0iiUilnOPdw4eNjyE+UE6Nq2uaKE55tXrz+W MLZt0ai+ffvOXv3nvykeiX+JSk3A6IvEl67QlRnPPBoO/fdlOLLip4b1TD/Jfi5U8rx/X5IvgyQ3 OTa5vLPKtx+/NPlYq1FIGzdtEl2APoxJ85MplPYlY/Xzs5m/9axAKDz2xwLvZn2/ZolJfA6qzJ5k SajVahqtjH1CDFNLsuOD3iLjkJ/P+jAMS46PDIuXdWlf7+eNV37Gbw4uKsjjCy2QjSGMQqPq0kR6 A1Tqv2au5dXlC4B/7KLiFc/NSvnc2FQmh9jahD8qRSHk4uhzhVEz5rw7czFAhGGEmdWdFAo/WYE5 Mytsx/j/GZWaA+vx/uYBrhmHzeacfa+9gX3tSF86BIM5/w9kNERelMzjmjGYTL7AE7IQCpXKqdYP gAjosLRHdwtvH9ELxTfj5uJGcecMab79xhs+1wyOy3W7iomL0wc0Z9Kprp7eXTugg2KL2vNX3kKi gJ+55d/n99CpNDqNGpGJhOq00DvwERKzQIjbXwIaJ1sLBoMBsznyNKGsunQ1F7JYLB5foDsIhHk6 CGFV2BxuUE5xYRZTm7PZNw/9wmYxqFSaTIWIqpGAR8ezuBxM6E6qzIUCmKkZl/csljhvJGbSYamo fIEPwJW0AIc5oLmQw2Gbt1xZapEamcMCUFhssw+ZaMWilGRyuejklgedYumELqOk0qheXafow5/a fbZRp7G6J14DAO6EVbzF4/9TVOhX6I8A4NoCmBgpIfyy79LdA+ugQ4Zhodd2w3GTWSRLCn+y9cRd eX489J/yx5GiQiSp5quxwtysmGcHAaiWlZklkquizy+E/pcevFw2qiMAljDl/vXQacrTtx7MqlPs unBZIpoOHvmjW4sH/TgZw81tjDiINFQ88ea68CSiJQALjt4hzKBtuxQuKcpZMHseDDDZwwa4Dywo Em+ZOMii+HGIoowQoqlXjWgG2LahEVEutsKeUzdAn809PQCoJZbJ753Z+TC62HkjjVqOz6+uryNR C4hkqp6+7nXb9ikUiY/NbApAWxjGXgCE1u1yi0RNqwl/RrZI0PQ0e+MNmaRg9fxZMMCp8a7ADgg9 Grx4gqomKnH4AHo6d52amV90ev0EAPjQRy5KJkorKsgLD0DGjTOys4skhpNUU35s377Xav1jT1cw 83gpFhtJfAdUdgLOxbAjY+tYVh+Me6g4VBCdr+jpxh+31WB17tSfk83tmuNOiWFKMrqt39XBYvRy ZFFFWYRWgwoM+6EmGDrvCvSJfnrxbZzhVLoyW8uNh06YKccP2rcA4GAIOr/pAkC3keja9F9rgqn7 rzzeu9zco4lRYRHlBDy5YmuJjJXsfRRpXJG8hBdAp3h8JRydcMwPOAKqDyRU/KJyDEoLBwb90LlD +8YN69frMFCjQm/DM9GJxe0r1qhwLd9rN077wKJQ6bfexclTIHXxiIj1rMD+h8nxr9CZQWMiRQSM 6zlhanROs0iFbfllbIcO7Rs2bOhdtxWmFZW1sINCiwQTpT/WeyoKkcaSiYHN5aO7t+yxVP/oAJDR qTL6kMS3RWVfAzMBiA5XNe1el3jE8HXWk4SiV5Na68PkREfxmxIn/jilJqJWKhs2whUnKGi8Ems1 z6ZI+79ayz7GIelWfpDxBTy/NaxvD9YLDHu/DTYQHV/jJgFw88950BEWAcxFqheJYfVr9zfKQwQL 26j16K1H/pk5qrNJAZRSg+2lVl5IvwIDCijdamQ5AJi5WhhswI8+eqyPSM1i0TlcLsAnBRsLpB0x ffliIsCgYdOXbb+1cGQX6E5/fl+vOWDl7AxX+wnxgQD0N1kXNZmw1YyirXe+VPXzr1tGSRQ0JofL N7U9D1uHRv34JRl9ujVaOfU8AL+hKPL0NAB61xR8LBKJb4OKnkHKAywelCkTrqDDiemF4ktbkS4R 5CUDfRjeDSYolMqUiBf1+ky/d+hXwLWQKlXiLGTZKKgQ50BF7/W1m1/THYAaYokEGdxlIhVFyIF/ ORtVMsdJbeudfxYplUrvbR9FKDO0QRw4nyhMMq7nsKcTHTSY9er4L5BqiiQymURU1x2prcDVZudZ O6UyWWE+4vP+RqoEeuW4pgyad6MJUqnYlgsm/LadsCW94dxrpVJxee8v8/4KMC4MwYFzjNifLZXS Z8xWPIssSwCuP7oLAySJpHKZ1NuOP/jnPcnvEAdOyi6SyyT9W7jAqCfHujYZtxmPjaaDd4mFWHFA z/23XkskkrH1vCh0pOAuNuLAsjxInqYcGBYbzhFtFxwUFRV6OwI6s+UndymJr4zKTsDE+fM+HbSK h5GpaPzJRTn6CWjDuWcatUKv8dDE16WG30wUp5jBK0Ud3OweYFkW4mbKBtQvnYD/2TBNn/K9D0g7 f06H6v6Z2rtsUvGBnHpnCQBdoGP28A5ESN/Ow2A5i7LjWbrTs2MXbTdONjnwFNKPR1aUdBYDXPso 8bqlR/jrc3yVUpy61HITAi7MCHfUBZ60Gh2m3zZ1MPHYoVc7QPeEYY7/PobwsfOsA3NY6ea04sgj fXseLGZdWeupg1N6gRTTroE7ahuuULvoMEF6jG7nz6FhJbdh/98GeRaaBIkqjKrxGYkECRKlgiRg EiSqMEgCJkGiCoMkYBIkqjBIAiZBogqDJGAS3xaY5r9gwaTSohITsDSZQjE3vmJULSugUCjf7auX uw3nxoecj4f7D0GjVi4b3g028qYT94l2bkKh+PjUpuiAX9uLeqG2q6vOr1b5aVJp9Acp385AlMaM QUksKt2EjSj0AMV3/Kek0sTHNijrqxnF+p6ovEcpFUVpcKzYuHnnJGgNz2Eq1MRvEgobu32Pg3tM BkOl/G5Ghr4hZAk3hT7L5RL/j4RTpnLNnDjWbtcu/tWzb8fH73ZeWj/FDvq36Hth7Wo4c1LZlvhw QRdxT1+3wZHHUSqV7jUafrQAZQ0ySW4818oXwz5ul6xMaORqFShLnTPx+ctPTCYiPMsFvxr72LT6 /k327Pip2ZcX6fui8nJghhAdnspNjNh28x3hQ+dZmjFAdOqXc0WJ5CMXfMhlUr19Mpmk6MtyyYwP Hzp4ULK8lFePrhwfMHDMlyVrDHHa28hMVDy1iZVGtfzi7VfFfDQqSHsKaTam/ogoiympm49cyk2L 79Hnp9/r+SQlIcMimQDMmzVLJctPTs7s2pWwMIhyHNq9VVpaWoGS26iuRylJqaSrfx63aFd51l41 Gkytgt1RpPlYweSizCy8MfPzSpC6BtXfnFP6FJGdndakae1SslYr/cNS8AS1WpAaUMuaDlRqTW7s u4joXFWJIknlWh+lwsCokyPfDh40MLPkhSbfExV9FKxsKNEp3Iw3yMROaKZWX4fHZpx8EquRF3jp yt9jzn5MhbQIC+Xq1Jd/AYDb7Do5CfCHFE+tQH+j78WXMdDj/vHfdB7mhJLdnB9qEM/VG4yHjy5C sH7fXsJn9TWkUViQFqZvt+3/PMDwQ2y/L9FqxiYqsYzga/oA087GGOc/f0hz5Mti6dpc2aiaDRGy /Y9z4TOslN62YofJxU5iYpj6p3bal16NO8DnnUPtuszfS9So3yCt7kSREgu/fQQ6eGz06FKzMUzV hm8wDgbAIPj/9eB0IlEnG97E9UdLNnxuQiCMs+mUP6Y7pWft6ObjDOdTc7zgWhuuvn5NmAxa7S4T jeNqFIWE3iVuL6M9kcJj/L77Y2vGERGHzToOHy2NiuXTe7JxIpd3L9S9sRKrsbNL+4BmYwmDF407 IhNWmeHFro82Ocm5aHAD/atRfxyDPgkf7hOPdrWQUbusMGREytMOqb5wrdy1AwS3xaXHweep+gRf HllgW7c94Yav4mRY+IMj+pDr7yZB/66O2t40r/ejqZmvb4mKJOBXD9KXLgxbuTR89/6EhKwS52lx AoZ/l/VoBR0ynMb4HCYk4Fl9fGu17Qcfr26CY6I+cTVESr5saI+GDPwCcT8Axm2/bJxY/3Y+1Zoh M0WSlOCUPHF6wEUofdyMySNsHcG8s6JRH+cgpVfl+RvPMZyAgTlYceLJi4NTAegEfXwB6DzzbzhI x9X39uo1mVAPYFm6iJWapgCEiTEhj9158ia1Bkt6+yCh0GAJQC1DM/3DMDQmdqxFd//PqetlXXcQ HPD3Tmwgqgkr5dm4s65StY0Lf3fXUpbQEyYb5n+RCLwNt+zRfuyqEd6AYVVNoVKz6WD/k9TU99eh /9qjN+F4BMgqJ2o1NVJOcCaSGtKtLpygUDvkInuZUXmmx5z/WjkJ+tfo/ivxCN3ec44QbgsA5l5P wZToroKnCYTpRCTR5BoN2Ed7JwKuu0IJ6y7ffe4BkcKjZJE8DUmzJ54nylLeQEcerqopzkbKJybD PeXFSQBo99Ad8dquObsY1XbWzqtpzw4B+3qYRgUnpc2XkCWqB4eWgOLqkwm3VzEEtmgwaVQWDOqM P89hGtRNNfpvQ+OHCXY/TiZ0SxybTf9fe+cBFsXxNvC5xnH0XgUsKPYCqAgoaqyJLbYYe+wx9q7R qEnEoEaNvcSKjdiwYYm9oQbEShGl93oH12/LN7N7HHfYkv+HyiXze3xwdnZ2dmZ23pnZvXnflyYK gOEctneUTdsZx6q0yfHFk5p1+lzXIErm7+CfImHJ70cdzZWR0Wv6C+1QC/91Go745qqPKMGfUoAX DH/SZ+Dj0aOf+PnFHI993XB/rq5xuzazE9QKpCsEGMb/Eb5SyEwtLwuQEjwMXHpZxGoS/JmFVO1j UwzcXsCYHD3XIIsmf9EicAoT1Do6G2DC/XrrA/1LoAB3/245rdUl6sMOE5uXDGcHWomaYAU4pxTp KMnLy2DuMxl3eFweP2jseoO6UGrW7pSpyPxhLqppLWuwYccGUxNUh+d5EraEJ4/9xlYqMddAvXZk KzBvV6S5CE1Cf9xCqvP31vVnvaWNDwDjGHsDXf3rTtx0vTwLeehjR46xvmDWUUYtWZ1S2U0ZDeS5 x+L7CWFrjanS5IPboEkpXVypn6xWVerxzw0CfdYhsWHks7Jhs/T8bOb8FcG2j6WVtaYiQaZUuXds oGfwKLYEHlbgOTNSvlHZePLwTt2+Yj3OSdli753Wmg3k3T0IHFoQSpmuOorCtCoSuKB5wx+3az2q jbO2XHv4XnnadbggYGO+G/bZsF+u5MYegVeVwUGEKKxy+d01A0G7H6s0y+sCzDrU4vEFE389xUbu iAg3M0UP73piLv0R+ZTvwCvDm5062nzPnmYxMX79fU3fkfLSoxzXrLuWPoF0hWWmMTM23X6cCitQ zxG5IukHwJWze0jHkJ++67n1IBpfm9a2qZKJq6DyW4dKKhXas2s9rU5smpqa1K/q+9J3476tCJ4G FBwXBD/szE3NQUODVYXiEWsfS2RhCf9bKy7TqBSxt87d2TUjWamXEUcAO2y5pDhsei9fT+QLhlCD aRPCLtxCnvgaO2u/yQ0d8xNbKR8Xg690kmKwauzX4Sevw6lmUDBy/3v/0omQOcNgwKt+wKXoWBjw dXR79eAMh4MeKFvPhCTgUcsaVIEj/Hl4999Gto5Uka8KNxmcUqX88UBRpCA9rSv1hAUmlRbvfr8D /P1qoUh+hfkuDfJjaqNnFM/VfzBFkXnZqSYcotOkX7T3pIFcRjm5soWhFe/8EKGRy83tPZig1jFd 6uO/gsLQFzgKkKCsTOvKUJs1AOxLeQUlNCEhK53IZJTkkioVEGj91chKC2GXLyl6AUCQ5dvcPrz2 O4eDl7lcZvCh+yAcfZTyO5cits/um8m8n0/6esSRi8gxaoiPy7uqV93U3I9YpFzPzBJX+EpWKH0R LZWrKD5nQFNXkdBLKimM2PurM4cTdjFj7u/fhM2YG7Z5dSe/1ifmDwTOQ6uYWHO3AJ0Hz0lLfzlx UJfZW853aN74wdUVKTkF+8N+gGdvZirmzAkKcW0U/SRp3+ZQC09kP4AiAavcLrRBvZbi2rgCTV0/ t8K81F9X/cjhcNIMf3dQS3K4HM6hY5dSnqMZT6nXD6J3TOw4YNzd2CeyMgHQoI8eAbXcnbwd5bKS 40d2WpoJ1x99ACslFNRhK+XGVEp3ef+RQ4UWQo1G+ufZiFYN3FqHLL0fAzw8kTw4NmqiuYS0ggNb WSWmajvurDkLpozoc1cGxgc4oWPCoPN9vzdCLZcJzevVdTCwf6DIeQplZtKQPgEBAc2bN5+8/g8o TbCaE+b89jL5WVffBqXAekl7B3XGORh5JOrmvWsnzSzqNAieYq7X1L7O5gtD175IfNGI5qrk2vvC pfDQJfNjjm4IW39iwoCQIgI0skNCT1Oojap86e/czPvk4e9Tc/J3/4xsGNzLQQOhPTOOODVoBtSp fKGlrUjQqn3fSxdOt2teGxhK3PLfF/w6+auVv23d8f3c3yXlUo3c2jsIaLIHT12wZsX8vVFPVk1h jWwydeehUV7/yxghk4KCXGBI7Qberx4/3Hf48KIFyO1TeUaMyMIq8vy1tKfI1BGU3419mlFUbYlM cv7E3mYcTs/QS+Cj8TGn+3+EpvgpMLHQjyHUsqCAti+L4RKGmtarR8OGDX39A9YcvUwjz115XMZw DKVArZ/ymgIrKc27snr1zDFj2nfuTufk0AkJC/r26tW7d8quXbOnjV3+63H64sUhXw2q59P49IoV fxxH9npg4uJY5E6NVEvzw8PhKy2lKoPp+/Xr16lLd/GjeJiPQCCgZTI6llHEpwjNiePdunRpExCY efICra4shFKS2b6Nr6Ojo3fD5hE3tE7xFk4e0aRRw5Z+bVdsPcFEUDN792QrteLQ+Srl37NyZvMm DZu18J0yHxmjuvRTx0FrL8LAlR3L7dw8YSDv1maT+l2k2ejNtkNwcGBg0N2kgoqmzBVZOeq1I5oB r+e/ruQrh1X7MWz1/v1Hok7uW7kRuSYrSrjZ1KeOi51dqzYdyireNVfOG1fLzcXaxrb7F0uqZHF2 7bImDeo5ODgGdOhcrEAX+DZrLlejwM5fF3q4u9X1aVlUrl2Wa2TFXI7D68rE33Xr6OrhEdix68h+ HSYvPXxyaeCM4+wXQUWF82F1l5B2jRo1GTh0RMf2HZSG75zXDi5v1qRRi1at921fPHsr+hRS9PJG /dq1nF09We9w2QmnW7SdxyZ2A+CVXks8Ozi1Sf/tr5WI7tm1Y7169QI7dEEfWSj1590/c3V1datV 59vvte9K6yaMatqkcfOWfiNCt71++Yej5gpwNTN5sjbg5aUN9OpFi5GpDXrLFvrgQRSAh8OGac/a 2GgDMCad8SEO08CUumur5Abzf8I4T7x1i1658oNU4W/ACvC7veadnjaGy/P5SAXCfGCwQv+/CllO goV7Y/Kd3zZaC3lOC06dW97r4xUL88Goue/AmP8Boa3L5Knz3/1QR8ydfXgJlt5/CXgGxmCMGDwD YzBGDBZgDMaIwQKMwRgxn1iAKYoqzHyhBkD8PNKxzvsV0/4RhOZNCkHVCk0T//ATAqWuufrtJPF2 7cmti4b2/GbRRywM5m/xyQT44Ia5HA6Hx+M5efp0/PkaT6AoSot7/2X/BIGJaa8lUdWbZxW4XAG3 3Y/vT1fB/IEthA4NKo6IlStWfohS/W+0buAiqPfF285mlJbG3P7zTWc0oaGrPlypMO/hk/z6fHQt 0olt1meaRqPkA2Dde5csOaLaC5OV/MFd5imLM9Sad++bMIBUlqcVVLggVCIngM9l77zgI0KUFxRI XlMpqWDR5C8cDF0ualGgfaOJNaYW/zU+wQycH3du0Kw9fX889+TUb3y+sFwqLojUOZsFJKkuLpYY XKBWxMTEiGXa9fCIviFLzj5RSYvGjx9/45mB92qFSknpLQJdvJC6AkWoPDw8CQDuntk/eeoi0nDJ Kze8pALaw909rURBqJUlEt1WWUoiQftyU+JjwsOPsFFCKycBv7INSwtzswoq7Q1ICpldtaT6zPGI BymoUlyByIvRvjhxYO+1+8h70+nTp3ft2q+iQFp65RZ8SHLyqze0HalJS0nTO6bEYqR6lZYYFx5+ uEralEStJRN5SZFuM3RhRTPSFHUnOjohpbIBeSIbRysDlRKFyuAdhHUcI5WKpUpt/JG9u27FJjG1 iNy9O5zd1UxT6g0/znGwteIIqjpPw1Q/1TseTB37xC8gNrXgXc5yvB2BlVOdKpHsDDyudVO2VA71 WX+idP/uOrdHwLFlDxjj7yGq16CdLjKDUcYPHdxbF1O3bWfmUtSzU5S0Soa8+wTW8dSetmnB5vx9 v0ofgs3adzcojcbA8oOpmTdB0zd2TAaWLg4VkQsPxcFJCwbOxaMtx5rySkmw92zE5EJ52AmatQvW xcNGGeon8m+PVBTtDZ/C+atoRNh0I4u9f8yeVeA1PbuRX3bQpb+fh/bvoiKZOzpWRE7eeV+/RWFM IqO0aw5Al5HzYWBrT1sA0Mbpu8jBsg4rdgnR0Jk/adFRpuDEF371dKd79UemEeAMXKdJc4+KyKGz kF60pWEt7qWWbAvV+gHv2hOV9q0TOqaaqFYBJlR+fjHw37oTpW9LQpahzbpXsqouuVgBBsD8r9Ti nCtIDQ1GXtuJ9FGO3UX6rp+7g1rtkUfskKauMHLYXLTf2AaAkzF50ZG/AsD/k/FFVppwmb2W1qAJ Dd6GUErZLvWiSJl8Yy97NmLNBDijPGRcpRXGHAFVBjKSMaZTu3V+ubI0EynrXX1ZfGM9Ut/rPWEh PO9tCRbsfcB63H3CaPMOaWwjMLMp05CSDKSwfjSxDAkwoz93OyFXkv2cFciODiB4zvGK2yBtpoQK Zdpu9eyBSLsB2wsApxad9EtUkHADJl68Eyk5dGnhJrJEm5nZInUbNZOi6WY24NtNt/QfBjy1NVZM ljFfFryQp0X4f/d5e9ihbcR05B75asQWGM5kdvN7iMCC8Hsw0L8RjHMulKHY6+uGsI0DBZhpxVpi pWbclwGe/l0qboSUq15UaA17A9A4YAgb3rpp79u6Aaa6qOYZOGzssz59n4qVbzVJkHF5S1VpYWAF eO4ZpCxCK5+waVrCfuw9l00AJzLPocj+SysXKHoebKQzAGGRj3sA4N5oARvz8ORKOKUwmSA/gNIK f/PztkTBuLT7R1hB8gegdbc17CXXt30LMzAsDur9R+6ksQdIcs48RdJi0oyNSYy5I4fTFiFmBBjJ KgyEXkxnzwYIQfCsSFaAF6xHylJwTrt09SEqPADBc0/pbgOvii7VKseXJiERnXYkofQpsiJ0NUuu X6A9k/0qFHHo5OuHAF9EsAIsaKCNjIuWGb6Mw/VryNIrK3vXsrBFqw+4SIB/Lz7NybqxCzZR4l9X WCM1X34zk03vBKAA/0VTSFfpxIMMNnIJMoOFZJURYB5b1v2oIT0eAAAWVklEQVRThrk0qxxfYIq/ xNpaBNlqZ+Ueoxco/snXAcz/RjW/A8/7vcmpyKbWwrf6iOa85j46NzNNF17Vq5EuDF83oRx/NmsE e1ivOXwZRlNWXh4YPOb7yus1AC5eeyzQGsq4cPWWqYM9eyfAqIRrpOgry+yxPfVvWgTXeN/2YcMR Vx7ZNGwA3kDly7FYwhhGddKuoH38AkVc7S0cTU1gyWCgf7B2lW5qCzg2WjNrtu7MCpfD69oJGWri coF/S4N7xedoFwg2DTrA14ANQxp1GTQPgIBO7gbKui+ew4WA1psp35wPuBWWDey1tqW8WwaYGT7M 0b4gee+pNZez9129BQ8Ls5BBr8BGroVFEmBJN2z92WeTVqjUxInda9n0MMeGtd1IZsHSso62pitv gIbjRmlv5d2qQpEf5OeV6N8rKU9rOPZ2iURcnL99zfwLe3+xDpr0plbFVCcf+yOWe/sB8K9vl4Hw r7Q4o76bo5tnHdhl5AWllYn4SM1arAawy59Zrf2+ZeviqUrYDwOwDzk005rOgOGCjIy6ziBy4Xh4 SIiTF22MEgorLUTIKsxTMArksNuj/6QEcLUFx1ag9bmmMG7r0WhLqypvcwjWDmFuwln4t4dv7bfV qEAJpRdNZmOGrEFXFTy6ngd+HNPlzakpEPMo+c2nADichz4IxSZmb43aX+VUhy/hQBbFmoUY23+i uanve59cyOgpOekbijV035ZoZAnoClu+pQUPeNTxAuXlaXL63NZFJgJeeswfdXyZoYEGiWm5PFPU FLuvPIJ/7xxYBW9Yp64XqleZrGLMALaOQrqw4E33JE5eibG2c5ow+5fYTSPUD3a+r4yY/zcff9I/ 97v+D6fm+24nwcjLy3tol74M8MTJp8WxUWhyaNSyrYsDa2JGqCapemZg8jbty55vXbt+c0ILn93V ZdfE28vdh1noMg6+4TuwnLE2yH4QkuWhyJdideqlY7pLfGq5tOkz1LCMBiYsLK17kOx61cvgvZQm dUtoOmr7NF16b79uzGm0hA47+Vj/ihZoCV1pbQ8m3vVcrJ+AycD29UYjlGIBr7JIqeVodYqK5B7w tnYueXkNpmw6dg8MT+zsamcH1t0pYk91b8N8o3LQTrN9Jy2FkY5oCR2D6jJtVMV9TOFLSuhN9Gow 2NemYZs+7OX59w/r9xwYPpCIPgQUxezTb7f6gVVtbmGqnU/zOzBFaOLjk4vFBp+yckvKdeF5k4an lyGhE2cnL1s6e2s4eoPt07ufhqLPR+xIKdJ+3Twwf+rWI/eYHMnnCfFlctXisSE+zecZ3Iskfllb YWOBVPTq0UPCWLejSM3T+HiFhvimd6vew7fQBiAB3nju7rVLF+49fslG5cSd/m7J2ndUKifp/vSF C3/ZXCmfE0cNepxe9o5L5vTto28Xg5AjU8yrI6Pflv6HsaNG9ZtQXPHFCBZpwrwV78i/R7duMsYa Rln6406d++ufkuSmrF+381DESdZcRhVIpeR5fDzJ2pTMQUZh5eXissrP4kSfPqN0B1P79NGdKclN njttfL9+/c/ee/qOgmGqi3+ZRQ606m099/T7ExpeMmbzbcNI9iNWSnUW7W9waTPa3yL/mGaF34ki Dy2k86Wq9yfFfCL+DfrAbi5OHL7QRMCX5OeVKpRwNnivwxhXZyeeiamAzyvJzirTEARN8wzOkxwO HwrwV4FvcDvw4TDhcDQ+8+jEsI9506poJI5u3iIzMx6Hk5uezrNzlRXnvP8qzCeCt2zZsk9dhv8v bRpYqSkTW3vHLn2/PnHmrKXw/Q6fmniIaI7Q1t6p15BvIs+cMRMYyi/gXozYNfzbGW42ojdf/2G4 ffbE1fvHrQVv/Yb/MeCZmHEpoanI0dl99LQFZ/7Y90lLg3kP/4YZGIP5z4L1gTEYIwYLMAZjxPwX BXhwh/aSv6dVv2jioFzFBy7Np4AiK3/oJtRG6dgaw1KTBZjgcAw+oKwbwBm0/sHbUr+D1cvnaL3J 23rBN/6jt24r/p4An95x7PqLkredJVXSqWMH8zkcR1ePaaFb35bsY0PJRw3oDetqXbvxsl/Ws3FJ Z37XNaaqMJbHF6QzDoqI0icCoQnbNqO+XfGpioz5n6nBAkzJqkRoyoBMYaChqlC9f/bYvHjAvGW/ rt9z5f7hDf+0uq51QWqG5I2nSGUp39TyToosMTM7MnyTI6dGWMpRlKZweOYvysjUjOwTm38iFFqn XvsOoV2N8Yy/tWu7tsG/yyOQWhjfAu1apWk66dapE3uX+QQZWOSAE7VK83YrO5iawCf+Hfod6LkX ZekLQM9Q5LVIXJjRtrZe+SkyfOWMwODgTYfOVtlVVPIiGqa5l1l1u2IuszdBKZMsnD5hQegWomLv RHkm2rrgFjJAhn5Opj+rDU6noP1h2ye5g1pf62fyYO98VrdWnwUjhuWVwwup8QPYvZnUoLFIm4qi yCXjhwYHBx86r91lRZGaxWMGB3fsEnXvGTy8sqp3qz7f3Pvz+Iz580vlVb0WqRWSpbOmTF8SRpCo oE+vhL+UE7cOb4ZFvZliULWonVPe+ExbAFC3HhizByl7fdUOtZ1129VM1ul66dHO0BSmZfLSn7gz 3h1Zx0uYGksNFmDGH6/+MRTgeacTSTHa2+xZd3hqdjabYKC9tdDc5trli57WYMSMffqX9LAQWlpP pg1hBViW9wL10OYdbQHwCmLtB0h4ACzZcWr2mD4AIAVaH4AEeMd3SDf96rMc/UwU+Y9hpImZpYur q6dnZ1ar11Ik2HnxufgZcgD/QkmXJ4QD4ATj7SwEALS+FIU2YP94Dm3wchfwa/t2u3DiEIy5mFBw ZF4PZjgSIt+hwMSwGVA1rW3tTPjA1BoZHvh9itZIwOj2fr2HGTgizotHOokicytYqpaBOpVdVOWh gzoCk0E0o4C2ZNFskSVymavJv69r5NKXF2H4lYoufnkcBj4ftPRB1G5z+yqKlpiaxacU4GG9Y1kD APDf2ouv7xlWVRFgeLg2Oqv08QEYGDDoq9gUZAqDkCTBHktqFKO/QhY29l14qXcF0vIrem1nIows Junl/VzNLfvCQ1Ku9X/dpb6FX7+l+imhOLVq3RKePfNXxuvlJzXqJ3FxZw7sqVfLjtXEaG9tMev3 qJ8nfg6A5dSjyT91bthm+MKcuBNAZKuRFn7RGTmqflykUOdeBsBZWpTRPRj5MU0vVVxe1QvUC2Gz tUAGNyp3L84a2MmtIatEgd4XFIyjbZFFT1its2HTp4adqFosQvHwYWzEod114QpZaK0maUk8Gjgy H58CyPrnH6hNEq4CrikBBT56LxwvQjp08LJHW1m6jFsHM0iKnA3Dg78emlrwro3cmJpATZ6BkaTd l2g1xSlVHjwsUaCVbeSO3/p+jry8frn4UOmzSBdGVbDX4FHFVXftGgwBFKGWE9psYbogADY9ZC2H aKd6OH/eSjawJQIFWGTjjCxr+Q54b1HjZfTJGY3rjN7oBMCpiN+sfJd5O4u2//ki5vhqAOA0D74a PVHO7PrPPDPbkVmgDp/2PXt5etRaUEur6tTADhyOrvTy3qeNx9erL+nuomIE+OstT97ffIy9gTyJ aka3AIt63QkpUgBs4+ocNHoxpUJaE4VSddYV9D7s7YwKE/LVWLV2sKO2LF7QNcQfRi45lfD+G2E+ HTVagGe3sRWaWagI9GL703e9eOaOsINlJj0rU6C3xNL7awAIUuehRaCEEWxSo/R1dNbPwQoA8x7f q9SqxNjrMFkD/+l0hRgs7Gpp0WoGzDAuciMw9YbxlmYmq0+gd1RCrYiLS2NTwndCtbSYxwVz117Q yxjJfGGZ1hxOTNR2dm5UJR+FIu9iEVSQdM3CUgC4QELRyTf3AIGVgnnPVssllk7esng47wElY7BC VVZgLmjOCHAIQZBl+Wnw1JOiytfgif2DfQK/gIH8hEh2oHmbABPieHh3qVYKqcu/fw+4PKmG8nUH gydupSu23J1+mM+Gw/6Ml6VeAgCZNyl6cVOEtqDaiZVEQsx9NdPmm5cMcfUc9/9/jpgPR40WYJoy +BE2n4nr0qqWLiZoxk4YM72rXiIfA5VdRfFL3Rm/kO/YSMCoBytLUnWn9jDW5DSZV/Vvx6ZMZjQX 088uq7Ke7+GjnxZsvpigy3z2lmtaq1qgvy5SR/1WgTDGU9+qXd8f06PWVlZq/DrDVijSndodhXSn Z7x9BgaGRGejIcYFrjXOoxfvdR2BrhbzG8PgEGX6FVaAWeCCvr5/e/0cxu1//k8eGOZjYwR7ocsl JQolYefoyOdqf8nMz0rPLRI7uXq6OduyMfKy0iJxuY2do5XFG9QPZDKZSGTGrbg8OzvP3R32akCp 5clpGdb27i72WoscakVZYlKKtaOblztcCANJaYm1rdZmTW5+sauzgTFJeM/svGK+iWndOp68isyj b1xvG9KRC8Czy+fdgj6zE2nNg0iKC8RSpYOzq7mpgI0pLcovV6gdnVzh1Jdxfp3Xt6fEcZEUl29r bVGl/KRakfgq3crO1cMZmckrzHrBdfC2N33tN7GsLFBUBGbOBBMnlrx8ZadSAj8/EBHxLCSkqVgM Hj8Ghw+Cb8YCHx8QHEyuWEFNnChITNRQtKBuHXDwIPjpJ3DqFEhLAxs3gvHjQdu2pW6etiePgsNV DdZiag5GIMD/BZAATzhDGy4BMJj3UoM3cvyX4MDnYPp+LUgMpgp4BsZgjBg8A2MwRgwWYAzGiMEC jMEYMViAMRgjBgswBmPEYAHGYIwYLMAYjBGDBRiDMWKwAGMwRgwWYAzGiMECjMEYMViAMRgjBgsw BmPEYAHGYIwYLMAYjBGDBRiDMWKwAGMwRgwWYAzGiMECjMEYMViAMRgjBgswBmPEYAHGYIwYLMAY jBGDBRiDMWKwAGMwRgwWYAzGiMECjMEYMViAMRgjBgswBmPEYAHGYIwYLMAYjBGDBRiDMWKqU4BP HsljA2kp0oxMOUGhMKEiCRIQMtXi2cl/PpLrEsefy5g9OzlXTLKH928VJqYqYWDzurQ5c5JPXCxh 42mKLlWgjJRyTZXbSVNy04qIaiz/R4bSECkp0pw8FV0unTcteeyYxF+25cU9KUtPl2XlKVQKYsf2 NNhEcS+VbHplvuR5pqpKJqtDs9hA5Mb0Qg1ITVH8jRuTj59K7t4sUhJa3+4FKaXPSsnXE969kBfL PJRrJ7J2HihAUWpVaGiKDLU6feFsbrnmP+odvoxpgmWzkmA75JVTbOTiCSmvp1SXlL3KQ11XKVUf PpJLVXeDVacAr9icq0Llo48fSJkyO3nzjqRVM56NnPp83qzHj6ILcx3JyEVJ91JlbOLflhb2Gygc 2OWRkiSD/GOvPizcvzpp+i9p4ZGlA4aY8qWlMhXqUoqS0pPXUmFg39L4+PQiSttWQKMk0q4Wv8os ZQ8pivy8W1xavvz1UtVYSjLk61ckr9n+8ubDLGE94ocf7Ns3V9++mjVySOLRQ6n7dyXvP1s2dJhp VnIO+9DTL+asXhzv3+FRlgyoZKhPaAj6XGyxuEQNw7kpitzCknPn08oL5WjQpN56X0JJXD6dOefn 7IfP0uHYCpOqZOrk5MwqyTYuSrrzqnT2oOdPzr06cEOiSimc/Vuaf+Cztm04IR0frRoWV6Yp6xb4 kKj2LlmzkWdKgjo+3LAmIfx2enyctDCn/HwUkttyOXXhoVhl2OyUUhXYLTnuaT4M9uz/3IQu7zQ5 vnrLU81LaD4H/uF8942Ll7fJ9Ek+8ZmaFw+JIsLM3NKUkpCxhZSlaeWcuTGsRAU4SdHFjkGiuVMb ha6vn5VSRsioOdMLNt+mzIU8mEaWWU4ClGn6K0KZWtamzcPgdrG3T2cNGv183DYVT0O0CX7YNSg2 5ky6uJxavvjl+iXxAwfE+fs/rPndyqGe1ecdzXsNsWntZnE+XD5gYMa2O5ypMxrbm3G+mVh/SG93 Za5m2uSCVKmIU3HJyJlel/Z4fNX/cVDIkwK5Oqj3E2k6MW9hon/f5+i0Rn32unpOz4QeA592H/tc dyOFgpDKKidYvplwwnBPvgu/pRlvze7knfOeviyAAx8NG02eV9ax9yM22dRQHzdaqLblHtsoGTvV bcK37snnS80CRZ271KlPko4thatWSDU09z8mv6AkTa6S0ldukHXsnNDhi7IkGc/fP3bOjKfAkrti /KOBX8b599Q2PtdUuH+S0MaWD4On9vus/LV8wkCT6i1PdQowh+lo5eUEoICFnUCjIYd+3/BedNOO zuSS3TnDRpudPOPVxNVal/6njU7dWnLic8pEdjw+l7NlUUaDFkITa+7N274X19Vn05i7W11/oIIL 6UvZHAsXi88XWfXwE527X7xqjec33uD5sYJvFzoE2IF63bzsrLlLwupeP68oU3H277Wpxnp9ODgU cBaY0IAzc6n9rVtN9s2uBSPNzTkKAk2qZg2Ft+/5TRvkyiaWFCMhtPG0UaspOKaZ8rl2HjxzT/72 bU0FuUoVCbMBlkJuLADrN3tJxLqBkh458tnkKc9KldrZwb93QkkR4e0rgA/M1NQEdgEzHhwrOQPb mXbolTznZ3s22Z4fXkRLVX8caNCmFS89m34RI7PyEcjvqmmKSiY5xyOUJ097OlrRJQr1R22yT026 jHf/r1aRR2rPGBkPB6/8TKKgDDY1d8u25vBs1GNSQXN2hYl06TUcmuYhoe3cKyH8gP3gTt7VWx5+ NeZFy6l2/rFCO56iBHW1cvnLe6elXA5wqs2b3k/EBSauLg6ViQEY9mXuZwNE3XrUenQqHo5h9dsJ Nw2ve/14EkcvTzMnW/HN1LYBD+evtrE35UaFSoAV9+QO1y/7oXVL2DyX+ZOy4HjRIbuEHT/mL3aY Hlo0ck757dOkqQmvGmtX7aRcyf5+YznYWL5hk+2GUPG2sBLvEY57JnrwTLkCmqmNGOg3hcCcu2hy Gk3Qi3+141ySdA58LGohVGQQrVvHLd1kHR9BAC5HQ6IJ0dHeHGSSahqYMAuio0db6t/3s1rqodPS 1u6zM6vneuBrNN9u7I3SLVhf51ivF+193Nhk1jacR2cVY84l7TzZcGyfBDHNOXa01gU6u02buAVh 1mavqAFfZgrr8i14+mX895PyoGTGkkzYyuu22WycK7ay47rzBYFdOW3bPARWvEWjLX4Jly7eIju2 mRbyOJRCNXarGphmdLxlC6+dOaPExFt+alPjamwyOD5U2xqIIgkNQQpMTGCmHK52bicIgsvjcTkw TjtF6yBJksfTyhhJwP6H0hFqFd9EWCVnjUbNF5gUvyra9LR0ce+6fHgVDWdlwIHDA5wRaPSti89H yzl0I4o5wzWCjkVRFJdpKFKj1pAULLTQpHKJpVQoTEUi/fSERk2QtKkpah/YevDNX8AXUDTNZsI+ Sg5sARgmYbO/dXRWKhV8EziFw4dCUdp2BLvnJILOpuN61Xl3UWGAbVyKJOFj5hlDO1cvsJ9TNIfP R50QoI5NwzaHjwO2DwzAh8L0vo/ULNUpwB8cms4vLHJ2cvzU5fh3QipVMpKyMhe9PymmxmBUAozB YAzBGzkwGCMGCzAGY8RgAcZgjBgswBiMEYMFGIMxYrAAYzBGDBZgDMaIwQKMwRgxWIAxGCMGCzAG Y8T8H8eEUJ/9iftMAAAAAElFTkSuQmCC --Apple-Mail-102--974640808 Content-Disposition: inline; filename="Picture 7.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 7.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAUAAAADuCAIAAADHk0nXAAAABGdBTUEAANkDQtZPoQAADzZpQ0NQ Q29sb3IgTENEAAB4nJWXCTxUX/vAz52VwVhCQgwhighZy0627HtFzDC2YYxdtkREEbIUiVIqWdpR IUIlLbaSImuRJEt2896hfr/f/30/7+f9/M/nM/d+73Oe8zznnufMee4DACfBlUr1RQAAKH5BNKv9 OgQHRycCtgegARtgAoqAzZUYSNW2sDAF/7X96gYQ494hw7BFOVbfGv36gvAlyiiCR0b3yH8ft97w NNghAJA0zNzkDdZisNsG2zA4NIgaBLMng4meriSYI2GWptlY6cJ8jWGHvMFVDHbb4GcMDiGSGWPf A4Dh8iN5+QGAnYBZg+QeSIS7GX5JpEAiBeYzACB0KBR/2D5HJyyXJFJp8FiOFZjFGOuyMWX3AADU dgPAnP23zBueawUNAP7Fv2XbWQDgDQWg/B96M1brawXxvg70UJBfF0GsOgCg++j0GQl4bhkArKbT 6cuX6PTVywAgPwJQ70sMpoX8Xi8IagPgfz1vvPPvhoQdMgIsAmhgAopD7EFCyFW0GMYb+4rZhQXN 2o1/ytHA9ZF7erPCFpJAydZxwk5RmliJxIAU+041mf2ySru3KmAVJ5XaVW6rndrrqCGiOapdoGul t2pwwVDZ6IWJo2mnma15g6W81TnrZVtHuxoHvKOLU+XB2cOKzjSXq0f63DiJBqRA9wseDeRRL5y3 lI+BrzMlxO+0fyG1IqCO9iZwIOhnCAjFhwmFy0UoHd1ydDKyISo7OiDGMFY0dvXYh7iHxwviYxO8 TlgnaibJnhRJ5k1hO4U+RT+9mrqWRk+HMpCZmLOYs8tZg9nNOaW5GedCz7vlWeZrXJApELrIUYgq XCiauPT5cldxy5Waq5UlF66dvh55w7fU/qZWmWQ5e/laJbiFvc1yB3+X7R7rfZYH2Af0qtnqsZq+ h28ePXlcWXuxLrk+9IlHg22j3tM9TeLNfC1szxDPFp6PvahvTXpp2oZve/3qzGvzN/g3z9/Gt2u2 L3ZUdHp0be3q6E55p/Nu4X1Zj9sHvg+ve0983Pdx9lNln3s/a/+5z2KfywZUB5oHbQaHhoKHscO5 I9Ij9aPWo6Nfwr+yfr04Jj/2dNx6fOhb0AR6IvO7yPeKSfXJph9WPz5PeU/N/IyYRkyfmuGdKZyV nC2fk5+790v216V5tnmP+doFlgX9heiFqoWfi6TFvqXOlai1FDqdsYNBJISAziC0kNzINfQ2zCFs NbM6rp01BU/kMOZS49bhdeKL4i8SbBGaFBHaZiJO2h4vdXZnoIzYrmdyAfL8Cg17vJTxKjfUdNQ/ 7KNorGgl6bDppuijDSL3fzGyM75nyn3Az6zRgtfS2+q29bztPrsQ+wqHIadNB/UOUQ7nOTe6jLpi 3MSIuiQX9zCPVPIVz0der70HfGYoTH5C/vJU44BDtJDAM0FFwUkh7qF7wzaHzYV3RNw6mh5JjbKL VosRikXFThzrjqs/XhqfnRB3wi/RKcnwpHKyeApXCv3Ut9NdqXVpl88kpvtmWGUqnxXOwmXNZPfl vMi9f674fHpeTL7vBccC/YvyhcJFuKJZeDe0Fd+9knc1vsTzmtN1jxtHS5Nuni8rLi+reFzZdOvl 7Vd33t7tvvf+fs+Dnqre6vc1PQ/7Hg08Hq39UTf3BDSwNQo83dEk27y1ebHl9bPi5xEvLFulXoKX 3W03Xx1/7fRG9i3y7bv20o6YTusu8a7Z7rp3p9879Uj0TH2o6o37aPgJ++l+H6mfs7/+s/+A8EDb YMSQ1NC74eMju0a6R6O+iH15/tVvjHOsctxy/Oe31IkdE83fXb8vT6b/kPzRMOUwNfEzZppr+tqM xkz7rNvsz7ljvzh+FcyLzecv8C0ULu5e7FxKXyavEFfj1/LoBLoDPY3esh5/HmAMzkEQFADNIVKR e1EA1YvuwPQyAWZpXChLC5s4Ppl9iTOAa4Tbkad1swpfMT9OgCxYK8QibEHIFenftl3MW/y6xJCk gJT5juidpdLtMr9keeXkd5vI2ymQFal7QpUilSNVIlTD1Wjqnnvd95E0PDQ9tFy0nXSsdE31tPUV DET2cxgCw0mjHuNGk3LT3AOxZh7m5hYqlmJWeKtF62GbN7a1dsX2EQ7GjjyOg063DsYeMj8seHjc ucbl5BE7V3HXWbcGYjrpiLu0+6JHMznd08VL2mvBu9HntK8dRYDS5XfCX86/hxoXIBHQRgsO5A+s C3IPZg6uCLENWQotCjMKmw7PizCMmDt6OdI6ChNVE02JEYvpjc06Zh3HHvfyeHK8XgJIqD1xNFE5 cSap4iQleUfyl5TiU26nhU73pualOZ0RONObnpfhnCmSOXz2WpZPtmIOIudt7sVz/ue18jbljeQ/ uJBS4HZRtZCzcLyo6VLR5bhi0hX9q9tLmEu+X+u4XnOjCN5lQWXO5UYVypXbbrHfBren7wzd7bnX dr/xwYOqu9WlNVceFj7Ke5xbm1OXWX/6SXJDYuOJp7FN4c3BLdRnHs89XkS0Zr4sabv/qub1kzdP 3ta3P+/o6vzUNfOO/71xz/EPzz4qfCrvNx5AD44OL31xG2f/Ljv1ZS5j+Qoj/hu5j9EwSgBkGQBg 9xoAq+sApJvBqY4D3iBwrrZgA8BGFSA+SgLEtTkABSr8lT/4gDw4ADxANMgG5aAZfAKzECskCqlB FpAnFAPlQOVQM9QPLSA4EJIIHcQhRAjiDKIU0YwYRNCRAkgVpC0yCJmJvIPsQM6geFDKKCdUFOoy 6jlqGi2I3o8ORF9Ev0QvYiQx9phETBVmDCuItcCewD7GzjJJM3kwXWLqYxZkPsicz9yP24bzwlXi Fll0WTJYBljlWBNYP7DJsZ1kG8Zr4wvxa+xH2Js5ZDjOcgJOKucAlw1X2ya9TXXce7mredR56nj3 87ZvPrz5G1/UFs4t1/l1+fsEogRFBJu2+gpxCT0SJhN4CE0iQaLiooPbmsVuixdJJG8PlyRL2e/Q 2yknTZBhkfm1a0D2hdyd3fnyxxUoirZ71JVElXHKsyp9qq1qteote3v3TWpCWlu0pXRUdQ/ouejT DBL25xqWGzUZfzJZPrDFbI+5s0WCZaXVBxtOW0O7BPunDqOO9IOEQ9qHPZ2zXOqPTLlJEEmkYvcR 8k7PEK8mH15ff0qTPz81KKA1UCIoNvhdqFzYyfCho7SobdGDsVfi/OLVT/Akzp3sSmk+XZVWkX41 syirJKfs3K28qguNFxuL+oszSg7e4LvZURF7W/Fu/4NzNTaPuev6Gx41nXkW3Up9dfRtcGf6u4cf PvUhB4yGS76e+J49F7youPRu+ftKz+rVtaL184MX7AYm6/HPAZXgGfgMFiBOSArShhzhMyUZugw9 hrqhKQQOIYbQQDgiguDo30Q8R4wiUUhRpBbSBRmDLEDWIwdRKNR2lDHKH5WNqkf9QAujLdHx6Afo bxgCxg5zCvMUs4JVwgZgy7ETTDuYvJlKmSaZdzOHMD/GoXHmuDzcVxYlliSWXtZdrCdY+9lU2bLZ 5vC2+Cp2fvZj7N847DgaOBU5S7gEubI2cWxK4WblTuHB82TxCvGWblbd/IzvIN/UlpP82/hrBQ4J rAkWbdXfOiaUKqws3EdIEVEU6RdN2eYspikuKYGXmN3eJ9kidXdH/s4k6RAZ4i5LWS052d2i8twK zIqQ4vyeH0rjyl9VxlQn1Wb3ovfxaezU1NJy0PbROaZ7Xu+W/kuDEUPISNhY08TVNOnATbNuC5Sl gtUR6xybdjsW+wMOYY7xTpkHSw/VHv7ovHKE11XN7QgxlfTYfZws6Gnllezd4AtRNPxC/e9Qp2iS gWQ4L/aEcoWZhCdE9Ee6Rc3HpB3bHlcX75CwmJh3Uj154FRq6t607+mFmfZZW7JHcsvPR+fbFsgX 4ovWiiWvulzLuNFUBlXo3Dp+58192aqMh4jH4fXYhrNNSi19LzLaXN4Ita90jb5/2lvWVz3QPNz/ Ne1bz2T+1JfpztnAuYX5u+vxFwfmIAwUghb4K5ILUoIOQbHQFagV+ongQ2giyIg0RDViGMmB1ED6 Ii8gX6EQ8D/cD3UNNYQWRRPRV9BfMTKYQMxDLBprhS3CTjPpM+UxzTAfYC7FseD8cJ0se1lusgqw prFh2GLZ1vCx7Aj2ZI7NHJc4ZTirufZzfdwUwM3CfYVHn+crb/pm9c2jfDlbTPgh/hqBEEFlwYWt D4WihPUILIRukYuiPtvMxPaJK0rs2C4quVVKcMfWnULS22V27VKTNZJz3E2VT1K4qti4Z1gZp6Ko SlTLU5/f56XxWYukPaJL04cMsg2ljZpNXEyXzNIsJC0fWZvYfLbzt19zTDjIdajQWcWl1ZXoRicV eWiRh7ySfRR8B/1SqKoBI4G5wfohc2HXIg5HoqKKY4xjJ+My4hUTPiYePymW3HzKJ5UtrSzdMGPg bHS2UM7Dc7bnf+anFuy82FDkemm5OOuqUkn7dXIp+ua5coWK1ltetxfuZt2XfvC0+nDN7KOUWsm6 50/Ijdinxc3mLYvPC1pN2xCvLrwReFvQsaOzrpv8nqmnutfnE76v/LP9wMQQZXh41PpL9Rj3uMW3 4xNl35sn3/7onGr+eW/6zIzvrPTst7mCX4a/pueTFgQXKhZlF28siS0VLCOWPZZfrOxaSVx5uyqw 6r5asbq0dmCtmi5Bz2DEf6NeWm84XX9ffxrBVFfvfxR3/99G8Q3+44ML/rH6uZmZ/+av1CALm/VT CIClwBBrffgO5yyIw8PLwOg3E0iueiYwC8IsF+Gpa8awAbOpB83AamMs5ODtamwBMx5mP3c/W+sN +1Ak1Xe9xmVwKjVIx2o94wGo0D1Q/49OVYSnjf3vsS9owVa261/VcG3p429i9dvXCsld7/fcEEx+ vmamG34RfF5BRuu1LMy7gAFwhasxMnAHMsAU6AK931cCLCfA5A/3uoNAWG94Xe+Plt36s9e/jZKB T2WGvZD1MT5gFGaKi1ccDbb1f60TYcvBwBfWCwY0uVK5MbmVv3QYXn3XPf+RmPyH5I+dv3W9AAm+ /9P+upzhnXLbIyTXP1zNzhMlgZJH7UHpoPahNFCqgIDiRfEDGZQiSgWljdJEqcN9qq8mHkz85Wdj fdz+ek+TP3OGr37/sWbEf8wGbNTv6985cAzy4xnUmLUQ++97Lcg9bL1G1vWnhtO8yJ5BBG0q1ddd mmDkR9wlTZCXk1MF/wKDW3gdwfXxVwAAAAlwSFlzAAALEwAACxMBAJqcGAAAACJ0RVh0U29mdHdh cmUAUXVpY2tUaW1lIDcuNiAoTWFjIE9TIFgpAD5Cch0AAAAHdElNRQfZBR0SCAk90aLHAAAgAElE QVR4nOydBXgTSRuAJ65tU29TV0px2qLFXQ8ODnd3dziBHzjcD3d3d3evU3dvakkbT3Z3/t0kTYVy x3HcQWDfp892ZnbmG8l8Yzs7S4EQAhISEtOE+qUTQEJC8umQCkxCYsKQCkxCYsKQCkxCYsKQCkxC YsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQ CkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsKQCkxCYsJQvuZjZTEMAgqF SgFauaZpq6jmY102j7f70on6d8GzTMUzXAUIlSrI4XxTrW1ugnjrkcJerbkLfxOVKCtVwskLXIb3 sXu/GEje56tT4FKRdMzk9JJShM6kFhdoIYv54nEdaV5p2+6J+Hjh9v2aVubsL5AsVN2+fYy5v8X5 Pzz/vUgkSeL2A1LYlsynd+pUdJ/eP/xZMjrwN/fZ3a3/vdirkBcr7jc+1buf6/4pNv+G/J+ahKQi H7zr3tH87EqffyNePWuGRV1NQ45crOtmRfv3YvkPoH/pBFRi1cLYs3cUZTaUuCg0WTkiBzNLnQvU aJQAfAEFTr2SKZFiklfi9GyRm5P9vxTLpt/S8KtKrInJkvg7C4zuuPbi1+sHsqZ2s2b+V/3Si7OZ CgWMPJhRPJxrZcb97PK97UBqDmHo+RPbz5vuJKQyaCA/D0tJ1N66oxnfi4p93AQPapGmwRFedayP 7XX/+NhPx2jw68k7yXP6+dJMuav/ihR47dTwsy+ImurkSx8xiC2K0ew9TZQyiqL4QFrvR4uiXyRt Hr28h7yLs29Axce4/14sV+MMwpNTCo0KjEqK9IaSdDRPVOrqYP7vJaAivRbWei6J6TuS+y+N0Vw8 aCAH7bbYfGJLG0tLCzq1XFvHTZTLVdqPnDCoSxEEBfHhRaJiS3sri4+M/cYJz9V7svsE0b+u8eff 52tR4CcnU0/ptHfQFH7v1ixnFzdGd8qb52GpclCxAjFoX2zAM2OJH54UY1Py+dEqjca7MWiXFoCu i+rW2uwyZ4iqJAB8rAJjEFI/nFq8VCl/mhcKnbZ2fR286P+lDNPKxhLmAgG98nyXzeWxP7rLZ/IM mq5QqIHVx4ay9bFct8byY31XBSbFyQqloEmQ2adK+Gx8HesiMvnMdcX4/8ZDeb1asj3c3Rm6Yc2+ iw2OHLCxtXeo4l0l06Smyqrti/F6eeJQ6u6DGXmSShOsvoEhgYGhqK4pGNU/PDAwpNuYhGrTgmkx tboa2RoVZtTe9WNicAnJcsK8Z2U0bm7eMfJDmVOpPmrYkPu0wGh+dkGtVBnSv+pheUYUsBpJSql6 /+6UA8ezZGh5S5f1MrlRUOiF50QSERVCFFfloUNQUGhg1xi9OT1dXiSuZj6qVkOjYg0lCjBEqvM1 ezRRgG0HxFafE0hk+bP0bH9ezpvmvesxKGrzHxl66+rlOfhPPHmq4WeVFCpzSwx5jnudP3xg5A8j 4srTiFWfwOd3c7dtSzl3Ja/a+znx4kBdRRowJGHKxIRnKXn/PI//kK+iB543JhG/MljUWT2Y7h6u FW85ObvgV61W90tY0nJjS36cmaIpu/vjGJdFE4zr0nBA78ikTENF3L2tgEqnXHrc0JFJWNN0HuIS EscNLVXrhInCpZ0Gxt064af3rxKV/NAvuUhe/ru1GWi3eraLvoW7vjTmlyvKVoNt1s90w62xaiKW w+cTXu2UFqoJD+pibZMW4S+f1DcGXz897uSzcnEUKmXrft8mtfkfKoQrN8t7YFCkVWtUZhw+1CBK NSFD6EjJyYVPsqC/R8UuEevSJqJAaqimf2wQsczot+7W49PAjqV4Xw32b0lcNa28+bDzN7t+2Jcw ITqdKFb16BiWW1ym2Qzq3RcNjDPvVQNCziaBrcfcmtYgFrH0yvrqbeLS6aVKncTSJEX7vjF3z/ob UzNz+Lsn0WqjlWNOP3a8pqsDs9r8ZiQQUnxsq3YhWjXKYBnGWcZyfrFTWlxWzs1ahz9/SJTz0fuE 07EEQ3V4+5YQ+OqFNCw2s0FNl/adYwCVcmKd/dA5eYghi9oxm1P2TvfEyy2oURh+99GzejyGIa77 2xLnHSwtS4X496XZjm68K+cM1UMcJ+oyJKtKI/folbS5Z9Xe5T/my/fAmFx+P4ko+h2HLOyErn8y 6gNqbOzMIv3PJTQjvJ0/lFUs15cq7Nw8VK+9fQZx5s7k2nMBhsB5W+K1us5AqPM0fDChve7+jNlT Obi1KFEukshwQ8rr3OBuSbj2OvvTx0zgThjNYdLBgxP5Q2fF6zUwXDc7RaUKvTJ4Molf/dpmnfYy KTPn8HArokQTUwy9wbiBESd02tu1N3viRG7PDgy8yZ8yIv5VquRDmXuVRKzeNejD0VvzZSpAPGsp 0CWA0qYBEePVyyqsrGtQlaoCA8N02ksZPoY7bTyXQQVqKXL6ZjJ+l68rxdwkQntpdODkRNjzY6Sr T+kG5FRdw41Avfa6e1AJ6VqsS8swY8/zLklX5NISvYN+8X3BFEJ7bVzo8+cQY1xJmjK7QAx0HVrb lqGE9jIo/QZzxo7lNqtNVZYiP3aPKi6p0DBVoFRBCN61rrRP93Bdt2b4a9o8PLBjFAIrlXOxrpxn zSXKWSNDk9KycMO25Q4D+rO7dDaMxX/8iT10KGfYcK4FS2uIA4MDZxHa6x/E6N+NaEfC78plSi1A dB4gzM3O13vMiSnQa2+LzuzZM3kD+7Jwmbnp8lPPcvQejNrbdxBn937B2GCiAPPzPs9A45/w5Xvg M7o5nsCJbkGjmbGrT49apStxBVHbmnVmzxjF4ZuZ9+ySjmihtEhkxXNaNTIG1yUam3LisIDN4Ts6 2t3cEyLC+/YfGbopNEVaJsqtMWvNHL7Q2WX91nDcml1Uam/O7TeJ+J0GzjLr05yNj9h5bGZTXuzw LQoM0UpUqCWbpm/BGVxD4yIp++FoDOrxoxbWdo7Zj+JPv0HjFYg3ABHnM0ITERqdcuSogM/nO9jb 4q3S5TshuH95SRGe12rzGJFORDKoJzvsHFHjw2NL/Z1sVugSFjyE28iOeuy6VPxKjWAYTaduo9tG 41e2Ne3wDnO+uaWdjWDv3lC8mJrXJBplVw8KyCcSOX2pebA/k2/Gv79dtPay8tbpwln9nBhUhj5S 3yDm8rk8DpfLpNM6dc7QKrC4lFx/L0f8lj7LxqUlcVk6HeswN//Cd3R23bszokgGM8RyJ1vLozMj cIU0s6Pt26ZPjCUYD/GhJu6/pFhkZeH+fn5f6CQqs7D39dvdh5KXW+wstDKWM5NLPXLQwsZemPUw Di/nRLnWC4AmnZ2adBIiWvXtm9F4O9VnoKW3swNe1FXm9vuPCARmbFYp69S1dLzDghAjRvlAP7k3 +Ow5jGh5Jywx79CQ4+ziLMmUXbwUj2u6TKZ7JoLpRgKAcuq0gMc3d7CzabgJNHqVbGH75Z9Vf3kF vvuOGM417su1dXH7S8+WPowZo3meHu642Qqk5xONLNEpno0i+qt5Gy3YFg5Ca6JzkBE9K8BbbAad qINGBV47m+vm4W5cCqOgmqjbumaYRundlOnuZhjA37tJNBn2AipNV4Xf6WbFAmeqPmBx2YTyxDEL Bxc3LoPG0HUDNCI9YNU6YjY7ZYMFPqKwNzy1NgxjbfjV/+JYSbHe4Mal1aeDcASEvFUPbIe80tWf 3q0YAW62YINUo4FiBeJgTkPF0nid/02bzO0cXfgcBt4J6sfKDAqhnL7+DPBKE9SX27qhhYsjMcvo /4vF2ssRpeloTp7EzdHQiCyfy/f09NCb2zpk3M8DMUUKfy/Cqp9KchmGOm5U4M0/81zcPRgUw4IA BcMLCtv8jIh7+RpzG6Grub4VhrohL4Xy58t+g8ew69VkCO3pTCaglEN1cLSqWM5HD1YqZ6puZZMQ TKHQ6YbGCKAYjVp1RLnlhKW9nYO9BReVKwXmlD4TiQGORkzUFiqNQmcSv45WbKgdbevSrczsRnYK idH9Ghw+tY2PTqB+wAJg/35iNl+676iZrzOrQWOvP8nXf8aXV+CSIuJH6hBA439EWtYv4wtdK+m5 bjXCMDdpYMPQay+OsV2vWH3azjTnW9lVWch+9YhQ4C5zzW0dhEbH28VEjazdmMmr8ODVw9UQVFVC 3LXzZVCoNC6j6sJ4km6U39yBWqa9AJUbBnV8evUPsQ/OIoYhDAc6XpGXrzbrPlv6+Ib6VV3DAM/F gs62IibPEIGFBRIHc/u4N3J95qy4HEJ7dRj6TAYxVnRpxAcH8PoPLayM2zAMtRBTy42jABqTZUyD V036/TwkOgfrDYHx0Sir8nPnoEE8joU1o7JKKkSGwnbkMc3LxlCqNELlBS40Cu3PFpQ7tubU9HWn vNdtGoSUlTOVxni/nA1QqXQa+MA6IcWBBnDtJXLK49y5W7e4WMrnsrRyIsE0Gj6AIlKbFEIUpv8P 3KnjJCKJoSUdv9CsbQO6nZO+Qae1c2bcyyJ+RJUMGdzrHZNDu36/voBRbaT/KV9egfXT8Mzq5oYq BcLmVkwhRcDjsSs/d1eVy6Gy2OXq4WsP8kRGm6EhH9mIZmVRaRkJnyChuvlWQzcKm2X8QaBUTASp 4UGtWGuMtUSuWzfqPoxr51JpyU1WvoKDq3Z50Nxk/e4UCpNXfW0+kUgofVB9BsfMyrYV3mGGQzm6 ZkMu7lh7EM/MGldCqjk+b8Sn6/nS2l72VP2jNTpNYFP2LIRCxRVZWzb707db+aLq5mhQW40jXka6 3OHtIYJBWlkhl4U3/B/clmFjWelZKzE0MZQulW1e/ojr6s4S/GpnTeVY/tnTGnx+Tn2v2zRSXs7O zpXc1dV4LtFWOyEt/xUoVLq1TaXE0HVzbIauQUq4pND3A9Pm8oODGGaW1jYCC2OrsvpiXUlBwdtQ cXS45sgZtUaJdu4Y/vxB/S++hvTFEwBq+RFad3BFaUVHRI0Mbhca3DJi/cHciu5MZvmSpr57y1KV 7dghNk6XZ0foSfw2GlAJfDRNr9zQS+QYg0uEehiFGtfPMt+I5LrabMWuVD5GldQ/zantRuWVV3Si 9sRmYZjhqTWkUMqrzsLpqcQ/SxqbWU2jjWkQsU7BgzuzrMxZRG+hizZD16jN6sq04BNqP7gt0Zat 367SYBAf3emKCa3YcTHZhLniSqlKCbVqg7qqC3V9S+XmD6vwcOnyYyJoU/dKWS7zbdANAZ/CqFxl RBKMYihTjEkvv7f9EdGtca1ofM6fdhJ/ugpkLGdu5XKOz8EqbA6g6FsASnXP2D4GVDfTxjM/eS7/ 9GnLrh3sPT09bS0J7Q0LK6+WAlvb9p18p8+v/eiBF/7TIlI0OfvLP0b68gr863piDlYiQpt3iMoR aUQ5ypO7U5s0j4jXLX8KBFJVeR2rVPncPYnEhyThikvVtaHwQXRZf4xhObrav/Z6hWaZTqFSyiuT vitMSEBadyCeBDzbLpXqmuDC9NLeE7PLQlQatmVkVHqWasMqT4+DNyHv8h4FrsENrAn3DWf0o1yw aUFcrG6SxTKjVrsRRSY2JLue0NDh+7oZ9JzCoPCYgKmrvo07E1NZeaxaKle61ddvIYDxOYawqBrR 6HT3aUz5qpCyBCuSIBgGZEWqzt2IRsS7IT5HLt9+kJSOaBGIp3n7gjhi4k4BXuYUZgUlx2fdFZPK qjAiMdO1bqEvNBxbw8r5tWdEPiEKBwWHluoSw+ZT2B8Y+eqdtR+hdO+X841Dysoa/NdC3sc4nqrR 3NAtsywFuOraWBHzCwxBhw2IGDs28XhI4S8jw2evzTauz7OZfP3EA9Foqgr9z/kKhtBs7obptrM2 F6jFmp7doozO+K+ydZfA3pKF15OsLGI7IT6hoVTQYVdvDoiRPzylnN8ddgvkXHyj3DRftNWqSADQ omJDYUcclCnGaHlsw1MTSCnvAAf4gv0JQCLBXAbYcliZSjVs3yrCEDXF0NQz6ZU7zLLfkMWhAAUs 0pRXnLq+fGKlLA9VabV/HPJo1j3l2Qlp4IkQ/V0Gi6JVQ2tvGo1WTYFr5AYlZNAMM9Jlk816zCE6 TPsGLJaZ4UmjT118gEosSoenSdrVEboxKekaOGVAkpMvU5ylUZRtIT9xtHRYR4NZnqwd9GP57gW8 uV45l+fiXP5GxMJZeMEWGa1NhvPpLLPqFp0MOVXD8vT39aOtLUDlxVADKdd22HSbWLj1lxz8T3+X SQd4g2Lt+sGtc62dwb0sMHJIyfK1BXgDUCpDioq0ihLt9Rul8zbVbKkbl32onDERqkIQBk3/60BU N8hQVT+E/jPUCg2w4AAWa8MU7qxtig2LsvC/ih7wStjEomRDFAqi8hqdqtzfUgELfHm+fA+M03Ko 6+UTLhVdpi00O3nS0sfT3sOdmPzwbYlOY8hgNoPJMfrp0YqYcSEFiAqFS3b4twkgqgpajOi1t88Y w2wzLKGgwkiwvMls2oGoIlnFUIvCx08aDOpYVtPYlB37Bfqpt3F8unQqUem7BBiqL5tnWIE1SnNy 1/+amBbBmA6W9695G2/V78TevJR4gOnnR6t2RRbVPyRzYrA4hirh2Npdb9gwhyO0MWSZZWPIUUoC scJ+5rFh00h2gkF7Z/9GlFJRjCYvz7hmXAEWdd8BAcfc+kMaNXGJ2axuLA9nW711wVAzKp1izq2c 4grz56DWRAEWSvEZALQPcjt3oPwdj0HT+BNaEWXl6fnBra9j5ul/cWzJ3IzZczOWLs3Ztq1g/xFJ XiG2fHmiVKeNHypnFMMjrTAa0vmy4nzsMx2mDbGuVbtt+YpJyxE1D262qKIMTbqyDh2x5Apsz+wS gvfYtlfANf/orZv/Gl/R64R4Q1osFqs0WhqVzuPzzPiVVpvUClmRROYodKj4K4U+zzB3QJzdPPQr W5KiwpRUMaRRLC2oZgIrK3OzKzeS69ZieHp64KOdxLQsvrmli4NhvIRn/PLFxBq16e6ehuByaam4 pJRCoZrzzdu2i8en1Beuurg4GCq0SinXohQzvkGL4uNSWBymu1v54sr9G+kCd9TdRWjFZ+vko8VF hUqVlsniJDyTzFguGb7YfEwPbw69mnr26EaSvRdV6OJqXjZjxLTalIxMvIoIbcufGysKZPvOZHbp zPLy9NRLKcjNTc+SMVhUMz7F0saWA2nPo3K83XnMPFX3CcU2Aaw9v9rg82AMYjQG29ramss2LCIE BhKjg9NnrNlMulqD4HNpC4GlpaDSRmuptJRKZ/M4RBAMReOT0nlm5q7C8rcLr15K8qhJ9fD04Ooy hWjUxeJijRblcPm/Ts94Gatduc+yY70PvoBZkJ5/9kphcipSLCaeBuLthaUVxVFIb9SC5VfTzZZH r7ac715Ps/bAcBdLriEvKonySXS2r7tZxRfF0mILU4rE7q4CT1fb96OGECstlfLNzGkVHuUiGpVI lF8q1dIZFBqNYmYhEAgsGDRCr9VKeXqqKEeE4ONuRwc6m021tbU343Pel/wf8xUp8NdDXmxB96EZ bG/muW0u9jbV77v4WwwPDsGn579vs2jT2Ls6/f07QN0pB3/1TkXe21RCgRuyjq3zsTavZqynV+Az 5+w93Jzfv/vPads4pBQFx09b+3q6/7lPrVajUhE7zHCoVCqDwcSh0b6KseHXz1cwB/4KqPiWkVaJ 4NqLG0b2Y7E4vE+TBipM1kOvZBGLaxTgZkf9p9oLdJuqPz4l/zi2j42o8rtNF1dE4dpLY9OY9Oo3 QlcE11gG46+9kVQLqcBg38KIHXcQBpPCZBA7fOQKw+SqdX26gPcpj+obNwrBNQcfZVGpFBTBVLq3 EZqPNGOy/+spk5s77T/QYUWevGX3OCoNsFnERkatBtPoZrCTFvO/hlnitw2pwMA/wALcKdJqoFZj eLDA86TtWmFubVfN0sXH4MwHGVKgVJavsoyawe/cjOHq+BlG438TyGT9WRtE/RwjVZZAP0kGCkV5 lhf/bl7Pl20n+BLnH31PkHNgAlmJuFhcotJg+DCQhvckHJ6VtQ2b+cmHB2AFIlGJVIlh+p1GNHML C2vL/1p7nz1ItnOlOLt5VLtsJs4tic0scHEyc/kcJwRBTJuXK5LJiafGdDpehnQLgaXA4su/7/7N QyowCYkJQ671kZCYMKQCk5CYMKQCk5CYMKQCk5CYMKQCk5CYMKQCk5CYMKQCk5CYMKQCk5CYMKQC k5CYMKQCk5CYMKQCk5CYMKQCk5CYMKQCk5CYMKQCk5CYMF+pAv/aiEKhMzkcDsX3p2nTpk2aNOvw mYuK1Gu+Qe0Uqr93GG/8+d+ZbI4agJ8Gz/xznxpMTgu9CABGCdmt/8NDvc5/gxteKmV6PxCivNA9 +sPTXxS83F1q/EYAXBl3yPh5idcFL2khuzcWGj75K1eJWidF58tTcVEb8lL1ji8yb47LrvRV4XWL hlT/Jb+/Cd3Sp4rLybGCvLIDBlaMHIzpDnD7k/dIL6wcRaPTD7zIqOLesIYTjUrJVSNQqzBnUigU fxQCcUYU/ms1/GmJzgukUKn8DjsrBII2vL8+BUihqv57EX+OVq36a0/fNvCr5OScVjIVojeXluTZ Ow/Mzs4ueHtk86VXnf2Bs9sYo09Uq0FQrGLYShYIG9d0QHWGoiIJhIhSQ9xPjIwIuXIMqexzRvxt RsR13GAWdjisOCUbr+IQhkvzUQz1Ctut9/M04xYnZDceML4wrGnCU2PYQmna7ITTckOScuvG3sAN A8P2ZWuJ6Ja+24dAdH5yKIKh4O0efbbcI85MyIqqmIDV8/tWKQeVXP5+4SDY+24GlEo1fm0j8Kni fnighQyDqK4gSouL8Ou+ie2TSzT6u4+vnMyVIecu39VbUUlo15Er8ILsCihyLVZcSqRBnBP/eEnw qbcpqEbJcA8K4jHypRp5wZtuY+YABx9c8LOdUw89TytNejpuf3TlyDEbbvsq6VEoVJVypC5o0Hwh UuX3gFCNoBWtElHa0bP3yu2odu3kzloMDyZPFJV8sFC+ab7SHjglLiG4SQMnB/t5a26Y8dk0Kk8o FPJtrbNzwI1oeH2JzcWwTL3PwsQ7dPfgn0d3+eNhMt4jbN5/3Lzj7619ba5du0AXuJ1YtTQmNu/Y kSMQK63TYA4AqJ+N9dif6p+NyDa3r/qlwI2+HeqzLPAeWIppGSzBr4kXUhBYg0mlhe515wfp/TR3 6UjXfVVgePrraFk8LWSfFCN6Nmu+WxMKoj9yVlSaN9+xBW742doyTa1Sq3POUj1pgLrKs0GfmFPT 7YMh1LJDT8bU+aHypyaAqqgY71QsKJQj+zb0n7vj0LJB+6++njN5utEDnsFfthwyCxg5oonLpcsX cWvyvR0teoz7ZXSnAohac1ghr++duhVOkyTW6D7ZUVDp0NMlK7avmztk091Uayd3VVFymrT4xOkL xfkpFPce5g7cPLHSwtJwgEbW84dzfp6Kx7ZkUx+pQtuzTf2ZcyfXm39i5/KnPzT0oDLYTdNyEs0c bPkMrk1gVHxM05Zz8WrUbOS01Ih3s+YsAxkPTr7OrBAz1KpZ936d2mrE4mYORAk5m3FC3j7edfKJ nx3j7J27FN+hV67fy8u7eONmTI+mHmt2HBA4dnxxdgml8bD6fs7G4ZaLveBuREZcfOxv3WpcuHTR 1oySFR+WUCg/c+kKitFY4JOPTzFxvnQLUj2/tjLTGvsZVCJ0m4j/z322c8/jLNygyX+4417c4smT p06dJhZFP86WQUXsuEWnHOq20YfA89Wj3/ACqRY317DR5REpErrNwf//5OcJvBvjhsira9RolWjV vdJCiAh1lgPJl98otVkqBW72CdtT5gfjvN2F//MPOYFfJbKIKLVSf2Nh+C69oVQaOziN6IWGRezL 0mKdIvbpejrMOWR3uproITNkSRPSHo1LvesZdaagQhrm9w1AZNk2Q07hZr9ec+xtgvTuV3ZsmjJl 6p4HiQyOmTGD7XoOyCnRjmhaG+8fT2wepyjOXHgxXH83iOOMX+v6ORfG3p4yZcqvK1fjPbAU76gU 6W0Hbaax+fjdWyu6P8ySQ1QzY9oUNz43V4Fu3ndKH1wcemzZgZe44YeaVJkW275wGAA8vBR+rg0y JHj6tRzXRjS2FS5PW5LQdfgcrwY9cM8xZ2cff5KWcG/n0bgqnSHCA+27t62H+7+6E/8dkZlHHhHF Ic9w6bQVNzQatQEvee9AvF3DrLmWRLx+ns/OLNQHfnTqIJ73pecj3tw4NqB7m/6rj+B5b9nlp/js EryC7PzfUN0QBXkdn/PByvRN85Uq8Lofbdds3Lzif79demz43Ane+6TfWVejXufVy2YDYKMqq/dS UbT+fqRIaVe7td5xYFO3Zp1/YLA40KjAWrHQb/pAodm1mOzo61sCgn9+fmC5svJgtHbYbvB2V4ha bfN219DoU86RRIV2Dd3TPuKgX/RtRJ0zKyt6b8we3M+qwuzlSWdGJz+lvt2twGCzyIvJxRG4O3i7 f37s6VIM+kccDAg7XDv6OqrJHpxO6BWGIcy3u2xD95mHGNsC9fisSPzfpEHD9fZ5ferhddERVxcz 3s4TkcuHeXXuO4wKLIwppJcp8OwuvrVb98Bzffh/gxsF96QD9saXmSwmvV/XxrPWnKPZ1MD9TKzj U6Q1BDwwxAI4egOmeZYC6luB2//r/iBT/vDoXFC/OYcJ4sXaX8bNNUbkYW9Vu3btJu3mxx0ds3DH aVVhgrmTL940cZg0oQXYfS8l5dl+3ejBIkOGrh9Rm16vsZWTL16aRgVW5r58mqrTZAzhcgc92zVN 6CrkmxNNEo/DGtCr1aDp2+0AfewgYkSDF4VXAK7AsGtwLf9adt0mLH12ZkHFnwbTSOlU0LSebZ+Z y9cPrOMT3J3HBC/TSncuHyoj7iPnn6R9QjX7BjD5M7Fk+TFhWrcWTh88wG8LVxkAACAASURBVDn8 XWL92lUXdb4ekJJUrzmv0/f0/9IJKad3794XL178h0JaBPrcfZNAHvf8b2P6ClwQE4q6t3T4s69I k5B8q5i8ApOQfM98pavQJCQkHwOpwCQkJgypwCQkJozJKTAEYkW5TV4K0nIq3U1KquQ9NQ78y6Tk Sf7a03sc/9/kv/QjV+r2CaIqjUajxEE+IR6SbxzTUmAI7KngeorBFnEKBPUFm5aAxZd1dgxQzMHj R4BZtr9pz2TgWfMvha4Z17Fa9//NGlWgBcmvL8Z/cPM1bO1LGbjh3sck/dpv3bIlxo3T4MT6w2iZ +fWRuUXySjuBMVkyxd5nyawxzp0WvtrYffSMhStXrHgYmf0xEZF8V5iWAlPAo9uAW/bBu9m/gpjb YNN+sKEvYQ25CI4/A6NGg03DQXIp4TL2j6oC1FEtunXz9a2XK0fqc7g/tKzbYtxyicIcV8U/Fo/h uPsXypGZ/YNGd2lMcR6kyC+ip9zzbtzbj0VZO2/IrdBcvDesaes8vZa5zKB8lPvv5OaVP9PerL4X RGWNOiwQJV1LlKtnDeni4OD6OKWkpFhpY8G6c2Zvyw7ttp+46gAoP08Z3Kh933eXdzQets6GzwxN k3q1G6oXQuV7QVHiT51b21Ht05NFRw8duHB4n+pr3fdK8iX5whtJ/i7XV8MUhcHcpobuHwaZNOL/ 63PwUjJhmN8e5uj250AUVsmgNu33o0+hMi2o5RpA52ggXDh7YxPgWpjybNT2lxAWzVp9eXIjKu7R r+PPbesRGxJzoq5vDCvGDTQAXu5b/cMfYRVfl1DLs5bdfFcxhtFNa9/fP5lmW3dNV4ok8tCGs3cd 6IwzMZK+gCFXpw75bSeEiL1XrTEWZrfj8hZN6oYHib61LFpUSuQEK5fcoYGw929HcEPcrcNqXdLr tOn6uUqR5JvB1Bp1ljkoKjKY2wWDvU9A+HXQfi1hDWgHpg0BEAXr7gMH3cYsqJs1ouUfrQV0m9j0 hOinl1lBPgwGnQHAynUz9Hfi09IzX17nMS0AsMOtsbeWGSLkWOgN17aMajJ63cVJ9Q8MtcxVGLpg jRYTFxVWTOCEES06jru/pa9g5Wshna4Nj03O1miOTCK6VgqKMBmU8IubLXgdLmFI2xr2AEPxaS7P 3MaQOk5rvQHNf+I3dOvCrjVSciQX565WaeCDXYuFgcM/XzmSfCOY1ge+IcjAx8/PQWA/0GMGuLIX 7NgKbkJwdSaYMBT8cQRcXA1WrwLZUlAcBs7lgFoQHDgAcmSPziyXdv+5uy/xtk1pwrs7fK8n63qN LRqoF7ri4lZrj2bDnX7fcZu24pchB0oH6d0XrNyCXxl82wAzojnw8vPvt6o3bhh5pHzV6uyFe3Xx gTnWaoCn64U04u3ZwJErdjnGdffCkP5uvJrOPd12rfz99+UHD2jCr7M43v1qvorRmrGaOa+eVAPv 0of2nyRHAdeuJptNbDpEVY/0Ymm2AQ2drqo1mtfP3sx7+WDK9Kn2ng1urun3nxU0icnwpYcA/wVn j+0oM8rWn3j5aUL6BTupPnx325Ezfy0CyVv082892zW8m1HNW74kJJ/Ad7eVEp9mUql/fUDE+yAI Sqd/ry+dknytfHcKTELyLWFqi1gkJCQVIBWYhMSEMUEF1lTeGKWSAZm6gh2C4uJKHiAG0H99mqCU lX5CKHVJnhz9Cz+asvwiKIogiFKp/nP/JN8VpqbAHhTg4w0oZatQEbeBsz+oIQQRulPUIAKoNPBT E9DEsKUJ5DwFlnbAmg8S/1LBFA0nH3zfFVOKBFYtccOYKVs+FDLhwQmu2Ucd+oHkv+g37nejNS/8 9v0MmdE6uO/iKv5HNaR4+fgwaBRMnso3s/X29q5Zs+vHRETyvfCll8H/JmotROTl+6voVmWGn4jr 2W0wSbdPq18Hw8l0Wt2jn99HwAcZFcWYOdfq361bWJY45PTSZ4/OC+x9Uai6HpWJluY0a1YnUQ6R nHtPnl0VCASYWvL7/VQvgYDKYNVr26P30it48Ptbx7+7v2fptVS9NI1a1ZTqXlF+ypujORCOdnHC zX2mLCnJSxQIrPfei0QlCVdjCyCmnTNx6JKtF0Svz10Oe9e1ZTuVFquPR0Fn+jRs04/HkZed+KVQ EumvIaBoxZF0BofP54/adP3zliiJSWNqCnxwHRS6Q0VZBWd4Gwz2uhOVT2+A+iMi+7WHxtMe67jD DaeriOHZe0qVSmcB+9Gmwb8fu7djYmetInLX9SgBqCFTKbk2TvL4w5N2XDnz63hJdnTPrWF4EFCT iKIFoElUWg7wqCJQQBwWW05O2JUNL7Px4U1a+qtpay/ae9TZvnQy8O6WdW/7prvpQrZVqQbt2aR2 zMtznnWaipIfX4sWEVG4t6kiNiv0Ko1KeZdahJSm7DxPnNvs4iDQfGrhkXx7mNYQGoLN98HrR0Bc tntxABNkScHbM2Cq7n2GwEAwdCbxWtKtu4bJwdqe4PAt0DsQYJUF0Tg8JkOLEK6D+rSdsP0GnYqH oKBuQh6doh+hD+vQou9vO+mAolYR3ri6efQtcYKAzTj+4oFG9HrIIsPGKYhhKJtaccumvU+DNX0b J2e9GNBn2LQJHUX5ud0mroo/MESJUREtJhZY8hnUF9HvtLnxWy7f5fAEbzKIHJnpojg4mCLR6Cft 0Kv1yIzMdB5NpVWhDes0gKhGLJEx/pWyJTFJTEuBKcBCAfYcBT/rznB0bQwOvgH9O4LpW8Di/mDh IODQAtQSg6DGILQQFEeBztNB0+7gj63g3ClwP05ZmNp/d6hekKY4vVnz4LNReTSeI10/oaY7eLlZ X5rWql5A49cJ6RQal8ogCodhZvljE2fc4CMU4leOhQuLBno1cWPaNzq6spVe2vFlcwI8qPsfpSky r594mIi7UHlO5mYObk5NCkrpXnzOy4O//ti17dgjiXbetQK8rGLPbwhu3tzC3IpjZu1vy+aau0TE 5eOhPF1c8OuIY1BgeCOS0rRhrW1/HNq7fgbD1mtK/7a16gRG5Uv/yxIn+cr5jjZyJD3e7tp8IpNG 6IatT1BB4ptPEFKU8mBTvNv/unhWe/fCWMuee8R/uV3r7r3Htb0s3LruVse898IjCcnf4TtS4Iqk pqV7uLt9QkCtspTGNv+kvZjlFOTlaTHMwdGRSvlngki+e75TBSYh+TYwrTkwCQlJJUgFJiExYUgF JiExYUxNgWv5AAoDLLpksGZFE1YaBWSWnZJRwwm4McDosu2KRW8Bmwnsql80royq1dzj77tCVYHQ 4wfcsGXrpffv6ilOfMmlCD4m+Ujh22EzNhutCde3X0kp30q5dumBKv63TGhGpVDc/Btg0iSKgU9Z eyP5ZvnCG0n+LmoNzEsv30rpaldmGENc7xyBVxMIQ9fGZSfPIcTRdktGwQxFRTFDx8zavXVrhlie /vZKUkLo1JmLMKiNyirGlJLVq5eK1BCVxCUmRU6dNg3TKm7EFS6aPl3g0fC3tVt3XInAg8fdP5oZ eePwq1y9tJSoNy0E1hXlF6S9kkB4eME83LzzxEVlSf6MGTOfxmVhClFkrhRiyNlj+y/eDyO2UkZn bFm7QYtiy6ZP4wtrLFq2bnnXNqqyw+0ePSeiayDkILJEZ/c2ffr8eOBO5OcuUxITxtQUODsKtmoK x601WPm1DQZeR+J6egPUfxF3UFdo3HA4ZRQU8KBYXVEMg2eRXVRkyaI/2jS4/7Tffu/uoZZH7L4e 5Q2scsRFZnbO8vjD9Uct37FwcEH2u56bdVspfYmtlM6AqdCiNhW+2avHixdU0Zr+6sz2sEIGANmF cWN/OcSz8Ah7ehMIPLPubd10O70JnZ0p045oWjfy+TkLW4+U0LOGrZSuVbdSSvMSWQzaydtxmsLI 4bN+xl2ENmbIPyg/km8M01JgDL6MhliFw2I78aAKgaUpcOpewhp1Ea65TRiEZR7un4UIBh/th7fS Kwqy9GiIS/Ow5eEKnK4/6koVued6tF2j4bh8jrUQV+CXSXgnCmXZMW1XvcENVB9CgUtzib1cO65F qUWvJ+4ILUsXRvNoXfFj4UhJSs0GDcLf3R49uH1YoQzQGK8T8xUSUfrdnauvpVi6+OF+fOxA9LWN 19MUUtG7ZTejcReaC6HAJ0aBEo1BGJVrpVSrlCo1qlGUKjR42mzNWZ+5UElMGdNSYAhb1YR0Gowj TlGGDFeoKoQUCqHPKAYndYIyCH/wgzQKfJ0CC97ChoOgKg1SadChGe5dI81vu+apXox++nDsdfrt VYNT9AqszTj5POXwqD40Ou1uskweve9+ghh3VhalzDlHfP0dCHvr/KEcOiDUC0NVGkNfuLxvG1za nBNReCuw/5bhmGjAscYgpp+knF45kcligQZ98yPPnXxbGHJyA4NBc7a1CD2xKEKMaKX5NedfIoLY tiISopIb2wI8eKfOfbs0F2pQNaBSmXTwIqv43y5jEhPiO9rIEXd3rVOr2Wa6Hc6fvJWyJDt01HnV uanNqr17cjCl52GMS/uL/VUJianujjwL76HKvFufkAYSEiOmdS70P8Kv/Vyjefbk0Z8mRIsgxyc2 +dDdAcc+qjWMePrwnkolzrz+aWkgITHyHfXAJCTfHqb2HJiEhKQCpAKTkJgwpAKTkJgwJqjAKWHg ZW65des6sL7Ca/Hxz8GyZaCw8rEVK//3MYJjM4uqcYXo8/CMvwx7YN2aj4kCYKqEjPJYUh8eCy9C /sQ7qlXs2L49JEUENSW79+zZtWvXls3kGQAkFfjSz7H+Jho5ZPLgxjCD9ecB8FQofH0ULj9GWIsT oYs/YeAyy4OsGQm5nCpilIpKHyrTf5j3wrP4Kt4Id1S1ef99/LZ3rzkVPt8LMUSt1BoOzlsx+kcz ljv8GLTF1x7HGG3EVsoUmUEghM4tB+ExysUFxnhs7Z1FJVJfazrUilp0WltYWKjUYO8JJfl+MTUF 9gZQll2uwMCzzNCduJ7eAPWKOfQHw55KmA/rj4VDqm5RNLRerRbe2zRYZ2JrUPHO61HLh3fCLc5u q1TxJ/Ve1LKc1hvDHNiE2bdJczMb4qTYZvVck5Ne7HmaZxRY25gSHS9PbLiVjZix6TJME/DT9F+7 e9Jo/gD4qLIerbqVHnFxtV54zMtzekN4domfOWFwrNnoj0FAVUFJ8yLPA9BILXqN3z1146rptbkk /yYmNYQ+NAIkAeBVF8zsAIpUOqey49pru+v+UYFU96UDaYHuCTcEFDuQeR6ceQB6jK0oydorAM+8 X/IO3Fe0RJuXFkHXZDJo9CWPib66SLoFBZq7sQXFaUnaEolcospVEnuh41883Te8zvmod6kOQzy9 moxobm8U+M610ktCNYKa3njwxr9xwOtre0eNHr/6YaG9ZfbZJxcK42PVCm2LyfvwWIIDvPkMMGP7 jVJRdLZEFVtC7IXOiXk1/oCCVbYTZGQ939MxDBS+YtrUL1Fq+3Xu5uZkXfnLFCTfN1+4AfkE8B54 C/GODtx3Fh5cCIdMgu1qw6ex8N4VqCyEDCZcMwfWaQfVEniv7MUdfQ+MIa/TxHoHwLKYPm0q3aVN +V5oOXEutJeAt2HTKjvngca90NLsdx11HT6ndl+dDBWDCtKL1dqi6OnLH+ulHdm3mccXrrqTipvT CnXbPBG8ZaEptcRcXYUhgGt16tylH5p7hd/ctvZWujfLbP9uYs789sSiy0lSeWHi0F3P8EA8TyKd 56YFSNT6LhhhcngDB/br229gUcyNNkNnHt04CdTu9e8XMYnJYIIKjM8W9W8aHbhAXMX5UKz7XvaT m7qbGExNJQxqMbxZNtKWE/PM7JAzN5NL9A6Wng3y8wtwQ2F6VOWXe1QhkYTao/JsmRqteCMiPA6/ IkoxsK/7oZS9WNchIrNUb75xhviEwsVbL3SpQhNT0rWIUSBWXCyp42QBEd1AH0OScoiERYRE/Em2 MxMiHj1+8yceSL5DvtOdWJ+8Fzr+8Sap37hAO+4/iZ3P4WgxbPL2ixtGd/knckhIvlMFxgcegDzS lcT0+V4VmITkm8CkVqFJSEgqQyowCYkJQyowCYkJQyowCYkJQyowCYkJQyowCYkJQyowCYkJQyow CYkJQyowCYkJQyowCYkJYwIKHBMR9mkBS/PTPjlSrSxXg/2dAGjlk3EwFJSWVnIpKQFY5V2rWDWb WKOj0/5OrJ8LpKBUXWZEAIoCTYWXjlENkMorecfzYgTDCP94KHJP7pfg61Xg239MMjO3tG81vn/n kZ8mYfNwj7/l/+6K7mdCCvTmy4uaZEq1HxtyUVfg4g6YZW9HYGrA5oFedUDfdQaX8e1Aw58AiwFQ XS3PTwJcAXC0BideVhak7TViqDr52IkXSX8r5R9Ckf30aqz4L72p067sfxhnsJixgZcX8PE1WBEF sLADrX3AfMMRJaCFHwjuBvjWQK+wK6cCD0/g7Q0exH+WNE+cv/+zyPle+MKvM36A1JcngyYQx1YU FhW3dGq4f9WchTvu4NaTG+c3aNQfNzjP2lPf1fVxagmqUU0YN/bqK+KrolP6dezWYxgCYX78U3f3 Bp38zPXSji+Zsm7rxj4DfsHN/9t0uFNwwPHIgtBzm2t0+gl36TJsMn6tU8sv8uLmUhTKCtPc3X0G N7cUa+GuqcPqBhJ+gieun9Wj7aS1t7LC77g4C1vPPDKzZ83y5JboXjOuW/bZsTmjYJruFWVzHnHU FVIIgwYR1uxH8JDuhV6tinB/fgguOmWUsXnhmLZdRwcEL0REL/Jl6rTQW3hEfvVm4rfqu7nN3XIU QmxUp06/n3mrFb2cfuSCq4srUQ6TN+PlcDdJgiHquv41pi3bgTs+O7TUw9O7uDTFRWhrae+85mqa Poo3tw7XbhBUArFa7q06N6u14ORLqFV0cndfPHfIpTCRzgsGWTTo6AhduhqSVcsdFutev6bqvuSq yYDzdhGGJ3thsu4rTb8Mh87O0MEBiss/4DqyVo0WXfvghstbfq7RcwSRzrG/B7m6Xo8T723vdGzN KNcOY3HHpWN7d+jQV4VBWXaEm5vbydCsWu7uDJ6g7YAZcnGKm6uLwKrLJ1eh74SvVIFtmJZI2blQ LQG49y7d2d5i/8Q+26+EXt83Q6MbrZWoSnsMWsm3tEcxrI6L+Zb5g268eF5XCHJL1QG9ZkGINuQK 9RLOTB1++mXCm3PLwwuVwLW1vDBh4rI/fpi9oyT77f92Px4eYK0WZ1GazfutZWCeBgr9muL1uK+T 3fP9k7advNu4nleYROtiAQql8s6TNwMqfc3OU9n5kkrJLUyA1jx4O9pgnTIY6j9mqldgbS7svIqw 5j+Fp17pbqCwfQBcsM4oIPnCvOuhmYriuOYTTkb90S+lQOEJwPKtxxPTRLX5nEK5Ji8vb1EPYXxO yaTGDnlp9zwC2uYnPQqRGsqhdfcVPlb8p9ePWHCANPNFg3HrMAxRahBFxt3BG+7po8h9/Ef/nw+l vjzxQKS24YL4Yrlnq8Hd7O1UKLy7dFhIrlLnC4MTiWYO7pgDU3VtkJsQ6k88YNoSV3Ui3HyLMLw8 ANOKCMOJrVCqhlolbP2rPqKnh+bciMlTSESxNzbM3nwh+93VG3HEuKZQIQtosWhvT7D4yONJ/Vud 3TLzSkhkkBv9dZpE4NYID5iWQ5yXAuoOxa+tAJiyZENCSvY/q0ffPl/pEFqg0eRKFI+O7Jy79UyU Xf22tVypNFpMen739vVQrRqfbjadc9ycxSxVxPD4TamaoqjMhnnSkiuvcsKzkBcxmRQNkS+l1jAG dq7L8/BwlpYWUCBs1L4n19pnSW+PoA4dMK2SSqGs3LmbZeksureCRswoUIASI2E5xHJzMs7fvP88 LP7unqsAtLLmc29snZSWX9KrLnvlpWeLJ3VVGZPbuR2ITwH6Y+lw+gaCVfuARgbkcoALo9uBEN1Z sCOGgEb+hOHxYbD0JJgyAKgNKcyOf0uHdBRBtKJ8PACGwUciyQ91KO0W3ErTai25DK1KIxYVezia 491hQULivPUHqVR6gkgdNHkXXg4ydUJisUzErZeXl/7o0evhA34EgKJBMTqDDVBDogrTU/v80AHV IhKlRqFo72vJFRWIo2SAQQVquqJYqp8DQ+DbnPh/9SGw1R3k90tTcOkpKEgEQlvCyvQA+1cR3oaN BDa6/ArsAZ8JIh+AlrX0EUU9vNvM2wavWyWSwgbNGiFqBY0C6o9aZ81hKjWxNy6DRYNa4LHmlhYe vBLyKk2bkZTgGxSAB1RIFfiVpVt62B6f+fOErr4/rv3cNeub40u3INWjVZa0bB48eQHxIe/Ogybi 13U9OkhKshrWr9e+5YA++9/9uO4G7ti817jbOxc1a9HKqskMiJQ2a9IosHGTbLn62rY5AQGBLVt2 0Et7sWdSQJOmnXoSh1p1nL9f54Y1bxLYILCJvptv37Mffr2xapIcg7H3Dwc0CGjVKliKwP7NmgYF NX6TURocSIzbISrHY6hdt967nMo98MyRcM4vcPl8wuzlQlyn/gSDgqAagZk34erjMOkZbNQIbia+ IQqda8PU53D4cLhxI9x81ijjx3aNGzdtNmLiJtGbA4UybdPGgbXr1H+TrcyPvFi7Tq2+k36T5sTX q1t/5o674pirh1/nqcSZYw5G/7DiHB62UefB8oLYoMDAZsEt8L4/uGmjevUaJhfK1PlvFvzxoiwG tFFAg3btOzVsPDQ4cBRu7+HXSpqfEhgQ0HJQq/vxhtPCYNcO0N8frr+ID/2haw3CpV9n2LiJ7pY7 zJLBG3uIrF2MhFAKp+6GCS+gnx9s2b78t1OIG9arFdSkuRZijYMCGrUgbvX4+Qh+bdi618pGAUoU nvvfrBylPLhZ48BGjSOzxdtWzqpVu86CA0RS63WYh19bNG/i71/7UNm3Wkk+hKm/0I+ERqValtxd +lZ4cMYPH/L0cu9k4dA/XFn/ZcJISP4LTF2BYVJSMgoYvt5uf3JAjkKcQRe4MskjdEi+OUxdgUlI vmu+0kUsEhKSj4FUYBISE4ZUYBISE4ZUYBISE4ZUYBISE4ZUYBISE4ZUYBISE4ZUYBISE4ZUYBIS E4ZUYBISE+YrVWCNojQvMz3i3TuJVFXBGWrRT9n4mRAX/ZHBFCjxfh8CMRRiWszwJh5WebepGjEm qdINCCudwSND1BVvRqmIUGglP1BVFoWewrSEj0vmX5AaH1PFBWrkf7fgZDL5+44Q1ciVhuyrlQo1 Yki/tFRh9CMX51aMC5EXIp/0q5F8DF+pAv/W1cKx88QbVy9atu9LKSPm2iYmnTpi4e6/JWpxy6D5 2y5AgLAshX/u83jyee/YR3gtZYTupYfuZYbtQwDwCtlNC91Dibij91OiTGFHHNbXx1Yhe8KMR0dh CmroXuO5WB1DdgdGn6KEGJKaIo2/p4T+kQdxsZTwM3rH5u+OzMyNrZiA/TsXK/9W3j7Aj8G9qrjs H+EkL2srKBS6GgPP9i4srRqunEAKpV6LYJ6FoIo7lc7yc+X02P6sKOY6m8tjM+hv89VHlo8TunQw +tk0WKipoLGiyEMJxdW0BZXRDFl+9q/8VMOSCcM/IdQ3xRd+nfEDnFnQSYHXAj1IiaPrGPy/MuXK vkdZCWEPALBQIIabRamPNx0/PmDADNw8b/j4OSN/XH41XCtJr1+//p6rz3PfvfAUmv08/2cI0XFL T0N18uoTT3CzX6OOI93dFWilSHNUUu/oB3hHSgvZ4xt5rFb0dSJyDC1RScxDdun9yDVSs5DdeJ+8 KvXiZXGeouzYEATVnEk9rZeXL4kanR6LGy4lHI9WEmdz2IcQxwOJ1MSpF+At8UJyZNa15fnxE7Ki KiZg9XzijWWkIK5v38ZiLZ4QRd26dScvP2r0ML5p85UzR0zZcBiR5eMZXH2UOBzjyNr57buMJ4oi +mrduvXe5Urb2/qd3vbbr7tuGgMeHmixbM74H4ZMwc2LhwxNu7XG1dasZp16WRq4Y9l0L3eX65FF DbuNNJTD012rTr3GDYdGNiiWa9uNXY6bR/j7TbFlZ5QSx+t4M3z4PGsUzzumDuw5WpSdzLfohrsX JL2sX79lN39z42kqOFnP14lK1GhJVt++7bNUhMutXUvq1msvQWFx6tuG9etHZRbUq1ebw7NvFrwU KUru27dlgQamPj2SGnahXr16RjmRtw7XrOE9cfFJaUFa/foNTz2Pmz6smzmDUa9uMKqOO/IgGn6X fKUK/FtnwZChIxct+vnBqySISoR6BU6/vvRIGHG79M26a+HPHz68dulCfvzd8ZvOpzw/PHPzA8Bz KJAq2045ZOda79LeDeZCH0l2upsZUCqVECnSCxkf4G1n6ZharKouWqRz8hu8VvaJf4jXwCPJV14q tVpEsTrrmXvU5TI/GE+nzHXe7tuZHz0kcn+yRn98DtwSc0BvyCkK215IvB//MPlkiEIVVvB2Vk46 bo0riuKFHIpQyIpVWdS3u07mhraPv6WsEP3C/kGougiApkqpqOHgRaNqOxepYHxUdEpU2K0bN17H FwAqI7lQ3qrHbA8njyeXDuLt7/4JPXdeen1i0ziFWsqs3QNPXk6htD0Ahx5E1XS3VRWm3793+/L1 h7gCh2cU5767NWDFLQbHDI/r1opuDzPl8uxoYFM/NC5RotAak5F+fcOVd8RxORfntiiQaY6vn2nn 5HjgZVIfYopBeHBie5jZOulLzL/LcExVaN6UOB7Iv8043KUm27GC/sLXmwfiCiwANUpkJXZ+jSAs bD9iK6aR56aEWDceiUHZ4r14Q6P0DgjGx+cs0FAmLarRafizMwt/vfxmYpPaEW+f37p+PUOq5AJw 5saLxMw8a6eap3YsBy4tceEjGnylFfg/4ysdQkOlev+h/StWLGvdyAtDIIoVSMQleVGRQhc7/O71 jVv8XOwCmjbt2LUnR+DYqm0TBpuCqjUOnjVt+Ox7W4flZ0S4tBqYpcmmfgAAIABJREFU+PSUhdCV zQJstu50GMCS58cfToHmLCmbxdg5gCbRVJqbYRBhEO8MY31tvfH/N5SlQgZlVV7yPKdmVERkTBrR 6unmHuNt/efaOinKJsJiBEF0U1wHc6ct+a9wOd0l0hpsVofM2PWOrri1UVpYWq3eDlSKJUtYWm9E V2sPG6aAXTEBeKemVTl36M5mcTCIXcwUWLGAOYfpWqNWm3btg3xtGCy2pzX34eV1qdmpiEtLRVHC ndepP3YOxBCtWi4eOmU6PkCmUUGEle+w1rUZLBbN0im4RetuXVrhwl3tLTAEn3RT9Mll8cwABdDM HaDo9e6B7VNkGN+ljT4Zzs06bVi1G2CaXutfW7C0/9u4v6aduTWPN211wPWXcbK8WHptLzdNYY5M G35ifaOgnnjkFCcuPkkRWFrjCWCgSKU5sO5gI1q9IHM2Cy85ddq9yZN7UKh0qShv6Ox5FKBFIXHs EJ4YvGStgtvy2Gz9osNvPQK3v4jyrxvQtkMHZy49T6m1yL608VJMUVFO/Z5TMq/9ik8EmByeLhLl spOPP1vlMy2+dAtSPXd3jMW1jsvhLth41MnZ2c3d3d3HpyjsnLXAgsPhubqNMfqUiqLthM4urm64 2bNZT73js5NrhUJhvcZEI13DSpdHTN5k2L6NfWoT3aUmv3X3Pu9H2iX6pHvk8VQtHBN51C7swNLc FNxxTcJ5YcThMyUStTKpb8rz80nncD9HJUXxxeGWofs8o07jfixCD2VLEnB398gbXWKO5aLwUtZd p4jDN0sVSnn0ivwcnXgsIOr45LgrvaONx+ho5ufG4ON5rrWb3v6/Uc3x6wJ3Vzt7h1w5mvB0j62t rat7X2MK7YSuekPMw2NCR6Grm7u6JMnB3sHfrdmAg9FNAurY2zscf5rk16wz7uf39sFFZd3qlfm1 nJ2cXRoQ5eNbszZ+vb966ONsZWb4JQc7ovw0lYti28xhTk5OzzNV2Y93JOlGK841iXPnWjasgf8c GuLMI6mns5OLK3FkZ1d3gqxixcllwxwdhW5ufvgQuoGHrV7Uq629SjXo4RH97B0cosXEzCeoltDe URhVqHR1FgqdXOztA/CiCGiHDx/g6qaBeN7TpOjrC79WTI9WUeIkxDPqGFeofrBvqaNQ6NZjGu4+ Odjhz6rRd4DJv9Avy48J07q1cOJ9yAOKYjTaVzrQwEFlmftTzMfWtfjSCSmnd+/eFy9e/CcSxGLx olNPto/v8bmSRPIhTF6BUa1cCtkCJu1LJ4SE5Atg8gpMQvI98/WOLUlISP4SUoFJSEwYUoFJSEwY U1Pg8a3AiocGMyIGfAqg0EFK2Qf42jcCNWqADj8arNkhgPLXh0H/0r9hte5zRvXO0wCpKFny4bDn 1w4Q9t7+MQk/N6dJenH57uhGFnzjNuiC+EdKbdVvmbZtVItCoUw5/vrGvFr6naQjN32vjzpJPoyp KXCbIcCaYzAP7gnyEOJbnr42hDXzGfAbDuLjAT8L5OtUJfc91UMLz926e/Lkedx4fvv2xzfOXXgc 2mPyetxamBz2x9HTuOHJ3cth969sOvRw0ODxAmnamlVLf12xIfTlg2IVoWMnd+3dM2mYqmzhT+k5 hmHLrRjD6ROHAYBnL4WqFbkSLRr3+v7u3ftx/w36LXW2Ymlk4itXrhTINPUo1NTo15fvPCtMDF/x y+I169eLSjWTft5kkIJI9l95qRKnnF2w0cLeb/rchZOmztw4qcW/UKAkJs4Xfg79d3l7Hj4VGcxt ahgMHAZxfX0ORum+l3dgPIwrNtyqkkH5O8cm/SPuHgiedwlQqDfe5doGjmoIXJTFqVZOPkmPDi3Z 8GRyI3DkcaKNpV3beo54iOyoSxvfFENZkm2z/oXR9zwCplWUh6hKR+x5VtGlXZBPVugxnmfTq8s6 F0sSOs/adGbt0F7L7nQDDAWitnQIhhA1d6oxxsKs5biVo9r74UFCL/8SkVtaJaOh94+a2bmoIbw4 2/9CdBZU5AR1GP+Pi4/kW8PUeuCcRGBvZjC7ewEtABopULYnrN41wKJDhGHxWeBhqfNRdVwKuO5z Z82s27y16kUkg83rXMsh/80+JmDIJDl7H4Z4teym0OKjcYchLbwLikUA6J8tMwAdAJ5Xb2G6Ta12 KW83X5ghEJftwUSQUhdhpVd2pja3b9J3+oIg1uxVbxk5j2+eO9552sHzi1pyAAVoUuetWA3lGY7W P8ZA7P6uhQ6+XioAWDQ6XRfWNugngxRN0i8X00pFGUwAflgX0cvfCaBKBo35mQuT5BvgS7cgfwti ky0Euj16Vo2hRqazcqACgc1rQRWEE3pBc3O47wnMugPn/gGH+xMeLkUVhJ7e+ihLJ0Gmz3WxEqHp 9vTjdPWpjaEaLptBp4FSFTqmrmEPYIcmPvg1O/z66jdEf67IeNSq1xJCRH5G2ds2hgZCpIIrx7XT O2kLX7Wf8r/XJza5Dj+CJ9hXKLCy4M7ccmGaD0uNwaY1nby9vWuPPmxhxsFlnF4yKVEJo28ti8gh PhGempCqF4Iq4oCtbfcffrBxapnx4JiZhTUAwlJ15ZenSEj+jbeR2jYLq/AyCta0RVjl+2iCqMrG 23+dyUPbl719KNtw4uWnCVkwsHWiFPnQXZ92gz5ChkZUKL5+ePXEM7GflgYSkip8ziF0QYb8+s1i JZdGAeDOzaInr4g3xulUBn4NeyK+eVeMqtGrl3L3H8yPTlIXZcmvXi2SIf/FPrBth++U7bSk+3va fZoQG4+63vwPbthMuHvsI2QgO7ZtjtfW2N7X79PSQEJShc+nwFAzaa2oYwseh01d2zPczpd7aGmi mjgyhprzJO15Nox9kns7B3T/wYbhwvX3oAxZnO3vBrqNyvxsCfgoWJ0aeXxayNkrNv/j2Dm//vrr jFEf/I4xCcnfhf65BKkzi7v3sKXzWBQquCbGRGcKt19qSAMIANiT89IbOYqTh/yYVAqxMkQHmgJZ QaKcau/5aH/VQ1tISEg+ns/WA7NcHe7vSG7ZMlShhEfWOD29Vtg6ODQmD6Hw2H2WeUuSld07hJ+5 RwyqERSwHCzr2IBJw98Nnv8f98AkJN8UX/5tpPBwmbMzy8aG8WWTQUJiinz558AikaZz58gFC1KQ j1nQmjMAmJmBvVcNVmUpwIfs+MhcoTW4zO4JeFRw4pHBisoAhwIozkDz3jPhqqDz9z+sxhmR9hhB bJBKTMr5UEitrDDA08bCRohPGGo50vU7HxUA8llUvVn1oZAV2P3b9JIKaZw3vKPxpFZMU1KqrnQA LYDIryO64pJDUkVhJ+boY+G1W/0R8ZB8U3y2OTBOYGDIJ4Tq0IHYdHH3rhj/mzHDefBg+w/uXy58 BkoDgPQk4DDAEDVgU0FXf6B/GNt6AXi4CoTfAvxxQH4ZNPcBAxMJd7oZUKKALgI/DQcXjhglvXwe XqeuN5vLA4gaUmnFxRI7O9vlw1vi0qQyGY9vToUIgkGxpMTWxvrM3mnFYnHnKStfn1jJ4nD4bAai ViDyvFilbQMnYlfJk6tXXqUURj4/dClTzTW3fnXmhJrrxMWbFjr96c1rLAffigdfKWRSLp+vUKMc OoZRGKhaqdSg5hZmw+f9zqLi8aMKpYrD5dYxtwOoVqpUm/G5KU9O3NK2GNOu5uY1G+ctno0LkeXG D1x9cekBmk//1Y9m1Fl/9oUnvaBr9+6fUP4kJs2X74ErsmlTVvPmoSUlSPW337wGCycQhq39gFS3 2zms7JnQo+fENTEG/KarxF61gPHEZlzP6Y4gp9IpyE2bN3gVHcPjWT7bMaZecNelHezViphDt2Na mfND4mJthLUUSScZgf3XLh6cnxv707ZIeWlJSnyKSqWw4AtQCHzNLejmTj42hl3QbQeMPL10Ytsf f+3jwpJJ8u39G8oe7n8kQlBE61G/8dtN814Xlvefo+sL8qLu8diNt3ZrGRn3snnnlS8v/rbqVmy3 YF+Aiu2cakilUnMqccyy0Kfx3gkt5WpESWO8i07WoLD/EMNWLb6wloMylEelP9o9Ozvp7eXIxI5t mgh4Qf/4FyAxMT5nD/z2bcAnhLp1q/jOHcPrRHgPPGiQHZX6gS7YwxOcfAoWdgHLjoP/t3cecFEc XQCfvcIBR5Xe0YhKEwsKotLEihoLxi72JPYSS/zUoMYSS2LvRsWKokYUUEEFFbuCgvTeD47juH63 7du9O5qJJQQ0xP3/+B2zuzNvZmf3zc7Mvn0TfJrcY/5GeUACRir11swI3CoEA21B8kNQZ3dIdMz5 6cCuc0NJxu3d/T162rUhO+3R8TG2LADkyRDEfO083reHh0zBJ5I9vnzco52+uDStSiC3sbMHDLaV hXluwsG+QwP7b4sEktIrKRqTvawICRFrZhU7fsMvP0CE33AwGoB4bS3KZIhQTr5nt7RvI5EjtYaZ wHNk4IoJ87qwCw9laHq9vp6VeqLK7NIP/TrGYlDVm0crT903Nze1+XZCteJ6TuZLzp0NEgxysLds U2Csq0mfuzYk9OTvhBBxwWOXmafFyvkLyym74wBE9LPp6Ds7+RT/Vf4VT2A6HfruO0tC/ydNMnun 9hJ0+hqcnw/atQMBOwETAm6DwdUbQEMD0Nng6HywejroNRHM7wqsNcD43aAmC0zfAorvkyPkNj7g 5HpMIVoWrlJ4wM1+TgwaO049hKJAPfLGWXQWNFkjwa693ZTZJwGGwRh5BGLQ7KxVHufIvrqdx8Sk W1E75w6gs/StddS196I0f9OyqS5uricyRIGWZv4BvoMWnB5ip9GdpREQ4L3kXIavFWv/tBEqA+rA wKDH1kG/LnW3nbLLLXA2g8vbtSx42MRtEJNu5NR3d6ADZOPW29k6Q8LXZQBjS7dUnoK4SipPqz6m Jqocq8qyOPeOdHJ1NQtc9er8ISNTR4jOvviqKUOYjwN/9uBO+LUbf9fuJjEppWXK8xcUZ7/550Ly bkdUvaP/99Gg+WW89xw+sWbFP8ygEZ/bFAzncOSfJqM30RvLxWorTuIJ3DQhEm6+6eQTfz8dyrZw +mAkDIXlckVF2sU9txI/GPmTgcFiE6b2xiMXD/wYBDp+1BdR52bpFwth4qy37D6LKP625SyCNLL6 RpH3GYE/ubK2QEg6vg3dvqlRsbFG0eD3CqljXG/7jyzkO6lJv59S+u7DmG2Pof80iwZ8fgX+LBg7 9GhawvT4vQIp/OF4TULBy+jt6jp81uYWkt80Brga1tSGQefxSzZdxGFeG0vb0AXWxAPAI2hW3rM/ gFMfIlyprBiH2mdDTMjSu+UKwNBg107iSXB83wQyMHDuujr56gcJpp6qxxUFHV061j9gZAWqwM10 bsTW6USgY4++iFw9Q78uyFoVKBFxRi5cLa3KVW51FBXcVO0XqvKAi9t1aNfwoaXaOLFh5LGEPKKJ ADrWDQtjav0NEXZTyj6eyFUd6qL8wq1D55nlj1UuHHxwRY0qfnRSYkDwPFhUBnz3ubQ3RXAhMDQn 9t8uFg7q60oEvHyPy4XZqsirL6Q049X5QhWY4qMRec74WRXKvbT89IOU3sFrpre3zM9+ND5kTxen r/ZfSdg7u0tWufC3kLXqZxwmZ0GuxP/R3XQxRRVTU5ubdOJITMrP84fmPLwya3eYa0e783deqaKy NekSGEVRbKSFDl+GzrOzfHbtt4Bp21d56IoUWDtdl/zbh9ccfyEof/PjoR1zt1yueH198ekUBktb gWKqB7WWSTviN3briCtpVWwTB2KXpRF728zARftvHFvoqypS/p3DXuN+3tBbjydBnAw7feNhVMaX jWjDFEoyu0/YMMff6iVHTMaDixet/4P4DzTb/OrbZcev68yM9CrVy3ChDv2CMQXv+I2nkEdw/x6d h4cctzHUFyO4m0WbywsnPyiSJN767ZUUZVqNyo3dvfzQTV5BQnb0xqXbd3Rqa3wtpVRTpzPRJ5g9 ylvUrB+VUQpM8V5k2Q4e5KJnibcvAot+qqH44p23IkMCdp6NQhTCY+dumZg1Gh2IK7IHbYglAm3c xyVF7jufKTw327ZAgIzvxj6yoPeZ6Aeooib85hMiAiziei67SuhGbglP374Liki0NdxH+zoRHWJg aEdEAF0W/C94SIECm9ev80xH40IReu6nb4tKMwdujCdSFVcKcUWlg+sSIqaniw0sL+s9+H8ybqbL iIOuumbETkstO1WRpgV2lRLS2MZk+V1mge5jiH66po4ecUgPgDEbQ1XRXp9dnlAoLEmNsRyy0LKN 9rOMwpL0eNW3c4K006H3yJU6chPOj1p/GEaRTbt+d/AcgCgEDJfFE4d7ErHmtTfB4YLtkUk/TPBR Lb01Xl83NOaZlF94/M7LzkP346jUUteqea8PpcAUH2Djj3Pd3d0nTP9etTm1fzDxKxNx/Hx9BwcO 4yvk42ZtaRg//cHxIqEcx+UHTj29HbaFuLPtrIyJ30CnATWcTB8fnyFDhwvVoxB0+ACfPt79siol v0zv37tvgESBzhrWjxhMWHcMIA5P+OUPdyO9gQMGnLubXZ4Y0cur95RpkwvlcH/f3t6+AcV8eWli xJV0soM/N5jsJgT49QkYMop4wvVfvJvY7B04SZXNvK/9iebCyNKDCI9Zd+aHSX5+/YZ59OyLoyJ9 6451JT+4ZG5AP//gOUuJcGLEHj8/v+8XrVEdurZkVLVSk1GFeLC/b/+BgzPKBLtXTu9mC54WVp/a ssLb19+xu5+iOKZCIJ/mP0SVSlr6jBASOH0+ER46qH/AgMGBS/Y179X5/KaUFBTvBus2fvXLc5ta SHrnTjYRz/LtdZu+rAdE04QxWXO+jP2b/CteI/09FIpGm9xCUNRg1h7HQHJyowhoYyPElqGiILcJ qXhZD4o/ZGZZU6OeKZHI5WKxuKLiPU4y/4PcP7G+5YTfSUj7J9pLwK/mfUbtBa1PgfXtwIn9wKKL evP0z2D1ORC6DFy4T27KuUCTDTh5wKR2yjEzFCzfDHq6gEr4rwXWg6w4FvfnvTgiGD1lMxHoMzHk XSmPrf7ezD7gY4qPiXO3HIqs25RXlSSWieo2uw/89q347Y2g8OuRZmwIl5e6e86OioqKu/f8YzJq XsLPnv/4yId31ZusXtk3r/QfvValsVmkgrCNrd46MMy5bZ1v0KE+7iIM3L8a/uf0ssLLdzLK3yXd 2EjHuO9cVdgCgj5oLv9n9PW1PxypRWneHnmLwy/C587CAyarN4FFbeBr8vfCTrxKOcc3IRCv835z 4FfcwRavafTuB2gadLCzm73r2v3Dc6ZNCQIMAwQTnr6fGXd+n5mZ/qqtDxR5V4OnjiXqB5FUTj2T aqpsZtt7eDsOIFc2/XGyd9qzK9tjiuoEdgPtGsp/Hb0/UYB2Z2sqMKTvxMU3Dq2BILPAyasUnOdH HpaUp93r4ebYa8CYvCeXxn/7vZ2FVTFf6sAiszDv2GOJq3odbRVCTpoRy0rBJY00giZOcAkY13y1 +VFEXrsKjL+KiHxAhB8+eNCwHotyMosr+UQg8/nDhOdpOI5duhKub24f9bhAFaG3vgHxW5L9Or2w ggggCumJEyeEcrUMDFEIETTmZgQxuhRzi2Nj41Hly9sn9+PKqshp4edxN+OfvoEFBV1HHHv14glc /2oXNWU53r0RyZMSNYXllAuirl+3Z4NrUbdwDIu9embcWHUtLesInjy6/zKdvFIYisTFxkpkZO7R l8KS8ypQ4cv/7b/OLUiKSC4DYFSLVmML0eqewNZg3gwQW9fG15ptOShdQwMcMJR7ZEJQ1zOavRC4 2oC0RsYxhpbtMvLz47ZMwCQ1E386HnNsLSTPE4sUvjPCy8v5v275BlbUDJyz5XnoPll1ZSlHwoFx 4BSU9Tg+MP96WgXvtxh2J/cRSwKs6wS+bGvXUL6FvePVR1l52trpL6/3GxA0bVv4UA9tHsu0IuU5 X6Cw8Zr0JCmVyU/GaKBKykpOuvWqRJBJPFDa+pWlP92ehGjVXpar2xZ5fz2rTFrM0G2XWi66ePqM MC2m8RCixWEoyvz9x1rYmUKQ+cPIbSG/xZF7cdTEQPteDsfLxGznnEGXUqvHDenJg1Fp0auhszc4 dTRTJoU5nXpeXD1m9NbLno7WOCLVNTL39/c4FU+OcQiFyn9w2MGx26pVSxPjLwycviwtYu2N9DIj tkkFr9RryNhT/wv6I10Utmtl6oOo5Mg5V8J2XX1WqEqIyIQ0S4ihxbDrPqg678XuuwU6bAbNZbiZ hRVEo1drOaEl6vthWwZ4VYpN6OssKE/WsnDREsRtOH9rlLeTyNR54ezgC0uD2xoWO/nM8W1TvTb2 oxz0/+v43C3I30KE+4/Bq0pxoKHckuA/jcNj0vAdU/Czt3GZFOdl42xdXMDFmSyivcVlCtydiWeV 4ctH4/ElRAp5rTkO0LfncTmadFb8zokFqil/6esjUckMmrmAV2pg/pU4I/RxNvlsEZWkDvuNtItq 40IutI3KBUQL8aqgRl7+ZNiYKyppQj7P3NKDKyabdkT1ECE68wCIZBnEbzUqByYdxBLJ+Z8CX904 sPNmAcPASigiP654em5VRK5QUP5qVUQykci8nR/xe3CUBleqKidK3PF379y8dvMOLyV6e3iioKoI MLU+WXWreHRk0vVMwa19wSIcl+Rc3349ldhZmhh27TUHhUv8xs8AENTGxEwkJWdpD2+Zya1NyHl2 ecnpx9q6pJdPN0vm8ZBpZaoD8oJOXl5jghfMBFqqh6q/LdBi6zxK50Qvt7ufUZ14ZUtkPoeppZ4B XjPMhvjd1N+6iFfczstr1PgZpc/3vSkREpps2SPwzOLeQhkiK4pedjCeiLZncbAmk/Y4n/SzjUrK ui29TQSCB7nO8yZv9UNB+nmFD5b8fEcluYOVno6WRtiT8gdnl7eUdU4L07oUGMdTE/HwcFyhvOxT lpNaGhuF3yZ7d/jRLThx2+em4mFhOHEziQrxDWdxHMYvX8IfJhHHeTkJuxLUNm66Vh2jo6P5Ujj7 4SWxqmOGKarF8urC9L2HD4thTFH5ooRP3pEYIi/lk8aeh46Rr/gxWEyD3q608rysxMTE0mppXsSP d1PUfudXLSDvv8VrdhC/NZzCM+cvPn2TC0v51RJYWlMZE3Ona3sTSWWBFMGIB8qlR/lkFgfOvCWZ EJuTm5+blUKU8fKpg5s275J+nElgMzKpv5sUx69uGtN55o/amhoql7qZd3c5jJ1H3P1Rqfksbfav m9bos0j3+sP1mHUJ184ezINFNLquR88u268nblw0fOjqHY4d2kprDT70TNX2T+4ArPx5c6f2Vv/r abFkzR5rU4PMKo6mSdufvxv884Eoti1pNmdraVRnkznPSNM5cLq9hf7jIpEey4yQd2yEz+NS+YmV g8fOWtTJXDevhhxBZceFmbd38vLsFrz8wnAzEBp2gk2jlaZesfIfM2uwS1qNhNb7R0zB1e4+cu7g EZ+qOpuZ1qbA/wB+6Ru0dhDVZFvo/Bcnz6dUvutoXvxx7F3HGhAYOGzS+NF9Zu9uWhk+MUWFJcr/ WEFBQcPGQyKRdDE3JM4XkUuredWqnSWFxXURRAKyCyOtqeDyJao9OTn5DRzzYtkltTaaGMqtUkso Li6FJTVERqKqMo5ygK2AUaXk+hkHqUhUzeMhaH1lc4vylGLgvLw8GawuJorAUhFfrBz0orC8lFMp 4RYQacpLiqqFUrI1VraGYrEsLyf/H9XR5+MLfQ+MIQiN0aT5f6K6PmLBtP84mNDc0g4w25wMjxvo Yf3h+BQtxheqwBQU/w1a2yw0BQVFAygFpqBoxbRCBUZhIGlg3SPiAZ64fpMYEZSUvJ2kvMV9zQh5 3CakEldkV3/IQkwqlaoCCgSRy+VCoeT98Sm+KFqhAltpgMO1jlrunQd9gsCIXuBBOrmJSgFTA2xe BFyG1McvfAAs3jbE+ytkg1df+PNeXM7t4EyaZI2dvf1dKR+G7dEzcvuYsqO8xG9X1BsM8DKePCiu N6UcPuKHt+IP6wSNDBrDZkK4pMDSqsuYMWMmTlr2MRlRfCl87mnwv8nKKfjVp/hvtR5ngFFtQGkH d2EXXqJ8TzFucK0pJYJr6OJTB7wlBuhZ+3t4RLzMexy6LOzMXsAyRXHJ5Rd5vLykjh2t4jP5cFH0 ubBDRP2gMt6KyCwT5cRzu55+PvOOEMnDQsa8vns05HpenUCPxqaUGQ+O5iH413psDMf6T11SmHwP AM0NobcQXsqFVxy5iDt59KCZq/aWPb10JDK6p7ObUIZ8pWxLzTr0GMsG4gavaxC5uK0OC65KIo6a mJkNW3GkueqS4j9Aq1LgR6E4YOILg3GjYFymVFBarQcj24nk74VfcaVnBTzID1e9IzTQxMdPxttr 4WevNZSkZ+tM9EjbmrDjd048Hp91fOVERPr6YFQyC3Qj9msZWYozQjdHPI1cP19Q8mb4XrK9AM6k JdYwAFVJFAzwtoMrDVufhpvlr29sTSgktD43+96S3TdsnbqvCg4AnacW3z6wM7ZAm20mR7H+ns4Z Ty45ewXwil9EviHNP0Bbv7fE5sSfhCCookaGiksiX2SRJ2rZ5hP5EKNoDXzeb6H+Jp6TgHwsEJUA s1LAUto6z7YEmTyQewosDiI3e/UFAUPBwwgQeVdtJV0pACgGphWCUQMaSpLJEAaE8wWkc2l/j/a2 3qeBPJkOIMiIaCEUDHKBVODn1MFj2G5xaRoiJz9T0VN+qxIuLGZpa8QklSo4Tyauq7m4nxSLoSgb YAgGGLUjEtP2nTdau5RWvujTIzAuLe/XNZwljxNGxvwqRCEMxRFtbSYNepz0RlyUsuXMHwxG7tMC 7hAnU0PlG72j30CjTqFtWIQs3OXr5ZmZqZzSIi1tAQQsMETKqazRABQUalrXGBgincjqtAEe9uSW +1Cw7w7YvgxcyQCLRoCN3wMTdzCrN5g0BeTwSV/Qk9YBBhMV6dSdAAAOz0lEQVSwWCBgOGBpiMrT 5oalqgXJeTNnfRefz2NbuGipPntg2nR3sni4f+7IcZOTcwrpmiZsbXK5JpaB2ff9yRVJAzzIbxg1 tI2YNBDgZqFh5qHSXoI7pw4Gj+p+83V5dXLoH4/ySflaFt07e5kbd7P8yt1aUzP16q75388MzbWy cfXyczEujDv17exvrUyNTOy6dDfXYhvY13DJeTj/3qRn9pkXcKX2kmK+nTr+btyzJ7GntW27nt82 L3D4uHw+NYlFUc8XZMhRlHjR3C2IqfQ7beLQozLrWROEcDIiT5V3/sHH5i+Pxv3s57367gcbxQMH j35lrRO8Nans3pYmlIGCoo5PpMAKOaahfqoAmQLT1PjMT35EoWBoNKkrSplSUvyb+ESK9P2oxLqw 99icT5Ppe2ii9hJQ2kvxb6KlJrFexHFuPpUvXW5bmVx57LKkQkgONKPPFadwIUtndgtlSkHxpdEi T+DqxOLQ59hgB3pCSs0Px6Q//WTNAxpPw4urrPQXjNN1aMtqiUwpKL5AWkSB0+7wF0w1BSiOCVCP ocZELloYyOFIvbtoMw20JX93hSwKCop30CIK3Gux47ghrxbsrAgLr8nclNbT/SVfphj33Vej/JN6 9nqVX9LI/Dc2tvrpU8G7RDUGBgYG5J++fv0+A32gb1C/eXwJ0NMDL/LUm7MM1El23vug9MM3kv5i LyZbtCXyL/Y3pmvDIr0HmHsi8lXd1tMja6JyxO+JLheVGhkYrA9PwARZBkr0G54sBcXntiTBb9yo 6t79eZ8+L6Oiqj4cu98E/PlzvM6tzDed8RI+Xl2Ej1UuCJb5AJ+oXKLOqdZb5aEgPDULT3zzlpi8 7OKGmwrlCnqlVcK3osEIguNoTkElimHthy2B4XoTR1jEya1SO5o4+8uKblbaH3OyOKYo59bnwnl6 KSJXLQTFUOs+44ks0u7+UZfNmMmLZDDs+ZU+BnN8Bu1+8eKJHP4Ynx8UXwrN+RrJ3b0p69P2729Y t8A3kwmFhNgPHNjmHXHlwMQR3L4K3DoDoh9OB0DLGUiVq8JCAQCPBRd/AyMXkxNzU0aAo3+Qa3yP gUCnnaADBJ6zwa4ZdYIgCJq3ZOnBy09jFtmO3/ncQZETm5d94rbw/o8jDPt/HXYuP//OaG3/X/rZ KS5FRI49JQgQX13264Xdvyz9YeEyqajKzcLgXmpKnsigm62OSmAXyCkJT62TnxJ1OL3T5OCOOiXi qvFzd0vvHfEbvyxk3Tpe0oHfOZ4ax2dm2Hk+P3vkSNi+zl4T5kwbMH71iaQLe+ZvPrl90ypvi5Ku I39SedcEOLZqwaQnBQ7RRwJtPSfejonydHUWSBXUVDiFiuachfb1bUrvztiYWReGYTwtTfJuBWaB SuUCCD2JqBig04BOoSod8OtF/mezwZtq4GYIitKA6j3RRYy030KqwaXlANQrsHF79z07tsdcMKAB 2ycZ6bZEZHkyg6YRTveSbttx9HcrHIx4fO++Rzs9cWkat0r6w4aflp1ImT9zuq9p8dytv5hPO6DP ZkPiek/gr2zNGxa0rZvnhoPHv1vx/R+HN8+au3D00Z+whzE8SZnk0XGhSLH3UTH33HqPa4f1gXRf fPaUToKIIsm8lT/N3xe/dO7Mwqf1XtQ7MTUvl1ZvMiXn7cvzsohfQ31ttOVeHlC0Oj53F0DdhSb+ Jk9Oxd7fPUQrcWCID/fHLUk/o/jAaXjCCZylhdMAXlSDb1xCdFBxNhN31MKnbsSFhfjaU7iNBT58 MvkJRJkMQ2R743JVklTnbjpoQ9xvtW5lxSmHb6QMdWC79XTr2mu/OD30ocqtbGnKwD3kWpjAabSq EFoMUKPAUVHRkegMlbQZQb6EtF47nuCY/H66ygWcDEAsGBWratisjd744NmAxU6O3bs9tnCUqdEQ f0cGnfby3KqoHJGUX+y37gaZhT35McOj/QvFKtePODlZoKXN1tZk8LLvAhPr0T2A1QzqaySKev4V Cty/f1JNzcf55VXIcbFYHeYpfRoisHpILBKo98uVn+tgCC5QDi9FYmIsS/xPv7U1my9VRTFq3x2G lW6cFdLGjQYmkSrjoAq08QGplFR0GZ8DfEPeVbqwGbqFNWrnpwI+WZ4agbq0MrmiYfOEIIgNk46r v5nC5QqyhFKJ9H2nLpOKROL3RKD4Avn8ttAyGaap+aktK0069KjMbIotdMa9PTpdv7XS/UdfBPVx di4Wi09F3e/r9Nc21RQUH8nnV2AKCoom07o+J6SgoGgEpcAUFK0YSoEpKFoxlAJTULRiKAWmoGjF UApMQdGKoRSYgqIVQykwBUUrhlJgCopWDKXAFBStGEqBKShaMZQCU1C0YigFpqBoxTSzAr96oXZP V8WVV/NhTPmlEwpjRACVKq5drsyuqF+buzCJd/lypVSh/hwqO1PIrUGJwL27VcT+1ByZaj+qQFFl QCZ+ezHs9MSq5i3/J0YqgrlcuUyGJVytPB1a9vvJ8gqujMdT8HhykRipLBLFRFfeiOXBtZ4/4m9x scYfj+FyRTFPVT34yROVOIzC6Ifz5ZZLS4sl+YXSuj0XTnD+HA1TIM9f1uDKwM2bXJXgx/eqkjPJ hAKuJKNA1pTTbv3I5GRlPI4sJ355InWN3z71V3UoV2QVK4gAjqIpqcJmLwk9JCSkGcUNDUqdMt2C AWGzpqYcDa1Iy+HLU6sWbSwJP19mq42fT6kOW1/sNdrEULmg2KKhqV188eDg/BmzLLx7vEwuEFw4 UoZYMTdtLPLxxm9HVHr5GNNpUNKdskxE0NZYb+7E126+bH222q00AmNXdmabddbS19EkNlEU6+mV FDzFTLW2YKvgQEj6snWl8XGVd+/X9BpMtzNEUp9X7dxffuRURXwMt6SAL9JQMCUSAQLbWuoS8YPG pf1+rKwMMHy6sxEM0CAgK6mMTpM42rDpED5nVlZPW+xJlcTORBtDcAbjnfWwPSR7629lL1/x/QYa azFpRKOwfFZm0EyLRilg2MMnmS4VnXkm/GVpwVfO8LczCxlZNTdyBFdPcDr31Rs9OevN7Up2N632 xpotX1X/FnAE693r5Z27lfFZgtJr3LY+estW5nw9zBRBsPGzMifMsHxr1aAenkmoNuLdw3D40Fc1 FYKzz0TD+rzLY1RTaO4uNB1okDcB7eg2ix4+WlvXOYYcF3PLcAcvIyNdhpklnWjGpbC8Lvr1cAkG oEcXiu36aJ082PnqtQ73H1cgNdj6tTXxmvoayuU6q7hSRLlYaE01dv9kibv7C+Lvye50z16JR+4i CjGu2rN5UQpAMD//pHGDk4jNOWvym/nUWoAFm5wBgI6f74LToA0r+At+qB46uVNoqLOuC+vMWTdD CX58j/iXnSKnzmqHWzQGlPCwW2V8ydEreSOCkl/vfx1+j79zeUkvz5d85ZM55paIrYd590ns3Scx tVT+rnzXbnd0tKRt3tmuv/cr4gL0HPSa2LlhzItHlfBk38SolzwyEpP5NKFL7D2Fix1i3Ys1I9iR 2PdHsnTDqnY7VltHp5ahNWhaCWbGfrtb9N9GXClToIBTBX03xZ7cxnCRCW31/GSvXomAAeWfSSHv Rv/kuvhXNpuY2JC38YWz7a7dUriYIu8Q3ERaagxMyNU30QA4dibKLTamvQ1XFHKm0rUd7Vy4lZOp Tl20GcvadLAC6SUSB09y5/7FhV2/YrBtGQkPXW+sMFXFMWqj9SSVvEty+ZC2geb3u8xsAFh/SxIV 2zHAAlxbl/v7aXMrbbBohwuhDDFxXQorUU0D2rQxrWR4rwUxyZJCZ8NtYu90omFEd5lRmqJ2fh96 2frhQ1c9eqMU3wUZZWVIGfoMhgbNUJ+2cKtl2D67k3H5xCGi9TTEFCb2jL1TNcqq1D3ksDWvvQe8 3Hs5V7XJzygr4aNEa6jN0AAMQDwxzFxIJ3k/HnNaODQ5XYT37aS8QDjq7pm4eY/hnLHti0rUvURN FpAAKC+3hi6GgxbrHv6ffuixj/Tp/R8BBVhCguvFs3ZTRyQjZDcQ5Qjxp4/h+EddiaNTd5ON5sb1 WvUJGICmXIgrt4oVH+sY+aiZ27vmdm8oxfq4vwA6NIWIHLdxi5D7N4SaNKBlSpviz7K003Gwr/fe SJz/7OkVPXxYo2ZYfjc20317pV0X5tFAu3Pns1kNFh/r4ms6u/friM1VK34x0CuhbVzIAbq0PZMM hgRkEEcPrzSdPptD3FZlIqLucAii+brS7+dgW44KL+1u5pNrdtZOSyRqrLfnS2cDaOXScliCXYhw ZdCBvjmNUGAajfhjaNRXBY7B+IQJybk5SPg1m6BhhVOSwQ9z6LvWlx5gQ2fOWJ4HfKKjIlQAtibd potWbLkQuJJ+Qsdu6Dy2QaaaxjoBAUkMJk1DkzG0HeTp/sLQm7zhGHpaPVB88H4DXW0yRxzFAAZW LeHb+2Dj7JnEg2XgN+wFw00C/VP1TOhH99uMG5MfwQBLthp/6lr7rGTd43y3jU8EBk3Qxu9JIAiy MoaGj2X7EE9gJvS/YJ1fLog3bhL1uYqxlQ3zN8sqYTpt6gDz9TPe5IjAnDW6zVueZnapA8ulUjnC 1tEhrj9x86mW8pNKpUyWJoMGYRhOozUcZuEKBVx3g8pkUjpTk0mHJMIabd23FjrARWIJm82OPVlQ 3IE2oZs5i8XEMBQHEI1GI/3a0RgYhhHjQBqdbJIQGCYCjfP6d4KjKE6nk1dawOcTbR5x4hp1Y3gc FcowXS1mwwQ1fD5dQ1NHWxPguBxGiOErixjEYsSIl4GhCHHWGOnPD2EwmVIZrKXJ/HOWSsFwVbXQ 2JgcjMnlcqK6tLW1iIvl0efVzTtuBiz6n5OgCEJTjqoJ8USZGUQzA3C5XMFifXErXaGIAkZwTaI3 QjqVg4jqoNPpKAJDxC0HQURF4cRYh/EXHUBYuaht896UrcwnFgbDZVyelYXZ5y7If5OU9ALnTnb/ /maPoo5WpsAUFBQNaSUzPRQUFH8FpcAUFK0YSoEpKFoxlAJTULRiKAWmoGjFUApMQdGKoRSYgqIV QykwBUUrhlJgCopWzP8BlNmIH13jKQYAAAAASUVORK5CYII= --Apple-Mail-102--974640808 Content-Disposition: inline; filename="Picture 8.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 8.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAUAAAADuCAIAAADHk0nXAAAABGdBTUEAANkDQtZPoQAADzZpQ0NQ Q29sb3IgTENEAAB4nJWXCTxUX/vAz52VwVhCQgwhighZy0627HtFzDC2YYxdtkREEbIUiVIqWdpR IUIlLbaSImuRJEt2896hfr/f/30/7+f9/M/nM/d+73Oe8zznnufMee4DACfBlUr1RQAAKH5BNKv9 OgQHRycCtgegARtgAoqAzZUYSNW2sDAF/7X96gYQ494hw7BFOVbfGv36gvAlyiiCR0b3yH8ft97w NNghAJA0zNzkDdZisNsG2zA4NIgaBLMng4meriSYI2GWptlY6cJ8jWGHvMFVDHbb4GcMDiGSGWPf A4Dh8iN5+QGAnYBZg+QeSIS7GX5JpEAiBeYzACB0KBR/2D5HJyyXJFJp8FiOFZjFGOuyMWX3AADU dgPAnP23zBueawUNAP7Fv2XbWQDgDQWg/B96M1brawXxvg70UJBfF0GsOgCg++j0GQl4bhkArKbT 6cuX6PTVywAgPwJQ70sMpoX8Xi8IagPgfz1vvPPvhoQdMgIsAmhgAopD7EFCyFW0GMYb+4rZhQXN 2o1/ytHA9ZF7erPCFpJAydZxwk5RmliJxIAU+041mf2ySru3KmAVJ5XaVW6rndrrqCGiOapdoGul t2pwwVDZ6IWJo2mnma15g6W81TnrZVtHuxoHvKOLU+XB2cOKzjSXq0f63DiJBqRA9wseDeRRL5y3 lI+BrzMlxO+0fyG1IqCO9iZwIOhnCAjFhwmFy0UoHd1ydDKyISo7OiDGMFY0dvXYh7iHxwviYxO8 TlgnaibJnhRJ5k1hO4U+RT+9mrqWRk+HMpCZmLOYs8tZg9nNOaW5GedCz7vlWeZrXJApELrIUYgq XCiauPT5cldxy5Waq5UlF66dvh55w7fU/qZWmWQ5e/laJbiFvc1yB3+X7R7rfZYH2Af0qtnqsZq+ h28ePXlcWXuxLrk+9IlHg22j3tM9TeLNfC1szxDPFp6PvahvTXpp2oZve/3qzGvzN/g3z9/Gt2u2 L3ZUdHp0be3q6E55p/Nu4X1Zj9sHvg+ve0983Pdx9lNln3s/a/+5z2KfywZUB5oHbQaHhoKHscO5 I9Ij9aPWo6Nfwr+yfr04Jj/2dNx6fOhb0AR6IvO7yPeKSfXJph9WPz5PeU/N/IyYRkyfmuGdKZyV nC2fk5+790v216V5tnmP+doFlgX9heiFqoWfi6TFvqXOlai1FDqdsYNBJISAziC0kNzINfQ2zCFs NbM6rp01BU/kMOZS49bhdeKL4i8SbBGaFBHaZiJO2h4vdXZnoIzYrmdyAfL8Cg17vJTxKjfUdNQ/ 7KNorGgl6bDppuijDSL3fzGyM75nyn3Az6zRgtfS2+q29bztPrsQ+wqHIadNB/UOUQ7nOTe6jLpi 3MSIuiQX9zCPVPIVz0der70HfGYoTH5C/vJU44BDtJDAM0FFwUkh7qF7wzaHzYV3RNw6mh5JjbKL VosRikXFThzrjqs/XhqfnRB3wi/RKcnwpHKyeApXCv3Ut9NdqXVpl88kpvtmWGUqnxXOwmXNZPfl vMi9f674fHpeTL7vBccC/YvyhcJFuKJZeDe0Fd+9knc1vsTzmtN1jxtHS5Nuni8rLi+reFzZdOvl 7Vd33t7tvvf+fs+Dnqre6vc1PQ/7Hg08Hq39UTf3BDSwNQo83dEk27y1ebHl9bPi5xEvLFulXoKX 3W03Xx1/7fRG9i3y7bv20o6YTusu8a7Z7rp3p9879Uj0TH2o6o37aPgJ++l+H6mfs7/+s/+A8EDb YMSQ1NC74eMju0a6R6O+iH15/tVvjHOsctxy/Oe31IkdE83fXb8vT6b/kPzRMOUwNfEzZppr+tqM xkz7rNvsz7ljvzh+FcyLzecv8C0ULu5e7FxKXyavEFfj1/LoBLoDPY3esh5/HmAMzkEQFADNIVKR e1EA1YvuwPQyAWZpXChLC5s4Ppl9iTOAa4Tbkad1swpfMT9OgCxYK8QibEHIFenftl3MW/y6xJCk gJT5juidpdLtMr9keeXkd5vI2ymQFal7QpUilSNVIlTD1Wjqnnvd95E0PDQ9tFy0nXSsdE31tPUV DET2cxgCw0mjHuNGk3LT3AOxZh7m5hYqlmJWeKtF62GbN7a1dsX2EQ7GjjyOg063DsYeMj8seHjc ucbl5BE7V3HXWbcGYjrpiLu0+6JHMznd08VL2mvBu9HntK8dRYDS5XfCX86/hxoXIBHQRgsO5A+s C3IPZg6uCLENWQotCjMKmw7PizCMmDt6OdI6ChNVE02JEYvpjc06Zh3HHvfyeHK8XgJIqD1xNFE5 cSap4iQleUfyl5TiU26nhU73pualOZ0RONObnpfhnCmSOXz2WpZPtmIOIudt7sVz/ue18jbljeQ/ uJBS4HZRtZCzcLyo6VLR5bhi0hX9q9tLmEu+X+u4XnOjCN5lQWXO5UYVypXbbrHfBren7wzd7bnX dr/xwYOqu9WlNVceFj7Ke5xbm1OXWX/6SXJDYuOJp7FN4c3BLdRnHs89XkS0Zr4sabv/qub1kzdP 3ta3P+/o6vzUNfOO/71xz/EPzz4qfCrvNx5AD44OL31xG2f/Ljv1ZS5j+Qoj/hu5j9EwSgBkGQBg 9xoAq+sApJvBqY4D3iBwrrZgA8BGFSA+SgLEtTkABSr8lT/4gDw4ADxANMgG5aAZfAKzECskCqlB FpAnFAPlQOVQM9QPLSA4EJIIHcQhRAjiDKIU0YwYRNCRAkgVpC0yCJmJvIPsQM6geFDKKCdUFOoy 6jlqGi2I3o8ORF9Ev0QvYiQx9phETBVmDCuItcCewD7GzjJJM3kwXWLqYxZkPsicz9yP24bzwlXi Fll0WTJYBljlWBNYP7DJsZ1kG8Zr4wvxa+xH2Js5ZDjOcgJOKucAlw1X2ya9TXXce7mredR56nj3 87ZvPrz5G1/UFs4t1/l1+fsEogRFBJu2+gpxCT0SJhN4CE0iQaLiooPbmsVuixdJJG8PlyRL2e/Q 2yknTZBhkfm1a0D2hdyd3fnyxxUoirZ71JVElXHKsyp9qq1qteote3v3TWpCWlu0pXRUdQ/ouejT DBL25xqWGzUZfzJZPrDFbI+5s0WCZaXVBxtOW0O7BPunDqOO9IOEQ9qHPZ2zXOqPTLlJEEmkYvcR 8k7PEK8mH15ff0qTPz81KKA1UCIoNvhdqFzYyfCho7SobdGDsVfi/OLVT/Akzp3sSmk+XZVWkX41 syirJKfs3K28qguNFxuL+oszSg7e4LvZURF7W/Fu/4NzNTaPuev6Gx41nXkW3Up9dfRtcGf6u4cf PvUhB4yGS76e+J49F7youPRu+ftKz+rVtaL184MX7AYm6/HPAZXgGfgMFiBOSArShhzhMyUZugw9 hrqhKQQOIYbQQDgiguDo30Q8R4wiUUhRpBbSBRmDLEDWIwdRKNR2lDHKH5WNqkf9QAujLdHx6Afo bxgCxg5zCvMUs4JVwgZgy7ETTDuYvJlKmSaZdzOHMD/GoXHmuDzcVxYlliSWXtZdrCdY+9lU2bLZ 5vC2+Cp2fvZj7N847DgaOBU5S7gEubI2cWxK4WblTuHB82TxCvGWblbd/IzvIN/UlpP82/hrBQ4J rAkWbdXfOiaUKqws3EdIEVEU6RdN2eYspikuKYGXmN3eJ9kidXdH/s4k6RAZ4i5LWS052d2i8twK zIqQ4vyeH0rjyl9VxlQn1Wb3ovfxaezU1NJy0PbROaZ7Xu+W/kuDEUPISNhY08TVNOnATbNuC5Sl gtUR6xybdjsW+wMOYY7xTpkHSw/VHv7ovHKE11XN7QgxlfTYfZws6Gnllezd4AtRNPxC/e9Qp2iS gWQ4L/aEcoWZhCdE9Ee6Rc3HpB3bHlcX75CwmJh3Uj154FRq6t607+mFmfZZW7JHcsvPR+fbFsgX 4ovWiiWvulzLuNFUBlXo3Dp+58192aqMh4jH4fXYhrNNSi19LzLaXN4Ita90jb5/2lvWVz3QPNz/ Ne1bz2T+1JfpztnAuYX5u+vxFwfmIAwUghb4K5ILUoIOQbHQFagV+ongQ2giyIg0RDViGMmB1ED6 Ii8gX6EQ8D/cD3UNNYQWRRPRV9BfMTKYQMxDLBprhS3CTjPpM+UxzTAfYC7FseD8cJ0se1lusgqw prFh2GLZ1vCx7Aj2ZI7NHJc4ZTirufZzfdwUwM3CfYVHn+crb/pm9c2jfDlbTPgh/hqBEEFlwYWt D4WihPUILIRukYuiPtvMxPaJK0rs2C4quVVKcMfWnULS22V27VKTNZJz3E2VT1K4qti4Z1gZp6Ko SlTLU5/f56XxWYukPaJL04cMsg2ljZpNXEyXzNIsJC0fWZvYfLbzt19zTDjIdajQWcWl1ZXoRicV eWiRh7ySfRR8B/1SqKoBI4G5wfohc2HXIg5HoqKKY4xjJ+My4hUTPiYePymW3HzKJ5UtrSzdMGPg bHS2UM7Dc7bnf+anFuy82FDkemm5OOuqUkn7dXIp+ua5coWK1ltetxfuZt2XfvC0+nDN7KOUWsm6 50/Ijdinxc3mLYvPC1pN2xCvLrwReFvQsaOzrpv8nqmnutfnE76v/LP9wMQQZXh41PpL9Rj3uMW3 4xNl35sn3/7onGr+eW/6zIzvrPTst7mCX4a/pueTFgQXKhZlF28siS0VLCOWPZZfrOxaSVx5uyqw 6r5asbq0dmCtmi5Bz2DEf6NeWm84XX9ffxrBVFfvfxR3/99G8Q3+44ML/rH6uZmZ/+av1CALm/VT CIClwBBrffgO5yyIw8PLwOg3E0iueiYwC8IsF+Gpa8awAbOpB83AamMs5ODtamwBMx5mP3c/W+sN +1Ak1Xe9xmVwKjVIx2o94wGo0D1Q/49OVYSnjf3vsS9owVa261/VcG3p429i9dvXCsld7/fcEEx+ vmamG34RfF5BRuu1LMy7gAFwhasxMnAHMsAU6AK931cCLCfA5A/3uoNAWG94Xe+Plt36s9e/jZKB T2WGvZD1MT5gFGaKi1ccDbb1f60TYcvBwBfWCwY0uVK5MbmVv3QYXn3XPf+RmPyH5I+dv3W9AAm+ /9P+upzhnXLbIyTXP1zNzhMlgZJH7UHpoPahNFCqgIDiRfEDGZQiSgWljdJEqcN9qq8mHkz85Wdj fdz+ek+TP3OGr37/sWbEf8wGbNTv6985cAzy4xnUmLUQ++97Lcg9bL1G1vWnhtO8yJ5BBG0q1ddd mmDkR9wlTZCXk1MF/wKDW3gdwfXxVwAAAAlwSFlzAAALEwAACxMBAJqcGAAAACJ0RVh0U29mdHdh cmUAUXVpY2tUaW1lIDcuNiAoTWFjIE9TIFgpAD5Cch0AAAAHdElNRQfZBR0SCA/UsgfyAAAgAElE QVR4nO2dBXwT58PHL56mTZN66gZtcSuuBYbrcHfXMQb/MXyD4TaGu8uYwLAxdDi0UKDurmnTpvHk 7n2euyRNFbYB5d493w9cn3ue5x675/fY3T1hEASBIRAIesKs6QQgEIh/DhIwAkFjkIARCBqDBIxA 0BgkYASCxiABIxA0BgkYgaAxSMAIBI1BAkYgaAwSMAJBY5CAEQgagwSMQNAYJGAEgsYgASMQNAYJ GIGgMUjACASNQQJGIGgMEjACQWOQgBEIGoMEjEDQmLcIWF+k2Lw54+MkBVEWIiKyuKbT8P+BgixF iQoHhvyEouDg0GHr/l/VZ3b1zl37xpQoCecm2JjO7h8nQRUxGAgWi/ExYyRw4vpveRfOZ72I1bv7 c3v3curZx9HT4S1lVREcJ5jMv5FyjUy9YHb0k2iD2WbONs9x7Zz/brw1TqUZn9Eh9JkSm7ex1pgQ 0YdOwG8nU7/dmmdhwXrwqIFOA2Wc8FNu0RwHkTX/Q6fh4/BOQ2hCo/zQ6aiK0J/jWrYM++O14qPF mP6moHmLsKVr0oB6wWlGgnbfDxkDu4dHpWv+VjhrF0W0aBGWqNG/o/+019K2XSMs1QsIi5RpDDTb 93fJ7Ncg46laQzn7l2Qlio/MUpd3ea8QRNeOYWXVCzDkSgtsxVzSjOv073pTPn0+9TlwXhy87VtP pKg/Sj0OO5s0YHwSMLA5jN0HxCdOiA8fEI0ayg0IYLI0GX8rBYp8LTiu3pPwLlcVxkoHTkimzHsP iU+dEjcme6mUZINBj/+9PNQ0qkIoj23HEsrZP3rW9NBh8bieXC7rA8bevm2YTAGL/PMZ1idP2R3c a0PZ63UGhnFMwNTqP2gT8lH528PCj4xrIxvsvIyDY1qNni/gfOjopm8sAMc+M23GhnDd3D34XBhj /UaETqcDN/5vjeOFrjzslQqknCAIBqP6S/U9RyaDP9a2rEP7bZ1d3YUC3o+/agZNjlw4lPuWSyF4 cqrWx+tdx4R6rYH9ITVk7czBYjSciu0Wg9Gwgf+HixewbtIrFWw2sfW7xAGeQg+JMyi9oa1fZzuy LG8Bl/0hm5D3xIs72TuOFo5YVrubX3UiZVT/ywydOoSBOfCCdaKRXWtV4y36qfTXP4uVaty/nnDc sPJzNq1CN3dq5PMYvcCW1aef07x57jyLSqlT63b9mBERo7QScVq1sRsx0BHaKlXtQqLs3djWal0c ORoS2jCUWqzbUMm3892MVxLExVPZL2KVDDbzswHOrRtYm8M8sytV42I9bpCDPLdk247MB08VTFvu lZ/qVZMFiKo4uH0c+HvuvIOfr0/1fqOeSk9ekGZLdUI7bquO9kP7OFB5yk0s7DU0yduHo8jT5isw NhvjcBgGJmPaEr9x3Suf+80e+epxrI4jZJ48KHL19LHiME350xcXK0UiW+o0PbLw9KUiucLg6W89 ZZzEfPn2xa+P39Tuu+zf1EW8+uuYi7dLBgyXLJ3v/uZR/pHTeZkFhs69JJNHOlKeC+IKu41IxFys n14KuHAqJylTKxRzp01xLdc4ybJK9h7KiU/R2En4XXs5dGtVJuWyVPnkafHJebidM6dfP+eZ0yQs BpYWJf18bIqPD0eWoy1UYnwrkAEGwWbMXuk/ohPMwrPfsyNwzvh+DpZBFecoDp+SSgt19o786TPc +BxjOrQZOW36p3ce4bThS89N38af+Q2u5038n+/MwfZV3ZH8SGmPscnAMHOVbbemYg9Xp9JYiout rIW6XGWHvtGgIb52s7aVnnX4ZD6osUFNbft1tSsXVOQz6akL+Tky3NvXetAIlzpePMq+TXCoFmM8 etIk/HbOrCUZBhwLCLY9tad2ucvjwgvvPFbpDIRfXUGPTmUCJ/T4vr0ZYeFycG3tusJhYyQ+TmW6 pZu/ZZ84kfM6yTzIZ95/1JDPqbLFeYuAO7YPU6iIb/eKezarqu0kxvd78SbTIhAH3rPr9c31QSfX tA55U+6aB0+a8sh1qTtnUxduLDtdYTKePm1a8CS1x6xy0xgIz455/qd6biJuca6ic69oS6dWw113 LjRqOzg4FBzH9LQ6flVl9hDU1+b4isDq+jOdMrh1FPjr1cJ6/SJvDwmPz6+81/1uTNivUeXKjfn4 WRM2A3twPHre9kpm7I7NeKe2BtkLyrem+pKSVp1igGH9YbtG3u6OtrxKk/bVqBe3YyzG0gL2s3uN qLQt6B16LwfbfMpu9aTCIlN2g9twnz/Ull5+2G9YA1iTwq9lTFqaXTH8a/caOwqMtWT/sjd7r5ad 8PM5z+43pKJT5Za07xVT7vLHT5veOhCzZF8lGXduzTu9sY6IzwwODgOnv90IcLcTUk4Hl0Xsvqq2 9Pz7rUYSW1hEiqiUjmPyHRpxraK06aX5wA5cDGjsJqykgDBsZOfQ2GLM1ptzYJPIz9e7ogdllgIK 2IU7oy1j98+lGew1xXX1NFOvgOEj+obHZZWZtjTu6nRgnRdmqlczh3B3nS9NU7OutnvXGTUc/TRv 9MxUy2sFDpzvdwS2DYS3tSRf2alHVLlUTd8QMLkzzBGu0bVo+8psz7dmqMm5wLU79R1tKq8V2Fvn wAT+lhncxJGvKfXaebCG9WPDeyzVzNyWbPYwvidUr7WIde6c3fnz9o09oZeMFOjh6ZlESr0iO/aZ s3bHD5BdDU4kJyY6tvS6/Jvzzh+EM8fB9smhIffIMfHJk+Lje0WUpCj1MphY2+5cTzeYi8dnslKl Ksu0AfUyWNioOdarp8DhZX68TlP95IcjaFMP1p7Up4oRgyPbt3vRPDgU3LMxXyVZFsPrm8mUehet tQWZOviDkKz4+E+34Z1rOybo7Em7HVuFXZtB64Cu/BMn7E6dstu1WFBpW9C1dyw4ujfl+ol4Van3 wIZoSr0CR9aIwRxYAkp9p/ll2q/1U6B6WRxG2zowHkq9TTvyAsk54MYJKRodDMHGurS951sxOnVi U417j5ERVBYPzAml1Nu0Ex/kbudaAbRV61LSc6GBILr3gept3AW6njtnLwbuDCw1LbPb1KAzJ+22 bxZ2qA9vR3B/q5Mn7U6fttv5BZlxg7HkFTI5ZSgITaHUyxcyx4zjkVUH6zMukkqGtZ8YHKXhUL0M DuP0Gbu6PtDH7kPplRaRPlcaSz50O7DRxsvLq1I/xnuYo6XUa+fIbOAIw7yyP7uwxCjIXp1eAPWC 4fa0FUKQwVEtYF7SU2RZBTCpVMsB1cvA5q2xPbQODDOw0GcKKfmYKu9FBqVep3qcs2dB4dg18WUq pbqvZ0WqyYUMSr0CW8YZ0rVHS1j0+5fGqchquXuF8YZ26A/L9vgRO6rCyGUllWaH4p3mwKwq52GG V7Fgcogt2ylu5Mr38JBMGpzdbWx2+DWZci4mYGK5TzNiQMY5jMP7bT3BsJLFPPCLT256msIAq9Gc TYXg2Ha09bx+PC8fb7YOFGskBgdRMFUu7p4u7pibdc6uo+nSPMLT21NkTa0iYne2xZJ/GafOiO0c nO1srNYsirx4V7v4h5RTK4PMaQU14+hBkcjeGU9QYvvTQKG/dTq542ijmJeJmzfKwmJKJRt1u6BF 88JbD5vakvFPWCwFx237xf6e9q6Odn89TaLqpq2tjvLvH+jnH0ikPUz4M7SoIJ+oHeDDYlbRUOK4 kmxl58+2dvVwq9wPhu85B3u2uZvF7Tw5Xt7u00bLOg1IVj5WFql1Ij7HXsLEcvBc6IVx4oQ4/Bbx IEoGTo6etBPaWNuquV2HJYI7VaLR8DhWItPDsO+2igLc2R6eHrhK165zJJauyy+UC3XMPY+g65L1 oia1+d6e7iKsAMOSMTs2nw8bl2fHY5SgKtqyl0yz8vH1ZTIYf971SUtN4QhgO1Er0K9WIBH3Z9y9 N/ISORYQ4Fs688SNY0LTA0Gi27R88KddP6u5owWeXh6zZ2ItW4ZjabrM3AJ3Z3tlUpEp+4wzJ8Wu Hp6rxjOGrCxQphr0ldXaHetgT+DXgMtg8thVPHSUy3Rm86od4rpuHE931/atX+kwQqmU29k4ZF+L zyXFcviYndhe7OFiX1wEuh9NYF2OLdm2mpW0Zp+4tqONn6cL0C9WhCukBQ4ejsOmw6HNqP/ZDgjm enl5gpu+dE7WoAWZoMGVKbWa57AFdPBh794g9PTy5rCZr2LCgQ2oGjn5Ch+J7f3b5KrnIXEdscDb UwLK9vEjt+S0DLG48hEHRfUCJgxksTvYVF7/Ik5CIVl7chq58Xy84INi+7rgmK3Nx3PTc328nL/Z ABM9dKFQYO8K1EtexHD2gA1k3sMUWO9tmPP68f38fKAL6c4VMBjc0hRzeWQKtRgOk2IU8IHbsLb2 nmwttHN2FMGqM3+m68W7KXmPNRoDwTfdv30HRG4e3lZcFtGQP7h3bsgQASiUDcsT0mW4wUBoNQat GtcasJU76wQ6lGYwsLHf3uMGlVptMOBater+n9JvNytBUfQZ+OrO5YaqNBmVCzcx7/kl+Zb9iXKy 7W7b3yrI3rIwGSIrMkwNhmOMqmYwWoVxidlbyK5itI4l34R9DlfEbOfF9PX1Ap5sPMA0MpnQE5mZ eSI/N6EYBA+DOX5K7OLmUccDtC8y+05Wnh5utvBpp7HrK5ZrHGyszE/UA31Fvh7kLJHDtuJgKh2W Ki1Ku0J2j26cxn58Xy8P8qbA9sU5kM3lwsKfsQOW/Np1Nk5unkxKnAwGaJotMy6mMg5uGaM04wa1 ScAcGI6qwDiCnTWa7+3rQyWqQS3263h9sqwECJgwFcaXW0VCRzcBl2MuHnDLKi5CRabAwVen4VZu 3lW+sGAu385DBQ28BV7uruC2gp5EBxtSWIB9lsJWY+hcG3t7sZsLnGxzyNvjWotlRY4QqEbduxE3 0J7rA9VrhMA1mLK4GJQ0n9m/GdfXxziAfxMN+22eC4fPZX93FNacmYtsnN09F86KeRBqHC3+eEBs B4cxWGBtZlw0vnwi8CbzDZR98Y1Pm7pW/n5+VWWH4l+tQl/7Dd6GDu25IgdJWRcCZglkIBkWwOAm bInYqty1d87DEU9wK65AbFpsMC/zc7hmb1w+ZS4zks/Pg8EO6MqR2BkfErDJgaFWj6v0OJ9F3V6G gM21IpdbGRz24pV11WotaER+vSLTYmV48SoxMKTMEh2DyRIIyCUxobD/COemdXMGTkpX5ujyCuX5 kbDc3Rtzhg/JobTn7MNavkIoEfE8PMpUHQdSz9XPQLTGp8QMno1NVX6ePYSVwKs2R2DvXk7iSg3M ClVsg9aIHZxdbK1AFwRPC+IMXC51c42VXSZXYK5ioYtxCM2zFpTmlwwht0gXegs+tJu/2NrVXWJy IoMjMBaLjauM89Vajmwhv8onAk6OMEa8iqyzyVQVU5MdazZfIDL3l9QwJSVf3zYAS31C9XaMlh5s Z9u3L7AXF8C70cCLyXvrKAvDpg7muUP1lqLXGcz3KqQFx9XFuFTGNNU+yx5syhxrV0/PcmHG/ARf 8KrXlmsjdjRbRifBXLQbyBdwmDmpsP+/9kPxt1HGiW73IVaThvCFInsRH5bJ8gP1sya/CY2GGUmK Uc4dG+lSy/bymfIrZOWoVsA4Ts0ZbdiV98CZBTDPXAEmsi4XDgN03pixSBhsXnn1YqZqxWUxxGLT 6jGbW9GbESluIErXFTTkUIjPKq1DTLKecdlMLZjp8YxV1vLJAaiIVlawHjx81jAlNdPsgcEEvOWh gqu/cR1YWaLikd1LxkuoHC8/9qrVQqEV28XN3arCOiFVHQx5Bh0BmvnKqxXTWHkJdoUxdlpcSY6G GVxfUFAEM84WMp1E5ctHwIVOymJ4DHBm2NtCTbq4k94y9OZ5Oxd2h1i+VI1VCwPDqTwI+RiXY7yh XOqNJTKZpgURpo2DY2UBGKE86fJxHYFVHMxSN0VHdchCho3Asm5AJ28y7NAHsISb9OGDUZbl5Wpd Fe0CEK6cCE8m2tcpmxgcv3+/qFU7O05pATNt7JxYprRSwWkslnI5FkPwup5MLMLcdxsHEQEiNq/M 7Sq91knIFNiUtoz3b8BctApiguE0hwtCIZ5FwQl237GC0b15VtY2ri6lj2yYfM7eE03ysjNL5Jo9 u4pv/qXPiS/eeydjWqfqXoKsbhEL1+PU8ItTxRhwZH9YV8LDS1810OfCcQLTjkkNG8nLCWMrXpa6 raD80gst38+A3rRgTmghPIHQqFICLxWwqxP0cD+69H2a/QfgFMiqMVfAe9sjPgbH24QXmKmAftMN Nsapd+KDg0Mvh1fyztmvuxLJC0GemGxTo3H2nN3mDaI6gX4+3l5AvYQBX7852bJyeQUaveJVv4gh EFMzBOyHU+YpH3xuvHzm64EjYqaPj8qRazq3gxLKjtWag8GLycVeFoNLFnJOOizmQBFGjWnFnsb3 jVSmd6GCyeLPKyqTDq3KOBAxqLRK0uhtx/CtD5NzP7bUJ4/saXOj9AR8YmGMn8Wqrtr41eO+NeP2 LuSII1tn2VFHkOspTuRglSoWFxFTaJoB4izoU67ClZpKViJDyIeIR74rtnTLTy5u3uLFFwsSt50s 81YJ2zwcZzBsyAaqEA6FjJbZstJ0NwiGecmKtQyVwbMq3yHhhMGpHrR8HadnmQLPfJCeRhrcrOAr BCwyS1O/tT171m7KcDc/Pz9KvdH3018klg4KnSRuvrV9129ttGIafHS3f2OBrto3eapdhTa14ZZj 2hu/pX/e/xWo6w/ziWYzA4FN8jPNzrM50E2lChkAS6rHUIGVA5whtKgLUz1hdo758gOb4tq0Dssy YIGfw0FI6lNtXK7x2UPoJTK/ekJdUlCahsoa3Cnd4O3fv7own+yK/zqVfPQyHKtsnsqzrmKw8FZy Y2EHtWJS1L3oUg3jWt2kz1+tOwedFq8XiYQCn5bGAf+yfYSvjw+1dqqVKdu2e3n+tPTco7TSEN/l bR8Gc/1oWIOuHc0fMSkm/GXBqrnRbVuHXXkK7yjPjaPIy67dDxaULMPw1cZkMjJtN3IduE4fAV8M n6km5ZoCIxPDsjHeLLnCOM9s2xHqPDwVt+y9zvxepFDh+SnFnTu9hucSNp9jHdwVVqnbm8F82dg4 ntkSD/8U6VUaFdPGWHFnf1P6pGTGpMg27V6UaRzeIeMCJ+OoeNpXZInh+IBuYSBK+zpcnsV4TSRi cEzdoXdbmNn8RINGVck7rVPWk0NNDd661Ytf/8j//Wxq/97hPQbHUa4dm2CaKlRgZQPDfxULw+xK thXrVxaby+nb47BePXmkUZsvt2WyLIZ+1PPxXD1h3wzOe6UR2t/vw8W5vIicAfOM1Z5HvgI0vh/0 e/BbOSH0dHUyPlc/sjFm9PycKUNfX98ZCzR16LrMHPLNG6QumJi+moaw+iG0RmG8FfNmZ+Rnp5Z7 q/few4TWfWsNacQ7H645sTEd/KPsBa6s8V04EiGsRjv3BzVv+0aWqgWJ43AYOlMNeh2V6FLPr54n KyLNMLFPtIMzqyDPYB7FzPyf7MY5D0qIyhJq5ZDQWzzJCZkf4HImNEdH9GgdarbsMFzAZfH+3ttS FjSbVE9wOEypwxaMLv+kDjB0sk0zH66dEI6OLuz1HDQtLfZPGfVU0IytB7u5S+k6Z2qssVnV6HAb TpXNSsf59YbEvTn/RBMXXjJpcukDg8nzbLq15Xr6eIG7v3ycaPXRovtnpcFnpZQrR8hcNYorIWcf Pi5Yeg4Wmk3Uo9Y7TNVLowQ1AA7+/VoJsNvyiFiDTk+YW+Kf9knBP3N0BzbYODk72LiDdML5Rdd2 4Q4OLKm0VIvHLuQunmJ7+1LtkL5xcQ9Kyt3QqNikVkG+lDkxEooBJwiNHhdU6Kt11PyHwbh6zL3n 2IzkUIVlMX7/P2tHJ9iIBDXhYqEquaz0rjOF5FQLJ/QKGeYgKBcsmEBfOuXXd2QiGDZ+tyTFbG3j yd63QWjn6AgGvUmxML/2LcBMq3SYFijipOZrY0O1WG9s3fX6wW3eyLP1zVuE2dkwCouNytHnGxKz cuu6k8PdYpCkUkX52GPhBVhGEbBkfDdPvHS7bP2XKesxYwK8RFhqkXFk1GWaf8PrL16l4sN6lj7s pZixzDaWXH3Y9U3Crm/KOG1ZY82s9l286vorvq2x3mWkG8zqZVkxWrTmbtotGtqADQYdiw/WnzWs 9BWogIacw9ttHSXGUTuDx3t8t06jIBgMdbOdvVlrdohqC+Gi4tFfGrcLhrVNmgvV26Ql98Bu2AYW JWpkpt6Dy4dl7dKEW26WePlxo8aBpTa9RgtmD7LysVyBrHpCXSkMFuPeoyaD+vDElnWDhbVoxz15 zm5EP5Gvn/Hponcz5/t/ejdvVFo3fQLYX6wQHthi6+xaurZh5wqz5tmCy6tavRSLf6y/d719/SCW rz+rbn32sDGCc+fs+nez9/PzpdZe+82ptWqGrdm/VwD7xEGRyMmNGq31Gg27JjcbhsFY243322Aw lqFHfeghL9Gg15a2L7X8mHwrBl/AaNaKe/qMncTZ0QYM55nMxw8bN6wNyxyol8HGOnXj7/0OdokR MRqVHhe62j647usrIeex5A2tVZ+z74jYzWLi5+AOM+7VhMuzGA2xBPxhvUTDplszTcXmVFdydL2z wPTkW+TC3HVI7OpkZ82FHnxawefADk5Mi8mpsbMhiMq7eNcAu4d3g9q34bi7MX19WW3acXcdFB/a Kvby8XGyg6VXp6XEx4e5cjqfwy3tQhfMhxEZWJgSTOa4vMsnPN0cGKCZAOrl2DDGzrEe3w96vhsF 1+cFXMzWmWn57pM3OV9Qa+FkuscY/3MHJfXrsNw8mE1bcI6ctLMyNlZGz4d+brJkhrWz8fkuxrVi tO7IO3HOrluwzZztjcYPsLKymP8JHZlfrrT1sOXwqn4NC3vrm1jgNp07Gy8QMl0kLAcxaAsYbDab yxM4OTlY9nWqElleQREICQwvXN3c2RX6wdysDCXZ9LJYLHtniTWvtASLpXlFShW8ls1xc3NlGPQp qWl2Eg+RldGPXiFNyy2WeHhbVVBCbnaGSq0DJcThWblJStcDCIM6OTWLL3Rydaxydbcq9FpVTq7U gMM2BczeOTy+xMWp0jawsCBXARoaeH8YDk4uVrzywxl5QXZ+sdrH2+cd3meGC/eygkKCwRBY2/B5 lTQ/enVJZq4UFhST5ezqZikPWW6GXEN4enpQp9tmR9zJ0G3ZbOfnZ3yeEf8mkSHAQPtipdG06gpH 4Od+9bTlYVqdgcVmOzuXz2BedpZaCwXK5oKCddIpi9JzCl29fPimupSVka7RwUYdXC5xdeOU7WmL pNmFcrWPj0+5LOAGA5NVpjriem1GVjaOEwwm087RRWhVmnF5YZ6sRGPOFMSgTkrN5PJt3V2rW0VT K+VKtY7F5tjaCsvlCxRyoazE3s7W0rIwP6eoRO3l4800pSkrK0cH3zxhWIvsHEQ2RflZhSVaH/hw yJCWlil2dBVald7rlORkkHxf87tfBFFQIMUxhp2dfcsWYaB6nP/J0de79N0SggzfgOMMst66OJW+ W6pVleRKCw2gJSYIUFAisaNIWMkCsCVvFTCClmhUKi7oYSs0HHpZCSXgny76+biVfwcY8R5RJOR0 HJYucGcf3+nq7fmhPur+1D8nRPwzeFaVqBfxQdHrLfpCtab3WLgq1KYLX2Bf5QcY/55P/XNCxAeC RYdP6mhEws8xw9aWf2mZJWJO7cN1Kv+WxPsE9cD/LRjG17MYrGqXRhB/F/++3nVqsczrErZ2jHa9 eaf3ixycq3rF/f2A5sD/OfQ6VVp6tqPE3XLFCPE+IPJyclQa4+NDK4Gtk6P4Q0eJBIxA0Bg0hEYg aAwSMAJBY5CAEQgagwSMQNAYJGAEgsYgASMQNAYJGIGgMUjACASNQQJGIGgMEjACQWOQgBEIGoME jEDQGCRgBILGIAEjEDQGCRiBoDFIwAgEjUECRiBoDBIwAkFjkIARCBqDBIxA0BgkYASCxiABIxA0 BgkYgaAxSMAfhO7tm/8VkfN2f++DqSPGfpyIEJ8gNSzg8D8PBdfzYZAE1G+yctOZGkmGNOGpt7dP ZnElP/3+z7h1//nFy08rd8PzOQzGvpsJZovBTX0ZYq/KPb8VTer+M8d/SVT+w8tNDG3fsNOk9f8y EMTHpyYFvHZa08afTQqNzB06fHi/Xt0z41+u+mqEe+0xHzxifTZoL/4qKP21a5W8ODU1RaWr/Jej /0kMVTsd6dsOuO7YucVsc+FFMlaUll3NNdXAcwGH52GZ/+jiUl5EJiXHxvzLQBA1AFFDvDyyGMTu 4t7X0nJu30bAUo1/4Lh1WSCWXa9kHy4GEP7C9RcrdbK1pn6U3s94rjF2xaffFPyjqNTw2oiif5jQ aslMjotNyaHMGq3uQ0SB+JfUVA9saDseDtiy0y9a2m45fAwcdz8vjDg8hQF/35Y4vWvbvP+t1BrK /IDTlUNbgGuXzycXGn9HCnt94+TRy2HA/9rZQ4DTgp8emz1vWDiFIZFsO3KJOoWDdY4rMMxsKAbG vrO3ArNeXXTszG3zJYRBu2bRnBEjJubLtWZL4HnvtbhXfxykBvw6c4pw3bxR/RkBAccv3X+HjOs1 CmqgnkidX17UjDKcPPPY0t/6BRNALONmrNLgZa5vGegK7H2HTrO0ZHPhbwGvWrFs6+6ycxCNbFjr psKmLR68STXnotGUXzFFHJULmSnwi2eOKSzGH1O7ewNXN5/ajZs0AacZf27lcTnAcGI5TFVCbkl2 4nN/BqPFsMXvkGXEh+T9twlaTbvmz5s1e/4svco2W5bwM4h6x9XX5R30ucB+wPbwXxa3KpfO+EIq NJ1TWfvH2QpgO+mzuhyB0MK6DrAsiPzD8keuWbbOOK4qF2yt/suAzyuH5oPBqJbs+d9c+tHSw9Xo QippwOwscTfb91nxM7AMPbXd0rNVnc5mz2vOhVZSNiX5wKlLh/bgGCWHNpj5YFwAACAASURBVEIB F6TCB8Oadh1m8lUkKJvILC1lb/DgwB8Hrd3AExwZHIEeWsIeeML8OWbPjfvOpHzv+LyHZSD2n39L JYzHczKXin/bAeYEf735NjAUJt03urrVnjUMpNNajxN/rOkDLBZ97o5VYML+B+9SKRAfiPcv4Nyw HKBe8G/Y+ryq/BwYAmduckN5e31hNLDfHi57uG0YMDTpMR/0vYRGCswDF2wEHu7smQHMoYlQVI9+ 2g3MG+6nAvPokEBg7jDxWxwnlrcPxrBAQienaphMCas/iM/Fc6ApHjj7HbEnwhzv0a+6YhwrauQO r7FzUwJx4Cova8yx/VDCbI9hfZcfNJpt+xEqOPO0k7hTHkQY1m34KrPn9efDK2Y84R5sHZ4lxsGq v+uxXlkADOO/Pza8hSPfpyXlZ0SbOhgmkZHNyc6544CHexkqYL65vjUw34/PhwWlUd558Ir0DgUM mq6g/gv1BnxI9yaYMBhaF0cB+1b9RwEjrpUB8+bfnppzgbUdB0KfNSoE49YqTfAvMMHru0L3jCIl MGvk0lNnbgPD090zqOu2n3oxyxv+4O3q/aD9Irtsp9FV3WXER+BDzIH1A3uGBTcPTSvSV+VjNFkb Kto/PbsK2KdoidizXwGD2mQf6CbCag0mqPoXMC38/i++TjbA6Fm/s56UHRAw17425Tkn/Mb3O4+/ vrIPeEgs0lCWsEdpuMAUHhzEjtj1yhzv3mnt2HwbYJC9OQecTr0y9rprR/Q0T1apXoky94Tmjqfn DwZ/CkzNEDD3n7bPbK5UwOP84ZUqHHqo067Xq9+WAcOrLOW6eYNA/22+dtamS5dP76A00677bNIa DnZFdReUD1GdAuytxL7U2Z4x/agEL/AwRgTQK+EDrUM3o0y54GvIUtszYzgoQnPgPz/LBKbTXzWh 4pX41f3trzdUsClX4JLbpCWw8Toz2ct872a4V34fER+Nmin9XX35WGWLVS2ALVsMDOq4C8CoMNk3 qCUpFTClJO9acVmlq1BAwJ4t+lkG9cdu0AQIdKYoGmGY17iDZlcQQu+Nj82nX7XFWKSAqZqqNNnv GdPfJGBYxRfuvmy+HAh42eedQKjmQEC9HrnputnDul8rCphaaIYZHNEaDJM9fEwNWfTVNcCQozcH Dglq0FShNTWC+hJgcytOWj5ILRTwsfAiU4L7UQEGwwBCjH508Nrfw9OoXPi3mERZzxwdYhIw9HDy QSZlH3XvUoP69WzIn/9e80tiuWI5PSPALNo/VsGmrMJACvHxqJlFrFFbzoPjxBW7LC1PTRn+FMMa zN8P6wT5ICbf9Fw2KyFHIimd4uYWlmQkx9WSgEEr9te1u5VGYevgCqqc3rT6BWbO+jvhlh7u331j NuuUGJOcLtsF+IJjXJHR/npCOOZGPaFVgP/d2rWk7AeTAThY22JYWmmMGFYSTi1NQT3U8XItlyRN HnxO89nqX8BxbLcpGJaeDE5XXgengR1HgeOkbQ8pn3U79lGqtVGvQgUcFjh9+hyMh2FGZCodVhlW AuO81bziBYe5mKlkmDCQrGwwp4Brcj1mLaCsm4skYLBMFQD4L7RiU/ZB7fu8ev2mWAHXCzbP6gSO ES9vwVhI1za9RoCjmjTX79IdHOX/7AEY4r1QQw0H7uYI5efkX+/Xa3fDn9/p1LQOPK3bkXJWxJ0F p/WatPhy6eo6XmJgPn47AdifWdUXmFu0mZGWmfPs3rVGgVBdGSX6ij1wSUYYcKrdpBXoH55fPQrM DJatuUMGp6I+B8yeD83vSg2hqekxz1r44HXUoD4dgXnpkSekPZxR34wyPunZ3hYWXeazQ+DYsf9I YHP1wGpgZgvqmT1fDMstl+e4O0eA/Y3kYmDWF8VS5Z9TojUnydbZAxhCmsBMjZ60LT8///L5w64i G+o2+ZD+d199olPLx7duxmByVQZjD3w+rpgKJOaXb8EpGJkk/AQaCGzR5qMEbvhxyQRg5jsNpSbM 887EUp7vbpsOTlWm2C88yTAo4Ky+w6zlEVGx5w9tA2Z7NzjEuEEuYlFXaVPgen4muaRYkn4PmKPz zXMdxMemJicw25dPtWxK2g6dah6MUQI2883+6yYXw6qF48z2fGvb07fhPA0I2K1F33Lhb5kz1Ozz 8xFw3n2DXAEiyPra5ItrZp83d87mWRvXkFIfXTNf1aFP6ZwTnJ74K4kyx52A8gDT6wX9Opg9jxwG xttYItQj7K7vJRaXS8/Ts1AScrVxVAw6aIG9q9l1XD3gaKOBTYxmTJ/G5mC9AoOfJ8K2wKBT1BaW rk9PWLyGgMv2z4G50DTQNhS/BqdnY+HkI8TF3uSXM2MwXACT6mEuuiz7g/Kc9xwWMpVKMHz4K6GI MKjb+lgWvG1MARRnyo2NZqkTyghgfpQFz7RKuKh+KSyz+huN+HDU/AqEQi4vKiopb0kKOEXzroHo VfJiZeVrZnq90V4hK10V1yje8uZDiUpjwKt7oSQlPb9iFEUFFeaoZcnJrXJlXqcquvkwoirX0rjU SrlCXo0HeVGZhkNvMLaKefmFFT2npGdXGkiJXK7WVbUGaejYoaPM5Hjtt0tVrlUiPjwMwmLV5NNB GX/OuvawPAPhiL62QCCq5pPWh/CTTh0CUfN8ohLh2cLnmKyaTgYC8YnziQ6hEQjEu/CJ9sAIBOJd QAJGIGgMEjACQWPoJGACxwm95tZT+CnPsA7+o7869O7XJtw6z7dviKb7iP9n0EPAxSkvXRgMJovF 5PC7tAwAOizISJRnyd89hMK8TI3qbfvOaAoHdWlMfenOYLHPPor/V4lGID48NBAwrswR+TTRSbxS 8ot/WgNf+v8HW1c5eDi+JRZdEYdv/yhR+SA8Pi87bfu6FRI763+UXgTi40EDAbOsJeBYkJXi5SAc tOQEQRDsCn7SkxKkcoWljaakYN68+dfuvaROpZlSs9OzM4sYni3KhXBnTR89hmUkxbZp6O/o4jH3 q2Udg+DnRNGvjB8tFWenUw2HTqMuNH1/o1UU/XnnTkxqnmVQhakxt+/cyZUbd/+4v65vk9l7gSE3 O/uf5B+BqIYafpXzbbz6E25hEZerKGff1Q/rN2obAXeeOGfOS2CLLpSrNOqORRb5wObZuS0Y3wEn iBc/fwesmoesLhfg832wbw+s22D30dMPQs3f+sMPA+PJt/hZGDZq9V5g+KIxD8PgrheLZw62iEVE vTldy0dSatV4ELAZR35OZIIRVYi+3UG8N2pYwLhas+R/cVMnR8yYGfXN0oTzV8vvFFkLVvouFS8E Ah608DSBa/gshnuLgQaCuHd+KxhQqMgvBv3ssFotp1I+7z+GaoQCFjje3r0IBNe4w+RK07Jz0yp/ sXnYzLzwLI7aNeb4qyJDPvxuDgsaQZDvvUw/FUMQhcCw/5cocOH62fBTp2IDEXPtCIbxcqFC9Z83 CsJs4deFU0TwS+ZLd6NBaPWByW3c+yo9BKKGBayTlQz8/NW0GVGTJ0cMHvzq273lP44BFf77p5Xs twqEPWrdzeIM+GlbopTs03DYW6bI1frCUGDIL/uNDBSwicic8h8/lcOgUzclN4sBjYEYwwZtuDsl CHOvA/eaMZQkgSO4PubMlxjmcWzjcirMg7/DLexWjw72Dui7fCb85N3WxTs0AbZHx0aIMKwTFfLd H8d/+qMeBI2oOJ38qLBF1j9faFC9n6wc0NfZUea0mHCNfe1aTgLqNWmtBu6d4SiidlqGu1FwmYz8 6Kegm3Mo+yK1XF6IMVl7r0dsGtikrksTAxFbdvZPlCg0NtZ86oTJ5v16ep1Xh/+B/rdvM37Eb1cv RGNvsm7XdxWHXj6DsZ1AN52Sko+56Kau2LLp9J0vh3ekLszOKU5R5+7+jfUwOqt1oMQifONOGiw2 52+WEAJRLTXdgryFxeTeF3H5cA48tlcQPOm0nyC3Avrf8efaYvhkaPcl+BnthU3zwHQXjKDxAtgD x5g++D1zCu7/enr7VIE93JLOoIU71zbvOcQylpgbx8HsVGraHEOvLuJC/cPdsDZ9M8ZcUODI5XL8 640H5sybsEvPMs1nzy1uKQiZsWl2T0wkMQc7oY11vZU3yR64LTzH1aR853+w0kL85/jUBQxGs5bN zaIfzlP2wLztegowrB1aulfW0hN/Ua6DOsNe3c3dk9oqCsyQ9y8bKHLxoFyv751VruUyaEqoEERO ztZWcO8nDs+qUA23jZFGXwanfTbAPVl7N3PlcrE/UoxbU7SpT34yZWOcNh+8GmYOx0ZktEwoUJMC NiMo1qJN4BDvjU9dwBSFubm5efmWNuFPH5o3tYx8fu/4gQOv4rMsPcS/eLBp0+brd59TvrSq4kSL XSyfv3xTMZak2Fendh3fc+BsYlaZjTVWLV9BGeTpEV8v+9HSSZqV8scfd56FvTFY7N4R/ybsr7/+ iopLoU5JAbdIiY95+aqSSBGIfwP6nPCDc3ykeOzp+gTxLj+8gkD8PWjwIgfdQQ0k4sNRw6vQ/wV6 f713uHvR2/0hEH8fNIRGIGgMGkIjEDQGCRiBoDFIwAgEjUECRiBoTM0IuDj1FsNE+25D8bdf8ZHQ 5TwGSYpTVeFaFD90+AhLm9l9uy86GfbP4nr10y4Gg63F/+0i4pmDu2TafxkGgrbUyOsj9zfBn7Gd M2fOhFHkJ7VMjlSh+9uh4KrGtQIzFNr3mDBVyhWQnDhl5a4D2sKvG39JMDobiuG3/hyxV+W+30bc vSPgcoXm3/20kDYVBNKy745/FQiCttRMD8zE4I9H79ix49CJ87qSHAzXdfvyxN8OBVe+jI85Gprx /tNXBbcewF2yli07RZ0+PX8EHHWy1H8WGocLP6L6t/0vx7MwL+vxxTn/MhgETan5OTDb2hkcQ5/H Wloqi4rU2up+N1qak6PTw6G3RqfPzsrSGd4yDNdrVBERkYZ/9dBbWUxF/Wwbdb755PW/dX1uemJc Svnmhs16x1tg6NSoqYr8fdBHd29lSUtH+WJHy+8WMY1COrJTAJgIDFoDP8O4tWtFrXrzyABURSrj L6br9eg3uf+/8CG69eUTIgYNjajmq5tt/fnmqJV58BP5UVsvazPh79Nf+HGeOW15VAiKOC7H+HWv fWAbaGOosL9krQHAuijlAZNp/K165+DSnwv+ZcNCs0ehg/EnedV5L83icWzYlbKkhtAJlW16o4o/ D72KMYxl/GAQdqDk94Fh5g1/DMUuotKf8O00bJb58qb2tmb7oWsvAJvkx6eBOf/NzzzTN8IRpp8N fXbh+9KscW0epJboS6Dyz1//xfw98VXyx1c16XeBOY2cRmhznvI5Fp9B204AluOaYiKPoK8bBFJ2 vkF1ze75f3/WgvjUeP8Czn2R06zZc/Bv1OYqfwv3Kx9YgY4ePTF1wnBoYnPlGkP6zT1UxVq4an1R /gtgSAFC0ispy2Pnr2+aOxIYDkfDL32LC6WxsXAKWqf/YWlBgVqtxTXGbesuXL67elJfWN3joSD0 xXAf6aCe8CvcuNBbDZu0w8H0WSujPJ+9eIvyfDIW/qyumhRwpVPgH/rDqv/DSvir9uDUUARTuPTI E3AcfiyK8tMv0AnDrB9FZug06vl9O2CmRmrZlB4wv49icdzw3cKx47dfJkwChk2If/Avv/8E/nrP OA3s817AlsLZu3a6tCg78ldg/u21lBIwwKVBiKwEfrQo6vED8FwU8Zs5wf7OsFk8egF+U7lteIeQ IXDPsHH1jXIdMmmbA2mo13n0i/twFrDuEvo6iva8fwErMmSUgH/8o8rfobbcDK7dZyMoS0rAUw89 Js9gHS3QExHXdwLDgxjjt4RkLzbaFAzc5qLn2nvUyS9bFoDTxCLjj4LbYJib9xfAMKZjYwyzK5eA GweXAc/hGcbfwhaCnlk0DRiSfl9XlYB9nawwzCkn9Hfg4Vaefm1/uLuAyjgmHwo8GNRpwLTnrxyl NGN832BgdvPpR10L+uruUzeXC/DN9X3kte7UOKM1hrl6wc26WvmKQESUH3kk3Lw+TU2YBawkv1vs ABM8wlxo1AfKnvC7Y9fZXy65/zLaHMt3Y1oB286D4FeQTYVY017G0gZan7LqaFU3CEEXPswqNI5X v7YKa2Ln78tZUnWxnOX5r0Mw8ot8ip7wyn6mM4OlgL8b0xSzcjB/lguquBupB3fQQ36xp1yw26e2 xDhWZs9dTXpIubKlCgHDOXbryesInJwI99zjzMOsgsYAh+nkjkAgqOI4OCXu0gyecq3tVpy8Y7xU 9QrYJBSXLxFqm67EErU5wa5ecK8PNob1mWncNFMZcxL4AT5KMl4Dw+Btd8wFSCX41rZR5kLLeHje 3aV0+2sd+Y0yFLCNcSeDrn5Y8z5GAQc6sIP6f1lJRhG04sMsYjEY3Lf+tq9S9y4hGcou0ybCg7Pp DCb+6tWn1AkOfDJKfcLekAHHjDgD82xUHytLuWCT4QFW/YyUv8CRXyEZ+vSfwXHM0H4Yg9wA5Or0 XA323Vo4XR/99RfgmKvQF2emA8PNUOze63S1vGDlSONGWaA0wMFVWHmJuPG5ZrNGfwscQaIFPHvK xsqjMQxcixUVwMBXjmhq9kwNUiwDdWs9OD07z6DXPTi5Bpxu+h1uLZSc+NzaxpghF6+AhBTjRMNO 4hp9KbzSJCFoRM2vQldPyyHwAcnqY7fB8fmZnTEYdi52WxkfJiV26jkYU0p3XIET41s7ViZh2L7b cMtINw/rH+YPMXoyFHdo30GPYR36jsZ0qg0/PaE8x4M5digcPCsKYLPCwMpz+uvJ4NijVW1wvEx2 eoBxfaCc6reDm2adefjGrU1vYGjTd0T7+u6kZrH2tdwd3b0xnj8wT1vyA3XV6z8Oj/j2WMWc1m2G yeRqkBuJBDt3YDVlmZkAF+cv30thkPl04lPb92F9odrvAINPvbbG61VJbdvBWTeTxW45CO4ZFJ1W gMFnbXpzwyZ29yiISaDMzcQOGH6vmpJH0IMa6fdhxK3Kb61e6RAajJObWaRW7Ni0fDhdNpnOdJb9 rJufcWFZllC+mhbBway+kYWNk3tbyvP1NX0qLZN+pDdq1VaW/oKMoA3lhOvIQbXPbGA+/v2QcnGt OR8G7JeO72xp6dlsCrA8vQ00CtZ60zj+6HegXeAodHjYvjWkL57Zv6Rxf3k6HEK/yTFO2rdPaIax rQyw0OAaAZj3a1J+LRf18+RC4HNGB1tM5ElddWz2KGqbe8C5uW1r6u4j3iM1cwtVhWkKbfk5ob4g 6rNuPSr1f2Ln8j59+6zbfbac/bQ+vZ6ml9nked+GhcDntiMXywatXDipX68+vdbuOGmxdxVxeOvX 5TxrClO27j1VMQGRF9f0nLrXfLpl6dIiVelDmF5d23WZfdgYlVb545Y1S5cuvXrvmWUI6ZEP+/Ts 2bt3/2exxr27cL0mOj7D7KEkK6bnwGHUbF+WkzB3Sv+BgwdLVbrs138Mm72KwDWfDxqiNW29Ffvo 1896DaTMOr2xJOU5KdPGjezVq9fIsUvMr6dlxT6cvu0MZb68ciJoMihzcdzVRk1aVswpgl6gD/oR CBrzqc+BEQhENSABIxA0BgkYgaAxSMAIBI1BAkYgaAwSMAJBY/6/CVinM9R0EhCIjwdtBGzQqcNf hEXHJVbjR5Efx+Wy5aSEs6Oebt19sCqfwHXj9t3vEq888/W4SV+aT2+d3dp34pJ3TXQVLJ8+sHXH kNHjp/yw5/yn/xR+0zdjGAxGrsUWAHqt8uWL0Jj4JEtv6qKMkaMmmvdViLx3qtPAGWbXAZ1bduza Y8K02b9ce1x9dEIGw0HS8dPZJu1Tp6bfJHknVo/vYJnm2FxVpd7kORHAVU6+mPTD7E5MgQNeqT/S lcERUK893f3xS7Fvk6qintsb7oOlMAVU630UWqAjJhDZubpQ3+diyflV7MH1YZhZG2u77No7elbk wl2Epqw3vZ2GG74Z3tzyXpg3M9sxGX53EZVjfDGuMemap6TeEoOb7jl5+TvZkb+66tJYXfXHatLY R8DL4DU3/1nu/mvQQMCLyarwPKXgrT4tBfzunF4yHcMcq3KlqunWF1Tsxt0fq/zQ+d0Iru3YY/pi Ar5NqeaR3xN98L0xdCpzW0Z+JNWzEj8GXcWSIzfyaGc+nU5mPyankgKgSmbZ5ZfkmbG/fpCYZ3al ylBbSI6h7CrsBGiRwie/roCNJvod5Xfg0xcwrAp1Zx6p1O3Qdwvq1qnTsNdU6tRSwOe3L9rwS4Q5 kMBaPk5OLvXqN6Q6DOC66twrQpPs7u7hbi8GV3l6uHt516oQg3E/EH6v3eAk+8ER6vRWdmlVP7x+ Qe3atevUq/8mDVbQ7g4Cm8knv5/du179+rvO3qkQIKR5gD0lYAgO96laesL44vSJ7yf716oVGFTn 1K1XZv9R93/y9XR3cnJyc5WkKQzR13Y5uQRTTne3zfdqafzE99yW2bX8/QOC6uz//akx9QUp9esF UV9FdFl87OJ3Cz08vamtfdzc3NpMhZ9kG/SaFsGNhVy4V49H066W6cSVcOuiZ7nmt83hp1oNF/xU WZ6Mu23xQr4DJ4WRf1Kn+27GUM4WjSAhi4fbAFE/1qwqTLdMoTFevRykZt/1yEpLD2HJpy9gYgD5 kZHYwblr955jJ8yUmxrmMS1h99Cmy2fgGNQPfgxkKeBZLYwbXAAa+jnz7d23bNpoY8Xr+fU+yhV+ EG8onjdrWqeWARjGnT177sKFS8tFLY+D+8J1beFLDZtn9W6FObcE5t6bjHpr29ALnM5dvLSNo5jy 85lpbNmskTs4nnpZycChlj02btFOyqyTwh1//nf8OTCvH9gOmOd89fX4IV2AgdLNxq/gRkIDpnzz +yW4e06EVLN/xURMXJu6fOfovph3CDAcHN0VuM788n+TR3Q3XUttfGe7fN3WPq4Y1uLLxJuXpk0e W8sJWErmz/9i57kblCbJLKxYPaUf5tzYMp0R1w9gGMdyb7NuAdCzg4t7tx69xk2cXWJyUmU+A/ZD utShCmHHF0MwoTcwt//iJOmuhq1evrHVe/HTLnBaVFkKzRGJbPhO3VdVUysQFDUsYFWWcf8d6t/M ZamVeot4enP2+PGDP+9L1bbQxEJV1nNg+PFWEnDN+msXVW+K0kPNw9HWGOY1HrbouU/grjS5ZXeP Bq6iwQco8/MTX1c1hF47oieGCR+TW8ypccIew0YtPjlNYhyCPt0L9+UJzYEz2EUNA7E6g4FhEnS1 05HDwT5u1s4enYFBr9OpVcpimUxaAD/xc8Gwzj3nbtu88bN29cjxpD9Is0GTD4y3Y6Ulhen9W8L9 t8it8uBqzvCvtsBA1ApgjizQbPjfCMdaxh54VP9WXm2HGnRwi69LYekKWeaQDo2MAlZFA8Pm42fS 84stM7WsrcUQWge/7/96+57o1KyK2b++bzFT4FhuHeH1oz+mjx8/aEAv6l4kF8D1iLNr54Detyj6 LOxa9XAXlOB+6xbDFoz8TlOfC0zf7dixaf13Xm5wrwJxY3LLwSpSCNg/UGS8FlEtNd4DG3bsTH74 VHrrVvb+/UmPo966nAN7DK/B39/fPxP0BCZLONAF9Sg3GnaYVDvfio0FLLsEDH06N67XY3q5UICr y8ILlDnn6QWsinWp5m5YQOeRJRmwY38ZdR8c4xXEncOzKP/j+rW0b9id8rkACDhgEDCsgFNM46Y/ P64eKZbAb3FtTN0ylycAHVrp/pQY9uWmE5RnWeIT0N2F2MGe3N5JklFM9m4quD8BVbv1argFh1RH rF80yFLAfh1HyTOgt8/cXGBr4OiSLDP2dW6S0h12zB8en/+6p2V+vT3dzRsYqPRl1Hp6+1SBvVvV 9wKuCPhNPARM/QMw54BgvQam8OxduKvJyyIi4epSjNxsSFcQbZFj7OSNF+Yg3CVOFVMIODYCCLhz 1VEjjNT4YyTmnFnerZvbh4S4TJ7s0zLIqpyzqjhdUcYC/iJ5amYOl8c07ukKUMOt1cvtg8PVY+1r wQ00cIM+MNAZq+AaEhj01sQ9y8RC+k+2doPhNK4Dxrdu/gKsfnv46ypZCr2ewbAWGKNtGcLDOOV3 8sh6+ZLa5rYYh4Di1qgVHCbMw9fHHj/4/Qhw2rxw9OxNcIMOZUkxGD3cLpTlyBTS3Cw3Ibw1hBq2 TdSmOzpVMjiCyxs4+krlJZYRqZVycLyRmZNVUFKQl+0tMu60k5GVh+OG7EQ4vj14NaLSPCanpoO0 KUpygLnn5xstnfwldZVqjflBlywvUVnmUlj+iSlwr5/fYrHa3RayuAJ7K2xYx/agCWpki3m0mwqc Xuao2NawVSrWafavhg+WRnUPPv8ihwoiPSu30hQWlIBoNZUmGFGGmm5B3sJC8nHEy8RsAi54ZLVo CFV3NypbVwK3huk9fItGKZPYWmMNhwEPEddWm3PUAXTUw+EQ+swiMCcUPEvJA739/H7dm87bS7mK +hiH0FX1wIa8BzCudDhE7EOW1fAVcG9HXAPHq5uuhv6xHio5SQa7yu5NvalAyB7Y8czlP098DTcD mrDhScWQQUe55AhcZwKNy+zOcB/pbpNWGFRwnNmo1VS1zqApKRzXJAjjCnCyl3PvOhrE0cTPnori zZV1QNRvkjITI183CXAHPbBBA3fPqd98gkpr0ChkM1vCUfTQXu0mLlmvVGuzEuCueouOGx8dWfbA Z3fObx7Ss0ihLpZmu4itmnTtY5nOpIc/gxZWY+oZJwZhLA4vMg0uLJfkpwXXhe1aVLbcUAB/HepC HBy2T/QCc1mswwhyyGPQgqZnNhhikENoauVaqyhoDZcUsK9PvhjWq93oL1dVTCHA1ppff9y2v1NT /qN86gLWlOQ18yltbvjWthcfJVFOp9ePMVnbZcnhHDf65hZz1Rzd0H3kLqN4+gWX7ma+5+JjyrX/ lgeUa/aTc5UKWBEHZ3TUE2fZa7g7ZLzUuGctDKjLCjA2bF7bOEb1UrMU1AAACw9JREFUaQy6HWz/ w6wVHUtT23Xw4orBAjz4xlUrir1r52IucFEq5t4Znmlndhs75xvhmcAy8u5Ri/EDOVfXyy1/i0FQ B25jkhV20ZrHpmx4AuHVsIx1i8dbttQFSuOzqnOLu5rz++DyXks/L7MUlunE1XnActfDdGOB5KfM nz+f8tmpUycfH58rz1KAvU4G1+GoJbfiGLizz5sMYzhBvpIB89YQ+iJzSVJ8NX0w1qA3SGGPHj2o AFeuXGlOoVaeDcYtx+/GVlp6CEv+MztyEDi5tVvlUwa9Vs/msiva63QGDqey3SR1hSpCaFX2Etyg Y7I4KzsxVt0Fc+Df3kOay7L7c8bMpCXEizVlbA2qIiUhEgqquKhSQLPNqGTnvsoYH+R8NCZPrtLb 8FnYvHnYN99gX36JNW+OOTtjERFYgwbYzZvYxInwmJaGbdqETZ+ONWqEBQZiT59C18eP8T59mI8f Q9fdu7FJk7A6daDr7dtYhw7YvXtYSAgWE4NFRWEHD2IzZkA/GDapg9uhv7I0OMF9t0T+l/nPCPhj 8eEE3JvBSJly8M2+ie895OowaOy5VoU4oSL3gv8IdGMwbjBY4TklDZ0+ToT0psYXsf6/8U67Xf8j roB5u0Tydn/vFxavQK+9cfUa9+1e3w8b7twsKEbqfVdQD/yekeenpqlEdcmfOXm/aEoKWQIxm4mG lYhSkIARCBqDhtAIBI1BAkYgaAwSMAJBY5CAEQgagwSMQNAYJGAEgsYgASMQNAYJGIGgMUjACASN QQJGIGgMEjACQWOQgBEIGoMEjEDQGCRgBILGIAEjEDQGCRiBoDFIwAgEjUECRiBoDBIwAkFjkIAR CBqDBIxA0BgkYASCxiABIxA0BgkYgaAxSMAIBI1BAkYgaAwSMAJBY5CAEQgagwSMQNAYJGAEgsYg ASMQNAYJGIGgMUjACASNQQJGIGgMEjACQWOQgBEIGoMEjEDQGCRgBILGIAEjEDQGCRiBoDFIwAgE jUECRiBoDBIwAkFjkIARCBqDBIxA0BgkYASCxiABIxA0BgkYgaAxSMAIBI1BAkYgaAwSMAJBY5CA EQgagwSMQNAYJGAEgsYgASMQNAYJGIGgMUjACASNQQJGIGgMEjACQWOQgBEIGoMEjEDQGCRgBILG IAEjEDQGCRiBoDFIwAgEjUECRiBoDBIwAkFjkIARCBqDBIxA0BgkYASCxiABIxA0BgkYgaAxSMAI BI1BAkYgaAwSMAJBY5CAEQgagwSMQNAYJGAEgsYgASMQNAYJGIGgMbQXMF7TCXhfEASh0f2r3Oj0 RI1c+58FL3u7aqQE37OAtZl5SzYnA8OxKaHBwfBfptrwx+lkYNh4vnBsz7BuXcIWH8g1+tYo2rYL ax0cKlXihF7frXVoy5ahE1emHhsXGtIl7LMuYUceyCiP7YNfgLKSJxcNXZRmGZ06X9VuwhvzqSwx T66hk6L3TTSW0rLlEZ/1fDnk8/BZE8MoG/Dv6ZOkjp3DuncL27Anm/Lfo1NYj6ERWQV6cwi6bOnu K5mUuUurl7d3Je29KXtrvCFtjbEYTJWuW6uXunIVEMc/Cw5t1zo0PFczaXh4l85h07Zlxt/ObN8J XPtCI1e3aBka3CJMh/+3lK8q1vZsF9qq/Usdru+5IGL51PBUhQ7Y65Iyd/6UXM5zUnhecNsXVI2M uJIa3O7ley+s9yxg3EAIrGCCx+5v5uLIPH3F3za/cPvPxZdvBIztYFCribO/BL64mmWKnBEcYrV1 pf2eu8kjB72ZuU708FGTzN/zSnBsxES7xcs8x7YRUR4ZGAaqmkFH6GTy9h1e9vrspQHDNi56031Q jMSLlfkqNyQkPP61rO+YtJ5dX2Yo8An9X85anvx+s/YhmHqoqY2AAUrJgY19t8dj3+7aOw40efK4 gbAO99GjBvizkgFjbecucl841cV4AQPbtVrYt1t4mkrXs3d0wav0S2GK42uzu/Q1tmJWIkab+uwe vcI7dnyprropu32/SZAb8/LNoMEhrwwafael6cDyu/kR4Pj0ZIyGkjKT8cNx+xUj+TeepWY6sC// 0Tj0ZPbwRdmnLgQMb8ffuT3Bp6WNPUGkFGo+bBl9Ynwx8vWKw443fvc34AQHwwRClpsVe0Snl13H ZUtEjJ1Lo/t+HmH27FqLj7GMPfOE5XkY+/330u9ZwLJULSk3CPhjY8W18XCcP07w88mU3r3TpCXY yFGxa1bZmf1HhKq/3VwYe1Wfnmn4rJUPi8ksAUMRA8ZiaLVKmYxs2wAGMuMxUSVtB/BVSsPab22X L3sTz2Qe2u7esDG734zMBYO4j+TK3Utt5m+0O7coMltNPLldWFhNFf5UgGUFSonNYt64kHvzr/TE DBmLzVUV4RwOl81k8NgGpqY4t6jEfIGzt9vVg96Lv4pVCA0FCeoCqbLXBOHWBY7f/5EEXN9EadOz ZQXFhqUDmGExxq747PLoceOiDtwsok4JUJYMBvjDZbHScINKSxAKObD/rJX1mLnRs3YqZBqqh2d8 /VXRdRVzcgdXb18mn80EN4HBxiRigRWTISeIEqmGQ2BK9Uctrxrn+30BUfcUM4fFPUlTgtOEKM21 48mdlgjX9uHqs1Qn7yqzUtVJ6fmUZ761UCBisDBsQKcwoTMTU+IXX6neb3rY7zc40EmmxatXLY13 rc8vKiHWLUvzccDzONb8ElBrtAaC8dvFJlyGyTeB8bhMLyeWgq+vK2F/szIVy1EFdrMSpqlqN3Zp XVdsDtbJAdv2Q9rVY7nHLnqfwQovnFYL/Jhx13QHVXnpviyMTTx6hjNxfbtmHBaT4erI5ufjIXWY fNb7zdz7J/pmhkYLS8nLnvBwEwq5XC9XmGu9nKDanrp1bTs1dTX716iIP/7M/+VIdv85wi3/Kzp4 BQ9oxXn5QJd+M2fAIuFV2NJhBrne2Znt78MJy1NhdWBoQ1fW7lmiMDfWEbcSN17WZ+cRHA7HVonv 3JnhYIsVYljL4T5rN4d+NtfWxQZ0LRheLM8uwSUpjMuRWPQZ5Vp5vGcQpyVbt2Jd2r17ikmDrLI8 OALckJORg7l7f/SSqymIz0YlThpin5OvwouhSnEN5ujM3nW46IlC230UV4cx+n3GfS3n+ZK+717N 1BTi6WriwvU6JWptl/5JIX7vuQ9mEMT7DBFXa4+dTmrQVODhbKXW6fg8prWtODIsmy1kennYMnR6 kbMDm1Hq/2VYmqOE7ejkzOewIl+kl2B4UJCrKl6qcLL2kwgtAiauX0kKaGjl6+4c3Pzlzt1Odes6 M7Xq9HyFjTXTBuNkyNUqJdGkviQjR+rlIUmKzdSxMW8vV55lZJ8eBo0WJJjHYwr4ghPHMzAe1quf h7eLTbEs31bsqM0vTirWBPo5mf3LM/OO/yxt3kHQqJ5nUWp2rlzHEtuwtWqcifn7uSXGZfl4O8hV mozs4gaBkoTkXH8f10rjvXw2oUSMDenurytRvo7PL9ETnmKej79Ly5YvLl4NdHOwprxJc3MMZA1x cbR7E5nr6iFysBPGxmRYCVmebpLo1+k6DiOgFihk2i+FvjuFOdLXsXL/WnxXiSQVzC2E1piVtSY3 v5hJ8Dg8ayaRlqty87R3EAkwOJbU5uYXMlk8J0fYkubn5Dm4OL3fGvmeBfzBIfDuPcIvXWnMZX3S yqQles2cr+N/2FivptOB+BvQTcAQwjzNRrxvUNnSDDoKGIFAGPkPzV4QiP9/IAEjEDQGCRiBoDFI wAgEjUECRiBoDBIwAkFjkIARCBqDBIxA0Jj/A0QrXYPvcHjBAAAAAElFTkSuQmCC --Apple-Mail-102--974640808 Content-Disposition: inline; filename="Picture 9.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 9.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAUAAAADwCAIAAAD+Tyo8AAAABGdBTUEAANkDQtZPoQAADzZpQ0NQ Q29sb3IgTENEAAB4nJWXCTxUX/vAz52VwVhCQgwhighZy0627HtFzDC2YYxdtkREEbIUiVIqWdpR IUIlLbaSImuRJEt2896hfr/f/30/7+f9/M/nM/d+73Oe8zznnufMee4DACfBlUr1RQAAKH5BNKv9 OgQHRycCtgegARtgAoqAzZUYSNW2sDAF/7X96gYQ494hw7BFOVbfGv36gvAlyiiCR0b3yH8ft97w NNghAJA0zNzkDdZisNsG2zA4NIgaBLMng4meriSYI2GWptlY6cJ8jWGHvMFVDHbb4GcMDiGSGWPf A4Dh8iN5+QGAnYBZg+QeSIS7GX5JpEAiBeYzACB0KBR/2D5HJyyXJFJp8FiOFZjFGOuyMWX3AADU dgPAnP23zBueawUNAP7Fv2XbWQDgDQWg/B96M1brawXxvg70UJBfF0GsOgCg++j0GQl4bhkArKbT 6cuX6PTVywAgPwJQ70sMpoX8Xi8IagPgfz1vvPPvhoQdMgIsAmhgAopD7EFCyFW0GMYb+4rZhQXN 2o1/ytHA9ZF7erPCFpJAydZxwk5RmliJxIAU+041mf2ySru3KmAVJ5XaVW6rndrrqCGiOapdoGul t2pwwVDZ6IWJo2mnma15g6W81TnrZVtHuxoHvKOLU+XB2cOKzjSXq0f63DiJBqRA9wseDeRRL5y3 lI+BrzMlxO+0fyG1IqCO9iZwIOhnCAjFhwmFy0UoHd1ydDKyISo7OiDGMFY0dvXYh7iHxwviYxO8 TlgnaibJnhRJ5k1hO4U+RT+9mrqWRk+HMpCZmLOYs8tZg9nNOaW5GedCz7vlWeZrXJApELrIUYgq XCiauPT5cldxy5Waq5UlF66dvh55w7fU/qZWmWQ5e/laJbiFvc1yB3+X7R7rfZYH2Af0qtnqsZq+ h28ePXlcWXuxLrk+9IlHg22j3tM9TeLNfC1szxDPFp6PvahvTXpp2oZve/3qzGvzN/g3z9/Gt2u2 L3ZUdHp0be3q6E55p/Nu4X1Zj9sHvg+ve0983Pdx9lNln3s/a/+5z2KfywZUB5oHbQaHhoKHscO5 I9Ij9aPWo6Nfwr+yfr04Jj/2dNx6fOhb0AR6IvO7yPeKSfXJph9WPz5PeU/N/IyYRkyfmuGdKZyV nC2fk5+790v216V5tnmP+doFlgX9heiFqoWfi6TFvqXOlai1FDqdsYNBJISAziC0kNzINfQ2zCFs NbM6rp01BU/kMOZS49bhdeKL4i8SbBGaFBHaZiJO2h4vdXZnoIzYrmdyAfL8Cg17vJTxKjfUdNQ/ 7KNorGgl6bDppuijDSL3fzGyM75nyn3Az6zRgtfS2+q29bztPrsQ+wqHIadNB/UOUQ7nOTe6jLpi 3MSIuiQX9zCPVPIVz0der70HfGYoTH5C/vJU44BDtJDAM0FFwUkh7qF7wzaHzYV3RNw6mh5JjbKL VosRikXFThzrjqs/XhqfnRB3wi/RKcnwpHKyeApXCv3Ut9NdqXVpl88kpvtmWGUqnxXOwmXNZPfl vMi9f674fHpeTL7vBccC/YvyhcJFuKJZeDe0Fd+9knc1vsTzmtN1jxtHS5Nuni8rLi+reFzZdOvl 7Vd33t7tvvf+fs+Dnqre6vc1PQ/7Hg08Hq39UTf3BDSwNQo83dEk27y1ebHl9bPi5xEvLFulXoKX 3W03Xx1/7fRG9i3y7bv20o6YTusu8a7Z7rp3p9879Uj0TH2o6o37aPgJ++l+H6mfs7/+s/+A8EDb YMSQ1NC74eMju0a6R6O+iH15/tVvjHOsctxy/Oe31IkdE83fXb8vT6b/kPzRMOUwNfEzZppr+tqM xkz7rNvsz7ljvzh+FcyLzecv8C0ULu5e7FxKXyavEFfj1/LoBLoDPY3esh5/HmAMzkEQFADNIVKR e1EA1YvuwPQyAWZpXChLC5s4Ppl9iTOAa4Tbkad1swpfMT9OgCxYK8QibEHIFenftl3MW/y6xJCk gJT5juidpdLtMr9keeXkd5vI2ymQFal7QpUilSNVIlTD1Wjqnnvd95E0PDQ9tFy0nXSsdE31tPUV DET2cxgCw0mjHuNGk3LT3AOxZh7m5hYqlmJWeKtF62GbN7a1dsX2EQ7GjjyOg063DsYeMj8seHjc ucbl5BE7V3HXWbcGYjrpiLu0+6JHMznd08VL2mvBu9HntK8dRYDS5XfCX86/hxoXIBHQRgsO5A+s C3IPZg6uCLENWQotCjMKmw7PizCMmDt6OdI6ChNVE02JEYvpjc06Zh3HHvfyeHK8XgJIqD1xNFE5 cSap4iQleUfyl5TiU26nhU73pualOZ0RONObnpfhnCmSOXz2WpZPtmIOIudt7sVz/ue18jbljeQ/ uJBS4HZRtZCzcLyo6VLR5bhi0hX9q9tLmEu+X+u4XnOjCN5lQWXO5UYVypXbbrHfBren7wzd7bnX dr/xwYOqu9WlNVceFj7Ke5xbm1OXWX/6SXJDYuOJp7FN4c3BLdRnHs89XkS0Zr4sabv/qub1kzdP 3ta3P+/o6vzUNfOO/71xz/EPzz4qfCrvNx5AD44OL31xG2f/Ljv1ZS5j+Qoj/hu5j9EwSgBkGQBg 9xoAq+sApJvBqY4D3iBwrrZgA8BGFSA+SgLEtTkABSr8lT/4gDw4ADxANMgG5aAZfAKzECskCqlB FpAnFAPlQOVQM9QPLSA4EJIIHcQhRAjiDKIU0YwYRNCRAkgVpC0yCJmJvIPsQM6geFDKKCdUFOoy 6jlqGi2I3o8ORF9Ev0QvYiQx9phETBVmDCuItcCewD7GzjJJM3kwXWLqYxZkPsicz9yP24bzwlXi Fll0WTJYBljlWBNYP7DJsZ1kG8Zr4wvxa+xH2Js5ZDjOcgJOKucAlw1X2ya9TXXce7mredR56nj3 87ZvPrz5G1/UFs4t1/l1+fsEogRFBJu2+gpxCT0SJhN4CE0iQaLiooPbmsVuixdJJG8PlyRL2e/Q 2yknTZBhkfm1a0D2hdyd3fnyxxUoirZ71JVElXHKsyp9qq1qteote3v3TWpCWlu0pXRUdQ/ouejT DBL25xqWGzUZfzJZPrDFbI+5s0WCZaXVBxtOW0O7BPunDqOO9IOEQ9qHPZ2zXOqPTLlJEEmkYvcR 8k7PEK8mH15ff0qTPz81KKA1UCIoNvhdqFzYyfCho7SobdGDsVfi/OLVT/Akzp3sSmk+XZVWkX41 syirJKfs3K28qguNFxuL+oszSg7e4LvZURF7W/Fu/4NzNTaPuev6Gx41nXkW3Up9dfRtcGf6u4cf PvUhB4yGS76e+J49F7youPRu+ftKz+rVtaL184MX7AYm6/HPAZXgGfgMFiBOSArShhzhMyUZugw9 hrqhKQQOIYbQQDgiguDo30Q8R4wiUUhRpBbSBRmDLEDWIwdRKNR2lDHKH5WNqkf9QAujLdHx6Afo bxgCxg5zCvMUs4JVwgZgy7ETTDuYvJlKmSaZdzOHMD/GoXHmuDzcVxYlliSWXtZdrCdY+9lU2bLZ 5vC2+Cp2fvZj7N847DgaOBU5S7gEubI2cWxK4WblTuHB82TxCvGWblbd/IzvIN/UlpP82/hrBQ4J rAkWbdXfOiaUKqws3EdIEVEU6RdN2eYspikuKYGXmN3eJ9kidXdH/s4k6RAZ4i5LWS052d2i8twK zIqQ4vyeH0rjyl9VxlQn1Wb3ovfxaezU1NJy0PbROaZ7Xu+W/kuDEUPISNhY08TVNOnATbNuC5Sl gtUR6xybdjsW+wMOYY7xTpkHSw/VHv7ovHKE11XN7QgxlfTYfZws6Gnllezd4AtRNPxC/e9Qp2iS gWQ4L/aEcoWZhCdE9Ee6Rc3HpB3bHlcX75CwmJh3Uj154FRq6t607+mFmfZZW7JHcsvPR+fbFsgX 4ovWiiWvulzLuNFUBlXo3Dp+58192aqMh4jH4fXYhrNNSi19LzLaXN4Ita90jb5/2lvWVz3QPNz/ Ne1bz2T+1JfpztnAuYX5u+vxFwfmIAwUghb4K5ILUoIOQbHQFagV+ongQ2giyIg0RDViGMmB1ED6 Ii8gX6EQ8D/cD3UNNYQWRRPRV9BfMTKYQMxDLBprhS3CTjPpM+UxzTAfYC7FseD8cJ0se1lusgqw prFh2GLZ1vCx7Aj2ZI7NHJc4ZTirufZzfdwUwM3CfYVHn+crb/pm9c2jfDlbTPgh/hqBEEFlwYWt D4WihPUILIRukYuiPtvMxPaJK0rs2C4quVVKcMfWnULS22V27VKTNZJz3E2VT1K4qti4Z1gZp6Ko SlTLU5/f56XxWYukPaJL04cMsg2ljZpNXEyXzNIsJC0fWZvYfLbzt19zTDjIdajQWcWl1ZXoRicV eWiRh7ySfRR8B/1SqKoBI4G5wfohc2HXIg5HoqKKY4xjJ+My4hUTPiYePymW3HzKJ5UtrSzdMGPg bHS2UM7Dc7bnf+anFuy82FDkemm5OOuqUkn7dXIp+ua5coWK1ltetxfuZt2XfvC0+nDN7KOUWsm6 50/Ijdinxc3mLYvPC1pN2xCvLrwReFvQsaOzrpv8nqmnutfnE76v/LP9wMQQZXh41PpL9Rj3uMW3 4xNl35sn3/7onGr+eW/6zIzvrPTst7mCX4a/pueTFgQXKhZlF28siS0VLCOWPZZfrOxaSVx5uyqw 6r5asbq0dmCtmi5Bz2DEf6NeWm84XX9ffxrBVFfvfxR3/99G8Q3+44ML/rH6uZmZ/+av1CALm/VT CIClwBBrffgO5yyIw8PLwOg3E0iueiYwC8IsF+Gpa8awAbOpB83AamMs5ODtamwBMx5mP3c/W+sN +1Ak1Xe9xmVwKjVIx2o94wGo0D1Q/49OVYSnjf3vsS9owVa261/VcG3p429i9dvXCsld7/fcEEx+ vmamG34RfF5BRuu1LMy7gAFwhasxMnAHMsAU6AK931cCLCfA5A/3uoNAWG94Xe+Plt36s9e/jZKB T2WGvZD1MT5gFGaKi1ccDbb1f60TYcvBwBfWCwY0uVK5MbmVv3QYXn3XPf+RmPyH5I+dv3W9AAm+ /9P+upzhnXLbIyTXP1zNzhMlgZJH7UHpoPahNFCqgIDiRfEDGZQiSgWljdJEqcN9qq8mHkz85Wdj fdz+ek+TP3OGr37/sWbEf8wGbNTv6985cAzy4xnUmLUQ++97Lcg9bL1G1vWnhtO8yJ5BBG0q1ddd mmDkR9wlTZCXk1MF/wKDW3gdwfXxVwAAAAlwSFlzAAALEwAACxMBAJqcGAAAACJ0RVh0U29mdHdh cmUAUXVpY2tUaW1lIDcuNiAoTWFjIE9TIFgpAD5Cch0AAAAHdElNRQfZBR0SCBRe184eAAAgAElE QVR4nO2dBVwUzRvH94qGO7obbBAUBAwUu8AO/raiYL52B3bna3c3vioqdmELSEp353Xf7v5375DX wNc6OFfm+9FldvbZmWfn9rcTO7tLQlEUAgAAxISsagcAAMDPAwQMABAYIGAAgMAAAQMABAYIGAAg MEDAAACBAQIGAAgMEDAAQGCAgAEAAgMEDAAQGCBgAIDAAAEDAAQGCBgAIDBAwAAAgQECBgAIDBAw AEBggIABAAIDBAwAEBggYACAwAABAwAEBggYACAwQMAAAIEBAgYACAwQcN0SH5bi4RH9JEmklNQ6 t4328IhTSlKAPwOqqh34c1gxLzUuVYySSChPWsRG775wM1CjPAzjY5uSkvPaNWtEJf1S+iiMcCXY X1lecbmNufFPpBD7svzMeRakQfLtxujTxYj8a/4AfgeAgJVA7qviQdOKPot8GZfXx9OeilSv/vr3 L0gUEg2CMAmLZPCP7rt3U/bRi1U1q48esFdCua4BZkeXW/6yXwBVAgT8q+RElQ+Wq1ddj/S/kZpm Wuj6LUJstbJCVkc5IjLpD9lPC4h+Jb+8NHalenvQZCIkPRXOyoV1KOxyloExQ7NOvATUC0DAv4SU LRgckocFdBiUowf19AxNjejaavHxax9JHW0oNWYUpQ41fNbyhRGU8vXW8N3jWQr1Hjihb6hDtbSy osm94XJYPL7QsN7Vi6IQCTTdlQcYxPolevVIVgSOHNSztLXH1IuF/de53rpm7mhqUGNmqI21fz/Z sbJUEBVVxeIiUG3EPizs1Cm2c5e4V0n8L7eqUWk14TG9YrzaxJR93cM9u5nYst0MPVNTIztbG9qH a4muHsPc3FyxUpxSlVLwUa0uFmUVfbQqk0bF8z5LNiqy9NChnKs3S5Ba+wYwcu1C/t692W/iOR9H 8zKLPD2jt19hyZOFc3P50h/uDQA+AdTAP09CWB5L3kw+e1HfzMJa/SONGphYKAIphdUxNdvenM2e uq2q5rRXN1CLvOvy8XV0WUh8RFS1fqaNScF2PXXfrSmjlktt0MB3SeV4SpWZ2SaO9rU6qdD625M8 vWGOtRqgMNxvZDZ2Ibn7qKmBrhYEw23aJWGrZyIaNTbWxQw6dkrgi9A1x216tsBHzl6czJ6x69/u 9JoVhea22uFhTWpiVoQk3IySKMJHj+KWgdNs5ozF9z29HV+NOJlzfh1co1x9B+17F//dHfBDgBr4 51mwsxxbunXXpNF0tDVotdrwhZ+slqdXTlGol0Jq3hxvY4urJKOWptcYvDmWqVDvtPk6ocu1m1lg wkcvX5EbINDH1dXM4e9i8/AKfPoKPW0N7a85uWSTGbaUsJDO7d55eERj/3r0iNu0o1Agqb6GkMjV TdrcMrxiZBZWtwoiHpTIM0WEItzSWpOLb81jKtTbuoP61BCtAf7q2L7FufxLr4oVqe1d8V6h3v5D NWfO1OroiR/jud15VRy8INRRPKuqgmr1mpvjq8ws/rIT+V8vZsB/AWrgn0UmKhPgfxcHadhbm3zD +EP92yswB1taN1ffukJbR1dXxpEEDCtOvc2pmCcwomuhMnjGHlxFS7bTvZoYWBgb9A2AcjPyYDJ+ wqMoWi1gBAnuFR2NXz2gyQt0O7lp21h+1QH3zpbhJ9B5q8vTMhFFc7eyUnbxdAn2b9Px5p1baGAK ptEgWAqVMMXY1mPzMxU7ZqZIMSWLWCK5nklaNC3sT7eBWdhy3Dy9vj4aVlZW3GLB7dspQinEYeNN fRRGjt7Ehbr7hL6Nka6FqXEz67Inb3FxspmVBnpW1rZk6DWe3Ni5ur3bqGElEHutavF+zuMzFdLR 1jTQN/5xgIB/krTr+Hmp50Cjqn17HEhPGz83heXVPckNK7Ss7OzVsNaPMaSlXiwQQ5nlbEzAKXey sSa5upOam7Umpl6Fsa2TzWepDRlUXd3N20j3ctSwtbb479zNm1udPm9VWV7KF4qxq0DqG/7KTVgI mj826cFzN7o6RVONJJKiJWV4f+BsRvVece9lHBGS+wAfomvWV1NHVxvmVTcnenlSDfXMgnrHJFTg q5o6ZD9nvClXFo8bN+muaWmoh/DUPfpEK+zb+2uSKXhVbO+Et1Oc26n7t9NRuN09iLF4f6ywCiko Ytpb6n+zJAGfAQT8k6TG4A1dRwuKtsG351SQKXgztSxPrFhT19BXI/+7Cau6Spn4VK1lK9nYctFU TWMLs+/xYdsKzqtnTt/psKGxqaE8YGsLdRkg6+Qdh8nx0LXcuUMdAh3Je+Ph3DS4qql8zMlCTatI IsiSibi8NVvwqrVvO5qOrk5RAj4e5txNY8YkVgmruhscvEi3szvVxBK/ylyXt67b2qCjBufxRNVN 9M276bYmFBtLcyxs3hKrxtkIAukYmX7wq3qsHhVjVzcg4B8G9IF/ElTe52WLEC2NLy6CUrhmjCrh o+jKCvmESkuqkcHnXVYjXXyPMnlr1dacrKNGgb6OngXlyGE9LACL0Knrs37CeQqV2rgJ7nZ5Kd5f 7TcRTy27Ar56IhcLHNigZWKMX1akUkG2vNXu6kDWpJIo8qlkWfdEJSzc0WlzdC5e1O/f2dTB3kFH HU9NWxs/nY4dFmHq1dQjrduihxl4uFg4ONhX97PlSzar1rH3H7u5DVAABPyT9ArGu51ZUZJKnvjj +N3rMjx8Yj3bJcLovzdYNDTwpbkF3o2ECqX/9vVQVCzGzQzlNbK8Tw0JJLWrF6m+LJAO76A7Nra7 uBl34E0Y89ant2o+ZvakpLlbP58ipiArA28wOzrjwjP0wluzGenw3hsSijpJX4Nka4pfn9JzuXJb soaaDu6AvA+NKTpkFi7dvj1MHBwcjPXpmDjfvcN9EEtwZRraUjb9TT95xNDbwwoz0NXWkgqlKVn/ juZJJJBEUD1MLWXLswCzOn8WIOCfhGZmZKaFn3b9uyYlpglYVeLXTyo9PKKPX8GbwRbNoUoWt8aY Kq+7zJvqyNfQy4/kN0JRdM+8BCkMqdOpajRc4vO64HJasJIt/aB9brlw7MC4N6n4NQKWVU/t0tJj 6GjSHPysu7bCZbZ8fIYErn2m5tMY0eNzxZsvlXwcWV4oaOcTzcF726SujeQXC7IGdh6IM6VqEOTQ U0vLwGKIN+7PlnV4p314qK6BIR0LWDXTrT4cBh1TppEB3uJFZPDo4XETJ6afja4YFmqHxVTkwqaW Fvb2tno6+OgAp1zk0yF+5ND3HH71lU7CR8uZUqwhzWeK+/dMw2JMHCgkqt5P/hINGxKK/vos3YaK VOTVNulL7fSfrvO/Dmo29vaYbDFJYzG7j+t7t3DAAnc2JSy5KPnMfsshRqvGtnpaVAiGPb1jFT8I jUaSftBx847qB7e0IAnFbX0TsZ/sxm17M6Pq7qJ3m2gZAjXpqXd6jfOXDs4eEfs09StTJcjQ/lP6 tqamxgy8PT+ib0xqCZ4dVrXa2zuQpHyPtikKw9Pn9J2dHBQ3uaPPpwRvqWVuCYkMXTivj6l6YO93 eWW1tJB1zClHd+qZQRq+Q4u/2Bm6eEHf1sHhv7oNgK8AauBfgKbx7GkLT6d/m39dAjSOn9Yf4adn L1dvDfQPA9U95rsEd/mkz7xmJ93OWBdXLwaF8uKJi6G8oV2j3lad1ZdOwet6rOOKr1t9svulHfhw lyxPLKytX7ntjNu88epfxvsN0zh7Vt/ayEihXoz5w/AKUM9S3tPFMlPTtlJ4bkhVo9Bqpqi0Ht7k 9F7Dz5Tm3Vv9xCl9LT0jLHzllvv8cRqfZRc0WwdTr6WNXS0u0kgHjjLUtPWBen8OUAP/OiiHzeZw eWQyWUsbv7tLJf97WURRJDMrR0ObbmVmWBPJKq+IS66iqZHMTCh6+oZG+vRP04Oz0wqSs0Wa2mQb S4qmtq6JkSFVPgUSkQhyC0rNrGw0Pxrl4jEryphcWwf7r2lAyOeVFJYXlctQBNUzoOhoknTp+gYG DMqnk5LPn81q7Q1ZWtlpyTvkYpboyNnsnj3Vre3saZ/2UWUScVlZGYsjwboG2D9dOoPBoNM+mvCN 5VhUVA4jCBm7IFAoWGZ0PV0sCUFWEVYD6znRjm0xJiESBEEoVHVDQ0MtzVquMoDvAQgY8B9gkicp cYCpWsCOtDN7nc0NwVNQSgA0oQH/gTLVWwOoMZQIEDCgvjExIQMNKwsgYIAKUNdSU7ULfwigDwyo V6Jf5OiYIpY29jrg2QVlAAQMABAY0IQGAAgMEDAAQGCAgAEAAgMEDAAQGCBgAIDAAAEDAAQGCBgA IDBAwAAAgQECBgAIDBAwAEBggIABAAIDBAwAEBggYACAwAABAwAEBggYACAwQMAAAIEBAgYACAwQ MABAYICAAQACAwQMABAYIGAAgMAAAQMABAYIGAAgMEDAAACBAQIGAAgMEDAAQGCAgAEAAgMEDAAQ GCBgAIDAAAEDAAQGCBgAIDBAwAAAgQECBgAIDBAwAEBggIABAAIDBAwAEBggYACAwAABAwAEBggY ACAwQMAAAIEBAgYACAwQMABAYICAAQACAwQMABAYIGAAgMD8mQIuLKn6HjMUrSWyNCf1+zMqys34 fuPfkPKsxFuP39S6ac3uS9gSkQneFor4eU+LRLUUlkxU5efnV8ETfxZ/9+hmYWWh5D8yRmXHnxVD kBQLLhk95ie9VxJlVdzvsKrtXIGg/Pfx359RXm7O9xt/J0QVMMzP7zlu1paN22rKVSiDJLLq8Kq/ w7ElpzS2/47Iu6sDw6LKFfEiZmVNCmJeYdjN215+vWtiZDCCLSMvHxax86Uf5ZWTkvBJ3qjsdlJl 3u3VFWL46Ja1Sj6wekRS8uJchlqPti2x8OJZswpY/DVXby9e/g8kKZ81a02FTBeLr8p63n/e+b8X LDv/JL08K3rh4t3X5s1au2Y5LE8BlgmPhEVsG90BlvFmzZolRGXnb147deO1oKoMgWA1CDq7NvTU g9iMt3eHDRiM2SOcVL5M/K6Qv2HLUx9X0/EDO0+YulRLn7x77YI6PVKYmxEwce6WDTtqYkQySApX h/ddeo4tyzOfDDkYGzbN90kqSxEvqCyrsa/IfPn8+YPWnfp+iEBh+eX/+r5N/LKkj8+WrOTPzhbJ kzRmzvVFTAm8IXSLkg8MgqhKT7F+oFCovORnd/k+Q+8sihQ0Sy0w/nvtzD56PB11Tu+lW42auWE2 SbcO35gXz25Lb6n1dkef+X4mQpgq1gicbOkzckhLBlXGNDIxs6zIP7dwCtW1Cdd15MoRARbClMkj hlRlJJq5GrZbeqjkVLgzmjVl7yq7Ji7igjvJTMrhe9SoR9nDVg4UZXNgSoyw9OXspQtXrdmgo+oC +QnUzNr65T3r7jc0uHmOqfmI57H5106GB4qvMozoLM77JUffYjbhG5bQbiTdGjTT9u7tq0fZK9rE FUa9XbA5demRW5a89BFDWk0NnlxYaqsxfaSFiXFGlfRZuZHpg9Xq5ppuGdFqmhrpDLOn+26cfv/P hM1bsdTIauQ759bfeOmg0cEpsUJyYOt0ts3QhW31dt+M4UCQXp0dKYWiVpXw5JGwY49L03K12qRU 2q5fPKOHpTqpPH7Y2h1mjp0wm5iIs5enp8S76Qd1SF3SebIPQyAqS7VbvNq63dheTXQlAo6+oY1p YfrhyWO0WttRvIMWjhnFqIgd1r1z/utnTl3Num67kbDralPS+ynbFzk0dRHlXMnmapx+pZ/6Oq3X XwFV+QLS03fightz5sGrNu/TVt6hEbUGfhEZ9/j5q9WDbW8e3+Ps2ntEN6PQM3ddnZCw3PY9AgJR Hm4zad4/f/dP7xq8OOvOOb3Ra3xGtHRuSpkzJTg7rVRLWweRssTcxDi6y9PEp66dxjQXV01a+Xdn h8YlQhKrskQmYTXTMIx5feB8atyt7XOw1NStfN07L+Qen3DspL9fI3r3bp6+HT1KePrrZoakf08T 7PdjydQBTFRDFlOob2/RovvIDTu2B4ybK4HFHU25109tklHx9sjcO6Xhm4ZNC57IeXlNUlBx60mi UAM6vH1lq1ae0/76S52qcfxsmK36exlDr13PMX28l6TfD78RkwiRLahUMolM5Yh1Pdj3mwwa8/jv IXiWGs4jthUwbwVt7t/I0URDCqNFTDFk5ErV1I0rR+ruSO/ejsbOljl+9Aen9ju0HtSnjfbG87ec reCIyp49+o9AhbjN/I1Pt/eKmr9r+8OwyzbBaz2HuTZ1hSZPnJSXXYmdLWIhR8aKTrNs+zj1lU/A nMaoKGTj0Y6Wdvki7dLSciG3zF3XOOXl+mvp0bd2LcUP1K5ns04r8g6MW7/e18dRv0c3j44dW1dQ WqyYMj6Tp9RjQ4kJLBW/efaiiifEgglxsQKRpEwAl6a8gKWi9ynZHK4Ys3n2PA6R8SUwEvPiZWlO WnF56ZGhNmlZWYg8BQSWyRAUlkmkUsm72DiRRDL7yM0qrrC8pBCLxAwKMlOKSpmZybEpOWWKTN9n Fya8fIntiu2ISCqkKMplMVFUViFDVFYQvwZWBtUBGGsSooi8WOSr1Uckk8EfAjIEA0VPDreR//0i KTwF2ZobCXg6HwwQBJaniaVXHYMFajKVZ/hFqA6QSUSvn71g8kXYTxcXGysUSyqFcP77tzKx4H1q Dl+A/9wvXydiZwv2Sz57+KI4M7WotHiPH5SaWX22yMQiVH7WSSXid3HxYjFv3vmnLJ6oKD8Pi8Q2 5aYmlVaw05PepeeVKzJNLSiNjnyBFyh2tojLsbOFzeZg502lUs8Wogr453i2bebXN8LhicX150q9 U8bkY0uZkP2L6XCKsj5ZF5XDH60xhdJPzWGUsNxbNuqr2xBxRCarHn35KkRqQq8dXT2E4Oq76Hvs 27qP/Sym3azt/64g0vNvC7Lun8CCHr5TsN5E3+ZmeNi9m4ePj59f125d23l6ePRs79um46rakhdA pm7VQZL3Dx2ISvjnJT5gnhV5XjF2I5JIFZXih+0yRYjNx0dkYHZ6hRiGIfTLdq2uuT22fBgRju3C 6HWWnxPB/TAaVJL09PTCwHV7Nx49eGntkulL9+5dNnsAq9am8eA2kKIlKeH/ezPg8BlIIIRgSfWQ L7bYMxlCah/+VR7I2edZtW7ouuoktsx+uB1zaNvOB5ivETFFik3l2a92Th3u0bVrn0F9e3bq0qZP z64Bq2IKamscLxsH9egAsUUQJITs5COmKAwdeq4091V9BfkuZg/oOGjizjXjR1fkv2vp3rLz1ENY 5P5VI/ysTHp0sI9MLgkZ2tW7/0wtHR1HU/vksHkD/LyuRBV2m3y+B123jaNdSVlO357dDkekYnt1 HRa6MXhURuQpWCJILePa0nXdu0+1cexpa21a07Bz8R6qCAT0no0tO4y/Wr1BVh4SMmXBurDq1W6B 1QGoDWpjgkqFqGcTNCwJNdqJ3lqGTlqAepvWT/n8B7d2zNu+fV2SEL31trDpgCkzBjVXxEOQWdNm lsN6e16aP+z+09sRt48PCZ7XvmtfDU2H+X4uSZdmCqXFxo26m1p1aeTptz2kLdZX4eREJVfmBe56 9r+5+0PGhOQlvtRuN6sy4Zhrm+DBwesVyYpyrydV4k1KXmFCthRNvxBUUyOHbVu7bds2sWKlLBMV ygORJ9GOPdBug9DAU2j3Zei0EejGrWjsC5QrQnuEosGD0GdvUE0rdGoTlCdDv0733r1NvQdE3TjQ 1tOlMu1yKTv/5IsC745HsE0WLoGQhbczw1bIK/Zq5HouptCrbbueIZsCNPSdHG14Yv6TjJKWA4e6 NRkbf/Fomy6dC9i4jy4jTttCtmfGt4g+sybs0FJ1DeNEATp2/Nhe4zbWZBr+Mh9bSpnJDwqxRjjv XT5XEZ8ReSQkJOR9YfUqun0ZWilAvTqgwfPl6zJ0zjK0ZS+0LB21tEArq9A8NtpuNjq2K+rogp5c hbZ1R4Xf28wmRg3ceckZX9orSId8YNqw2JhYHzdDLBIW8y89uHbxblrEvUvD11/poJelq2eQkXst vZh14eGrv0P3pVZJXiGyJ/f3jZq2LDziRlg2dhWEtMtTT564fCX8Jd45gdGn5xa+urNbw0D84uIC vqS6smgsq77QUjm5n/hBYQRPnjhuSPvqVbrVhw3voEd7oPAj0KtkaFEg1JwKSbiQoAB6WVz3ZfMN oqPypk0cX4HXDcIxQSFjhwUp4tdePOPSvHdwgP/Rk8/92rYzcXJfGLrKiCUyMpn015KBMjIkq8q/ HHkDkbzbczksPV2mgdW9FvbN/NyfrN8/MNCfTCZbN/emos3VaZSnL/ZTefmKZNVNHRF5japJN+CK obysN1h/WCjEh4mOhm4MDQ2tdguWQhT5TT8SB3pwDpqzAzp3ACKRIVYJNGUQxNPDb/KQydBIP6id J0QTQDsSIJIM+jrkJn0nuEkG9J2cVdhE36HVzvmDIk+dmnlwKL6txGJpa81Xzw8cOrTp5fu3OjTS hKVHu+gXtvJ3SklKjE6JYXFF7btNG9L4hete4cvTKzkyXBS8VxerdMpWPm0T8zJ5YNBqu0b9mmvy eoxYYijKq8m0hInfcKLqmuSwBJCsiESqjrd26xE8IdjaUAtfGeMFzVwFaedBKfHQkR1QrkheTO6Q PwVauwgqyIeOx0I0EmSoCVHMoNRYSMiEouMgDRL0nXyn0FVLYwfrQZO3rJo6pDjtoZWVhbuiBl4z VlCW/qKI12zmHrqxmbqVej8yWV9HPf2f1UbGxo+SmDZDz9F19VFJ1pIdh01t9Y8kcLC9ovf1S2WW t++1DBbzkoo5WVdmYjWBR4dFgqq4XFZ19TCydfvqwIAZKCpRZ5iYGhsWsvBhDBmOvF8nzkDJ6qhI bgf1RZFC9FU6amyGRuaikBZKV0NHdq//gvoSqZh/78FjLMDiSfJSE9+npivic8uZB/ccYRWkCDnl T169yy54ffb+C65QamTWJzGtWCpgIbCQJ0Pe3nuQm/Z+Xve2ir2u3Y3LfngFO/7KSia2evdJrpRX hq3Gvn1XnR8ikSgGwBCZBEFLYiMOHT+bV1z+uVvZ2Wi2fGiQXYD3k5/mobsPoGVsNCMNcxktE6AP H6I336IVmbhNVQn6/DUK/1elNHPfpXNLQy6smISdHlFFrA5Td41ua6XYwcJ0efjMvggvZ0tYmI2N tY7BOk0duv+QLXM7UI1NjAUybmRm4ebHBftGWWwc7tKqFaVS3mbYPUQdlaYdfpT64sAUbNWxeUsU 5b7KZU8d1aMm0yN3kvA/sqq98WyUF2Npba2n2Vp+7DA+5qcwsqGi3fzR9Ao87B8ij5KhtxPRy/PR pPuouSkqEuOnjdMEtMsIfKOOPsqgff+YHjEE/J34mttgy4zLk3mfHv+J3Ut7dfUtFxN1rLg+kBTn 8vAL08zFDz6Jl4mmT5t24XG8aryqG3YdxS83i3p7fBqN9PUPaK6nQ6yzhITWOp8Qr5olrxLLvF2s at8KAAB+A2rpAy/p4VkiRiBUll9QLhHgnaevaRwAACgXiQSZMyeTx4O/bSrncwEXPNqw82lsIxOD 3PL8e1Vacy0sSDR1Mpmkp6uzIjz3zGQvBsOdRDL/Oee4XHjUqOSf27dhcvx4yatXHFV7oUxOnix5 /JilrNQQBG3f/h0M/1E1zJMnrE6dYoOCUqXSbx9XLU3oW0t8zWfes698PeUho/HqDuPTyru2+l9K 4m7bgRcr7/3FYNC3nX80rLO7wtjDI1r5RwAANFTU1MiSD3dDSCTIxUX78OHGWA36NftaHmbQ0MEf Q0EhmE5XzxSi+lpqVrIHJHUDQdxWCk1t7vLtp1ePa9M21l4DNw4Ntft+50JDc7Blq1Y6AQFG379X gwVrR23Zgt+eGTHC1NlZU9XuKIG3b7k3b+IPhC1ZYkujffedkq+za1dBVRV+e+mHzsPfGaxNsWpV 9c1LrG718aGTSP9ZUF+OawmZuaIPI3H8khwsuGslPpJ+6cIdbJmbly8Q1XJLXSr99uhdQgKvT58/ ajyzrlm0KPPYsT9qgmdwcOrx40o7IqEQ9vaOxpbKSlDliMVw69ZR2L/Jk1Ph7zisWgT8YlcgXyKR Saun0AjSLwjlt+Ce7Bn+sUaFPPxOoGKSOvbfxu6IYkZ60OSp38y1slL6TZuGDPzFPU82m9gllpOj mHiFhoZmKyXBM2dKFAF//z+qSsAE3KNHHJP5vT93LaPQsyv6xp+Yee/8nu1BNocC6QKRAIbwSpxV VkKCCt4kvc3kI4VRV7K40vCJ+sWZGX1HBW4f0wfyJq84/Sh41/npvvrfbCfs3l34M82LBsOdO8zP YrZuzVeJJ8ri0aPPB65KSv7rjR3fJDZWuU/l/S5gfeDbt10ZjO99UL8WAdOex5YmmrrY6Dk16ra1 ZIihk4/ijSlO7bqjiN6s4KnmmmQ2Bx7fvzfZvPvQUaNsuNk7nzEZPu5Xdi7jFnKy0r89arpsme3y 5dk/cFgNCezMNjD4/PebMMFcJiPqWCvW0DMxoX0WuW3bL12SGjfW+pXd/xxqqZVFFXkfJhX+BPef pX+n5cmTJdeufTHJrgEjlSKbN+dlZAhq3froEfP58199GLD+wRr/27fn16zWNKHDw8tre6z4e8nM rG6T/2FN6B/l6zOx6ouEBN7VqxVmZmr6+jQ1NdJ/jJgrBQqFRKdTbG01LC3Vv2aDFUl2tqiwUMzl ypA6fFEEDgyjEglSUSEVCJDx48319b/Rdvr77wI9PYq+vhr5155DIZEgIyOaq6uOpuYnCWHH/v49 Pz9f/IsVPpYOnw9nZQmDgsxNTNRq4leuzFmxwk4Rnjw5rU8fwy/31dGhdOrEwAIREZVwbTMaHj5k btvmpAgHBCRcv+7yK64SG1VfQVTGu3fc8eOTy8okH0fGxHCCglLy80Wq8qqeqaqSjh2bXDNm9s8/ 5XfvVtVpjt8ziCUSwdhlfd++wu9JsIHXwMR4nLAucHPTOXKkCZ1ODQrC3xq6Tu0AACAASURBVCMr laKHDxe5uekeOtTYyuqrlfMfBlbhHzvWZO/eQqwhsGRJdr9+Rt26fXsMsq5RVyfv2VPYvDno5X4b or6VUllgjfbDhxsvWpTVq5dBUJCFqt1RDdOmWU2blr5jh9N/TxmoT6ZMsbCy0lC1FwSgoQtYQd++ hu3a0VXthSrB+uFU6m8jXwhq2lT7Fzv5DQQgYJwGrl6Mgwcbq9qFT/itria/Mw3rKpefnc0W4vMH qoqrp5s+vhmpUo9UC5qVVaAIlLJEqnKiJPfzGQGo/GW0n0cS9S543dKABMwpjYM16X28RkMQt4ln P0Xk1m0HPrYRS6QQ9O+NIyGn8n3RnznjB+PZxSOzlofJg6S4jM+/JgXLPzQj+d7nUn8WhDN64kxF sJglgKUwit8dxp8PlML4P5lYhkkX82L31Vd17AohaUBNaD1T15CATqvPnuhs73xhxZysMr6DiTYE JV67dtbQ3ffspSdX1p6w9LC/u6Xb4+jntGYjtYvfRLAdRnfwgCAifjjl27QfGrT79XV5UBSyZFlz LRoj/9X4RYNaOJtpNJs4ctaC7NeIRVHY7YKcOnSCrOfrWP1NFR8r7WZurfp3bz8wcJiGTYtB03cZ krlcru7G0aim8yghn3Vjwxw9D+8T5S2PBDaqQ5cIRQOqgcuT7wyetBBmse6k5Vk6m5oZ4A/ooWjL fj07xr4v7NDBByJpMsRQfmEeCWIEeLV2NLeb2ZZxMalC1Y7XFeyyPG6FouKF92xcbSSuypRoq6Fa FJpabkGBmV7Tfsum1a165VnnZJcK5Y0el7GH7O3tA/x9y/lVqChn64qZEi6rvKogP49pY28nUdNK zslXt/WxybhUxy4RClXfiFYNiKz6aQ+pFH80soIrLS/Mw982KeaVFRdyuRWKrRlZOSpzsX7B2q3M 8lJYIsorxWdrFuQX5+aUlvCU/5jef0zkYPIEUQ9uI2KuYm6NFEELC4tEfFZVRRHWquYI8Nk1ZSVF n+3VwCdyNKAm9MeQKNUHTqVSsKWhDhXSscbX1bSNzf79dpyjva0qvFMBJKzVYWSCBaxN8EksllZm 9e8DQ1uzdeceWEDx3AOVBFlY4C9vUtfC7xHoauKOGZv+5Ouc/lQaUBMaAPjzAAIGAAhM/TWhV6/O KSvDP5yFtdZ27XKut3yJy8yZ6YpncSgU0o4dTqp257eDzZYtXZpdWSmbPj196FDjDh0YqvZIBdRf Dbx4se3LlxzsX73lSHT++stKUWIdOjT0iWK1QqdTExL4YjGCFVH79g1RvVB9ChirRtzd8RuqoPr9 TuztNdXU8BmFgwYZq9qX35Tt2/GGycaNDr/PYxj1TL2OQu/b12jixNT6zJHozJhh1bQpeKruq2BV gqYmuXNn1T8CqSrq+40cUimqlBcCAwjKx2/kUApCIfLZS0UaFPV95EC9AOXSkNULgdtI9Qwq5ft2 CxgSOHJi0OSOvfoNGjw4ODh4b1jsl5bM4lQLG5sHqWVYOKhPy/9Ic9PC4LpyV9WUpkf37+GxrpMN eBLpawAB1yskmvbTe9c5xn6HDu97EnEtit/vwIED+ozq2fy8iqSFCxdGJuDvW9UzdijMSt91NTEt fI1Xrz4fEmAy9PWFEDRzuO/CfZF5D/frN+8LQYyJPd3FEHRs/vC+Yxfc//vMxM762Kolg37wZoqK DlQpwDP3R/xz65VHL69xXczL+LJjSwd1CF7vZ+9gwmDIIKhvpzaRaZWLBrQJCj2OWZfHnJ0fMjyu SvbXrhP6+n3yom63bNsVu2Y6Wpk8SSmeM7z72OXH2OmP6bo6BSWZDLpe/J/xmJlKJnAisEws/XM+ h/GjuE/erghY2IzDluceZClWsVIpKsoXivC5wLnR4bN2X0RQVA2CmliZjw45hkU2tfTFlqkP/i4V I/S2B0auvYCtblwwmM8r2pvAcnJpNWHlzo0LJiAyobjyTWPX1pWi366Qv//LDDk3V+fJXy64toeW BEbCI59eiytdGuhnTTcVJB6e1rGVDEV93Ee6erVdue8cZlb65gRHiujS+3SYdCotOqrX6Fn5b8OL ow7ypQjKTW7q7rn28I1TM/q1adsh6vy2lh7edXaI9YrSamAUEbv0Hrl9yyYBDA3q1OfjTTCMsAse s4X4R6iwtpBHh7mIVJhVxldW1oRDUPXh4VsSFYL4R/eHdvZqjq+RKQyGIU0+PfvVi9s5dy92X/WP GEUvbJ55Yt9YLHLuyv+NGzUYsfZJio9Dkzakh+1Zs2CyZwsvLS3G3sc5azdtL3+4Q4TCJIrG0+1L fVo6FjMJXMi23acOdvPsPGQiRapLI5Ne5XLWLJp+LDJBrGuv6eTtO2zQEP/BDP++JB2LZ4eC5B/i 1PH37xc0bwnV0sC5VWu9soQJ89bpWLhNmjRp/+1KA02TyHObVj0oNxC/O3AvqpGprFKm6iNUBsob hUakPTt2LEPMrp1eHxAw6uSVPefuZBWJ4du7QweZ6vpOGaTBcOsX0LsgLa7zoLWvXx90cutmaeU+ oGVls0aNfILW23z+4n7AV5g3D1JTgwIDoQ0boM6dIR4P0taGpFLozh1o2zZo7158a1AQNHs25O8P jR+vanc/R1mj0PEP7yXnxKl5Bw1oVj2Fo/TNSajVaNOG9niOsqpydlEiTyytyngakcIa5e6X82gz XyZbtuPM4r1vsK2CiuhidvXXHlq1nyzmFSQVc/p59xvqalzClUTn1f4tggYHgrd4mWy+qv2oQ5T1 cbOvEX37ap2m/7uhvD4wAie8eZ1fUokF05ISsNXXL9/GvstIz2VhMbBUJPnw9vC4uBS8E4ygWSlJ MokwLj7xO75M2iBY7sMQS1G+QFRYXCoRSlDpVz9RJxbLmDkPS9nC+nRPKdSFgPMLmVwOXgdg59EA XToWuPvPDaXn8nuivFFoErmFZxsrUwMs6NysBbbaxtujpZujkw0+j5dMVad9+GaKq2tjvLdHguwb N6PQNFxdmoM3EEJ4F0Ssb2tZymTPPnBleEvThRO7Pnt5MTfxUsTdW33GT8cMbq9uGf0u6uDxQ3ki 1LVDp/zSsrw8Yn+y8BeRVMXvOX/XxNrOy9Uq+srcu3tXJKSl3yf7WRpqW5pqf3v/P4JfFbCL3yKl +AEg09SbudlZGdMbm1kbtgrx9Gzl7dnr/dvXfC3bQE97zKAoMc2CTqFqaSRn5Omo+zg3cmGYWqEy saodVxmC0qICAenitvFI42VOlo7FfJa6tjYKSS89iJ8y44+9N/45P1t1IxO6OLTpv8qzw1BXRyc+ O8+rkcu5mMLuvXubeg+IfXDa28ujgs/u0MZn09k7mPWLLd39WzRJLqkcODrYp+30paN79Z+2ilMQ 5dbKrYjLdGrZZlVY9KCO7W1d+zz8e0HH9i05xP6c9U8iYFa/L4bD4RRmxGMdDa5YWlVRJqu+GYTk 5uLfti8rKk5PykVgWAojgb39VebuT6HcJrSAUyWB0UqmAJVysVOmoqRMIhRWlhVwhJJv7/xH8JMC lrKz4uRDLc6mg0vfHN+zfhoi4YQnFPWcvXdxSJ/2vf4SsTIe/j1aS0c3pwLvnLzY3h3rn2w7d2/3 4yJhVcGh97yzg21H9BuLbXr9zzYtHf1ilqBjS9uB43dfXB+kQYMacKf4vw5d9q0Pcv7+5VbXg1gN jZ9sQlN1rdrbmOtqBdsEdta3ayF1bmPr1Cyw4/EmzsYuRta9HAqMPZ3cx27V1dUbFyx/6y+sZ25m PLCbpwBCNPQtgj2tT1otnDPO3drKQrv1ADpDp8/4Fe9LJGxu3Pj1V3Q0oD9s6tyG6UG2tnqeTZuN DOylz2C0MDO3aNK5FjtYxKDRpF9LBYWHbXr4X9kIU5+ks3/ZWQChqIurgr9/QFsXO9lH1UHkhvay usiJONxcEaQIJB0cgjXvpoybWrNpxtjxI4IWK8JnR9oq2stHF/WdPd7/zbnxE8cOf1VY7uYwxGvh 9VYePs5NWzEzX/1vyqyQi2meHq5tGrWa07V9yPjh+D7ilFYtm/UIWn5lfde5kwau7NNUhvL+t/Fi 077jXdqvqd/D/SqgBlYudXLb+/r1a5/FtF/QkL9ggsMwUxNDkDoEGdg2EcOQSPbvHClzWys9xEYR fhMpC5QHTia4PQpfbWPhl5m48fa9w1GZFykQPNZSezT/6MVTRwUctcN9LP73funlJQPDz+7dtnOf Yvdd/7w8v3rygrOmCbeHSBgeIwf0mDd91MzH/Gt3Ztf3AQPqBfAwQz1h1rixYrKZQXMvKhlSK33b yqPNuSj8YaOFoStXr5qABVCZINbe+WFyKRZe3cfSv1evM+s8Vi05lhvr4uvjvfhs7DYrjkuX3oP/ WryiS+vVx1+YGBpSKsoLkou0HXzwpEla1sbajY2sVw5GugzfkVmgRXMa0arTSISVO3D6XtUdOqAO qe8H+gE/RsuWUFwcHvD3h06fhuh06OxZiM2GJk/GI319oadPq7eGh6vSz+9G6Q/0N3BADawaLuxa +U0bLleIqfdtpvzbLpg+6XS4/F3VwMBq9WIo1KvY+hFfHQYD/HEAAasGWXnJ0rFjWQiUcvfM3FW7 ISl73LhxQlR25MbN0ZtOYwav750wMLR7V1hubqCz5VD4/C3nJoWsEfGZSOa13bs3P8vh5MTe3bD7 jCK1tfPHcSFo66W3qTf2h44a7hcQqNKDA9QfQMCqAeu3rDl+vIlt2wmH3ya8jpw9ZrCOBq+II965 OZZ9Zwtm4NVtjKZWG3czOKtCeOn6y6LTfwfaPM2NPMQrLTXxHrFw0fmbgpYt0jfJICjl9pbgtcf0 XP/mwOJnF2+HHt/deepmVR8foJ4AAlYNVAg6dfZIswkLUrN4Y7o7ljOM+vQbO7jH6tBdY720DRU2 MBIJUdQhKsXDu5etg7RJ595CmAKhlf08LIQ5z8LPnRu9Ox5Lh25odOzUcf8ZnY+fPhadkQuRtQoq CPwYMOCHAINYxARFZCRyUwuP9KIoVbvyY4BBLOUCauDfmrjM8prwuyzWvxtIJHZlVUrBWxX4BPid AAL+TUER/KPXvUcfr4nxGxX20XYSXd+AAuGfTkLkloCGSUN7AcnvSy9Lb9f2eX4uAUz3/vmo8Ysb YeZkE+T9spUhtxbuf6QOodzXIatGbRk77a89kaQixFHf2cnjpH9YCdfPq/vMHQdV7T5ANQAB/y5E awmvn0z/n53DufwtB8Pvr9m4wkzEvZzKHdtPo0IMWaojur32D+seHfXweeisg71nXYVNTIVZCKnR 0Jk7Nqnad4DKAINYvwtCblVGQVUzZ+vY99kMujbMLmbYulAoFEMtCR/S1iaTKgWwoQZPDOnGvo72 9PYsTE0oLygiG9q6uTdRte8/ABjEUi5AwID6Izy88tq1in79jDQ1yV27NtwvkikRMIgFqD8uXy6L jeVhlbC6OjjxlAOogQH1iodHtJoa+cULd1U78ocABrEA9Urv3gbOzpqq9uLPAdTAgHpFcbqRwIuE lQQQMABAYMBYAgBAYICAAQACAwQMqDuqe2cwDP/MzqBv9x0AAQN+jHmBQywt9Jo7OA0f2p2up+du ZMww7/qlGSpl66ppK4Q7uOdPfOUUvR1d9IuuNgSAgAE/xuZzl9b3apuUlXH+4t1byztFVZS3buP1 YSMSMiF4ZPBqLESi0dd1IStOL1H6s/be3pC40LdrhysP06euj/xn9bDTww0GDB2QzJJie3XycLZx DZky2KtDh/bpDy5MnTmxQihbPqWfT7/ZZzcETxvXXyjlebbqF7Jkd1tPfzObnqo69t8QIGDAD2Nq U/35CEMbJxiFpJDkwxaShbWZvZmDYuX1k+oPUuo073Bx/4rYg1Pu34989uYZSZOEklFOKfOfi/80 ZdBkrLR9z9Lz4ve3GL+va5NGO44d3LPjkJGmZNGOS05Q1dRFF3Ss+lGo0KHrZ/eumuzpbeUXGFL/ h/zbAgQM+GFs3FwVE4BMWrbHTiCD8putPb1uJFRiAl4eunL1yhHYJkRYUejVOqmYg4W92rY0sHC0 mH6+Q5s2s6eOKLg0f/Ntrh7XTZEaldE4pEdH6PHjN8eWPE5Ln9Pdf2JgIE+CDmzGOB468tqJZa8i T8IPo9TUyFLm+yHNW7ZuZa+yI//9APeBAb8BsbGQmxumYejaNWj7djxGXx9iMvHAuHHQihWQnd0n WwEfAAIG1AmwhE9R0zxwNSa4v8c3jREYJlMo9eDVnwdoQgOUDzc3qoW52eTVj1o3t1656fDcFevG TpmHxc+cMimpAGtpQ4iEP27cODEzrpAPr965Y7B/53Fjxqjaa0ICBAxQPrq2HrMndt27uH1kelFE 2C56RcqKkd6FEXOsrBhv4xIwgy0jnY8dO/b0xTM1NcqTl7lbV047duKEqr0mJEDAgDqBKj+1LBh6 +g6DdRmwiV1joZW7adOOR1ZsxOKtzBiX9y+2cXDYe+AYjWyiKX8VNjP9nYqdJiCgDwz4XfBqsvh1 yjpVe0EwgIAB3wuCwGRybUNNiAQiqykpE7hKRDLQ+GrDkM+q0GYYKSmvPwHQhAbUTnZi1IoZAy6c PBlx58bMga32HTw4ZuDAWi0bGZuL5IHS4nKZDMGrBET0JoctgyAZgshksGJeM4nU47MdZdJPvqMo wSylJXczOLXmEp9Zgi3j7p765SP7owBv5ADUjn0LjzEDhzh0+h8Wbo7E6/aYJM14WrP16PZtTJL2 nJnBWHjHJB8NeaSZhdmItrpmPp2nzN+YK9Jtp+llY2Jo6+Z4aXWA0NAVgirzC16fupT2IObVg1N7 MK3uvRKjq6Z/ZNpUH4Zg9KJ2ZfYjTW2sp3Tz3mGq65zD8pnWos3wRWOWnOLyPPK1s6e389i1YJga CWrXZ5B1/8WGh0I8unhTW1gOGzR5w71UTnL0pUdxuRH7VVNYKgQFAL5C9otzLHlAnHurWIzOH9VS KhZXsIVYjI81ho/CbG/fLmKpDAto65lG7+8lFuWduf8wpbwwLE/Uppl9v/7ziqLOC/A62Dv94vwD t6KyMtMwY17iPpZYyuayAlfeurBySHcIkkrFIkHenXzhSn9nXU0aiyvIeHcjV4QisFQs4LUavRPb 69nFbSiKuC6OaNxxavHrk0wpFyKps/LuzNkcXpCVoaJyUiVAwICvAsskH0ISrGX89u656/ee8EXS z8yYTKZAjAs4Kf49N/WKCEUTCzkwAgtgJCM6SlhZnBQXg+3z4ulbzCYtObGKw1fs+PZtDLx3r/jQ oVImE5GJpT17ymBYCqOytu0wySanZaJ7/obPnMEUzMrNxbZiu4iF2KUAfR6VJWKVJWfm5jKlWSm4 bnMy3hdXcuqpXH4nwCAWQHU8egT5+X0SyMyEaDTIxgarjqHXr6H27fHIu3eh7t1V6edvDBjEAvwq C3ae/W8DcUUaF4VebPb++CtsTcx6V4sWoybg6IirFwOTcfv2T69fwMNAvV8HCBjwq5yeuci9fTeJ kOXs5rU5Inn92MB2HX3f3T7YzcTxTlopZuDl27eNW/u89/yMc+M82rYc0KPD5sh8WodBTa3bOjgY CzilA/x7bQ9LwixfRxxv2rp9YfQtnhgOWLJp0LjggHFzVH18vzeqbsMDCM+CbeekzPfr9m7S0tGv 4okoVLXRu67eOjoTkYnmnn+KGUgq4tIFaAAEpV+YwZPkPi0UNnENhTruaWLTtihy9441M1BU2nLD G8wyMGRWVfL9uNfnRTIkYOqhw1NHqPrgfndADQz4Vc4tnWTqNfGvoUPpDJ3uE9Z19W52d/VolKJG olBfRZXKTWCWEOnbG4JkZTSa6cvkSo4oDEJpENnX0K6pZ68hFjbmY7s1wuy6ifOd/Rc5O7Sxs7ZM kcIwDbw/+huAQSyAirl9bsOeUw8O/3PXVB3I9YcBAgbULel3Tjr0GP3lDMzLzzMHt3P8OEYmkVDV lDUls6EAmtAAJYI+i3zK5IvL8pLfJGUiiOju/UcatNL8rESmEH9BZcKNK1EvnyXGvJGgkFsj85s3 Xty+dYdblIvt+LqgYriHS3RSZll2ysv4dFUfCGEAAgYojex7ofq0sq3H9qx6WHk/NNBd16J7V7+8 tLi7+Vr9poVjBgnXQgW8NMih0ZSz74NOp86dHNDKID/y5gkIlSy6XNDYgN66uV3IudgJfn1As/A7 AQIGKA2ZGBYZtMmOiKRS0LdR3FRIPe/9ozIOOqajgyAtEjOIeSP2amYnkGq9CX+DP7LgPItM1kYN GImpyZhim1vRsLjiJzHHjy3miX/mXfANENAHBigTPo+npa0jFnCo6hpUCo3NFdB1NSESmcfl6ejq yEQCqjqFJ1NjsziWxnShSKqpBsFkGp/LlVG1tBGBurYuIpNJEEhDDTxm810AAQMABAY0oQEAAgME DAAQGCBgAIDAAAEDAAQGCBgAIDBAwAAAgQECBgAIDBAwAEBggIABAAIDBAwAEBggYACAwAABAwAE BggYACAwQMAAAIEBAgYACAwQMABAYICAAQACAwQMABAYIGAAgMAAAQMABAYIGAAgMEDAAACBAQIG AAgMEDAAQGCAgAEAAgMEDAAQGCBgAIDAKF/Ao0YmY0tYIlu8KGPp8qw7kTxECm/ckLt1T3HBkwLf djELNhbUGE8ZFOvb6V3YKz4WjrpdGhKcvHoLthUZEBDbrl3Mku2FCrPru7IrJfjn6lauzvksu47t Y6QwUr2Com+zxEo/orpDwpcskpfSretFHTvEeHhEt+2aMOOvtKVLM7HIbdvLBg2Mw8phyrxshX3h o5y/FmSVsz/5ct/gMcmKwJrAxAKeaPXuom/mW/amcO7c9CkhKems6qS2TnyfwxF9Zpb2unxEYMKm CxXCEk6/3rHTVuRhJTx7fELAoESWBLp6IHvs2PclfOSL5P9w3j0oXbs+t0SI9u8UXZXNOvVPlSK+ vUfcl2WxaFZyMRcrWOnosUnjxydtPV6mXGeUL+DkIvzLkBQ16vjeiLqVxMGC5+sT6+wpc3UQxb/i jl9jzL9WWs6XKYyLc5FrVx23zE3llTEX7CleGmpgD3NOxJQKrWkHD9v8NVJLYRb/kl/JxkUefqsq 7EDO0wdVhZUyPkt05myJVIbCMHr/VmVyjvjUiaLJo96/zBAVpHJvRlQp/dCUjpq22rgeMqyUHO0l Ns3UHj9qfivMLnSZQdEbVlCQ5oABcC4POnjQavk8usJeUCaxtJWMHhB76g731rkSGIWuPGKXVohP Hi8SyL9RJ5FIW9iKLh7O/+diaV7FV7/QadLGMrC1zNGbKskoY8ugK5fws4pdzCnkIIgMicmRKsxu 3KjatNn40ubc8eMy1uw2deIww06lWvbSOLRaf+7KlHXnWfMna+24mlHnxfQ7URBZHHq4tF9vSkVR EYRAqDrFzlnCzOOeuVAu0kT5LPGNG5VMUfUHAxGBMCNFyMFPXdL7VAlNHfHvqaVcf+qgCY1AJPlf CzMtbS2qs6PZjEDN/RvZi5dXZVeR9y4oK3akqdNq8kX9+6STSZSjS4rmhppYmZv6dGJUsfhVceLV KwtuxfEVRqkSWIaVCQqr65CuHaq8H1vSv0dCx25J7q1FUhk04X8JydyKGQtT/f1QSAyZkUuGTs44 viz75Ms85R+dsrE0x0vJ3oyRHi8ZMCh56s4CAyMjeweqlp6+jYUJxIbXrio6fKOyxt7BxSDiYeud azKWbytkiSXb9ueKq5DWrcW+ntH4WSMVXrgnuL6/LE7ImrYpVbELrskY5ovXnI/zNdTVoNFpqbHc 7KKiHTvyBSIZDZIMHBR/fXl8bH51uY0eb9Z/YOHGowbMStTB2rRJK83sZJGvi75pYwORRIbwkBmL qkgCSn0V1W+BlaeBmAnPmFk27zBe3WY9r3iRJOr1v3RvNx6kQQ7omvjyUcGYGSkKY7KWZkBrqo6G JiQR2XnRlk7XXbVcyeek8gWsRidJxbJDJ4sqy2F2KVqcWXUjTf32bTeGJikqQ3j4qv3lky56av/m e3i/nVgoM7eXnT0rlPLF/5ta3M9Zx8xH4/x5t7FdrRQ2va2p128Lnp8rMPPR1ISg/kNtMTVj8Y3s LLGEpAIk0N8aRSG6pRkWaWNmJOGgK4/pmxuYKv3olE5lGV5KZWy4pZ/O3TtuZ5Y3heS/ikAi7wsY UM9ccFs63llhHPsUj2TnsDV1SVgBoCiqQydTjch2ZsZYvAzBy0RbjYKdPtOHORfFyxQVAYlCUldn MvQqJfIWHiKUeHi9S43Hqn1NRIqWcilY0ZHJZKqBXrA7tOYx0q+1rSK70UMyVixm6JCMHZwo0dnC Vbu5vl11Fu+qOD4/19mcbGJLvR3heu8AF25IH6id8b/3FyLc180xLL9XjrVwuEwEQRESCbK3MsG2 ciGo72id3q10a+yLS+FSDvZTkQK622THQBSykguLEhoaqtwUM16Uvk1mNnVCUoux9jMJ1YKsdUS3 H5QNGqE1tI+Fui6JoaNZY2xoIM4o5U75y7BjgLMpxAmLKJk8W7+Fs2VuMau9m2GNmUtPk8zIvCxY tjTE/sHxcpY6b9IU+vzJNqcvZvv6qk+danvpQl4rB3KT1iYSMtvLy8KrOfwmXtDCETXW163Nx98F rG68+aoMKyVIi1QUxTl9qSRTzPVpbmjbiKqlq6GjRYvPqOrtZ0z6YG/vqXtqb+6zZO7KZSbBQ80u XM21tKAM8lWPTmLNWmTWqKm2vrmmka6oQyst5xYGUi7T09OITIJIJJKJib6xsT5FnhCJRmluLdhw iTd9gplbK+P71/ON9Uj+I4wMTdTEVRLdzpo9XY0U2bm5kfmwmFfFmzzT+fXdnL5Dtdt1crIlsXkm 6OhAh+bmspv3i/9aaGRm8FsXsnLxbKt9/HCGUANZtNjS2hRq3cNMnw4H9Te+GFHYpZP64r+snj5h NXYj2VrpY4WNymA2lSfk8B0bmSU8zCpG4L9m2GhrqCnRH+J94HuqrJIfIQAAAHFJREFUR3RIeBMX c21VO/IHMtgjeldEIwvjBiRIokM8AUP4YDOK1Sqq9uJPBDsZQMESCkIKGAAAKAATOQAAAgMEDAAQ GCBgAIDAAAEDAAQGCBgAIDBAwAAAgQECBgAIDBAwAEBggIABAAIDBAwAEJj/A+Tm1rrplEk1AAAA AElFTkSuQmCC --Apple-Mail-102--974640808 Content-Disposition: inline; filename="Picture 10.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 10.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAUAAAADwCAIAAAD+Tyo8AAAABGdBTUEAANkDQtZPoQAADzZpQ0NQ Q29sb3IgTENEAAB4nJWXCTxUX/vAz52VwVhCQgwhighZy0627HtFzDC2YYxdtkREEbIUiVIqWdpR IUIlLbaSImuRJEt2896hfr/f/30/7+f9/M/nM/d+73Oe8zznnufMee4DACfBlUr1RQAAKH5BNKv9 OgQHRycCtgegARtgAoqAzZUYSNW2sDAF/7X96gYQ494hw7BFOVbfGv36gvAlyiiCR0b3yH8ft97w NNghAJA0zNzkDdZisNsG2zA4NIgaBLMng4meriSYI2GWptlY6cJ8jWGHvMFVDHbb4GcMDiGSGWPf A4Dh8iN5+QGAnYBZg+QeSIS7GX5JpEAiBeYzACB0KBR/2D5HJyyXJFJp8FiOFZjFGOuyMWX3AADU dgPAnP23zBueawUNAP7Fv2XbWQDgDQWg/B96M1brawXxvg70UJBfF0GsOgCg++j0GQl4bhkArKbT 6cuX6PTVywAgPwJQ70sMpoX8Xi8IagPgfz1vvPPvhoQdMgIsAmhgAopD7EFCyFW0GMYb+4rZhQXN 2o1/ytHA9ZF7erPCFpJAydZxwk5RmliJxIAU+041mf2ySru3KmAVJ5XaVW6rndrrqCGiOapdoGul t2pwwVDZ6IWJo2mnma15g6W81TnrZVtHuxoHvKOLU+XB2cOKzjSXq0f63DiJBqRA9wseDeRRL5y3 lI+BrzMlxO+0fyG1IqCO9iZwIOhnCAjFhwmFy0UoHd1ydDKyISo7OiDGMFY0dvXYh7iHxwviYxO8 TlgnaibJnhRJ5k1hO4U+RT+9mrqWRk+HMpCZmLOYs8tZg9nNOaW5GedCz7vlWeZrXJApELrIUYgq XCiauPT5cldxy5Waq5UlF66dvh55w7fU/qZWmWQ5e/laJbiFvc1yB3+X7R7rfZYH2Af0qtnqsZq+ h28ePXlcWXuxLrk+9IlHg22j3tM9TeLNfC1szxDPFp6PvahvTXpp2oZve/3qzGvzN/g3z9/Gt2u2 L3ZUdHp0be3q6E55p/Nu4X1Zj9sHvg+ve0983Pdx9lNln3s/a/+5z2KfywZUB5oHbQaHhoKHscO5 I9Ij9aPWo6Nfwr+yfr04Jj/2dNx6fOhb0AR6IvO7yPeKSfXJph9WPz5PeU/N/IyYRkyfmuGdKZyV nC2fk5+790v216V5tnmP+doFlgX9heiFqoWfi6TFvqXOlai1FDqdsYNBJISAziC0kNzINfQ2zCFs NbM6rp01BU/kMOZS49bhdeKL4i8SbBGaFBHaZiJO2h4vdXZnoIzYrmdyAfL8Cg17vJTxKjfUdNQ/ 7KNorGgl6bDppuijDSL3fzGyM75nyn3Az6zRgtfS2+q29bztPrsQ+wqHIadNB/UOUQ7nOTe6jLpi 3MSIuiQX9zCPVPIVz0der70HfGYoTH5C/vJU44BDtJDAM0FFwUkh7qF7wzaHzYV3RNw6mh5JjbKL VosRikXFThzrjqs/XhqfnRB3wi/RKcnwpHKyeApXCv3Ut9NdqXVpl88kpvtmWGUqnxXOwmXNZPfl vMi9f674fHpeTL7vBccC/YvyhcJFuKJZeDe0Fd+9knc1vsTzmtN1jxtHS5Nuni8rLi+reFzZdOvl 7Vd33t7tvvf+fs+Dnqre6vc1PQ/7Hg08Hq39UTf3BDSwNQo83dEk27y1ebHl9bPi5xEvLFulXoKX 3W03Xx1/7fRG9i3y7bv20o6YTusu8a7Z7rp3p9879Uj0TH2o6o37aPgJ++l+H6mfs7/+s/+A8EDb YMSQ1NC74eMju0a6R6O+iH15/tVvjHOsctxy/Oe31IkdE83fXb8vT6b/kPzRMOUwNfEzZppr+tqM xkz7rNvsz7ljvzh+FcyLzecv8C0ULu5e7FxKXyavEFfj1/LoBLoDPY3esh5/HmAMzkEQFADNIVKR e1EA1YvuwPQyAWZpXChLC5s4Ppl9iTOAa4Tbkad1swpfMT9OgCxYK8QibEHIFenftl3MW/y6xJCk gJT5juidpdLtMr9keeXkd5vI2ymQFal7QpUilSNVIlTD1Wjqnnvd95E0PDQ9tFy0nXSsdE31tPUV DET2cxgCw0mjHuNGk3LT3AOxZh7m5hYqlmJWeKtF62GbN7a1dsX2EQ7GjjyOg063DsYeMj8seHjc ucbl5BE7V3HXWbcGYjrpiLu0+6JHMznd08VL2mvBu9HntK8dRYDS5XfCX86/hxoXIBHQRgsO5A+s C3IPZg6uCLENWQotCjMKmw7PizCMmDt6OdI6ChNVE02JEYvpjc06Zh3HHvfyeHK8XgJIqD1xNFE5 cSap4iQleUfyl5TiU26nhU73pualOZ0RONObnpfhnCmSOXz2WpZPtmIOIudt7sVz/ue18jbljeQ/ uJBS4HZRtZCzcLyo6VLR5bhi0hX9q9tLmEu+X+u4XnOjCN5lQWXO5UYVypXbbrHfBren7wzd7bnX dr/xwYOqu9WlNVceFj7Ke5xbm1OXWX/6SXJDYuOJp7FN4c3BLdRnHs89XkS0Zr4sabv/qub1kzdP 3ta3P+/o6vzUNfOO/71xz/EPzz4qfCrvNx5AD44OL31xG2f/Ljv1ZS5j+Qoj/hu5j9EwSgBkGQBg 9xoAq+sApJvBqY4D3iBwrrZgA8BGFSA+SgLEtTkABSr8lT/4gDw4ADxANMgG5aAZfAKzECskCqlB FpAnFAPlQOVQM9QPLSA4EJIIHcQhRAjiDKIU0YwYRNCRAkgVpC0yCJmJvIPsQM6geFDKKCdUFOoy 6jlqGi2I3o8ORF9Ev0QvYiQx9phETBVmDCuItcCewD7GzjJJM3kwXWLqYxZkPsicz9yP24bzwlXi Fll0WTJYBljlWBNYP7DJsZ1kG8Zr4wvxa+xH2Js5ZDjOcgJOKucAlw1X2ya9TXXce7mredR56nj3 87ZvPrz5G1/UFs4t1/l1+fsEogRFBJu2+gpxCT0SJhN4CE0iQaLiooPbmsVuixdJJG8PlyRL2e/Q 2yknTZBhkfm1a0D2hdyd3fnyxxUoirZ71JVElXHKsyp9qq1qteote3v3TWpCWlu0pXRUdQ/ouejT DBL25xqWGzUZfzJZPrDFbI+5s0WCZaXVBxtOW0O7BPunDqOO9IOEQ9qHPZ2zXOqPTLlJEEmkYvcR 8k7PEK8mH15ff0qTPz81KKA1UCIoNvhdqFzYyfCho7SobdGDsVfi/OLVT/Akzp3sSmk+XZVWkX41 syirJKfs3K28qguNFxuL+oszSg7e4LvZURF7W/Fu/4NzNTaPuev6Gx41nXkW3Up9dfRtcGf6u4cf PvUhB4yGS76e+J49F7youPRu+ftKz+rVtaL184MX7AYm6/HPAZXgGfgMFiBOSArShhzhMyUZugw9 hrqhKQQOIYbQQDgiguDo30Q8R4wiUUhRpBbSBRmDLEDWIwdRKNR2lDHKH5WNqkf9QAujLdHx6Afo bxgCxg5zCvMUs4JVwgZgy7ETTDuYvJlKmSaZdzOHMD/GoXHmuDzcVxYlliSWXtZdrCdY+9lU2bLZ 5vC2+Cp2fvZj7N847DgaOBU5S7gEubI2cWxK4WblTuHB82TxCvGWblbd/IzvIN/UlpP82/hrBQ4J rAkWbdXfOiaUKqws3EdIEVEU6RdN2eYspikuKYGXmN3eJ9kidXdH/s4k6RAZ4i5LWS052d2i8twK zIqQ4vyeH0rjyl9VxlQn1Wb3ovfxaezU1NJy0PbROaZ7Xu+W/kuDEUPISNhY08TVNOnATbNuC5Sl gtUR6xybdjsW+wMOYY7xTpkHSw/VHv7ovHKE11XN7QgxlfTYfZws6Gnllezd4AtRNPxC/e9Qp2iS gWQ4L/aEcoWZhCdE9Ee6Rc3HpB3bHlcX75CwmJh3Uj154FRq6t607+mFmfZZW7JHcsvPR+fbFsgX 4ovWiiWvulzLuNFUBlXo3Dp+58192aqMh4jH4fXYhrNNSi19LzLaXN4Ita90jb5/2lvWVz3QPNz/ Ne1bz2T+1JfpztnAuYX5u+vxFwfmIAwUghb4K5ILUoIOQbHQFagV+ongQ2giyIg0RDViGMmB1ED6 Ii8gX6EQ8D/cD3UNNYQWRRPRV9BfMTKYQMxDLBprhS3CTjPpM+UxzTAfYC7FseD8cJ0se1lusgqw prFh2GLZ1vCx7Aj2ZI7NHJc4ZTirufZzfdwUwM3CfYVHn+crb/pm9c2jfDlbTPgh/hqBEEFlwYWt D4WihPUILIRukYuiPtvMxPaJK0rs2C4quVVKcMfWnULS22V27VKTNZJz3E2VT1K4qti4Z1gZp6Ko SlTLU5/f56XxWYukPaJL04cMsg2ljZpNXEyXzNIsJC0fWZvYfLbzt19zTDjIdajQWcWl1ZXoRicV eWiRh7ySfRR8B/1SqKoBI4G5wfohc2HXIg5HoqKKY4xjJ+My4hUTPiYePymW3HzKJ5UtrSzdMGPg bHS2UM7Dc7bnf+anFuy82FDkemm5OOuqUkn7dXIp+ua5coWK1ltetxfuZt2XfvC0+nDN7KOUWsm6 50/Ijdinxc3mLYvPC1pN2xCvLrwReFvQsaOzrpv8nqmnutfnE76v/LP9wMQQZXh41PpL9Rj3uMW3 4xNl35sn3/7onGr+eW/6zIzvrPTst7mCX4a/pueTFgQXKhZlF28siS0VLCOWPZZfrOxaSVx5uyqw 6r5asbq0dmCtmi5Bz2DEf6NeWm84XX9ffxrBVFfvfxR3/99G8Q3+44ML/rH6uZmZ/+av1CALm/VT CIClwBBrffgO5yyIw8PLwOg3E0iueiYwC8IsF+Gpa8awAbOpB83AamMs5ODtamwBMx5mP3c/W+sN +1Ak1Xe9xmVwKjVIx2o94wGo0D1Q/49OVYSnjf3vsS9owVa261/VcG3p429i9dvXCsld7/fcEEx+ vmamG34RfF5BRuu1LMy7gAFwhasxMnAHMsAU6AK931cCLCfA5A/3uoNAWG94Xe+Plt36s9e/jZKB T2WGvZD1MT5gFGaKi1ccDbb1f60TYcvBwBfWCwY0uVK5MbmVv3QYXn3XPf+RmPyH5I+dv3W9AAm+ /9P+upzhnXLbIyTXP1zNzhMlgZJH7UHpoPahNFCqgIDiRfEDGZQiSgWljdJEqcN9qq8mHkz85Wdj fdz+ek+TP3OGr37/sWbEf8wGbNTv6985cAzy4xnUmLUQ++97Lcg9bL1G1vWnhtO8yJ5BBG0q1ddd mmDkR9wlTZCXk1MF/wKDW3gdwfXxVwAAAAlwSFlzAAALEwAACxMBAJqcGAAAACJ0RVh0U29mdHdh cmUAUXVpY2tUaW1lIDcuNiAoTWFjIE9TIFgpAD5Cch0AAAAHdElNRQfZBR0SCBhXYYI1AAAgAElE QVR4nOxdBXgURxuec5e4K5IgwRII7u4OBUpLcSsUKcWtpVixFqdQ3KW4WwjBIiSEuLvd5XKu+8/s 3l0uIWhDgf73Pnkus7PjM5+M7DckDMOAFVZY8WWC/KkLYIUVVnw4rARshRVfMKwEbIUVXzCsBGyF FV8wrARshRVfMKwEbIUVXzCsBGyFFV8wrARshRVfMKwEbIUVXzCsBGyFFV8wrARshRVfMKwEbIUV XzCsBGyFFV8wrARshRVfMKwEbIUVXzCsBGyFFV8wrARshRVfMKwEbIUVXzCsBGyFFV8wrARshRVf MKwEbIUVXzCsBGyFFV8wrARshRVfMD5rAm7XJqLzkKRPXQorPjtgekOvTlHfLM391AV5J8z76nnn Hi8+UuLUj5SuGXmpZYcPlYjVWMMW3H7dHRnvkaFOrsRAmjQ3v8TV2Q4+hx3OXryv6Ksltce25bw9 NqYfNiBGx2WeOuRP+tDCl2WWdRyYxHNn3zlXx9J/xqDnoRm6CWtrTOgo/NC03xWTh0Y9TdWbHwMa c1eureFu89E77rOFXqkJbhMDHYZcUaGI72jLrRTg0d2CC1dlTD6lQ1eb1kGCV1P4c0Xc9vOKX4/X 71KDYenfMihcA8hhTxrTLOTa4K7h6SLTA5kU2Iy/aXMNFuU9xpREqist0jULjrgX2oRV3f32ESXw 8wdFQUHhfYYmHTsvunZNvHZZVqvm4UFdYt83HQwYCMdfZ4tKSw3ntqaoDW+PJYoVp2TrM+LlEUkV +HT/7pEjx6W+Y9ZbV6KQ0mxFQl6ZpT+kXvh7cnuG7uNfaxGbU6G2MZGy/l2eT1me9dEzrlboyhRw MOw9W/b2oG/D1z0R9QImedNPbA6XZfnqz42pMJdpc7Kv3Sz9+0zJzEnJ8PGXk+KKCWCQeuG/Zd/G afXlbZtxPkGD/hu2Xk63DF1OveglFv5I0iY4YtWuwncv8PbTAVDgGPRYx2HR1T5ePhYB/7UwduzM TOiwcSR36UkfPJjuV4tiIyTZULVp2SUflub2v/zr1aWu+oWrNby9HWzr23/Xi91jNBvmaOmfXWxI iBJn5xa9S46nI42iLzm5vMMMUuOAEKfpcwul71r6DwWZgn4nLRecPm2/cxPPywXx/icXCrv2fm9W +AmR9xg1+KG/UhXvwHzfgKS7+YlSQCKDI/sFri5uHDrF9Ab7ulv49sOoa7xrUIcOZ3TtRPPxpnC5 pMLcAolcY05BGldAONRqfWGZyuw/f4WMcERelL06vDbvFsL2X7eM42yL2v/Mrqzxc9PfscwkBv3O g/rQoc3QXnpW/H4Vfhs+jiZWUvzHNdQ0szcKg91ITq7uHCYdPirkZSKxxM7pA9VOMpe1/0BD2Ljv qL5MWV4HYBggVRFcq1W/Pb6+vHfvJhm6twHEYHmw1Sz9ML2yFADeuxXnA9GYTAoBWF663qtXTS8v cLo1CL8YP3GZXJSvGrwm6dS8Wh819w+DTq2RaKh2vHLx4OzPhr8aNSgskns7vXYGpFdrxSqSveC1 w3LhnBz4O3qtkG/vzGOXK8BLvnsZh8uFEyds4ADx9Pamkkmw98XiYplcxePQzSHP7ZEYXQaQny9y s2ETT4mmACK5QakHbBNnqI2/EkuxVo29YPt36I3d2Bk9f7cu8k7JqtOMBYNcqixnXp7CxYVtfiQz GX9OZ479XbVseU6PC/aUKuN8ED6KBJ4+CA1x10BGC2+mr68vQb0QbA7f3d2DRatc/tTEstjY1yhX fDKZTDM/6XSVqRczGKZ9Ezf8q5drfs/SVXyl0xjM1Hv3RPqUuYkHjxnV6YOHSkeMiFuy7E26dOHj cikdck6lVBmTX3yxPB8Vpq8cDbJ2ufbv09l/XylQWXDygugsqM5dj1RCt16jz8lRGN5NFhHingSA OXhgb//ff3KEjvSTZWKlpkJonf7y37lHjmTHpyurTE0pVi6fnzh8+Mv1e3NHjIg3Rxs2NDYso4Kq Mm7Ey7MRikrRn9wvPHo0+/4jEagKGS9Ew4fGNgsKb94qpluHyNgCRCrzJ8TNX5Fy/BgiL02pYdua TJjvvjMVBFFuYulXw2KDg8KDW0V37/Q8Ok9cZfpALiM6rJcn2UnAtnxzPxpx268W8Vk2Tr6+Poh6 IUgkG1sHDw8Py1EellveMgUlRh6tkZQz9PwMfamFZCZULDKayhEgdZnY8IeeKPe/t+SrLDoRDsUd Pyf26h6FZo594rr0iLG8OLDBSHwZJU+XWvCBGmiV+CgSmEi0MEFr4Di9OeS8SS9uPStvu1bfum+e ZopCCEkoQU00O7xzeHIpuHjH35lnZOFlubKOfRMId3KS8uT+wiad7Hat8YaPibfyR8zLAfX4T/fX gvHnrEWt9uSOUeM9fxYlnpioqN8ha2g7jyrLduli+fDV5WpVahWXycW0OgVOlw6OpKJC7GGewd/H kqcYBnd/nl5s7NWVi7M59vQrlwPYZLBhDlLC/9qetCRCa2YAPs1tTv7h++YmKsLnC7QKwxW0GOwG VqMEc3IKbWq6GxtzXPStKBMRbkCK4sLNfgNamdZ4dJp+vWNzTGVLTkbjeMG+lFVjatxcl5SSqvpt VfyR7QF0fLAXPS+MSlTGfh/f+VYDHr7weGVHyuI9pRZFSGvYyvbPzT7EQ15Ufv9xOZWY2bOoYt9G lBuQC0QobhCto8Nu30etmrhK3qMd1dlOWJpQ2GNklrZixLBwUYPeNq82xflNefDXtSaNTOdV4uPE Y8jfytn937LAmZKGiklC4hncidN3a40Uq6THiLNT6CS9DsMUBq1MCmyYRHiCl1ArEsrIFbU2Xn6u l2P5WfneXs7Q57uh0dGpFeohV+rKtAYB3cg9SFSyjwslLU9/8JJoxXd2by7ku+OjSOC1J7zgr05m GNr1OeRG8K99+8iNO3ILSit08W/TnxPUyxaQnexQF4T+lf0wyTgVgb1dKVkRPn7ExWbmbSCo17Me bdUqbs+OSFBH3i3JFsmhIzcXF03FKoUKObYsdGzdit64MZWQ/k2b09q1o7dtSw/0qDR4yhGWgoZ4 QG/jMkmJHHHlwjQRzlVJnQJRShcvqw0mNqtVaoKCIgnq7dSNMaQXA4oBebHmyGUkNhh4bRJx6oXT Wlt8KpX2SLz9Sv6bG1OGU5yLB8Wyqx6dzSEcZGBspY2zjdTbqSfjm6+ZdX1Q8F9mJJSZRHT7VjGQ ekl00rDx7MOHhK0boPLrdahHQsLRry2PrNQZyVsmMfaUXI3Sf3Evj6Dehk3po0cxmweh4fw8VPQk BQ1vvUrTx0S9rTswdu4V9sYn6vm5OpYTd2R3TosWtIYBKDsyjdSiFWr2PiPZKoUS0+m7mqi3ZTvG 9j3CQTVQsfMq61JGXIhEY6NBT6azq32lVwP7IrrNjtES4w3+DRgUc+xcFbKuBE979kSkFd45rIIz YehYsQDpFF3Gcah4A+gM5VKakMV8ToWZ2MnfktE/CuQCqPib5sQR1OvqS5kym3P8BJokajWYuERm EQmMa450/phQVRVq24fio0hgmqPt/fO6EZNy8vINxDqfTGY4vCcP/k1c5ze+A5IJ0izJ0TDUltOW 8tsH0Dk83u7pmWcS9Rt3ZzRfW698sFpKN/zXrJUcWJkCf5k2lPVLuZ5ePl27kuaXleYUi4AeBdHj dEVlk4gkWg7wgH9araZ7ixio2E2bI/TzcKOQyW+YUEekoHYeOZj500XUnZHxUj9X+/Xj0eyg9RhO Mx44dkVWeF+t0xsoOFuYiO9t0Djkw/sELA7fxcnu3JUIKD7b1EWp+fiSQBQq0rj5vK5N6CwW+/L6 wu131af3Fozv7kx9/bRep0WxarihJjEYsOJ89R/Lki5HILK0caGzaEhQ6KTKw/fQANpzyMZRyHd1 to9rXvT1VLSIKCou4Xu47J0YJdMDEo10/JCQybVxdbRx5byECjWRbSJOxr5NaGzT/klZCWps2D5k EvL5djYSUIu32zR0onp6eJblKzr3iUOJF4lADZuCZDkR6/gJGxab5+rsEHgBdHmQ7OKKmuWHn/0x OMwVpS3bpRpIpNnz3DydbSA1kEgkaYHcYIrIZHHcXJyaHgftQ5Kd3KqeJBbmo+Ddm1GZr8id6Uv8 mzZOWva7tFhkHCBZGZr1P6fDv1PXG3nbGhOUxqA2gXnXrgUJWANkUJ9SsWn0FPxtr2a0glMgshC8 kOhrGBM2cjQeGkhArzfkZ6uWTIh/XoJyadmJRaYi1ejJM6RWdJ7IndCZ4eLmzqJTr54tKdJKqBVn ix2/tgFnFYUF+iKxytkk4f8hPtZ2ItvV8ezfDqUlBSKJwqDH8tO0PyxE3bxzbkKTU3UCvdkXThEy hNq2Hs3bG0nsefsEZ1pFpd1Wl5QqHYRGucd1IptJjFDgmCRj7/3xN5o279zOd/XypuL7ciy+sCbf uEKWVYKozr4hFadSI2g0OtEhZAyjUt64lKAwLnX4ssnEMkZUuGp4R8MdfKwOakVtAoXAlmSNxlCq 1DnxKIYyeTQefuNWgZ2Tu4BDh1MiDM+MRkLMPqAJHUSpAweyezbnebqhlY+x62y2N40uTdPnF0nd HXnSMo1ag0mlmpISrahYzRCy2zUXwERw4gIzR4vJpHCLXQ8gdKTs3Mxxc0czjntXEYEFDOPa29lx 9OS2rSMIPb/TcDaZCqtv2BOBUpmwgMcWODjboVW3XA3yqVEbNQLJlCztFT7CpJO1JUjMsu0oAXbA 29NjVK/I+AIiAqmWI4pAMm2Kfv11qbO3+vBhB9h5rVrXNCcCaZVOMa6DGLQ6MtmUDbk8oq2z6vhp tLrVok15xEogZqZ29Ko7rnmfWpd76vLzcpVqHeR698/Kd55GTG1w16jQx00YeCF/moFkskdzulMN ARQr0J1eLM8JNfa1E5taswkr8qry8CV17wCAYmiNCtqYEWJSxfav25oxcxzDyx1XhvES3d4jCzuk nPOzTZ82AnsPOzvMllRxAZXmjNQEtQTTKRXgMydggHebjb2zDa7s1KoNHnXUDGwRAwfa6p3px1bV jbyFCOzHrVwnV+MUjmwUQ5hOA18ZCZjOJFFoFXbbSQRBKspgY/LdqWwqhUl57USgRRC1UiM68ID0 HbZ+Ds9BrJpqT6UyGGtWcQcskN2+qnnW0LgD4canchx5eFmx4iKJE88x/jGRKMmRxxCY1jwJWUCm oUe3IDbYq8YAJrQ3TfJJxOIcpldJlallHYZW1qUvXPFxsTfyI6hP6E26h8CV/NNcbg13qoenNw0f l2Fn0RDs564bMzBFrEThSBSwfA3f35Pq7uykLlVp8Lgd61EJ6gXoOAQajK5CFN0Aqt6WIztTqWRS xGWUeEB7+rzZ0rSsCOLVxLncjk1pru6I87r4C+BUOA0tMmOZCYo2QeFCJ8alC/UZlt3CxMcrCVhm xXNg12OSYlUYjJifoWwXFC5woF+4GMB+DWslOrKqXQVTgSlUV3dPwu03HwwbJ+nYA+m6Z+9lDe8I /bFIfELSMpDOd3QEAImQJ09L4/cjSg4czxM4OHZrDE5eVRbeUerm6pFiZaoCWogwldzJjzp/JsfV ge7paVw9WfubV/9xGQY9kMv1y39IXg7ANz/4TB9p+0oFTMl98NGiV6tcbSm9DVQafeUKPnRkp+jl Sm0SPly9uYDFrMRESFo9Ynvy1NJXE4Eg+LeqCNF/TR8qz8HtDZkq1SQSuYrWyle9ZSd5fywqQ1Ag DSqcHl2RPmWQ6Dbiiyg1B3J49g5oVwsPmV6IFAESsTVNowjtTOsTJDLVYiASxSgpqSJfA6Zj+bpt WGezciX3l1+469bxtu0QHDos1JpXu6hgxCim+ciCJNdwLZTq6+NDM4k+Mj6of/lNBalX4ERe8iv/ +FGbVoGuvr4+aDPFNOWiscoPLalw7dUG1wz96K/h4wYkhYj2Cz+tTMOnphOmc06csOnfxcnX15dF CEMS6eSzwEtnXX78gd21HeJKpQXqTv1jqqgq5GCgwuL7/gdNrvzt+tMcTs9OKKKkSNO5T/Sbl+ff /SwE38F4DKuwAMludRlUmNBj25ZUHp08OxAN/rPnlA+LUJI/dqEKOIyAzohjykqxAot1aUADXw1l mPdCChJ0d6JYvt6eVNPQcm9k//CB/x8beaNHMFk4p9q/MS06T/5K0U01q77zHNVPwPs3JX03N73K Eu7aiMZ6jXoUOClq4IsqH12ImclLY9SQKDQKPp7w1hHaVF1CDNdmlFqM88bDaUx65YIwOShZ8hub ENPqRHJ8ktOVYStgoqk0XoqEQuQ5fwBdyEHUNKItGr6/7VFrDVBTwENo9WQLfkEo6ZYrFnIpplUb tTKtRGKuJkTbDr49evh16+bXoUPtZkE1/f1qeLqivSJEmzrQtrfg1oM6B7bZ2ODj6O4pUYt2z82H IjRa5LLzomzeJdyz1bZdc3dIXQIeR6vU5hVpyzvZQlVJzsAJGGcBzfA1h6yXVZ8r0xLeDNK0BTxI ugN6I9J1sEWyOyWtfLHHycN16Mg6q9YHXDjuCh9VuZqMQsvdJrMsq7wD7+DmMni4/4rVAdcvecA0 NYXajIKqTzvY49pDgaqCJxwJk0bG7L9dxTakXmPkgC6uKPecaOMmogMNNWK/ld7wV5yMwlA4sBtI kCApAj5eSCwrCz+6QwxPLeg5xP7Ovdq/LeYRuwF/78zvMCjO8kQgnclp3qb297Pq3bldv60fGpM/ LkrDKjaoOhuRNMehOomu+gn490Nl0XdKZm7KsCy8Vq1fMPH5Y3xJftpABpNJ6zocCjGwY66kVI5G uF6jb9UFrYt8M5JFpSPyyH6M15YL6Cz6q7mwfJEiGvdInZ5f3p9RdwuGTEqyzDfqeeUFPxbr7eqL TGwcZIEeZII9+Hga2QSJSuIyACH6mvdCBFYWpZLKFT5NiN0LLL3EGNegMxBSOSyxvIRqBaZQoXVr jULXvRvS7nwbQn71+p0PEpkgOkyvozPZdZv53ggLnNwVzSm0cl3bZuH5+KmhnmNQSYoz9P61vXy8 vQQ81IBKqbZFm+g+PaIxDpXYy/j1NyNFKUViQuNn4ryyWUc0LNPSdUq8teDkXaYg1trRT8shqKd0 aiywiSsiXTsbonbdu0QOG/LyRmLZnJFRWy+VGpudRHJwsyM0D7Xcchu5imZf+l3UmuMl5ohCWzua sZWq3sS2c0EJX3tQgQWoSzXPEjS//5h0LboCDZeJVcEtnyMXjRTogSKe3IiqT7KjsnhIE2HbC8xl 8mrAYNkZVTl/vPQ7L+FbvObtI72KyeG161f73pNG3b1QCGmGolWzCCjSZdmlQUFRMqWRmql0RkBt FlFjbUUKvvEXKoCLI5nCrLgr+A9Q/XPgqR0oW+/oQw8VtzwhsrOFU1CgVulFYiMhzVgjcBRwGRRS 6wHuYBVicl3aRdnaUkUiI7Ps0ZpqL6xQPaxiKxjXtQF5YFf2meuKr/vG2jvSWAyyqFAjRxoaiE/N rePragytw1B4i/UqcRGKXlr5hEIFaEwDiGZaelk+ljt4MVLpbevQaRxHwrNWAOTWSKmOyZK0q+sC h3kRAOMGJDVpw5XkaNJSNcYl1qOSkR2NKUvjNQN6vrTMa/mPHFfX99sVHLuqfo9v8/uOQFO43h0j Hz1u0qy7O1iMGrNb++dCGyqDRpLLdAQRclypBfn514+4tx+e/fRWWfNWkbZ8SlERoQVA9oDGsENL 2FwlhfHadi0jmDSgNM0vDAV4p3C4Q9vRTtzTjhmcwOZSeByyRm0Qm3YEvbCCuwn6u0tTDvxM4vMo mM5QWmYcyrQKpSb616IrdZpL0XoQnX5mYwaPR4FzELFp76oKho2jRz3O08Sy6BtKw/hyycO0ZcAy q7Rg4XdJqwUULhvqd1DT0Urlxrz27BMK7dFWbXwGemzQgc6k42oumezpQMrA9eeFM5guAmO2A4az fj2sfHlWrpil4b6i38Em+/l0o1FhqaOmQ3GEdewUFYx0On37NpFsLhmOQ3mZToW3bp+hlZep9j1F rMe/GUMgrJ4VLPAxJPCYdY2WzkAUqNUY8vM1eXkagnpd/ajb/hS2qsHy8cRXcUiksJAAYpmdoF4o 7PYdEto5uBB8kcFFZTNvAEAE+tD4zuWPC1bVmTAINURxoTYrS01Q708/8xn4omrnzkhuTO37ymDA U/eo4huVcmik+N6pE5XONK6fefcwnljYtJjt5mgUmCyTIzkeybOLDxsRjxEhshScesfPRAHyIjV5 hVXN5+nkP3YLBQKbN+whAbR2gF5XWnl1re384LY/dNRvxygsKYWN+fRx46Ed0WgrFesKCrUE9X49 kbNvE8/Z2YVb0+ncQXcnPhSkhsIiLTG0qfZQvOPtQ6Kvno7kKqbHlBVXB9T40tmPvzVY+j2qi0Km LyjQEtTbsifj4BEboYPzkkkorl6LiUU6M/Vu/0vIt7VcxcErSSWVi2Iqfe1cxLn0OgyW2Uy9m3YL ecIqTnFA9JqB6LAgVZdbZLG/SiI9CGvSqxVqoEEDHEpLdXDU+dfltmkj6DacdfyEjY+Loy0ficS+ C9GSW9t6VB7XSD/rvrcdPtzRuTaNTysn1DbdXaBEgQ4l6kMjgTjYV1iR8m/he/WMb/36nBb9mPMP 1pr2nSPeOIb5870I6l2+2q23H41uMZ/SqbUZuPAY1NY4I6sWkCrJt+qCQlZWVChOSVWpVZjQiepk R6YzWLb29mxGRb4MDNHP0rKKdA5OFHsh2cbexYZf/n1JVlqmFtN5+fqaR29JcTGDLeCyyxORiIrv 3CnSGUjetWi2ArJAILSzNXa/Riktk6vt7Sts+itFirP3slo0Yft4VX0Ai8CJ/fH1guluHu5C05Ky Xq1Kycplc/nuzuUJStJFq3bkjp3AruXrS/RVbmZ2SrqCwSHb25B5fAHbQLsWnh8YwGXkq3tPEtkH MXYtssF0WqhGU6g0gY0trMxbGzMzI51M57gjGV8J+qLCEsjzzKtZElFJXl4pnLjRmCQKmcLj8e3s bMyDCOrhRcXFcoVCJ9Z8NUHu1oi+c42vs52RDclKRfGJJXDECm0oNBrt4D5Z89704AAvnmmJSyWT 5BWIFUo9jU6iUklsLtfO3o6GbwqUiUvSUsRpWTo9CfjXprNYZBtbBxtBhalBwrO8DJ3c39vB07mc fUolovQUUWqmDrLw2rVoHDZFaGNvK6z8haAZI7uEJ4iBazDz7631jPWaNw8sWwZWrABMZmajZpzL 521q+mZjVAaf7VQqBgUFYM4csGsXMBjAD9+XzVvA8vCgNWsGkpOBRgP0+pI69biPHjK0WrBmDZg/ H06xwIAB4l0H+R4OpRSana8XSEgoS0xU/zDP4cQhlN2kSWDDBuDgABo10qWnUxUKg0xG7tZFf+mK srj4eufvu97cQrO1lbVua/fkEeBywaxZRDG/7xf+MAcIPGh7Ntv7eLq+roLvi49FwP9HgGILLQO/ ZWqd/ywNEXATxuH1tez4jDcH/tgoCkvvMb2kRVfWyqX+QsZrxYFeb6C8fovuk0CcUtplGDp2MXqu 9/fDqu1A4qvQ6XRUarVNMI/9kbL+L6SFbdorbFDbm8+sts8ZPq/u+SJBoryVej83PLqAdH4Wl8Sk vWkAfG7UC2FTQ/jHCrTTc2Bd+qhFmR8vo2qk3nnDIwjq/eFngbstvxqpF1gJ+F+Ghxflc1B47uFb rXB2/Ub6/UzRvGeN47vRnDM/S1Io+ujfY/9zFOML7Ru2Clr4MbzcX50H/SP8/1pm+SQgkTB65VWA T4CmvuS7+cDJ930Mw3xOqNHYIyzUvrhEzOdV237Mx8OfN5oU5ucxOAIB7x1MQb0nrHPgfw8XzyTW akh19/TmfAaCLz87U6UD3t6en7ogVvwjWAnYCiu+YHx6UWCFFVZ8MKwEbIUVXzCsBGyFFV8wrARs hRVfMKwEbIUVXzCsBGyFFV8wrARshRVfMKwEbIUVXzCsBGyFFV8wrARshRVfMP5rBKx4F5uxVljx X8GnIeD6Xt5md+yZ+bN/u/iOEf3f8uWtnsMXyrTVf7p7/chey3afAMg6nyhPWfXFH/8EX3u5Pk6R vD1cdUMhySsy3S3Tv07N8JLqr5oVHxWfhoBjMzPM7uz4Fy+TH5iedOk5b7o6OeEtCVPw60eqk4Az kpH9h2m/75oxoj90JIfs6DT3fDWmT+C+rvySQa1SLFa89samSviHVQ05t77j/OuEe8u5c4F21s9L vzRg1Y3nT8XJOeo3h7HM98YvvSctPKkuzTOVyAd6Zr+4TzxcDU+Cjy9vHsOf6ltGXDG2357QXFkh JLAx8NHbaL+Sdv/CThhswqbT8LEsz3iD5sGbEZhBw6CAZd8Gw8cF+x+a0zHoVN/1CISenYbNsSzk 1KF1iLg6DJtVr2ZoRtlwn/J2gzW8sP0Hwp0uVppj7RzfbOLiTdCTLXSErEQhzibCLNt/Fb7NfXGP eDwVngkfJZmEhUomh8NILtUkPTPSUt3RWy0KYqjniWxQ9Jv9B3zIfIS0Fae6rWHij9e2m7wVtUyd wH5ERK0BWzi9v2/rcdAd2G+i4ZXaaVVG83rLj4T0szAKpsGwQGPbGvrXR5eb7L0ThWF6AQP8MhnZ 1Jy56/57DAIr/i1UOwFrAwOfwb+35GpBh7/06TB+wdGVg3x7/XobPu7cfQLDkM1BpUb/dN/0wN5T VSWJgC5Q6zFJ0mUAfM0Rd08aPnz1tYOT/PDUyuCoxkyyV6YT4yGRFc+UImX8lQ2+gd3h0MSN4bVV 54V5N2ppTufrxqBGnemVSqUrCAGgGXREXDsIfxv4u5+PKISOwuRroMcW6CiNuwLs0bVdw9ydpqw9 aY54aUEbmM5LCdJFlVq9LwA34kSitId0JpdQDfI0WOzF7ZBIiRxTpTqdChk0LtVikG5CchHvOxea YE5wmZDfZepm6Lhw+a5ejWxlx+bJJner33DFtciNfeHjqkuIKVyMLXC1ZbiCnD4AACAASURBVD9K Lj26YDxsCi2G+TgyzzzOqVS7gQDMOPASOu6GJ2OIM+4FffdYdso4AQ80+05bmoI/GuzRB/PNNYUR zjXrvesQsOJfRPVL4KgwcVzmWySwAwASk7tjQ9e/QrLi7h8maG/f3y9EcXcZLDtbCrlmi/4iqTrh 9h7PXvuNxbUg4Lhza9oMnghIdBqNmnJrQ9Nh3+MBIMUq8EsfXZRF6QBwXDhMt3qt80QKzKCG9Btd oFAXPLGvGWROx0y3FfQRvdwBN5/QYSAS7/7uNs+LoZTCCuMvgdbroePkwkk2PkhEj56xATIXM5a3 DWo3aSmRmgzdCc70dbDh2rkl5UowVTzgOzkI2fbOnUvkOkxfCFx6ErFc7TiQgNdN6Iay5DgVSMwN iJhOscZAPBTFHgCBi6Aj8eZOvwYzYraO6L94H4apAL0m9Fzaxn3nudjTiya1mfU3fDwxLWD5jlsV awcVdQfLjnh5bTdov9UigIHDICWWoNxdkIV3HWyDxzkyTfFzgZvfm/vUik+C6p8DN2wu9Pd4nWlu I7p3rzFiyhrkUmbffp47tKU72S4Qlkacfn/MyIkkMkmNkRJKlUkPz57YtkLP5ZU82Q3Hl7ok2fKi klptuoec2uno1qUPm9VvzIqvv52GWw+nOCOr2VRkch0teMkfpRdmvwh5dGqjVIdu2qjryIITR7m6 gnX/Vy/jkeTn50qhIFbeObOP8NEbUCga2w68RBd8YSQSW2gDtev9m35YMmWSOeJTlaxXn2GEW4mi qC48jZcWZ6ujDscXykFZQWRaYVHejQtLZoo0bJD3RI3MWqoVcrUBA4OXHoaNcHGa75gtV0zpQQ+g 06JaZ2Zksmx8QepV6L5x/oZb505PQ643b1QHWVDXIPNu3fo1isqIdvcTKp4+hxF/P59v6+JcsXZ6 wDIqKZn56J4+lsAGvHhqUW8SmUxNzy8FWkkeoGMGvRKAJq4c2GJKrQZY8Rni0/ANjaimybrXuhM3 oYezyVpQk2m/w8e2gcb5p2f9pvCxZaNaVRYYPl7NUaWdngMdUOxCsQnIdEJcCXEh37VdIBHLvmYD QgIjMaothh7mRH6b1IQIQ6eBmylGzWBI1yDCkytAwq2pt310MZJLBS8vAN44FEJXVsN0o0Lz9j+Y U1vWNujXk8+hY6gtuJUtmz95EBGG4uRbWKYeEVTfWC//Jkodtn7OcONbCjkxM8pcx5NP0s0Jnp87 gPC09WoPKaoOC5mkZQmdoNQPWRk8dfcFzKQ7iCN3BX63IeLoAiK8a+1G+oq1Ox9f+svgpsSjf+Ak GOXFlV2AP5XIiAVo8Df9xjoiwIjpG2ElOfhsH9OKABBUX/dbUW2wmtT5LyDiwd0mrdsb3ccWzIwO vr+q3yctkRX/Ev5rBzn+P2GmXoi0F2Ks6rvBrPgPwiqB/2uQ5sclKRyb+H7EWwus+HxgJWArrPiC 8V9WoR+d//vDIxvMy92YSvvmK+MrQ6VUaLWf7ExiUXby1avXPlXuVvzL+GQEnJv0iISjbsev4eOe 6U3arLgLHfKcqNsx+dWSRYt+6PAjUMaTSJVvo5FlR1FZPMK9YdOeV6Ia7LnUo2Hp0HXz6AoW/f0u s2GxOUwmDVYtpqiav6w4t331m5kJVvbC0cNv0+Erbwr0z3Dxry3mInzgpVCKWFOP6Bct31FN5fp/ xSdZ+06/uRUAQUahSCmX5mbmQx+9TqPDt3/ubR/VcsDYN8S9d/Xaq553Ll981dNcO5lc+cpLQ5mU 8NQAQK30TiMtgnGHLEJHlKbWQXvaSv0rCbweeL6GzPhQ6HiQLH6PmK/B/WuXzSknFkot3sjvRyRa hry+duDXc3a9NcEyheqDC9PZD9zI1hBuqVT+XnEL0mMK8JyJHjFoEIN7Q9MWJEfnid4vi/83VD8B L5qfvOlkyZvDnFj8rcDNJyohuUxmJK2lXR3jVFj9Ws5mzqLSGQ4t/p5wT/jjFgzTxM+4MCMzJ6RX NK1rvBwkqkgtzU8S4u6t59CpTIKAtXkhgaN+go7i5HuEvjHv94MFcXd4tWeWRJSz/1Uh2eZUi5Ku Q6pm2Q+EGRBvc8vQkN25/Dvi8Wjo8wVT+th7NQTo4vJAXcXamRnHrt6C7zYcgo6ZPVoQES89z4L8 oaNpl/tZocoegDKLWOe3zCReLdl1smLtSsqZrv/XiZeOmh5szfmOG9lPwOcCwIR/sOR2FNClZQAM 0XH+FfjoI0Qax+Sl6zC9lgXAqG7oCGrnluhS8qGrLluWf//Pc/GUqd8djIKPx9fPwx8pN7JV5iLY unpimALYdC1Lvsv1boiilSUC0NygEtfE+9DRq64l11zxw9dEROfhh7U5t2GPPD+22Zzagr+eyIpS CHeNwHYw/LbBvYjHkfN/f/NY+j9HtROw7l3OQkOsnjpp8MB+FDIZeAZD0fuND4jFOzznzo7gviPx IGi4SBTSqUO6O3t8q8qEaqFnYnpudvxTcyIp9w7ROLbxGflJkY/VBqwGABP/emA6x2skieIne4KG QQJGk9JkdERRl1FQlvboBE8wwdgEr6gh2wfXHrbpHPQXx99guwZ0gIr0y/ysB38CG3cYf7aQf/ph 2vEFEzx8BkPpUc+Bf+B2ilarkcvlpaWlxAHs48cPzpn6DXTcjStIvbPbzreBXJwb7GT/05ar62Z2 d203GuYSWMshQ27gWxx11MkzAdcO06vmDgluOni2uXapMc/UuHoyGIDYfETvowL5HWfuUWj0Dx7F mIstLS4Y17XF0bBcoiNsAFi47WzC9d11261vx2N3m71HrywG+AFJNgD12gxfNKplr7ELMVUyAOUH S3XicAD4xXLd4R+7rbgLlSO0JSXRYRpVGSG1R3fyu5iOd5UuD4B2UI4ibothkzvUmrb+5I/9/Kbs DY0JOQt5RJq8XLhyADh8+6lGJY3PlRaG/oH3CIyqhuqNFg/QAIArsSUXdm6BqRnwzgp5GqHXyVLy qkGF+Q+j+iWwXq0zGN4jfD1H8ChP2RkAEf6YfWtHs74jkEsVjTgwjTVo5GoiZOfgenwex8Hb4lS9 Qd0goJ49D0rWtgZ0/tlYHb4FAaeeWzl43hpN0QuevZs53struwUdjKz9VQKGPhGZpd400LlXy+4z z4Wu7jFy06Vj00aNXIMUgbFuvMuROScXTuq9GAmuo+M8l++45e8H4V+3Xj2VQQGjE3fmJeWhc12n F6GDlmS27YZ96IOenk4gAZ0aw/zsQZ66wkns4ufGuetXszZUrF1zokUHoi8ZEAGnR93wqwX5FVh+ 4JFlyTf06XA0LA93IgLWmvqETQc5MqQoECecWfirNT8OXn0lvVILJB6dOxbXGvbN7rQtWiyN2tVu 3GrLLEZ18LuQhutAqlhQ81vUAgsH9Pw1BIr+YjXWHC+/q0/tjIqq794lI7w90LX0YrUh6fh82CNE BWmmQhIVr1WnvliBPPatnOLtAQsLEkUfru3/P6D6F7HIdMpblzbKFz/U2bGFwMsean2AOD/t6Fcn M1+GO9G3qZhGcerQvC4k0ssn9y6GvZCUyYrSY83pZCc8fx79oqhM7wLu52lQeCRiJNFlwN0yO51e TyJTpAolMUxiU3PRPw6r6sIZJLAs/q6CgHaNb156eGhjv5Yz1h6eCTU6SuaT/fC9h5ycki2qUd9W GhkJCzj9eL5LHa+4eIi42BcvGHjN4OC99MePtVwE2669hE3i16ytXl7yw7dtPEkkOxuw7QyqQkIx sKWDZgAozFlTALBH3wwc+e2HIa1rvDDVzhuyOPwkcvseIFmERGJyETs+MRmqIEtHT6qqDpVAplLp T5PygCo3D/AhASvxxm3gUOPiNXR+E5F6ed9o/ryCe7o7hjxIJdOY98KfozbUKMT4yrrQzeNxjOmb bSbqtIGz11+e30bWbr4d3oVn09Q5qQlu2sQOY+eYU20+/ve0zJwjC3oP2PCM6BE8LxqNBqSmBXtI qYkvY/Jvbxn3y5n6w39Oy8xd3z54x+4L71DB/2N8ErZxcOUUcwEex8NpITarkxsulrCsu9sadh9G BNuzcDwR5pv5f5xYY3R7+vc2p3N+42TC0y0Yad2JD08a00wtxkyCRZZ0ftRCtK5zeJ0x083nwnJe 3Goy4yyRSKVG0JYmAz76lLfwyW7g3dIcRqmVO+HRG7dqBegtzUeOu09ZXUnhMCdYmoemhZhBO7ZH sDHro/dU0gLzlZ4wzJ2t8y37YvfCsYS7z+x15tq5NBlEJAgl8NNMqKVjDUzXRG+99cIy694dGxol sEHHIw5+41AWJxLhj4elmCVwzLnVgW0WwLfufJBvDooZ/F3RwXQhz4/K4sHnka0DiLhRxUhzHtWp 9uEXuFprkLh0nWuu8osctLomL0wzV+dlpvFguUFTZPJjlaoN0viTRI8QEliFN19+8jNjEJ/AnPQX 5kQypG/5su3/HNaDHB+I8GPzlyW0vbC0x4cmoCORWmHY4+osE9T8b52s2XYwn/ZOuzsGrUqsItnx GNVbBiv+TVhNqHwgMmJLMRbtHySgxJeLqxlNOg1598BQPbb7JzWw4jOAVQJbYcUXjP/yUUorrPjP 48sjYINaHposJpx/HDgL/2lLE7fv3Ps4Jv6VsFi3rt0snzMSqzZrqddqpK85o1iUlf7Pyvve0Caf 23r7xdvDVYzUunP5B8A/j5tmdqtk4szMzJyc/CpPdD+98WfPHj369lto+W5o20D9q0Ffj7Bz69NV bw9mxUfBp15Fexs0pfXdQM1GLWq40RfvuQI99i/qRRQ7+fp2whG/b3K7AUM71qnJtnersGSpV1Ss oKFzhzZi3GAHoLtZBkwMOzR0w80q8+/bsfW/vAwqidwy59i9Sp4nFk3eHJL72jj6Uo6tq/nJ0t7I lqlDOnYMBsCTzXQ6G1WoFOXANqkf1FrIZS87/3LvzM5P4tJWL54BXBqYo9Rng/eqMkwkSvE+Eayo PnzuBLxxwoCu/Q5a+jTA+Y7agE0Z0QHgNl9f7hlHWJY59/t0nvD78qD4mYpTR/Zv2bmHOC1w+tRp zKBas34t9F+78ud8ifGQQHH2S5EKnXO4fv5Y83qeju5e5jROn0SnrEd3b5+W8GTS+EnFqvI9I1lJ 1ubNW4+dvg7dfy6flF2cM3XChOh0dCDlZdiVeQsXPUtAOzoZL8O2bt325EW6ThI9eeWR40cPX4tI g/6luckrFiBRqTPops1cDH2yox7cTJTEbB1xOCQVPkaE3ti6bVtCbunZg7t7dAqs12vK+j/2Qv9r Z49s274rORed6NDKi3dt33Hi4C78bKMRlgQMkfbwmNOg3YR7YU/PBRcyza9mdzBaF3Sz4HSNnUFx UebBg4fK8FYrSI3+/fet56+GEW8vnDq488+/ZDgfvHPl7M6de/r746dB9Yod27btO3AKvpBlh+eI xbu3bT5xxWqM9uPiExOwXqsvLlaVlGjkiqrPtKfc3U6jGD8GKlPr8IN7JCoAWSKVNwCTRraIEBlO Tw/edSlaq9Us+baDjfO35ZFxAh76/eJfRvZyC+pD7DpC75Cb1wDgPHocodIYTzGfnN/jfrbsyebR dIZPblGxe8065jQIYvB3twEU2qm/lnoM3mlKXA3IlLsR0c52/N2PM+YNDgQk8qOXj0DAJE3+YzLV tig/xYYvyLi5iUJjRMQ8A3S2NOm4KyC3mzQHzlvkaj0JgHk7/94+o0OBWkJoClfWzVlwMgkS8MlH 6cemjqQxfF5G3gaAlpseN2NAx+GL9sTHp5yY5clqPCji9nHggAxocwDYc/JKv6ZsV8/vK5XZjPTH x3qsMhLS/f2/Gjce6nTQ6AyzgsH9p09dHYTMnjPM4SEBAzJ14neD+cGLMb0MUOhPY9DJEyWGNfV3 btD9630rxteYdfLu8s5sbvfrp/bihTd42oJFf16Y923nBmtuQ5YKAOXXP3c7B3T4wJFhxbvhExNw 6q2USVNiJ02KHjEh+Q3BdDpt2KmfqZy+srQQvnfjPf3AnnPngWO7a9sW1l1168BXAmJMNhi4DLKB /Lu/OzjY29gIjyYVgvKDimRMr6RWaUEWys/JwbezZWmXfoP+tvZOZRavCGKo7SY4dD9DHHfP1XM6 4Z8XdrRW/Tr2Qi5oPFijN8waEDBqYxgevuO0EW0PRxs/5+jQyDWySK1XFLB4AkwV1/ir5dDz8Kz2 d7JlrgBQ6Yxew3/VykoAaAX918wbTBDwsdDUmvgnUPKSDNBtLXwVfmR+70Xo5KarLbtDt7awnOcf JWDymI5zkEyWpD519RxnKrIa8L0ta2dJwMb21Gp2zhreuNf4jgDcCr0Xk5hp+RYS8MWYQllOHE8w Nnbv+F7D+nBZDK8Bc/HaITl/ZcecPS9krnYcCc51O0MlQiWDjMbF0RY41JRr9ZCAD4ckQv6cmvl6 td+K6sAnXsTy6ei7fWvd7dsDDu+sUWWAvv1nA2S0kerm4qOzYV06dLRO4Lff7rs/rn/f2bN+CGzX IWcz+mbgwrPU7YunR59Ztv92ilO7aYWFRSKReHhN49dLmDwfAC9U3dcUQ6OUUEjAtiWS3hd3r/D3 nmx6gwQ+/KeUSQa09kRfPRoiiRdqjVgsJ8ekF2IRJ9f8cSI3KWbT98RB4DhFmdTNDh1mkkikQA+o JBKZydHpDIBEAhTU4KsP3HVmUdK1OqW0+NGx+RQa1AzQt4cNHHzh74uQ2wYiYzKg0ZjgMTL7aj58 ajDounw1D5azPiVBSxdEnUff7iuU4vLKGOSAaTybUSrG71sik4k1JkyZ/fWMJag9qTQfLp/GQGuY HVu2rV/L4o4GHF3qOzD4XK3hlFSek1zEyi6Rph5fuuYclMMoJVt79+dRWWQKNT0HfQ8Ya7Q4rb0a FosVJq2Z8xNsZxsubAGyD36e2YqPiE/KPt6OToHexoJ6NsgWKZdO6LApBE0s4ZDPlusxHRxAnGPj BUdvpkBPcfZzs1lZHOWLqXtDkzGDhk6qWgKfXdH3WZGiZw0jwU/eVC6vAAstd3nbUcUwt7JUVvla kb5FgPGqlQXbz41pycnA9XFYsOKEu4S/a0D7Z9tWm8uQkf+ccPi2GaYpfEi4+fbuUP90EhoPZv94 LGFHXxCaVLR71RQAWFCVhTQm1WNPD/7UayGajcdeWESE5Ho1gY/fdUVrAnQWvXwOrM0znSsHnjWC Vow0GrK1t7ePFckD67gRjz4BbUs1WNuqBoA7+h4In4BQ2QZM6+VsiyJQGbvvZgzwd+Tz+SwOnevg Lk1/QBSaMNM/dUgrIuWBE+a92PnNpfDsV1O2otphPcjxL0KT0GTs8YiDSz51Oaz47+DL2wf+svFe G6xWWPE2WCXwvwqFSstmWs8fW1FtsBKwFVZ8wfisCdggz169+QAsIE/Ar9GgzZPTW8gONbkMqlav 5/KEPvXqLJj1U536dSZOm9ehmd/7Jq6UyVhc7utytmNTChRYzINLGfYt+vvbvhIAW7Fyy5LFM6BL pdEzK5qtVKo0LOZbrnd7K1RKJZP1GpMDOB6dWvKo5pyZjfimEqElOwqJpC2JDOg5I/7x/X9YADNI pCAMe/b2cO+RYDcMe6vhW0ylA0zqu1q9rOHumJpTpMYwc7vfPLqR3WZCS3dO/sPtu5O8Fn/T813S 2TJ3zJWXopYdu/w0cyqN8kE2NyvCoNOQqPRqSOg1+KznwGQm17Om36JFCzPiHv++/eqUWXNreLjv +vFHHz8/lTi3oCQ7WslaMGXogLZ1Zm68ZI6lVr/TPXpsnq3itSZaCUtPQMjlufOr/FyWxODZwH96 tYLFqDwy2KygdynAm9GIzX5zAKVMYjmlLkq62nYZurgQ0+v0huplyu9nFvvtYL6JMRFQFWeyaAPf NUFtSrawD2ZBvRDjR8z6fgS6qK37uDVLlr2r8dqn4WFzNm9N2LKGTiUr9f+gGTFMq0O9s3lg9wOP ys0kG/S6au6cT7oG/k4gbu42oxcARsOqmmzg0Rx36YmK7Jg5jIVvgZpsQWECvuDUppk8LvdxkUar ltnb8PkCQYm8hIvLXvj7541EaV48H3kLJOZ7fg1qDp7gpqXfZasxBgWkRp7icnn7Vs7m8Xj5Sg2G KduNmhv99588njEd4+FhbRoMQPggk1CqHJhyp1HldxdChGxfyuFwhN2R5/Mre2GA1RfioduFRv95 zlAWiw0LD/NCifC4B+NK7QSCBV1bQB+Yq1qcCMP3n4EMSp2c3yPSZGH2yG/juRwmoDK4PJ664Ilf szbfBAthjYi3TQQCGOvQg3IDtN7OtgcW9oN5RZToeBx2pkiF6QvdWw9+eXX5b2HZfB5v8vLtfD6v 6zLi6kOqH3zguxNxV4zqCVPrPXUjdNcWCPbNGgkra2m3anATlN3151kHl0xeduQmh80OmncM+qdG XIL+wt69QNAcYwfKSgSTDrUI8OHx+PAx6QFqjTb9J979fSUXbSOjZoS1PrV6GvRv2r9CM85uUg92 WpYckxUn/TSuB53FEQprWbxHTNy+FjLWZ4+20CmE77ROLjCpXReeXts3c/He47CJ1l2Ktkx2VAe/ 86moWU/M8lx/FNkba4i33unwDOhODD3G5XBgqXLlag4H3f8evXfipThkF9kPheI/ykct0aahD41K sXX1dHO2p1IpdCa7YdtuWnWxIx/ZN/t67R2s+vCJCbjoee64cfHjx8ev2vDabUMAnC0ff+njEoHb VFPnP3QJ7FGYk9K5XTMA6uvEsRzn2sVSxfFD+/XlccHIeZu2TBy69jL6vicsNn1R99a772aUikRQ iqYVlGp1yCJTRoH4GyfO+lPhxmgmAp43ODBJgTNMFlgwrIt/0MCH535tMuMUpk7y6z4JctOinDQo ccuk5baaRcVFANAlkjKDVk4mgTsRL3s28ziTaDQuoxfHAl5NpVp97vgxTUEorFpKWgocXmVqvSMA DTv2eXj6t9F740rFIi8ASiQSnR7ZbVz55+Wx3WoliPJgyKjE1GB/x/tZMkjAUSb7ujqtOjbsCLvf aqlUDgkYlnfapuP9a3vdShAvGdrg5yM30iMuWJqedLXjAP8+SSGHm/ZcBQMXKfSYNtujWd/Yyyvg 4+G/9wNgExnzjMLgEG0Ynpgd9wjqOE5xR+e1GzK2JA/WmqXUGdwB+HbFga1TmoebStLNVThl0xlp wf36Y7YcWDARxk0vKGHCxpSlAteGBSLx6Y3j2809RgTWlKGjchcfxdQCIDnkJI3JLilDB9R0Om1u /FMAOLBhM27tqNEwuFRczCGBQpN57pM/1PLrMTUu5BzDraWkIGXr+BbLdp1NTc0wV1Caes2zeTf8 StRiANo2xi9JHVfLsc+8HdLiKI8OYy7vmWnDqpuUlsbDj9Ob0akWLSJXdPnEDjqNcjky54c+dded vJP29CwALSSJlwHwkii1Ah4rS5wG/HrB8A/XD74UW9AryP2v609Dj24AoOu5H4M7f7VArVEfPHZO IZPM79Zq4eGHCiU6+bv/5jNlSVJoeN6bieK98IkJuCxTfOVa0ZUrBWcvil4XphIB753ZmZA8qtwQ sx6hNaDLgYd1bwfd3UautoiLS2ODXhR3x9kT2c1a3LP14zw18apQodOLYwAXGZiaOmdh+WlsEwF/ 28w2XY31ASAmt+zAtJGbrmUoS7MBGK7NudWw/zQUUKd6VYshfMoKYoEDMq95ec30BSeTiFenZg2a +ZfRLO75BW2m/orscn1jDwokaijKSzTIXGbfjZHQs7MvMvJGGF7F0BEwXdqjo7xak6H74LSBu+9m W0pgCCnMrvkK6IAEbOOJPi2a08DvxLOc2gAEuIKgTv3yJOVfDDnyaS/y5MXPrzRqjSxdi1R6dX4o JOCC6DO1Zp3GNKmQPeGzCHQqBjT+Go+E1JzJLRp4eTvbOLreiUDU4o6XzWBhhRQAFxS0JPT73Zc3 zRjedeYB4pLhrFu/j/sFtz6tjGw3x4KAW/6CoaOyuj9ntgsRoR5wIeqrLCKacdO4ATbetRkszplb zy1bOL1EhTs8MPxrlt2Xy83rQiz/qvvopcd8oSLdN2D1ufBvewRcS5FB3R2OE0PZix6TFsB2/mob kr19g71T0qMCAgICA4N33o7o7GscUUceInudNQCo4wyCuw8pkqv/mjpg8ib0lRifQ5dqizkNBkP3 xn4AErATpGxb0KH/KCWGSZIfBTdA11kfepoDA9z4pfeCv56gYbBwjgdSD+1LqtXM5ieeA/M8hN27 2nfv7ti/l02VAbIzMyD3fHD7dkyGiPChMZl3jd8Dg2Z9Rxp0mk6BtWjkhjHPwlfuOSkvE906/JNl Cmj9gESm0Ggy6S3Y4WKV+tGDZPNbMs8WyBhimfLXhdO87I1zV0yrkuMOBzd3lR5A4eUs5NQN8nh4 L4LB4gNwjGrrplK95fYjJtsRFB2RyOWbT5zv1NJ4/onrSI2JfAjH/JljBwLa9g65fUImKdpfTOWw aXB82dIAiUY/HxL+ampkCsXe1U+dfUChUmy5HhpY3z7qzhVDVWsjsFPtHNHKVuvOjKyUXEcWWHUz LezKsQMLBkeXEMYnId/R+jmzyVSyQp1oD0BSVkEhbgi0OO/FxAHBgOaSEBGHt5xGrtaDyNDCUumT KwcB8PYSMtsOXlmQk84qvLjxrtEUe8ULVvIkGkNBYcGFI08LtdKZM4YADJAowMavwdl9K6QK5eHt e2ABLCqGpjwUCgXqwMcOPcH0Kq2liUzYBTa8Gj4DpWWldYVJP2y/TniOsgNnQiJTQ85wa6ITuBRq 5XWKu5EPxo7ts271qN3nY77r0nBg06abFm6DM+uCMo1IVBKOD4C8+Li8rOTzj9M9vBpGR0c/e/Zo QgcoqtE3G/ePbRrd2nvPlUg7Jth4N+PB+QPbv++htuE9OX1arRQrlRo6lSePji4rK3Pybwmj8Gjg SHju1WM7fuoTcPz+iyuhUbGX980dtLS8QAZtjl9QYqlkch///fcygXBgzAAAIABJREFU3jBs3hvV yQ2qHeoUOM+5ePx4g/oDFu8LxTQaTKW6snd+GpSqZWX6stiWg8ZgEqSdrujSKvHGoZFDhzJZrOVH ymc1dDrdPB+eEiRgsVgtOgZ4dZ0CH9lMBpTA0BF6bBma2PB412OMJ+8NGil8ho5fp/WDQo7PZaeL lHkP9vQducn4SZMub+iMZRgugRlMdqVSM5kswrFtrAfMsevoWZZvO/N50FMg7A7dfQORe+NVJJ9d OFz4K0l/xmShV11qMNEsGuoCDKY57qrBAjaLNWTWOuTuwZNZJFuWH81uvBI6xDFXOvVEn0yJo/eM /HmnVloA57Rw2tZ17Hxz4BpuQjmUmopsp7otxdEH4DSVx+e5Nuuf+mjfoB2PMSTZkHXbfgxavkQN p3YwOs/R+IFE6zp8OAt09vDR6DFPi7IReHJ8FawR7DVYzt1LJu8OK4CeXk48sRY7uOA7OPkXCFry 2y83dq+kkNl4rbnNeVwOm8OtVcd9w/VMvaKIweQQr4a2EMAc+QKBzGQ6U69VwbAsNicHl2YxO7+p JIHrMJlQ35BmRXPx2bU6P8w1uG9R7GVYKjjfhvWFEpjG5PB4vENhFe6mGdmKZzIkrxJ2nKmR5BCt 12sKKvPUIW14+OoJdA9vy2ez2Xwu68LLfFVRIh6K+9WyPT82awBbAFYkUoRG1+XlAxbvhhJYB+fI LCYTlud9bul5Oz5vAoaYMweTy7GsLKx5c6ygACspwfr3x9LSMLUaW7cO274d02qxmBjkKRajAPXr o8AfBQad7n0s1n/J0Gi0bw/02UCvlmnfs2uQCr09+u3hXoHBpNt/Jvis94ErITwxJ7C226cuhRX/ BURf37M0Jfjs5ID3jaiRZDOEUIM7/zFK9QH4rPeBEQzyP/Ydw12KoEErPlImh1etrLQ9d3XbJpGy Og8uw4nisyxJNSZoxT9Bg67jPoB6IegC98+HesHnTsCYXlqWvXTt1lKJeehjOp2Rrgw6rVKJFoG1 ppMbmKH8yIFGjS4Z02vVeEjjgpNapSQOOcS9iIOaV052HnRLS8t+X7ikSCzW6o3RZaWSg2vWPE3I Uaq1REZQQ7MsF35/N5x9lxGPSoXCfHZCr1GITP4wpkKhNDr1+iAPgUKlIQpK8AuVUqn5dFeBW/Ff wKfW4d+EgpAt5nKWqsvMbnTDhzyJcPMcXNl08DIXrfgMBOBYmnGRHpjuN3uZLx/Ts1FonspstfFJ gdqc1I5biWb3eNywFmYxp2g1clLS5b2E+25CqblgTqYAaVrM1d54mDFLVx63boeeGqn5QtBg3J8m 16Th1/lhN7aP6bH+4ZY2TYnXP13MwKyw4oPwWRMwDglwxK+fxdDOTnh+2ZElgyKkWB0v+8jMvLq1 vIXO7nkP1tFtXFUFkQCUm5KBxFFWgtbr/7oV7wpA1Iltts6tDRjWyk9Yhku/wzHFySfmL9+BLhyc UrfyHTxb+ngcDk3DcIIsVRsUWbfqDZ1nfgsJOE2i3LNkQHr+E+8hPx9ZP5YJQKHW0NkOHHuK7NFB ufqNLSOtWN61RS1QqxueDk2hx+rbA3S0C5YN7UK5JT6+4Chkb3xktTtjxQfi81ahERjlR3EDxjZx 4pHp5IdpMrlM3KFt19+OXBXnZTm3muMASoJa9Zu15ZA5WsvedX5bu+BRzstrD6/nevcuU4gH/rqT BJNjcikkqMfajqhvB8lKjd9/6+AAKKDCHNjRiURGdK4FVC8BncRy9CRpKkyJvfnMscvPsLIi0k8u ilYHlGoNDlTSzRLQozEy00GjUs6J1D72tX5YewRLvIoOLZNIZBLYOHdKqxat7Wp24jGg8p/z/dZb 0RnFM4Otdmes+EB8/gRsKqNOAjjofL+bX4M/jz/t1NTTy61O6qOrJBIpX64JPbz8RbLot+mtzJG6 d+q9fMOlYNc6Rxd/P+eHCV51ah6a3urcX/vCn2cfD8kEbCEM41ivTlRC1abeTfnS6ttmjP7pF0fn xtO+/ubVIDb1esNfOx519pj2XnW69Qx0Hjhy6u9rFrg26rR+TLBrq6bpMWG1XUhXMrTo+wgMdP5x TUZE6PHQywBwhCxQx9v5z3WLaBzHL2YnwIrPDZ9aBXg7dvx5nHDI0VcEmEYmuvaiCDqKshOfPQsn DrKubtt05Px1FaJpxZtOoiNso4f2JMJIchOOnzmv14vCXmTdu/eQ8Dv/AF3PGXvvmFZfYSOxMPZa gZQ4N2A4tPdQeGKB5dsNv+2wfAx5GJaSU0y4H107ffz0VcItzk8Je/RYoamwdZ8WW34k8ElYaOTz hPdpDCusqIAvaR/4DfCkkJ+p9Y7v/PmoFVb8N/AlqNDvgClrt1up14r/Q/xHJLAVVvx/4tNIYIVM ptH8+wcYXmFVmE6pVFWzhYSqIMlNfpIh/YeJ6PWmEyxa9XsWGZPJ5NVtpuOjQJr1NCalsOp3GvHD l2n/bnEqwuKYkFylfUPAfxOfhoA5PB6HQyORSKGpRR+cyJrlv77hrbY4imSBTDXgksikiujtXovN 5lHIJI+aEz9YEbmwZ12x6i1GZx5e27rpcjqo/OVdBSzp07732B8A+pgx69rL3EpvlTlhVKrxVqOO dZnfTj/y7iVMCzvB43GpsJ4kf5m6eg3bYr+s2/XBkWUlcaHZMsJNtMzfKwafvVnhatWI2yeSyhCv 1xSFthr+yz8oapXA1mw79Y5Bgz0oI9bdgg516mku65/aPKs2fJKlM4Afe8yMR/eJPEgWV3qr077T 7ZbAwnROlVCrNf0AOPcoWSQSEQvBGo16be/24346pFappFLZ0YkBS3bcUitl3QHgO/Q1R0x+9sB8 79lb4eVmt+/umy52gri8dybx+TjMFP6qFNJXwxh0UClBxVTG7WZ2/bnS23PL0G0vOXihKADU7jzq HYsHUZR0H4Aeep12+5jBNIbr2yO8DTq17NLNCNypBoBq+SorIbzkne8mjb+5mjXAuJ6vkKIbqY6N 8ySO1pgxbXTnwevuIJcqFgRM+EflrgIqAOjvGBS2f4POQ6BjW2dH6C7QvDXGv4HqJ+CZ3yf8crDo LbmaGMeu3oLvNhyCQ6JxbXfETjj26aXqaZ0F8zevgU+1G6LDhmwBcWmI3ssGHVocNvVHDMszMyDP 4QcgYQp5yE6awL12pYxaAXA5MsfS5+rSXsNnGzectnaquxQfLnpFIcEOxjZvSCS79sZLy9J2bhsI f1sPmAoJrVd75GZwbV5KZOWM0L0DfNUhEJliAEz+w6wKJGoiYAXgtYGVhSH6dmkGAzYNRNk16zEb hpnXpdlfj3PHCsqTtLTcMLVfQ8BmL76cqS8KAYBrwyKMgWHt6qMv2jl8Nz1mcOIz6tVGx0gGTZhj mXte9GVIwOa64NZ9NOhaNpiQS034IM14ZMvFRQrL3oCfbIGeuS+u8ARovHap5wx9aHSWCPKCmItc 3CIdhW1f+GSjuajbYmTjhnYl3G3nXDTlrDV1tAKAwNL4uyyB0b7n9bjiQbzymqohI6AhUx6VCNjH bEKbaWdQxTYcPMvLxQ6yjEc49fw4ugteFNrh8Kw6DrR9z5BVJkXeUwBsyysvTa3tZg9DNWk1DD6t HNSdSG/G7nuJl+eZC3AoQW6OMbJtM9yP+yDVwkqMKgn62LHqw17mMpHeejMZNeSVrVMJi6Rz1m/b Nrp+QFM0Yt3qBGL/FqqdgHWBgc/g3xvDoKPIx47tnzMVHY24G1ewe843AV/NyY17Zs9j3I8vXjEy CNC5xdI4AGoWSvFvEjCsl5tDhym/61UiM/H7mYZ4Dz531YkHTy+fJkJWqN4rBJxxeUP3ScZDkb3r en+3aN36NT87AOAa3Jco2JPoOLW8sEShtUyk17Sd2rwH/h0GX/i5B6jTRY8f1STE+gwv1x3X0V5u 7M1doFEfcXZiAy/hpivJBoNepVKUlaEb/IwErMsHoCWRIPBus7ZtswbNJshzo5lCZDOoe4vaBx/i 1pLUz0HLRZWaDA78/X8s5flNn9fWbfrGQ0QjDK4PgnvMw0wM0dWWPf+P03p5HiFVNBqoZUhlClX0 pbWgTr9tWzd3qF+TuNtpiIfzwn3XI2/8TbSYIxdsOxOJaYsZNs74kVVUyLjr+3mCr0I3Dmk0ZFZe cqQH7KlC7VfB9XqNWVoqV98xbqSbeLFewwDgfGikWlaSVmQmBg1sV/RflQzZlCoP2abdcTf1+OSA BTvuQu/CxCug00Y8uoQwXfiqBD4wfVTv5dfwRNAVp0u2nb+5e8bAbdHq4sfAs5FSUjCkpcdXv90J +3Ma4CH27QvAussm5qtH37qExBUR5VSK0+GvVC4Z1jaoUasfK5TfhD+XD3fyhEwWc7PnxhYqzf43 lwxsOxHdiaMSZcLfaa2bzNl6T5waBtlHsVJzYPTA8SuunPixc/1uo3QGrLEz9262SqvVKBQKiUSC fUxUvwTWa3SGt3xcja7tJSwyR6ejazin9EIfdjl7+T/ADfz9PLr5oXioakL5hk4RD68FkpQGBy5I K0MapIupxWubCJiHT0hq12+SXVpZe+v2CgFLXpzEDT4hNPB3t7dD7Nmr9jSiyPMmjajl7QQlkURd rkIDwuwbjuEAZEtRtg2YgOjeaZCAr8VhuJlIGNLG0ePE3Vj4uHNos6CgoODmzR9nlB1bOXDB1WxM HQ88hxEJqnSGCwvaTF14FjNAicfTGLCODd1DcvEKKSNBcLn1DAiDCo48uiwrikq35TFBnEhdF4BM DZp4Z0m1WDkBc5JLNcSjRl4Ic2/WrNnI7xeGnpwPhRLe3nXkyHoYbtQOcse6jTNEKnN0rTiOjcgb NjsS7y+v7Rb03gPZE3wrdKt57Sm6glSaHUloDd/8csLcOIRjx0/D/Gp6A9zClqngasJEFqK9+hOK n19huEIJhp2d0WDOmvPQURh/CbRbjwJo8wC3Bur6Nu7rDlfg/vunjey9BBnTMkifAx4yQ3X3yPKG sy8mHZ+PBDNHsPLPa0RIew5Y+tcREpmhNQ0/ZWGyib+UAeCBskNxBHOWHrbsXMvsRndteCEVTXMg ARONScDf02bHydhOXDByTB+HTptij/3UdNj3kSc2C/rtQX09od+UP0JO/tRtcxSaD04Z1WHTtQzU /UFNm7doUfYxzUBU/yIWmUZ5/UoNAfQaqpjXdy1p8D/2rgIuquSPzwLLBt2CgIiEIigICgYq5qnY mNjdHWd339kBYnJ6iNiBYiMiEoKAdDdLL9v5/jPvLcuCnnHH/fHu+H10mffe9Mxv5jcz3/n9LPR+ uR2rrKrcY3VQUXaSs7kyqbVXWuI7ZwvYw+A/pP67u4f7m2wOnar++F2KoDq3hCSTvcwtQTF+rUiF BG69y0qJj5bkPNdyOyxPhs/nw+KV5pQUFdWL3KoaatK6a4NkktKOK2FiblVF/lklEolfkz1zw/GU zKKxgBeaWaGYY6xuB5tMUboeB0d0KZ0PoAwF3/QcoFKcg/aclOmqYMjx8pLcEa4mJM2O8wIjo6Oj 30VEdDPX4FbWmpogngHQD4AitI6KEqljj0GZFe8AiQorgydCWZJI8R0majsQ+VYx9dxnga16TVQz dRALq1h8lfY6qiMmu3juegyFt4QchlSC9nhgeBUqNTu/ojInApCUyHQDmHpkZOSVY7uh9At6bYSN PaJLgRpZCY4dKiTSxefJaYkxKox3pI57YXtkVQk+vn5IpVLxan8nFIl4+D1HMkXFe9uxivw0dxsK iUQKeVsc/u59VUZE4C/LFXMoEXLdFhxPSs3cPb3nhmup8soGoEQgFBG3MovyEtqZIaVTEmWVgsoU VFCdNiD0ucwvMsMIyvOlGrpqijHbdNZixSKTrrziBIdRrtChr2uafe6OEp0MOnnXMivXT3FXp6nC uT4saMeOGZP77n4qBwSo4thbnliyecpYYNaahOvfErIq920a6/YHfVRZGfO5GwHbl6SkxGDUHxwU 51ePGNZh8uY5Vy/ef3N7vt3o+dGBx5WUVIUvVsO+QeeqMBKSTJy7BAUnCvjca1deunU2Rs0fHRXx 9q3G3wpQ+BsHhz8mebo1JelwvBfzmK51+XkVn71rqsOVVKbc2+9H5k4+n8Srkmmi++21TIkRnIGZ +NgmqCmWLa20TfKr6sQeCbrNFxeH2t5a21o+KYjKo5et2US4i1PifF8ifVSQB8ao09+8uOPt7e3h 4UGmafHF9cI4jKG8TqEppzKHGPNMLCz6jEYaFZe2MTl2A6EjpWLhkLpSXHkarVjec0tcrmRxMWmt UZ9FWN0MzMm6TcgCAGmCE8zx6BxThg/53HhgvkQx+P0twyauOAwd8y3B8utIWfG7KztMbByqc54S ydlbgXGXks1NZOZR70Q02FTLjrwGRp0m3EHbF089Hi1glshuRGoY5FZwE97Kbqib9kGan1xtTGQf tbwxqcDJSqYF5VFkfntzA8K9PyhasSn5TPkBjyZLwb7rhrFude9dK+LvW7kg6bQy5pT1KLRKL0t5 BCy3IH9SHs24I/w7xdzE92WWYuYvL5kyZEEQChV12nvvJQxpuvqArKVj2CqkLhbRjvN38bZBwm2j 2e5FENpMGTphaSvHoTCZg/NHEUEW776kmH85cStlo49rJ4rd3COKfQCKZOz8d0DTWFr3hiUREkos 27ZvD1QscUkH0YT1Z7H/F/3QQI7CwlJT01Z/PvzJk2DJEnD0KKisBNOngw8fQEgImDQJ6OqCy5dB x45gzBhwFj8FmTcP3LoFkpLQVzYbBAWBM2eaqhR/TNKKGp6+ttrXPX4btWmt/yK5pJ3WnzSedv34 6kf0aRfndG6q/Pyf6djKSYEpFm8ff+ZwMeXh/snHP8SFXPtbM/D2+sYom/UrHLW+7rUJ6f82VLTQ 301wZau4bPte8tk1ZcHl5K/7+1HJBYD4mgaHf5ySZNjDHeD0CMDTjJo/CthUFLRhyJG4P1Rv/jdR 88zAwXfvquvoW9vZGet/Xh20IoVf2XdJOsZv2reaL8NE3DKW1EhX0XAZRtJywJgf/zAMTl3a6b1I r9RW/rKvv0wYV8/CuTIv5Ru9M6L8kyn9PTp/gzY/iRAo/x0AAywnt7itxY+uTlAikSorNyu2H7LS 17Z/mpyap8DDRo2aNKmXiYGultv2r3ouqMoF4u/AD6VfWzZ4MbJqVZkdqaYxEX9HArVJn/UsKH5h 2XcC4VbCJDlVgs96a0IS1+RJPmc16+mucbPX+H/6/snRZQzeN5lr+3u4FwBRgWXbTk0SU0ni07oW aXpqZu4F4P/PvaAZbyMVFWESMV/8Ya/fA5y1MHFOTo4A1x338sqv5QCwmUzFbl5bId8WxipZ9R26 uBi9r65EkEyJCAEFbaeeiwvYUcPIT83M4bIDY2Ni8HgQeobJrFHMA7e8IDn+fU5STszbWCkGlFSo enQyj1OvfEvAZeXm5TfIt1Q4cPZ+Mbvs99/vyN9lZ+cI8J1tXk0ZnpaIhZ/xlFU2SA5SYUGBWEmZ RpWBImsrSytq0FZnHsxHYkVqdkjsB5mYUFKYz64z/kACStmZqUScBDGKCphcGRy3piRrnHuPQSP2 yjPDbaiC7/j8PgKR9H30O1g5jII8vrwexYK8wiKiJlYfugRrjy9CA6WQ8eHk3fciPkc2apLNxWJY vZiHhwccf4KuXpXHLBbLFQHWU0VJfkExg3CvnT0RYNLb1wJ4EgBbJCU9V94itSxYcCwpPp4nwlgc WaYknJqmNoX4b6f/s8hOkDxdT1u1JScDeCWo1y5esUKNAsLSqxZ2R1udHboioxVwSRdwbN6c8x9b aVP33AyDQW7u9gbGg4ngoqpUJTV9KYbRAHiewTy9ZvCqW1m/Tzff7vP8ybXDAzwQpMZrzMgSLuyK 6PCpVSsAHOfLs/HuxJ5B/WEqmuPHezEF4q7WRq1bG6GTFJqeBMPentgJgN6i+VNhwLpNaEzCl/Gk o33byUfChKx8yItzFy+CbzJ4qFzPPpZsm/6TTffBQnaFYvWKeGUw4nGTveHLtnZj4JsORrqmNvYu tsZdtwRvWz6ne2cDbeM2Xl7jYCIaNBWnfuOMALieyfWfhDZFRk+aBn8DEyrh19a6FJvuI80AuJDC melkBYDxxp9X6JiYY5IqWA8zF6DMJNcbQkIavLq1lw0Zamo6JDIdlubMwVXwcc70sfCXnR4INFGp oTsooTTsyBxYXWqaKN2sKq6g6FWbPpMJWBWkIb3tnAdMFvNZ6jRKr5HjbEw1Ry84KU9rXW9nLV23 8UN7AQNCExii8V4DNfushi3Sr08XvEVG4C2CaPSwHl5rVwNAR2t3qUSLovLwYwPdCS30ZWoWBkZz jq0twk5qmNgxhdJVU9ynXwrbv3IGfJPC4O6e6nb4FbKu4GJt+CK79hpi4CROziOAjJihubdUvlUh 5cC2F1RHABWw9lSoNRz+cWjU4QCE1OWV58pZCHWjMxG4w61BXoR5oJXsDWRgq+HrcD90gRSz0QRR GZnDu7cFwEKODRBx0OnUu9zq2ICNfT33rO4Afo9O3rJwNBwFKiTYxlbAJzjRHHKqZofCmKsa7XbJ 0zk+BPjhAA/Ghye2nZZXRR5XM+0PHw9P73w5BeEu84IP9/FGp0qHuoHOqy9DRx8AOBgGGfhqODpZ KU0Mpmlo+Y4ws5q4DcNVcMJgdkYUp35jbgUj9NKhQWY7f7+3ZzUccagMhd2c/gC0c/aoivZ3n7QS B3IqsfBj5+xaMSv/A6oiQSrQHISSSLoPzJbBnPSYtBw+hh0aPe18eOFzn66j5mBSNEkeehDBLw4z cPA4N8t2GG6s7M6B1a7Dz8hSklQBNZ248BBVsnKnbpuIavf45TWO7kLGONlFyYotUiTEeLn3DwS9 mNDNyGnMNkb87wCY/vlu9Z+kZhGh0TaRJYJjgeHzNmuQSfzqmitzBlWaIRvNNvpUjCQxMETDP0VD g8MUlCTE9+7Zhm7xk0tb1XZO9vrWPYzk+0wkOhT/1vft//BZYPKH6xnKRsRJKFncqFxovA9cQJxJ vmucHRWZ1Mblsm5c3EU4+SIptxb06eq2yDcUw3LkCRKoCdc2SKUWCZByU8Dk3t3YHWdgGFMbk049 OPNtxPVy1/kqtSnX9nrfeLpSnkjCK2DXGonxqhQEJyhNTZ+9Fc2B+h0cJcQ9NRgdhhZRKVHg9CJk NNzIThZWCX+voYe2kbLiJatno2WkOX50nlTKP7XRe86kERar7+anSbbOnJCpC6c+nq6CVW5Y+NBX j2i6WqWVHLzypSwOGgfbaihTCHCyRBm0QpgHqo4pKMjFSGINHFveuotTWQFaUKirqwLc5PnSYW5E +924kLZ/di/ofvH8fp/Zg+pSYgFO9eApqxhcYfw7mRb+F6vdiab6tB+YkAG1jec6L4+rj5/F3dph 1Hny/Y9xn3proS9Rc4waUiJdTjWDogL0usz3XeVNNXbIKyr9dU13oDLYZ/dUo3YO54+uIqGzcuzY vN7nk9AZACcXQeHu53AV45qFH6VLpWhW79zPEyPAyY8QtlHEZtQVkE/YocQ+ObjHsBr5J1t9UCaQ +SmtEXS31u07wruoIKuNaatxv8gA+qwyuGInQ0de2OWOfYYFLe+q06p1bkHBkplj9S3sMDEy2Hfh WdZM/DBVoGCwJ/vZHkDXfp+QYKitYWrrIswNAjRtNpfdWZtu3RkZ+KpNvdW2DzKAenuBrbbhTFZ1 IQ3dqSiFM7B+q34xMW901KkrAzNCNnlo6Azj1DLUAdhwr6iVceu4pJR5nt1NLXa+2jdKQ88gK69g 78/zKGqa8qRhTlh8EcbNABbIbNowKOenV8LgAeHZD3y2oHwiQYb863FfXTXy8jvJvLxgFZqGz9lT ZDja5VfBGRiKBhIeWhFIEKQxCxg4PDnopWXQK2A/ksBvZNTd3JCi0e3A+fvpCZFaFNUHyQw0+Ci0 uJCZDxRmYMVmWP2TOVClN63hr/8CNc8a+PCvx+uc0pu33sA/LwP9lyxZccLXnyMQQQaes/vY4X37 MkoRHiv6nm8eDkUuDj8P9BwaRVWW8XzlYQROGujcLrUK8V9JSnhRFWJyMa+6tydxAU104ZqMA2eN HN7grFDCHT5RZvo9yP880YH8l04uYfIwieDcqV9WrlwTcPO2vGNJhNwlaw6gyJmZkxZugfm/e/3y 8mXLzpz3J9bJpnrOMP70d3ddpm9vlNVnD4Ogz2u37577/SZ8vH355OSps24/eNZ38CT4yM0P33A0 gPB5bOvaGXOXPAu5O2mFX2FUwOVL53du3X7v2Rviq9/+rdNmL3z16tnAqb9cv3hi9IgRKzbuJWDh T+9fX7506XGfC1wFVvh950o2gnZDmQehnZ7sHvksp7IsO272tMnbD184tHhCKasGGDsd+fXw5SAE UYYMbN93yC+/HL4Viq5ASvhVb2PTYInnzVuMD0jifkPgQCN9cPN3v/NXlo/qlKIworKrivduW7dm zbbwWDSGrlkms8w4qDdaEovZZXUtgvXt/ZNi5Ywz11pys0W/33fTjwjkOLx8MAGlbEQDXdpuOBX+ /8/Pv5+ERcDKS/5UEXVBfmHrj0jAqRVLpdwapDq/CQwZCssBaGyltYW+hVT+vwL7N5FYIFH53Jle yoec24t6/P/z8x8gkaphPe5FJBArkRqbzG5EO3u7+2bnAzJ19e7Av96HyuJDrVwG/+Vo/ov0Q2Oh W6iFWujL1NzglRZqoRb6C9Q8DDzopyEKT1KvcYuaKubxw/uSSKTrb/P+YjylRdlpmdly4eRj8Ml7 HwoAMngqGD3Gi3g5wWvMpEmTz19/+hfSER89fOELn1+dmPq6mPO9cU5duJZw+fy67UVa9beH5LOK xozxmjptelbZj2XKOPaef+UX8KSCzH6rLn5vnJumTSHAbSXJD5avv/5dYZfNGgub3u/3x9/iOf2Z r0vvTd+bvW+l5lh4I0xP9yH1WmPgY21TxMsqiFVWofJFf+lD+InGAAAgAElEQVQwQsRDPd7K3rlv L1eTjn2Il5b6tNaD0R3d8mTUZiUctJMNHRs3TrdtRQW6Xfh/TuuCpKZnryFf+L7HHbwuZMsfpWL+ V5ssLfgUwC+vQmqH9Hh5f3t2GKnBALSePBEdDi0+6P/tAb+BeABY/unA24YPfocrb/kssRN9ei72 U3zjPbLbmddFf+QfQ1vrCHvr+xLdvvp5ogvQNv+u/BjAqWLqEru2RmQKVfC1/hYbsNHFfeN3xf/t 9Deo1BF/nX9g3emogYB4me47ewAyuLB7Sl89ffLqDQJRSXg1ZOvhSdHPly7bKMB5g8nI2b17Z/j7 FDyE9OHd2/cePEHHm3UkEnCfXjik3nlZTEyMUCJNingl4tdeu3IxMgWBuirysx89elTORoi9lVN6 f6zmXzhzpqC8JuTB3fD3qYp5O79ltKnF/k8zDJkaOvzGWUBXdHY1pnCSOWuI47j5ZxT91zJytm3f +/Y9fjtPInrz8klI6DtYjuqku8NXXIiKeBOdjN+5lwgSkwn9BNKQh3fv3HtUw5XdB4wJfXHv4ePt fUEuS6bcjl2e53cZacM6e9r3YwEa8VJjImGheKIGg8fGJSOgnzdlElwlFdDvJDutqSkrvHPnZlxS DkxVm07OS0sKDXvTMCjMdpJM/Z1QduoL6X3405u37xQwZMpDEyJfbt++/cQZpJVm5250HChkMc5f Ryi3akZWYGBQRGwC4TM++qW7vbEKTUPMyvvtqh+M8PyZMyW8+u4hEQv27d1x8/5LggVKc9NgcWo4 Algb5hR9Rn72y9A3PNyyVFZsDKGoqSjrY1DQjdi0HCKGvLSEO3fu5oQfXexzXx6tz0nfHvb6g6bs vHANXfSvKsmF0ZZU16utQ2klI2Cf3VykEAfXUaBOvBfx2Y/v330RHiORYtf3Tr/4PO1NaGh2cUWj /mCjD0pwyMB6q1au629BB6uqEJY9NDIG5jLEb93pRynhoaGZhWVYHQMnhz4VEKwhFYc8f4s1ETWL UjtcwxgjAf3iTTfCFjEwziRIq+PEzQ+kPJm+6KEDXIZuDhbjs+KjsGhjALh4cJdJaw4u88DVLMho 86JhRJDevfsyuFJn3L3vFJyOJjGi0U3ukSMHAFyN1jCFi4mm+GVRxbwlBByTfy1mEb2tiniU4Env muLiE5yIKTDwSHeHoTMVdWgg+fN5bCJVVTmzRuiMlG0iBRjLLr54vn8STFNLz0AFgDvRBQJGVCsH DxjA1EDT3nPWqU1e2hZO8NHe2hjY9943C8nqLL7s3JrPKt+7B+Eujp05lVfFv7N7DHQbGekDY0/F /MPSWTo69lj/IOf2hvZDpxIwFVHBA+j5+G9ImzRPLLs50NvZytKpp2JYpDXKbhty8RAGBo6O29uY AuB0P/AU0cVn9ugMgHF5RQ6g6kpwi83wZXFisIbWJEyMlhhXHyIVOY9zWBt7I/2MMUnpQJUuFVfu 3b0ZPp7yPaOorRO+mf/LrfFO7TeejkgLQTexhvZTw+OEOaRCxwBjU2A8ivDJYArK3qBR4MVrlERG CfvBZoRIu/abD/z1uZ8oj/b382cdOli69Znrc+EmxkMaNvoOsm3UysF+i1UcesH+hgkLYYvUfUVA FKfxO9wA2PkwybNfZ2AMTN1QKzDYDQ7LjHAcK6QVdrC/+mISpNX07O0X8PdiaMaiKR4wSk1ndMst vZJPMPB8+NAH1e2j4+sNrTp+yhR/jpqcgaUDnWMm/PwVk/NEfX0MPgyALkeCGDg+K4VMVYccwsp8 2MZ1BK8iF/rJquZH+C3q67nnwjzzWedeEWE5JSlQGNs9YSQFgG3nHytGGx10hFC/DAmyTWw5ZHbx yYA30wbYHQpCk6GWOi0yi7lomEOH4Zv5rBzguBa+hGMGr0Hu4JQpqKoou3V6O8G0UUfHtB5ztLcJ eBAZDuh6VW8P2s88jncyoK2NIJ8Gdv25CnPZ9iUjB665KHsQwoIgbYn82izYIQuf+zgPmwgf8x9v 7bX2EiPqpn2foUIWHK3Mj82fQoNMfvgGpjA0DASAzVcEnojV8AsehB+OFMM+gTTBx5yYBzQN867t jM68SCOKoKlGeRxXUOcZRYLkGgkTKBthGNfdvVf37t3HLtiQ9HgH9EAmo4Oh3ZcfwrlCXQkE3zhj oEUztUAADGUAqoQScW0urv5OhnBOCvHTdD+0uWf7XQF3nB1sANCsEUgW93Kia2q5DhjdqNHlVBB9 TdOwtfzRA4CXhQgR0tUQFAjqPRMO+MvkS/o7mV0MftaxrSmZQoNDf08zUIar74k/Nc0vOFExcp+p IxadRFdfxkPefoQg6JOswUeFOdiZCu7gtjKurZzq4b1oqS14XS4+Pdx1xPKjGK66MKm09vBwj/lH QuHjSkcQFJW7aELvnj17uLm58fA7W5raSMkxhWYHl2x+80ZPOXDe1RnpZiys5vsv8Z646wkMuMFd 8+jNGMjAzu4bJUIESk2u4MNg4QxFlcF/iZp8E4v0JMb52j7zb/HaccjKvSt7qxnal1cCLrdahYwO f0kAI1NVoHAFPVhqo9NIEiDHPclf7dmFCIXM7ILsMkvnGqFk05Q+DWJseCRmqw85QnnxxJ7MKkaX bm0JHyoUZTabtefozyQlGviA9p/6dAVRpXJLGeI7j0OVVFR19AxGL9wGOzpcunVbcevwmhGew0Z6 uvY0G7xHx3X2x4tbCHDvhS2bKMqARmKTlOuxvgUFxcsXyW69imsrQTtrImlgoKuqpc4XoGFewGWq 49dHlZRIeLbzk9UsygXiX5cOVyzCZ49Y8dvEaPeF/gm+uPoDlDU6tnHozmOxo7MYM/raTLAAAYkI FdPBUq6ciKRMxtHhUgmQwCqn3bx568GDh1eP7UA3WrtuWDARIbEr81NhEaVSsCswJjanvCD7NMBh 1TpkJRGXjbKNagAh2kkYIGnp8FjYljXrV/0KRWsmxuefDIstzEjq145E19T+bOuX5xZqD65Xf5ML parWCICNCQDlszoVSKjpNy/e6Hs7VMjnSqEAwMJrD2ne+6SK0FVHpOA6GQAHawRBl7ABXa5rSMp6 zwcjzdXbGdIm+v22cdt+r40rxwzxq6iRuPVAyO32uMJpDRMVUS1icnYtUMKU9p65CcX1kKdPqbj+ Pb+TSNuWtBViYwFPcuXg1pmb0a0sDWWJmqGquAaxKxcGlChnfqyiu3ZTImtsGG/bx8FM1LpbD8Ov HLN/BzXVSPBdpJjusomoyrK5SB5bvHWPDgDbbybXFMYSfgpC/ay7D/5wE80Mv/1+GYrQmbjPCcu2 Ht6LpLJyhRX3K/9dijOwfPPn5p4lQL/NtoWTYaNA76McKG8YIolAJgHum9NrXVCdIjUxkpbnbNh3 +aJvKx16a4uxhFiVV8lnJiEpNAsfxWFPyMVvyxKBpg1qDzTrdcqHHd0MNE1+v3ZFVUX5XQ5THYBZ a5FNkLOvEvmFSPybNgMpxH6TWc6ICnLwGIpJhZoUlaGz1h49iIpZKsbcjNVsXTyWTUGXBPJYiqO1 REsVVODS3ES4Dus2ZoC5SZtBK+WfQw55Oo5eQtQwMBkPHf775ljZL5hmr95p6KzzJ3ajdMv5+nTg 0m9EOx3QcdQcxXYpS30MeiE9r9U5cVC0mOL3vruBZkfX/j6nj8KAe1+W2miruw6YObaXdSsztDem CsDy9T+7tG+r2f1g9pOD0M/x074ThsEGRSP4xl37ZwztRVM3/bTRIXEZSCfJ6UtXh9q0WbD5WsC2 MWQKdYmXG83IivBs39vT2FDLvO9C4pEpkJxf4Q00zX3P+g3uAozar9q9agJQNyG6wWK/+4qRB24c O2nRBehIDlwKv25YNJ6saSj/KmDEEHrkTwyxI3JVlRcFHWl3YVS2gQGXobvfqhtP93gCTb0p49Bw Vs1vsLNjJFNpLB3cG80rhVHojvThkz6Lp3rCeodiI1DXmTltPPrEFt3cvKDXijtE88E3W59kYE1H zcPAbt3GKz4mR6I1s1QiPnnubEQqUg2NSYSB93HjHbySAyd/h3+r8xJ+PfhrLkOm2Sj06YOQOmyw nIKOz/O+ROxyYb6blit+Sgp/fHTPfsKId1rMczZKTmBoiDSqJwSfvkBoVJeR5OH1S0cOHy6ulo0A y+fMIeRjeYorPacVcSXJcQnyMGJJgwauLkg6cPgUZHs8Pv6JX468TS2GTsjAjoNHxycmcyWNt/oi QkMehbySP3548zLk9TuhsLKh4XFs87J6qwvXTh85eeGe4tfytJcv4tHuK4+RzOYhRhdUZfaddwxl /saFq/eeMwvTn+fUQAZOTklLzshvlAeJWFhSW39Xk/iTkxx5584jbt3rgqzkE3vm2ExHsG1hbam/ v396yodZR9BaRsStvnX9ekoOqkwxu/rEof1nr96WR75j857GyYkEm3bsD3kjq8b3wQG7D54i3LCj F2UlJaRlNwrCrim5fv12QZlMGq4uTrtz7z6sompuA6G05MPz6FxZV0kLD/718IkGsYhrtu65SLgS s0sJh8VgC1jg/ITwU+cuYxLBpmO3IANPO3AjKekj9gnFx9ZL7GIxqhoxn30rMDA+DS0eIQOP3vZ7 SspHou1qSnPymWjdIy6LBipNjBj9EbHQ/2Iqenmi24hJzZwJqRjK3n8FwBxwbP6c80lNlp/PUXPJ hoq0f5QHsZD+Xrqw1Nt7//NP3y9wtFp/POQv56sB/YhY6H8xaZpZkZUzmzkTJCUq9S8heNpZdtbE 9TH8ndT85v86dqZy8CXu91K7DuoJGp9RLhtaXfN8Tv+/nK8G1IKFbqEW+gdTCxb630vYf1o/HCb9 QS2aY03aLs3GwHM8WjPwGublhXQcOv97gooJ89zLdvk1udV5oeDbFLh+IYaC4L7Tmhj4imGSL5dU wikbOmqVLANC2ZFY5w7mwXGMps2JIgnKE7LLccVIqEVo4rr3nLIc2DqLlixZgGjx/l9PBr9Nb/LU 25tqVYi/5OH8xmmbb3yyWsFqx81tIivhmFT8OfXAX6V9c3/yT/5efPsfUnMxMP/8q+K+PyMVOQcX 7Ul+9D1W3qXoiDg5Kz3+9n66mvpXvX8XUah/9YBOIhbpGDVxrp7tHbVwS+AXPJBU6X0G9cKdfArF gXg5jKJeUP0dNxm+i6Qitlorx9XHAvAHPlAB8r5M1zeLjXo7cvhwX1/fcZO9TNRBRWFVU6ePDIJ/ ue9Wgc+q+Kb27+vUJDmIvbZlwKjPmHH5Kum1bRUbV9gkeUDUtHtiGNLVIPyaeVGMk4dAZwam3aG7 kyY6X5fZBeWWTxg3ZvzEOWwJNqSLqX/Q7UkTJ95602gfHw28hMqYtSO7dt/0CEMaebaNGDFy0WrZ BYm4J/79+vTqN3AQ9LVw0pBsdDQi6dsH2fWVcEvHjh41dtyEchzQ9Dhgb0+nDgAhFqsHDUEgip+G DJ5/TPGASjJ+5NABg4YGx6CzYl5ZpteYUZOmrOJLsXl9TUqrsnu6uW48fVPum5t9p7PXzHFjRo6e NIM4RZDyq8aNHT1m7Li0sgZWvzesXGjVygAAQ1kqY8eMHjPufR6CHFN02pw9vNHZuVuJCJs4eri9 sWGrtlaDfxqqGDzyrt/IkSOnrEKKLzmMzBVnXnPzng3zRAashwwa9KyIv6GT7dOk0qlTvJeuOUYE 2bFq4qhRo09fR+iiA9tXl5TnjBnpOXriEcVod86d5eXlhY49pAIlMv3RqWVdu3SJzG5sl6SfvYnr 0KFAZziedxZQoX2KgP9s7yp5HzLOy+tMINKskhMVkF3LmzN+zLCRi+Ue7v2y5fQttMU9+qd+GeU8 jw46aQnPXLt2PfEQWZDjMYvHe42ZOGWGgSpCpEmFrPFjR48e65VYVIVh/EUb9tw/u/unnwYlFDAP rPfaGJQx0cuLsLXGLk6at+Qkxsr0vf8ak9TSDGwDd3u7ODllMNCJVHVBytSpU9fsbnDa1MlMPT78 uquLy8VwZDq8IiNy1MiR46fOEUmk65fO7NreSsvAcNCgweyq1F0X0Sn0OC90qH553bLYfBYm4kyZ NN5rojfsefzKtE27Hu6ePmXQoJ+YQqnP7qkLriD4vaGeZlrVnzeFI6vkvxj+E/omLPStPTOsHXop 0/WkOCBxlLPR2wqRWIDG6f2+V5aNdZ1/IcZRUw2omh8/g5CuDTqHGCGNRRhWnp9qpw1Gnf/AyrwH DOziU9P1AHheKs5+CiVYg+SCKgscy2GtD7JYYtwML10sxaCfI+efntm6QF1zgLQ2Afq8Fxp7aOxP NXzRi+dPdAB48jqsSMHO8MHR3ewHTEmOfTVm7oHKzFcAqPwW/Nq+reGlsJzFSO200v3XEYo9FTIw AGoHgx5t9R5JWMpuA8D6PUHBF3YCUK/QK+rIGAM794Ss0kEe/SEHGKpT1x3xDz63Xq+tI4Z3fb12 jr77FpuNPp+bEHV+x1jnYZPDwiPkwTNDfqNr6mbk5bUzotyOLMx9F2BiPgeTcJ4+QUJNWPgbWADI wNDttRhpxuQKJYu7dew8YFFKHCyCMleMzBEDmtHFmzcUM//rqC7AoueWdQtxY9mEhGr54PzaXhPr lWlj6JT1qQqFzmQzZWH/gIFtcLW4DQImvoRBTvv4aAGQy5WE7IRVBHac9lfMg/dIt+13U4hKSCxg DUBKC9VfhD/H/aBJdc+1R6cXzyCCwBKu3Bbw+sYRAOyQkWEAXAZP3ePZaq9fBMHAPU3BgBUXoc/x DkY/bXjITj7XbdZhIh6yaqe7hyeP23Ii5u5pirp2RELCpN4Wqw7ckufECUHXdJ4+DcLTYsPfW6Ex K4YaDd4YXJyecOXoUovObmGhL/h5j0B77yr8mhqGLq5Rowq5VnAmmLpovLuty6JfGVHI9PyU+cut LIzCsmp2T3UJSEHKiZ0HzPxDDvlmavoZeMnEpO1XGt/eaEQjnIx230Mw3ehz3toTtu9Y5DnpSFj0 iRnOyy7CrzsmOV1JZc7R0ghOQOCHGZ1APEeqR5eJDGJ2kVx8mLAAXRvy1tLY5+cLH9taI03L5ia6 556jKz5EhdroA2S1U1wJqHpSdgLoMta1gwmFqpdQIcaE+ao4au/ULRmCwrYxLhquJ1XkD/tm9Z1w GpnVdLHSjyjhucJec+AV1nCqgQw8as1e3CmmKQMhLxtYu4/pbaukpHn3Xf0Ft6z7W4kiRKaUC5hw pWoxsaMlmap+6UUGEWEOW5r+3AexJa4yupGSqrWjHXb6/Qa9tbHqACeY6OuHzWf9TnySZwYysMc8 BKvqid+I0Afg2O4lsDhuPZFSPsjAwem1kPleRMgvY0kJVsfw00VMjFCEudU8fuFzyz4KdxKlXHn9 w8rLqJX+EQPbqyBl94rks9B1GQ56WzG1/9GQPMjAa++hloqOqLfG6j3Cze9VIVGQApaoHQCzrsVL cSAxN/2O+6SFRN3CoRbj54HWDpP628ERM+BZFmJg7Q6oCcqyariiA2tGb7mdRVwsKavNA0AVfko+ N2fesQBMgFgdzo2cjECnSTtGtwdvyxEYY173zkfu1p9vGwOw9XEa0d/Srq70nLOpLWRoI3O2EHmG bIlQdHibwyX5vuXDtLTUPwhxmCs/B5Dt8E+Q7btBn206o6E8J/4dnHh2T5WZXK0VNFCv+Oeo6dfA JwLstnnrfdnPvTjGguE2cPjtOufq+Z/njervGHZ+rUjAcHGC0xUw7uhEBiod3ZVKS1AfikkA2hRS Rd1gTsQgqkJ3XwJ9fgY4LHjDpSewarLTnxUyaqQicetW9RlQVkY4ONkSDXbM2JunQxL4vApb1XJA NkN1KKhePKYvXyyLmdXADJMIaLeVP0hETLeuaEag6+gpA6VSAKLWNQRj16UJ/2NCDk8CSKiPh809 9VQiYQ5zqD/btPRElngZH1+6uvYhIVB07vRLT4Q81qQeJrgFcGChRgCdceOjZMCuabC7pqSsemIr snCbm5FcWYXboVZqvKXzUMDxGo1uaGkCwBSjr6/IrnBIighbI8YNotDpMHNKHm7yy1k4NhtHaIsR A8OVLc1cm4pHXh9tWeQ9mDuiLQa52x27817CqyWTVT7tSZbtQCNQs7KSirExMmfHYTNNWqMjVh1t tIBycXNRKBq5orJ+zQz579QEmWUmEkW1rFRmdFtK5KoocdIvDyGfjOuBn7uqoBqmGVhq0VSqcvM7 2cMVimanDuaGmm1+mijTUy2WSKS8GqBtLcubCqhMBW310VNwRLxblzbypDkAbBxsI8uVCvXBuctv a4VVpXlsRgkRkM8l6pwGQOqGYw8jbx869etR4LKGBBtMnYZ/qgZtUP8hk1H1WHRyRbgLMjgQknNq BNCkfLbzfCf99THg+4lLpJv0AO0HCqSYlJUBB0h+FQLHurv3ogBgatsfmRShqpsZaQOT9g1CS1AT 4mOXdOfskSrqBswsdLezm6tbayM9Nc3xKddhtHTnTu1h40FPs1zt9U3bWpq3BkoaUISG/GFj19mp U0dYkW2t2xi1sXFyhG5VQodzewrIajhpeBoDc1tHl84wNqfEx0eUVVR7u/eErT1s4R7YrQjdmWYA FNetZXARGth3Qjsluy4gNChcYVtYd3RxQr2woA6oqE5R7uDg2KGdOTDpikklRtr01u06du2C1Enz cO3K0E9VynN1fXRfp+DpEduhCxRzlRMeBJTIrm492prQbfrNj4Qz8ETZ/Xt5m9q1NQxJQpfgtw8A xyMLN7o6aGjru7kiuf9CaB6cgV8VNpJwsdOznIGuaWtN9X7TdmGiGqCCK2rm5QJKB7mf6YPshuyT 4TfjfNepdRzGLvqoRFZ279XTth3q/Rl1649hluADs8EkU5YaBj10cYCVqYfuze4cufd1TqM8vPfb SNPQtrOBQihIKeWYE3K4REBHw5AUmcmwdTDAhzUhblLU3Mquq7MjfEwvKwD6neXxrPdyDspAt6al gmKALlGh9k0+N2XW4StSXh7QxbHr7BRA7/nEZ5UqVc9CH8UZW1YPyTQgxDFcEuEJ0a9Dl672thYA X9OVxd5q1cmD8OnRXrfbmLmsEnR18WYcKpE1lAc7OCopkQLC0+AMbOXSSx7tVDsQWoTqqJ0h1fdF A1Psf4KaB7D2LCwO/ZFKchkyVRwXTgbCX251WWR0rFAqffI8AjLwjYiU0tLPWMopKCiVuyU4qFgs 4CQnJVUyZT1SLOAV58dT9GQTRerHhJyishOnfYnHnIzUrGyZNJuaGPv6TYSgbtctNuzlp8nFR795 FxVPeKkpzYuK/SDBpBEf0kvyZHqMo8OeKwqQLC4nPyevqrZ+JCjISU/PyG+4tSeJefc2MqYeTV2Q m5mRmUu4k1IL8GLwnr3A171C5sfsUqwhScT8jx+TK2oaM+HLF7IdOBFXhuXmVOWX41Dm2sqSlJR0 XEbG4sJfCrDPUPL7yMj3MivBCYkyx9PQKLkHIb+BYn0Wl4dJhYcOHPj1yJGImARFXfaST/DekPg1 pRGvXwvwL7WlKTWiz4iR+dnpH1Mynh05whVJczJk4PbnT0OIqNOTk0sqmdVVMgUdRbnpaWm5hMLq pwoX5ZmMIiLq67N+au+5tHEx02TXV56FoyYQ8dlsrtjOkMZQgJhmpMqK/+jRIzx+SVpKcmGxTAsF JuJEJuQQzuKUd+W4ooIjR47Iyi8Vv3sTkVOKtiTF/KrXcfWMyq2V2RAWsKv5wr+qyv7HRWJN09ac +Cp1qKPJnwsuqkww6Dy+pjC1aXPVQv84stCmnY8q6W/z+VuNkG4eO8I1sK7KebRiM5QsCv6fefvr 9OMisbxXWRhp0/50cLK62eo1m5swPy30DyV9I6MvcC8ky44Wr+5fzWGbi6T/MO4FLVjoFmqhfzT9 uDPwZ4lTW/t1T98YFV/ydU9/MwkFvG/0KRFD+jKGFvuWsVjA43/Vz3fRpwa+/9EkEfD/WQVqHgbG D07+DBlr1d/SkjDTujk5derUqVevvtNnzWVLgCmJZNmhs7u7u5ubW9++A8aPn7iuE0JN6xlZnLsW qRgPvyJbT1/3L5XhE0qPi/reIL1a0cu/YRgJ3LtUhUzuO2LmF/ykPNtnPv60wgupc1vrKmEjlhZR 6V854YN0bfuSHWeRnmSphMPgfAkc/vr01OGzt301wn8QbZozfP/9HMU3JJJBc2XmW+gfdh+YpeBW 1rK9fud+DwuzTSEvhOX5ZGWQLxIWFhdu7OGmsXDXyjHupeU1tyYE+gQnumvm9OnlFpUXfHa9TKE8 mUaVX1bBPmu79mvErqmgaOqTFQZA2y6uku88WDc2AmwRMFAGMDOEeqfP0rEL/hHFfDfjL+G09c0c CyveK7xQ+uXMKV3VRnGSCS1Wf0TlJcUGxiajlv1co4z4vDT67NArxh9OTvwj/+bm9ty3uV+IEJKI zxIpqdFV/69ThVTMr2JL9LXVPvdRwihnGhl8fvhmAUnDG8Ciz3r7gegv7mJ/SowCdi3nK5vjjdIt iEVAOZr6IGILPmDbbDxr7cVSTCzkEcrsTgW//zQgJE8AChtojcKuzTbf7vuScPsOAYS+QkF5AkDI TRmJ2UUqNA3o8Bri0nPUNAyT/jwG3UDo0GOkFCmolrTSQ+3oPm83keiOXWg/bNslpE4h+ZnMlsKG K/F18SkI9o4r5nn1iE6NwR8Gwm8vf0PKolSpXfj4EcvsQQgb0H4kQlaNsAWZPKwi7xWo0zVJkN96 pE5pg38ohkkO7tyBR2XQfdA+uYdWeD08Xt8r8HmmlJdj3LlfWerD/ttDnO0soE+kq1cq0ibqSioh wPvTN13Ey2Ka+vwcfLz8JkWx0n5Z1Y/Ifi1PdGiIe2hu7WKH+jLB+q0pSiHc7zLrD/bygg9PXnxh uIOFsiqNh5cu5h5xL6U9VywtTYsggnRdclUeZH0vEPQc6RK06j4MQ+c3NYSfgPCMypSbU0+/xhVH ucBPcKxNLJKdhM2A6WahI5kDGyZsfJAtFfEMcD7b5PdpokAAACAASURBVPsAxkFVBpe2z0A1FvhR yK1Rw7EnJt3GsIviiQ4T5b/E03u/VMyjUQjFdg3UuO+eguAuPm9zoHvRFI8995Aen9RwpILbpIMD 0LPGfmBqcgYWfaNe6PoHIYKqxWYV9wXg6OP3zLT7ALTlCQTPAnwEUikcuVf6PilKgk3u1ThgXVSN GDjl8tJJO2SqlfoD8DChkMdkdDHQ1jQylfthFyXRNbQGuiNwBeSrZ6fngq4LeDyeMQBvGcKluure ewN5XARYFWMYUidN6ltUivIpFvOg0JKUX1aWEvEyuUweIZPJhPkvZdZy+aIpHrZAvW0pA/l/eXwy AJbVuHLD3Ere/eUz2joPFAj4PsdOY7hG+8w4hEYOTq9XypUVgAzNlJTmouSkkuBgNLrl5xdUVNeb r4BjQBWOfHSefTzCd7nLgAVIpTMA0zaenDvaZd2dbLkNB5/NY9vZrRHwOT7nbhLVpaRKyyuIASr1 GqHFFXB9YVPFZEcFHuOLJJ79OgdElAj53MKMx6DXViazlkACl1QyQ0/PcRpWrwE7DykGBiO3Xlhg DQLe5YSfWwD7fBWTpUmnJJdy2iLIXS6cgc8/qccnnkNq50FiQSWePTGVRHqZmJ8YfNTQ0rE24xFw 25p6ZwfxCf4y6swcJz/eT9FchOFq9CrEmAYAZ58k1OTCNYsuJuXClz/N2xN2Yb2H59HeAOwNfCsS CQ/6BBYlBsPcwVB318wa4X30wlz7rgt8eQLRgT319zf8F00C5q4lBejiYQVfQjBwbQni/Apm7bNL q/WsXL7Yl5uZmn4GfnKr7M1H7pf9KPJhnP/cfjOQoray2DN91lybOqrHjht1k4MgGxj1Rp9SHgK3 ndjnGLjdJwyc/3Cb06Qd8oQIcunZ4CifXZRMvB+18iyGq18egaMOt+y/hodSGuaBEEvnbz6Fj5AF wzMRunuqA0hkS/paIlHW3KFHo5wMqVP2DRn4Vhp0SvOLKgZ0afswpZLISRlX3LMNSKrXGocRk5wq TVvxPN8MgOfJaJZb6K6biMM0TD8p9Rx3o/vJaUCnPQCuc4c7HX+VX5b6CK6p4afDqyYvuhwv5st0 boKG9ntRv0QADhFh7FtGklpj/AbkkIlzMRwmHcVAnjilr4lqL//wkK5pBqd98879i6rqoSN5IYdN 7ZHlh9urLC68TBvdq71/DAKcaNDIBSzRmpFIt7uKvjWLV19kKFp4/nqXyImAWQaAdgd9bX0Lh8S8 KiEaMU3GultZWbWOYxQqtrVUyIZcmh91WbddPwTFU1Lu3tkSLkGCX6UTDCxCYC0uTOjaJlx8UzOI zKwpRgw8Agb3X+I9ef/z7LdXiUb3C4yTxzzQQSMkk0VUcmIBa/647keeF0ZdWLCTUDQtLtf/sRm4 6VcmA0cb9Oz45fNbHhQ0CVdFUY6WnlVhEcK+Pjh5rZuzuVgk0tBFcg6vtkwK5xgeGqopmqagquiz cdniU6hYXI8E1rNqp+jh8ceSM4e2xISfmL3lqPylWMynqmtiGO/5kXm/vcmDvanWyQuKgDtWDD7t HwjXUEPnI3l1fM82/o/Tug0CBeVwChI/SQRGqtIHaWh46kbNPBVeqphQK1NQWHcFVQWVgGRmogdF 2Uqu7K1IhNRdkyVo26qsGB05cvH5ZHAnTZuB9RtUcOTIZaBSh4ZVmdPBZ8ml9+DhdrZXIt9rg8gH L+Lm9TErz4k2HusNP5nSNONeRit6JrbJSkoYUE6HXVsP4YWRGCH3wKlm59ci6Naja35cEZrYJajq AYmsA7LRSEdSUuLyOfEsUd6HZxH3Lso3slNiXnRycYUOA6POb1PyMKmgjI0+KqmoCAWSNReQYrez o1TmnA+XpxUG5d7RvWStgFboNTdiM8tzEvgpD4UUDRVQfDOMs3+216JJUy3n3pSHIpHVhpoZmXeb vu0cMs4ApJKfL8KxtdiOXphYjnbySbhkoU5Vdp6NVj2RJ6fOXraCQoPLCFlVQA/Khm7wU1V22Nw5 c+Ux09V0s/LKASYuRGr6qZyKqnZttdTN2lw/gaxYVBVlS3/wc9ZmGDR4WQrpqyUWcXQ10KpFSVmb JZSy817L9W+nl3NbaaOpQUkJDTRcacMZWFTP0lQlqnwW5qZd6zJ1J+GeCMeFDwg1Kawt0oKdmC2D D5YkPlLXQhZJMkMOg9Y9GInPleo2xmcuDowJ2Cwb2MjUs2H5hNQHyWzglLz3v9WlqZJQ1WCp7wF5 Ap+cpnjY3M+RLd7iri0mfGuqAe/TIa9PrKrLsS4UD1WI4oj5NGWlHGbdTMlJJXD2NgOmES8+baaS 2HvENalutq3UbcdAR+jJ6YP2I2sAyfd3tXPpJRFwlAAFPl49slSWAX0TdCWLbEbEQFa46ze8n0xp vjJZB66fhzqbR5YiHCi76CWgTCD8WLcxJvzotraQZ8Nv/EDvNb9BR9mHc8Dp58Q7P9cVljR288a6 iiJdjy2WB4Et8joDoRHdqCCeg3XrbF1XH0hRs7Euff4B/6qPIfBNOdaQKt9DX4Rzl0MHIhSFpp5T yyXXSRlSXr0Gktkb/QgYM0HDvU/r1G0Cmgyv16RdEnmFeGnRYQzedtYPctlwNrfCZxE0Euv+0Gvg 5gFyCPhcJVUqWemfcQp9fiSpw9HyHm31mysDZlquBczIr/trof8eNQ8LUaj0fwr3Qnp2D0iaFfTR wr0t9Ef0j+GipiP+pqVLfj3x8tsD7Hh2pEMrjb8vQ3+O5s9f8XcnIRULl+6+9dlPmFR8/XHi352B Fvoq/SMZeBCJdOJJ3J8L262N4Ys0pq3D1wFJcrLpv0JfvemsUTWkPwCliWcu3PXFcKKzZy/9HflR JKmIdXLL2M9+YlekT9h7R/FNe1PN4A9oV+/pyZXFnO/AP0g4mRtPBtU9iWctPkC4Eo4Psp957I9C tZCMmmXlnZqWi0mlXB7aeBII6iEMIpFQjGuCE3BqBBKp/EIps6wQvm50v1TEY7N4IgGPw+LVxyBV UKgHP4XeDSiqZCuGalRkkajOLqgURS4Swuw0uqEqFQpl8Rfkof0wwgySVCworWRJpXLTRVL8pYjH l+2TiUUi4puAw6zli+WZJ3KIEiLMWsszLJUIRcRejEQgQIpgeFxuXVRCYeN7s0IAtAiXBMdJyz/w uRw+v7GqNOgH5UTAl1tfh+VU1D0Iyyh/EvJ5XB4qBX4WRUOOT4y2sxhJoMeuBhnDo+PzeOv7ggOv 83gN8yCViPOzEi9efyZPjmhoiUhQm3kXWA/nonvF4kYFx7MuKqmohd6qa+pVAkq/qjbxP0PNwsA8 ACxpVHSaoYb/ztqErtq7ahJiqtL8qx/Ozu1JpaMjFDIVGYOCDhoN7VTTHNHWsSMAmeWc+ytmkimy Y5Ya2P14DDUamidVqWoFTJGnuuzTsnMPiFRZpSk0KooEznkee9ABr6MVUlumQkZ7m1N0NTQ0EbqH ZFCv1YFfmUbBjeWqUmgShBBSoqiix82/Pcl+4a+sjKvIUVLJrBHdP7iWqiYD4cGee3BuX9ypUsyR bFwwTJmM0lVRpUIG3entrKlF+FRBVUEygQkxM+4r45sCNMuuJa82yIfX80mc10fGE27nwWMU6lDG wAlBO/EZnPS4AI2GyTdlimNMZ11TrHENGllTA+EKO3mMhCyhjQMblZRViEvxungrwOJAXhQxXhMi gUPvwTgDD6RT0NceBxoY+0EMXIfDHeIbBnnKTINUIWqwISr3nPN4P4ETJekgPRidLPHtQJLS+biy /fr1yMXYByvl7iupHJ+BZN/HH6vi7yqpyBIKTavA+OVqdCreyvQC5l8x8PQvoWYzL9pv3flZAJy8 Fc1KvdW655Q3t3ZT6fZwVB7VzexhFjvo58GDV52EY/RAO4PbGSxPAA5eDIe9BAq+tXjw/Cr+08Nz oKNWKNXSoCUWsx21Va++Qeb2Wuurh6Wj44Tfbj7ApAI2X97MUg5XZpMaUsbDbQD0F0uxlZ6dj74s nqOl4TxxvRQTALV69TEGasDvSRqmYGY6taBSwisHgMqIDGpl4yQQS6+vGjxhm++jQ2s0DM0hA9jo AEbGMwBM+BLsyY7xozeeDdo0v32n1XDKGGxj5hucsnuqm7n1fOJ0ERNXAGAhFXHISiA6q7Iy7q5l l57yKsKQkUY2ZDU2jz3S0aZNl/4KVShjYMhbCQxWyYenWoYIZ0YDoIglxCRiFl8sFPJrampKShDG S4Omuv5EiLA0sn2vIb7jTVZfDXtz8xgN2WqVWuuD+ftu1qUooasqRWdXw7qqrOESaJAN/s8zX1y2 7YSsPXK5rPKysorKWsTAdtNg7QnZsDYoMKC+CqjB5+kbG4fsC2tg4d2htf6g6csYTG5hMaM25Qro v7g8872ZPn3dDdzQpjAHWA5T7BuEY7E+8H+axsp8At8kltT+PtP86M2YbrqqF1/lwK8dzHXC0hsr u/0PUrOtgZ8fmNVuAOjiZqdu078oPDEzMvrYu3BlJZIyXQ0OuLBD9BszHA7b1l3sk1PKpQAMG+IA B+3+9qAEv4FHo5FLsnmD5u7RIONjuwT7UCOc3NMMGW+uYdtaGN66fDLIZxdJiVJQK1fwTaLT6oER Ty7u2HFntzIJOPd2TS9CYOZdG5aRgCrGTpb7KeeAOQNtFLNta6qrRNVH6GCAGbY2UVUmDZvvnZ6O 1n5tvQ4pA5BWheVG3O4ywJmiBPpMG5NbysbgpD7YHeZy7hCdknykn2n//V9IxIiAiQCdLubzRFLg YqmrrKbR6EqDhM+FZVenqXebvTH3/TOFD2xAoSEdknCqNFQ3tLIViqVAUsprPcZEnQznVnWK8i97 dvz884b9Bw7U4hfkls7oRzbqlhIW/PR68a/e7svPvv1YUtuORsqoALuXj5TFyqvlCqUubbVhXelq 0Qg8496p/cgUCV8UD2WLVavWbt+x81wAuqsENK1g7ZHVYG3AGoaDBqDivQkWq9G9jMi4cEuVKiMt +vqjV/NeBIPnpzoNnH7u4YcDY63w79hnt2KqK4CWOpXFKNXr0Mu+lYaSMpAKxVFVwhl9LGArV5RW 21p8xoDYf42ahYEhCyIQsrPHsBcZDECCQlS8lq7mmi2HJGJhNZP35llqa5eul3yuZKbFX7nycmhP sz4DwNXgVwmRwdc/QuEbRQF7f2RNiZEbsvVmRCLlM2t1AHiTln/plxW1YqBc8o6j1f63G48HAvA2 Lvezmeg3fvW2NQeqyot3rTs7bzgOJ/jkJiiU1ZKLmLVl6H4ZIR5GxH28dnod0LLUsbDIzc7LyMru 2X1Jf3d79K3u4p2ty9DYqISKmprhHWdOGNLdyl63+HFgdlbawgup9t3a4+kopEQnKykrw2YoZwkK CwoYRQ1sKZBU0PgUl1m0ePIQbw+b4noRVQyQbI+MzsfkFJ/fvEW77XCgrAOKbhVXsYvSYo9fDN2w fe+ZM6ePHjmiSfBVXcg27fWm7TwVeutCZcrzNo49YO0/jkrj1ZbBTwJldL3qY2FFeUH60bNXpUh/ IEKCa+i0rmGVQLn1zJkzJ0+eWL8YhytWxxWVVd4/t4WmJRvjCPyJSWfHR6/z6suASXcdu7nz4In3 t8+E3P5ds21bYD8hIS6ig24tiayDKoJsCDI/b7GRTFXJTXvX1hTFT9M1TCvNhiLYq+Q82MrlQqBD /myg/xg1y7xPp6vB36SQnUP2vYYO2EmhrKupoU6l0dy72hi5jQ4P2kBRU9dQV1/ji7Y9DgwA6hqI giKQLrIe2to1Aunl1bNmH0Zqmc+OMfQLSeKUpWhqahq3XqgOWakmU0NdjUKhaGhqNVTdxpaL0JCc bM2oVOpQ70PQPdZILySpBGtIyS/OwbU3zEhrQ1rAeySWa6JcaNbwJQJGFFybwQetrrOhz9u/ruu6 tt7W9qHFQ2BZNLUQTjg2YKMyhQZ9Tt1xGT7umdbtZpZ8k0Zk5ogE41vbR8H1ubpmBzWaDGxEocgc RR9uqqtBUvdYo2A3QFiu1hqJ+gl3DtBoNLqaDB311Hc5lUqBz6+zGoiXepr0Yo58o0tiaWZMp9M1 NbXKYO2IStWgZKKm1stZY8TZxKJofxqMgUY/cieWz87WGnkQhRBXqmq1bVCPFemaWlrq6uoamprE G4d2rYgEbu8etftVAxHa1sKESkG5epCMFt2bne1h6jDk4484QktYQDEfLvesWlfwW+t7vMuqKI24 3HXIOPjITDzrvOA4tzKTaGW9H8CA8I9AzVkLUqlE/Ae7ieGBG/a+zpU/7hoAkkpqP++1IQk4+V8e lYrL//zCSTFmQUmUg8ewL3iWU1TAeveVd/50oi30KX21lf871JznwCSSkvIfXGIv/vBBQegDMc8A 6Y+81sdG0jUwoKiZ34z7kmoyY/2mWTjVFBQo5vALVJDEBLp/cCmhhb6T5K185W1Gc+flh6AfVqld Az0ZMJN/WgtPExIUGZSU6o0NSKRA+R8JhGmhfw/9sAzcQi3UQl+n5plBHr94rfiYndt05lL/i8Ru 6zKwufPQQs1DzcLAgiH9+8xbJ0fSStu1NfusMeZmIFEhifQ189z8BBLJ9O/OyLcvGUSliXxh86vI baFmoWZhYAR49Ds0Ok+mIFHJDoA8HJ7BqWVy+A30mKa/CXiTXl1RlMWXSLmsmupaTt0XKYNRhjuw dWtWwUcev8EgUF6YTTg4NWVE7y4rKalmEkliPISAFqany44fC9Lj53iPD/1YCMimYrFMQx2XzWJz Cb3N0osP37Mri16/xVXVUTtJkQp/bOehk5hU8DwkRJ4ojkluUFQuB2W4IC9LdvIrEZSUlMpPgUV8 dmRkZHJqLnRHxyAVGZhEmJaPjoIl+A1GLgddSS/MzeEIZXvgJSUlYml9GuVlZVISUKe3HIn+V6mp t7Wlzs4xA2ekf9kTTDcu+AKZrkUg2j1tQQYXWzGyE24KE1wMrT9A2jl9sIt7j7rMormRj2F5kUjd iUcfpJlFKpDxm4GOep/lR+UBR5lqnniDNEvZ6FFeZdUO6WJs3smtvYnysLWnSt8FAoQEVqbTKB8Y PJgqTc16tEeHhWfvC0vfGTr0haH2ze1PJPfrg3RMQqj+0DTVAo8Kedy031wW+2JSIl2lTmbUJb9c 4VejVUDPfv3UqCqn7tSbAiMsO3XuZKfV9Ri3CN2gGjwYQSO4QsmTczvhYDBx0lhA1ZVgMhVWRTI1 TpBv7bG6waCTo53HrLWV6dEwuSFDB8E3ZSKMV5ULHb1694a/LgNmNGUbttA/h5qcgSVuzjG9BsR/ 2RPRWf0WtoN9XoxrV03MSycpUQVSrCz6ilXPUXKfF5dMptA1xNxqIsiM7tSnxaivJ5bUIoPOpm5w DlSF/CDBMG4BULOVB0x6eMzA0g4TlgKgVpsRQu88NOnNY2UApu+/xoi6qUprA/2MGNg9swbFtmzd 1uwipMKlOMzf2nWQiF0BX3KkWE36q1btu2ESNJlnMEU+u6dOPp+UfG7OxD2BmBTp8bqfx+Wk+dtN 2jG/n9mCy6jUP7s7bzz2Sp4NKGo/SalkpLx2mXzN3sr4SnjylkmeKmQKTyShAZBQwZfyGXRdE/yC B0KYJD7yA+remCAVUPsTFRVXzuMXvpy55fBkK/C0iLUTH1mqJdi2PiC4AEEnsoJPe3juaar2a6F/ FjW5CK0UEeMc9rTTt3idczpDUz1Wo9tiZVVQxcikqVNUSUDb1JwtqkcaKgGlgasC4WxJPNr1Gvbq DToAtGulAVTUcFPY6MQJ3a6hGQIOUx7Qbuji8uyUrT3Mtl4LYZcyuPHB3YZOrmTzLq2fAL+adzSD v3efvG2nRWfXlFupMyxbG7zIRHxLV1PlcRDoig5FU319vlgKhBxgOdNKE92JIc5zWxlrAIkIaFh7 miNgJ1wSvH1V8Ms0VOpnpflO7naKxezTXtewvXv01QliPn9KTzul3nP5fB5VRQmyrIMeRSIgFgVS YmWBzqVccIlDKJOKO+hQKK37Xti5sjATDGytwe++Viyp1VYCH8OAhymqFprG1xbtLfTvpeY9xyQx WVybqqDbiaC1jQuXxXoQldC78+jennPkPiKri7o4tyPh9wbh4riDvuUz/1D4/v7b3JiH/qA0DpDI ZDLYesh3Qm87i272CpErn/XutitGtM6rh56tA6Bo3Ql9lxf/SludUqOwTC187eO9dNOwKassqaol +OJTiknVddrAWd3/ReRw5586DFrOy4kAHRDsvrW68ZNQpOVQJJGIocysjQR+ina7uMT0QaM6DRq+ 5tKm3jEZ5VamDZX715GDhpbtgHkLRnXbvdSNpL7MAIDl26+e3rFKnd4ZHxnCnrx+4+N/V+bbsjFb ug5q6+A+cIWn4/I5ExxHzJ5zcjbNxC49I83da0UNL+GvNkUL/TOpeRhYU6ON3P0hk7Fg5iwLLYO0 V78f2bq2/dg1gVuGy79O8fTSEQshl9JogCcBDr2cpHQxKz/q9NbZx24mLZg8OAffuqrKjtdzHJ4Z +VQxlSknrs9YcExNmaRq4Jjy2N9vz/pDZ28GvUkx0tXt4ChbV5t0G2+swvaePGPAvOUT+1kbdRm4 dOYSElktKzb4twNbNPtOe3tqCs16+Aw3pAaxc49enQDXeuxqL9fOKno2Y/v3BUhZqbOzLv2XmzEe HcFHUR9HKwNj7Xr1HTYdO8qRH9eTc2Z0pixYsLhWZ4S49lgJt1y5KvxBbDbF2RN+PXd05/GD+8Wa rSzEJUDV6tCGKfClU4eOynVXew4+Thve3W7+/IUUA6t3d87/tPDc9tmeP6/7ef7Gn8eOHNC0DdRC /xT6FwA5JDQVFbYYU/66z7+RhHw+mUoV1BbRtExFGPbtJqeun1n2VG2B3zS7r3ttoRb6hP5hxs0+ Q0i/yp+xTta0NKaN2YtathKZcvB61HfVqQqGGWlT/65stdC/nf4FM/CPgpRuoRb6/9O/gYFbqIX+ s/Sj36ZxdXLyHDP2zI3vUOPchEQitf/0JU+GW8TWrtnyLZFsXL/+jz6JBLwvpt70YsV8JxLr677+ Ekkljc2KE8Tnfsk0sSKF+m6deTlNwkzZcev7NNrnhF3T9g74riD/dPrRGTjqw4cz+zafWjeZNORv 12P+CWGA1lgdtIhVTqeMwp0ka7tv2nly7lBvbI3PZSt+WjHWNYv/SYC/k5jMv32/4PbWUaHFnPpn TCIQo4P9XmqfNbf9GWIzOdYGdGV14+7tvs+cjYQlAbXfOkz8S6h5cSRfpbocSg00QJUIq8mLJbLN xtUYu+Hu+4kIROUzC9kgS6jGOEnnp+72gW6rIdvhr+XYbRjGB6167hxpCx9d7UwBMMLjlLTWQbtH gaHZ/KpCALwstVEg+IFTk4bitbcHpn3gY16UP3rq7RV+/qC83gSYwMJ5AIqGj4CWjoO9idz6LEB2 ST9UiRWK4Ap/yz/KDnhD8mRm2IzrojKf6I/hNruBaQNLlvBF5tOT8DepkAkfH/kuh+4BM3b6TBt9 4BEyQj0ZgLgC1sbRfeD7vjP3KYY9Pn8IfBmZWVmTGWljt4qKNtYc4fveALAy7q+78R73xVazcJIH SX+DVNXN90FKjiwA+P0IMuGXV82VZ/VNMU/uWcRnIUyLPdJ0+8tYkMwnMty+j7yCHFdgmEB2Wui2 U/76SBxS72yLM2ZWjdhTS+POPWQwfebFaPh+aT9D1AZIrSyTlXjOPyTj5KKJm/wR2tx2ObKiVlWA LPfSu01QLOwcTXRmPuPI3dx3AVqTAgy01UD7kXgLy0bH2LyqfXMHvn6PLC1vvxAKvxTEoRPHPpNg 36jvVDWCrxim/wGpmRm47H3hxIlJ8N/mPfmf+w4lTGtGceG84R0Bbu0a/pZVs7yowPdJ2o5lo4Ys 8eVzmS8+FIWfHGviOLgoK56kQqtNRvx27PodACipucU0hM1ADWlovFCNSt59LmS8i8kbhtBcF5x9 ER95Yz/o0I9Xnov6VnDMBHeLHFY1oGoVVzGj7x+37OOd9gqJZDVsbht0wUBcWZAOAJXD5WKiklYO HphEqKIE3iRlT/aw+u1jFd5xvdOfnPQYd1heBtj3cPWOSh9zGfnxERV8GW9zOew5A60eplcLhCJD TZWzjyLPLJ48aMUdhYBAU8+wIOmO84JjDw6uNe3oyuFxYHE4uc/VXEZiYjTLxVxaOWDK4moGzD+N V6eg6HXQDpqae2lRNgBq1SkI93LvY65TO91SIWJgiQgJ0eUC6dFVY7pNOkYEEVV+AEC/sLSUTlHJ rBJAFjLr4FiWFTxy35OhTsaBb5LCf/8VgJ/qsoYQcMGxaSt6dll+8s1YNcCWZdhJyOf+tqLHkdAs nkB0ePm4iVt/E0vF95+msVms9qga2RIppq+q4v8s/uGJjRNOvh+rhZSBV1VmGNl2fXlw9LxDV1jM mt5mIJWDJZ6a7Bec6LMIDlOAUVUFC87MeAiMHKtYnBNTLK+EZxNZSXx2CljOFAp4z8NiIQNDz+cf RvXr0KpQgGkBEBSe8d5vwfI913dPdYPNyuSwALV35NVdJjYOHB7X3tbs0cfy/7V35nFNHmkcn5wE wn3IkchlAFFcqcYLb8SLikXXo+tqtZbWal2t2mqlWmy1Wq1VsRWPrla8xa6IbVdd70WxHkAAATkE whGuXOTOmzfvu/MSTNW1u5/d0uJr5/uHTnhn3jl4fvM8b0jmab8/ZVRffJvXaZb9W9HFAta3aG/f Ud++rcq+9cwjrx6FQzx3k8WKt94FfE/4asuu/dBU+/N/Sl09fEBYVpEtjzbHrLoXmLiKxFvcBNRH o6HhtlInSnqS7ccjqyzk4VXz15+lUpzyHB1iX3tXZbCoavMBoA5Ynz064kaJpHt8+/FxWBUU8P53 R2UrKWEEt8cCBKaxBQUWuSSof5xZVw/8Z8GX1/etWXqkFF6qUZpl2Ydi4hc8GhoGXKkPOaduXOXI 47gFhD8+veRFL5+t0trvqam8Lh6ebL8Kf0i5veI6uwAADgpJREFUPH2hd8KahS/3LtESJGFxbK8p ACDn3M6e0w4uGtLH18/TRxiSX95kb7h8KKhsP8uvFx9U5xzz6xELywPCfB8aKAHDcsoMwcTlVDRh zzB68+tFU5YepIbUy/XHSjU0fQVGJfiOW/sD9Im+rmDqmyvsxwNa2qqcfQSw0PLj/j8v+vrtMJuA 4YZC+fObp1Zv/Gc1LMjuZQ+OCIU7V85DFXz5ahQwdMyLOvv6H7s+PFis7+3KP3C1DO6G3iIxfDJR t6cCXzWtPxTw0Vf9Dl0vXzsvfsLqUyRhhvH3jj+N2XKukrRlcpV1GMxcbyA3dGSBgAJ2jqRysk4e GFSoaHEP7QfLkvR3Np8tWDTKM/Vmc3vvvu9M6ZurpjoKD3Crq8+zGxX9/G/XnokFcfJxHjjAbeBA 92GDfyZ7WMR0ksBnxEXzOCwFywvonRVa/Zsz4nxco529QM6DBqO29au9lxMFHulHTsmKsplcLtZS MrJfCGC5tynU8AbOHl6VjWrQnYqf/TnsBqUxso/vubNUyunT14p/2L1+9ew4HW4Aw6jMvSwuW006 NV1dI1NqMw8dgdbu4OyStuMyiRv17ccf22G7+pgxK5vjARqPyTXaz/YdSRhNfb5a6MFl8zh6k/2I Ag7QtGHaZl7vKQqlKordXP1vX31msHkuLPCgSZm2emN4Yvzjl6gQ3ylUnlPI5vHOZBVYMZ2VOlEW bEhJipm4pPjU3GBPx1EzP6mveqC+/80XVzq+HdlvdMLHW0/JKvNL9AEWo6bb6AXtvTCVWrPtIIV1 J2uvbls5IHGF/aiu8JdG5l87oNeptlUauvs7t8ENjwOlx7t0u8iNC47dkR5LTVk8LrLJQAVBbGdv nVota9MlL9gSNmqwb3i37PK62qqnT2X44Wbehdyioovbkg/eePLKTQNO1re2pO+4XE8So16CImfL 1drE10TvbkjXaxTXJA8JEkQNGWrUmxW4cclbk6h39FggtLfvpawz9cU3rsJowbUjibyvCGTmFFsx /e7dJ6A/YvWgvp7lGhBQUatVN9XD4UpLZUW37pjalEkx3dpbNPv4BKSnXynNOV0ua/P284NGJddQ RiX0jH62ET7PdPUO8p+x9ox801YqzNh8trA+59tNPUJDwiIi71SrMFV1aJBQKAxMb4+meoaFCgWB 0MngLTkJq3aR1F5LnXi6OXF0VmFLUPBwWJ7j5nKrUq0oyIqZ8AmOKSMjwkQi0ZyUb4zyh6LwVbBC 2vtJWy/XlV89EBIcHBk1rnfs64RFFxkWEhgcGjdu0NYLtQSm9fEPah9a24w3FsP/M9aNEwoE0xdS nhO2MkFvra/pNeqP9jlEJy62GlWR4SI/P79eUa8/Pr3Nq2ZdkFJuqSUvo7tQKBoy/fGrUVGTbQU4 R6uhOSw0KChU1K9v+D+KlaRJJh4db7s6fUzvUJFIHDPCYvcgVlNkWHCAILCkQaMsuzThlTT4sxUJ Y07lt4aLRLYqAQBU655wOcun9eouFGw5I4HlgaE9SCo3ktZXkGhWVveEzUSipakn7ZUl328XCrv3 HEula2ituR4SGCiKiHR1pZ7hc7/7NPXHelhY+fqkgAB/OGaFjvKQ82P8bQ7/m2UJAoFg5NjhQRHR M1/6Q0kztQI+3WBsQowYFB0cGhr3cuz5WmPjldTrFc37PlpyLE9OrYZI0IaTb0+N7T1gDNSz3Ngx eLip9QkLCRAI30k5+uDi8c2XqfxVV7f95cO9t09tWwY7ipo0Xyjov+OdoY3tzy6ibr6w0R/6RPUT D/J3c4BBHGVUIZRRZZc1/3eTfM54kf8OTFit9q8x2YAmwmA872+8/xao7jL6fkHWnujqcfxfWNoY Tv4Wi+EXfooQN+m5js4Eze3/Rbbmp9QL2g+y7ZKRPG+cXvva/v0pXT2K/5mjH01gQLjup86V/BL1 rnhtJLwNh+9+q6Kp0wbXRbzIHhiBeOFBHgmBoDFIwAgEjUECRiBoDBIwAkFjkIARCBqDBIxA0Bgk YASCxiABIxA0BgkYgaAxSMAIBI1BAkYgaAwSMAJBY5CAEQgagwSMQNAYJGAEgsYgASMQNAYJGIGg MUjACASNQQJGIGgMEjACQWOQgBEIGoMEjEDQmE4WcHNlm62gbDE1NBgMRlsqXWA0UQkm9+6s3Xfw p5N4cZPl88+lNwo7EiA1Vmvv5VNZgopzWnbulB7JaCIe1cyv7Mija8Kf6A7Xm47e1APaQuLWujpD ixwj9YYvNkqTk6sOZSpKy3UymbFZbsZMeMbJBrhE5TLMVl8ra6tX4U/dJP24wlY4tVVqIEBzq+W/ d0zgFZW6/Lsq+wrf/r5Z8fSNKa6cb5ZT6VzAmSP1V3Kp31Rdierg4UbbXa5dlVv/50m/CGBmK0EC db3uQgUmr++wQLVM1/qs5Th6otlWwDX62tZnrfIvoJMFnH25qaSBGu6JQzWvvFL64QclaqVePCTv g/fvf/O3uvRMhTumWbpLaqvc1tTGDzHvTi7PrtId+ujBXz6tPpdVK55QdHRbXVA47sHSVze1J6Mm LO8vLieh6VyUfvxlVYuqY5FIK6GqM17La3zUOZn1dZlE2ta5M/pVaanUfrSyLHlD2cVb0haOft48 Rz9nzfFDNdOnlOzcVrF7Z9me44qYGPLOzVrb4d1lZ+pWvV0oHluoNgPMRK0DtKOjF2U6LWUW+dfV rRr9gZOVWpUZpzJl/my/JoV+z+bK9dvrih5Sq4eZCWmJVtqoeKpagji3uF45aZRkz/rSnCrtobWl N/Nb5idL2WbN+FmlccPypdXyPy8t/bVW53ll3RuSpMXFSa8XNDWYjmTWHEmva9EaLJj1oaQpt0z6 VOXlC+9v39NIZbQyYzGxZRqtsnMH0/khNJfBgf8ueq8nAIxN2/vgdQpgIeG8Rg7txmSA745rg31+ Su/192P6siarM9e465pxz/bIteuiPOWY0QQ2rFWnbFIHd6PyvloNHZtWdYXFy9MaP1YSNyJX8lA3 LFYye3G1mzMYOjh33Ki8nQeq007oP1xaXXCjJnZsnlicSzz3R9b79nSfGc+ftdBzWJDL5ZPGWbNk fyvlfbIhytUBrFoTMXeKQFNvWbFMYeS72bNyv7dRlPWZ99R592OGSaC/HTKpSFmIzZlTNHFRBbzK MBmKa4kFY+/HTS6cuLLM3pHFQpgxu7sFPB+3d2d4Rgzk6/K150rqXp0skessTRJF7IQiY03z5PeK bdW+u9vfUmJxCeHcOG9YviT0q61elw7KEmd7zE4SGVtMLB7jyzS9t9Nzv8qdzb0qoqQM9wzz4LOp X8v5SwZdkXJ8QuGydW1CHi9mJGV7cAu1Vd62O8pdyIL1dkwtIpjkvBmyzjXLX5hf5mkUlaafggh3 FocJpCrHe3ejjUbN+DmlHh6sT7Z6BAYF2assSHENrsfS05UcJ4a3CwcYtEp/NhvgWed7Bnh1JHRn 8dhGM5XCJuO2/o313pe+N5z/Wrgno3p6kmdCMP9kk8p3vNNbDkzmULdwFs4a6HhypVKjIj9PcyN/ 7Vz0nQELgCC+AzBiy9Z5Jsb6OfKohISOTgyTFecC4N3P8fy+XvbKRi3hTJKC/v4adStgMhyYoFs4 CwtgZv6114i4Ait8zQJCd+YlADL2Bs/4uMHWyiA3xk8r5XsyM0725XMYgCDE86Wboq3+IY6k1eDF 5wEG3HYZftFeTvKa4dPq044H2homDcid9JV7Vr+glJkFHC77Toaqew92fSOBq00sJmhTQtsNnxBX QWz6Hb2VQuLE3r+/5MPEdn9anlkIn+wYmInMytRuPRCoPCFTFyowPTl3pQvACeDwqA2LWp+8ZnDi fOThTdV5DSqx0KOzxtPJK0+SZNLMGrgDTRiTC9T4sNGSy982xIwoGD6iKnkJtD0QEhLMYj4SFsn8 +A318j3meTPd1s9xga3EI8rTd/gxLNCiHhsYmzO9N2PY0FwikBPh4ymvxsVxNYNHel3Yq5i5rLa2 ldF03pCSqbt4Ws10oFq9lypkMsH7yzWtKlPnzq7TqctpWp2qnZkoLWg1pW1RTZlc9kEG9QDC4jDY JEmtk+aJ+iYLWPJm1ZBBeWtXus4XMwaJc/VWoJSYxeL8pevc9LA+g6kxwh2e0U3gBoosts3Uydvx 2rV+P5yOptQLYTLdpar1GZrRYoeIPj6L/lhbKydNDOrS4dMhIJTbN8QLdDQEX65pixteuPSz4PEj JCsvg0lzRaXnVIPjHmze7hHuzkh8uXxAIu+3XLEuh8CtU0fkDRt+/3oNOUjA6x7CYrHBnOXCt16p +eA45t7HE9rg4S3aGnnHo9y6hffVxVieTLHjUPe508quVeHBLo6dOJ7Ozo1EknqDkcvlcjgsgoCm QpkFbsFIBpMDPSvsi/GEW8QtOJMNFU39kLDiuJWETUkCx6ENM5+oiZnNTA6HTVgm/unBd8d7sdlU oA4bwC6YTKbFgjMAyeZwMJzgspkkScCHQ/a/JTd7DrFaraz2cVrMJjMOy2xHnn3rBnqtju/i/Hh9 zGS0WEk+n8rsa4GRsdXKdXAgCMJ2k46Uk+3gmJnNdQA/g06r5fGd2UwGvAOVtJFJxWJr4vNmpPpG Rwif1YK0Wjt6sY8Zxy1MFpvJoEOo06lgGAaNDU4cWiCbDd0GtD4Smhxliwy4LDib/YzY1goflAGT y+nMsJd+yc2kNc1Bwb5dPYoXE6NGx+TzHVi/O0HSF/oJGIFA2Pn9vPuAQLyAIAEjEDQGCRiBoDFI wAgEjUECRiBoDBIwAkFjkIARCBqDBIxA0BgkYASCxiABIxA05l/MlWTEMhHDRwAAAABJRU5ErkJg gg== --Apple-Mail-102--974640808 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 29, 2009, at 10:51 AM, Dino Farinacci wrote: >> I personally believe that you should not have a limit in the number >> of the RLOCs in the reply (except the size of UDP segment). And >> consider the 31(32) first best RLOCs in the R bits. You have thus >> to know the order of the RLOCs in the Rbits, this is an open >> question that you also have when you limit the number. What if you >> have removed an RLOC and that a correspondent is still using an old >> mapping (e.g., the position of the RLOCs is not the same in the two >> mappings as you do not have the same number of RLOCs)? It seems to >> be a major issue of the R bits (in addition to the big security >> hole). Versioning has been thought to avoid these problems. Yes I >> try to sell versioning! ;-) > > Damien, the spec indicates ways to deal with this. A removed RLOC > from an RLOC-set can simply be marked down with a loc-reach-bit so > any ITRs which have an old mapping instance cached, can just stop > using it. We have tested this in our implementation. Adding an RLOC > to the end of a list is simple by having an ITR notice that a loc- > reach-bit is set for an RLOC it doesn't have. So it can then go > request a new Map-Reply. We have not tested this. > > As for the loc-reach-bits and security, there is no reason that an > ITR can take the change as advisement and then send a Map-Request to > solicit a reply which will tell you if the loc-reach-bit change is > authoritative and legit. > > Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-102--974640808-- From olivier.bonaventure@uclouvain.be Fri May 29 12:31:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB873A6AD0 for ; Fri, 29 May 2009 12:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbdiqXNjsZGx for ; Fri, 29 May 2009 12:31:44 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 933F73A6BFC for ; Fri, 29 May 2009 12:31:44 -0700 (PDT) Received: from mbpobo.local (ip-83-134-219-160.dsl.scarlet.be [83.134.219.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id D4DE6E8BA2; Fri, 29 May 2009 21:33:28 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be D4DE6E8BA2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1243625609; bh=so+tSBKmSALFBI7f+4OWmY+I+O8Kb7veCeqCYpqTsuo=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=m6egNYZO2nGlzboZcsRz5vW+edRC9TMoqxsPnSAC4lhCx2eL6xdpG2g0PiFXICSVO sQOwSA93Kz5nl3IIc/dLvh9feoSiRMi8ZCUa5nVfbR8s3BSCafo1HRiFMo4kdV5PWr gmEMJvt+BmikOvkCNfnd+3BU7wzY9xJ2am/yg0Do= Message-ID: <4A203884.5020901@uclouvain.be> Date: Fri, 29 May 2009 21:33:24 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dino Farinacci References: <4A1D38B3.2020902@uclouvain.be> <75605CFE-3DF9-4C71-9FA2-FD2D5DECDA8A@cisco.com> In-Reply-To: <75605CFE-3DF9-4C71-9FA2-FD2D5DECDA8A@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: D4DE6E8BA2.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] On the two usages of Map-Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 19:31:45 -0000 Dino, >> In the LISP architecture, the mapping system is used for two related but >> different purposes : >> >> Discovery usage : This is the first usage of the Map-Request messages. >> When an ITR needs to send a packet towards an EID for which it does not >> knw any mapping, it will send a mapping request through the mapping >> system and will receive a Map-Reply message that provides the mapping >> that it can insert in its mapping cache. > > Right. > >> Update usage : This is the second usage of Map-Request messages. Even if >> the ITR already knows a mapping for a given EID, it may need to send >> Map-Request messages to one or several of the ETRs that are responsible >> for this EID. Typical examples include updating the mapping upon >> expiration of the mapping lifetime, verification of the reachability of >> a remote ETR, reaction to reception of a packet containing the SMR bit >> set, ... > > Yes, but if an ITR wants to send a Map-Request as a keepalive or to find > more recent mapping, it can do so by sending to the locator address of > one of the ETRs. So this doesn't directly use the mapping system. Yes, discovery Map_requests will be send via the mapping system while update Map-Requests can be sent directly to the ETRs > Likewise, SMRs are from ETR to ITR so they too don't use the mapping > system directly. Agreed. >> I think that in the discussion about the mapping systems that it would >> be useful to distinguish between these two roles of the LISP Map-Request >> messages because there two usages can be potentially different. For >> example, Map-Request used for update will likely be more frequent than >> Map-Requests used for Discovery, Map-Requests used for update may > > For the same mapping entry? I don't think that is true, but you may have > another more application for it. Assume a Mapping entry with a TTL of 5 minutes. When the ITR uses the prefix for the first time, it will send the request to the mapping system. However, when it needs to re-confirm the mapping at the expiration of its TTL, it can send the Map-Request directly to the ETR without using the mapping system. >> include additional information compared to the Map-Request that are used >> for discovery, Map-Requests used for update could have a shorter >> retransmission timer than Map-Request used for discovery, ... Another >> example is the rate limit imposed on Map-Request. The current draft >> recommends : "Map-Requests MUST be rate-limited. It is recommended that >> a Map-Request for the same EID-prefix be sent no more than once per >> second." This is an important requirement for Map-Requests that are used >> for discovery. However, Map-Requests that are used for update could have >> a different rate-limit. For example, when sending Map-Requests to >> update the mapping of an EID prefix reachable via two RLOCs, then it >> could be acceptable to send a Map-Request to both RLOCs at the same time. > > I don't know what you mean exactly by using a Map-Request for an update. I mean that the ITR sending the Map-Request already knows the mapping and wants to verify that the mapping did not change or reconfirm it after a TTL expiration. Assume a site with two ETRs. If an ITR needs to revalidate the mapping of this site, it could send a Map-Request to both ETRs to obtain a faster response. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From damien.saucez@uclouvain.be Fri May 29 14:18:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DBC3A6FDB for ; Fri, 29 May 2009 14:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMcdXRK9GpSw for ; Fri, 29 May 2009 14:18:32 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 68DC83A6FE6 for ; Fri, 29 May 2009 14:18:32 -0700 (PDT) Received: from [192.168.1.4] (unknown [88.197.225.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 403B4EB5CD; Fri, 29 May 2009 23:20:13 +0200 (CEST) Message-ID: <4A20518B.2060209@uclouvain.be> Date: Fri, 29 May 2009 23:20:11 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Dino Farinacci References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1F8DA1.8040108@uclouvain.be> <2B9F303A-3636-4A5E-9C88-D6BC3829A76A@cisco.com> In-Reply-To: <2B9F303A-3636-4A5E-9C88-D6BC3829A76A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 403B4EB5CD.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: 'Noel Chiappa' , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 21:18:34 -0000 Dino Farinacci wrote: >> I personally believe that you should not have a limit in the number >> of the RLOCs in the reply (except the size of UDP segment). And >> consider the 31(32) first best RLOCs in the R bits. You have thus to >> know the order of the RLOCs in the Rbits, this is an open question >> that you also have when you limit the number. What if you have >> removed an RLOC and that a correspondent is still using an old >> mapping (e.g., the position of the RLOCs is not the same in the two >> mappings as you do not have the same number of RLOCs)? It seems to be >> a major issue of the R bits (in addition to the big security hole). >> Versioning has been thought to avoid these problems. Yes I try to >> sell versioning! ;-) > > Damien, the spec indicates ways to deal with this. A removed RLOC from > an RLOC-set can simply be marked down with a loc-reach-bit so any ITRs > which have an old mapping instance cached, can just stop using it. We > have tested this in our implementation. Adding an RLOC to the end of a > list is simple by having an ITR notice that a loc-reach-bit is set for > an RLOC it doesn't have. So it can then go request a new Map-Reply. We > have not tested this. > Are you sure that you proposal support the following case: R_1 receive the mapping x:X (1,100,R), y:Y (2,100,R)at time 1 the mapping is changed at time 2 and becomes a:Z(1,100,!R) b:G (2,100,R) R_1 receives the mapping only at time 4 > As for the loc-reach-bits and security, there is no reason that an ITR > can take the change as advisement and then send a Map-Request to > solicit a reply which will tell you if the loc-reach-bit change is > authoritative and legit. You then consider the Rbits information during the mapping delay. It is then possible to have a DoS attack on existing flow by setting the Rbits at 0. Then, if you manage to slow down the mapping system for this mapping, it is a more important problem because you manage to break the current flows and limit the possible new flows. Would a better solution be to consider the mapping as it was and wait for the reply before changing the way packets are sent? Damien Saucez > > Dino From damien.saucez@uclouvain.be Fri May 29 14:26:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188113A6932 for ; Fri, 29 May 2009 14:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDc8G1xLhCHr for ; Fri, 29 May 2009 14:26:53 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 512683A6922 for ; Fri, 29 May 2009 14:26:53 -0700 (PDT) Received: from [192.168.1.4] (unknown [88.197.225.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id ACECCE8C80; Fri, 29 May 2009 23:28:37 +0200 (CEST) Message-ID: <4A205380.1090500@uclouvain.be> Date: Fri, 29 May 2009 23:28:32 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Dino Farinacci References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1F8DA1.8040108@uclouvain.be> <2B9F303A-3636-4A5E-9C88-D6BC3829A76A@cisco.com> <4A20518B.2060209@uclouvain.be> In-Reply-To: <4A20518B.2060209@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: ACECCE8C80.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: 'Noel Chiappa' , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 21:26:54 -0000 Oops, the case I would like to present is this one: R_1 receive the mapping X (1,100,R), Y (2,100,R)at time 1 the mapping is changed at time 2 and becomes Z(1,100,!R) G (2,100,R) P(3,100, R) R_1 receives the mapping only at time 4 Damien Saucez From dino@cisco.com Fri May 29 16:06:28 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C728D3A691D for ; Fri, 29 May 2009 16:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7Ez3iQ7OTzO for ; Fri, 29 May 2009 16:06:22 -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 6965B3A68BF for ; Fri, 29 May 2009 16:05:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,273,1241395200"; d="scan'208";a="165729403" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 May 2009 23:07:43 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4TN7hW8012961; Fri, 29 May 2009 16:07:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n4TN7c0Z004266; Fri, 29 May 2009 23:07:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 16:07:43 -0700 Received: from dhcp-171-71-55-144.cisco.com ([171.71.55.144]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 16:07:42 -0700 Message-Id: <779D2DBE-3F68-47A6-AF57-6CDC0455EB78@cisco.com> From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <4A203884.5020901@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 29 May 2009 16:07:44 -0700 References: <4A1D38B3.2020902@uclouvain.be> <75605CFE-3DF9-4C71-9FA2-FD2D5DECDA8A@cisco.com> <4A203884.5020901@uclouvain.be> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 May 2009 23:07:42.0782 (UTC) FILETIME=[454685E0:01C9E0B2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4000; t=1243638463; x=1244502463; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20On=20the=20two=20usages=20of=2 0Map-Requests |Sender:=20; bh=F4gOlLs1n2+41W4mo8GHbjzH6auPG2k8Jpg4PBv0xwM=; b=d/yq+V4EMuUcmy12uMHSQtWorDdBdOBpmmzRe7oB6tyXIs82jnGav5o0Jw gdYFk7EcNjvEE1i7ojSxn802T1Le5eL8H6GXUIWmC4HCQO1vY2AIir2+m+g7 ET6r59Mb3/; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] On the two usages of Map-Requests X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 29 May 2009 23:06:29 -0000 > Dino, > >>> In the LISP architecture, the mapping system is used for two >>> related but >>> different purposes : >>> >>> Discovery usage : This is the first usage of the Map-Request >>> messages. >>> When an ITR needs to send a packet towards an EID for which it >>> does not >>> knw any mapping, it will send a mapping request through the mapping >>> system and will receive a Map-Reply message that provides the >>> mapping >>> that it can insert in its mapping cache. >> >> Right. >> >>> Update usage : This is the second usage of Map-Request messages. >>> Even if >>> the ITR already knows a mapping for a given EID, it may need to send >>> Map-Request messages to one or several of the ETRs that are >>> responsible >>> for this EID. Typical examples include updating the mapping upon >>> expiration of the mapping lifetime, verification of the >>> reachability of >>> a remote ETR, reaction to reception of a packet containing the SMR >>> bit >>> set, ... >> >> Yes, but if an ITR wants to send a Map-Request as a keepalive or to >> find >> more recent mapping, it can do so by sending to the locator address >> of >> one of the ETRs. So this doesn't directly use the mapping system. > > Yes, discovery Map_requests will be send via the mapping system while > update Map-Requests can be sent directly to the ETRs Agree. >> Likewise, SMRs are from ETR to ITR so they too don't use the mapping >> system directly. > > Agreed. > >>> I think that in the discussion about the mapping systems that it >>> would >>> be useful to distinguish between these two roles of the LISP Map- >>> Request >>> messages because there two usages can be potentially different. For >>> example, Map-Request used for update will likely be more frequent >>> than >>> Map-Requests used for Discovery, Map-Requests used for update may >> >> For the same mapping entry? I don't think that is true, but you may >> have >> another more application for it. > > Assume a Mapping entry with a TTL of 5 minutes. When the ITR uses the > prefix for the first time, it will send the request to the mapping > system. However, when it needs to re-confirm the mapping at the > expiration of its TTL, it can send the Map-Request directly to the ETR > without using the mapping system. Yes, but you assume all the security is sending the Map-Request on the ALT. I was stating that the nonce usage adds even more value. >>> include additional information compared to the Map-Request that >>> are used >>> for discovery, Map-Requests used for update could have a shorter >>> retransmission timer than Map-Request used for discovery, ... >>> Another >>> example is the rate limit imposed on Map-Request. The current draft >>> recommends : "Map-Requests MUST be rate-limited. It is >>> recommended that >>> a Map-Request for the same EID-prefix be sent no more than once per >>> second." This is an important requirement for Map-Requests that >>> are used >>> for discovery. However, Map-Requests that are used for update >>> could have >>> a different rate-limit. For example, when sending Map-Requests to >>> update the mapping of an EID prefix reachable via two RLOCs, then it >>> could be acceptable to send a Map-Request to both RLOCs at the >>> same time. >> >> I don't know what you mean exactly by using a Map-Request for an >> update. > > I mean that the ITR sending the Map-Request already knows the mapping > and wants to verify that the mapping did not change or reconfirm it > after a TTL expiration. Okay. > Assume a site with two ETRs. If an ITR needs to revalidate the mapping > of this site, it could send a Map-Request to both ETRs to obtain a > faster response. Not worth the overhead. What if there are 8 ETRs and how do you know which ones are the better ones to send to. Dino > > > Olivier > > > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium From dino@cisco.com Sat May 30 15:58:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5AA3A6F8E for ; Sat, 30 May 2009 15:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 YnAtio+YLML9 for ; Sat, 30 May 2009 15:58:03 -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 0172E3A6F70 for ; Sat, 30 May 2009 15:58:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,277,1241395200"; d="scan'208";a="313645408" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 May 2009 22:59:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4UMxlFx010467; Sat, 30 May 2009 15:59:47 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4UMxmU0026973; Sat, 30 May 2009 22:59:48 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 May 2009 15:59:47 -0700 Received: from [192.168.1.2] ([10.21.120.128]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 May 2009 15:59:47 -0700 Message-Id: From: Dino Farinacci To: Damien Saucez In-Reply-To: <4A20518B.2060209@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 30 May 2009 15:59:47 -0700 References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1F8DA1.8040108@uclouvain.be> <2B9F303A-3636-4A5E-9C88-D6BC3829A76A@cisco.com> <4A20518B.2060209@uclouvain.be> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 May 2009 22:59:47.0510 (UTC) FILETIME=[54678560:01C9E17A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=830; t=1243724388; x=1244588388; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Can=20I=20get=20opinions? |Sender:=20; bh=3FBystdFyP4cnNg0c40ZNK4EZr4OCBzozu1tUc67+Xk=; b=tFWHZR7CoiEIVyYkayoQuMzEa1a8G1Om0o1JF62zrxGOyqv/89uKj8V1V4 McoVy3oru3iJPheHHKqyzh4KCUaAtBQ3L7hObHHSiuNZPoZ5kapTpLYIECpx Tlgd9vOuXp7qkESiyCRJZC/XnSLYzDOThZ2n6NEfzTfk03fTvoeMQ=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Noel Chiappa' , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 30 May 2009 22:58:03 -0000 > You then consider the Rbits information during the mapping delay. It > is then possible to have a DoS attack on existing flow by setting > the Rbits at 0. Then, if you manage to slow down the mapping system The spec says the loc-reach-bits are a hint. That means if you are paranoid about who sets them and reacting to them, it means you send a Map-Request first for verification. This is true for data gleaning an new RLOC and gleaning mapping information from a received Map-Request as well. > for this mapping, it is a more important problem because you manage > to break the current flows and limit the possible new flows. Would a > better solution be to consider the mapping as it was and wait for > the reply before changing the way packets are sent? Yes, we spec it that way. Dino From dino@cisco.com Sat May 30 15:59:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7641A3A6F4D for ; Sat, 30 May 2009 15:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 dJ06bRWh6pXW for ; Sat, 30 May 2009 15:59:50 -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 C6B013A6E25 for ; Sat, 30 May 2009 15:59:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,277,1241395200"; d="scan'208";a="78437722" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 30 May 2009 23:01:35 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4UN1Z1Q029389; Sat, 30 May 2009 16:01:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4UN1ZE6025862; Sat, 30 May 2009 23:01:35 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 May 2009 16:01:35 -0700 Received: from [192.168.1.2] ([10.21.120.128]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 May 2009 16:01:35 -0700 Message-Id: From: Dino Farinacci To: Damien Saucez In-Reply-To: <4A205380.1090500@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 30 May 2009 16:01:34 -0700 References: <20090528200451.85CDB6BE54F@mercury.lcs.mit.edu> <4A1F8DA1.8040108@uclouvain.be> <2B9F303A-3636-4A5E-9C88-D6BC3829A76A@cisco.com> <4A20518B.2060209@uclouvain.be> <4A205380.1090500@uclouvain.be> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 May 2009 23:01:35.0384 (UTC) FILETIME=[94B3C980:01C9E17A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=434; t=1243724495; x=1244588495; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Can=20I=20get=20opinions? |Sender:=20; bh=7Cs20SE46tJlZkCdkvnoU6s+QZf4WoVgtumvjqkS7Gg=; b=O2UllMb6rWGiys8bskgkM0/iF1DYtOHchkifVQGttPPpo45qM8FWQ5ziZh 3rJ9+3iwXLT9Vx2VFrVeS1pCrUCslfjQ/o6mRkAEQNkLkmXqt0jDawRV3dEO RQ6D43HWpt; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Noel Chiappa' , lisp@ietf.org Subject: Re: [lisp] Can I get opinions? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 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, 30 May 2009 22:59:51 -0000 > Oops, the case I would like to present is this one: > > R_1 receive the mapping X (1,100,R), Y (2,100,R)at time 1 > the mapping is changed at time 2 and becomes Z(1,100,!R) G (2,100,R) > P(3,100, R) > R_1 receives the mapping only at time 4 Z replaces X and not used because R-bit is clear. G replaces Y and is used, and P is a new RLOC but not used because priority 3 > priority 2. So what is the problem? Dino