From nobody Thu Oct 1 17:24:33 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112951A90E2 for ; Thu, 1 Oct 2015 17:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEgDhAZsUmSs for ; Thu, 1 Oct 2015 17:24:30 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9625A1A90E0 for ; Thu, 1 Oct 2015 17:24:29 -0700 (PDT) Received: by padhy16 with SMTP id hy16so89528926pad.1 for ; Thu, 01 Oct 2015 17:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fkPgCHpN9DeOG7QSAsjREReecGIE3cB2vmloTF0GjbQ=; b=C61JT10dHJApco6W3C+gWNs+Eoh9jMUqYt5BY+Gv20xZOUDKhcRhJfFw8nSHH2ww4U XmZsyy7noROT0EbBFLqACDKcWFRbQcLapIAW2Cwf0deSDiHDVQiNAgihISEOrddpnzPx VcQ2rjkDhFqhua5hWQHJd4MVpLgbnxUlCNuSv4T7Q8oLrzrVi+NwuI77BR/IfmJMzakw LnFHcYcCcQF8phvmtEwhBYF4PMIlRMUx7y/wySUj9zi43UqRyoKkwdUegdipws0fWDkz PH5KlziNza7r2rrhIZR5WLFP6cerCrHiAANdwgB3LUEJNNmcvYUfVxSNcb8Cqw1vlLcH 2qyw== X-Received: by 10.68.137.161 with SMTP id qj1mr15963863pbb.14.1443745469156; Thu, 01 Oct 2015 17:24:29 -0700 (PDT) Received: from [10.63.111.139] ([166.170.40.18]) by smtp.gmail.com with ESMTPSA id of1sm8960662pbc.11.2015.10.01.17.24.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Oct 2015 17:24:28 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-1B3B0ECA-86B5-459B-8DE7-E9E9915FE51E Mime-Version: 1.0 (1.0) From: farinacci@gmail.com X-Mailer: iPhone Mail (13A404) In-Reply-To: <560C63F1.9050201@cisco.com> Date: Thu, 1 Oct 2015 17:23:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: <870D90A9-20A5-4AB1-A2A0-0DBC723BDF91@gmail.com> References: <3C2AD973-A1F7-4C84-B8D5-31BAA8371CA5@gmail.com> <560C3A74.80808@cisco.com> <1DA97E7A-E11E-4C21-9B70-8BF217D62780@gmail.com> <560C63F1.9050201@cisco.com> To: Fabio Maino Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Comments to draft-rodrigueznatal-lisp-ms-smr-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 02 Oct 2015 00:24:32 -0000 --Apple-Mail-1B3B0ECA-86B5-459B-8DE7-E9E9915FE51E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Your email (see below) says the main point of the draft is to document the b= ehavior of ODL. If that is truly the main point, why shouldn't it go into th= e draft. Generalizing to an SDN usage could mean all sorts of intentions.=20= I look forward to discussing this at the WG meeting.=20 Dino > On Sep 30, 2015, at 3:36 PM, Fabio Maino wrote: >=20 > Hi Dino,=20 > the draft says, right in the abstract, that: "This extension is intended t= o be used in some SDN deployments that use LISP as a southbound protocol wit= h (P)ITRs that are compliant with [RFC6830]." I don't think we need to quali= fy that any further. It clearly states what the scope is without the need to= enumerate implementations (that I believe would be quite unusual for a draf= t).=20 >=20 > This is a draft marked as experimental contributed to the LISP WG as part= of the conversation on pub-sub. I honestly don't know what the WG will deci= de to do with it. I observe that the authors are not proposing this draft as= a WG item.=20 >=20 > If the WG will ever decide to have a WG draft on pub-sub, I hope there wil= l be a section talking about interoperability with xTRs that are RFC6830 com= pliant. This draft may, or may not, help writing that section.=20 >=20 > Thanks, > Fabio >=20 >=20 >> On 9/30/15 1:36 PM, Dino Farinacci wrote: >>> Hi Dino, >>> thanks for your replay. >>>=20 >>> The main goal of this draft is to document what is implemented in ODL (h= ttps://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Architectur= e), with the hope that comments and feedback will help us improve that solut= ion, and facilitate interoperability. >> The draft does not say that. >>=20 >> If that is the goal to document ODL behavior, can you please state that i= n the document. And indicate that this solution may not be a permanent one b= ut a draft that simply documents an implementation behavior? >>=20 >>> The driving requirement (as stated upfront in the abstract) is interoper= ability with EXISTING xTRs, as specified in RFC 6830. >> But more to the point for SDN environments, where with SDN, there are mul= tiple ways to skin a cat, where ODL is one such way of doing SDN. >>=20 >> Thanks, >> Dino >>=20 >=20 --Apple-Mail-1B3B0ECA-86B5-459B-8DE7-E9E9915FE51E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Your email (see below) says the main point of the draft is to document the behavior of ODL. If that is truly the main point, why shouldn't it go into the draft.  Generalizing to an SDN usage could mean all sorts of intentions. 

I look forward to discussing this at the WG meeting. 

Dino

On Sep 30, 2015, at 3:36 PM, Fabio Maino <fmaino@cisco.com> wrote:

Hi Dino,
the draft says, right in the abstract, that:  "This extension is intended to be used in some SDN deployments that use LISP as a southbound protocol with (P)ITRs that are compliant with [RFC6830]." I don't think we need to qualify that any further. It clearly states what the scope is without the need to enumerate implementations (that I believe would be quite unusual for a draft).

This is a draft marked as experimental  contributed to the LISP WG as part of the conversation on pub-sub. I honestly don't know what the WG will decide to do with it. I observe that the authors are not proposing this draft as a WG item.

If the WG will ever decide to have a WG draft on pub-sub, I hope there will be a section talking about interoperability with xTRs that are RFC6830 compliant. This draft may, or may not, help writing that section.

Thanks,
Fabio


On 9/30/15 1:36 PM, Dino Farinacci wrote:
Hi Dino,
thanks for your replay.

The main goal of this draft is to document what is implemented in ODL (https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Architecture), with the hope that comments and feedback will help us improve that solution, and facilitate interoperability.

The draft does not say that.

If that is the goal to document ODL behavior, can you please state that in the document. And indicate that this solution may not be a permanent one but a draft that simply documents an implementation behavior?


The driving requirement (as stated upfront in the abstract) is interoperability with EXISTING xTRs, as specified in RFC 6830.

But more to the point for SDN environments, where with SDN, there are multiple ways to skin a cat, where ODL is one such way of doing SDN.

Thanks,
Dino

--Apple-Mail-1B3B0ECA-86B5-459B-8DE7-E9E9915FE51E-- From nobody Mon Oct 5 10:31:23 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37D31B2A35 for ; Mon, 5 Oct 2015 10:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWpoZEYiuzSl for ; Mon, 5 Oct 2015 10:31:19 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id DA1BC1B2A36 for ; Mon, 5 Oct 2015 10:31:18 -0700 (PDT) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id t95Fe9FY002883 for ; Mon, 5 Oct 2015 17:40:10 +0200 Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id D2C31EF for ; Mon, 5 Oct 2015 19:31:16 +0200 (CEST) Received: by laddr2 with SMTP id dr2so12286052lad.3 for ; Mon, 05 Oct 2015 10:31:16 -0700 (PDT) X-Received: by 10.112.32.72 with SMTP id g8mr12070570lbi.22.1444066276278; Mon, 05 Oct 2015 10:31:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.59.225 with HTTP; Mon, 5 Oct 2015 10:30:56 -0700 (PDT) From: Alberto Rodriguez-Natal Date: Mon, 5 Oct 2015 19:30:56 +0200 Message-ID: To: "lisp@ietf.org list" , SDN IRTF list Content-Type: multipart/alternative; boundary=001a1135e3fa6e08af05215ee14c Archived-At: Subject: [lisp] LISP for SDN X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 17:31:22 -0000 --001a1135e3fa6e08af05215ee14c Content-Type: text/plain; charset=UTF-8 Hi all, We recently published the paper "LISP: a southbound SDN protocol?" in IEEE ComMag, people in these lists may find it interesting: http://www.researchgate.net/publication/280222575_LISP_a_southbound_SDN_protocol Thanks! Alberto --001a1135e3fa6e08af05215ee14c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We recently published the pap= er "LISP: a southbound SDN protocol?" in IEEE ComMag, people in t= hese lists may find it interesting:


Thanks!
Alberto
--001a1135e3fa6e08af05215ee14c-- From nobody Mon Oct 5 11:58:10 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8A1B3382; Mon, 5 Oct 2015 11:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgdZbV-CbMSw; Mon, 5 Oct 2015 11:58:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E7B1B3373; Mon, 5 Oct 2015 11:58:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151005185807.4818.13824.idtracker@ietfa.amsl.com> Date: Mon, 05 Oct 2015 11:58:07 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-impact-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 18:58:09 -0000 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 Impact Authors : Damien Saucez Luigi Iannone Albert Cabellos Florin Coras Filename : draft-ietf-lisp-impact-04.txt Pages : 16 Date : 2015-10-05 Abstract: The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet routing scalability properties by leveraging on three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end-user. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-impact-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-impact-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 5 12:02:07 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57931B3389 for ; Mon, 5 Oct 2015 12:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8XEpXKSllZT for ; Mon, 5 Oct 2015 12:02:04 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BE81B3375 for ; Mon, 5 Oct 2015 12:02:03 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so134949451wic.0 for ; Mon, 05 Oct 2015 12:02:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=5RuxkrQhnbR2XZQltZIUDiSb2ta3DaFDSP70rXNjc6w=; b=GWnqKmP+KlhHd6mmF6SPp+GBUO9OShKD11jc/dQQ7lM9tjdmGIZ9TyAA1OnXoWVBe3 SpWw3NdFF9gwBWe1D0hlcRO8qwgyeiPATq/T6ywJoXDfnzYhYe0ZtCTsWMFWYiE8Lrx6 oX9eeioVud5DJmaGucaILPXM49UjxkgodDtBSuw+LrpEVgYGhiL5utz6QYmDbL8NNlp5 BBzXuegwi5ObVZA7gVzuiWfT1UR+4u325GFjBtNnC2gGN/kH3khM3bxnsf2Ml+Jzskva q8xFYy7HWPdhuTQlzle3vuMtOGINJhX82whpLN4XbFdqg6r96avE/iKaM7X9rDnbGM7/ 3MOg== X-Gm-Message-State: ALoCoQlmYruJ8Qq8KzyKIgSOMNr0sFJoEOo3wQBhDTa4FD904uZSj4rWeahi4ASouGpMAvmAh9XM X-Received: by 10.180.109.200 with SMTP id hu8mr12719574wib.86.1444071722384; Mon, 05 Oct 2015 12:02:02 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:b8d2:68ff:9b20:53e1? ([2a01:e35:1381:3430:b8d2:68ff:9b20:53e1]) by smtp.gmail.com with ESMTPSA id xa5sm28356126wjc.20.2015.10.05.12.02.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Oct 2015 12:02:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Luigi Iannone In-Reply-To: <20151005185807.4818.13824.idtracker@ietfa.amsl.com> Date: Mon, 5 Oct 2015 21:01:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7853F4C1-A1CE-4B13-AB1A-1761C0DB7995@gigix.net> References: <20151005185807.4818.13824.idtracker@ietfa.amsl.com> To: LISP mailing list list X-Mailer: Apple Mail (2.3094) Archived-At: Subject: Re: [lisp] I-D Action: draft-ietf-lisp-impact-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 19:02:06 -0000 Hi All, This document has been updated to improve its readability in several = parts. All changes are editorial, content remains unchanged. Ciao Luigi > On 05 Oct 2015, at 20:58, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol = Working Group of the IETF. >=20 > Title : LISP Impact > Authors : Damien Saucez > Luigi Iannone > Albert Cabellos > Florin Coras > Filename : draft-ietf-lisp-impact-04.txt > Pages : 16 > Date : 2015-10-05 >=20 > Abstract: > The Locator/Identifier Separation Protocol (LISP) aims at improving > the Internet routing scalability properties by leveraging on three > principles: address role separation, encapsulation, and mapping. In > this document, based on implementation work, deployment experiences, > and theoretical studies, we discuss the impact that the deployment = of > LISP can have on both the routing infrastructure and the end-user. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-lisp-impact-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-impact-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Oct 5 13:23:14 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091B91B4FB8; Mon, 5 Oct 2015 13:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgjMsmAH59UJ; Mon, 5 Oct 2015 13:23:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B701E1B4FAF; Mon, 5 Oct 2015 13:23:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151005202310.30395.33813.idtracker@ietfa.amsl.com> Date: Mon, 05 Oct 2015 13:23:10 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] Last Call: (LISP Impact) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 20:23:12 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Impact' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-10-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet routing scalability properties by leveraging on three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end-user. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 9 19:58:22 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7711B5382 for ; Fri, 9 Oct 2015 19:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMYozeboRpdS for ; Fri, 9 Oct 2015 19:58:19 -0700 (PDT) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE8B1B537B for ; Fri, 9 Oct 2015 19:58:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3F64D1C02D6 for ; Fri, 9 Oct 2015 19:58:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id DB2711C029A for ; Fri, 9 Oct 2015 19:58:18 -0700 (PDT) References: <20151010012842.29540.92962.idtracker@ietfa.amsl.com> To: "lisp@ietf.org" From: "Joel M. Halpern" X-Forwarded-Message-Id: <20151010012842.29540.92962.idtracker@ietfa.amsl.com> Message-ID: <56187EC9.1060708@joelhalpern.com> Date: Fri, 9 Oct 2015 22:58:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151010012842.29540.92962.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Fwd: lisp - Requested session has been scheduled for IETF 94 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 02:58:20 -0000 We have a slot. We will be working on the agenda based on working group discussion. The best case is the charter discussion has largely converged on the list, and we can spend a little time on that and most of the time on work items. We will be sending a charter proposal to the list based on ideas from some of the WG participants once we have worked out some aspects with our AD. Yours, Joel -------- Forwarded Message -------- Subject: lisp - Requested session has been scheduled for IETF 94 Date: Fri, 09 Oct 2015 18:28:42 -0700 From: "IETF Secretariat" To: ggx@gigix.net CC: lisp-ads@ietf.org, jmh@joelhalpern.com, ggx@gigix.net Dear Luigi Iannone, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lisp Session 1 (1:30:00) Tuesday, Afternoon Session II 1520-1650 Room Name: Room 301 size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Locator/ID Separation Protocol Area Name: Routing Area Session Requester: Luigi Iannone Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: rtgwg nvo3 i2rs sidr grow sfc sdnrg nfvrg pim Second Priority: intarea mboned icnrg irtfopen idr spring Third Priority: l2tpext bess Special Requests: --------------------------------------------------------- From nobody Mon Oct 12 07:44:27 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA221B33F6 for ; Mon, 12 Oct 2015 07:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOjEBQwOMaO4 for ; Mon, 12 Oct 2015 07:44:24 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD941B33F5 for ; Mon, 12 Oct 2015 07:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1984; q=dns/txt; s=iport; t=1444661064; x=1445870664; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=dOfHQCk0lylcJSQzM+DMZqPthkYxr2UYXCp4nNPLjvU=; b=gC7NFor8gnm5JwKnGw4b1pkO8z0WXF71SzIfJMIdmbKWXkFF9Rqet43/ LHe0ssWrJnP3LDVIRlVsKvBH/4wAtpVr1QJaTjFuKDye4qjcLRJQ+0YSA RrDnhre+dws/ZWKqNsd5jZSbayHbg+SdhG/16O7QXe3NBzLBmxBeuU2jN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOAgD7xhtW/4oNJK1dgyZUbga9fQENgVoXCoJyggp/AoEyOBQBAQEBAQEBfwuEJgEBAQQBAQE3NB0BGQMBAh83Cx0KBBOILg2ab6MdAQEBAQYBAQEBGgSGc4R+hRqEKAWHPIVRiQYBeYwgjz+MQwEfAQFChAJxhmSBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,673,1437436800"; d="scan'208";a="197205748" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2015 14:44:23 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9CEiNml024170 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Oct 2015 14:44:23 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 12 Oct 2015 09:44:10 -0500 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1104.000; Mon, 12 Oct 2015 09:44:10 -0500 From: "Vina Ermagan (vermagan)" To: "lisp@ietf.org" Thread-Topic: Request for time on agenda IETF 94 Thread-Index: AQHRBPx0I3TeJO8BMU6AFqWRE9dB9Q== Date: Mon, 12 Oct 2015 14:44:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.240.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E919849B1E1944FBACC3335D20334D2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lisp] Request for time on agenda IETF 94 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 14:44:25 -0000 Hello Chairs, If the agenda permits, I would like to ask for 10 - 15 minutes to present the NSH extension draft (draft-ermagan-nsh-00). Thanks, Vina On 10/9/15 10:58 PM, "Joel M. Halpern" wrote: >We have a slot. We will be working on the agenda based on working group >discussion. The best case is the charter discussion has largely >converged on the list, and we can spend a little time on that and most >of the time on work items. > >We will be sending a charter proposal to the list based on ideas from >some of the WG participants once we have worked out some aspects with >our AD. > >Yours, >Joel > > >-------- Forwarded Message -------- >Subject: lisp - Requested session has been scheduled for IETF 94 >Date: Fri, 09 Oct 2015 18:28:42 -0700 >From: "IETF Secretariat" >To: ggx@gigix.net >CC: lisp-ads@ietf.org, jmh@joelhalpern.com, ggx@gigix.net > >Dear Luigi Iannone, > >The session(s) that you have requested have been scheduled. >Below is the scheduled session information followed by >the original request. > >lisp Session 1 (1:30:00) > Tuesday, Afternoon Session II 1520-1650 > Room Name: Room 301 size: 150 > --------------------------------------------- > > > >Request Information: > > >--------------------------------------------------------- >Working Group Name: Locator/ID Separation Protocol >Area Name: Routing Area >Session Requester: Luigi Iannone > >Number of Sessions: 1 >Length of Session(s): 1.5 Hours >Number of Attendees: 70 >Conflicts to Avoid: > First Priority: rtgwg nvo3 i2rs sidr grow sfc sdnrg nfvrg pim > Second Priority: intarea mboned icnrg irtfopen idr spring > Third Priority: l2tpext bess > > >Special Requests: > >--------------------------------------------------------- > > > > >_______________________________________________ >lisp mailing list >lisp@ietf.org >https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Oct 13 13:31:00 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8BA1A8A98 for ; Tue, 13 Oct 2015 13:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_FR=0.35, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od8rfI6Qf425 for ; Tue, 13 Oct 2015 13:30:55 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.52.34]) by ietfa.amsl.com (Postfix) with ESMTP id 15BBE1A8A84 for ; Tue, 13 Oct 2015 13:30:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy120.enst.fr (Postfix) with ESMTP id 2CE6A100A0F; Tue, 13 Oct 2015 22:30:54 +0200 (CEST) Received: from zproxy120.enst.fr ([127.0.0.1]) by localhost (zproxy120.enst.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4F_nH54EbseN; Tue, 13 Oct 2015 22:30:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy120.enst.fr (Postfix) with ESMTP id 9D007100A0C; Tue, 13 Oct 2015 22:30:53 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.0 zproxy120.enst.fr 9D007100A0C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-paristech.fr; s=A6AEC2EE-1106-11E5-B10E-D103FDDA8F2E; t=1444768253; bh=a7X8ozdxlVilzLdtWf2DTLWza1oErTt2D0e7rdMFOa8=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=wD4H2K0eiht0pjpcyBw1G5LwSHNFNu6FgepdA4EYGidLWGu0zI+GcvSrBgzZVBf9x HbFOc3bmgyga8pl+qcIYdgVjPbRNi8BFpWIa5Flt7/HnNU88zFSruoYRQ5FWu2SWBV Q4FEVtCGEIUw610K0/8d5fnljdLztAWS7BqWy2z0= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([127.0.0.1]) by localhost (zproxy120.enst.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VhUTlGXu5Nh5; Tue, 13 Oct 2015 22:30:53 +0200 (CEST) Received: from [192.168.0.42] (bny92-2-81-56-19-67.fbx.proxad.net [81.56.19.67]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 59D3B1003FD; Tue, 13 Oct 2015 22:30:53 +0200 (CEST) From: Luigi Iannone Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2015 22:30:52 +0200 Message-Id: To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) Archived-At: Subject: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 20:30:57 -0000 Folks, in the past weeks (and months) there was a fruitful discussion that took = place on the mailing list (and also in Prague) concerning=20 the new charter to be adopted by our WG. Thanks for this effort. Beside this discussion we had proposals from WG members as well as = discussion with our AD about what is practical and reasonable. Hereafter you can find the result: a draft of the new proposed charter. This does not mean that discussion is over, rather that we reached a = first consistent milestone for further discussion.=20 Discussion ideally culminating in our meeting in Japan. So please have look and send your thoughts and feedback to the mailing = list. Joel and Luigi = %=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol (LISP). LISP supports=20 a routing architecture which decouples the routing locators and=20 identifiers, thus allowing for efficient aggregation of the routing = locator=20 space and providing persistent identifiers in the identifier space.=20 LISP requires no changes to end-systems or to routers that do not=20 directly participate in the LISP deployment. LISP aims for an=20 incrementally deployable protocol. The scope of the LISP technology is recognized to range from programmable overlays,=20 at Layer 2 as well as at Layer 3, including NAT traversal, and=20 supporting mobility as a general feature, independently of whether=20 it is a mobile user or a migrating VM, hence being applicable in both Data Centers and public Internet environments. The LISP WG is chartered to continue work on the LISP base protocol=20 with the main objective to develop a standard solution based on the=20 completed Experimental RFCs and the experience gained from early=20 deployments. This work will include reviewing the existing set of Experimental RFCs=20= and doing the necessary enhancements to support a base set of=20 standards track RFCs. The group will review the current set of Working=20= Group documents to identify potential standards-track documents and=20 do the necessary enhancements to support standards-track. It is=20 recognized that some of the work will continue on the experimental = track,=20 though the group is encouraged to move the documents to standards=20 track in support of network use, whereas the work previously was=20 scoped to research studies. Beside this main focus, the LISP WG may work on the following items: =E2=80=A2 NAT-Traversal =E2=80=A2 Mobility =E2=80=A2 Data-Plane Encryption =E2=80=A2 Multicast: Support for overlay multicast by means of = replication=20 as well as interfacing with existing underlay multicast support. =E2=80=A2 YANG Data models for management of LISP. =E2=80=A2 Multi-protocol support: Specifying the required = extensions to support=20 multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 = Network Service=20 Headers). Rather than developing new encapsulations, the work = will=20 aim at using existing well-established encapsulations or = emerging=20 from other Working Groups such as NVO3 and SFC. =20 =E2=80=A2 Alternative Mapping System Design: When extending LISP = to support =20 new protocols,it may be also necessary to develop the related = mapping=20 function extensions to operate LISP map-assisted networks = (which=20 might include Hierarchical Pull, Publish/Subscribe, or Push = models=20 and related security extensions). From nobody Tue Oct 13 14:53:29 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AD61A0470 for ; Tue, 13 Oct 2015 14:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvqDHEJ_sWwj for ; Tue, 13 Oct 2015 14:53:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4A01A0451 for ; Tue, 13 Oct 2015 14:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4758; q=dns/txt; s=iport; t=1444773206; x=1445982806; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TQbRWqxykfSBXRskY8+ohQZwRNJQgLO86cl4CfuFtdw=; b=BFHA0qrhxw3KbSvRXmmlNUM15cjqiSMKuxi9bIsrunR9gnzfTDIS/Fxs jzrwjwHFVjvcFC+85j8hPOFKSb+5dIW/Mc/hUx0tz56Iu24d0dlHvwRbQ TMCgw/Xk2K5jBFfg8N/uzEbt3eDvq8ad08shmt0aBHTeAbVMIx288xuHe 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ACBQCGfB1W/5RdJa1UCoMmVG6+IIFaFwqCcoMJAoFKOhIBAQEBAQEBgQqEJwEBBAEBASAPAQU0AgoRCQISBgICBQMTCwICCQMCAQIBFSIOEwYCAQEXiBMNkVudNpNIAQEBAQYBAQEBARkEgSKFU4R+hDBkgmmBRQWOBIgSjRqBWIQ6gwGPBoNvKAc0ghYYgXQeM4ZxAQEB X-IronPort-AV: E=Sophos;i="5.17,680,1437436800"; d="scan'208";a="40436950" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP; 13 Oct 2015 21:53:25 +0000 Received: from [10.154.249.177] ([10.154.249.177]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9DLrPJg001988 for ; Tue, 13 Oct 2015 21:53:25 GMT To: lisp@ietf.org References: From: Fabio Maino Message-ID: <561D7D55.3090305@cisco.com> Date: Tue, 13 Oct 2015 14:53:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 21:53:28 -0000 Joel, Luigi, thanks for taking a stab at this one. I think it covers the relevant aspects that I would like to see the WG to focus on. As discussed in the use case thread, I would suggest that the draft should mention a very small set of use cases that we can use to drive the design decisions. I think that we can possibly cover all of the protocol aspects you describe if we take the following two use cases: 1) LISP-based programmable L2/L3 VPNs with extensions to support the following services: - encryption - programmatic northbound access to the mapping and to xTR configuration - SFC/NFV - VPN termination on mobile nodes 2) LISP-based programmable L2/L3 VPNs for DC applications I think these two will give a good scope to the WG work and, without resorting to more exotic use cases, reinforce the focus on the use of LISP as an overlay technology. Thanks, Fabio On 10/13/15 1:30 PM, Luigi Iannone wrote: > Folks, > > in the past weeks (and months) there was a fruitful discussion that took place on the mailing list (and also in Prague) concerning > the new charter to be adopted by our WG. Thanks for this effort. > > Beside this discussion we had proposals from WG members as well as discussion with our AD about what is practical and reasonable. > Hereafter you can find the result: a draft of the new proposed charter. > > This does not mean that discussion is over, rather that we reached a first consistent milestone for further discussion. > Discussion ideally culminating in our meeting in Japan. > > So please have look and send your thoughts and feedback to the mailing list. > > Joel and Luigi > > %—————————————————————————————————————————————————% > The LISP WG has completed the first set of Experimental RFCs > describing the Locator/ID Separation Protocol (LISP). LISP supports > a routing architecture which decouples the routing locators and > identifiers, thus allowing for efficient aggregation of the routing locator > space and providing persistent identifiers in the identifier space. > LISP requires no changes to end-systems or to routers that do not > directly participate in the LISP deployment. LISP aims for an > incrementally deployable protocol. The scope of the LISP > technology is recognized to range from programmable overlays, > at Layer 2 as well as at Layer 3, including NAT traversal, and > supporting mobility as a general feature, independently of whether > it is a mobile user or a migrating VM, hence being applicable in both > Data Centers and public Internet environments. > > The LISP WG is chartered to continue work on the LISP base protocol > with the main objective to develop a standard solution based on the > completed Experimental RFCs and the experience gained from early > deployments. > This work will include reviewing the existing set of Experimental RFCs > and doing the necessary enhancements to support a base set of > standards track RFCs. The group will review the current set of Working > Group documents to identify potential standards-track documents and > do the necessary enhancements to support standards-track. It is > recognized that some of the work will continue on the experimental track, > though the group is encouraged to move the documents to standards > track in support of network use, whereas the work previously was > scoped to research studies. > > Beside this main focus, the LISP WG may work on the following items: > > • NAT-Traversal > • Mobility > • Data-Plane Encryption > • Multicast: Support for overlay multicast by means of replication > as well as interfacing with existing underlay multicast support. > • YANG Data models for management of LISP. > • Multi-protocol support: Specifying the required extensions to support > multi-protocol encapsulation (e.g., L2 or NSH – Network Service > Headers). Rather than developing new encapsulations, the work will > aim at using existing well-established encapsulations or emerging > from other Working Groups such as NVO3 and SFC. > • Alternative Mapping System Design: When extending LISP to support > new protocols,it may be also necessary to develop the related mapping > function extensions to operate LISP map-assisted networks (which > might include Hierarchical Pull, Publish/Subscribe, or Push models > and related security extensions). > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Oct 14 01:13:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1B11B2C2A for ; Wed, 14 Oct 2015 01:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggo-uNvKdTp7 for ; Wed, 14 Oct 2015 01:13:46 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F761B2C42 for ; Wed, 14 Oct 2015 01:12:32 -0700 (PDT) Received: by oiar126 with SMTP id r126so23637922oia.0 for ; Wed, 14 Oct 2015 01:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=Aef4KXplPDM2Z/ywWPlpEHBdleSe8Or86f6umxK92Oo=; b=DjV64HIKu15nuKjVkX8FIG/KcWJ6uyUCIE8x9bXSFyAanOVC+D68mYzZuefaTjkJFI jYfgn91FaEVDJTBRURSchRvsZPJ1pjxxhhacNVgPFZkdSRFO48J5n97mMw4AqGDnCLRD 732rIMxcGW1mVci1Jgh1X871YGif24eWKKWIFYZcFrpVL/X0rWgTZLz7XFh+oJCZ43vY cYdO6mhmqlMd/t5HUHv2oGMQCDp2lCY452hS9VxaRdzx5fbNCWXrPefrZrzuLfMnEggJ GRS4rClzHLLIaQsgJv9db3MnB7HJNKNG9M48AnVdLgO3HcK1XZLCuPRz6OeWsMySh6fa uBqg== MIME-Version: 1.0 X-Received: by 10.202.169.7 with SMTP id s7mr970781oie.28.1444810351894; Wed, 14 Oct 2015 01:12:31 -0700 (PDT) Received: by 10.182.143.9 with HTTP; Wed, 14 Oct 2015 01:12:31 -0700 (PDT) In-Reply-To: <561D7D55.3090305@cisco.com> References: <561D7D55.3090305@cisco.com> Date: Wed, 14 Oct 2015 01:12:31 -0700 Message-ID: From: Albert Cabellos To: "lisp@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 08:13:48 -0000 Hi Luigi, Joel Thanks for the draft, I think it describes very relevant action items for L= ISP. I would also suggest exploring a flexible data-modeling language as a complement to LCAF for LISP control. LCAF is too rigid and it lacks of design guidelines to define new ones. A flexible language with a clear syntax would ease deployment of new use-cases both at the data and control plane. Maybe this could be done as experimental (not standard). Albert On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino wrote: > > Joel, Luigi, > thanks for taking a stab at this one. > > I think it covers the relevant aspects that I would like to see the WG to= focus on. > > As discussed in the use case thread, I would suggest that the draft shoul= d mention a very small set of use cases that we can use to drive the design= decisions. I think that we can possibly cover all of the protocol aspects = you describe if we take the following two use cases: > 1) LISP-based programmable L2/L3 VPNs with extensions to support the foll= owing services: > - encryption > - programmatic northbound access to the mapping and to xTR configurat= ion > - SFC/NFV > - VPN termination on mobile nodes > 2) LISP-based programmable L2/L3 VPNs for DC applications > > I think these two will give a good scope to the WG work and, without reso= rting to more exotic use cases, reinforce the focus on the use of LISP as a= n overlay technology. > > Thanks, > Fabio > > > > > On 10/13/15 1:30 PM, Luigi Iannone wrote: >> >> Folks, >> >> in the past weeks (and months) there was a fruitful discussion that took= place on the mailing list (and also in Prague) concerning >> the new charter to be adopted by our WG. Thanks for this effort. >> >> Beside this discussion we had proposals from WG members as well as discu= ssion with our AD about what is practical and reasonable. >> Hereafter you can find the result: a draft of the new proposed charter. >> >> This does not mean that discussion is over, rather that we reached a fir= st consistent milestone for further discussion. >> Discussion ideally culminating in our meeting in Japan. >> >> So please have look and send your thoughts and feedback to the mailing l= ist. >> >> Joel and Luigi >> >> %=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >> The LISP WG has completed the first set of Experimental RFCs >> describing the Locator/ID Separation Protocol (LISP). LISP supports >> a routing architecture which decouples the routing locators and >> identifiers, thus allowing for efficient aggregation of the routing loca= tor >> space and providing persistent identifiers in the identifier space. >> LISP requires no changes to end-systems or to routers that do not >> directly participate in the LISP deployment. LISP aims for an >> incrementally deployable protocol. The scope of the LISP >> technology is recognized to range from programmable overlays, >> at Layer 2 as well as at Layer 3, including NAT traversal, and >> supporting mobility as a general feature, independently of whether >> it is a mobile user or a migrating VM, hence being applicable in both >> Data Centers and public Internet environments. >> >> The LISP WG is chartered to continue work on the LISP base protocol >> with the main objective to develop a standard solution based on the >> completed Experimental RFCs and the experience gained from early >> deployments. >> This work will include reviewing the existing set of Experimental RFCs >> and doing the necessary enhancements to support a base set of >> standards track RFCs. The group will review the current set of Working >> Group documents to identify potential standards-track documents and >> do the necessary enhancements to support standards-track. It is >> recognized that some of the work will continue on the experimental track= , >> though the group is encouraged to move the documents to standards >> track in support of network use, whereas the work previously was >> scoped to research studies. >> >> Beside this main focus, the LISP WG may work on the following items: >> >> =E2=80=A2 NAT-Traversal >> =E2=80=A2 Mobility >> =E2=80=A2 Data-Plane Encryption >> =E2=80=A2 Multicast: Support for overlay multicast by means of rep= lication >> as well as interfacing with existing underlay multicast support= . >> =E2=80=A2 YANG Data models for management of LISP. >> =E2=80=A2 Multi-protocol support: Specifying the required extensio= ns to support >> multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 Netwo= rk Service >> Headers). Rather than developing new encapsulations, the work w= ill >> aim at using existing well-established encapsulations or emergi= ng >> from other Working Groups such as NVO3 and SFC. >> =E2=80=A2 Alternative Mapping System Design: When extending LISP t= o support >> new protocols,it may be also necessary to develop the related m= apping >> function extensions to operate LISP map-assisted networks (whi= ch >> might include Hierarchical Pull, Publish/Subscribe, or Push mod= els >> and related security extensions). >> >> _______________________________________________ >> 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 nobody Wed Oct 14 01:25:54 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB90A1B2C62 for ; Wed, 14 Oct 2015 01:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICR4HzWM3rYT for ; Wed, 14 Oct 2015 01:25:30 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1822E1B2C3E for ; Wed, 14 Oct 2015 01:23:17 -0700 (PDT) Received: by wijq8 with SMTP id q8so69433642wij.0 for ; Wed, 14 Oct 2015 01:23:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=B3xMdAe04gpiat9H23ac33uAvitKfbKR6vs1tMtXttI=; b=EU8A3eNE9xBbOthVwirV9pmKjkbOcPQtk9lXJZ1Te2Ji3JICfNuNZrUGrhI6paxueW akH3eAI03CHwAx6rJEXPtjHxIZydSxaa5qTBhBedU+5qlTAagGyaH3XBr+clYcWmD4O4 P87J5bVXUxJafuyUY3eSbpFmexk8qirAQ+CFuOpKalwqXH3iGS7+qKDbYjVuyM1HOQSf D+nBwB0/jR9UmjBbRIESCOHsHSNZ5lWx9xcA0PC87uhLD+mbgsmCFBENfaan0nfanWRe 2TYbcPaWXCTonn7KAM6ZBdOColDMZ2znvTy4wzphHU5zHeKnwALoCsWhz9LXM1wSe5Xn yOYA== X-Gm-Message-State: ALoCoQk3Xy3GIZCT2Gm8CFCXjFA5e+pfQZsTGJXB54qg/ZZpZnEz8ku//8nsV0y1USWX64hSzDUC X-Received: by 10.180.182.83 with SMTP id ec19mr26772059wic.35.1444810996119; Wed, 14 Oct 2015 01:23:16 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:6cb3:fafd:2fb3:eef? ([2001:660:330f:a4:6cb3:fafd:2fb3:eef]) by smtp.gmail.com with ESMTPSA id xt1sm8453716wjb.32.2015.10.14.01.23.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Oct 2015 01:23:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Luigi Iannone In-Reply-To: <561D7D55.3090305@cisco.com> Date: Wed, 14 Oct 2015 10:23:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C8EF5A4-B81B-45DB-ACF4-20F9A4A9E625@gigix.net> References: <561D7D55.3090305@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.3094) Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 08:25:37 -0000 Hi Fabio, thanks for the feedback. Are you saying that the scope of the proposed chart is too large? =46rom what I see in your mail I would say that the proposed charter = covers all of your work items (with the exception of the programmatic = northbound access to the mapping). Or I am misunderstanding your comment? ciao L. > On 13 Oct 2015, at 23:53, Fabio Maino wrote: >=20 > Joel, Luigi, > thanks for taking a stab at this one. >=20 > I think it covers the relevant aspects that I would like to see the WG = to focus on. >=20 > As discussed in the use case thread, I would suggest that the draft = should mention a very small set of use cases that we can use to drive = the design decisions. I think that we can possibly cover all of the = protocol aspects you describe if we take the following two use cases: > 1) LISP-based programmable L2/L3 VPNs with extensions to support the = following services: > - encryption > - programmatic northbound access to the mapping and to xTR = configuration > - SFC/NFV > - VPN termination on mobile nodes > 2) LISP-based programmable L2/L3 VPNs for DC applications >=20 > I think these two will give a good scope to the WG work and, without = resorting to more exotic use cases, reinforce the focus on the use of = LISP as an overlay technology. >=20 > Thanks, > Fabio >=20 >=20 >=20 > On 10/13/15 1:30 PM, Luigi Iannone wrote: >> Folks, >>=20 >> in the past weeks (and months) there was a fruitful discussion that = took place on the mailing list (and also in Prague) concerning >> the new charter to be adopted by our WG. Thanks for this effort. >>=20 >> Beside this discussion we had proposals from WG members as well as = discussion with our AD about what is practical and reasonable. >> Hereafter you can find the result: a draft of the new proposed = charter. >>=20 >> This does not mean that discussion is over, rather that we reached a = first consistent milestone for further discussion. >> Discussion ideally culminating in our meeting in Japan. >>=20 >> So please have look and send your thoughts and feedback to the = mailing list. >>=20 >> Joel and Luigi >>=20 >> = %=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >> The LISP WG has completed the first set of Experimental RFCs >> describing the Locator/ID Separation Protocol (LISP). LISP supports >> a routing architecture which decouples the routing locators and >> identifiers, thus allowing for efficient aggregation of the routing = locator >> space and providing persistent identifiers in the identifier space. >> LISP requires no changes to end-systems or to routers that do not >> directly participate in the LISP deployment. LISP aims for an >> incrementally deployable protocol. The scope of the LISP >> technology is recognized to range from programmable overlays, >> at Layer 2 as well as at Layer 3, including NAT traversal, and >> supporting mobility as a general feature, independently of whether >> it is a mobile user or a migrating VM, hence being applicable in both >> Data Centers and public Internet environments. >>=20 >> The LISP WG is chartered to continue work on the LISP base protocol >> with the main objective to develop a standard solution based on the >> completed Experimental RFCs and the experience gained from early >> deployments. >> This work will include reviewing the existing set of Experimental = RFCs >> and doing the necessary enhancements to support a base set of >> standards track RFCs. The group will review the current set of = Working >> Group documents to identify potential standards-track documents and >> do the necessary enhancements to support standards-track. It is >> recognized that some of the work will continue on the experimental = track, >> though the group is encouraged to move the documents to standards >> track in support of network use, whereas the work previously was >> scoped to research studies. >>=20 >> Beside this main focus, the LISP WG may work on the following items: >>=20 >> =E2=80=A2 NAT-Traversal >> =E2=80=A2 Mobility >> =E2=80=A2 Data-Plane Encryption >> =E2=80=A2 Multicast: Support for overlay multicast by means of = replication >> as well as interfacing with existing underlay multicast = support. >> =E2=80=A2 YANG Data models for management of LISP. >> =E2=80=A2 Multi-protocol support: Specifying the required = extensions to support >> multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 = Network Service >> Headers). Rather than developing new encapsulations, the work = will >> aim at using existing well-established encapsulations or = emerging >> from other Working Groups such as NVO3 and SFC. >> =E2=80=A2 Alternative Mapping System Design: When extending LISP = to support >> new protocols,it may be also necessary to develop the related = mapping >> function extensions to operate LISP map-assisted networks = (which >> might include Hierarchical Pull, Publish/Subscribe, or Push = models >> and related security extensions). >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Oct 14 01:31:55 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30101B2C5A for ; Wed, 14 Oct 2015 01:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBg6X89iVrsy for ; Wed, 14 Oct 2015 01:31:51 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377EB1B2C3D for ; Wed, 14 Oct 2015 01:31:51 -0700 (PDT) Received: by wicge5 with SMTP id ge5so90143757wic.0 for ; Wed, 14 Oct 2015 01:31:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=uhrWezhH2eK/shCQpvyFFSd6aiZfv7+dp3Zh+7cvv+w=; b=iAjTmkls2gES4yK+HJg497palqUFt0eA1V3rJ+tNxkXXCa5lgytO3WZRSXgl0ZKtl1 qLmsYr+h/OBVi+ZwdYmVn7bwWqG8uUgrfX4GUSM95aYBRS9UzEoQFJySRJ+IBnkorc/p wjq5pV4+Ad9B78V0UCnbPDcJFyvx5oCobzTiFifnUyKgWpgD3puMyvXBF+REHlTqJS7c BJDRP7VZ3YtxiUifxZpdcg9+EfOc91MUzIZ6XJoEruY47suRmp70pVj1yGat+eqG/IE5 1NK/VW0L5Pene+6NmFjMGSFNJguZgYjFI4k8KhXTOiU+268JLkG2FzqxiSKrwNupTYo2 l6dQ== X-Gm-Message-State: ALoCoQk87PkWjAoJCoegQz3PrUGV0KesGbqRXNA9tgadRt/9gUgF95uYrVgHv3CyRxmX5eQxCpoZ X-Received: by 10.180.107.164 with SMTP id hd4mr2967354wib.94.1444811509691; Wed, 14 Oct 2015 01:31:49 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:6cb3:fafd:2fb3:eef? ([2001:660:330f:a4:6cb3:fafd:2fb3:eef]) by smtp.gmail.com with ESMTPSA id r6sm28157972wia.0.2015.10.14.01.31.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Oct 2015 01:31:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Luigi Iannone In-Reply-To: Date: Wed, 14 Oct 2015 10:31:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <561D7D55.3090305@cisco.com> To: Albert Cabellos X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 08:31:53 -0000 HI Albert, thanks for the feedback. > On 14 Oct 2015, at 10:12, Albert Cabellos = wrote: >=20 > Hi Luigi, Joel >=20 > Thanks for the draft, I think it describes very relevant action items = for LISP. >=20 :-) > I would also suggest exploring a flexible data-modeling language as a > complement to LCAF for LISP control. LCAF is too rigid and it lacks of > design guidelines Having design guidelines does not forcedly mean having a programmatic = language approach. Right? In your opinion could well defined guidelines (not language) be added = to the current LCAF document?=20 > to define new ones. A flexible language with a clear > syntax would ease deployment of new use-cases both at the data and > control plane. How much relevant and with what priority is this for the WG? ( _NOTE_ = this question is for the whole WG not just for Albert=E2=80=A6) > Maybe this could be done as experimental (not > standard). _if_ the WG decides to take on this work it would very reasonable to go = for experimental. ciao L. >=20 > Albert >=20 >=20 > On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino wrote: >>=20 >> Joel, Luigi, >> thanks for taking a stab at this one. >>=20 >> I think it covers the relevant aspects that I would like to see the = WG to focus on. >>=20 >> As discussed in the use case thread, I would suggest that the draft = should mention a very small set of use cases that we can use to drive = the design decisions. I think that we can possibly cover all of the = protocol aspects you describe if we take the following two use cases: >> 1) LISP-based programmable L2/L3 VPNs with extensions to support the = following services: >> - encryption >> - programmatic northbound access to the mapping and to xTR = configuration >> - SFC/NFV >> - VPN termination on mobile nodes >> 2) LISP-based programmable L2/L3 VPNs for DC applications >>=20 >> I think these two will give a good scope to the WG work and, without = resorting to more exotic use cases, reinforce the focus on the use of = LISP as an overlay technology. >>=20 >> Thanks, >> Fabio >>=20 >>=20 >>=20 >>=20 >> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>=20 >>> Folks, >>>=20 >>> in the past weeks (and months) there was a fruitful discussion that = took place on the mailing list (and also in Prague) concerning >>> the new charter to be adopted by our WG. Thanks for this effort. >>>=20 >>> Beside this discussion we had proposals from WG members as well as = discussion with our AD about what is practical and reasonable. >>> Hereafter you can find the result: a draft of the new proposed = charter. >>>=20 >>> This does not mean that discussion is over, rather that we reached a = first consistent milestone for further discussion. >>> Discussion ideally culminating in our meeting in Japan. >>>=20 >>> So please have look and send your thoughts and feedback to the = mailing list. >>>=20 >>> Joel and Luigi >>>=20 >>> = %=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >>> The LISP WG has completed the first set of Experimental RFCs >>> describing the Locator/ID Separation Protocol (LISP). LISP supports >>> a routing architecture which decouples the routing locators and >>> identifiers, thus allowing for efficient aggregation of the routing = locator >>> space and providing persistent identifiers in the identifier space. >>> LISP requires no changes to end-systems or to routers that do not >>> directly participate in the LISP deployment. LISP aims for an >>> incrementally deployable protocol. The scope of the LISP >>> technology is recognized to range from programmable overlays, >>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>> supporting mobility as a general feature, independently of whether >>> it is a mobile user or a migrating VM, hence being applicable in = both >>> Data Centers and public Internet environments. >>>=20 >>> The LISP WG is chartered to continue work on the LISP base protocol >>> with the main objective to develop a standard solution based on the >>> completed Experimental RFCs and the experience gained from early >>> deployments. >>> This work will include reviewing the existing set of Experimental = RFCs >>> and doing the necessary enhancements to support a base set of >>> standards track RFCs. The group will review the current set of = Working >>> Group documents to identify potential standards-track documents and >>> do the necessary enhancements to support standards-track. It is >>> recognized that some of the work will continue on the experimental = track, >>> though the group is encouraged to move the documents to standards >>> track in support of network use, whereas the work previously was >>> scoped to research studies. >>>=20 >>> Beside this main focus, the LISP WG may work on the following items: >>>=20 >>> =E2=80=A2 NAT-Traversal >>> =E2=80=A2 Mobility >>> =E2=80=A2 Data-Plane Encryption >>> =E2=80=A2 Multicast: Support for overlay multicast by means of = replication >>> as well as interfacing with existing underlay multicast = support. >>> =E2=80=A2 YANG Data models for management of LISP. >>> =E2=80=A2 Multi-protocol support: Specifying the required = extensions to support >>> multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 = Network Service >>> Headers). Rather than developing new encapsulations, the = work will >>> aim at using existing well-established encapsulations or = emerging >>> from other Working Groups such as NVO3 and SFC. >>> =E2=80=A2 Alternative Mapping System Design: When extending = LISP to support >>> new protocols,it may be also necessary to develop the = related mapping >>> function extensions to operate LISP map-assisted networks = (which >>> might include Hierarchical Pull, Publish/Subscribe, or Push = models >>> and related security extensions). >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Oct 14 08:27:07 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CE91A916C for ; Wed, 14 Oct 2015 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwsIf85j2L32 for ; Wed, 14 Oct 2015 08:27:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0011A9007 for ; Wed, 14 Oct 2015 08:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6788; q=dns/txt; s=iport; t=1444836423; x=1446046023; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5dyLx3gT4eHhYj14NoSBjI+1OFX8/IAk39C9nn/tLdQ=; b=jiheoPey5KuOt69ZGDp7kh0mONT2m31VQNf+t3BuCEu3zPnbDg+aA9aS pRCArvMrCpH/GMMU1A0+1i7Xx+NDc4Ra8Q3EszNAPfeglB7sIo0K33evB NmnJH3HNk/nnRR80WweW+j4gcuTrC90J+IFRLzowlJEaWdJrsYefqqNwZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiAgDOcx5W/40NJK1UCoMmVG69JAENgVoXCoJyggp/AoFDOBQBAQEBAQEBgQqEJgEBAQMBAQEBIA8BBTQCCgEFCwkCDgQGAgIFAxMLAgIJAwIBAgEVIg4GDQYCAQEXiAsIDZIpnTaTQQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBIoVUhH6EMAsBAVAHgmmBRQWOA4gSjRuBWIQ6gwGPCINvHwEBQoIWGIF0HjOFL4FAAQEB X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="scan'208";a="41381742" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2015 15:27:02 +0000 Received: from [10.24.42.192] ([10.24.42.192]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9EFR1Kn003946; Wed, 14 Oct 2015 15:27:01 GMT To: Luigi Iannone References: <561D7D55.3090305@cisco.com> <3C8EF5A4-B81B-45DB-ACF4-20F9A4A9E625@gigix.net> From: Fabio Maino Message-ID: <561E7448.7080209@cisco.com> Date: Wed, 14 Oct 2015 08:27:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <3C8EF5A4-B81B-45DB-ACF4-20F9A4A9E625@gigix.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 15:27:06 -0000 On 10/14/15 1:23 AM, Luigi Iannone wrote: > Hi Fabio, > > thanks for the feedback. > Are you saying that the scope of the proposed chart is too large? No, I think the scope is very appropriate. I was just suggesting that we use those two use cases to drive the design decisions. There are clearly many more use cases that a LISP overlay can be used for, but in my opinion those two are well understood and will help focusing the group on the protocol work that you have identified. I selected those two, and articulated them in that way, exactly because they can cover the whole scope of the outlined work. If we include those two use cases in the charter, probably it should also mention that those are not the only ones, but are used to drive the design. > > From what I see in your mail I would say that the proposed charter covers all of your work items (with the exception of the programmatic northbound access to the mapping). Yes. I think the SDN angle is very important for an overlay, and may drive very relevant components of the architecture. The text you posted does refers to YANG modeling, that is one component of programmability, but I would like to see this requirement more explicit, particularly for the mapping system. I believe LISP, with the clean separation of the forwarding function provided by the mapping system, can play a key role in controller-based SDN applications. Again, it's not the only way to use LISP, but I think it's an opportunity that the WG should pick up. Thanks, Fabio > Or I am misunderstanding your comment? > > ciao > > L. > > >> On 13 Oct 2015, at 23:53, Fabio Maino wrote: >> >> Joel, Luigi, >> thanks for taking a stab at this one. >> >> I think it covers the relevant aspects that I would like to see the WG to focus on. >> >> As discussed in the use case thread, I would suggest that the draft should mention a very small set of use cases that we can use to drive the design decisions. I think that we can possibly cover all of the protocol aspects you describe if we take the following two use cases: >> 1) LISP-based programmable L2/L3 VPNs with extensions to support the following services: >> - encryption >> - programmatic northbound access to the mapping and to xTR configuration >> - SFC/NFV >> - VPN termination on mobile nodes >> 2) LISP-based programmable L2/L3 VPNs for DC applications >> >> I think these two will give a good scope to the WG work and, without resorting to more exotic use cases, reinforce the focus on the use of LISP as an overlay technology. >> >> Thanks, >> Fabio >> >> >> >> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>> Folks, >>> >>> in the past weeks (and months) there was a fruitful discussion that took place on the mailing list (and also in Prague) concerning >>> the new charter to be adopted by our WG. Thanks for this effort. >>> >>> Beside this discussion we had proposals from WG members as well as discussion with our AD about what is practical and reasonable. >>> Hereafter you can find the result: a draft of the new proposed charter. >>> >>> This does not mean that discussion is over, rather that we reached a first consistent milestone for further discussion. >>> Discussion ideally culminating in our meeting in Japan. >>> >>> So please have look and send your thoughts and feedback to the mailing list. >>> >>> Joel and Luigi >>> >>> %—————————————————————————————————————————————————% >>> The LISP WG has completed the first set of Experimental RFCs >>> describing the Locator/ID Separation Protocol (LISP). LISP supports >>> a routing architecture which decouples the routing locators and >>> identifiers, thus allowing for efficient aggregation of the routing locator >>> space and providing persistent identifiers in the identifier space. >>> LISP requires no changes to end-systems or to routers that do not >>> directly participate in the LISP deployment. LISP aims for an >>> incrementally deployable protocol. The scope of the LISP >>> technology is recognized to range from programmable overlays, >>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>> supporting mobility as a general feature, independently of whether >>> it is a mobile user or a migrating VM, hence being applicable in both >>> Data Centers and public Internet environments. >>> >>> The LISP WG is chartered to continue work on the LISP base protocol >>> with the main objective to develop a standard solution based on the >>> completed Experimental RFCs and the experience gained from early >>> deployments. >>> This work will include reviewing the existing set of Experimental RFCs >>> and doing the necessary enhancements to support a base set of >>> standards track RFCs. The group will review the current set of Working >>> Group documents to identify potential standards-track documents and >>> do the necessary enhancements to support standards-track. It is >>> recognized that some of the work will continue on the experimental track, >>> though the group is encouraged to move the documents to standards >>> track in support of network use, whereas the work previously was >>> scoped to research studies. >>> >>> Beside this main focus, the LISP WG may work on the following items: >>> >>> • NAT-Traversal >>> • Mobility >>> • Data-Plane Encryption >>> • Multicast: Support for overlay multicast by means of replication >>> as well as interfacing with existing underlay multicast support. >>> • YANG Data models for management of LISP. >>> • Multi-protocol support: Specifying the required extensions to support >>> multi-protocol encapsulation (e.g., L2 or NSH – Network Service >>> Headers). Rather than developing new encapsulations, the work will >>> aim at using existing well-established encapsulations or emerging >>> from other Working Groups such as NVO3 and SFC. >>> • Alternative Mapping System Design: When extending LISP to support >>> new protocols,it may be also necessary to develop the related mapping >>> function extensions to operate LISP map-assisted networks (which >>> might include Hierarchical Pull, Publish/Subscribe, or Push models >>> and related security extensions). >>> >>> _______________________________________________ >>> 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 nobody Wed Oct 14 10:42:21 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BD01AD05B for ; Wed, 14 Oct 2015 10:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTJ3btffTM_h for ; Wed, 14 Oct 2015 10:42:17 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id ABD021AD055 for ; Wed, 14 Oct 2015 10:42:16 -0700 (PDT) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id t9EFqVhm005279 for ; Wed, 14 Oct 2015 17:52:31 +0200 Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id 123E51D3 for ; Wed, 14 Oct 2015 19:42:15 +0200 (CEST) Received: by lffy185 with SMTP id y185so16237664lff.2 for ; Wed, 14 Oct 2015 10:42:14 -0700 (PDT) X-Received: by 10.25.22.149 with SMTP id 21mr460791lfw.8.1444844534401; Wed, 14 Oct 2015 10:42:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.59.225 with HTTP; Wed, 14 Oct 2015 10:41:55 -0700 (PDT) In-Reply-To: References: From: Alberto Rodriguez-Natal Date: Wed, 14 Oct 2015 19:41:55 +0200 Message-ID: To: Luigi Iannone , Joel Halpern Content-Type: multipart/alternative; boundary=001a1140809a3a94880522141543 Archived-At: Cc: "lisp@ietf.org list" Subject: Re: [lisp] LISP subscription X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 17:42:20 -0000 --001a1140809a3a94880522141543 Content-Type: text/plain; charset=UTF-8 Hi, Would it be possible to request some time to present these slides at the WG session? A slot of 15/20 min would be great. Also, if time allows, we can use 5 extra min before the slides to present draft-rodrigueznatal-lisp-ms-smr-00. Thanks, Alberto On Wed, Sep 30, 2015 at 11:43 PM, Alberto Rodriguez-Natal < arnatal@ac.upc.edu> wrote: > Hi all, > > As you may know, some of us have been talking for a while about different > approaches to support subscription in LISP. On the attached slides you can > find a summary of our thoughts on the topic. > > We hope they can help to trigger a wider discussion within the WG. If time > allows, we can present them at Yokohama. > > Thanks, > Alberto > --001a1140809a3a94880522141543 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Would it be possible = to request some time to present these slides at the WG session? A slot of 1= 5/20 min would be great.

Also, if time allows, we can use 5 ex= tra min before the slides to present draft-rodrigueznatal-lisp-ms-smr-00.
Thanks,
Alberto
On Wed, Sep 30, 2015 at 11:43 PM, Alberto Rodr= iguez-Natal <arnatal@ac.upc.edu> wrote:
Hi all,

As= you may know, some of us have been talking for a while about different app= roaches to support subscription in LISP. On the attached slides you can fin= d a summary of our thoughts on the topic.

We hope they can hel= p to trigger a wider discussion within the WG. If time allows, we can prese= nt them at Yokohama.

Thanks,
Alberto

--001a1140809a3a94880522141543-- From nobody Wed Oct 14 11:29:11 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF6A1B29A7 for ; Wed, 14 Oct 2015 11:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_92=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zztSrT8ZRnJL for ; Wed, 14 Oct 2015 11:29:06 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170C21AD49D for ; Wed, 14 Oct 2015 11:29:06 -0700 (PDT) Received: by pabur7 with SMTP id ur7so12264080pab.3 for ; Wed, 14 Oct 2015 11:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dnlqZAhH1r98enWqLHTqxvSBSACoSAUNHfu3CKC/VsI=; b=0JdwV678/y/X/ItZtBNka7fE5An8H9FRkZlureM7Afu4ocP/YCddHM+UkCR/ms0oJn LmjNaU5hVvUf0yo/9v6O4t8U+igYzEojCaOfXyeJkzMVzoDwRjuNvPRVJB5Wh4HqFslO m9oCC2DO7hyp0T6Mh1weBKg7uxfJVu8Lpa9huXpKEKeOEltFf9wyAJITXR2oYKXo1SSj cziioxZzM0tAUbUJeFhH0N+JzHprvFf8olXHgYYzxrBNsEtIBvHmEteJb1b1LigPLRu9 0ujJRZvfnBHSXTDIIwVEkq5jr5nkbW8g4m31mwCwiJB4j5NzTxv9ivVv+QFD7VzzKpQD KT7Q== X-Received: by 10.67.1.73 with SMTP id be9mr5028824pad.35.1444847345733; Wed, 14 Oct 2015 11:29:05 -0700 (PDT) Received: from [100.78.129.128] (204.sub-70-214-1.myvzw.com. [70.214.1.204]) by smtp.gmail.com with ESMTPSA id st5sm10984267pab.42.2015.10.14.11.29.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Oct 2015 11:29:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (13A452) In-Reply-To: <561E7448.7080209@cisco.com> Date: Wed, 14 Oct 2015 11:28:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <561D7D55.3090305@cisco.com> <3C8EF5A4-B81B-45DB-ACF4-20F9A4A9E625@gigix.net> <561E7448.7080209@cisco.com> To: Fabio Maino Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 18:29:08 -0000 We could say that as we completed a set of experimental lisp rfcs the import= ance of connectionless logical services networks overlaying and or anchoring= topological IP networks grew significantly.=20 To accommodate we continue to evolve the unique lisp map-assisted overlay ar= chitecture characteristics along the following lines: - traversal, schemas, chaining... etc We evolve these lisp aspects and examine their applicability by matching and= testing them vis-a-vis key example use-cases: - VPN virtual logical private services networks - NFV virtualization of functions from junctions=20 - DMM distributed (floating-anchors) mobility =20 --szb > On Oct 14, 2015, at 8:27 AM, Fabio Maino wrote: >=20 >> On 10/14/15 1:23 AM, Luigi Iannone wrote: >> Hi Fabio, >>=20 >> thanks for the feedback. >> Are you saying that the scope of the proposed chart is too large? >=20 > No, I think the scope is very appropriate. I was just suggesting that we u= se those two use cases to drive the design decisions. >=20 > There are clearly many more use cases that a LISP overlay can be used for,= but in my opinion those two are well understood and will help focusing the g= roup on the protocol work that you have identified. I selected those two, an= d articulated them in that way, exactly because they can cover the whole sco= pe of the outlined work. >=20 > If we include those two use cases in the charter, probably it should also m= ention that those are not the only ones, but are used to drive the design. >=20 >>=20 >> =46rom what I see in your mail I would say that the proposed charter cove= rs all of your work items (with the exception of the programmatic northbound= access to the mapping). >=20 > Yes. I think the SDN angle is very important for an overlay, and may drive= very relevant components of the architecture. The text you posted does refe= rs to YANG modeling, that is one component of programmability, but I would l= ike to see this requirement more explicit, particularly for the mapping syst= em. >=20 > I believe LISP, with the clean separation of the forwarding function provi= ded by the mapping system, can play a key role in controller-based SDN appli= cations. Again, it's not the only way to use LISP, but I think it's an oppor= tunity that the WG should pick up. >=20 >=20 >=20 > Thanks, > Fabio >=20 >=20 >=20 >> Or I am misunderstanding your comment? >>=20 >> ciao >>=20 >> L. >>=20 >>=20 >>> On 13 Oct 2015, at 23:53, Fabio Maino wrote: >>>=20 >>> Joel, Luigi, >>> thanks for taking a stab at this one. >>>=20 >>> I think it covers the relevant aspects that I would like to see the WG t= o focus on. >>>=20 >>> As discussed in the use case thread, I would suggest that the draft shou= ld mention a very small set of use cases that we can use to drive the design= decisions. I think that we can possibly cover all of the protocol aspects y= ou describe if we take the following two use cases: >>> 1) LISP-based programmable L2/L3 VPNs with extensions to support the fol= lowing services: >>> - encryption >>> - programmatic northbound access to the mapping and to xTR configurat= ion >>> - SFC/NFV >>> - VPN termination on mobile nodes >>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>>=20 >>> I think these two will give a good scope to the WG work and, without res= orting to more exotic use cases, reinforce the focus on the use of LISP as a= n overlay technology. >>>=20 >>> Thanks, >>> Fabio >>>=20 >>>=20 >>>=20 >>>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>> Folks, >>>>=20 >>>> in the past weeks (and months) there was a fruitful discussion that too= k place on the mailing list (and also in Prague) concerning >>>> the new charter to be adopted by our WG. Thanks for this effort. >>>>=20 >>>> Beside this discussion we had proposals from WG members as well as disc= ussion with our AD about what is practical and reasonable. >>>> Hereafter you can find the result: a draft of the new proposed charter.= >>>>=20 >>>> This does not mean that discussion is over, rather that we reached a fi= rst consistent milestone for further discussion. >>>> Discussion ideally culminating in our meeting in Japan. >>>>=20 >>>> So please have look and send your thoughts and feedback to the mailing l= ist. >>>>=20 >>>> Joel and Luigi >>>>=20 >>>> %=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >>>> The LISP WG has completed the first set of Experimental RFCs >>>> describing the Locator/ID Separation Protocol (LISP). LISP supports >>>> a routing architecture which decouples the routing locators and >>>> identifiers, thus allowing for efficient aggregation of the routing loc= ator >>>> space and providing persistent identifiers in the identifier space. >>>> LISP requires no changes to end-systems or to routers that do not >>>> directly participate in the LISP deployment. LISP aims for an >>>> incrementally deployable protocol. The scope of the LISP >>>> technology is recognized to range from programmable overlays, >>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>> supporting mobility as a general feature, independently of whether >>>> it is a mobile user or a migrating VM, hence being applicable in both >>>> Data Centers and public Internet environments. >>>>=20 >>>> The LISP WG is chartered to continue work on the LISP base protocol >>>> with the main objective to develop a standard solution based on the >>>> completed Experimental RFCs and the experience gained from early >>>> deployments. >>>> This work will include reviewing the existing set of Experimental RFCs >>>> and doing the necessary enhancements to support a base set of >>>> standards track RFCs. The group will review the current set of Working >>>> Group documents to identify potential standards-track documents and >>>> do the necessary enhancements to support standards-track. It is >>>> recognized that some of the work will continue on the experimental trac= k, >>>> though the group is encouraged to move the documents to standards >>>> track in support of network use, whereas the work previously was >>>> scoped to research studies. >>>>=20 >>>> Beside this main focus, the LISP WG may work on the following items: >>>>=20 >>>> =E2=80=A2 NAT-Traversal >>>> =E2=80=A2 Mobility >>>> =E2=80=A2 Data-Plane Encryption >>>> =E2=80=A2 Multicast: Support for overlay multicast by means of repli= cation >>>> as well as interfacing with existing underlay multicast support= . >>>> =E2=80=A2 YANG Data models for management of LISP. >>>> =E2=80=A2 Multi-protocol support: Specifying the required extensions= to support >>>> multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 Netwo= rk Service >>>> Headers). Rather than developing new encapsulations, the work w= ill >>>> aim at using existing well-established encapsulations or emergi= ng >>>> from other Working Groups such as NVO3 and SFC. >>>> =E2=80=A2 Alternative Mapping System Design: When extending LISP to s= upport >>>> new protocols,it may be also necessary to develop the related m= apping >>>> function extensions to operate LISP map-assisted networks (whi= ch >>>> might include Hierarchical Pull, Publish/Subscribe, or Push mod= els >>>> and related security extensions). >>>>=20 >>>> _______________________________________________ >>>> 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 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Oct 14 15:10:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B91E1A904F for ; Wed, 14 Oct 2015 15:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbzcPA_sordp for ; Wed, 14 Oct 2015 15:10:53 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B1E1A8798 for ; Wed, 14 Oct 2015 15:10:53 -0700 (PDT) Received: by obbzf10 with SMTP id zf10so51036812obb.2 for ; Wed, 14 Oct 2015 15:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KHTBGY51AwhUqkiSpQZ4pSKUqoAW6FicnI1XrTlfjZ4=; b=jd3/aUX3RKU8VeRfrtqdZ3eMomkGPFdBFDtZ5N3XS23mgqfZwfPlIIClglXjaNXpCb M54F85IGnOyrfT4HQaaH2ceY8WSe3T/QolXMiSXJpeY9W2JwNI67jlCK90LVg4ZGPC6+ qrvNVCCogggCbzCpgOsEvCP2dj4TEuF4/vxCBah04sZ22IfmO1mPRkPYy7/+wMxt8EOw wZZwmgzVXFZIAFojhvMKWEJ4uaXt8H9uG390sZKkfX9/jhtrfWz/Qexd7wjt3/TZ+stX K/eolJeq7J4Juh5N7LzOEkFz2tSd9jHbzgN5+DTPUmO+g5SMM+BzaDmfy/sBLa+v2RB4 YLQw== MIME-Version: 1.0 X-Received: by 10.182.96.168 with SMTP id dt8mr3506658obb.36.1444860652484; Wed, 14 Oct 2015 15:10:52 -0700 (PDT) Received: by 10.182.143.9 with HTTP; Wed, 14 Oct 2015 15:10:52 -0700 (PDT) In-Reply-To: References: <561D7D55.3090305@cisco.com> Date: Wed, 14 Oct 2015 15:10:52 -0700 Message-ID: From: Albert Cabellos To: Luigi Iannone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 22:10:55 -0000 Hi Luigi Please see my comments inline: On Wed, Oct 14, 2015 at 1:31 AM, Luigi Iannone wrote: [snip] > Having design guidelines does not forcedly mean having a programmatic lan= guage approach. Right? > > In your opinion could well defined guidelines (not language) be added to= the current LCAF document? I am unsure if we can do this without ending up reproducing some sort of language, we=C2=B4ll start by defining scalar data-types, then complex data-types (combinations of scalars), then data-structures, then encoding mechanisms for each scalar and each data-structure and so on. This could be as simple as defining an encoding mechanisms for YANG (XMLBIN with some sort of compression). I am not stating that we should go this precise way, what I am stating is that LCAF is rigid and, if a new use-case is not defined as an LCAF, it can=C2=B4t be deployed in a standard way. A language could solve this issue and make the LISP control plane truly flexible. > >> to define new ones. A flexible language with a clear >> syntax would ease deployment of new use-cases both at the data and >> control plane. > > How much relevant and with what priority is this for the WG? ( _NOTE_ thi= s question is for the whole WG not just for Albert=E2=80=A6) > me too :) Albert >> Maybe this could be done as experimental (not >> standard). > > _if_ the WG decides to take on this work it would very reasonable to go f= or experimental. > > ciao > > L. > > >> >> Albert >> >> >> On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino wrote: >>> >>> Joel, Luigi, >>> thanks for taking a stab at this one. >>> >>> I think it covers the relevant aspects that I would like to see the WG = to focus on. >>> >>> As discussed in the use case thread, I would suggest that the draft sho= uld mention a very small set of use cases that we can use to drive the desi= gn decisions. I think that we can possibly cover all of the protocol aspect= s you describe if we take the following two use cases: >>> 1) LISP-based programmable L2/L3 VPNs with extensions to support the fo= llowing services: >>> - encryption >>> - programmatic northbound access to the mapping and to xTR configura= tion >>> - SFC/NFV >>> - VPN termination on mobile nodes >>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>> >>> I think these two will give a good scope to the WG work and, without re= sorting to more exotic use cases, reinforce the focus on the use of LISP as= an overlay technology. >>> >>> Thanks, >>> Fabio >>> >>> >>> >>> >>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>> >>>> Folks, >>>> >>>> in the past weeks (and months) there was a fruitful discussion that to= ok place on the mailing list (and also in Prague) concerning >>>> the new charter to be adopted by our WG. Thanks for this effort. >>>> >>>> Beside this discussion we had proposals from WG members as well as dis= cussion with our AD about what is practical and reasonable. >>>> Hereafter you can find the result: a draft of the new proposed charter= . >>>> >>>> This does not mean that discussion is over, rather that we reached a f= irst consistent milestone for further discussion. >>>> Discussion ideally culminating in our meeting in Japan. >>>> >>>> So please have look and send your thoughts and feedback to the mailing= list. >>>> >>>> Joel and Luigi >>>> >>>> %=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >>>> The LISP WG has completed the first set of Experimental RFCs >>>> describing the Locator/ID Separation Protocol (LISP). LISP supports >>>> a routing architecture which decouples the routing locators and >>>> identifiers, thus allowing for efficient aggregation of the routing lo= cator >>>> space and providing persistent identifiers in the identifier space. >>>> LISP requires no changes to end-systems or to routers that do not >>>> directly participate in the LISP deployment. LISP aims for an >>>> incrementally deployable protocol. The scope of the LISP >>>> technology is recognized to range from programmable overlays, >>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>> supporting mobility as a general feature, independently of whether >>>> it is a mobile user or a migrating VM, hence being applicable in both >>>> Data Centers and public Internet environments. >>>> >>>> The LISP WG is chartered to continue work on the LISP base protocol >>>> with the main objective to develop a standard solution based on the >>>> completed Experimental RFCs and the experience gained from early >>>> deployments. >>>> This work will include reviewing the existing set of Experimental RFCs >>>> and doing the necessary enhancements to support a base set of >>>> standards track RFCs. The group will review the current set of Working >>>> Group documents to identify potential standards-track documents and >>>> do the necessary enhancements to support standards-track. It is >>>> recognized that some of the work will continue on the experimental tra= ck, >>>> though the group is encouraged to move the documents to standards >>>> track in support of network use, whereas the work previously was >>>> scoped to research studies. >>>> >>>> Beside this main focus, the LISP WG may work on the following items: >>>> >>>> =E2=80=A2 NAT-Traversal >>>> =E2=80=A2 Mobility >>>> =E2=80=A2 Data-Plane Encryption >>>> =E2=80=A2 Multicast: Support for overlay multicast by means of r= eplication >>>> as well as interfacing with existing underlay multicast suppor= t. >>>> =E2=80=A2 YANG Data models for management of LISP. >>>> =E2=80=A2 Multi-protocol support: Specifying the required extens= ions to support >>>> multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 Netw= ork Service >>>> Headers). Rather than developing new encapsulations, the work = will >>>> aim at using existing well-established encapsulations or emerg= ing >>>> from other Working Groups such as NVO3 and SFC. >>>> =E2=80=A2 Alternative Mapping System Design: When extending LISP= to support >>>> new protocols,it may be also necessary to develop the related = mapping >>>> function extensions to operate LISP map-assisted networks (wh= ich >>>> might include Hierarchical Pull, Publish/Subscribe, or Push mo= dels >>>> and related security extensions). >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From nobody Wed Oct 14 16:04:20 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07831A01F9 for ; Wed, 14 Oct 2015 16:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQWSQ8PakF4U for ; Wed, 14 Oct 2015 16:04:16 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955BC1A01D8 for ; Wed, 14 Oct 2015 16:04:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 811F6240771; Wed, 14 Oct 2015 16:04:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D63FA24073E; Wed, 14 Oct 2015 16:04:15 -0700 (PDT) To: Albert Cabellos , Luigi Iannone References: <561D7D55.3090305@cisco.com> From: "Joel M. Halpern" Message-ID: <561EDF6E.60805@joelhalpern.com> Date: Wed, 14 Oct 2015 19:04:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 23:04:18 -0000 I am really unclear as to what the problem being addressed by creating a programmatic language for LCAFs is. Heck, I am confused by what the JSON LCAFs are solving too. Beyond that, I do not even know what it means to support such LCAF through a mapping system. It sounds a lot like research, rather than engineering. But I that may be just because I have completely missed the point. Yours, Joel On 10/14/15 6:10 PM, Albert Cabellos wrote: > Hi Luigi > > Please see my comments inline: > > On Wed, Oct 14, 2015 at 1:31 AM, Luigi Iannone wrote: > > [snip] > >> Having design guidelines does not forcedly mean having a programmatic language approach. Right? >> >> In your opinion could well defined guidelines (not language) be added to the current LCAF document? > > I am unsure if we can do this without ending up reproducing some sort > of language, we´ll start by defining scalar data-types, then complex > data-types (combinations of scalars), then data-structures, then > encoding mechanisms for each scalar and each data-structure and so on. > > This could be as simple as defining an encoding mechanisms for YANG > (XMLBIN with some sort of compression). I am not stating that we > should go this precise way, what I am stating is that LCAF is rigid > and, if a new use-case is not defined as an LCAF, it can´t be deployed > in a standard way. A language could solve this issue and make the LISP > control plane truly flexible. > >> >>> to define new ones. A flexible language with a clear >>> syntax would ease deployment of new use-cases both at the data and >>> control plane. >> >> How much relevant and with what priority is this for the WG? ( _NOTE_ this question is for the whole WG not just for Albert…) >> > > me too :) > > Albert > >>> Maybe this could be done as experimental (not >>> standard). >> >> _if_ the WG decides to take on this work it would very reasonable to go for experimental. >> >> ciao >> >> L. >> >> >>> >>> Albert >>> >>> >>> On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino wrote: >>>> >>>> Joel, Luigi, >>>> thanks for taking a stab at this one. >>>> >>>> I think it covers the relevant aspects that I would like to see the WG to focus on. >>>> >>>> As discussed in the use case thread, I would suggest that the draft should mention a very small set of use cases that we can use to drive the design decisions. I think that we can possibly cover all of the protocol aspects you describe if we take the following two use cases: >>>> 1) LISP-based programmable L2/L3 VPNs with extensions to support the following services: >>>> - encryption >>>> - programmatic northbound access to the mapping and to xTR configuration >>>> - SFC/NFV >>>> - VPN termination on mobile nodes >>>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>>> >>>> I think these two will give a good scope to the WG work and, without resorting to more exotic use cases, reinforce the focus on the use of LISP as an overlay technology. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> >>>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>>> >>>>> Folks, >>>>> >>>>> in the past weeks (and months) there was a fruitful discussion that took place on the mailing list (and also in Prague) concerning >>>>> the new charter to be adopted by our WG. Thanks for this effort. >>>>> >>>>> Beside this discussion we had proposals from WG members as well as discussion with our AD about what is practical and reasonable. >>>>> Hereafter you can find the result: a draft of the new proposed charter. >>>>> >>>>> This does not mean that discussion is over, rather that we reached a first consistent milestone for further discussion. >>>>> Discussion ideally culminating in our meeting in Japan. >>>>> >>>>> So please have look and send your thoughts and feedback to the mailing list. >>>>> >>>>> Joel and Luigi >>>>> >>>>> %—————————————————————————————————————————————————% >>>>> The LISP WG has completed the first set of Experimental RFCs >>>>> describing the Locator/ID Separation Protocol (LISP). LISP supports >>>>> a routing architecture which decouples the routing locators and >>>>> identifiers, thus allowing for efficient aggregation of the routing locator >>>>> space and providing persistent identifiers in the identifier space. >>>>> LISP requires no changes to end-systems or to routers that do not >>>>> directly participate in the LISP deployment. LISP aims for an >>>>> incrementally deployable protocol. The scope of the LISP >>>>> technology is recognized to range from programmable overlays, >>>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>>> supporting mobility as a general feature, independently of whether >>>>> it is a mobile user or a migrating VM, hence being applicable in both >>>>> Data Centers and public Internet environments. >>>>> >>>>> The LISP WG is chartered to continue work on the LISP base protocol >>>>> with the main objective to develop a standard solution based on the >>>>> completed Experimental RFCs and the experience gained from early >>>>> deployments. >>>>> This work will include reviewing the existing set of Experimental RFCs >>>>> and doing the necessary enhancements to support a base set of >>>>> standards track RFCs. The group will review the current set of Working >>>>> Group documents to identify potential standards-track documents and >>>>> do the necessary enhancements to support standards-track. It is >>>>> recognized that some of the work will continue on the experimental track, >>>>> though the group is encouraged to move the documents to standards >>>>> track in support of network use, whereas the work previously was >>>>> scoped to research studies. >>>>> >>>>> Beside this main focus, the LISP WG may work on the following items: >>>>> >>>>> • NAT-Traversal >>>>> • Mobility >>>>> • Data-Plane Encryption >>>>> • Multicast: Support for overlay multicast by means of replication >>>>> as well as interfacing with existing underlay multicast support. >>>>> • YANG Data models for management of LISP. >>>>> • Multi-protocol support: Specifying the required extensions to support >>>>> multi-protocol encapsulation (e.g., L2 or NSH – Network Service >>>>> Headers). Rather than developing new encapsulations, the work will >>>>> aim at using existing well-established encapsulations or emerging >>>>> from other Working Groups such as NVO3 and SFC. >>>>> • Alternative Mapping System Design: When extending LISP to support >>>>> new protocols,it may be also necessary to develop the related mapping >>>>> function extensions to operate LISP map-assisted networks (which >>>>> might include Hierarchical Pull, Publish/Subscribe, or Push models >>>>> and related security extensions). >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Thu Oct 15 02:41:47 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AF51A92B5 for ; Thu, 15 Oct 2015 02:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPKYKhy7RlNw for ; Thu, 15 Oct 2015 02:41:43 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C751A92EF for ; Thu, 15 Oct 2015 02:41:41 -0700 (PDT) Received: by wicll6 with SMTP id ll6so10293895wic.1 for ; Thu, 15 Oct 2015 02:41:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=yisfgO2Air8+A805WFzrvT05GGT22/J9e9D94KC22Uo=; b=BtGwbOZefLtpgD5S8CkCy09+VgREwP97FzDoXyjs3OWobY/lx0U2H57jS/W/evGCcA uhXP0pNO7/XMwYlp6tbzE/BirBUED+7cikSOn3VQgChtWC7/T7ujvampy4j+2jkMOg3+ sXsfKenR0BWmfOiK1S6TsREkvDglKi98zWGTDG6wq8bblJH4BEoeWmb75wtQf218EoGW jzZKIU0ucXnBtxMrXpXl+vTlcLm/Mxg/dfYFJj6kL2z6giZhy57lvsSDGm4bn9kaLUTk 2I1/4+t34eji7ZkTom7HRcOD7HTT7nktZXmB/go1I5QYD9ddgNDIHq38a24AiKiV6dR8 39ag== X-Gm-Message-State: ALoCoQmf3mauCxD5z8bFl32z0+9FYQHfd2G4HiHzqPz4gvNYh+KPFB6e5Uv8wCLJ2W6sGvzLid/p X-Received: by 10.180.87.225 with SMTP id bb1mr34650232wib.0.1444902100473; Thu, 15 Oct 2015 02:41:40 -0700 (PDT) Received: from dhcp164-197.enst.fr (dhcp164-197.enst.fr. [137.194.165.197]) by smtp.gmail.com with ESMTPSA id uj4sm15355268wjc.34.2015.10.15.02.41.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 02:41:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Luigi Iannone In-Reply-To: <561E7448.7080209@cisco.com> Date: Thu, 15 Oct 2015 11:41:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <561D7D55.3090305@cisco.com> <3C8EF5A4-B81B-45DB-ACF4-20F9A4A9E625@gigix.net> <561E7448.7080209@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.3094) Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 09:41:45 -0000 Hi Fabio, > On 14 Oct 2015, at 17:27, Fabio Maino wrote: >=20 > On 10/14/15 1:23 AM, Luigi Iannone wrote: >> Hi Fabio, >>=20 >> thanks for the feedback. >> Are you saying that the scope of the proposed chart is too large? >=20 > No, I think the scope is very appropriate. I was just suggesting that = we use those two use cases to drive the design decisions. >=20 > There are clearly many more use cases that a LISP overlay can be used = for, but in my opinion those two are well understood and will help = focusing the group on the protocol work that you have identified. I = selected those two, and articulated them in that way, exactly because = they can cover the whole scope of the outlined work. >=20 > If we include those two use cases in the charter, probably it should = also mention that those are not the only ones, but are used to drive the = design. >=20 I kind of confused here. You agree that there is the right scope in the = proposed charter but that is lacking use-cases.=20 I would prefer having a charter that states what we are working on, not = where our work can/will be applied. If people are interested in use-cases, it is possible to add a use-case = document where we document where the work can be used. Would people be happy with such type of solution? >>=20 >> =46rom what I see in your mail I would say that the proposed charter = covers all of your work items (with the exception of the programmatic = northbound access to the mapping). >=20 > Yes. I think the SDN angle is very important for an overlay, and may = drive very relevant components of the architecture. The text you posted = does refers to YANG modeling, that is one component of programmability, = but I would like to see this requirement more explicit, particularly for = the mapping system. >=20 > I believe LISP, with the clean separation of the forwarding function = provided by the mapping system, can play a key role in controller-based = SDN applications. Again, it's not the only way to use LISP, but I think = it's an opportunity that the WG should pick up. >=20 >=20 I would prefer that in the charter we refer only to IETF work. This = means avoiding acronyms like SDN. First because it is a I_R_TF work, = second because SDN way too large. It means different things for = different people, so I am unsure on whether it helps in defining a clear = scope for our work. YANG is different, because it is clearly an IETF effort and is something = that we have anyway to consider. Yet, you can always propose some text to help in give a better scope to = the proposed charter. ciao L. >=20 > Thanks, > Fabio >=20 >=20 >=20 >> Or I am misunderstanding your comment? >>=20 >> ciao >>=20 >> L. >>=20 >>=20 >>> On 13 Oct 2015, at 23:53, Fabio Maino wrote: >>>=20 >>> Joel, Luigi, >>> thanks for taking a stab at this one. >>>=20 >>> I think it covers the relevant aspects that I would like to see the = WG to focus on. >>>=20 >>> As discussed in the use case thread, I would suggest that the draft = should mention a very small set of use cases that we can use to drive = the design decisions. I think that we can possibly cover all of the = protocol aspects you describe if we take the following two use cases: >>> 1) LISP-based programmable L2/L3 VPNs with extensions to support the = following services: >>> - encryption >>> - programmatic northbound access to the mapping and to xTR = configuration >>> - SFC/NFV >>> - VPN termination on mobile nodes >>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>>=20 >>> I think these two will give a good scope to the WG work and, without = resorting to more exotic use cases, reinforce the focus on the use of = LISP as an overlay technology. >>>=20 >>> Thanks, >>> Fabio >>>=20 >>>=20 >>>=20 >>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>> Folks, >>>>=20 >>>> in the past weeks (and months) there was a fruitful discussion that = took place on the mailing list (and also in Prague) concerning >>>> the new charter to be adopted by our WG. Thanks for this effort. >>>>=20 >>>> Beside this discussion we had proposals from WG members as well as = discussion with our AD about what is practical and reasonable. >>>> Hereafter you can find the result: a draft of the new proposed = charter. >>>>=20 >>>> This does not mean that discussion is over, rather that we reached = a first consistent milestone for further discussion. >>>> Discussion ideally culminating in our meeting in Japan. >>>>=20 >>>> So please have look and send your thoughts and feedback to the = mailing list. >>>>=20 >>>> Joel and Luigi >>>>=20 >>>> = %=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >>>> The LISP WG has completed the first set of Experimental RFCs >>>> describing the Locator/ID Separation Protocol (LISP). LISP supports >>>> a routing architecture which decouples the routing locators and >>>> identifiers, thus allowing for efficient aggregation of the routing = locator >>>> space and providing persistent identifiers in the identifier space. >>>> LISP requires no changes to end-systems or to routers that do not >>>> directly participate in the LISP deployment. LISP aims for an >>>> incrementally deployable protocol. The scope of the LISP >>>> technology is recognized to range from programmable overlays, >>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>> supporting mobility as a general feature, independently of whether >>>> it is a mobile user or a migrating VM, hence being applicable in = both >>>> Data Centers and public Internet environments. >>>>=20 >>>> The LISP WG is chartered to continue work on the LISP base protocol >>>> with the main objective to develop a standard solution based on the >>>> completed Experimental RFCs and the experience gained from early >>>> deployments. >>>> This work will include reviewing the existing set of Experimental = RFCs >>>> and doing the necessary enhancements to support a base set of >>>> standards track RFCs. The group will review the current set of = Working >>>> Group documents to identify potential standards-track documents and >>>> do the necessary enhancements to support standards-track. It is >>>> recognized that some of the work will continue on the experimental = track, >>>> though the group is encouraged to move the documents to standards >>>> track in support of network use, whereas the work previously was >>>> scoped to research studies. >>>>=20 >>>> Beside this main focus, the LISP WG may work on the following = items: >>>>=20 >>>> =E2=80=A2 NAT-Traversal >>>> =E2=80=A2 Mobility >>>> =E2=80=A2 Data-Plane Encryption >>>> =E2=80=A2 Multicast: Support for overlay multicast by means of = replication >>>> as well as interfacing with existing underlay multicast = support. >>>> =E2=80=A2 YANG Data models for management of LISP. >>>> =E2=80=A2 Multi-protocol support: Specifying the required = extensions to support >>>> multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 = Network Service >>>> Headers). Rather than developing new encapsulations, the = work will >>>> aim at using existing well-established encapsulations or = emerging >>>> from other Working Groups such as NVO3 and SFC. >>>> =E2=80=A2 Alternative Mapping System Design: When extending LISP = to support >>>> new protocols,it may be also necessary to develop the = related mapping >>>> function extensions to operate LISP map-assisted networks = (which >>>> might include Hierarchical Pull, Publish/Subscribe, or Push = models >>>> and related security extensions). >>>>=20 >>>> _______________________________________________ >>>> 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 >=20 From nobody Thu Oct 15 02:47:34 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0531ABD3B for ; Thu, 15 Oct 2015 02:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP1I4BMm54Oj for ; Thu, 15 Oct 2015 02:47:31 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FCF1ABD38 for ; Thu, 15 Oct 2015 02:47:30 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so20165536wic.1 for ; Thu, 15 Oct 2015 02:47:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=aOGe9Tk8xmR6tq/9iG9bde7WR6RXe8sETlp5lM6ZIck=; b=hKDL6IJNMFjq/IP/kYvruIfo782tykqY+rIeZlNU62UK6GPsoWCcDkshDwG7XSglZe 0Ple24LrWeblNTy+vaMxuO/3BXetU6FMIoLHPnw/BGCaq+USx+g4nO8kaFvyeVPLIDLb eP2L5R8ZIpSM4cmxP5/pHWloVi+pDp+xug9q0ryw3kZrTyI01qwydBOnwIJHtm/xjmkJ 00PV82zxzfgVdaYZSsxenM3XrxgkdMDRpAXglXovx7uNuVI3RcYbtzGlfdR6xnSvYfaV BF0z1JLFg3mX981jl+zdVTvtlVkOwjDGjHy58jxRTIB2nmr5X9oNDFLYqntzhG0F3HYk K/xg== X-Gm-Message-State: ALoCoQkwmvejZurFBc1qOmNeIVwnRDWGJZIPuF2/qgxTz5P0HHjIi0vf3/5TaVvuyY1k3I40izCH X-Received: by 10.180.91.12 with SMTP id ca12mr33327267wib.4.1444902448616; Thu, 15 Oct 2015 02:47:28 -0700 (PDT) Received: from dhcp164-197.enst.fr (dhcp164-197.enst.fr. [137.194.165.197]) by smtp.gmail.com with ESMTPSA id x9sm15380145wjf.44.2015.10.15.02.47.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 02:47:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Luigi Iannone In-Reply-To: Date: Thu, 15 Oct 2015 11:47:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <561D7D55.3090305@cisco.com> To: Albert Cabellos X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 09:47:33 -0000 Hi Albert I may agree with you in what can be done and what is interesting, = but=E2=80=A6.. At this point it looks to me (personal opinion) as a bit premature to = add such kind of working item. It looks like we are still at very early stage where we still look what = kind of solution would be the best fit. Or have you more precise ideas? ciao L. > On 15 Oct 2015, at 00:10, Albert Cabellos = wrote: >=20 > Hi Luigi >=20 > Please see my comments inline: >=20 > On Wed, Oct 14, 2015 at 1:31 AM, Luigi Iannone wrote: >=20 > [snip] >=20 >> Having design guidelines does not forcedly mean having a programmatic = language approach. Right? >>=20 >> In your opinion could well defined guidelines (not language) be = added to the current LCAF document? >=20 > I am unsure if we can do this without ending up reproducing some sort > of language, we=C2=B4ll start by defining scalar data-types, then = complex > data-types (combinations of scalars), then data-structures, then > encoding mechanisms for each scalar and each data-structure and so on. >=20 > This could be as simple as defining an encoding mechanisms for YANG > (XMLBIN with some sort of compression). I am not stating that we > should go this precise way, what I am stating is that LCAF is rigid > and, if a new use-case is not defined as an LCAF, it can=C2=B4t be = deployed > in a standard way. A language could solve this issue and make the LISP > control plane truly flexible. >=20 >>=20 >>> to define new ones. A flexible language with a clear >>> syntax would ease deployment of new use-cases both at the data and >>> control plane. >>=20 >> How much relevant and with what priority is this for the WG? ( _NOTE_ = this question is for the whole WG not just for Albert=E2=80=A6) >>=20 >=20 > me too :) >=20 > Albert >=20 >>> Maybe this could be done as experimental (not >>> standard). >>=20 >> _if_ the WG decides to take on this work it would very reasonable to = go for experimental. >>=20 >> ciao >>=20 >> L. >>=20 >>=20 >>>=20 >>> Albert >>>=20 >>>=20 >>> On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino = wrote: >>>>=20 >>>> Joel, Luigi, >>>> thanks for taking a stab at this one. >>>>=20 >>>> I think it covers the relevant aspects that I would like to see the = WG to focus on. >>>>=20 >>>> As discussed in the use case thread, I would suggest that the draft = should mention a very small set of use cases that we can use to drive = the design decisions. I think that we can possibly cover all of the = protocol aspects you describe if we take the following two use cases: >>>> 1) LISP-based programmable L2/L3 VPNs with extensions to support = the following services: >>>> - encryption >>>> - programmatic northbound access to the mapping and to xTR = configuration >>>> - SFC/NFV >>>> - VPN termination on mobile nodes >>>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>>>=20 >>>> I think these two will give a good scope to the WG work and, = without resorting to more exotic use cases, reinforce the focus on the = use of LISP as an overlay technology. >>>>=20 >>>> Thanks, >>>> Fabio >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>>>=20 >>>>> Folks, >>>>>=20 >>>>> in the past weeks (and months) there was a fruitful discussion = that took place on the mailing list (and also in Prague) concerning >>>>> the new charter to be adopted by our WG. Thanks for this effort. >>>>>=20 >>>>> Beside this discussion we had proposals from WG members as well as = discussion with our AD about what is practical and reasonable. >>>>> Hereafter you can find the result: a draft of the new proposed = charter. >>>>>=20 >>>>> This does not mean that discussion is over, rather that we reached = a first consistent milestone for further discussion. >>>>> Discussion ideally culminating in our meeting in Japan. >>>>>=20 >>>>> So please have look and send your thoughts and feedback to the = mailing list. >>>>>=20 >>>>> Joel and Luigi >>>>>=20 >>>>> = %=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >>>>> The LISP WG has completed the first set of Experimental RFCs >>>>> describing the Locator/ID Separation Protocol (LISP). LISP = supports >>>>> a routing architecture which decouples the routing locators and >>>>> identifiers, thus allowing for efficient aggregation of the = routing locator >>>>> space and providing persistent identifiers in the identifier = space. >>>>> LISP requires no changes to end-systems or to routers that do not >>>>> directly participate in the LISP deployment. LISP aims for an >>>>> incrementally deployable protocol. The scope of the LISP >>>>> technology is recognized to range from programmable overlays, >>>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>>> supporting mobility as a general feature, independently of whether >>>>> it is a mobile user or a migrating VM, hence being applicable in = both >>>>> Data Centers and public Internet environments. >>>>>=20 >>>>> The LISP WG is chartered to continue work on the LISP base = protocol >>>>> with the main objective to develop a standard solution based on = the >>>>> completed Experimental RFCs and the experience gained from early >>>>> deployments. >>>>> This work will include reviewing the existing set of Experimental = RFCs >>>>> and doing the necessary enhancements to support a base set of >>>>> standards track RFCs. The group will review the current set of = Working >>>>> Group documents to identify potential standards-track documents = and >>>>> do the necessary enhancements to support standards-track. It is >>>>> recognized that some of the work will continue on the experimental = track, >>>>> though the group is encouraged to move the documents to standards >>>>> track in support of network use, whereas the work previously was >>>>> scoped to research studies. >>>>>=20 >>>>> Beside this main focus, the LISP WG may work on the following = items: >>>>>=20 >>>>> =E2=80=A2 NAT-Traversal >>>>> =E2=80=A2 Mobility >>>>> =E2=80=A2 Data-Plane Encryption >>>>> =E2=80=A2 Multicast: Support for overlay multicast by means = of replication >>>>> as well as interfacing with existing underlay multicast = support. >>>>> =E2=80=A2 YANG Data models for management of LISP. >>>>> =E2=80=A2 Multi-protocol support: Specifying the required = extensions to support >>>>> multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 = Network Service >>>>> Headers). Rather than developing new encapsulations, the = work will >>>>> aim at using existing well-established encapsulations or = emerging >>>>> from other Working Groups such as NVO3 and SFC. >>>>> =E2=80=A2 Alternative Mapping System Design: When extending = LISP to support >>>>> new protocols,it may be also necessary to develop the = related mapping >>>>> function extensions to operate LISP map-assisted networks = (which >>>>> might include Hierarchical Pull, Publish/Subscribe, or Push = models >>>>> and related security extensions). >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 From nobody Thu Oct 15 02:52:46 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240A01AC3C1 for ; Thu, 15 Oct 2015 02:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek4JrrLTkL2C for ; Thu, 15 Oct 2015 02:52:43 -0700 (PDT) Received: from mail-wi0-f195.google.com (mail-wi0-f195.google.com [209.85.212.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB04A1AC3CB for ; Thu, 15 Oct 2015 02:52:42 -0700 (PDT) Received: by wihh2 with SMTP id h2so17979170wih.3 for ; Thu, 15 Oct 2015 02:52:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=lq0HKMfnKCB5SzvgaOb8fkw+2Mj7V2RFsD4be4Qk8JU=; b=K7sNGjoX9xFti1+oxSrZfmZ3lFHeig+5LByFdT42bwk8nusHkM77fAzIEaP9XqAfqs g8gRtNMkTaY2dgd1U64twiHCGwFUrKXSupKTtcd4hs/adWR5zMOr5m9ipQWZXVj3ips+ gU8akH/Fuam+gcbnsRs3rla9+/lVgjiJo6eshgfeUOiMWx2V25LqAu8ktX7E+Z3+T6TD VklD6yQzH5r62gVe3+EyGJyuTcKsnhRlgJLzNYcNeR0yAivoK0h1mOE1pEH+7X3eit+f m/yzaCvhbaip00GfxCVjbu9/k9woc5NH+f9jEJ+Apv5CHOtN8p6er7blwl8oP5HA9Z0o dGEA== X-Gm-Message-State: ALoCoQm748DL0HH1e2o0R4GsR8SGNwjElSEpYcA5ZKj5zccnO8uf/AEtd3fBUAIfPIQqJnyiNTYy X-Received: by 10.180.106.10 with SMTP id gq10mr9014878wib.51.1444902760985; Thu, 15 Oct 2015 02:52:40 -0700 (PDT) Received: from dhcp164-197.enst.fr (dhcp164-197.enst.fr. [137.194.165.197]) by smtp.gmail.com with ESMTPSA id lv4sm15411855wjb.43.2015.10.15.02.52.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 02:52:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Luigi Iannone In-Reply-To: Date: Thu, 15 Oct 2015 11:52:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <561D7D55.3090305@cisco.com> <3C8EF5A4-B81B-45DB-ACF4-20F9A4A9E625@gigix.net> <561E7448.7080209@cisco.com> To: Sharon X-Mailer: Apple Mail (2.3094) Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 09:52:45 -0000 Hi Sharon, > On 14 Oct 2015, at 20:28, Sharon wrote: >=20 > We could say that as we completed a set of experimental lisp rfcs the = importance of connectionless logical services networks overlaying and or = anchoring topological IP networks grew significantly.=20 >=20 > To accommodate we continue to evolve the unique lisp map-assisted = overlay architecture characteristics along the following lines: > - traversal, schemas, chaining=E2=80=A6 Thanks the above observation can be converted to text for the new = charter. Let me think a bit the way to do it. > etc >=20 > We evolve these lisp aspects and examine their applicability by = matching and testing them vis-a-vis key example use-cases: > - VPN virtual logical private services networks > - NFV virtualization of functions from junctions=20 > - DMM distributed (floating-anchors) mobility =20 >=20 References to VPN and DMM can be added, since this is IETF work. For NFV, is I have the same comment as for SDN. It looks to me that in = this way we make scope more fuzzy rather than clear. Moreover, like for = SDN, this is IRTF work. ciao L. =20 > --szb >=20 >> On Oct 14, 2015, at 8:27 AM, Fabio Maino wrote: >>=20 >>> On 10/14/15 1:23 AM, Luigi Iannone wrote: >>> Hi Fabio, >>>=20 >>> thanks for the feedback. >>> Are you saying that the scope of the proposed chart is too large? >>=20 >> No, I think the scope is very appropriate. I was just suggesting that = we use those two use cases to drive the design decisions. >>=20 >> There are clearly many more use cases that a LISP overlay can be used = for, but in my opinion those two are well understood and will help = focusing the group on the protocol work that you have identified. I = selected those two, and articulated them in that way, exactly because = they can cover the whole scope of the outlined work. >>=20 >> If we include those two use cases in the charter, probably it should = also mention that those are not the only ones, but are used to drive the = design. >>=20 >>>=20 >>> =46rom what I see in your mail I would say that the proposed charter = covers all of your work items (with the exception of the programmatic = northbound access to the mapping). >>=20 >> Yes. I think the SDN angle is very important for an overlay, and may = drive very relevant components of the architecture. The text you posted = does refers to YANG modeling, that is one component of programmability, = but I would like to see this requirement more explicit, particularly for = the mapping system. >>=20 >> I believe LISP, with the clean separation of the forwarding function = provided by the mapping system, can play a key role in controller-based = SDN applications. Again, it's not the only way to use LISP, but I think = it's an opportunity that the WG should pick up. >>=20 >>=20 >>=20 >> Thanks, >> Fabio >>=20 >>=20 >>=20 >>> Or I am misunderstanding your comment? >>>=20 >>> ciao >>>=20 >>> L. >>>=20 >>>=20 >>>> On 13 Oct 2015, at 23:53, Fabio Maino wrote: >>>>=20 >>>> Joel, Luigi, >>>> thanks for taking a stab at this one. >>>>=20 >>>> I think it covers the relevant aspects that I would like to see the = WG to focus on. >>>>=20 >>>> As discussed in the use case thread, I would suggest that the draft = should mention a very small set of use cases that we can use to drive = the design decisions. I think that we can possibly cover all of the = protocol aspects you describe if we take the following two use cases: >>>> 1) LISP-based programmable L2/L3 VPNs with extensions to support = the following services: >>>> - encryption >>>> - programmatic northbound access to the mapping and to xTR = configuration >>>> - SFC/NFV >>>> - VPN termination on mobile nodes >>>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>>>=20 >>>> I think these two will give a good scope to the WG work and, = without resorting to more exotic use cases, reinforce the focus on the = use of LISP as an overlay technology. >>>>=20 >>>> Thanks, >>>> Fabio >>>>=20 >>>>=20 >>>>=20 >>>>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>>> Folks, >>>>>=20 >>>>> in the past weeks (and months) there was a fruitful discussion = that took place on the mailing list (and also in Prague) concerning >>>>> the new charter to be adopted by our WG. Thanks for this effort. >>>>>=20 >>>>> Beside this discussion we had proposals from WG members as well as = discussion with our AD about what is practical and reasonable. >>>>> Hereafter you can find the result: a draft of the new proposed = charter. >>>>>=20 >>>>> This does not mean that discussion is over, rather that we reached = a first consistent milestone for further discussion. >>>>> Discussion ideally culminating in our meeting in Japan. >>>>>=20 >>>>> So please have look and send your thoughts and feedback to the = mailing list. >>>>>=20 >>>>> Joel and Luigi >>>>>=20 >>>>> = %=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >>>>> The LISP WG has completed the first set of Experimental RFCs >>>>> describing the Locator/ID Separation Protocol (LISP). LISP = supports >>>>> a routing architecture which decouples the routing locators and >>>>> identifiers, thus allowing for efficient aggregation of the = routing locator >>>>> space and providing persistent identifiers in the identifier = space. >>>>> LISP requires no changes to end-systems or to routers that do not >>>>> directly participate in the LISP deployment. LISP aims for an >>>>> incrementally deployable protocol. The scope of the LISP >>>>> technology is recognized to range from programmable overlays, >>>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>>> supporting mobility as a general feature, independently of whether >>>>> it is a mobile user or a migrating VM, hence being applicable in = both >>>>> Data Centers and public Internet environments. >>>>>=20 >>>>> The LISP WG is chartered to continue work on the LISP base = protocol >>>>> with the main objective to develop a standard solution based on = the >>>>> completed Experimental RFCs and the experience gained from early >>>>> deployments. >>>>> This work will include reviewing the existing set of Experimental = RFCs >>>>> and doing the necessary enhancements to support a base set of >>>>> standards track RFCs. The group will review the current set of = Working >>>>> Group documents to identify potential standards-track documents = and >>>>> do the necessary enhancements to support standards-track. It is >>>>> recognized that some of the work will continue on the experimental = track, >>>>> though the group is encouraged to move the documents to standards >>>>> track in support of network use, whereas the work previously was >>>>> scoped to research studies. >>>>>=20 >>>>> Beside this main focus, the LISP WG may work on the following = items: >>>>>=20 >>>>> =E2=80=A2 NAT-Traversal >>>>> =E2=80=A2 Mobility >>>>> =E2=80=A2 Data-Plane Encryption >>>>> =E2=80=A2 Multicast: Support for overlay multicast by means of = replication >>>>> as well as interfacing with existing underlay multicast = support. >>>>> =E2=80=A2 YANG Data models for management of LISP. >>>>> =E2=80=A2 Multi-protocol support: Specifying the required = extensions to support >>>>> multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 = Network Service >>>>> Headers). Rather than developing new encapsulations, the = work will >>>>> aim at using existing well-established encapsulations or = emerging >>>>> from other Working Groups such as NVO3 and SFC. >>>>> =E2=80=A2 Alternative Mapping System Design: When extending = LISP to support >>>>> new protocols,it may be also necessary to develop the = related mapping >>>>> function extensions to operate LISP map-assisted networks = (which >>>>> might include Hierarchical Pull, Publish/Subscribe, or Push = models >>>>> and related security extensions). >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Oct 15 06:22:01 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DD51A6F82 for ; Thu, 15 Oct 2015 06:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19tcypKDtobI for ; Thu, 15 Oct 2015 06:21:58 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3481B2B5E for ; Thu, 15 Oct 2015 06:21:57 -0700 (PDT) Received: by wijp11 with SMTP id p11so29618272wij.0 for ; Thu, 15 Oct 2015 06:21:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=sYF5wrF1m8j8FQVIc/IhyOwkLLM1mefNgUNLy8N0dt8=; b=ahXxzqwY7WrkTy+WwjqBxPgr3XTEiqaqXcg6R4nDBqPHkINjVVqpHxNzVOqwMUM0ru znv1CWz4L3NvD+kz5hPB1sTmg0T9m0Uetz898b/cQYtRw/Lj4aGNeXz2S+olKOjEYJj2 OdFqmOxbtm3cdMOBpwIUPEtCSngc79IcPy/BWERztbX3UoykMMAyL3zknevZp43MnCjE wyv975KetBzTyZZ8DUHJaE3pLGqqD+d7Q7qiPGyrDodtX86JoQKHa+QrTvGTeTB1E6V9 qMciGPszknRIuAXi6DaQwtQ7okLWb7ePqHGRlCTOkuckxc8VWwLlnu4d1FZL3TILnsJv Y2/A== X-Gm-Message-State: ALoCoQlcwFAYlhCRzNzYTC4ngE/Kr3n3hGuDd5Efb61jW1jMChKRDwgqKyi3/0eN9CfvN1lIv7U6 X-Received: by 10.180.208.42 with SMTP id mb10mr36087167wic.60.1444915316328; Thu, 15 Oct 2015 06:21:56 -0700 (PDT) Received: from ?IPv6:2001:660:330f:38:e46d:a71b:e13c:3edf? ([2001:660:330f:38:e46d:a71b:e13c:3edf]) by smtp.gmail.com with ESMTPSA id it4sm16489911wjb.0.2015.10.15.06.21.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 06:21:54 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_5CC2851F-71E8-4634-AA72-70FD38B08B64" Date: Thu, 15 Oct 2015 15:21:58 +0200 Message-Id: <47289974-45B8-4EFE-BB35-39DE183C0719@gigix.net> To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) Archived-At: Subject: [lisp] Call for Agenda items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:21:59 -0000 --Apple-Mail=_5CC2851F-71E8-4634-AA72-70FD38B08B64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, the Yokohama meeting is rapidly approaching and is time to fix the = agenda for our WG. The LISP WG is scheduled to meet on Tuesday, November 3rd, 2015, from = 15:20 to 16:50 (1.5 hours) Beside the usual administrative stuff and a quick update on the progress of current WG documents we would like to dedicate a=20 large part of the meeting for progress on rechartering. This time will be organised in two parts: - A few presentations on potential new work items as for the current = proposed charter. - Open discussion on the proposed charter (eventually going through it). Thus, the chairs welcome slot requests for those new work items. Please send your requests (Presenter=E2=80=99s name, ppt title, slot = duration) to lisp-chairs@tools.ietf.org = by Monday, October 19th, 2015. Chairs are going to prioritize requests based on the charter and milestones. Joel & Luigi= --Apple-Mail=_5CC2851F-71E8-4634-AA72-70FD38B08B64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi All,

the = Yokohama meeting is rapidly approaching and is time to fix = the agenda for our WG.
The LISP WG  is scheduled = to meet on Tuesday, November 3rd, 2015, from 15:20 to 16:50 (1.5 = hours)

Beside the usual administrative = stuff and a quick update on the
progress of current WG = documents we would like to dedicate a 
large part of the meeting for progress = on rechartering.

This time will be = organised in two parts:

- A few = presentations on potential new work items as for the = current proposed charter.

- Open = discussion on the proposed charter (eventually going through it).

Thus, the chairs welcome slot requests for = those new work items.

Please send your = requests (Presenter=E2=80=99s name, ppt title, slot = duration) to lisp-chairs@tools.ietf.org by
Monday, = October 19th, 2015.

Chairs are going to = prioritize requests based on the charter and
milestones.

Joel & Luigi
= --Apple-Mail=_5CC2851F-71E8-4634-AA72-70FD38B08B64-- From nobody Thu Oct 15 09:08:36 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386201B3358 for ; Thu, 15 Oct 2015 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oys3NyCAx9qm for ; Thu, 15 Oct 2015 09:08:32 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0F21B312A for ; Thu, 15 Oct 2015 09:08:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8CFF724022B; Thu, 15 Oct 2015 09:08:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C4A4824143E; Thu, 15 Oct 2015 09:08:31 -0700 (PDT) To: Dino Farinacci References: <561D7D55.3090305@cisco.com> <561EDF6E.60805@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <561FCF7E.2050107@joelhalpern.com> Date: Thu, 15 Oct 2015 12:08:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:08:34 -0000 Agreed. My concerns in the LCAF aspects revolve around EID usage. RLOC usage is, as you say, understandable. Yours, joel On 10/15/15 11:26 AM, Dino Farinacci wrote: >> I am really unclear as to what the problem being addressed by creating a programmatic language for LCAFs is. Heck, I am confused by what the JSON LCAFs are solving too. > > At this point in time, it is not clear to me how the JSON LCAF would be used as an EID-record. However, returning a JSON dictionary array as output of a lookup (an RLOC-record), is quite useful. Doing that latter requires no mapping system changes. Doing the former would require a major change IMO. > > Dino > From nobody Fri Oct 16 13:49:14 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D3E1AD05F; Fri, 16 Oct 2015 13:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMzvurVJJIor; Fri, 16 Oct 2015 13:49:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5AC1AD05E; Fri, 16 Oct 2015 13:49:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151016204907.24911.75589.idtracker@ietfa.amsl.com> Date: Fri, 16 Oct 2015 13:49:07 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-sec-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 20:49:11 -0000 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-Security (LISP-SEC) Authors : Fabio Maino Vina Ermagan Albert Cabellos Damien Saucez Filename : draft-ietf-lisp-sec-09.txt Pages : 19 Date : 2015-10-16 Abstract: This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-sec-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-sec-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 17 11:59:30 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C60C1B2C4F for ; Sat, 17 Oct 2015 11:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBrQiVv8SJCT for ; Sat, 17 Oct 2015 11:59:28 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2162A1B2C4E for ; Sat, 17 Oct 2015 11:59:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0D100240E9C for ; Sat, 17 Oct 2015 11:59:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BC0B924032B for ; Sat, 17 Oct 2015 11:59:27 -0700 (PDT) References: <20151017170403.30424.54786.idtracker@ietfa.amsl.com> To: "lisp@ietf.org" From: Joel Halpern X-Forwarded-Message-Id: <20151017170403.30424.54786.idtracker@ietfa.amsl.com> Message-ID: <56229A8E.9040800@joelhalpern.com> Date: Sat, 17 Oct 2015 14:59:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151017170403.30424.54786.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Fwd: Nomcom 2015 CORRECTION: Call for community feedback X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 18:59:29 -0000 Please provide feedback. Yours, Joel -------- Forwarded Message -------- Subject: Nomcom 2015 CORRECTION: Call for community feedback Date: Sat, 17 Oct 2015 10:04:03 -0700 From: NomCom Chair 2015 Reply-To: ietf@ietf.org To: IETF Announcement List CC: ietf@ietf.org The links and emails in the previoius posting were wrong. Here's a corrected version. My apologies! -------------------------------------------------------------------- The 2015-16 Nominating Committee has collected a list of willing candidates for the positions outlined below. You can see the list at: https://datatracker.ietf.org/nomcom/2015/feedback/ You may provide feedback using the web form there; it is secure. All feedback goes into the datatracker using asymmetric encryption, which is decrypted by the nomcom members as they read it. So your feedback can not be seen by the secretariat, the tools people, or any of the management. Your feedback through the web form is not anonymous as you need a login to provide it. You may also provide feedback by emailing nomcom15@ietf.org, which enters the same system through email; it is as non-anonymous as email is, but I do have to sort it out. A separate email per candidate is easier to deal with. If you want to give truly anonymous feedback, please contact one of the NomCom members that you trust directly, and ask him/her to relay the feedback anonymously to the NomCom. We will also announce office hours in Yokohama shortly. The positions to be filled are those currently held by: IAB - Mary Barnes - Joe Hildebrand - Ted Hardie - Erik Nordmark - Brian Trammell - Marc Blanchet IESG - Alissa Cooper (ART) - Barry Leiba (ART) - Brian Haberman (Internet) (*) - Benoit Claise (Operations and Management) - Alia Atlas (Routing) - Kathleen Moriarty (Security) - Martin Stiemerling (Transport) (*) Harald Alvestrand, Nomcom chair 2015 nomcom-chair-2015@ietf.org, hta+nomcom@alvestrand.no From nobody Mon Oct 19 11:44:00 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ED11B2B65 for ; Mon, 19 Oct 2015 11:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GliU_4YmX3am for ; Mon, 19 Oct 2015 11:43:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699BF1B2B52 for ; Mon, 19 Oct 2015 11:43:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYZ77617; Mon, 19 Oct 2015 18:43:54 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 19 Oct 2015 19:43:54 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.220]) by SJCEML702-CHM.china.huawei.com ([169.254.4.95]) with mapi id 14.03.0235.001; Mon, 19 Oct 2015 11:43:50 -0700 From: Richard Li To: LISP mailing list list Thread-Topic: looking for clarifications on rfc 6830 Thread-Index: AdEKnhay+P+VUKtLQsuYBYLz3YP9mw== Date: Mon, 19 Oct 2015 18:43:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.32] Content-Type: multipart/alternative; boundary="_000_F061CEB6876F904F8EA6D6B92877731C3900A80ASJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [lisp] looking for clarifications on rfc 6830 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:43:59 -0000 --_000_F061CEB6876F904F8EA6D6B92877731C3900A80ASJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, I have read RFC 6830. I have a few points I could not figure them out by my= self. Appreciated if you could clarify them. 1. TTL Page 20, Section 5.3: The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of= IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when th= e Time to Live value of the outer header is less than the Time to Live valu= e of the inner header. Isn't it always true that the TTL in outer header is less than or equal to = TTL in the inner header. Since the ITR copies TTL from the inner header to = the outer header, the ETR should find that TTL in the outer header can't be= bigger than TTL in the inner header. 2. Fragment size: Page 21, Section 5.4.1 The size of the encapsulated fragments is then (S/2 + H), which is less tha= n the ITR's estimate of the path MTU between the ITR and its correspondent = ETR. Is this right? Look! H is a fixed number (=3D UDP header length + LISP header length), and= S is also a fixed size (=3D L - H, where L is the path MTU). It looks to me that the fragment size should be less than (S/2+H). In order to achieve (S/2+H), does the spec actually suggest any padding so = as to meet (S/2+H)? 3. Best-Match Prefixes Page 35, Section 6.1.5: A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record count = of 3 to be returned with mapping records for EID-Prefixes 10.1.0.0/16, 10.1= .1.0/24, and 10.1.2.0/24. Take a look at the EID prefixes in binary: 00001010.00000000.00000000.00000000 (10.0.0.0/8) 00001010.00000001.00000000.00000000 (10.1.0.0/16) 00001010.00000001.00000001.00000000 (10.1.1.0/24) 00001010.00000001.00000010.00000000 (10.1.2.0/24) 00001010.00000001.00000101.00000101 (10.1.5.5/32) Performing the best match of 10.1.5.5/32 against the EID prefix database, w= e will have only 10.1.0.0/16. Thanks, Richard --_000_F061CEB6876F904F8EA6D6B92877731C3900A80ASJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

I have read RFC 6830. I have a few points I could no= t figure them out by myself. Appreciated if you could clarify them.

 

 

1.       TTL

Page 20, Section = 5.3:

The inner-header = 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be = copied from the outer-header 'Time to Live' field, when the Time to Live va= lue of the outer header is less than the Time to Live value of the inner header.

 =

Isn’t it al= ways true that the TTL in outer header is less than or equal to TTL in the = inner header. Since the ITR copies TTL from the inner header to the outer h= eader, the ETR should find that TTL in the outer header can’t be bigger than TTL in the inner header.

 =

2.       Fragment size:

Page 21, Section = 5.4.1

The size of the e= ncapsulated fragments is then (S/2 + H), which is less than the ITR's e= stimate of the path MTU between the ITR and its correspondent ETR.

 =

Is this right?

Look! H is a fixe= d number (=3D UDP header length + LISP header length), and S is also a = fixed size (=3D L – H, where L is the path MTU).

It looks to me th= at the fragment size should be less than (S/2+H).

In order to achie= ve (S/2+H), does the spec actually suggest any padding so as to meet (S= /2+H)?

 =

3.       Best-Match Prefixes

Page 35, Section = 6.1.5:

A Map-Request for= EID 10.1.5.5 would cause a Map-Reply with a record count of 3 to be return= ed with mapping records for EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1= .2.0/24.

 =

Take a look at th= e EID prefixes in binary:

00001010.00000000= .00000000.00000000 (10.0.0.0/8)

00001010.00000001= .00000000.00000000 (10.1.0.0/16)

00001010.00000001= .00000001.00000000 (10.1.1.0/24)

00001010.00000001= .00000010.00000000 (10.1.2.0/24)

 =

00001010.00000001= .00000101.00000101 (10.1.5.5/32)

 =

Performing the be= st match of 10.1.5.5/32 against the EID prefix database, we will have only = 10.1.0.0/16.

 =

Thanks,<= /p>

 

Richard<= /p>

 =

 =

 =

 =

 =

 

 

 =

 =

 

--_000_F061CEB6876F904F8EA6D6B92877731C3900A80ASJCEML701CHMchi_-- From nobody Mon Oct 19 12:02:31 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAF81B2C13 for ; Mon, 19 Oct 2015 12:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KL_prxP3k1zY for ; Mon, 19 Oct 2015 12:02:23 -0700 (PDT) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E801B2BFC for ; Mon, 19 Oct 2015 12:02:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AE3A01C0D4F; Mon, 19 Oct 2015 12:02:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id EB6871C0095; Mon, 19 Oct 2015 12:02:14 -0700 (PDT) To: Richard Li , LISP mailing list list References: From: "Joel M. Halpern" Message-ID: <56253E35.6070309@joelhalpern.com> Date: Mon, 19 Oct 2015 15:02:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] looking for clarifications on rfc 6830 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 19:02:30 -0000 Thank you for reading RFC 6830 carefully. My understanding of the answers to your questions is in line below. Yours, Joel On 10/19/15 2:43 PM, Richard Li wrote: > Hi Folks, > > I have read RFC 6830. I have a few points I could not figure them out by > myself. Appreciated if you could clarify them. > > 1.TTL > > Page 20, Section 5.3: > > The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case > of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, > when the Time to Live value of the outer header is less than the Time to > Live value of the inner header. > > Isn’t it always true that the TTL in outer header is less than or equal > to TTL in the inner header. Since the ITR copies TTL from the inner > header to the outer header, the ETR should find that TTL in the outer > header can’t be bigger than TTL in the inner header. the reason the comparison condition is needed is that the encapsulation condition of copying the TTL is only a SHOULD. If the ITR did something else, for some reason, then the safety condition might not be met a priori. Since the ETR does not know exactly what the ITR did, it needs to check. > > 2.Fragment size: > > Page 21, Section 5.4.1 > > The size of the encapsulated fragments is then (S/2 + H), which is less > than the ITR's estimate of the path MTU between the ITR and its > correspondent ETR. > > Is this right? > > Look! H is a fixed number (= UDP header length + LISP header length), > and S is also a fixed size (= L – H, where L is the path MTU). > > It looks to me that the fragment size should be less than (S/2+H). > > In order to achieve (S/2+H), does the spec actually suggest any padding > so as to meet (S/2+H)? There is a bit of sloppy wording. The S in (S/2 + H) is not the maximum S supportable without fragmentation, but the actual size packet received from the site. When we revise this document, we should clean up the description to make it more clear. > > 3.Best-Match Prefixes > > Page 35, Section 6.1.5: > > A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record > count of 3 to be returned with mapping records for EID-Prefixes > 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. > > Take a look at the EID prefixes in binary: > > 00001010.00000000.00000000.00000000 (10.0.0.0/8) > > 00001010.00000001.00000000.00000000 (10.1.0.0/16) > > 00001010.00000001.00000001.00000000 (10.1.1.0/24) > > 00001010.00000001.00000010.00000000 (10.1.2.0/24) > > 00001010.00000001.00000101.00000101 (10.1.5.5/32) > > Performing the best match of 10.1.5.5/32 against the EID prefix > database, we will have only 10.1.0.0/16. I am not sure what your question is here. The reason the extra entries (beyond 10.1.0.0/16 have to be returned is not that one of them matches the request. Youa re correct, and the text agrees, that there is only one entry matching 10.1.5.5/32. The reason the extra entries need to be returned is that in the absence of those entries, later packets which match those other entries will be misdirected. Is the text insufficiently clear about the reason for sending the additional entries? If so, can you suggest text improvement for us to use in the next revision? > > Thanks, > > Richard > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Mon Oct 19 13:38:29 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2831ACC89 for ; Mon, 19 Oct 2015 13:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j47xXEFUvCUJ for ; Mon, 19 Oct 2015 13:38:03 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570F81AC422 for ; Mon, 19 Oct 2015 13:38:01 -0700 (PDT) Received: by qgeo38 with SMTP id o38so125447406qge.0 for ; Mon, 19 Oct 2015 13:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qV3RE9x0QNSn0EEBOt+8/XwqbhDv3QuTXCiI6vqSoHU=; b=DKrg1viP5p/sPhuPZ/htlh9Qq/7GOWj4tT9TaYNRIMhpoaz2KQtKQSoSKmcMawgW4F V5PEyDbRKkELRxz/IsK69JPM10DQZXQ4z4CJHgY9NMkAHwCx/mL9BC6OZFSrFDamheHT WmbRlIL19cTI35VCBYOt5hk94LokzNMN2l5sUwG6Pci9hvwI9alo3XwiLu/TnmUkOBl9 Tcii/3hHJYJcaRlP79+9jhCinIsFF1bR9ui7esiVzL9uaFzPVhSjMKXpEoKCDDPFOjNo 6c6zLHMroHSRObhPK7Qm5nRRJneP8vLfHpI4+LKw6QYk0hU5ZizbsZMfFWe2FtzHbiyF ahWA== X-Received: by 10.140.131.198 with SMTP id 189mr41388385qhd.83.1445287080526; Mon, 19 Oct 2015 13:38:00 -0700 (PDT) Received: from [10.20.21.228] (ip-64-134-242-26.public.wayport.net. [64.134.242.26]) by smtp.gmail.com with ESMTPSA id m26sm15108040qki.28.2015.10.19.13.37.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 13:37:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: <56253E35.6070309@joelhalpern.com> Date: Mon, 19 Oct 2015 13:37:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0F6A7294-3DC1-4821-BF59-BE77E3776551@gmail.com> References: <56253E35.6070309@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] looking for clarifications on rfc 6830 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:38:07 -0000 > 2.Fragment size: >>=20 >> Page 21, Section 5.4.1 >>=20 >> The size of the encapsulated fragments is then (S/2 + H), which is = less >> than the ITR's estimate of the path MTU between the ITR and its >> correspondent ETR. >>=20 >> Is this right? >>=20 >> Look! H is a fixed number (=3D UDP header length + LISP header = length), >> and S is also a fixed size (=3D L =96 H, where L is the path MTU). >>=20 >> It looks to me that the fragment size should be less than (S/2+H). >>=20 >> In order to achieve (S/2+H), does the spec actually suggest any = padding >> so as to meet (S/2+H)? >=20 > There is a bit of sloppy wording. The S in (S/2 + H) is not the = maximum S supportable without fragmentation, but the actual size packet = received from the site. When we revise this document, we should clean = up the description to make it more clear. Please let me clarify. =93L=94 is the largest packet an ITR can send so = there is no fragmentation. So it is made up size H, the size of the = headers the ITR will prepend, and S, the size of the packet that is = offered by the source. S is the maximum that the source can send so that = when H is added we can get L. This is all stated in the 1-3 bullets. The S/2 + H is the intentional size. We were not trying to get the = maximum size packets for fragmentation because the intermediate routers = could add headers (if there was more tunneling going on). So we give the = intermediate routers S/2 room. Dino From nobody Mon Oct 19 22:50:46 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E761A03E1 for ; Mon, 19 Oct 2015 22:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qUGOJryg3q9 for ; Mon, 19 Oct 2015 22:50:43 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8B71A03C7 for ; Mon, 19 Oct 2015 22:50:42 -0700 (PDT) Received: by wicfv8 with SMTP id fv8so11567695wic.0 for ; Mon, 19 Oct 2015 22:50:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=DV3WH1PqA//BmPul4UnQSlo0jVqEeaHSXaX4JGwCnGs=; b=LFBGfpM/vXFNeNiaW4DsA84DmpCFlDh0odGO33m75vcginI54X6ZgPZfhi1KbyD1lg tWrmMqPtZB0uS84WrmzQJwSR2gYhWJtWauYZ+JOGH0885GFgnRSHCUBdm8D8gOHdpf5+ qkA+craUfRGqXlEjBGkg2t+XmK8gPdQGUEM0/vnxal4r+ESaScJ+KCfyq5uAfSZq1qFT Q3952FcIl9B+cZGBKTZGYMqYHX8VZXF8DuV+6vGqXI3EpVMmDjBTQbQQZk03ppXrmZGD vhSDX/PLJtWTXrfmJBlpPbaam6p+uJ2cKDN/iISxExR/GsIzei9sibNmsIKwQQE2/WrW L0vw== X-Gm-Message-State: ALoCoQlDPSLucmITsdL726VCXw9oitXtJVQ5Ujv9Y8m8Pvr34Ep0LhGN7HVBpRjh/R8e1RcVpzcz X-Received: by 10.180.221.193 with SMTP id qg1mr24299007wic.87.1445320241016; Mon, 19 Oct 2015 22:50:41 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:b8cf:5063:4a7a:55d5? ([2a01:e35:1381:3430:b8cf:5063:4a7a:55d5]) by smtp.gmail.com with ESMTPSA id p4sm17802059wia.15.2015.10.19.22.50.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 22:50:39 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_567D164D-3492-4E25-9F39-EA5318B5C9A4" Message-Id: Date: Tue, 20 Oct 2015 07:50:44 +0200 To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) Archived-At: Subject: [lisp] Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 05:50:44 -0000 --Apple-Mail=_567D164D-3492-4E25-9F39-EA5318B5C9A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, the preliminary agenda is now available at: = https://www.ietf.org/proceedings/94/agenda/agenda-94-lisp = and also reported hereafter. Please verify we did not miss anything. Note that we had to shorten some of the requests in order to have enough = time for rechartering discussion. ciao Luigi & Joel AGENDA Session 1/1 (90 Minutes) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Tuesday, November 4, 2015 1520-1650, Afternoon Session II, 90 Minutes Room: 301 - Administration =20 Halpern - Blue Sheets - Agenda Bashing - Status reports for WG drafts 10 Minutes (Cumulative Time: 10 Minutes)=20 o WG Documents Update - LCAF Draft Update - draft-ietf-lisp-lcaf-11=20 5 Minutes (Cumulative Time: 15 Minutes)=20 D. Farinacci - LISP-crypto - draft-ietf-lisp-crypto-02=20 15 minutes (Cumulative Time: 30 Minutes)=20 D. Farinacci o Rechartering Discussion - State of Affairs in Multicast Overlays RFC 6831 draft-farinacci-lisp-mr-signaling-06 draft-farinacci-lisp-signal-free-multicast-03 10 minutes (Cumulative Time: 40 Minutes) D. Farinacci=20 - NSH extension draft (draft-ermagan-nsh-00). 10 Minutes (Cumulative Time: 50 Minutes) V. Ermagan - LISP Subscription 10 Minutes (Cumulative Time: 60 Minutes) A. Rodriguez-Natal - Overflow Time/ Discussion 30 Minutes (Cumulative Time: 90 Minutes) --Apple-Mail=_567D164D-3492-4E25-9F39-EA5318B5C9A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

the= preliminary agenda is now available at: https://www.ietf.org/proceedings/94/agenda/agenda-94-lisp
and also reported hereafter.

Please verify we did not miss = anything.
Note that we had to shorten some of the = requests in order to have enough time for rechartering = discussion.

ciao

Luigi & Joel

AGENDA

Session 1/1 (90 = Minutes)
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

Tuesday, November 4, 2015
1520-1650, Afternoon Session II, 90 Minutes
Room:= 301

- Administration =         
   Halpern
   - = Blue Sheets
   - Agenda Bashing
   - Status reports for WG drafts
= 10 Minutes  (Cumulative Time: 10 = Minutes) 

o WG Documents Update

- LCAF Draft Update - = draft-ietf-lisp-lcaf-11 
5 Minutes  = (Cumulative Time: 15 Minutes) 
D. = Farinacci

- LISP-crypto - = draft-ietf-lisp-crypto-02 
15 = minutes = (Cumulative Time: 30 Minutes) 
D. = Farinacci


o Rechartering = Discussion

- State of Affairs in Multicast = Overlays
RFC 6831
= draft-farinacci-lisp-mr-signaling-06
= draft-farinacci-lisp-signal-free-multicast-03
10 = minutes = (Cumulative Time: 40 Minutes)
D. = Farinacci 

- NSH extension draft = (draft-ermagan-nsh-00).
10 Minutes  = (Cumulative Time: 50 Minutes)
V. = Ermagan

- LISP Subscription
= 10 Minutes  (Cumulative Time: 60 Minutes)
= A. Rodriguez-Natal

- Overflow Time/ = Discussion
       30 = Minutes   (Cumulative Time: 90 Minutes)

= --Apple-Mail=_567D164D-3492-4E25-9F39-EA5318B5C9A4-- From nobody Tue Oct 20 01:47:27 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCBE1A879A; Tue, 20 Oct 2015 01:47:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151020084725.10777.28272.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 01:47:25 -0700 Archived-At: Cc: draft-ietf-lisp-impact.all@ietf.org, lisp-chairs@ietf.org, draft-ietf-lisp-impact@ietf.org, lisp@ietf.org Subject: [lisp] Terry Manderson's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 08:47:25 -0000 Terry Manderson has entered the following ballot position for draft-ietf-lisp-impact-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for producing this document, and appreciate the honesty contained therein. I have two suggestions. >From the introduction "The main goal of LISP is to make the routing infrastructure.." please consider s/is/was/ given the tone of the rest of the document and the discussions underway regarding the WG. Section 2, second paragraph "Provider (interdomain) Aggregatable"; I think "interdomain" is superfluous here. Thanks Terry From nobody Wed Oct 21 09:42:43 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE391A870A; Wed, 21 Oct 2015 09:42:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021164242.13296.32356.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 09:42:42 -0700 Archived-At: Cc: draft-ietf-lisp-impact.all@ietf.org, lisp-chairs@ietf.org, draft-ietf-lisp-impact@ietf.org, lisp@ietf.org Subject: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 16:42:42 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-lisp-impact-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "RLOC" is spelled out on second use, but not on first use. "Addresses are semantically separated in two:" was a bit rough for me. Perhaps something like "Addresses have two components with different semantic meanings:"? In this text: Middle boxes/filters: because of encapsulation, the middle boxes may not understand the traffic, which can cause a firewall to drop legitimate packets. In addition, LISP allows triangular or even rectangular routing, so it is difficult to maintain a correct state even if the middle box understands LISP. Finally, filtering may also have problems because they may think only one host is generating the traffic (the ITR), as long as it is not de-encapsulated. To deal with LISP encapsulation, LISP aware firewalls that inspect inner LISP packets are proposed [lispfirewall]. I wonder if we're far enough along with RFC 7258/BCP 188 that we expect middleboxes may not understand traffic, whether it's encapsulated or not, because of encryption. Perhaps that's worth a thought, if not a mention. From nobody Wed Oct 21 09:52:32 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EFE1AC436; Wed, 21 Oct 2015 09:52:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021165230.18223.65896.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 09:52:30 -0700 Archived-At: Cc: draft-ietf-lisp-impact.all@ietf.org, lisp-chairs@ietf.org, draft-ietf-lisp-impact@ietf.org, lisp@ietf.org Subject: [lisp] Kathleen Moriarty's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 16:52:30 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-lisp-impact-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello, There was no follow up or changes (it seems) as a result of the SecDir review. It would be helpful to address the questions on the aim of this draft and how it applies to security for the user and impact of LISP. https://www.ietf.org/mail-archive/web/secdir/current/msg06103.html From nobody Wed Oct 21 13:41:40 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0411ACDE9; Wed, 21 Oct 2015 13:41:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021204139.7539.98645.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 13:41:39 -0700 Archived-At: Cc: draft-ietf-lisp-impact.all@ietf.org, lisp-chairs@ietf.org, draft-ietf-lisp-impact@ietf.org, lisp@ietf.org Subject: [lisp] Alia Atlas' Abstain on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 20:41:39 -0000 Alia Atlas has entered the following ballot position for draft-ietf-lisp-impact-04: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The opening of this draft "The Locator/Identifier Separation Protocol (LISP) relies on three principles to improve the scalability properties of Internet routing: address role separation, encapsulation, and mapping. The main goal of LISP is to make the routing infrastructure more scalable by reducing the number of prefixes announced in the Default Free Zone (DFZ)." is targeted at solving the Internet scalability issue for Internet routing. While the document goes into some details about rather large unknowns and issues observed, it does not have any indications or caveats up front that this is still experimental work - certainly as far as solving this Internet-scale problem. At a minimum, I think there need to be clear caveats on the experimental nature, on the aspects still to be understood, and on the complexity and concerns around the operational and security aspects. While LISP is a really neat idea and it's good to see how far work and research on it has progressed, this document reads much more like marketing than something discussing the engineering and operational trade-offs. 1) There is no discussion of what the "mapping system" is and I think that some of the discussion is assuming the use of BGP, but it's a bit hard to tell. At a minimum, it'd be good to clarify whether an Internet-scale deployment must use the same mapping system and what the trade-offs there are. 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the one with the highest priority and sends the encapsulated packet to this RLOC. If several such RLOCs exist, then the traffic is balanced proportionally to their weight among the RLOCs with the lowest priority value." It is unclear whether the "highest priority" means the lowest priority value. Please clarify because it incorrectly sounds like the highest priority RLOC is picked - unless there are multiple in which case load-balancing among the lowest priority value RLOCs is done. 3) Sec 5.1 "Proxies cause what is referred to as path stretch and make troubleshooting harder." This doesn't actually describe what path stretch is in any way. I can guess from the name, but that's not sufficient. 4) In Sec 5.2: "Deployment in the beta network has shown that LISP+ALT ([RFC6836], [CCR13]) was not easy to maintain and control, which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt]" Can you give a reference or indicate what the benefits of DDT are as compared to ALT in this context? From nobody Wed Oct 21 15:16:35 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A87C1B3295 for ; Wed, 21 Oct 2015 15:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDx5aa9gt02R for ; Wed, 21 Oct 2015 15:16:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9E11B31F8 for ; Wed, 21 Oct 2015 15:16:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZC91387; Wed, 21 Oct 2015 22:16:22 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 21 Oct 2015 23:16:21 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.220]) by SJCEML703-CHM.china.huawei.com ([169.254.5.225]) with mapi id 14.03.0235.001; Wed, 21 Oct 2015 15:16:19 -0700 From: Richard Li To: "Joel M. Halpern" , LISP mailing list list Thread-Topic: [lisp] looking for clarifications on rfc 6830 Thread-Index: AdEKnhay+P+VUKtLQsuYBYLz3YP9mwAPT92AAFw2xRA= Date: Wed, 21 Oct 2015 22:16:18 +0000 Message-ID: References: <56253E35.6070309@joelhalpern.com> In-Reply-To: <56253E35.6070309@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [lisp] looking for clarifications on rfc 6830 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 22:16:28 -0000 Thanks for your answers. Speaking about the Best-Match Prefixes, the RFC asks for returning all best= -matched prefixes. For the example in the RFC, The prefix 10.1.2.0/24, for = example, is NOT a best-match prefix, but the RFC still wants to return it. = This is exactly where the confusion comes from. After reading your explanation, it comes to my mind that it is better off t= o introduce a concept like "more specific" and "less-specific". 10.1.2.0/24 is "more specific" than 10.1.0.0/16, and 10.0.0.0/8 is "less-sp= ecific" than 10.1.0.0/16. Using "more specific", the RFC could be rephrased as something like this: I= t will return the best-match prefix and all prefixes that are more specific= than the best-match prefix. For the example in the spec, a Map-Request for EID 10.1.5.5 would cause a M= ap-Reply with a record count of 3 to be returned with mapping records for E= ID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24, since 10.1.0.0/16 is= the best-match prefix and the other two are more specific than the best-ma= tch prefix. Does the above make sense? Richard -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, October 19, 2015 12:02 PM To: Richard Li; LISP mailing list list Subject: Re: [lisp] looking for clarifications on rfc 6830 Thank you for reading RFC 6830 carefully. My understanding of the answers to your questions is in line below. Yours, Joel On 10/19/15 2:43 PM, Richard Li wrote: > Hi Folks, > > I have read RFC 6830. I have a few points I could not figure them out=20 > by myself. Appreciated if you could clarify them. > > 1.TTL > > Page 20, Section 5.3: > > The inner-header 'Time to Live' field (or 'Hop Limit' field, in the=20 > case of IPv6) SHOULD be copied from the outer-header 'Time to Live'=20 > field, when the Time to Live value of the outer header is less than=20 > the Time to Live value of the inner header. > > Isn't it always true that the TTL in outer header is less than or=20 > equal to TTL in the inner header. Since the ITR copies TTL from the=20 > inner header to the outer header, the ETR should find that TTL in the=20 > outer header can't be bigger than TTL in the inner header. the reason the comparison condition is needed is that the encapsulation con= dition of copying the TTL is only a SHOULD. If the ITR did something else,= for some reason, then the safety condition might not be met a priori. Sin= ce the ETR does not know exactly what the ITR did, it needs to check. > > 2.Fragment size: > > Page 21, Section 5.4.1 > > The size of the encapsulated fragments is then (S/2 + H), which is=20 > less than the ITR's estimate of the path MTU between the ITR and its=20 > correspondent ETR. > > Is this right? > > Look! H is a fixed number (=3D UDP header length + LISP header length),=20 > and S is also a fixed size (=3D L - H, where L is the path MTU). > > It looks to me that the fragment size should be less than (S/2+H). > > In order to achieve (S/2+H), does the spec actually suggest any=20 > padding so as to meet (S/2+H)? There is a bit of sloppy wording. The S in (S/2 + H) is not the maximum S = supportable without fragmentation, but the actual size packet received from= the site. When we revise this document, we should clean up the descriptio= n to make it more clear. > > 3.Best-Match Prefixes > > Page 35, Section 6.1.5: > > A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record=20 > count of 3 to be returned with mapping records for EID-Prefixes=20 > 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. > > Take a look at the EID prefixes in binary: > > 00001010.00000000.00000000.00000000 (10.0.0.0/8) > > 00001010.00000001.00000000.00000000 (10.1.0.0/16) > > 00001010.00000001.00000001.00000000 (10.1.1.0/24) > > 00001010.00000001.00000010.00000000 (10.1.2.0/24) > > 00001010.00000001.00000101.00000101 (10.1.5.5/32) > > Performing the best match of 10.1.5.5/32 against the EID prefix=20 > database, we will have only 10.1.0.0/16. I am not sure what your question is here. The reason the extra entries (be= yond 10.1.0.0/16 have to be returned is not that one of them matches the re= quest. Youa re correct, and the text agrees, that there is only one entry = matching 10.1.5.5/32. The reason the extra entries need to be returned is = that in the absence of those entries, later packets which match those other= entries will be misdirected. Is the text insufficiently clear about the reason for sending the additiona= l entries? If so, can you suggest text improvement for us to use in the next revision? > > Thanks, > > Richard > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Wed Oct 21 15:39:16 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298121B3309 for ; Wed, 21 Oct 2015 15:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqrB9PqA2E1f for ; Wed, 21 Oct 2015 15:39:11 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E391B3306 for ; Wed, 21 Oct 2015 15:39:11 -0700 (PDT) Received: by pabrc13 with SMTP id rc13so66871562pab.0 for ; Wed, 21 Oct 2015 15:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=73XGTCl99AwyrEU47zToL1auhicUr2Mj+5DcILRui7M=; b=JgGA59cVifaYO++qjnqL7sHu0CVQ/ODUhLZOXbH3kL5Zm+Ry6oiL9gnpFN6WZalvF/ yCnd4ZKHiVAmaOk5PvClvUSOZaKqSjo5TSQnGqJbtCoBFUseBt0lzuVjdREiC+aFBAq9 8resarO4PXDeZD1jaSAdsGGK+zSC/oiwbCS21X/apBSVHTleL2oX/K0m0ZL7AT9LWx1b zqS6D86xyVeL9Knj+z8QfnPHhEjJTltFczZQRVHQjjOKcxB2CFgfXpbiNzjpUOvRfmFp kqbbn7tAHQHARApth9ST2LWSK0NKxwm3X6iAFbEiIKd+0E/PRm9RU8EGLnRTzvnflMdG Dutw== X-Received: by 10.66.145.193 with SMTP id sw1mr13350432pab.74.1445467150915; Wed, 21 Oct 2015 15:39:10 -0700 (PDT) Received: from [172.31.99.196] ([4.15.125.155]) by smtp.gmail.com with ESMTPSA id y5sm10932002pbt.77.2015.10.21.15.39.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Oct 2015 15:39:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_46C6968C-5824-4C11-AB27-005C7709C5FC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: Date: Wed, 21 Oct 2015 15:39:11 -0700 Message-Id: <6EA9FAE1-8236-4610-B797-34F468BFDA3F@gmail.com> References: <56253E35.6070309@joelhalpern.com> To: Richard Li X-Mailer: Apple Mail (2.2104) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] looking for clarifications on rfc 6830 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 22:39:15 -0000 --Apple-Mail=_46C6968C-5824-4C11-AB27-005C7709C5FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Thanks for your answers. Let me respond to your comment. See questions inline and thanks for your = detailed review. > Speaking about the Best-Match Prefixes, the RFC asks for returning all = best-matched prefixes. For the example in the RFC, The prefix = 10.1.2.0/24, for example, is NOT a best-match prefix, but the RFC still = wants to return it. This is exactly where the confusion comes from. The RFC really implies a longest-match is looked up, but more than the = longest match is returned. > After reading your explanation, it comes to my mind that it is better = off to introduce a concept like "more specific" and "less-specific". >=20 > 10.1.2.0/24 is "more specific" than 10.1.0.0/16, and 10.0.0.0/8 is = "less-specific" than 10.1.0.0/16. Yes, that is how one would do a map-cache lookup for a local cache. For = entries in the mapping database the overlapping prefixes can be = registered from multiple places. > Using "more specific", the RFC could be rephrased as something like = this: It will return the best-match prefix and all prefixes that are = more specific than the best-match prefix. >=20 > For the example in the spec, a Map-Request for EID 10.1.5.5 would = cause a Map-Reply with a record count of 3 to be returned with mapping = records for EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24, = since 10.1.0.0/16 is the best-match prefix and the other two are more = specific than the best-match prefix. So let me explain the example in the spec: The longest match lookup for 10.1.1.1 can only be 10.1.1.0/24. If any = other lookup was required for 10.*.*.*, it would not match the = 10.1.1.0/24 entry. For example, a lookup for 10.1.7.7 would return = 10.1.0.0/16 and a lookup for 10.7.7.7 would return 10.0.0.0/8. This is = all traditional longest-match lookup rules. Now for 10.1.5.5, in the second example. The longest match for 10.1.5.5 = is 10.1.0.0/16. If that was the only entry returned, then a lookup for = 10.1.1.1 would not occur because the ITR had a map-cache entry for = 10.1.0.0/16. And, then of course, the packet would go to the wrong RLOCs = (the ones for 10.1.0.0/16 and not for 10.1.1.0/24.=20 So the *additional* entries returned are entries that are more specific = for 10.1.0.0/16. So that all of 10.1.0.0/16, 10.1.1.0/24, and = 10.1.2.0/24 are cached so when a packet is received by the ITR for = destination 10.1.1.1, the 10.1.1.0/24 entry is used. And if later, a packet was received by the ITR for destination 10.7.7.7, = none of those entries returned for the 10.1.5.5 lookup would match, so = the 10.0.0.0/8 entry would be returned. Does that make it more clear? Dino P.S. Coarseness is good for scale but not for correctness. ;-) >=20 > Does the above make sense? >=20 > Richard >=20 >=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 > Sent: Monday, October 19, 2015 12:02 PM > To: Richard Li; LISP mailing list list > Subject: Re: [lisp] looking for clarifications on rfc 6830 >=20 > Thank you for reading RFC 6830 carefully. > My understanding of the answers to your questions is in line below. > Yours, > Joel >=20 > On 10/19/15 2:43 PM, Richard Li wrote: >> Hi Folks, >>=20 >> I have read RFC 6830. I have a few points I could not figure them out=20= >> by myself. Appreciated if you could clarify them. >>=20 >> 1.TTL >>=20 >> Page 20, Section 5.3: >>=20 >> The inner-header 'Time to Live' field (or 'Hop Limit' field, in the=20= >> case of IPv6) SHOULD be copied from the outer-header 'Time to Live'=20= >> field, when the Time to Live value of the outer header is less than=20= >> the Time to Live value of the inner header. >>=20 >> Isn't it always true that the TTL in outer header is less than or=20 >> equal to TTL in the inner header. Since the ITR copies TTL from the=20= >> inner header to the outer header, the ETR should find that TTL in the=20= >> outer header can't be bigger than TTL in the inner header. >=20 > the reason the comparison condition is needed is that the = encapsulation condition of copying the TTL is only a SHOULD. If the ITR = did something else, for some reason, then the safety condition might not = be met a priori. Since the ETR does not know exactly what the ITR did, = it needs to check. >=20 >>=20 >> 2.Fragment size: >>=20 >> Page 21, Section 5.4.1 >>=20 >> The size of the encapsulated fragments is then (S/2 + H), which is=20 >> less than the ITR's estimate of the path MTU between the ITR and its=20= >> correspondent ETR. >>=20 >> Is this right? >>=20 >> Look! H is a fixed number (=3D UDP header length + LISP header = length),=20 >> and S is also a fixed size (=3D L - H, where L is the path MTU). >>=20 >> It looks to me that the fragment size should be less than (S/2+H). >>=20 >> In order to achieve (S/2+H), does the spec actually suggest any=20 >> padding so as to meet (S/2+H)? >=20 > There is a bit of sloppy wording. The S in (S/2 + H) is not the = maximum S supportable without fragmentation, but the actual size packet = received from the site. When we revise this document, we should clean = up the description to make it more clear. >=20 >>=20 >> 3.Best-Match Prefixes >>=20 >> Page 35, Section 6.1.5: >>=20 >> A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record=20= >> count of 3 to be returned with mapping records for EID-Prefixes=20 >> 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. >>=20 >> Take a look at the EID prefixes in binary: >>=20 >> 00001010.00000000.00000000.00000000 (10.0.0.0/8) >>=20 >> 00001010.00000001.00000000.00000000 (10.1.0.0/16) >>=20 >> 00001010.00000001.00000001.00000000 (10.1.1.0/24) >>=20 >> 00001010.00000001.00000010.00000000 (10.1.2.0/24) >>=20 >> 00001010.00000001.00000101.00000101 (10.1.5.5/32) >>=20 >> Performing the best match of 10.1.5.5/32 against the EID prefix=20 >> database, we will have only 10.1.0.0/16. >=20 > I am not sure what your question is here. The reason the extra = entries (beyond 10.1.0.0/16 have to be returned is not that one of them = matches the request. Youa re correct, and the text agrees, that there = is only one entry matching 10.1.5.5/32. The reason the extra entries = need to be returned is that in the absence of those entries, later = packets which match those other entries will be misdirected. > Is the text insufficiently clear about the reason for sending the = additional entries? > If so, can you suggest text improvement for us to use in the next = revision? >=20 >>=20 >> Thanks, >>=20 >> Richard >>=20 >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_46C6968C-5824-4C11-AB27-005C7709C5FC Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_C0700171-CEA8-4D57-AEEF-49549F7E6719" --Apple-Mail=_C0700171-CEA8-4D57-AEEF-49549F7E6719 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thanks for your answers.

Let me respond to your comment. See = questions inline and thanks for your detailed review.

Speaking about the = Best-Match Prefixes, the RFC asks for returning all best-matched = prefixes. For the example in the RFC, The prefix 10.1.2.0/24, for = example, is NOT a best-match prefix, but the RFC still wants to = return it. This is exactly where the confusion comes from.

The RFC = really implies a longest-match is looked up, but more than the longest = match is returned.

After reading your explanation, it comes to my = mind that it is better off to introduce a concept like = "more specific" and "less-specific".

10.1.2.0/24 is "more specific" than 10.1.0.0/16, and = 10.0.0.0/8 is "less-specific" than 10.1.0.0/16.

Yes, that = is how one would do a map-cache lookup for a local cache. For entries in = the mapping database the overlapping prefixes can be registered from = multiple places.

Using "more specific", the RFC could be = rephrased as something like this: It will return the = best-match prefix and all prefixes that are more specific than the = best-match prefix.

For the example in the = spec, a Map-Request for EID 10.1.5.5 would cause a Map-Reply with a = record count of 3 to be returned with mapping records for = EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24, = since 10.1.0.0/16 is the best-match prefix and the other two are = more specific than the best-match prefix.

So let me explain the example in the = spec:


The longest match lookup for 10.1.1.1 can only be = 10.1.1.0/24. If any other lookup was required for 10.*.*.*, it would not = match the 10.1.1.0/24 entry. For example, a lookup for 10.1.7.7 would = return 10.1.0.0/16 and a lookup for 10.7.7.7 would return 10.0.0.0/8. = This is all traditional longest-match lookup rules.

Now for 10.1.5.5, in the = second example. The longest match for 10.1.5.5 is 10.1.0.0/16. If that = was the only entry returned, then a lookup for 10.1.1.1 would not occur = because the ITR had a map-cache entry for 10.1.0.0/16. And, then of = course, the packet would go to the wrong RLOCs (the ones for 10.1.0.0/16 = and not for 10.1.1.0/24. 

So the *additional* entries returned = are entries that are more specific for 10.1.0.0/16. So that all of = 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24 are cached so when a packet is = received by the ITR for destination 10.1.1.1, the 10.1.1.0/24 entry is = used.

And if = later, a packet was received by the ITR for destination 10.7.7.7, none = of those entries returned for the 10.1.5.5 lookup would match, so the = 10.0.0.0/8 entry would be returned.

Does that make it more clear?

Dino

P.S. Coarseness is good = for scale but not for correctness.  ;-)



Does the above make sense?

Richard


-----Original Message-----
From: Joel M. = Halpern [mailto:jmh@joelhalpern.com] 
Sent: = Monday, October 19, 2015 12:02 PM
To: Richard Li; LISP = mailing list list
Subject: Re: [lisp] looking for = clarifications on rfc 6830

Thank you for = reading RFC 6830 carefully.
My understanding of the = answers to your questions is in line below.
Yours,
Joel

On 10/19/15 2:43 PM, = Richard Li wrote:
Hi = Folks,

I have read RFC 6830. I have a few = points I could not figure them out 
by myself. = Appreciated if you could clarify them.

1.TTL

Page 20, Section 5.3:

The inner-header 'Time to Live' field (or 'Hop = Limit' field, in the 
case of IPv6) SHOULD be copied = from the outer-header 'Time to Live' 
field, when the = Time to Live value of the outer header is less than 
the Time to Live value of the inner header.

Isn't it always true that the TTL in outer header is less = than or 
equal to TTL in the inner header. Since the = ITR copies TTL from the 
inner header to the outer = header, the ETR should find that TTL in the 
outer = header can't be bigger than TTL in the inner header.

the reason the comparison = condition is needed is that the encapsulation condition of copying the = TTL is only a SHOULD.  If the ITR did something else, for some = reason, then the safety condition might not be met a priori. =  Since the ETR does not know exactly what the ITR did, it needs to = check.


2.Fragment size:

Page 21, Section 5.4.1

The size = of the encapsulated fragments is then (S/2 + H), which is 
less than the ITR's estimate of the path MTU between the ITR = and its 
correspondent ETR.

Is this right?

Look! H is a = fixed number (=3D UDP header length + LISP header length), 
and S is also a fixed size (=3D L - H, where L is the path = MTU).

It looks to me that the fragment size = should be less than (S/2+H).

In order to = achieve (S/2+H), does the spec actually suggest any 
padding so as to meet (S/2+H)?

There is a bit of sloppy wording.  The S in (S/2 + H) is = not the maximum S supportable without fragmentation, but the actual = size packet received from the site.  When we revise this document, = we should clean up the description to make it more clear.


3.Best-Match Prefixes

Page 35, = Section 6.1.5:

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

Take a look at the EID prefixes in binary:

00001010.00000000.00000000.00000000 (10.0.0.0/8)

00001010.00000001.00000000.00000000 = (10.1.0.0/16)

00001010.00000001.00000001.00000000 (10.1.1.0/24)

00001010.00000001.00000010.00000000 = (10.1.2.0/24)

00001010.00000001.00000101.00000101 (10.1.5.5/32)

Performing the best match of 10.1.5.5/32 = against the EID prefix 
database, we will have only = 10.1.0.0/16.

I am not sure = what your question is here.  The reason the extra entries (beyond = 10.1.0.0/16 have to be returned is not that one of them matches the = request.  Youa re correct, and the text agrees, that there = is only one entry matching 10.1.5.5/32.  The reason the extra = entries need to be returned is that in the absence of those = entries, later packets which match those other entries will be = misdirected.
Is the text insufficiently clear about the = reason for sending the additional entries?
If so, can you = suggest text improvement for us to use in the next revision?


Thanks,

Richard



_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

= --Apple-Mail=_C0700171-CEA8-4D57-AEEF-49549F7E6719 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-9.png Content-Type: image/png; name="PastedGraphic-9.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAAA/oAAAHaCAYAAACw1TK+AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAW JQAAFiUBSVIk8AAAQABJREFUeAHsfQl8TWf6/zcjkTAStYQhprFWQiOqtVdItLULWlVrRymmY2tn au2+UZ0poqW01BLU9iuiolNNaqmlSEkQqpaYogSRG+WmSf/n/571nnPuufeec+65N4v3fD7Jfdfn fZ7v+7z7FsCQD/SjCFAEKAIUAYoARYAiQBGgCFAEKAIUAYoARaBcIPCnciEFFYIiQBGgCFAEKAIU AYoARYAiQBGgCFAEKAIUAQ4BOtCnikARoAhQBCgCFAGKAEWAIkARoAhQBCgCFIFyhAAd6JejzKSi UAQoAhQBigBFgCJAEaAIUAQoAhQBigBFgA70qQ5QBCgCFAGKAEWAIkARoAhQBCgCFAGKAEWgHCFA B/rlKDOpKBQBigBFgCJAEaAIUAQoAhQBigBFgCJAEaADfaoDFAGKAEWAIkARoAhQBCgCFAGKAEWA IkARKEcI0IF+OcpMKgpFgCJAEaAIUAQoAhQBigBFgCJAEaAIUAToQJ/qAEWAIkARoAhQBCgCFAGK AEWAIkARoAhQBMoRAnSgX44yk4pCEaAIUAQoAhQBigBFgCJAEaAIUAQoAhQBOtCnOkARoAhQBCgC FAGKAEWAIkARoAhQBCgCFIFyhAAd6JejzKSiUAQoAhQBigBFgCJAEaAIUAQoAhQBigBFgA70qQ5Q BCgCFAGKAEWAIkARoAhQBCgCFAGKAEWgHCFAB/rlKDOpKBQBigBFgCJAEaAIUAQoAhQBigBFgCJA EaADfaoDFAGKAEWAIkARoAhQBCgCFAGKAEWAIkARKEcI0IF+OcpMKgpFgCJAEaAIUAQoAhQBigBF gCJAEaAIUAToQJ/qAEWAIkARoAhQBCgCFAGKAEWAIkARoAhQBMoRAnSgX44yk4pCEaAIUAQoAhQB igBFgCJAEaAIUAQoAhQBOtCnOkARoAhQBCgCFAGKAEWAIkARoAhQBCgCFIFyhAAd6JejzKSiUAQo AhQBigBFgCJAEaAIUAQoAhQBigBFgA70qQ5QBCgCFAGKAEWAIkARoAhQBCgCFAGKAEWgHCFAB/rl KDOpKBQBigBFgCJAEaAIUAQoAhQBigBFgCJAEaADfaoDFAGKAEWAIkARoAhQBCgCFAGKAEWAIkAR KEcI0IF+OcpMKgpFgCJAEaAIUAQoAhQBigBFgCJAEaAIUAToQJ/qAEWAIkARoAhQBCgCFAGKAEWA IkARoAhQBMoRAnSgX44yk4pCEaAIUAQoAhQBigBFgCJAEaAIUAQoAhQBOtCnOkARoAhQBCgCFAGK AEWAIkARoAhQBCgCFIFyhAAd6JejzKSiUAQoAhQBigBFgCJAEaAIUAQoAhQBigBFILBkIbDj8tlL sCEQEZGRCC1hbkoWC5q6PxGw513CVVsxKofVRni1EH8mXW7TsudexqUbd4EgXsRK1SNQ1wO2NB88 qUMxcnNywMJao34jhJcyVfVt/tH2wZN2GPUvuPwzzvxqQ1CQUEhRRMprHURH1SGtcPn7fKuf5Q8v KpF5BGj7Zx47GpMiQBHwHQIBDPlMk7f/jLVLNuF/9kpoN2ws4uoGuyZVfAlrFyZzYR8e9By6RlYB bu9H19AOSCOx3jtyC9NbVXUdn/r4DgGSN5sWbsIltynYUbFOF4we2IbrEJ7esQxbfroN3eOOik0x fFw3VCNpXNmTjFX7byJEHTk4HC07dESHmPt93Om04dOEqhiTDjSd/QNOTW3tVnLq6QmBa1g74zkM mfWVIqBnbGk+KADTshQeRteQ1lwdOWv/LUxrV5rqSB/nH20ftDTCK7ejH9THQ1NylDSiF+DmyfFc 3az0KOs2H+unv+Ex0U5zLBZfQ8rStThfGOCaY3swOo4cjYfDKwhhinF86ypsv1CgbONJG928dVt0 bNVQ6e6asn4fN/IF12yA1m07oVWj+/TT81tI2v75DWqaEEWAImAYAe8m8Ytz8dmkaVwndFREd8QN fcAlA4UX0zCEhGW/WXHPkoE+MZBVhQjOBagk/NKfEkDAfgULJ03i8tFt6qRDOIgM9KvhJr6ZMgpT s9yGVnnGInZoN3QOBX49ugZTp6aq/GXWB8dh5+YP0LURmQzy8dckRFzZ8nFC5Zj88RUTFIP8mPh4 BKSno02tyrqlpvngGiqxjgyp6DpMSfvozb/jKwYh5m/rgT4rYNs6AqQ6cP3R9sE1NiZ9wmImYdiw U6hZE0ibtwSZLJ3GwT6eWDXJrIXR9OqnhUlaT8pwOy2wYD+LeeMme2zfZ8U9Qwb64kTiHeyf9xym kslw7W8Eko/MxtBWdbS9zbjqkK/50AXYsGg8ot1WHGYSNx+Htn/msaMxKQIUAd8j4N1AP7AqmhAe 2RX5q9fvuOf2jk3yr3WfOGssOVFDSSJAxrriYAKIxZjJbQGn7LwDJuIBYUImDC1HT8CwE4WQD+Wu HViCzVzPMRbDxrRV+P3GPIJIYTYnKDhMkJZNK54PdycX85as5t2Pf4LHGt/BMdsKtPBJg14RjbuP QjzOoXlNuQQlmQllNW0b9q8gAzf2G7oEvyx/HhG6axWaDzxwZfW/ifwTVxXzC1FcVsUuw3w37P4i VnXnBTjd8hai2EmX/DIskFvWTeinW3ol7Gm4nRb4DQlHvzFD0Rh/5hy02uk7pL2PraPcYic106RP 8Pz0p1ATF3Fw1qfChMFKDHt4JX5YfxrzB7pe4DGEmEK+BEye3gK4Wwl3ru/DkuRdHKkTqyegmS0Y N7c+X0p2oND2z1Ae08AUAYqA/xFgt+6b//KZxYlgt/4zzSamMEVuCOVsfZkLB/RnDtuEgPZDzHAS l40/9/BtN7Gpl08RkOVDr0XHTSd1avnTfB73WcHcdUMla/Eg7XB3zzNJw3h9YHXCG17cJE+9LEWg iFkh1AGDl522lDIlRhAgZbOfWEceuVXmIdFbR3CCyuol2j5Yn/VSPRy3hBGbZOtToRQtQ0BWHrxp G/WVwXypXie7b2TteT6TsfF1oS/HttUJzM5rFknoRr6Cs19JfUW2b7Aws7T0F2n7Z1HuUzIUAYqA jxDQvfZGKleNrzKaPNIB2LIPJ49eAbkvituKWUAu5SooYoMHoXrdcO4sl+2KsM+7+cP4i8YqbVhF G86lrcOcpFX4yXYDN66Ho+eLb2HGyI5utnfa8ePWz7F42XrsP/cn1Ai4DqZFV7wwfjIGtr3fmV/2 DNjSjbhUeB+6DB+A4IMbMPcTI+k5k/TkUpCbje+/2YXdu/bi5JnL5OJB9gtDi/ieGDBwAOKiyB5K 9VcCfIosBBRyGSdaDf0WyVbrWF1Qrg9okCKreopwIfUxYe42fJbcm9tS6g0vzqmRM4c71uH7X4sg 3SRRWIhqsX2R2M7D9sOCC0hZsxIb1qXj2PU/oXrDUNSr3QCPtE/AE72eQHS4RNE5WbMu5Fxl+vpl WLb+a2Syul2TQWhES/RIHIAnez+qfSmb/QI2LZmLj5d+h7AWLWDLzETd+NEY/+JItGPvxFB/ZvVM iHed5HAwbmHLFp7w2g/nonMA2Q1CcGX/qrcZiIFO2JrPh9tnd2HenP9gw4Ec1KhRA3Xb9ceLY/vi 7qE0nLgRgNg+g9FOfk8I4XNrcgou2Cqhy+BhaCGdP2X5JXXHxrXYc/l3NIl/Ej1inMthce5hLF27 D4XBDTB8bB8UHFyPxR+txv5jBWAa1kPLZq0xaDzBtq4aW4P1kpAvTvK1fQYvPRuF2oK/1z9EP9Ys 2YrrJNfaDB6Ndgo8VNQJdimkrmTP9bZMJPevRIo6bjT/+LO+aVd+RzAhcXqlsPsjZQWSFv8/VAXR FfKxKtOR8OQ4I6zkx1z7oKSh22akHMlwavLECPSI0jhDXJCN5Z9/Q+p+gvtTBPe66h1t5vTFvH7q RkIK6F07VgtdnuqAKymLsGjdD7DduAGmfnuM+NcUjOzUUEpDMgj1y6VCg/E4Akb1k0SS0jPXL3Aq t57qJUlQ8wZv2kbv2ukwPPTkG7i84zfU7f5vIkAa5q05iq6TWpoXRiOmWr4qDXviw7TXsCrhLS50 4W/O+4HMlweD5U/QF/+0fzakL/8cWaQeDq7SCs8OfdSpX3UuLRnbjv9GcAlBz5HPorFT/9qgfGJ+ lES/R0xb56+pekknbRqMIlBuEPB2AkFaFWj+DvMLR+wq84GwAkU2gzG7brKORUza2x3I7C+ZAe4j Wz2QzeByflI8x6ouJqXIZpNl3NpOMm/Hy8Kp4vaene4cr+AQk6AK55Suq/RkSes35jMLYlzzyKY9 MVljBd3ffMrywZuVAkkXPKwQuQ1XfFSaue8970f9UHsMeUOml4486TT7B7cxiy9/41Znms466ja+ Gc+Cs19Kq7hO+kl0RitNe85XbuPM2n7OmRWzelawjyGbKvny7O73jUPOaTLm8iH34Mce0yOX1SnT k8nn5MfkM0uE+sOVDhRk/EdIM4GZPKOPZvrkwkFlmmbqJULh8p4PNenL83+utyv6JN/E+m/KzitK vtW23P9KeazEzmj+aYeXyyWaX1fnn6xeEsM4/VpaX5MNFEbLUdEZZqxYBkZv0tzVlrPxH1LervrZ rkTapL6wREzppyx1t/WwLBxDyoqv2rHe8/Y6YyYrt075LWCtGY/jWVvfXJVxLoqO9Fz1Q0zVSwps DVhk5cH37bRsRV+rPS8+4dB7LX8DYklBZfJptf32U59K5UjL31R5MFP+/Nz+HUxqJ8k9YbOyHbef /ULyQ9wC5qoEpmAwIx+JWhL9HjXrnu0m6yXPhGkIikC5QuBPpCH16qvfug0f/8QR/K+AGG+fxfes C1lRBI4h4xw703gHZw7vY13xaNeWrlfoySVs63dn4EDqQpAOKf/NfwU7cv4QbcLvNSxIbIZX03lr 8+fnYOeRTGTu3owX43m3bdPi8Xrqr8p4ijNgxEt3ekoyxm2xmPT+YqTuPoDM7EykbZgryZc07EFs VstXYnwCX32xGTvS0rBjxw7l39atOJBz27jo7mKI9/7IwtzO/B6rBPstmbv3xjD0+XY9Pl+9ARs2 zJPwr+r2Mj47tkx5XDiTSM4pzl6DA2SV/MDub7Hh89kgW6qBgN+9Z01O4dZ+JDbqj82CW+dJSdjN 6vaRXVgzfyLv6pTmJbwV2UuK0+et5RyfaavfkChP79kf2y+rypFZPavSFB+RZfwt5C81NRlj2aLO fp3fwZbUVM59y5YN2DWoPues/GciH24fxvNt/yGRmfj5DmRnH8HiyZ0kN9bgdFmdTD4nPxJePIPq UgeCxFVssmr1XgqXVp/pSUTGLSQv3pR0iPPg/pmsl8jt8i90ekkiM3V1GpFvP5LGRklulhhIvvUT 6sf9h8+6JXnr3CH+ojb0R5em8oJqNP/CMODAdmzgdGUL5gwXk+2PZZKuEF3akIphTdU7I8Swwq/P 62sT5SiwMcYm9eAZ/CwZh9k2UPHZsGPVx7xL3AL0aiTqFOtkUl9E+ob1U4xo9tf7dmzzgVOknV7F 152EjW2TH8VHGapLAmTlluOU5LuueFxgo/pJImmkp6sfYrZe4vj07p9f22ktVivUQ6tEwYP02c7b tQJZ63b1p58kgl3bNpDMksFweTBZ/vzc/rWZ8BXIEVnuW9CP9A3E/mLxz3ir0TOC+P2xf/N41JLA YA0m5SO73fze71HwbdRisF4ySp6GpwiUdQS8nbawn1opzCgmcKv3xac+cswwktn3wYvYc7s3mDnC 6tko+Tle2Qwums9kTsoOdtuzPpPoKFeUGCbv4LuS3+hl6lXfq9K9AcBM5rxcQJPpyUkYMxcxFzIz mWtalxdc3iatro1KVp1t9jef8vTE1SmNX6fVSxUYeleIpHCdP2DO373L2Gw2xnbzGpOVulDChJQr Zml2gSoFq6xFzFrhXLnWyoAjFccdFIj6wuEsmfKZazdlSiu5mzccfL+HpNsT16v0gpAtvrSP2b7/ siKB3D2O8tB79l6l30FxVRpMJ5Ufe/6bjLv49AyUP0UCZN+MeEbf+CqTvnw4u/FvEiZTt1+UJX+X 2TjmAcnPacVbJp+TH1mlFPl2pQMFWfK6LJZZeiRXljYx3r3K/HzJoaNm6yW5fG8oVtrzmeWyOyuc ZVCyo8cm6RdZ/eE2W7GRivgyePeuo6LKSBL0kJRRp1UiKSF9+ScFJwZ954OFGLL8M9I+yNMzYjZb joplq2pTtqt2SuRuk3ZGjEpWrsaZ1RdRJqP6KcYTf6V62OOKrAXtGMY57uZhGZDvlBq9TbmqL893 I/FEwaRfnfopT89APSgvt4bqJYk/gwY5n2K9rfFrTTvtqB+hqR+yXZrk3qX9VlzyIJNP3ZbkZq1T 9A20zugbLQ/elj8+93zf/nHpkF0EUluNd7g6OW16I0fbp94NRSKZl8///R6DJUEIbrJeMpcYjUUR KLMIeL2iH1w/WpidJ+dkr/6GS8cPK+Y+1u45geI//od96bzzgy0c97vLA054fRSiZYe6g6MfAdkS yX3fHzwvC2rHt0tnCvZYPNMtGvaCPOTlCX/2MHQePl7wP4mLebKoMqP+9GSRDBsDERkTg3DuJoRi FOTlIlfg016lOboLq2un3bxY4B8+lYK1ILsxnP5IkG715Ct7yjimbLteRoNKlRAWFoaw6rUQ0+MF afX8jc2n8VyUhxU+U4myke7A8Dp8k1xccDoWGIbwajKlNc2PGPECtojPDsYtwRsatxlXqNsePVTn 3n89uUcg0B8vj+koEuN+a7b5G5IEPduz/SRcFAeY1zMHkupzlQpGNC168sGGvauWC7FnYkKPv8oo haD3Sy/L7L4z9lq0HM+1Up3jD6mFRtL5fLP1kly+dzC6619kQoThmakfyezeGxt2eJQnsvsQzgmr zz/MTeDKYKVWnwj6YUPWt6lcuE4J7VWrRHIe9OSfPDwgPx9cpPRyazOvn27JKjzNlqMKDeMxJ4Yn NSf5O7Ie5vhOf7NJ2BmRgMFPyFchzeqLg7bc5Fk/5aGNmr1vx3otGouH5WeH6zyGV6Y34hn5bBtO ykGTsWc2Hk/CuH7q1zN5uS2ZesmpjWbbbSK45e20LD8cxkCE13LUxWRThPDZcTYrAxlZWcjy9JeR gVMudgl+9feh5F6U4Rg+fDj6dQ1AeMwgoW9AkiFPcw6L4V8QEFNV/3ouD1aVP1+3f4JkVdojKUPY GYRXUDsgAAmzznKevef9gMnt1H0zi+TzS79HnXt67d7XS3pTouEoAmUZAS8v4yOiB9fEw6R14Z5V u3MD2Rn8oGP2htU4MXAoVq05iZz59wvb9RPwgOoJFxG86CjlpiNUaIAOicBi4aIvMRzIEO3GVdF2 DI9FuBtofYmLV0lFXM35AWr96YlpmfwlF5psWjQXb01NEjp8znT+GuxoJtW+fuNTSJisbiLF4ot1 1DJ5tE+cg9cTLXqyx2Ni7gJURqTYN0+ZgAZBEzB0+hz0bBeDqAZN0CSmketjKO7IuvK7fR0nBb/e A1rrfj7oVr6w9TWuBx6qpiZeHfHPDALS15FjBvlwNbjyt56pudRjbzaxndPFdMH1W4OsdEjHPfTQ MRNmxOPRHqJ5Xy81mxjrLF+TtpbKVzOqNXfkIA0rcezSp3g46hZ2rdpPjloR8TK/RFbeeMSF/YJ9 Qr3btaMwGPMgva+9/aGf5stRLfSdPhJThnwOrPkUP3z0DOK4cngT//2UuLHfkOfRMZw38v+91xc5 Nc/6KQ9twuxlO/ZY6yZOiUbGxBE3drByFXfYikmjKTcbzykxnQ5m9Kwk6qXS0E4Xab3LePtHjGnR wTEo94A72X2AU1Nba4Q6huQlx5zcO09ageWzR3hsdz2XB2vLnxOjPnC476EXkLF4N1qNJW25+PVZ gpWTtPDzRj4/93tEWcz8elkvmUmSxqEIlDUEvB/oozruZwdD5P30vTvTceME23AnoHPnLqhMVhJX pR/Bnl0VhI54VdQOraCJUWGR03KpZjjW0dEfiCUrz4yLcORcc2Ys8WNnXJ0H+kbSc5GAZ+eCYxgX 1hKL5SGFWXcWMHLcm/sK3Nx07xc+5fz509z5A5zcMIq8z1sM26+ZWDbpMbyXTvIsqRumdb+I2YrV W38yJqYViG5vncTbxxz3QayeNQWrRW9yfnlz9kokWrXzgMz3iItemmcQpXTlhpvITiUDNT3frn3c Km4tMRFZnLKgZw2iG8Cpwir4xeeDfGAEGkXIz1bLgJMZva2XatSt7SyfjL4lxprNEE8G9Wmk7tmX dRXP1TuFHVki5TSkZeUjrkmWUGfFonW0YnQqBvT7r+/107ty1PTxJ8lcyeekVk/Dxt3/Q1ziX/HH xV2YmM5DNWVYF1m7xbt5qy+OTNCnn47wBk0WtGMIcG7fa0U9KDHicqrbbDyJsjGDGT0ruXrJmGzW hia7frbvkEhKE8hBQYiQXD0bmri6I6f5S1j9Xnty5xO/Yl6xSh08+EhrREk7qNzR1lcerCt/7nix 1u+hZycBsoH+lBlDXC4ImJfPz/0esxBZUS+ZTZvGowiUIQSc+s3GeQ9DTNce5Im9VFw+uw+/sitB zRPQMLwuihM6kJXEL7Fzbzi/YBRH3DUGGcbTFGL0eQl7t3qe3TVN38uIx9fOkgb5o+d9jTefi0Pd ULH6tWFlv6p4Vlg58zKpshk9rCrqhVfjBrfh4V3xbupR3AjhJ0be7/kehtxdhBYiXCUlYWg0Xkkr woiMfdh76Ecc2ksuZkveKnDzJfpFv4wzRYvQ2IKSxC63i3d5/ZB9FXDajqcFQmVUEXtWVbX8iVuw OBnWAFVd9qhdxC1FzrZruc7chNYzueJdjHybMzltF5IrbE9Wry5aWi9ZnWG10bEXWaXPJJemZp/F uTp7udW3mPh4ZKWnY913xzHiD2lfCZo5PQWnjVDZd/WyHNXshH8mgqvPFyxNx5zEEfiZPOfJf/3x 9KPyIxkqtLzWF4P6qUqevHHo9rOiHQsOcq4g7bfy3abLepqN55GwhQGsrZcsZMynpApw9ZyQgLxf F/wIVjIM2S/k3ddr/HMY0re5SSIGy4PX5c8km4ajFePrN19WxJozehaeP/qO+/6HGfn82e9RSKTf YkW9pD81GpIiUHYR8PqMPit65Zp8J+a7JUu4TmN019bcuc5GrclAn3yr5y3ht63Xq2nJipV0nI/0 1J3XCbgkS8E/O05nZ/B8DFmLBZOekA3yiXPheey8lwf5LDLqfl5wLF7f8S8eM3yC2Zt+Eswl/ROI +1vFYcjYSZi7aguKbOexZnovic9vjv1mDYOBlaWt20d/uqCTZghiOnXnw6bk4KpTgSjG+aM/8v59 olBP72BVZ+r+CCaW9z3rDpN7hJXfH1dPuVnRdwySnQYMheeQJqy2Kimat4l8sjMITtnghqwYb8/2 g853KNz8hbxdYuUXiKjO/TmCp47sxKZNLAixeHvhfLxNVvpPpf8fNu7k6y12S3I9K5OW0/IwuJQH 9Y/Z23IUhi6j/sGzmrICP+ReRvoXwkB/0nOI1ZjgFvPdqL5YjkfKXje3plvTjuX8ctOJ7f8dPyS5 sfNoWp/ZeFq0rHYT8894vWQ1J/6n98e5vZiSJaT7QF2EWcyC8ftejDMg5l+Jlz+drF/8ega6z/pe GfrEu0j85zbN9sZ7+cz3e+yXM2WvNqXh54I/lHx7bbOmXvKaDUqAIlAGELBkoB8R87BC1McSojl7 regO3Eq+6Nm7TZS0NVl0M/5LLtvr/zQfbfcEfJnpepBVbKS3bZwRjzGqVBLvHQh2muC4+N9P3QxQ PJL2WQDGzX0BPktURrhOt39ghmBfO2wusqXWShaohI2BofXx9JAEiQsz2z2lyHJDSEN0HsY7ZM9+ nzyHJ/d0mO12pWLXaNJG8HwXGw+rZk9uH8KyeWd4/9BQ9iWpMvaFoUNPcscA+518GdtU5X3/F27W joqKpB0SRzKVUwS3T+6WniPkiXv732y9FIbW7I4o9tv9Jfbn8kbx/+n/ruQnSUUHC37Zepn7tr6L KfPInSrNe6N9VAxZ6e8IfPchpr63jfPu+mhzp3rL++QF/Tx3DXe9J2YpBW/L0f3xQ6WLaV9/6QV8 JkwkzXqmkwaOZvXFOpHrt2bPyLPfL8hzNdImvla0Y+8vSldcUghcwlef8Rc+Qr4izPHj+Gc2noOC r0xe1EsWsORNOx0k7vCqGqyvPVCHyzuGWaOfkaRYOLGb7s1OUqQSN5R8+TMCwR8Xv0Sf7h/wUcgz neTFFJAXVDj7yaQ+eGnL/1TkrJfPSL8ne9NY9OjRQ/jrio0nbqv4895qRb3kPReUAkWg9CNgyUC/ Uo36igF9mwf5AW6FujHoKsOg+QM1ZDbzxqaJk6U3rEfF9sUnaaelTkSxPQ+nDm7BzH4BiP/4qPlE vI5JtioG/MpTWTMA/047L1AkM5FbZyGy78dep+ALAl/tTcdBchvuwYMHnf72HDwtDZx8kTZPsz7G bhVWxsiq/n+sWtUvtqOgoID82VFsvyltO8y3/wa75FdAzHLJbFgxPBrPJ21CVs51ada8OC8bC9// TAiYgJhGVi1PhqDHS/8R6KahV8QAbMi4IqRLXm3IzcaKcQFoOV9YoRdC1nkoQSoP09uPxJZTtzgf ls8P+naQBrSzxj5e8h0yCWv9+fDggOFS/cKW99UHL8JOyvkPKyai09TtAgoaPyH3oZngvHTYPyVc bp3ajOGt/qkRwTsns/VSs16DhYRJng98F5l5/OrHxb0LEfW39d4xpRGbrZdflLl3evoxbgdWTM+e MlegTau6CjtnMZF/ciJBoXV464lXMHP+f3FZfC0lr0AqX/Lw/jR7XY6qPIRhY3iOv0veIkzQjEPi I9r1g1l9sQqTSjXE9jgNXYb+G0dyLuPy5Rzk5ORK7SnYKQor2rGUZzFq/vdC+3ETKe8Mwqvkngj2 GzzmCU7/eJvqv9F4XuqnKnW3VtP1kluq+jyNtdM20ifi2/OMjIM4cPQKn8i5Y0g/yLf1e/Zk4JKr SfWUY/j+1FmcyjqATUnTEFC9JV4Vd0PpuAFfn0T+D1Ui5c+Ufp7Ba5EDhPokATs3jufO5beZ8qn0 2seCfn2wOUe5am5ePu/7PUHBkYoMDXG+Jkvhb9xiUb1kPGEagyJQ9hCw5GFA8v5pP+k913HMSek5 Zvada+GdbuI/9/BtZXKyeM5vRDve8tR65zpnx2sMQdvtX6fZP1iWnpKQPpv91KdK/sjNgWR3rNKN 2J3k8wIXfZypQsnSc49prNv3cvW+y+wxXPEJZqyE0zjmmAVP1Uvvgkt0nfOBlf3ReT/KwMlnlsQr w5EnjZT5N3oTeUneyo+8TzynpzINFc9Oek2SPyi+e64KK+XnkBWOd9NFdmX5brT8iSQY8h794kQe Iyc9dgSSTObygWGy1ox0iwkrp7MMJN7i7h7jueLb8S6z/neiTdVLRIN2zHC8iSzlmSovteSTgDVk UNbLs8Q3mPP2uajHHcTN5p9EgaRB9sJo5omTfJbop5SyLoOpciSjnLvnXYVsUW+my3ydjeb0hadj Rj+VHCj1wKF3CYp63pt2bLiLvHakNZM5I/UXBO5IvpuKR6Kb0k8v9MxsvaTMB502GZ8O/LTKkqqd Jm+wuypzcjpSPcCx46jX5WHk5rhpa7n33HVy7zmYTD5XdbI7ImbKgzflj+fFgZMeno3r511m64zG Up0yZfsVJQSXt8ny1rksmZPP+35P1vKnJZ5ZnZkrtjFK7r2yma6XvEqVRqYIlD0ELFnRR3BD9Egk xZn9hnRGA+nenRA82GUk705uKG/X8M+CWfwJkrbyhwVKkURPBAvnGkPDnDcc39/tTeSS56DGkpv9 tb4ufcdiwuPscwDyz3x6cip6zcFNRyNnz8fSait7zT6/iBGLeal7sGbyAxypUKft8v7lE2QDn8YR Ug0x26Oyc1Y4wklbAh1OmiZP4So0w4trRL35BGlHVdvRNYm6dwwK0yeh8qnDimjcb5S0msymkCk+ lUDMk8gFizc/HWDxKnkg4l/+Cme/XSpsA1bJFdMPIzs3VDmS1dcJW5Gx+g0Fr2KgIbMJn6tHaNzO 68h3o+VPpM3+iuW0dlhlubOm2Vw+AA8OXkYwWegoSyz1Li9hw7dbQCaFXH4PjlmNjdPJlnTFx5e/ 5WOacq5a9QvrERQULMQiRx7c6b0Qiv0xVy+FoNu7GdjxvmM7rEhy0vtvSXoQzDjXkWI4Y78heEiq l0fg8ebCivN9zdFfsx53UDebfxKF+9pj+6V9SJrcR3ISDc46aI1+ivT1/JorRw7KNVv3Uujjy/1a Ozw1TOb0hSdkRj+VLITgycU3sGP+RFW9UU+xpdt8O+ZIbej06ZIeS659yKsrNvcXiRmNZ04/zeuZ 2XpJwsCQwcGn+2iqdjqoMpq4j8D51qosr18qokZtvn+ijBqLoZPmYGdmLnbNesb1TgxlJJ02h3yu 6mR3hMyUB2/Kn8iLL9u/wtMb0Pe9n7mk4qZ9jXd7/EVMlv+t0wvJO14T3N7Fa6uU9xqZk8/bfg/Z tbpPvpt2BDqJbYySe69sVtRLXjFAI1MEyggCAezcRBnh1SWb9rxcXL1pw11yJjeoUhhq1a6F0BB5 o+Uyqn88igvIdshrQKVAFN8NQq3IuggtRez5B4SynArZNk+2GBfY2IOsd2ErDkREZKQf8rAYuTk5 uEHSCwssRlHl6oggrxS4VR2yNfDypUuw3S0CKQ6oUb8xuQTSbYwyljHFZNs+e74iECFsGb/9HbqG xnOXgJIVYUxupb1NOi/nLG6iEgKLixBG8q6aHyAxUy/Zcy/gwg12D20QakREIrxc5V0ZUrUSKEdm 9MWviBptxwoPY0RIa+4umoXZhfh7lB05Z/MQROqyu+T6tkaR4drsm42nTc1PrubqJT8xR5PRgUCp L386ZHAXxLh8Jvs95NWWcYHNpRenBi87jjUjm7tjzTs/o/WSd6nR2BSBMoeAH7q7vsckpFo4Islf qf0CQxHZSN+KcqmV4Z5mLBChRL9Cq/EgaJxc9hE6gQiPbARDmh0Ygrokjv949JHoKrL2vAvkRYE6 iAwP5gf4gv/ez+dwg3z25vgH/lJFFcthrUYwEbLP4ehjk5l6KSS8PqIMZbiPhbhXyZdAOTKjL37N Hi/ascI77NWLVUk7aOx+drPx/IWLt/WSv/ik6XhGoNSXP88iuA1hXD5z/Z7CnCPSIB8Yh2mDfTjI ZyX2ol5yCxj1pAiUEwTKxUC/nOQFFYMiQBFwgUB28mC0mngAfZ9/G/16P4LGZNR+IHkWpizZzceY 9A6euGfefHcBEnWmCFAE/IoArZf8CjdNrAwgcGbPaonLUckvokUZfNJXEoAaKALlAAE60C8HmUhF oAjcKwhs/fRVbP1UJS0563tmdm/3RxpUUaiVIkAR8DEC5OjQJSEJ++8G0jIbz0ASVgel9ZLViFJ6 ZRWB+o9Oxyfze6IwOAJ9B2nd81BWJaN8UwTKJgLl4ox+2YSeck0RoAjoRaC4IBfZJw/jyNEzuHbt Cm7dJOfYqzdE2yd6oVfbhnSQrxdIGo4i4C8Eii9ha3IKrhSGof3Tg9CiWgV9KZuNp4+6paFovWQp nJQYRYAiQBGgCFiMAB3oWwwoJUcRoAhQBCgCFAGKAEWAIkARoAhQBCgCFIGSRMCa5/VKUgKaNkWA IkARoAhQBCgCFAGKAEWAIkARoAhQBCgCEgJ0oC9BQQ0UAYoARYAiQBGgCFAEKAIUAYoARYAiQBEo +wjQy/jKfh5SCfyIgD3vEq7ailE5rDbCq1l9nawdl89ego2cOI8gb73TJ9T9mLFlMqnyri/lXb4y qXR+YJrmux9ApkncowjYcy/j0g3y3GUQD0Cl6hGo66Ev49t+zz2aET4Tm9afPoO2jBL28ox+MY7v WIfDvwagIn7Hn6O6IbFdHQUUt8/uwsY951GxIkiISCQOiff7e9YKhkxYruxJxqr9N8n73arIweFo 2aEjOsTcTy8DU0FTPq02fJpQFWPSgaazf8Cpqa2tFfP2fnQN7cC9C//ekVuY3qqqtfTLKjVyOdem hZukG7y1xbCjYp0uGD2wjaMsFl9DytK1OF8YoB2FdbUHo+PI0Xg4XLwojNRpW1dh+4UCKIo7KevN W7dFx1YNle6uKfvep7zrS3mXz/caUjZToPleNvNN5Lq819du5Auu2QCt23ZCq0b3iWiUot9rWDvj OQyZ9ZWCJ899GR/3exTc6LF4N+64cnA9Vu36FSFVG+CZsX1QS5Gk2P7nIrhGF4wd2sapvS/O+xlb Vn2GVZt/wDkStyb5i2gSi0faP4pOnTqTvGdd+O/0jmXY8tNtJxqiv9NvxaYYPq6bd2MkWn86wXrP OzBefflMUjwYAiL/1+wD5qqCXhGTMkbmjwRmv00RoExYMpJ6OGQUZZX/PjiO2flzQZmQpbQxmbX8 aR7bPiuY0q8a+cwSQd97z/tRF5SG5LMfYoYLejX3yC1d9O+JQAWHmAR5eXNljl7A3JQDUrBPV7xZ ++VYO/JYqtcU6Y1gko9clqdiqbms6IshPs0iVAbLg19wMYunBfH8Il8ZzHcLoC0/JMp7fa1DvuZD FzAnS1mHRiq7QnsWEx/PtCDm0cuOe9A9R5uot9/jgaCX3t6NOxz9ea3xiENWqPsThOvLez50PxZA f+awlO83mAUx8vGPHnMs850U3yRMtP40CVz5jeb11v2qYbK5kpPJ2JfzIvpFCqtjt49i/RKZP6qK u4XkjqXeHBQsChmLMZPjUZnl+E4u5i1ZzfN+/BM81vgOjtlWoEVoqRendDEorrbmF6K4dHGmwU1F NO4+CvFkHrd5TU4LNMKonMqUfCreS4uVbDGMkHhhy2BbUv4kB8FwB0zEA6gkdw4JR78xQ9EYf+Zc rx1Ygs2ZrDEWw8a05crxHUInto5i7R5ScSfhnp/+FJmxv4iDsz7ldloAKzHs4ZX4Yf1pzB/ogzeC y4q+lBU+5frgD3N5x6W8y+cPHSnvaZT3+lohXwImTyfD5buVcOf6PixJ3sXl7onVE9DMFoybW5/3 bnXWMl2xYf+K9Ty1oUvwy/LnEaG792+i32MZ39qEvBl3OPrz2uMRqf0PD3bsDiRs/HFlJ7p3ekli qM/0JLzwWEtU/P1XnNj9DSaSPgKQjyIpRBhajp6AYScK+TGD4K7VDxGj/MY8gkhFJ0b0ob8UAS8Q 8G4OI59ZkaicpRq8yDE7mJv2mmr2Sz7b5V3K/oydtXiQtOp8V57w3fNM0jCH/L1kssuDUbNrBE7J VvQV2LqOUqZ8DMknn4k9fLtMyelTZmW4eFPG9OWFrE4ju0wcOpnPZGx8XVafJTA7r1kvtT4ehXRl uMz1s74Y4tMsTCUon1mW/YKLWeYsiOcX+cpgvlsAbfkhIcu/cllfu5Gv4OxX0q480i1nFmaWlna8 SOqrD152uozrmqyNFnYnGBl3SP15xeq7CImMdtwSxS7TrMXdpfZ/7q7rYgTHLxkPbPl8A3O+yOGk ZfJ5HSrTT3/3C7TkpW4lj4DuOT1PcwktWrRAZmYm1i5Ixbxxzcm5Fzt2ffGWp2goyM3G99/swu5d e3HyzGVyERn7haFFfE8MGDgAcVGO8y4SMfaM1NKNuFRYC12e6oArKYuwaN0PsN24AaZ+e4z41xSM 7NRQCm6Zgaw6kytMHOdtQupjwtxt+Cy5N9iFwoBCx1yeMk07ftz6ORYvW4/95/6EGgHXwbToihfG T8bAtvcrg8ptedlY8dGHWJF+FmFhYajVrCvGjh+OKqe24bszv+H+Dk+iR4wMH4LL1uQUXLBVQpfB w9BCOnfMEiU8bFyLPZd/R5N4VTwpTZN8FlxAypqV2LAuHceu/wnVG4aiXu0G5MxSAp7o9QSiycyo 4+PPQKVd+R3BxPn0SmGWOWUFkhb/P7Lno5ALWkh+Og6Wn512UNBtsl/AmiVbcR3BaENotVPgoaJC sEshOsWe526ZOBZxkSLP/Hmw738tIlSEjzBXLbav030UvK818oVVtOFc2jrMSVqFn2w3cON6OHq+ +BZmjOwIKzeNeFf+7kOX4QMQfHAD5n7iWz5F6F2XMTGE698i2Wqkohy7iqIo72F46Mk3cHnHb6jb /d8kRhrmrTmKrpNauoqt071k9MV4vlvDp05QnIKF3DmP9OWbMH/lLq6eR/VYPP3qTIxLaOoU1uFQ zuozTjBy78Ricu8EaWHr18jHxoXruDq3ywtv4Y0nQ/HZK68g+UAOalRvj5nL56OrVI/xqJRYvpP7 MtLXL8Oy9V8jk20DazIIjWiJHokD8GTvRxGu3FQjZaG5etAf+S6xaMpgPB9IMlK/x0i9ew1fE305 Teq+Om0GYqDqDiWOeYluACIfHYLEVrI+hSnpHJHKX33tkI01qeWr0rAnPkx7DasS+L5v4W/O+xSL cw9j6dp9KAxugOHkjHgBOTO++KPV2H+sAEzDemjZrDUGjR+JdnWrKBNj+3BG+pFCvl4nPdZg3MKW LTy5tR/ORecAsiuO7WSRv+qaemG032Mj9fPnyCJ6FlylFZ4d+qijnyxIcS4tGduO/0ZsIeg58lk0 tqAjY3bcoQJWl7WI9E65r88KjIur4RyHjAf6/q2+s7vKxXA/RBXfiNWv7aYRxmhY/yLg3VyDY/Zr yPw1zNvC6v66C4SqfR/Tj5ttG8G8P32IMBOmXtHP93iGZWKyY4eAxKuOM1K95+1lPEysSeQ8GaQZ QNUMHxev+Kg0g6t5fsl2knlbfo+BMANJcpnDpPfsdNmqoYMTe85XHs8Xk0tUHBFYkwwX5blj1tNx 9qiTOh7rbZLP4svfuOWz6ayjLHXZd4P5QIWBiIX693XF2WkZCb1G2RntKTuvuI+V+1/uvBrLgxI7 bX41MeRS0A6vlo21O8knm4nVCs+5TUrR1Bf3wrny9V35g5V8ynDxZoXIbTmWIHLUadAs7yeYsaL+ avlLdPQaSkJfzOS7F3zqhUIdTpbvrspDpzfTtev58lifsfjI6jRXmDjcZzLnFZiWTL4XnP1S6As4 dr85eATj1EboyHeX9Yvf8l0BrEGLmXwgScjadzl+CrNTvfsL845YX2mcOWYZL8j4j7RSOWH7RYOy aASX5V/5q6+JvDL5tPp89lOfSnhq+TvwTmAmz+gjhZXno1Pfzoxek7qCPYMvp6tpfuOQRiZq1/eu +z0MczCpnZTWhM3nFDTtZ7+Q/BC3QHWXlyKoDoujjTYz7pD6AYZW9O8yO6Z3FGR4iTmjg0tXQaT0 Lek/aKQi00/N/CY6YXW7qcEFdSpFCPyJKIIlHxMajX79n+ZobU77CdcPpWIzsUVPG4guMdJaqIu0 YjHp/cVI3X0AmdmZSNswFwlCyKRhD2Jzzh/KeIozUsTrwXHYfOAUMnevAplc4L5tkx/FRxn5gs2i H41L0G9nfo9VAvlbTslcw4LEZng1nfdo/vwc7DySSfjcjBfjebdt0+LxeuqvqpiX8O/IXsKZYKDP m2txJPMAFk/upAjXJIQAIf9kuISQVw7Un3j2qKo6HszyaceWKY8LfJLzzLPX4ADZ1XFg97fY8Pls Pi8CflexEYYBB7ZjA5leTk3dgjnk9jn+649lqalk1nkL/7chFcOaqme0xbA6f6s0RT8B5/2Hz7qN dOvcIW5XBtAfXZrKMzoMfb5dj89Xb8CGDfMkvXTGUCRvoXxEr9fvzsCB1IVSupj/Cnaoy4OYtOlf 78uff/gEvvpiM3akpWHHjh3Kv61bcSDntmkEdEesUA+tEoXQJG/O23XHdBGwJPXFSL5byKcLJDw7 j8B6VT2/5/V4vLP7hipqOa3PWCmDgqT7KsiFXzhwYDOkKpR4j16Ujj1rpgh4bMMPOfwOKcFB+PFj vt/aj8RG/bm+AJt450lJ2M22gUd2Yc38iTw/Tm2EwKb4o7se9Ge+i8x582skH0g6svadS1UXLhEY vPEfPJPZE/DNWbU+FCN95SeCEOPw98f/Kpit+Sl/9bVnXK7+9JMUqGvbBpJZMgSJ/WGyK+y9FM6Z Pe+9hfSH1sx/09HWSxFM6jXp/3wk9KdSU5Mxloz6ua/zOyQtsa+1AbsG1Rc85D9G+z1AmwlfYbHQ Ni7oR8q82E8p/hlvNXpGIN4f+zePV910L0/XmNm7cYeRtEIQUV/cgvAh+g37N+lvOPf4jVD0X1hf t5v+k4SmZBIB7yYdHDNrvRadZoovC7N2XYYzYxObc7Nfs/ZfZ86uGSjMhKlX9IuYC5mZzDWtpffL 26SV4lHJqjNFihmrcbJbLok08hXm0du0V3sMCi3NwHX+gDl/9y5js9kY281rTFbqQolHAj+zNFt5 837ewXcFudmbTdW3tF9lSKUo+CtXXvJkM+y958lX7Ytks4pgnGaLZbg439ruyCt1PLN8srsEJBmi vtBANZ+5dtNxylkjAOPr80oH3xdeTCCzyNKN7EV8Ht6961A86SZWksfKlyPkXBcxa4U8U2MoDyU3 G5JPln9oPpM5KYPOnvWZpEvKHQfy1IyaLSh//uBTjoubFQqnVRAVHFI5djuT7ignmiv6pEZJe7uD VJ9Z/YqIf/TFZL7L8DTEpyyeIaMi30co6/nc7xyrxEOUL3aU5/pMvpq48FghB6ek19KrN78wb7fg 2xZlO+D/fJfqX1JuJ65XteOE++JL+5jt+1WvWMjz3UD9UpL5bkivSR3idb/HAC7sLhCyAMLVWU4r sgq/vcbEcBVann/lsb6WyafesZCbtU7RJ9Q6o1+Q9ZHUlpOrYJmlR3KVSN69yvx8ydGXNK/XcrJ3 pTP6ap7lobTNBvo9RJ/IxKMg3ztcXypteiNJ3rne7tLkGHS00WbGHVJ9aWhFn9RVZEzivEMigRk6 +W1m0YY05pLO2/Kl9N32Q7RzQperTD8Bf7SburiigUoQActW9NmzShXqxIN0MIDvVmHxlhPEMAI9 H6mBogJXyQQiMiYG4dxNAcUoyMtFbl4e8sifvUpzdBdWY09fJ1dju/h6LRqLh8WJNjZMncfwyvRG fOjPtuGktOJmx9msDGRkZSHL019GBk5prQ7uehkNKlXizsuHVa+FmB4vSKvZb2w+jeei5CvQdny7 dKbAdSye6RYNewEvGytfnj0MnYePF/xP4mKeYCQ/vxz6RrD0x8zn5G+1B6LbhOkQJ2YdMbwxmedT kWqTXFxwOo4WhvBqLg5fCpHl55Vc3XCgSMegpWGHR/kYuw/hXAFv/GFuApeHlVp9Ah52G7K+TeU8 OyW0dzPbfAfq/Qme2DEr34TXRyFaBl1w9CMgW8a57/uD5z0lq9Pf+/LnHz6V4rDn8pz+SJBu9aoq A/rEFojwWo5VL9WeGq9T9I++eJ/vZvk0C1DveS8q6/manfHPtzvw5NZsxgmhbLN3kZitdxW8ldL6 TM5jYTF704Tsa1RVeHUiFPdrLCSC3CHtbXtrLN8vYMtUvl4lk2Z4Q+OVigp126OH1rlxQSz99UvJ 5rssF3QYvc8H/bgQdqq0xrjJjTm+9kz7Aj/L2umL6V9Kuy3GP/WIDt6NB3Gqq9n6m5Ap2fragv4g keGrvw8l5+yHY/jw4ejXNQDhMYOknZggZ7mHxfAvvrhCrdei5XhOfSdCSC00ks7nW6TXsp6L+l4B V7w53A30e6q0R1LGx0LUV1A7IAAJs85ydrJohcntrG2jzY07HJIZMVWo0wu7Mr9U7KBi7+pZPe9V /H1gAiLCWmJ+qlV9MyOcuQ7r93bTNSvUpwQRsOwyPnCPStRCv38Mwqtj1/EijX4aLUgKx90JWHAB mxbNxVtTk4St086B/xrsujv9WOsmThEiY+KIG1u5XMUddvTIDphu/4gxLTo4KmHi5O4jq4M4NVU+ yHYTeuIcvJ6ofmrrd9y4KsY5hsciZKM20Vn6/RIXr5IhZDV+v/2dWwG8T58eaC6fxGBdw5uiN/lh L/+z5jPPJ8ijIZFihzJlAhoETcDQ6XPQs10Moho0QZOYRpZeHGdG3ppRrbmtcGnkWbRjlz7Fw1G3 sGvVfnA9DVJpZ+WNR1zYL9gnXFTTtaMwSWQmMQvjREfVUlKr0AAdEkEm0JTOXtu8LH9+41MQlOyk QIrXF+B5h1oReUKntH2G88HLfPe3/F07iRWNI+WoLr2IZR/n4Gghynd95pAeqFlV1aboUUt/5vvt 6zgpMNx7QGtTz4zp1+sylu9e5oN+XNgMCETHUZOBeezCwofYuG8GpnGXid3EjqXkxhz2i1uAxxuJ W8p5Jyv+l9r62rL+4DEkLznmBFXnSSuwfPYIj/2fEY9HO8VVOnij10pK/rLd99ALyFi8G63EcQCb cJ8lWDlJZ3/aEKNsB9/EuMNQGo7A98X0w0omHy/vSUf6d+lIS/8WW9KPCwGOYXLPhri767pQvhzx Ssrkn3azpKSj6epFwMKBPp9kdPf+xMAP9F8f3s49HwXHMI7Mgi2WhxJme9mhLDnuzX0FLm+zJ94B sulpgU6tqAcFE3esjTfLzjZKnm4MTuff2bCdP8DJDaPIu9rFsP2aiWWTHsN76bFAUjdM634Rs3s4 VvrY4I5uWCxZgWR3L2l9rJyEBjfjyg70b+LYDmEVJCWHu+VfMdYPrIWmZMCHLVq0zLmZ45NNi+ww eOsk3j7muIdg9awpWC2xQc5pZa9EomKng+TpH0PNZognywdpRJf2ZV3Fc/VOYUeWmHQa0rLyEdck S9DBWLSODhc9S/S3sMhZry1nyILy5xc+LRfcG4Jk98f2HRIBX+xCkYgbMBjKBwvy3QBrPgsayM+L OtEv1/WZJO0IREfwA7P6HToRV2FyXfLXMPg738nsi9h2aZ5V1mBR7WREr8tMvluQD0ZwYTGt8mA/ sttyPF4l7eB0MgibHNcfIVd24WOhHzHhpURTEzHq/Cp9dhf1tRX9QVbY5i9h9XvtyUISv9evYpU6 ePCR1oiSVuTdITICjYQy7C6Ueb12R9W3fg89OwmQDfSnzBjiU/0yMu4ICnbVF9eLSRhiOiVyfxNf JY9h5JGdSx/NwFOvreUITP/3V/hHnOdJHr2pWR3O+nbTag4pPasRsHygX+H+RFz4OZsMUCshIrKG W36Pr50lDfJHz/sabz4Xh7qhYrVmw8p+VfGshwFtcJCzCPZb+c7pBj9CZuIYsq7rxRdWFfXCq3Gd l/Dwrng39ShuhPATFe/3fA9D7i5CC5F9eTJ9XsLerXoLfiCqRAiR4yKFrZhyYsVkc6qZrxj5Ng/x DPEp0CKXML6SVoQRGfuw99CPOLSXXDCTvFXw/BL9ol/GmaJFaOycTR6Yscq7Njr2Iqv0mWfxffZZ nKuzl9vVERMfj6z0dKz77jhG/CGtO6FZ3QpWJVzq6VhR/kq9kJYzWICr5wSicQkgL0mWua8s5rtW PR9Yuap77MtlfSaKTM4qiLvVRCcPv37Pd8KfeKLih2yyvc3ibbsuxS3l+e73fOCAisDAaSPx6pDP gTUf4cel/VE9ZYl0Ae2zCcpFCpfYljkPF/W1Ff1BgkWv8c9hSN/mJlExWIbN6LVJzryLVoyv33xZ QWLO6Fl4/ug7PusHGhl3SMePFByatwRWq48nX12JrTcPo++8M0DKfnJJ7wjtsYD5ZEzF9Fu7aYo7 GslfCLg6PO9F+iGIbBSFqEaRCHU7uLPjdHYGn86QtVgw6QnZIJ84F57HTg+DfDZyzi83eRqy//87 fkiysX0hyz71/EFwLF7f8S+B/CeYveknRVLSgJyMsPWvz7KzhYN4OrtzcENBkVgKz4Fczuric2xg dSrgJF5aunY0c3zKaQXi/lZxGDJ2Euau2oIi23msmc5uq2W/T/DNsd94o7v/Hvrs7qK69wtEVOf+ XJBTR3Zi0yYWhFi8vXA+d5/EqfT/w8advB42m9gO9dwTM+/rM/nMsmRN+TObelmN98e5vZiSJXD/ QF2E+UoQn+mLxfnuMz6VwGafc67nLxzZLQWS1/Pluz6TRDZoKIF8D6yM2ijWFgMAAEAASURBVAKX R3+6YJBf48FLRb57ZNvifPCYniNA0x7PCje6p+GLLzZhwxc7OM/oaeOU9184opR5k6/ra+Pn3Y1D 6r1eG0/TmxgXv56B7rO+V5I48S4S/7nNQD9YGd2zTe+4Q07Jyln6QDzQ8iGBuHBkWJ5UCZn9226W kJA0WY8I+GCg7zFNKUCVSuI55GCyCVz5Xfzvp9KzdUofpe198pyQVBFyXpfw1WfiBUC+X3Gr0+0f mCGwtHbYXGRLzJDL9oTnBrF7Ar7MdD3YLVbNAgSFVhYovovUTH5LmCj1rUP/lS7PEd2k36IiaQXl SOY1yZk13D6520U883wqEpBZAkPr4+khCZKL+22GwuzJuWvcMQUpkoWGWtEdeGpb38WUeXvIdrve aB8VQ1b6O5KLIz/E1Pe2cf5dH23upIfes+F7+czyaEX5M5u22XiMm/s6PNGUtuxVDWZfqvL8qcPl HcOs0c9I8RZO7CY7niM5e2nwvb5Yk+++51MO5IKlO6S6jXe/htQV64UgD+MvUp+t/NdnclyMmP2e 7yEN0XkYz2H27Pex/bI2t3a7qgHUDubBtaTz3QN7Mm9r8kFGUK/xvrZ4YQwfOGnkU9KzvxOGkHbQ R1/5r699BJxE1nq9lkj7wPDHxS/Rp7vj3gfy0hHIyxtcSieT+uClLf/zQarGSBYViltbj+F/4pYj iUQBLp6XLIqJidtnj+BIzm2Hp8Jkw4GdQnvUrAP+KrVHikB+t5Rku+l3YWmCLhEowYE+GdoH/Moz tmYA/p0mli4y4711FiL7fuySaYVHyrMYNf97oRN4EynvkMsAyTk09hs85gk3N6jzYbz/Xx9jt/5D IPMJ/iNb1W+aOFl6E3VUbF98knZampQotufh1MEtmNkvAPEfH1Ww0fTxwdLN+i/ETseB3D84/9vn tmNkp5mKsApLyH1oJjgsHfZPbDl1i7PdOkXeWm71T0VQucUsn4ANK4ZH4/mkTcjKuS5VisV52Vj4 /mdCEgmIIbdBu/qCQuvwXidewcz5/8Vl4dWFvLwCiZ6ruHrdK9SNwYuywJ2efozTi5iePWWu5B3Y VnUVds5SbEdBQQH5s6PYflPatp1v/w12ya+AmJ2jsi7+kE87ZU+uFpU/T8lY7P/V3nQcJK9iHDx4 0Olvz8HTqsGgjZQxPlxGxkEcOHqF5+bcMaQf5Gns2ZOBS9LknIrZlGP4/tRZnMo6gE1J0xBQvaXU OdZzo7KKmi6r7/XFmnz3PZ8quFLGYMj876R6/uu3R2KKsENp8LJ+qC8LXt7rM5moBowlke8h6PHS fwQe09ArYgA2ZFwR6nXyyk5uNlaMC0DL+T8akMN10JLMd9dcqX2syQc1VX32EHQdJ+aHEKP5O+jr 4WZ4fbS1Q5X3+lpbamtdzeu1F3xIfRsj/Z4zeC1ygHAcJAE7N47nzuW3mfIp5sTwvCzo1webc/j+ rBfceRW12RODhfjH0P+Jf2L3WdJ3Jatt9ryfsfbFZ2Tjh86KewXObB+PR+qHYtj0JdiddZG8nEWw IfHyLmdiyYu98bdkgWzLRqjhFYcWRvZLu2khv5SUbxDw7mk/xzvq7t4Vz1rcnSHck7/+jPzdafup TwV34d1NcmNdC+kNTvEtTvfvxfN0HWEd9pnMGccz6V6J6fHdy+ITzFiJ73HMMdn75zk7XlPKKIVz 8Oz0ti3h9mCS8P67ED4mPsaJjhbmDqwd9B2Y8G5a8czxmc8siVemQ57SUfI5ehMjg8M5H/L2Kd6d lfOqfAPaOap+l7vMxjEOPqV36Ena/aT8GMec1NCXDFU+yPmTmx+d96M2O0bkI++fivw4y66vrGkz oe3qTfnzJ5/s2+FienLMnc2xivqFfT+a7CtR6qOGXdIHDiYHzs70eVpx09Zy7wNro+qlqx/0xXS+ y0Uzwqc8nhGzrnx/iTmpUcGU2/qsQCwL/ZnDwrvN0rvc5F1msoJGPocOy+uRksn3IiZtTk+3ZdCp /ZPlu5x/XnUcspWqdoxnTtd/0/ngBS4Oxs4zM1o46sTBy447vKwyyfh0VYfy7mW0vpbJp6WDnmCU yquqP+wunrn6TE7RfbmRh2TNxvs9d5mtMxpL5XzK9itKkuQNekdb7G3fXJ8sjr6wctzBkB6pvD+o raPO7UpGUjtJPu04bLlKYHZeKlbKrrJ5HE+owhu2yvTTNZ/O8rHpeK9nhrmlEfyAgNcr+qHCFpVQ N1tqK4c2JvrGfrVRWbZnNrjpaOTs+Vha9Wav2ecX42MxL3UP1kx+gIvljvbQ6dNBBgHKrw+5Hd9m 4cUf4i2drhamKzTDi2tGCjx8grSjwrZW4nJ/tzeRS55xGxuvZFG0dek7FhMed346qs2E/8Oexc+J wcjFcfzB4KFvJWGGC1ps4AfHrMbG6eqteDyey8c05eiFhskyQUjBHJ8V0bjfKGn3AUsqU3wqgZgn kQsWb346wP325vvaY/ulfUia3EfgxPETFkhWPyz5QvBQFzF/RuDx5kJG3tcc/ROFBIZ0RgON5ILC BAX3wIfLJyANyRck3VKtJXuwWNY08s8De5re5suff/lk387QlwvtFfULgiqjiabkSsdaleUZXxE1 avP1jjJULIZOmoOdmbnYNesZ3+0U8oO+mM93GSKG+JTFM2R05Puk999XvV9MCPV9B8ds/0G0xgWo 5bY+I7eF8+feNUpEvVDp6JHYLgczDt0umXwPRPzLX+Hst0ud22lWF8hzVSM7N1RphSPfjdaDJZbv KgncWc3ng3lcHPzUR3upuxGLYb2bO7wsMzn4dE+yrNbXDvm0+lLuZSatWVCwECSUmD2F5v3N6bWS tth/qB1WWemhYTPa7yk8vQF93/uZoxQ37Wu82+MvSqrkDfrkHa8Jbu/itVU/Kf0N2sT6zd3YwNW4 g30P68nF+UibP0Ez1c7PLyHjB+d2pUnP2Zgzeaiivysn0HlSEo5d+y+6errQ2dN4Qk7UlNmhn/5p N00xSSP5EYEAdjLBj+lpJ1VcgJyca0ClQBTfDUKtyLruL/IrPIwRIa25M/wLswvx9yg7cs7mISiw mJzzDkOjyHDtdErY1Z6Xi6s3bbhLztIHVQpDrdq1EBri6IhpsWfPu4Az52+iiLQINf5SH5HhQeQ1 gkrcawRkNtnlm+J5OWfJQ32VEFhchLDISFRzn4wiaeN8km2YZMt9ga2I0LkLW3EgeXHB02WMiiSp pSQRMFr+SpJXmrZ1CJS1fOf4vWm4nqf1mUplSizfi5GbQy6YJe1DGGmriypXRwR5xcZA06QSxL21 1Od7ieTDBbwT24DfnjxkBWyr9b4G5B5r6us/BIzrtf94K3MpkTKYe+0mbLa7pI9dCTVqRSDc/S3i REQ78nJv4ibp71Yi9RiJihoRkTrilRA6fms3S0g+mqxHBErHQN8jm6oAsoE+2dqHya1cLbWr4pUL q+PZQXcD/XIhKhWCIkARoAhQBCgCFAFLEDi3aTwaPcXff/T6rut4I67UnCa2RD5KhCJAEaAIUASU CPhqMl2ZCrVRBCgCFAGKAEWAIkARoAj4FYHi3MNY+EkabDf34tV5KULaM/E3Osj3az7QxCgCFAGK QEkgUDYH+mSH+CUBLbvy9bmSwNDvaYqvg+Tb2a3y9KMIUAQoAhQBigBFgCLgjID9l68x6bVXFB5L M/+F+goXaqEIUAQoAhSB8ohA2Rzoh9TBpM8X4enCMLRvWqU85osbmSoj9oVFeL+7DQ0ek27VcROe elEEKAIUAYoARYAicC8iUKX+AKz+pCZ+Dw5GxSqRaNM1Do2rVbgXoaAyUwQoAhSBew6BsnlG/57L JiowRYAiQBGgCFAEKAIUAYoARYAiQBGgCFAE9CHg9fN6+pKhoSgCFAGKAEWAIkARoAhQBCgCFAGK AEWAIkAR8AcCdKDvD5RpGhQBigBFgCJAEaAIUAQoAhQBigBFgCJAEfATAmXzjL6fwClfyQhvGLNv ftZvhPAQ30hnz7uEq7ZiVA6rjfBqPkrEN6yXSqqlFc+Cyz/jzK82BAUFCbiRiyGD6iA6qo7P3sUu lRlEmdKFANUXXTDRQBSBUo1AaW2PSjVo9zBz3uiLPfcyLt0gHVahi1GpegTq0j5lOdImOy6fvQQb 6TFGREYitERHo/4ZH5VU5tEz+iWFvL/TLTyMriGtkUbSnbX/Fqa1q+oDDmz4NKEqxqQDTWf/gFNT W/sgjXuJZOnF8+gH9fHQlBxlZkQvwM2T41FN6VoCtmIc37EOh38NQEX8jj9HdUNiuzoKPm6f3YWN e86jYkWQEJFIHBJfCvhWsOjRcmVPMlbtv4kQ9XxacDhaduiIDjH3l5pJl9KtLx6hpgEoApoIHN/6 ObZfKIC6CMoD2xGOp18YjPol2pGVc2TWXHrbI7MS0Xi+RMCsvlzD2hnPYcisrxTM3XN9yuJL2LRw k/TCmAIMyWJHxTpdMHpgG66tP71jGbb8dNttfSRFZQ0Vm2L4uG5c38fv/Ynb+9E1tAM3JnnvyC1M b+WLMYlCWtcWv4yPXCfva58y3/QcXzEIMX9bD/RZAdvWEQj1NWJlmH6EwHsIGdz4+msSIq70+jql e4N+acMzLGYShg07hZo1gbR5S5DJZkPj4FIysLyD9DnDMJFMOHFfsw9w9cS/UEuwAsX4bk4XjFwi OiRgf594tCtjlcevR9dg6tRUUQjn3wfHYefmD9C1Ucm/TFK69cUZOupCEfCMgA375z2HqWI94zJC AuJGkoF+GatfXIpDPEpbeyTySvuDIhKl69eIvhxfMUExyI+Jj0dAejra1KpcuoTyNTf2K1g4aRI3 EHabFFlgGUQG+tVwE99MGYWpWW5DqzxjETu0GzqTusnv/QmyG1Qck1RScVUSVpEXf4yP/C1fmR/o ozCAxyy/kHTf6VeyCFRE4+6jEI9zaF7zHquUfQJ86cWzYfcXsao7L/TplrcQxU625fsEBFNEq4bJ op1Mxr6cF9EvUnhS6vZRrJcG+Wy4quLuQFmk0m8MChaFjMWYyfHgStydXMxbsppn/vgneKzxHRyz rUCLEh5klHZ9Kf25TTksjQhIRRCxGDamLV8GVYze+a0xqpaLee/S2x5JkNP+oARFyRvM6AuZPFtB +hLsN3QJfln+PCLK/iiFl8fof1JniINPkPplzOS2wB01kTtgIh4AP1AOQ8vREzDsRKGiHrp2YAk2 cysxznXUb8wjiBRG2WWpP6FGgdrdI1Dmi1BQMMNLWDVYUHb3At/LvgU+Fz4E8VM+I38+T+geSaBs 4Fkkdq5Kba4cw/rUU+g3rjnH4fVDKVhVank1wViflzB/7ghpu97c+e9gwfMNMDGZpbUSM1ZPwTZB dhPULY9S+vXFcpEpwfKOACmDny52lMHyKW7pb49of7A0aZ4ZfakMcfJscNfO9+4gX5WNvRatxmKP bXggHp2YhEdVcU+vuIXN3K5nnXVUSfQnmJIfivp+fKTKGD9aLUW3OPcwlq7dh8LgBhg+tg8KDq7H 4o9WY/+xAjAN66Fls9YYNH4k2tVVbyW140dy1m3xsvXYf+5PqBFwHUyLrnhh/GQMbHu/Cg5y/nbr KqRd+R3BwcDplcLsX8oKJC3+f2RtrpALX0h+Og4ejYfDhVU81pWcedmanIILtkroMngYWsj9QHjY uBZ7Lv+OJvFPokcM2ZOs+gzLx56xWboRlwrvQ5fhAxB8cAPmfrIKP9lu4Mb1cPR88S3MGNnRzXED I7g4mGXPH8+b8x9sOJCDGjVqoG7bZ/DSs1Go7QhioYk/D/39r0Ug2cF/BPxqsX2dzkWL3mw+eIeL REm3oSA3G99/swu7d+3FyTOXyQUg7BeGFvE9MWDgAMRFOee3buKuAhZcQMqaldiwLh3Hrv8J1RuG ol7tBnikfQKe6PUEosMlxGQU/I+nk760648Xx/bF3UNpOHEjALF9BpMyq8WrjG1DRnN6bSgJIXCL Fi2QmZmJtQtSMY80lLVIOd/1xVseSZnSF0mva6HLUx1wJWURFq37AbYbN8DUb48R/5qCkZ0aekzb cACym4lcWSQN9BFSHxPmbsNnyb25IxUBhUUuSBrMB7/Kdw1fL16L02QSqU6bgRioumOBE0jiJwCR jw5BYitvyvA1pJD0zhMNqV8jHxsXruPKbJcX3sIbT4bis1deQTJbn1Zvj5nL56NrpFZ5MIinmCum 6gkS2UQ8U3ot8Gm+njCJi4hPWfhVl0E9PNsvYNOSufh46XcII/WUjdRTdeNHY/yLpI8Uqe4jOQga 7oc4opow+b89MqbXXvQHCRqmyoNU75jt15GEi68hff0yLFv/NTLZPm9NBqERLdEjcQCe7P2oi8uS y0I5Mq8v10kLFoxb2LKFV9O1H85F5wCyis125slfdVftgAmtLrF8N8ErG8V1G+6ZoDSxrreOUofT 3Z/wzIurEGEVbTiXtg5zkvSNj0zln5C4Uzvm0/GRK4n97M5Y+BVk/IddXid/CczkGX0EM2t3/JEL NZQp2k4yb8c7/OVhWXPv2enMXUWMG8wHMnrq8HL76/tvKWIyBYeYBCEuuZBO6cfkM0sEPjqpeRRC GpZPlp6cL4V5UopKPiExw7jw8S7v+VCBtyItQfa5R9Syq6AwZNXOD1cYcqS9wcUQb2LgfGZBjGsd YzGamHxcDGzJb/HlbyRd08qDprOOukjHv3jmHvzYo744lxUl61mLB/E04pYwNqWXs82kXjsTcueS z6xI5PN7yPw1zNuCed0FEse+j+nHlYMRzPvThwiy92cOKxg3qS869Lr3vL1MkTvWDfi5xb34KDNc KO+95/3oTNVMPlgkn1u+JU5/Yd4R+Ef0Auam5O4wOOpjMBO2X3R4mDEV7HNbXpVleCZzXp2GGTwJ DbP1hLl4JvWa8Gm6njCJixre0ml31DPkjiDtdtwF4/acr4R6SLtdmrX9nIuYDOPQewP9LJfUPHn4 tz0yrtfa/CnLK4+xU3+Q9PlM9Qt01INw1a8jcBec/dJt3mv2DcpMOdLOD/f9wX1MC7Gud/f7xiFP yqrTv2TyXSdzjmD2Q1Ib3muR+f6pvvaWYdyG89SfcHCt3ySTT6u8cm6a5chk/hHO/D8+0g+HL0P+ iYBp3RckrnKkYd57KRzdPtOTsCV1C9bMfxNkkK36rmFBYjO8ms47N39+DnYeyUTm7s14MZ532zYt Hq+n/iqLF4YBB7ZjA5n2SyV055DeLP/1x7LUVDIbuIX/25CKYU1Vs+KyMy9aFy6IW4aqurpIzqh8 svQ4HsnlWOt3Z+BA6kIHFvNfwY6cP0QhhF8zuJCo5BbLFzq9JNGaujoN2dn7kTQ2SnKz3hCGPt+u x+erN2DDhnmSXC4xZBkwjYu33Mdi0vuLkbr7ADKzM5G2Ya7Eb9KwB7HZKR/MpmfHlimPC5eoxOL5 2WtwgKzWHNj9LTZ8PhtkoEmmaH93QdyPeN4+jOfb/kPiY+LnO4i+HMHiyZ0kN9agVVYUAXRbTOq1 bvrOAZnQaPTr/zTnsTntJ1w/lIrNxBY9bSC6xIj1lXM83sWgvmjo9eYDp0h9torPc0J02+RH8VGG xZcZaFxWezvze+l4wi0n8Uzmg1/li8DgjYJuZk/AN2f5nVoOUYqRvvITwToOf3/8rw4vMybZxUDN hy7AgQObITUthN7oRenYs0Y8k7QNP+TI+TGJJ9ldYq6eMBtPBMagXpuuJ8ziIvJZhn5TvsWmHTuw detW5d/GrTiQc1slyCW8FdmLq4dYjz5vLefah7TVb0jhpvfsj+2X1f0CwdtoP0Siasbgx/bIVHnw oj8owWGwPGjUg/r6dSTBW/uR2Ki/lPedJyVhN9vnPbKL9JEn8hw59Q3KUjkyoS9VmuIjod+empqM sWTUz32d3yFjB7FPvwG7BtUXPKz68WO+e8nyV19sxo60NOwgdYzij9Q3zvWLl4kZ7k94mZ4YXff4 SIxgMP9KZHwk8lrCv1bOIhRkfSRbHYxllh7JVZK/e5X5+VKB5JZ38F0p/Ohl6lWnq8xiYSUO0FhB EaicWv40T0PPjLpsBsl5VdsxO6+5AkbSMyofI0sPzWcyJ2VbE+xZn0myq1dMzeJyduPfJJpv7Lwi 4cyQmevlwxwrB86yy4J6ZSxi1gp55gpDjrxJXMyzVsRcyMxkrmktpV7eJq3kjUo+bT4JRcx8h+5G faHw4S35zLWbMmXQCME7+RZPub5MVayI3mU2jnlA0iVP+uJ2Jlgmm1m9lpHQaXSU5V6LTpNV0y94 WboMZ8YmNufMs/ZfZ86uGSjIqF7RN6kvcr3GOOUuAfkOj9HbLFnVl3Dv/AFz/u5dxmazMbab15is 1IWSTpPmhVma7ahzWQBN54NF8kl8e9oBQlbZ+d0XYJxWhBR+e3XqhZtgMtkWHivkAkp8NvuAucq5 /MK83YKvR+VlwjSepF6W2jhD9YTZeOb02mw9YR4XN/lUqrwc9Qxbzlz9qXcx5u5x9Ht6z1bqbu5B cVckq/NKP1F0w/0QMaLXv75tj9h+irny4BDMUH+Q1MKm+gWyusJIv47l8uD7PSQ9mbjeub9RfGkf s33/ZYdAxFR2y5FOfVFIe1fajefNKraCpJPF//nuxIIeB7meGahf1KSldsxDeyuFM9ifUKen2y6X z8D4iDFZbuXtWMmMj3QjY3lAa1f0ZZMWvRYtx3PqM5MhtdBIOp9vx7dLZwoxYvFMt2jYC/KQlyf8 2cPQefh4wf8kLubJiMuM8vMnrk6iyoJbZvQsnzKpCa+PQnSIwy04+hGMFazfHzzv8CCz2uZwsWHv quUCnXcwuutfZDTD8MzUj2R2XxnvkDfJjX36cTFGVxk6EJExMQjnbqQoRkFeLnIFPbNXaY7uwu6R 09fvKKNZYWuSiwtOz0GEIbyaTBlcpuNLPOX6MhMTeshXREPQ+6WXXXJlzsOsXptLTYzFnm2rUCce ZIAGfLcKi7ecIIYR6PlIDRQVuKr+vNeXXovG4mH5Tfd1HsMr0xvxbH22DSftIod2nM3KQEZWFrI8 /WVk4JTT6iChs+tlNKhUCWFhYQirXgsxPV6QdpO8sfk0nouS72yyJh/0yyfKaeK3SmuMm9yYi7hn 2hf4WVaOLqZ/Ka2KjX/qERPEXUcpLGZvPJB9jaoKF72G4v4GMnfOaA2eMFtPGIpnRq/N1hMW4aKG uxTb2WfA4lV/5Og9+jWsqeD615N7BHt/vDymo8KvZpu/IUloj/ZsPwkX3R4pjtF+iBTRlMGX7ZGK IUN67YhrrD9opjw40mJNxvovF7BFfA41bgneGPiAkhixVajbHj0U95GU5XJkXF8g60F6cy7dCViF g7/zXZG4aQt735DTH6HWrZ7GErzpVEhEQ/0JbxJyxDVWjszkn7wdK6nxkUNef5ssvYxPzvyIx6Pl Vg3z77hxVXQ+hsci3A18vsTFq2QIWc0PD8CLLHn49SyfkkB0VC2lQ4UG6JAIMvBQOrMVnbe4NJsY 63TxXnCTttxW1NJ227h+XNQ4GbQXkIuPFs3FW1OT+DffNaL/NZjsybPkq4xIcUCQMgENgiZg6PQ5 6NkuBlENmqBJTCM3FzB6x4AZPJtNbOesL/VbW6wv3uu1OWTY6b9a6PePQXh17DqexOin0YLUfMfd EfRSXx5r3cSJemRMHHE7S/6u4g7LFlvl3f4RY1p08PxWLgnKfmR1EKemtuYtnv5PnIPXE9WdSWvy Qbd8nnh06x+IjqMmA/PYCd8PsXHfDEyLq0HMN7FjKbmphf3iFuDxRp6OYPBB9f6vWVXVFrk9aeEN nmbrCbPxCAJe6LWxesIbXPTmVCkKRwZu36c9r6tev5UvKFRcDzxUTS1DdcQ/MwhIJ3VVQD48LV4Y 7YeoU/O13Vh75IVemxXEi/LAJmlIvtvXcVLgs/eA1uTdcz3fPVaO9EBiRRh/5rsF/JIdskiZ1NIC Sl6Q0OxPeEFPFtVQOWLjeZF/ZWl8JIPIK6OPBvoj0CjCc+fL0Z2KJTNV7I4mrY+cX8qMJR7sWnFp Gejrk08uTWGRbDlK7qFh9haXGnVrw0cZq8Gtd05GcDGdUsExjAtricVyAuzsKGdn9Yv3KHB5O7k8 oh5zILq9dRJvH3PcP7F61hSslqKSM3rZK5GoWGmVPL0ymMGzQXQDZ30p+EU64+0VQ7LI3uq1jJRh Y3T3/iQOP9B/fXg79/Gt0JcA5/JeK+pBKV1pSkl2NlzydGNoonV/SOcPcHLDKNREMWy/ZmLZpMfw XjqpM5O6YVr3i5it2K0hu52fvM1rut7VK58bWfR4VXmwH9mNMR6vkjI6ffFuTI7rj5Aru/DxFj72 hJcSdXaY9aTGhhmBaKHtqt+hE7ELk0NuopvXa7P1hMl4Xuq10XrCPC5uwC7FXs4lXovZm8hO3a/l 4ey2ax/OkTefasl3BilCGe+HKKL7wWKsPTKp12bl8LI8sMkako9U+mJWdm0rrgR4Zv5eK0eeEfEy hL/z3Ut2/R7dYH/CCv4MlSMv868sjY+swJal4aPxIGmdxBUrPZySdxv3bh0hVYJ6olgfphj5Nr1U Dcqnl6w6nKW4SEMLdSrl3n587SxpkD963td487k41A0Vm08bVvarimeFgYNlYJBL4F5JK8KIjH3Y e+hHHNpLLqhM3iqQ/xL9ol/GmaJFaOyjEmhEDtu1XOfgofWMr+jr3UFmqV47s67lUuH+RFz4OZs8 Q1cJEZHsqrDrzwp9CQ5yzlj7rXznRIMfwUqGIa/de/GFVUW98Gpc/Rke3hXvph7FjRB+Yuv9nu9h yN1FaCGquzwZL/JBt3zy9NRmXfoSgYHTRuLVIZ8Daz7Cj0v7o3rKEmFXTn88myA/cqJOwIzdi7rd DJ5m6wkT8bzVa9P1hBlczGRdCcdxLvFaDFVGlQjB3ZX+B4uLHg1Q1W2z7YWuarFWGtxM6LVZtr0t D4bTJX1ikmPc90P2VaCdKwVwQfkeKUcupLfM2e/5bhnnfiJktj/hJ/Z8k39uK1o/Sea7ZFwdUvVd ijLK0jFVMsLWNxsui6w26qozHZnp1FEtPIe0dDXRkrGbxUWMt2f7QeezfTd/wbGSEaeEU7XjdHYG z8OQtVjw/9m7D/AoysR/4N/8JCRwJggYOMEzVKUIURDBQgseinQEkSInSLPQvDtQgh0NiEqEk45K l6YUBSwkQiIQhAABAxzSPIGjJbDhYGPW//7f3Z2Zndm+s5tNNvnu88BOeevnndnsu/POO2M6qjr5 YnPBSXwf7E6+UuNyuKNZG/QfMQbTl6xHoeEklr/SWdo7B98d+J8SsjgWlONl5R5ccCjAH+eP+H9F f2MGTsqJOqRnWVV2BeN8d5G+503RiK/bAA3qxiPG4zfy4Bwvp3/LdSrOfw79pGzzNiRXCejLguPv B1EJeH3LP6SYczBl7b81qQSjHYJSPy/Hi1zouzr9TXo6Rio+/3wtVn++xbqr4csjtfMgyBFC/B64 p97PCX/i6T+u5fql+/k5Icez/IKu6++7MQdJCRFISEiw/ouIeA575Z5SiNs4eNlFo0nrx2zJbTyN 804wJpzcv8+2v2sD3O7qB7rgFaaEpuTPce2mCl6/D+o/H9zk6H1zuYrKLXL7/33Ke3gpRMDnkUjH eDZbNVt7Kn7J/8Pn/EtXwGJo93AD9PP7RGirp7/95POoLPaPirGjLybbkx57he2j8GW2+06PyemP ofrQko7KExfE1Tovr8JC5RfVvdnars21nO3K5E5eUini3XpdYtGiQydb2bZ/iZ0OF2mPfrvY7b3p RVyhYk/+5gry/AhRTkNYfv12vv8dWp01KhdTC0/2T1Ri+zVcSYkVrIVYPPi4uBfU8sr5J75yOP92 fu77NeZaLSz3nltevyHPbQ9W73FtSzmU/wfjeJkqHscm/2Gxlf0Mvl6w2bbYJhF15DGcRVSx2x59 AROltFcMnI7DSmGC0w6B1M+340UFc0tLPD/ctj5jcG/lcayj+j+kClRci8HxVJde7+eEt3j6jmu9 nxNBcDFdR464ZSNb3Ftl+WeZ28Ltx4sasIQvV61/v1TCd7Bmj8O36ms/4ZOUY7b9MTGWJ9GW+Ze3 41oL5Pv3QX3ngzY3v9ai66DtQFuMw1Omiscnuo5tNKq/8AbhPBLZHF47Ap06dZL+dcCan6+5zrwM bA15uwfB1By0+aP0Fcb99wl96QUSS1/7le3+UTF29MXEUt3HKs8xfzahG+akHlW+HJuMeTiSuR5J PSLQ/uP9bo+LyJjbbPt+noSkj77FWXnW/rx856sI0begkZTSwoF/x/ojV6xrV46IZyY3+7vbPEK9 Q69Lo879pKKmonOfd5CdZ/vV9teMWWjwzKqiqYbJiPz8fPHPCJMxF+dP2LK5avwfjMq+fLFcNNl7 T1Vcvo34ry3Y8l54P/WkFEX8MrghGfHdPvaehN8hDFj0dEMMm7EWB09fUo5DU95hzJq6QEotEU3E bN5OL8Ws6D3v7vW0NE8BYDn/lmX+CqM473YvGo3WEzY5Fc3dhgpVq0q7UtFuwPvYe/oszp49jdOn LyrnsyWA3uPaXb5Fsz1Ix8vGv+HZj36UfljMxcbJYjJAS19FvPoN7yimByzqVy2M2PCClMkcfKC6 qh+Udgigfr4eL3ahaHQY+YF91bLUeDK6NfmTdlsxren31Ps5oSee/uNa7+eEfhepIUUv1/H3sNLQ 8b3t3kTle88rDwxWvodY/j5M6/agcsEhecRfrfN1FtNhbcs2hH+PAD3HtVbH9++D+s8HbY7+rEWj 00vy55j4jlazF1ZnnZO+H4inAV08jEUjI3DPR9KIDinpgM8jkU5kVLymoNFFNd1VSI8XTZV8XCmO dvexaB6CfZ2Rhkzx1J3MzEynf+mZR5ULmB6SCHCX++8TASbsZ3T97Vcs/SM/a1dkwYP5wD778117 mncafEv59JbXLDekefzn9AxlddJ5OzTPjFanpX7WsRzl4NzHPOZlie/uGfB+1088J7KHVDfnstif GesqP30uN8xbJtb1Wj/nssg6/r9nzbA/F1Zt77j8cMo+e+IBuNgT8X3JeGS+1kTMQCYm4tNu89Du vuckh7xqntdem754LIo2v6FrzTfk4Kr3UHseXD5YWy4XLt6PlxvmNcO19bW1f6LT54C+41oF5NOi 53NLTsL+WaD9vNJ9vKifC+vC0WaSZD5WKJcgsHflubfuno9r+tksHuEpte9I8wHVAaerHYJWP9+P F7vQSfNE6Rn2Fsd+nxyy7wrGUr78Wd3TvEf626V83gvfXGse9uPK8ZzQ5SmeG67vc0JfPN3Htai7 3s8JfS5SgyptIh/D9rYJRpMHnob9eIC7c9BNJpne/m72XyQdc84JKMcltJ9bziED3xLav0f6jmtN Lf34Pqj7fAjo+0uhOfW9xz3+zXX1fTeg80gAHfzsSU2e03de0bAFa0XX8aLJ3H5OufperAmqc6V4 2l1HYVXHmeP3ae16gtP3LHVuXr8nSIG9hvPwfUKdn8/Lqvo5/j01i7+Nc7vbPvcdjwPd7Se+cYe6 f+SzRREHDOoV/chIeaZ9MeTMx5/e73j0TVzM/hIjpGfHigNY82rXbQRG/dXDDKW3PIBNZ3Zgxtiu mniWldhy4tcfh9fdw5dhzSuOQz4TkLI5HZ8Nv8saOibWdeH9r1+kckXCVVmipMsVrvLT5xKNR9/J wpapTznUGhgz9S2IHx2sryizs4tTBB83RMY6XnNxHVH76Dr9Lq5T97w16q6hOJ3+sXIVxTLNvu3i qq3dl4+905pATNCGR5VHvR7PKlfLLYnbhp7ayjlGTAiYO7+Xy6s1ofa8u98nOL51lt3GUsR2L2H1 1vUQnUQfX9F4Yu5lbPlotKbOwO1OQ0/1Hdc+FkMVTIx6tb48tWnFmHpSjOqoqDrlg3G8DHjlFeV8 U4rVVcyOb5gcvAkY5Um7XAwMseZ5UyOMWz5Yyn4OUvfbhwkH2g6B1c/340WxQy08oPwZSMDALo3t u4KxJP5gVbem4+Lz7PYY5ZYf+bhy/AzV56n3c0JfvECOa72fE/pcpAZV2kRuYBdtI+8qlvfyqFrd 9rcDleTvPr4V5P5RG5C17A2Hz0tb3P5TxN+HZYPcPk3C/+8hvpXJVajQ/j3Sd1xryu3H90H950Mg 31/Kof0/vxZ/cxc6/32wVKRJDwxuW0dTJctKQOeRGFd3dId6VOwgtG7s7o+GU9Z+bdB3vGizkL8X V4+tqN0RpLXiaXc9hbcfZ55jP6D5/uIU1tv3BDmCt3Aevk/ISfj3bq+fP/0j/e0X+v6Rfx5FFzrC 8kNC0SXvX8rGvIs4n2vADXEvfWSFWFSrXg0x0cHrlKpLk3f6uHgacwWUMxUiNj4elYsmG3WWupf1 uBgvnsKpy5YbcyNRtWY84jzPQKa7bGEV0ZQvhpOLuRkqlIPpRiSqxdfwMjFboLUTw/HErST5Bsud pTdgMJUTM757mwwu0Dz1xjeJYfuW+yvKIdpyzl37AR1i2luf7y5+bcXYZsH/YqDnuNZbO13x/D1e CvZgUHQL65wPsw4X4LkGRpw+nofIcibR+rGoGx+nqxhFHcnndijW+p3C5ITattsf+i+CQXSESlq3 T24nnz3lCGLwrr7PCZ3x/D2ulXJaFvR/Tvjvosm4dK6Ioc5nz5yB4UYhxNceVK1VT0wWW4K/jISk FXQe13rLFtD5oDdTSzwTLp4+jcvie0Gs+BtRWLEKaoqnp3hrfb/Poz9yMLJcY+XJQ2I0FJYPDvIP pYEwFFfcYmv34qpwKcs3gPYra/2jEtXRL2WHIatDgRIvYMw7JWZ+vg3xcdorUhkzH0fr0ZbJ4xLw 9Zm9eLzGTSW+LsVeQFVHuKh+HCnWOhZj/U6sfRF1e9vm03h92yW80UaeF6JYRcpM5vycKDNNzYqW MoGCE0sQXXeQVKuROODucaulrN6sDgUoYBPw9uMhnShAgVIscHhpPzQbvQvdhr2NHl3uQ73KwK6l yRg/b7ut1mMmoyM7+aX4CCi5VTNd3INZc1JhyM3AqykbpYIm4Rl28kPeaPycCDk5M6RAUASOpS9T 0nl26Tg0LZOPbFQIuECBMifAjn6Za3JWmALOAhvmv4oN8x22i3vKj03p4nUooUOssrsqht6ekWpv /L0UMoS4fsbfvsGY1yZpIBdm/0Pcrc9XcQnwc6K45JkvBfQJ1Hr4Fcz56HEURNVEt77SnBL6kmIs ClAgDAU4dD8MG41FpkCwBEz5F3E4Zw/27j+GCxfO4UqumNehSh207NgZnVvWYSffH2jTGWxYuhHn CmLxwJN90bRyKbvdIdT1E48bW75qO36PikL5m+Nxf4c2YsRJKTP15/gqxrD8nChGfGZNAQpQgAIU 0CnAjr5OOEajAAUoQAEKUIACFKAABShAAQqURIGgPl6vJFaQZaIABShAAQpQgAIUoAAFKEABCpQl AXb0y1Jrs64UoAAFKEABClCAAhSgAAUoUOoFQjAZn/Ss0BuWZ8TWRVxYzvgpnnV7XDzrVtyxXHKf g17qj9USUUFj3hmcN5hQMbY64iqH5cFcIhyLqxBlof2MF8/izGXxgRtpU65QpSZq8FgtrkOu1Oar 5zgrC+dfqW1wVowCFKAABcJOoOjv0RfPXu4Q3QKpgiZ55xW83KpS2CHh2k50iHnQWod3917BK83C sA7hp14CS2zA/MRKGJ4G3DVlN45MaFECy8giuRco7e13ASsmDkH/5K81BGF7rIrJ/9bOWqs8yUBT KWXFiPK3tcPQPvfbJ440XcDGhStwsiBCCeW0YIzCQ4OHonmcPLmfCYc2LMGmU/nQ/HwXFYfGLVri oWZ1tNudEtSxwUP9om6tjRYtW6NZ3Vt0JFzUUfQeZ6X9/Ctqd6ZPAQpQgAIU8E8gBFf0gZpSmaLL +1c4X0IfWtQXTZ5ZBXRdBMOGQYjxJZK/YSIjlTpU8Dcuw5dKgfrR0uXSUlm7oq9USM5bD9Uoje13 aNEoTSe/Sfv2iEhLw/3VKnqQKMG7jOcwa8wY6w+sHkvZcCb6io5+ZTmQ8ThSRo71Gi+5zVOioy// aHsdO1OGYIL4Ec/1axCW7p2CAc1uc71bz1Yf6td4wEysnv0iGhbJHzY9hQaCcZyVxvNPnyZjUYAC FKAABYpOICQd/aIrvkhZvmpztQCmIs2IiVOgPOo99iza4wQa3xqmnaeS0ojFct6W5vYzYOci8YOn 5TVgHn77bBhqhvunu/gtTf6RGEjA8LEtgeu2Ktr/vw5zzTuh+QE2Og49hg9APfzJGuzCrnlYl21Z TMDA4S1hOXOvi3QSbtNcu0dUrDW4NdywV3rjVvyKzOT50g8GizGw+WLsXnUUH/UJ0rOoNfVLxNhX mgI3KuD6pR2Yt3SbtTA/LxuFRoYo5G4YZv8hQy5msbwHcpyV5vOvWBqDmVKAAhSgAAU8CoTkq2C+ xyIEtjMyymxLoFKU9steYMm6j20OCZn7/LmnGAWi0X78AvGvGItQSrIO+XlrdSvN7VdR6aj269A2 /Dv5Dsd559nLMHdkY4etblbL1cOouUuVnUcXXcE666ivlzB/7iDvQ/C7voQZ70rh3n0f+9Z+iGa9 37SmN+PJ59DtwlZ0iFOSD8pC59kzMF1Vvw/e3ITn63bGEkvqG4fj84P98VwT2w8XQclQdyKBHGel +fzTDcqIFKAABShAgSITCGqv9drxbUh57wOs3nUaVatWRY2WT+GlvzVAdQ/Fz794GD9+tw3bt2Ug 59hZMeGd5RWLpu0fR68+vdCmwa0OsW33Uqae+x1RUcDRxdJVrI2LMGPu/0MlFFjDF4i3h/qp78G0 JeN/ftrso6+fRNpna/HR4m0wXL4MVEnAk68mYWTiXdqA0lpA+eWfwsbli7F6ZRoOXPo/VKkTg9ur 18Z9DySiY+eOaBgnAFy+jNi34VPM/WQVdp74P1SNuARz0w54/sWx6NPyDpcx/N8o7oOdK+6DRTXU qnoVa2attJax3fNv4Y0nYrBg0iQstRwHVR5A0mcfoUO8tqy6XCz3tC5cgzMF1dCu94M4t3E2Zq/c bW0Hc60HMOgf4zG4dR3nquiNZ01JHG9bVuLH/xZCqYE4uCondEP3Vm6G8Sr53YJ2T/dCVOZqTJ+z BP82XMblS3F4fNxbmDj4Ibe3mTidR616YtyIbrjxUyp+vhyBhK790KqGUhrn+vq9xc/jRVf9Ajtv LVUyXdyDhSt2oCCqNp4e0RX5masw91/LsPNAPsx1bsc9jVqg74uDhc3NKgEd7afE9tNFjqf7vJUT 8PFdaodLousahStYv94Wb8WH09E2Qlz9tnwIin9V7u+DPq6OVeMprJ03HR8v/AGxTZvCkJ2NGu2H 4sVxwjBebagtj7520Kbh71pEQaG/UZTwharRI2KKQu8dfTE6zB4uFvc+8QbObvkfajz2voidipTl +9FhzD1K+sFYcKzfzXUex4epr2FJ4lvW5Av+5zxeTX87+HlcB3Sc+Xv+GcTf109xULRZ1M3N8LcB Dzu114nUpfjq0P+ESzQeH/w31HO6rcHP+skNGMB5eylrHZZnnLd+Jykw3opuLzyBWkH9diUXku8U oAAFKEABPwTMQXqdTf/Qcmnd47/pe6845HbVPLOJ5zijlx5yiHPZPM1LPnI5Xt8ZjPxE9safzE97 ybP1m2nmQoeSms166mdLxHT2O3OihzzvSt7vlJt1gyHH/HZ796ZdpqSZb7iO6d/W/B0eyye3ge09 yXxSk7pOl/yfvObZJSXDuR30xrOW2fXx1nrKbk2NNCs+5IcxG122w8XMjz2eQxZPMamlJruAVvQc L7rq59pRe5zYjlvn89ZWw/ysDySbRPPYiV1dOomJ5xw4XOfrsf0sKehxEdF0n7cOpfZpVZyDYrC3 SweN6xs/OSVnPP21uYeHuMmbTjjFkTfoawc5th/vqs/dzrMd/w74ns7BuX1tRm3mmQ1uo101L+ou WboKZ/rZPEL2crXfbboedqjq1yVln1NA45H5Stu62q+rHfQc1wEcZ2az/+df5oxWSr1HrdMeh8bj nyv70Gam+byjmp76iTQCPW+zVGUGEs073R9ojiXmOgUoQAEKUKDIBP5PfCEM/CVmpX++9UtKOhOW peLw4Z2YMaKBss3zQgLGTJ2Lzdt3IftwNlJXT4fo5FpfMwbejXWn/1BFj0WvXZuwWly+2rx5Pd4T PXDbqyc+2bxZXNVab/u3ejMG3uXuqpQ/+cnpq98HYdWuI8jevgTiy7L1lf56e0zeLq7wu3z5m58R 68f/Vbo3NAHDpizHLnG1bdf2rVj96RRbnhG/u8jpAmZ2b4RX02y7Gg97D9/vzRblXIdx7W3bvnq5 PV7f/F8Xcf3cpJqg0DJh1K5d66A0hUhq6Ow0pC+Xx7h/hd2nbSMttLn46aK5p1WkdPdIrHNoh6/G Pox/ZV3VZqM3njWVWHTdugqfLluN1atTlOOykqfJ+Fzkt2p7FnZtnqXEx0eTsEVzXIvMru3BsJYv KGUf/ekWcR7txdyxrZVtloXgTWqp83jRVb8gnLeR8igGcVX13Y1Wk66vzMB68Tmw/KM37bYaLR3t B50u0Hveagrs+8rNd+Ff0ufd5s1LMUL0+q2vtpOFifxZuBrb+taSdshvZ/BWfGesk1a7vvWZ9fMl ddkbcgC88nhPbDqr/txVdonH9ulpB1V8HYtff74OW1JTsWXLFu2/DRuw6/Q1HSn6GeWm29GsuxRH nMsnjX7G1xH8/L//rcTq0LK2sqws+N0OOo9r3ceZpaT+n3/3j/oacyXrmT162v/+m37BW3Wfkqrf EzvXvSjGk6lfOusXhPM2MipeVZBK8pMtVdu4SAEKUIACFCgGgWD8hHB8zTPKr+xvfH9OleRV82cD 7VecnK/oF5pPZWebLzhfCjebz36lXL19dulRVZraxSOfPWnLu+sil1dItaF15qe68gIMMu9R/1p/ 8Qf7lbH+ixyuGOnMT4wEEF90bPVq8Lm2Cta1q+YLuc7X5fMy31HaYegnjleIztvThOMVdhdZeNuk Mpl1oMAaWrly1miadKXlN/PbTW310La9ThdVnsBIbTuoR0AM/Up7VV9vPCeDQvMKqV1cXWFTgqvz a5xkzlE1lfHgAqWNHK/Mq8+jCZt+VZIziyN7zfA7lXhaS1UwPxd1Hy8666cunn/nrS1m/sF/KQZi KjXzwr0X1UkKpvPmX87ka7dp1nxrP90uOs9bTRF1r9xQrkh7u/p9Md3+OdFlSoYmx4uZ8qgJmFs7 7JMDBt4Ockpe3tXHmXw13cW78ygObbrK55LHK/FeruiLT5TUtx+Ujr+ewbliq6qfY5tdPLhS+fsn vhaYZ2Vf01ZKrPnbDvqPa3XWvh9n6li2Zd/OP2tYMYpA/HAseU+2/j1JfaWucv5PdzGqSX/99P29 Vdfv4NzHlLIBQTo+1BlwmQIUoAAFKKBDIAhX9A3IWPKZ9BPFZAzt8GfVzxWxeGrCv1TrjovlEN+k CeKs97KZkJ93ERfz8pAn/hlvbozHpKvQRy9dd4yorKvvv/R+F2fg+XVJGYfm6nsCb22Lv7/9oK08 y9fhZ83Mg4Hnh/oXccrp9sxYxFXWzhgNcVVi68IkySUBTz3aEMZ8m6XFM88Yi7ZPvyjtz8GveQph wAsFJssdrapX3UrSxIgxuMPFhSiIJ14H2u6dZ4/QtsNtj2DSK3VthVjwFXLcXHHTG8+W8HW4Gkeh qrnT4qjXn0VDVVNFNbwPYgiw9fVj5klVePV5lIRRnf6i2heNLi/9U7UejMXgHC++109bZv/OW21c y1rn2Z9hSLNbtTuiq6Gu5v587W7LlO3e2y84Lr6ft45l1Ltur5nj/d6OKf43J13a1BP/HP6QZvet 9z+DGdLnbvqmHHj7mNDXDposfV5pKuYRcPonYj96eyWf09AfsBziqtnPSTGoRXoZcfxgFrIOHsRB b/+ysnDEzeiDr58bIOadeBpPP/00enSIQFyTvvbHA4pHxw70MhGf93YI0nGtOoO8HWeykP3dl/NP Cn3zA5iR9bG0MgnVIyKQmHzcut4lZTfGtnJs8yDVz+e/t/ZaWZYqVm0Cy+Msu3fvjiZtG6Gi/QDR BuQaBShAAQpQIIQCQZ0uptHoBKeJ96Lqt7QO6bbOHuyqYmICnLWzp+OtCTNgfQKSizB/iQriX80A 8+vQ2rnn2qBdZ1HqHdaSO5VUV34VES9ns3EUakeOwoBX3sPjrZqgQe36qN+krouJ3H7H5fMy3gE8 UlPVu5Q3K+9f4tfzomNQubyyJZCFWys55OUwct5l2rpc7Ck90qK+fUVaim/SRixZvgyex3XLrz4O xbIE0xvPElfPq2ED7eBS3FQbD3YH5koTp7lKs9HoVs7nUa0Wns8jVwl53Bac40VP/TwWy8edg/7a 0MeQ/gYLxEXPeetv+QIPf+WqdIK26YR7KzumVwXtn+oLpK0EIq7C24+nRdcO2nKJETTYGOQJ8LQ5 eF8rhIsPtmv7MLzpg/ZOuZdkxOgDHJnQwkWoA1g674DT9rZjFuGzKYNcfN5rg3pvh0COa21eoVq7 5d7nkTV3O5qNEMei/Oo6D4vHuPILpH6Bn7d1nngP2U/IheQ7BShAAQpQoGQIBLWjX7VGdXGt1o9X /gGMjL0Hc9VRLFdtrOvi3nKp558fwIzL6qRRRPmVc9df1p1fOTz6Vg7ePmC/335Z8ngsUyoj7ls8 vBjdG2jnILD3axPElS/LSEJXL4trgthhuQLoruCu4rnbNggNa9ru2a31YGsRSPWlzF0U3S6qBCOc hjmgWoO7lQBOP7jIe/TGk+P7+V5Q6FxOb0nUbljb+TzK/832qC1vkf3YH4zjRU/9/Ciim6CDUFc6 5twECGizfhd9521AhfU7ci4Ob97pW6xtO3BCjFCqph7BpIlZtO2gyarYVww4uGmLUgrlBxDVXCXK Tg8L9d3N7dH4JSx79wExT4dtZEb5m2/D3fe1QAOPI1TkjHxrB/3HtZxP6N/v/dsYQNXRHz+xP5x+ m5KKpb9+4XDeht6eOVKAAhSgQPgL+NUv11ddt10uHFqRrHTyh6Z8gzeHtEGNGPnPtQGLe1TC39br y9VVrGDkFxXpTFauouMwQlvuAeUX0xCTUgsxKGsHMn7ah58yxARkSzdI1foSPRr+E8cKZ6Oec3EA 8RzojA3erwK5MvJ/m+gJuLl67i6tgFykRF21g/GKiytuDoXQG88hmSJdNVy46Jx+zO1BvqKvyiKk x4sqX92L/h9zurLS4xLIeaurkP5Gqoiba0pxXH9sAVHyj4S1Ucn9x7dIJETt4G8ViyR8Ps6fkBJu kwjxpFPbK+o+LDabsTjAPDu/OAT9uzXWmYqf7aDnuNZZssCimfDNm//UJPHe0GQM2z/Z9d89OaSe +pX481auHN8pQAEKUIACvgsE4R59y93htlf6pkznezpzf4PzgERLeCOOHs6yRey/AjPHdFR18sXm gpP43p9OvrsvrbYcgpbf4RO5Sorywqm92+VF1VDXYNSvHO5o1gb9R4zB9CXrUWg4ieWvWG4TsLzm 4LsD/7MtSv/L7YCrBvh/HVmTVBGuBMMFOP2bczv859BPSrmVK27KFtuC3ngOyRTJqtx+6Sv3iHnf ta8/zh8J+hV9Ob9iPV68nrdah1CsBe7i33kbijrZ84hGk9aP2VY3nsZ5pw8KE07u32fb37UBbpd/ d7UnUCaX/jiRgfEHparfWUPMJR/cl//3u/uff+DHtf95BhLj128m4rHkH7VJ/PwOuv/9K5d/3wKv n/7z9srx7VizZgM2iKdArNmQgYtO55W2GlyjAAUoQAEKhEIgCB39WLTo0MlW1u1fYqfDxcij3y52 e+/9zRXk+5ejnIYq//rtfB87NtJV3BMX4DAlnJNfMPKbuXCL5TqW6nUBmxetktab48/ylR6xJRj5 qTJCuZhaeLJ/orJJO2xaTLbX80nbvu36j7IJAABAAElEQVSj8GW29kcAJZJYMBXzl5BguEwVj+9T vthZK3cGXy/YbKum+oqbuuJiWW88h2SKYDUWDz4u7o22vHL+ia8c2m/n54tt+4L2f3EfL76ft0Gr sk8JBd/F83nrU6GCGqhq/ful9N7Bmj1SO8g5XPsJn6Qcs63FxJSYx4SZA5inJVIeoVApyrf6OIbL O4DkoU/JQpg1+lFX038o+0vmQvCP66Ks5x+/fomuj02zZdFmJnLFqInMqbbvGTkzuuKl9f9xyD74 9fPnvD25aQL69OlunYyvT/fXcdzblxGH0nOVAhSgAAUoUBQCQejoA40695PKlorOfd5Bdt4f1vVf M2ahwTNyJ9ix+GLMecR/bRuX98L7qfIM5OKK74ZkxHf72DGCy/XImNts23+ehKSPvsVZadb+vLx8 h1/9g5MfNg5H/49+kDr7ufjm7cEYn2YrQr9PeqCWUspA8jNg0dMNMWzGWhw8fUmphynvMGZNXSDl kIgmYnZ79euu7mOVZ4k/m9ANc1KPKp1hkzEPRzLXI6lHBNp/vF8dLcTLgbioirrxb3j2ox+Vdtg4 uS9eleZ06De8o8PzlQOIZzIiPz9f/DPCZMxVhu9eNf4PRmVfvlhW5aFz8e5eT0vzUwCW9luW+SuM ot12LxqN1hM26UzVfbTiPF58P2/dl9+nPUob+d5++l30nbc+1SOIgW67N1H5nHjlgcFYf+SKNXXL 58u0bg9inZRX8oi/lpgO7dcZacgUs9ZnZmY6/UvPPOrw46tBfNbZwmVlZWLX/nO2Gp04gLRMWxrp 6Vk4o/2l0C688QB+PHIcRw7uwtoZLyOiyj14VfqMhw8z4NsTKllL+o/rAOqh4/wDjuG1+F7SBYJE fL/mRet9+fePn4/3mtjKMrNHV6w7bfueIZdOf/0CP28jo+LlYoj3Sr79oKSKwUUKUIACFKBAkQjo eCSfiyg3zFsm2p9xKwpqdvXP8fnfxiPzteHEDHJNXcT1+MzyvB2a5w2r8w1afuJ5xz1clEudF/CS 5nnpFiT99btqntdeaygeK6W1GrpWPF3d+XV6y2vacC7K3XrKbueI/m7Jl016Ks+zV57rLJ5XLa7A iJf9+cTqttDtonrutNZebZVkPlboUBm98UQyWTM6efW0lOXhlH32TFXHi7retgB2E1fH9cHlg73m 55ymPWt/l3QdLwHUTymfH+etHEc5vvx4TrWu9hMZ6nIRx7ve81auo/53z8eVY7qZ3o7r/oukc9gx pvr57UX8vHDVceb+fLec+wna59qLZ7CLcU9ez6NkzbPY7X7u8mrz8grr89ydRXRuUdXP1WeBt1T1 nA/6jmt1SexOvpTZ//PvhnnDxHpK243fdE6dudl89itV2zp/1uurX+Dn7cG5fZUyQ3w+7TFoi801 ClCAAhSgQHEIBOWKvuU5Zo++k4UtU+3DG8WXJetrzNS3IDrJ1leUWVzNVb2i7hqK0+kfK1eXLNPs 2y7KJiBlczqWj73TGjrG07DNWx7ApjM7MGNsV1XKtsXYcsHKL1J5vNGYqVOtk6JpMus2GQcMH2ie l27Zr79+5VGvx7PK1V1LWtnyIwjE8hgxcWHu/F4ur7bd8eibuJj9JUZIz8K2xFW/2nUbgVF/lZ/d p97j57KYbbq6NYrqXgU5idtjlFsxxOhf60vd9vpd5AwgHjf4inJcKVu7TkOOwfNETf7Gi4x1UT8l Q/uC9hGQ9uPF8Ri0xIiSkoyJdZ7p7O5+n+D41ln2c8ISod1LWL11PUZYloP80ne86K+fUnw/zls5 TmSk7ekOEGejOPx8eulrP0Cfi/7z1qfKeAkkH1fVYyt6CQncP2oDspa9ofmMkSP1nyI+X5YNcju7 uZ52kNP2791+nHmO94D2ueWRFVHfcwTr3moV1X8fyqNqddvfG23UBAwY8x6+z76IbclPuR8ppI3k 45q9fq4+C7wloqcd9B3X2pL4c5z5e/4VHF2Nbu/+Ys2wzcvf4J1Of9ZmfltnLN3ymrTtHby25N+a /frqF4TzNkp9zvn2N0NTcK5QgAIUoAAFikAgwvLrQjDTNV48hVOXLWMiI1G1ZjziYtRfptzkZMrH 6dMXgArlYLoRiWrxNeBLNDeped8caH7W+LmILGcS8wLEom58nOc8dednQr64FSHfYJla7gYMpnKo GR/vs40x7yLO5xpwo7AQkRViUa16NcRE+9AenmsTvL3+uhTswaDoFta5G2YdLsBzDYw4fTzPezvo jRe8mupIySSG7VvuByiHaEubXfsBHWLaW5/XLa7oY2wz7W0bOjJwilLijxenEodmg/8ugZ23oamV lIsYWn32zBkYbhRCfEygaq16YlLUEvQZEVKMspWZ/8d1ePn4X78wOm/DqylYWgpQgAIUKCaBoHf0 i6kezLYsCKg67H51dvXGKwZTY94pMRP6bYiPk69e2wqRMfNxtB69Wawk4Osze/F4jZuKoXTMkgIU oAAFKEABClCAAhQIBwFeugmHVmIZy4zA4aX90Gz0LnQb9jZ6dLkP9SoDu5YmY/y87TaDMZPRkZ38 MnM8sKIUoAAFKEABClCAAhTQI8COvh41xikeATG0+IyUs/F3P4qgN54fWQQ76Ib5r2LDfIdUxRwE x6Z0UeY/cNjLVQpQgAIUoAAFKEABClCAAlYBDt3ngRA+AqYz2LB0I84VxOKBJ/uiaWUfh6/rjVcM Mqb8izicswd79x/DhQvncCVXzHdRpQ5aduyMzi3rsJNfDG3CLClAAQpQgAIUoAAFKBBuAuzoh1uL sbwUoAAFKEABClCAAhSgAAUoQAEPAkF6vJ6HHLiLAhSgAAUoQAEKUIACFKAABShAgZAJsKMfMmpm RAEKUIACFKAABShAAQpQgAIUKHoBdvSL3pg5UIACFKAABShAAQpQgAIUoAAFQibAjn7IqJkRBShA AQpQgAIUoAAFKEABClCg6AXY0S96Y+ZAAQpQgAIUoAAFKEABClCAAhQImQA7+iGjZkYUoAAFKEAB ClCAAhSgAAUoQIGiF2BHv+iNmQMFKEABClCAAhSgAAUoQAEKUCBkAuzoh4yaGVGAAhSgAAUoQAEK UIACFKAABYpegB39ojdmDhSgAAUoQAEKUIACFKAABShAgZAJsKMfMmpmRAEKUIACFKAABShAAQpQ gAIUKHoBdvSL3pg5UIACFKAABShAAQpQgAIUoAAFQibAjn7IqJkRBShAAQpQgAIUoAAFKEABClCg 6AXY0S96Y+ZAAQpQgAIUoAAFKEABClCAAhQImQA7+iGjZkYUoAAFKEABClCAAhSgAAUoQIGiF2BH v+iNmQMFKEABClCAAhSgAAUoQAEKUCBkAuzoh4yaGVGAAhSgAAUoQAEKUIACFKAABYpegB39ojdm DhSgAAUoQAEKUIACFKAABShAgZAJsKMfMmpmRAEKUIACFKAABShAAQpQgAIUKHoBdvSL3pg5UIAC FKAABShAAQpQgAIUoAAFQibAjn7IqJkRBShAAQpQgAIUoAAFKEABClCg6AXY0S96Y+ZAAQpQgAIU oAAFKEABClCAAhQImQA7+iGjZkYUoAAFKEABClCAAhSgAAUoQIGiF2BHv+iNmQMFKEABClCAAhSg AAUoQAEKUCBkAuzoh4yaGVGAAhSgAAUoQAEKUIACFKAABYpegB39ojdmDhSgAAUoQAEKUIACFKAA BShAgZAJsKMfMmpmRAEKUIACFKAABShAAQpQgAIUKHoBdvSL3pg5UIACFKAABShAAQpQgAIUoAAF QibAjn7IqJkRBShAAQpQgAIUoAAFKEABClCg6AXY0S96Y+ZAAQpQgAIUoAAFKEABClCAAhQImUC5 kOVUhBmdO7gVaXv/g99FHpWbPoruzW7zkpsRu9ek4N1Z3yKmfn3kHzuGWo++gLFjnkCtaC9Rde1m fr6zmbB7+QL8cMmA2PjHMbL73U5RjWezsXLpQny5JRUnEIeISxFokvgYBjw7EJ2aeGt7p+S4gQIU oAAFKEABClCAAhSgQKkSiDCLV3jWyIRfs75Cyts9MX2dvQatp+zG9gkt7BuclnKxaGRVPDPXaYfY MBJ7cmejeWVX+/RuY35+eZ77GhE1ulixH07ZjfQx2rY8l/YuaiQmuW2M1m+mIfW1digVv2C5rSV3 UIACFKAABShAAQpQgAIUcC8QnkP3Tb9gcmIk4ptrO/mWalaKjnRfW7EnY1oXeye/bRI279qOz8ba OpbAHNz38Pu44DEF/3YyP/88Mxa+KwH3xLQh2k4+rmzDQFUnf9iUNdh7OBvpq6cjUYqV/np7vL/9 sn+NxNAUoAAFKEABClCAAhSgAAVKk4Dlin7YvfJ/MvcALCMRxL9Ec8rqZeZxTW3rXVL2ua+OJl6S +VihHPSGeaaSHszT916RdwT2zvysbeSzZ94PZtFht8ZpPSXDyT4/6wOpzWEe+skhzX7jkcXKPjES QLOPKxSgAAUoQAEKUIACFKAABcqSQHhe0S9XEbWb3I0pq9ORW7gVY3r3wj21vf/8ciXnW8ij/N/4 fhzqyeO7L6Vjqyr6F98dUq3pX2R+NjtfPfctmYpUa5QEvDzkIWf4yChl2wNt6ivLloWou1phorTl Fnge1aGJyBUKUIACFKAABShAAQpQgAKlTCA8O/rRjfBh9kFM6P0wKls765Zp+Ly/ftufLgVKRPtm VaVlA1aM66j8AGDZmL4pB3nS3kDemJ9NzyfPgj2YPnqzNULD0e+hY5wL+cICZaPhSqGybF0ouIoc acsV7R6uUYACFKAABShAAQpQgAIUKFMC4dnR19lEV65etcVsnIg7pAn3LqV9gP5LHRKMuAqHbqRD AN9WmZ/k5IPn0S9mYYkU/I3Rj7icTO/m+m3wtBRm3N+Tsfei1PE3XsDaN8cqP9b0f9iH4R2+NSFD UYACFKAABShAAQpQgAIUCDuBMtTRz8W+zTttDVSnGqzX8wsOYFLiW9Zt/ZYewpE1g237t+3AifxA 25L5+ewpJlec2/9TG3j/FehW181hefN9mJG9EmJ+BmDbO7ivWjSaJiYiokJ19E7+0Rp/wqpDeK55 JVta/J8CFKAABShAAQpQgAIUoEAZFHDToyqNErG4t8dTtoqJC/uWu7gzpj0P61P2Gk/GtAGNgcvX lYoHfpc38/PV89fN8zBdkp/1cldEK63gvHBL/Wa4T7X5YFqaag14oFm8Zp0rFKAABShAAQpQgAIU oAAFyppAGeroX0dO6ue29r09BrknVqL1qzus6wuXj0VNsaQerq9e1ndQMD+1oXpZ63kGiydNs23q Og8Dm/xJu1u9dm0PBlWoj0nStqEfLcf2XbuQujpZebxej3oxmL1XukVDHZfLFKAABShAAQpQgAIU oAAFyoiAPO98GahuecTESNU8NB8v9LTN797gzTQMaerYuayOSgFf0md+9oPKveeljEV4NdsWMnni k5CbyB7XvnRo+fvKffzJ287h5TZ/tu1s2RLtLzZHzzjbpIrPv7QKA7cN85iWPVUuUYACFKAABShA AQpQgAIUKF0CZeiKfjSatO5ra73sVKyzdi5H4ovx7aQWNWBv+krbctdmuN3T+HEphuc35ufd8wJW vJZkY2w0DUNaebq33oAdm6T2aTMTI+ROvtwIt/4Vr0ztZFvbvhk/BzzHgpww3ylAAQpQgAIUoAAF KEABCoSXQBnq6AMVq96qaZ3kbZPRUO7Q//Ebdsqz71ev6vpJ7MYcJCVEICEhwfovIuI57PXQoWR+ Ercbz2v71mC0dIv9+PcHopqmdTysVIp1OSt/peqexgN4SI+7KEABClCAAhSgAAUoQAEKlCKBUtLR L680iTnK/Zj7+BYdlHBoOBMvtLHOvW/ddmn7StvEfGJtVMcWrieEM4n77sVIgOzsbOs/4Lzmvn57 4rYl5mdzcO1pwNoPX5DIkvBcJ2kYviOial259WLjOuzLU+2wLubi20WrpI3VUdH9YeAYkesUoAAF KEABClCAAhSgAAVKlUD4dvSNZ5CVno7MzExkZf2I/Sdt7XIqawcys7Ks2zOzTsCoaq6b7miLGe2l DYdH4Z3VP8MkVq+dWIe+0mP2IKZ16/3IX1SxVIui8+h4zdhTf5L5WexcexYcXY9npBEUz656FrVU zK4XY9GyxzPSri/Rtuck7Dp7zbpuyj+DtZMHKaMD0L8j7pRHarhOjFspQAEKUIACFKAABShAAQqU WoEIs3iFY+2u7fsQMc3+7qXoidhp2IpWqt55gZht//66T0Ga/80p/qhVJzCjT22n7dYNYtb3njEt sE7Z2xN7DF+guSp9ZZe0wPxceZrw1YhIiEn2xWskDtyYjaa+dMxNvyApsj7eVSM3bWoZYqHakoAv T2WiR3yUahsXKUABClCAAhSgAAUoQAEKlB2BsL2iH1kx1odWutNpCHdUnb748fiXeNpF7OR1R913 8i3hIyNRXRPPQw9fCsf8nH80+ePcRiRZO/lA59kv+tbJt3iWq4d3bpzE8rf62VtB1clvPOBt7DzD Tr4dh0sUoAAFKEABClCAAhSgQFkUCNsr+oE3lgGnj5yFKTYWhZcNqFqrAeK899sDyJb52fBMSJvY DonJP4rVnmLExReaERe+ApuMeTh96jzKifYzGQyoUL0WalT2ZViArzkwHAUoQAEKUIACFKAABShA gfAUKMMd/fBssLAvdcEBDIq+B0tERVpP2Y3tE1qEfZVYAQpQgAIUoAAFKEABClCAAiVJgB39ktQa LAsFKEABClCAAhSgAAUoQAEKUCBAgbC9Rz/AejM6BShAAQpQgAIUoAAFKEABClCgVAqwo18qm5WV ogAFKEABClCAAhSgAAUoQIGyKsCOflltedabAhSgAAUoQAEKUIACFKAABUqlADv6pbJZWSkKUIAC FKAABShAAQpQgAIUKKsC7OiX1ZZnvSlAAQpQgAIUoAAFKEABClCgVAqwo18qm5WVogAFKEABClCA AhSgAAUoQIGyKlCuNFT83MGtSNv7H/wuKlO56aPo3uw2L9UyYveaFLw761vE1K+P/GPHUOvRFzB2 zBOoFe0lagC7/S+n3sxCXb9g5mfC7uUL8MMlA2LjH8fI7ne7RdDjee30LnyaMhMLUg/BXLUq6sTW RK3m96Nrj97o0MTbceO2KNxBAQpQgAIUoAAFKEABClCgxAhEmMWrxJTGr4KY8GvWV0h5uyemr7NH bD1lN7ZPaGHf4LSUi0Ujq+KZuU47xIaR2JM7G80ru9qnd5vecurNL9T1C3J+575GRI0u1so/nLIb 6WMc21K/59ENb6BB9zddwzacidycFxHUpnedE7dSgAIUoAAFKEABClCAAhQoUoHwHLpv+gWTEyMR 31zbybdIVYqO9AiWMa2LvZPfNgmbd23HZ2NtHUtgDu57+H1c8JiCHzsDKKcfuWiChrR+Iudg55ex 8F2pPj0xbYhDJz8Az3Npr2s6+QPe+gybN2/GsjlT8HRTDSFXKEABClCAAhSgAAUoQAEKhLeA5Yp+ 2L3yfzL3ACwjEcS/RHPK6mXmcU1t611S9rmvjiZekvlYoRz0hnmmkh7M0/dekXcE9q7Jz49y6s1V k1+o6xeE/PJ+MCdK7dB6SoazgqZ+/nieNE9U2jfBvCQ7zyHtG+YLFwwO27hKAQpQgAIUoAAFKEAB ClAgPAXC84p+uYqo3eRuTFmdjtzCrRjTuxfuqe39B5crOd9CHuX/xvfjUE+eoeBSOraqon/x3SHV WgCLOsupN8dQ1y/Y+e1bMhWp1son4OUhDzkz6PS8tm8T5HECE9ZtxMAmtzikHY24uBiHbVylAAUo QAEKUIACFKAABSgQngJyVze8Sh/dCB9mH1SV2TINn/fXb/vTpUCJaN+sqrRswIpxHZUfACwb0zfl IG/CQ4Hfr62znFLB/H4Ldf2Cml/BHkwfvdla54aj30PHOBfV1+l5LOMrKbFB+Fv3v4hlI/Ly8mEy AeViKqNydHieBi6EuIkCFKAABShAAQpQgAIUoADC84q+zoa7cvWqLWbjRNwhzbp2Ke0D9F/qkGDE VRQ6bAqH1VDXL5j5Hf1iFpZIyG+MfgRF0vUe0ALnNqQgIaICqlSphmrVqqFKhUgMeGsFzohOP18U oAAFKEABClCAAhSgAAVKg0AZ6ujnYt/mnbY2q1MN1uv5BQcwKfEt67Z+Sw/hyJrBtv3bduBEfrg1 b6jrF8T8xCR7c/t/agPvvwLd6gbzsMzFni9tIwWwbBQ6dB+HbIemXf56f9weOQm/sLPvIMNVClCA AhSgAAUoQAEKUCAcBYLZoyrh9Y/FvT2espVRXNi3zM2fMe15WJ+y13gypg1oDFy+rtTB89z9SrAS tBDq+gUvv183z8N0SXLWy10RHVTVKkjo0VeT4oSlu5FruAHDhQOYMVDe9Q5eW/KzvMJ3ClCAAhSg AAUoQAEKUIACYStQhjr615GT+rmtoW6PQe6JlWj96g7r+sLlY1FTLKmH66uXw6N1Q12/YOV3Bosn TbMRd50nJsr7U5C5DdifulJJs/PsfZgihvBXjolGTFxTjPr0GMZJe1d8tgNhN5BDqRkXKEABClCA AhSgAAUoQAEK2ATKUEe/PGLkidUPzccLPW1X9xu8mYYhTR07l9VRKewu6Ye6fsHJ71LGIrwqjaVP nvgk5CYK5gmqtDsSMb7vPdqky9XD0zM62bZtz8BJo3Y31yhAAQpQgAIUoAAFKEABCoSbQBnq6Eej SWtpCHd2KtZZO5cj8cX4dlKbGbA3Xbry27UZbg/u+PEQHBehrl8w8ruAFa8l2WwaTcOQVpWKwCnW 3u6ohD+5mOUvMipWyjcf18NvKEcRmDFJClCAAhSgAAUoQAEKUCCcBcpQRx+oWPVWTVslb5uMhnKH /o/fsFOefb96Ves9/JrAlhVjDpISIpCQkGD9FxHxHPYW5VhvP/MLdf0Cze/avjUYnWZTHv/+QFRz Ag/OhsioikpCrvrxhZCexiDGE4TdQA6lZlygAAUoQAEKUIACFKAABShgEyglHf3ySnuao9x31eJb dFDCoeFMvNDGOve+ddul7SttE/OJtVEdW7ieEM4k7ksXIwGys7Ot/4Dzmvv67Ym7W/KtnEpsP/ML df0Cy8+AtR++IFU1Cc91+rNSbd8XfPOs17q9lOSXWLDhpEPyZ/D1x1ts29o8jDpFce+AQ45cpQAF KEABClCAAhSgAAUoUJQC4dvRN55BVno6MjMzkZX1I/ZL/bdTWTuQmZVl3Z6ZdQLqW65vuqMtZsh9 vsOj8M7qn2F5otq1E+vQV3rMHsR93L0f+Ytrc/EbgmM/0P3PClISOsqpZO5nfqGuXyD5FRxdj2ek ERTPrnoWtZRKe1nQ4XlTnURMlpJdOLAnUraetLY7RFprJ/ZV5gjo0ktM0ucle+6mAAUoQAEKUIAC FKAABShQ0gUizOJV0gvpqnzX9n2ImGZ/d7VLtS0ROw1b0UrVOy8Qs+3fX/cpp2epy5FGrTqBGX1q y6va92t70DOmBdYpW3tij+ELNFelr+ySFvSW0xpdR36hrp++/Ez4akQkxCT74jUSB27MRlP5FgrJ zd2bXs9rhxYipslQVbIJYvmAal2UwyDK4aEtVYG5SAEKUIACFKAABShAAQpQoMQKhO0V/ciK8gRq nmzvREWHS+5Rdfrix+Nf4mkX0ZLXHXXfybeEj4xEdU08771CveW0ZqMjv1DXT09+f5zbiCRrJx/o PPtFnzv51ibQ2e433/0s8g+r293eyW88bCZy2MnXHNlcoQAFKEABClCAAhSgAAXCVyBsr+gHTm7A 6SNnYYqNReFlA6rWaoA47/32wLMNWQqhrp+v+ZmQNrEdEpN/FBI9xYiLLzQjLoqexyja/RhuVKiK CjcMQNWaiC9dDV/0hMyBAhSgAAUoQAEKUIACFCjRAmW4o1+i26X0Fq7gAAZF34Mlooatp+zG9gkt Sm9dWTMKUIACFKAABShAAQpQgALFIMCOfjGgM0sKUIACFKAABShAAQpQgAIUoEBRCYTtPfpFBcJ0 KUABClCAAhSgAAUoQAEKUIAC4SzAjn44tx7LTgEKUIACFKAABShAAQpQgAIUcBBgR98BhKsUoAAF KEABClCAAhSgAAUoQIFwFmBHP5xbj2WnAAUoQAEKUIACFKAABShAAQo4CLCj7wDCVQpQgAIUoAAF KEABClCAAhSgQDgLsKMfzq3HslOAAhSgAAUoQAEKUIACFKAABRwEyjmsh+XquYNbkbb3P/hdlL5y 00fRvdltXuphxO41KXh31reIqV8f+ceOodajL2DsmCdQK9pL1AB2+1/OADITUUOXXzA9Tdi9fAF+ uGRAbPzjGNn9bg1C3ulsbE3bjB+37sCBM/nA5csw107AY08OxsBe7VHT5/YzIuOzucgyRADGKDw0 eCiax92kyYsrFKAABShAAQpQgAIUoAAFwlEgwixe4VhwwIRfs75Cyts9MX2dvQatp+zG9gkt7Buc lnKxaGRVPDPXaYfYMBJ7cmejeWVX+/Ru01vOcMkvyJ7nvkZEjS7Wyj+cshvpY+xteXRRXzR4ZpUH mESsO7we3Rvc7CGMbdeljHcR1zpJCZe88wpeblVJWecCBShAAQpQgAIUoAAFKECBcBUIz6H7pl8w OTES8c21nXxLI1SKjvTYFhnTutg7+W2TsHnXdnw21taxBObgvoffxwWPKfixM4By+pGLPWio8xM5 B9szY+G7Un16YtoQeyffsvG6QVzBl17thk/EnGWrsX71JxjRXt6aih4NX8dho7zu5v2PHExSdfIt oaLLuwnLzRSgAAUoQAEKUIACFKAABcJMIDw7+sYr2JsmSyciZfUyjGsqr3t4v7YHH4zfKQVIwrHv J+Oxlq3xt+mrMVOOlvNPLM+6Kq8F9q63nHpzDXV+wfa8sg2vv7rDWvvWU/6OVjFaiKrx96P/m8tx LNeEtLnvYET/3ujWezDmpF7F8uF3SoE/xDc//08b0WEtLXkYXA7ocAjHVQpQgAIUoAAFKEABClCA AuEoEJ4d/XIVUbvJ3ZiyOh25hVsxpncv3FPbO/+VnG8hj/J/4/txqCfPUHApHVtV0b/47pBqLYBF neXUnWOI8wu2574lU5FqrXwCXh7ykBPDHd3ewLLX+qFeZcd76WPRa9RoJfzu7FPKsuNCwdEFSLT+ mNATn65OgS+/DzmmwXUKUIACFKAABShAAQpQgAIlWUDu6pbkMjqXLboRPsw+qNpumYbP++u3/elS oES0b1ZVWjZgxbiOyg8Alo3pm3KQN+EhBHyrvs5ySgXz/y3E+QXVs2APpo/ebK1zw9HvoWOcn9WP jFIi3FqlorKsXTiDaU8Os27qPPtt9Gu2E4O1AbhGAQpQgAIUoAAFKEABClAg7AXC84q+TvYrV6Uh +Y0TcYfUi7+U9gH6L3VIMOIqCh02cdVZIJieR7+YhSVSFm+MfgT+/gJ1bJdtyL8liYZ1qjkXVmw5 tOglvJpt2fUSUkY2Fjf9F7gMx40UoAAFKEABClCAAhSgAAXCWaAMdfRzsW+zdH++6Ahar+cXHMCk xLes7ddv6SEcWSNd3922Ayfyw7lZQ1H2IHqKSQTn9v/UVuj+K9Ctrp+HpZipf8AzUvxG09CtyZ+c AaxhbDP2v/H9RNQTIfhjjjMTt1CAAhSgAAUoQAEKUIAC4S/gZ48qnCsci3t7PGWrgLiwb5mbP2Pa 87ZJ2RpPxrQB4grv5etKBT3P3a8EK8MLwfP8dfM8TJckZ73cFdH+qJpOYfJjXWC9UC/iLVw7EjWd 4udi3nNSmK6L8FIH+bYNp4DcQAEKUIACFKAABShAAQpQIOwFylBH/zpyUj+3NdjtMcg9sRKtpRne Fy4fa+0cqq/wqpfDvpWLpALB8jyDxZOm2UrYdR4Guroa77b8uVg0uLY0HB8YveoohjS42Sn0rxun YMR6y+YEfDlnAOTJ/NU/5kSZ/b1ZwCkbbqAABShAAQpQgAIUoAAFKFAiBMpQ76Y8YuQe3qH5eKGn bX73Bm+mYUhTx6He1VFJ3QssEU1V0goRHM9LGYuUjnryxCeVTrj32hqwdlwrPLPUFrJLSgY+6iM/ Yk8V25iDSd2kHxKGvoa2Va4jL88ElKuA/IsXlICnL1xAfv4tiKxQGdFl6KxQALhAAQpQgAIUoAAF KEABCpQagTJ0RT8aTVr3tTVcdirWWcd6j8QX49tJjWnA3vSVtuWuzXC7X+PHpSTK1FswPC9gxWtJ NjVxb/2QVpV8FDQhbXIn9E45Zg3f8OVvsHrMQ67jmq5DmW5hwROoUiEWVapUQZXYCoiX5mewRJz6 eB3ExlbB9GxpwkbXqXErBShAAQpQgAIUoAAFKECBEi9Qhjr6QMWqt2oaJHnbZDSUO/R//Iad0tVh VK9qvYdfE9iyIq4OJyVEICEhwfovIuI57FV6kU6hA99QwvML1PPavjUYnWZjGv/+QLieK9+ZcfeM gUiUbrvAsBXITO7o/r5+MTLD4JwEt1CAAhSgAAUoQAEKUIACFCi1AqVkkHJ5pYHMUe7H3Me36CDC fWwL23AmXmhjn5Tt0vaVton5xN5RHVu47jiKq8M5YiRAtjL1W10/Z273rZxKZUp4foF5iqH3H74g VTUJz3X6s1JtTwuHFg1ByzG2kReNhq7ArnlPeR7uH3UP1uXmQgzW174sQ/f3JCtX9SdsOoGkhy1D 930dVaBNjmsUoAAFKEABClCAAhSgAAVKikD4dvSNZ5D10wkUli+PyMhr2H/SRnoqawcys8Tz0QvF dHqRcUhoVkfptN90R1vMaC8mbbNcRT48Cu+sbo/JfRrDeGId+irDuBPR+5G/uG4f8RuCfJu/HMD9 zwpSCB3llNO2DCsoyfkF4llwdL1yf/2zq55FLaXS7hfOffM6msiP0RPB/jHoLhzLzNT+2PL776hQ 9140rSFPylcOMZUru0y0Ypx9DEF8tWpiDgfHuRpcRuNGClCAAhSgAAUoQAEKUIACJVogbDv61w6v RPM2f3fC/Xn+cLSaL29OxE7DVrRSestVMHzB51hQ9ynrNfmpT96NqXJQ6X3UqgVo47pfaH3wur8j 9fWVUyqM+K2iZOen19OE7z4cJFVyJEZ3re3QCq5X//vvnzQ7hrRpplmXV+6ashtHJrSQV92+C17l VRDhdM1f2ccFClCAAhSgAAUoQAEKUIAC4SQQtvfoR1aM9cH5TlR0uOQeVacvfjz+JZ52ETt53VHM 6OOh0xkZieqaeMovCJqt6hW95bSmEQb56fH849xGJM2zKXWe/SKayvMkqOFcLFeM9W14f7NKFV3E dt4UGRmlbIwtF7a/eSl14AIFKEABClCAAhSgAAUoQAGLQIRZvMomhQGnj5yFKTYWhZcNqFqrAeK8 99vLJpVPtfbVU8yYP7EdEpN/FKn2FCMuvlCNuPApIwaiAAUoQAEKUIACFKAABShAAQ8CZbij70GF u4pOoOAABkXfgyUih9ZiiP12H4bYF11hmDIFKEABClCAAhSgAAUoQIHSJ8COfulrU9aIAhSgAAUo QAEKUIACFKAABcqwQNjeo1+G24xVpwAFKEABClCAAhSgAAUoQAEKuBVgR98tDXdQgAIUoAAFKEAB ClCAAhSgAAXCT4Ad/fBrM5aYAhSgAAUoQAEKUIACFKAABSjgVoAdfbc03EEBClCAAhSgAAUoQAEK UIACFAg/AXb0w6/NWGIKUIACFKAABShAAQpQgAIUoIBbAXb03dJwBwUoQAEKUIACFKAABShAAQpQ IPwEyoVfkZ1LfO7gVqTt/Q9+F7sqN30U3Zvd5hxIs8WI3WtS8O6sbxFTvz7yjx1DrUdfwNgxT6BW tCZgUFf8L6f/2eedzsbWtM34cesOHDiTD1y+DHPtBDz25GAM7NUeNYukfsH0NGH38gX44ZIBsfGP Y2T3uzUIwaufERmfzUWWIQIwRuGhwUPRPO4mTV5coQAFKEABClCAAhSgAAUoEI4CEWbxCseCAyb8 mvUVUt7uienr7DVoPWU3tk9oYd/gtJSLRSOr4pm5TjvEhpHYkzsbzSu72qd3m95y+p/f0UV90eCZ VR4iJmLd4fXo3uBmD2H83RVkz3NfI6JGF2shHk7ZjfQx9rYMZv0uZbyLuNZJSmWTd17By60qKetc oAAFKEABClCAAhSgAAUoEK4C4Tl03/QLJidGIr65tpNvaYRK0ZEe2yJjWhd7J79tEjbv2o7Pxto6 lsAc3Pfw+7jgMQU/dgZQTj9yUYJeN4gr+NKr3fCJmLNsNdav/gQj2stbU9Gj4es4bJTXA38PtmfG wnelQvXEtCH2Tr5lY9Dq90cOJqk6+Za0o8tb/ueLAhSgAAUoQAEKUIACFKBA+AuEZ0ffeAV702T8 RKSsXoZxTeV1D+/X9uCD8TulAEk49v1kPNayNf42fTVmytFy/onlWVfltcDe9ZZTZ65V4+9H/zeX 41iuCWlz38GI/r3RrfdgzEm9iuXD75RS/RDf/Pw/nTk4RAu255VteP3VHdZMWk/5O1rFaPMLVv3S kofB5YAObXZcowAFKEABClCAAhSgAAUoEJYC4dnRL1cRtZvcjSmr05FbuBVjevfCPbW9+1/J+Rby KP83vh+HevIMBZfSsVUV/YvvDqnWAljUWU69Od7R7Q0se60f6lV2vNc8Fr1GjVaS3Z19SlkOZCHY nvuWTEWqtUAJeHnIQ05FC0b9Co4uQKL1x4Se+HR1Cnz5fcipINxAAQpQgAIUoAAFKEABClCgBAvI Xd0SXEQXRYtuhA+zD6p2WKbh8/76bX+6FCgR7ZtVlZYNWDGuo/IDgGVj+qYc5E14CAHfqq+znFLB gvsWGaWkd2uVispyIAtB9SzYg+mjN1uL03D0e+gY52fJfKrfGUx7cpg14c6z30a/Zjsx2M9sGJwC FKAABShAAQpQgAIUoEBJFwjPK/o6Va9clYbkN07EHVIv/lLaB+i/1CHBiKsodNgU7qvHdtmGxFvq 0bBOtaBUJ5ieR7+YhSVSqd4Y/Qj8/QXKl/odWvQSXs22ZPISUkY2Fjf9FwTFgYlQgAIUoAAFKEAB ClCAAhQoSQJlqKOfi32bpfvzRUfXej2/4AAmJb5lbY9+Sw/hyBrp+u62HTiRX5KaKcCyiJnsBzzz qS2RRtPQrcmfAkzQEj2InmLSwrn9pfL1X4Fudf08LH2pnzWM7YkEb3w/EfVEDUrbjzlBaFQmQQEK UIACFKAABShAAQqUAgE/e1ThXONY3NvjKVsFxIV9y9z8GdOet03K1ngypg0QV3gvX1cq6HnufiVY yV8wncLkx7rAeiFblHbh2pGoGZRSB8/z183zMF0q06yXuyLan/L5VL9czHtOMui6CC91kG/b8Ccj hqUABShAAQpQgAIUoAAFKBAeAmWoo38dOamf21rl9hjknliJ1tIM7wuXj7V2ftVXeNXL4dGUrkop nnE/uLY0XB0YveoohjS42VVAHduC5XkGiydNs+XfdR4G+jXawLf6/bpxCkast2SRgC/nDIA8mb/6 x5wos783C+ggYxQKUIACFKAABShAAQpQgAIhEChDvZvyiJF7eIfm44WetvndG7yZhiFNHYeyV0cl dS8wBA0R/CwMWDuuFZ5Zaku5S0oGPuojP2IvGLkFx/NSxiLlh4jkiU8qnXDvJfSxfsYcTOom/ZAw 9DW0rXIdeXkmoFwF5F+8oGRz+sIF5OffgsgKlRFdhs4KBYALFKAABShAAQpQgAIUoECpEShDV/Sj 0aR1X1vDZadinXUs+0h8Mb6d1JgG7E1faVvu2gy3+zV+XEqixLyZkDa5E3qnHLOWqOHL32D1mIeC XLpgeF7AiteSbOUScwcMaVXJxzL6UT/TdSjTLSx4AlUqxKJKlSqoElsB8dL8DJZMpz5eB7GxVTA9 W5qw0ceSMBgFKEABClCAAhSgAAUoQIGSJlCGOvpAxaq3avyTt01GQ7lD/8dv2Cld/Ub1qtZ7+DWB LSvi6nBSQgQSEhKs/yIinsNepRfpFDrwDTrz2z1joPSseFGEYSuQmdzRt/ve/cwvUM9r+9ZgdJqN afz7A+HrswD8qp8YmWEIvCWYAgUoQAEKUIACFKAABShAgbARKCWDlMsr4OYo92Pu41t0EOE+toVt OBMvtLFPynZp+0rbxHxi76iOLVx3jMXV4RwxEiBbmdqurp8zt/tWTqUyOvI7tGgIWo6xjUxoNHQF ds17yvfh8H7mF5inGHr/4QtSVZPwXKc/K9X2tOB3/aLuwbrcXIjB+tqXZej+nmTlqv6ETSeQ9LBl 6L6vowq0yXGNAhSgAAUoQAEKUIACFKBASREI346+8QyyfjqBwvLlERl5DftP2khPZe1AZpZ4Pnqh mE4vMg4Jzeoonfab7miLGe3FpHSWq8iHR+Gd1e0xuU9jGE+sQ19lGHciej/yF9ftI35DkG/zlwO4 /1lBCqGjnHLalmEF/uR37pvX0UR+jJ5I5B+D7sKxzEztjxG//44Kde9F0xouJuXzM79APAuOrlfm D3h21bOopVTa/YK++pVDTOXKLhOtGGcfQxBfrZqYw8FxrgaX0biRAhSgAAUoQAEKUIACFKBAiRYI 247+tcMr0bzN351wf54/HK3my5sTsdOwFa2U3nIVDF/wORbUfcp6TX7qk3djqhxUeh+1agHauO4X Wh+87u9IfX3llAojfqvwJ7///vsnTW2GtGmmWZdX7pqyG0cmtJBX7e9+5gfo9TThuw8HSfmOxOiu te1l8LAUcP0c0hbVVV4FEU7X/JV9XKAABShAAQpQgAIUoAAFKBBOAmF7j35kxVgfnO9ERYdL7lF1 +uLH41/iaRexk9cdxYw+HjqdkZGoromn/IKg2ape0VtOaxp+5lcx1rfh780qVVQX0b7sZ36WiHo8 /zi3EUnzbNl2nv0imsrzJNhL4nIp4Po5pBoZGaVsiS0Xtr95KXXgAgUoQAEKUIACFKAABShAAYtA hFm8yiaFAaePnIUpNhaFlw2oWqsB4rz328smlU+19tVTzJg/sR0Sk38UqfYUIy6+UI248CkjBqIA BShAAQpQgAIUoAAFKEABDwJluKPvQYW7ik6g4AAGRd+DJSKH1uIWgu2ubiEoutyZMgUoQAEKUIAC FKAABShAgVIvwI5+qW9iVpACFKAABShAAQpQgAIUoAAFypJA2N6jX5YaiXWlAAUoQAEKUIACFKAA BShAAQr4KsCOvq9SDEcBClCAAhSgAAUoQAEKUIACFAgDAXb0w6CRWEQKUIACFKAABShAAQpQgAIU oICvAuzo+yrFcBSgAAUoQAEKUIACFKAABShAgTAQYEc/DBqJRaQABShAAQpQgAIUoAAFKEABCvgq wI6+r1IMRwEKUIACFKAABShAAQpQgAIUCAMBdvTDoJFYRApQgAIUoAAFKEABClCAAhSggK8C7Oj7 KsVwFKAABShAAQpQgAIUoAAFKECBMBBgRz8MGolFpAAFKEABClCAAhSgAAUoQAEK+CrAjr6vUgxH AQpQgAIUoAAFKEABClCAAhQIAwF29MOgkVhEClCAAhSgAAUoQAEKUIACFKCArwLs6PsqxXAUoAAF KEABClCAAhSgAAUoQIEwEGBHPwwaiUWkAAUoQAEKUIACFKAABShAAQr4KsCOvq9SDEcBClCAAhSg AAUoQAEKUIACFAgDAXb0w6CRWEQKUIACFKAABShAAQpQgAIUoICvAuzo+yrFcBSgAAUoQAEKUIAC FKAABShAgTAQYEc/DBqJRaQABShAAQpQgAIUoAAFKEABCvgqwI6+r1IMRwEKUIACFKAABShAAQpQ gAIUCAMBdvTDoJFYRApQgAIUoAAFKEABClCAAhSggK8C7Oj7KsVwFKAABShAAQpQgAIUoAAFKECB MBBgRz8MGolFpAAFKEABClCAAhSgAAUoQAEK+CrAjr6vUgxHAQpQgAIUoAAFKEABClCAAhQIAwF2 9MOgkVhEClCAAhSgAAUoQAEKUIACFKCArwLs6PsqxXAUoAAFKEABClCAAhSgAAUoQIEwEGBHPwwa iUWkAAUoQAEKUIACFKAABShAAQr4KsCOvq9SDEcBClCAAhSgAAUoQAEKUIACFAgDAXb0w6CRWEQK UIACFKAABShAAQpQgAIUoICvAuzo+yrFcBSgAAUoQAEKUIACFKAABShAgTAQYEc/DBqJRaQABShA AQpQgAIUoAAFKEABCvgqwI6+r1IMRwEKUIACFKAABShAAQpQgAIUCAMBdvTDoJFYRApQgAIUoAAF KEABClCAAhSggK8C5XwNyHAUoEBgAsaLZ3Hm8g0g0pZOhSo1UaNydGCJMjYFKFDmBPLP/oJj/zUg MlL6MEGh+Fy5DQ0b3AZ9f9RNuHj6NCwfT1Vr1UUcP5bK3DHFCpdcgeCf7yW3rpaSGfPO4LzBhIqx 1REX9O9IRpw9fgYG8UlZMz4eMfo+MEs2IEvnp0Dp/vsXYRYvP0W8BL+AjTNW4CQixNkahYcGD0Xz uJu8xPF1twmHtqzEnv9GoDx+x58aPIrurW7TRL52fBvWpJ9E+fIQIeLRvX97VNaEKPkr59KXYsnO XEQ7ftmKisM9Dz6EB5vcofPLXMmve+ks4QWsmDgE/ZO/1lTvrim7cWRCC822sFgxncHaWWtxxmNh jSh/WzsM7XO//Vg1ic+GheKzoUB8Nrh7OX1miHN+wxJsOpUPzekgzoXGLVrioWZ1tNvdpRvA9nMH tyJt73/E5wlQuan4zGmm/cxxTtqI3WtS8O6sbxFTvz7yjx1DrUdfwNgxT6CWphLOMQPZ4n85A8kN KO35BaZTtLH3T6uFe8ef1mbScCZyc17U9/euYA86RLdAqkgxeecVvNyqkjZtrpUhAX7PKmnfs4J+ vpfoo9mA+YmVMDwNKJLvSNd2okPMg9bPunf3XsErzfhZV6IPh1AUrrT//bN09IP5Mh1fbPnhQPnX b+nRICZ/1TyjvT1tNJpmPq9JvdC8cbhqPxLNOw2aAGGxkjWjk+KntlSW7x5p/v6X/LCoS0kr5MHP nrTZdl1kDtWhoeQpnRdN2rc3NxXLQz85VNJ4fCtP/k/mRNU5rhyXjtsazjTnqlPM3+FTPNHRUMW6 ap6nPucd88Ag89K9Z1Xhg7VYaD6990vzuB7qzxOYW0/Z7SWDy+bPRmjj2H1GmvdoQLwk5dNuveX0 KXEXgUp7fi6qXAI3Hd/8oXngwOHmsWOHWz9LrMdY13n6P9OMP5mfls6t6XvV518JrDyLVMQC/J5l PZ9K0PesoJ/vRXwEBZa8/W9+l5R9PiWlfMfy5XsdP+t8Mi1TgUr5MRH0QSuH078Sn5H214qVuzB3 wJ2IsW8KaKlSrCp6zlLsOD0OPeKlEQPX9mPVPNV+VJJHSas3lvjlyCi5kgkYPrY9KlpKfP0iUuYt s5X90Bw8Uu86DhgWoWmwYEu8SpAKKF9NvloAU5CS9JyMATsXrbIFGTAPv302DDWDftZ5LkHQ94rR wjWVRC3HaEtxfCobpIXrMNe8ExXUm6Pj0GP4ANTDn6xbL+yah3XZlsUEDBze0nqcXxfpJNymveyt nA4i3LBXeuNW/IrM5PnWX+SBxRjYfDF2rzqKj/rcqc5N/7LpF0zuWB+vpjknUSlaHirtvM+yJWNa FzwzV9rXNgmbpz6K85+/h2dSLJ+Lc3Dfw3Vx/ud/oJoUJKC3AMqpK9/Snp8ulOKJVOexcVjymC3v o/dcQYNnxGfM1eIpC3MtfQL8niXatAR9zypb53t51HvsWbTHCTS+1frt1/sJFvLvdd6LxBAUKCkC Qe5y5CJN7tTINdy4CPvyBqFNkYyfP4BVm4+gx8jG1twu/bQRS+R8S8N715fw0fRBytDk6R9Nxsxh tTF6qaVyizFx2Xh8JdW9NFQ3FHWIjLJc0BevSlHaTqhtaxH8XxFyR7Vfh7bh38l3EOo8exnm+noM lquHUXOtB681laOLrmCdpYMijvP5c+3HuUMW9lURbsa7Urh338e+tR+iWe83rftnPPkcul3Yig5x 9uC6l4xXsFfp5CciZfWzOP32AEy3/ijhIdVre/DB+J1SgCQc+34y6lk+YVu2QH5KBYyy7Mn5J5Zn DcPYYAwX1FtOqYR+v5X2/PwGKRkRCuUvuQEWJz/A+IxeWgX4Paskfc8K1vleco/WaLQfv0D8872E ur/XmYPcBfK9yAxZwgRK89+/4B7ll/ZigfQF+c1ln+KXAYNFxzsVX+/6L9p0+nNQm7Vp06bIzs7G ipmbkSI6GtVgxLbP3/KaR/7Fw/jxu23Yvi0DOcfOigk5LK9YNG3/OHr16YU2DW51TsNyT/LCNThT UA3tej+IcxtnY/bK3TBcvgxzrQcw6B/jMbh1Hed4gW4RV53F3EhKRx/RtTBq+ldYsLQLLH2OiAIx AZPLlxH7NnyKuZ+sws4T/4eqEZdgbtoBz784Fn1a3uEyhnVj3mEs+teHWJR2HLGxsajWqANGvPg0 bj7yFX449j/c8eAT6NRE5SNcNizdiFOGCmjXbyCaauZiEGVYswLpZ39H/fYO8ZQS6Cxn/ilsXL4Y q1em4cCl/0OVOjG4vXpt3PdAIjp27oiGcVFKDhDX7S33eKee+x1RYvPRxdLVdfED1Iy5/0+M+Siw hi0Qbw/1C9J8EtLxckm0XBSuYP16W3FWfDgdbSPE1W9LZuJflfv7oI/DHBPWkMZTWDtvOj5e+ANi xXFuEMd5jfZD8eK4wWgVf7OqbtpF08U9WLhiBwqiauPpEV2Rn7kKc/+1DDsP5MNc53bc06gF+r4o 0qjhPg1tit7X3B+D3uMqX1gcj3N3UTXhYnHvE2/g7Jb/ocZj74sYqUhZvh8dxtzjLrbv28tVRO0m d2PK/2fvPOCzKPL//+EkJHAQjn6AZ6gSwBBFkSaBBAu92KkKImCh6P0EAQsqSjsFUcGgIB0pHlWC hUQ6CERIMIRDkHAGhEACCQcPJv73P9t3n33K7j6bJyH57uuVPLOzU77znpnvzOyUfWMehve5D1XK urCEfz/hZ6B/Oe1brJdimfz9S+Ign7+/uBPbJHv+59/fHWUD/fYaG5tGm3LajA0oqfGx+rZi/kZc ZLX1XqYD2uj0mBstVrc3sbaAP2fizt4jEBOh0TVW623A+tNNNpO3/Dk2s2e8jzX7MlCtWjXUaf0k Xn4qErVM+rfljJ3PkbR6IRau/gYpfJtUnUOluneia++H8UiP+wyH/9ltpwNqjyy1K1oKNtsxbRAm zba4mAzbkzPqZznYz5L6BcHpR17AN/ErcZzpqdre+hmKPGUQcV9/dvaMpm/nqTB4s3NEf4rnQuz+ PZ9pYelifaQq0b0M53CJT53p14WXy8WpxFWYMWcp/pN7CZcu1kC3l97GxCHtHVuFzMsb7HrLx2m/ PxiAPrOo53k5YbXdFDzZT1+RtH+SzEX24+Q+jIyNL3AsIeyvL3cw94K6t3bYZi7fkYiucIt7i/tf +3+4gntHMq86zQJ37eH6CHEP5qZP6K+RQxvxFe6jKG/7Z0X70cs87Js2sSe5x+xdDqWR41LjnxDl j/Gw57LgsLKX0uP+pdw07h0fe5p7TEvirmuRSGZXxtd+90+zg1H0PjVc9PuqeWfqPiuP+5ptyllw 9jufcjaZelgvI3eJm2nY1+25DLyp2xvuFoyVW7YXnd+DL9YFH7+TDxhC5fNBLMee/U3dcsrgR7bI S35fijOOGzuxp8f4DXkoe7byq9nP1H2eh/piMiyf5VwJQ63z8FgffuZGyKw9PVfCCcSgyuCxzklB p8Z3UfhvV/biX+FWDHTLSyan8jgQsQx+zclp8GbbooTEpzk7Ytz353zTyPpWqdtanWer3gaiPzVS mqtHooezOz/wqBe0usrpPfp5J9f51GlGnR14O63NGzHlvtsj6+2KlAE22zFN9lkw2uRiIQbRqVqv qZ8Fx0dSggAAQABJREFUzqPOt5PvmvqurW9as5l+pLn6/hs3RW4X3c/KkcqD2l8AN2rLGculRPHg gP7kvPTTPPYdhYgD6Ndp+i9a9jrzmE0e+8lKmi0ZglVv9UKp+WuhP2inXEvRWtfzbNgW5P5uUbR/ +lwpmru/sMLt0OXC7tWfiGH17IrmlWqgbR9pE+Hnm5HmcigaKRiuUlP06fu4cLc+8T+4eCBBmE1r +upj6BSlvBP0Emk0xkyPR8KOfUg5loLENbPADhcTrjkD78D6jD/1/nR7ktmjO0Zi/b50pOxYCjYo E67NY+/Dx8kOb5L0cBjo1ZTdyvaEy1Lc6s8FfNS7mbK3uPmzM/D9oRQm53q8FCvJ+Wos3kz4XfUi mDLxr4ju0p5ntpL6rZU4lMLOVhjbQeeusfv+ZA2XMPaVA/dLXrJu3NdsV04XNox7QJKT7deetgL7 2Gz3vh3bsOaLaWJelOHPRtde4Xh43xasYdPqCQkbMIOdOCVefbEwIYHNtm8Q/9YkYGATh2a6KzbB x1K4CQnLMIKN+oWr4xRsUOJcg+1P1JMeyD+ZeJvlw3rptufbi4T0JS6fLDvAhG59seWsW/mUn4bI 5Z7Nbr+3SbDtOWEOi3MDVnz4llLGZedO/H795XpsTUzE1q1b9X8bN2JfxlUnovAdxi23omVvycmO ZPzqsJ7xHbn+6eUrUv1vHofbpK1KF5PeR39+NYD2KnOF/xgaXcWFAKuvfST9uPfgSZ9SXT51QFrY 0RedmsgK2ma9ta0/fYro/SE7bfr5Di8rz8cvT8SxY3sxZ0SkYue44fJe9G7YV9FpHcfMwQ6+TTq0 nemk0WJ0Bp0tS2G/nbbWHtlpV3gZ7bZjcvrs/lrkYjca5o/6WWBr8twvm/muqe9CiIXaj6yLfmtf EAU/NgrfnRRXLqopKUDSkk+l25F47oF/qI+smgLWn3yE4ei5bTW+WL4Ga9bMVvoqxr6jLJyD/TqW D6tZ32FfwlwlXnz4Gra6jwPkqG3/Bq/eCiJa7g/aLNd8ZLb0vM12U+ZvNX1F0f7Jshb1r2PvF9hb PTboFWYL+kmzfHmpnyuzB87MEqhvmrvPO84VnP1SDL/TIG5E7+aCeerei9zJFY9J8fIrC7QpzOdO p6RwFzwtLzi7WZkpfsb9SwG6N4Ds5GxtmNoZZodWLihvbDvO5H69fp3Lzc3lcrMvcKkJcxUZWbnh FhzTn7yfs/9dhfewhe6nlZ7n4qUVEMAk7lcNlhxlJph/e62dtc/ntk5or4RpeLOt4WLMXzWv3P3Z lZNfJaCkIfJLTQpk4xXuQran9Qryc45L15y679ul6icw03VlFYq/2e+snWr+9Zi2Sxdt1n55tp4/ +V3/THaYl/qxklfsSDtuwaEs+ZH4e/0890umvszoHZi80+Q7Xw69/flbPaCUc58z8Wo58jijz9bR JL7TTpKhbyF9ZUOVwb0sq8QuqV8EkU8/dx1WVhv0YyuF0tcOKQZyqhIHbjLDJfBY1BAKL77906Uv ncRovhSRL+re69fVBkP5IgrTzfIXX2zXW009sqI/VR6iyVw94riTa59W6upk3cqFK9wizaoToyzu MZq/V7gyPTF6tfELPAWZe7gte92/mhF4O21Mg6+yY69dsd+Omeend2mTiz4QE3cqK+pnOdfP4jT1 HbDfjzRb3zlNn9wwM6575rk/YaKgKE6Uem5DfyqBKIZ8bqXUV/Xe3iqOBYOlfp02H5pP4tI0HUGX ZsxiXBWkj9P8XbDqrV4iq/3BQPSZkv8W9LztdlNKptX0FUX7p8+RortzbEb/4uEk5a39/Z0aC+8v KjZqC7asVrjiNx+VTM788HuDb6kdi3f42dIfliJ+w8/MMBjd7qmG/DxvySqLiKgo1BBOJihAXk4W snJykMP+XBWbo4s0q3P84jWvQnafNwJ3a0+6r30/XpvQUHSvW7ngwsnUZCSnpiLV319yMtI9zX5u fwX1y5cX9suHV62JqK7PK7PZk9cfx9BI7Qy0C9sWTJLkjsaTDzWFK09MG5++HFc4Og56UXqehjM5 ahJ/O/CddNMXk4Zqv+teFg+NmgB5Qlr1EYjJvpy6WBtn4bTh2Pxw1KgSpnPmfqPdFx6cWVV1hYG/ /ey/p+2UxO2LV4a314le/d6nwT4tKVw7t6RBk306d/JN93mLMNR9z11YTTR0cH++HBe/j9Pwxx4+ dKs84ym7LIzfsqhRU52NYJMmRXSxMwP6PCnGzSb2eTl2zXwe8bxN8ymYOYAdGHpJ1StFJ6coIv3X E2jQ7j7RYscBnJJO5flxVpyge8u3/FSqb7lI3ZYguOsQ11b5coKT9VYvlZN3udi1dJEU4BQM6/x3 TeDheHL8x5p7p4ynsWG8yIu9pMNkD1/FuKVOW3Q1nFMSeDttOwWm2xWH2jFLggafC/WznOtnabPa fD9S68uiuWIrjBzbSPC089Uv8Yumv3QmaZ3SX3/x0XssBmx0Hoj+NIZ2DWqvyfjUk43dft2oN59B U02XMbTpPcqYZff+Xz1FZcMu+PXWXUj//cFA9Jk9Pe9ku+k/fUXR/rnnQtHdC0PewKMvwKGEhVIw kxAXKa3jDmuGvkzRxM/+BelvJuD0G+1RL/DIpBD4YVpN9HnhCbw+YpVoN+xxtGAp8vlKIY8ddDZv Ft4eP8fr2Vr/CPXeDb+/VWNDCiKiYpgdv+TzPK7xYvGK4+pPGN6inbIcntn4vNjsJ9LHawfZPpyP noE3e7t/SuwPXDov+zmC++tqtJdsrfyuw5nzTJVWEfPp2uUy4hNhy4XiSDTUaIIezOTnHDI3T75u 7csJ9gG2iPpS2JtGoX7IKAyYMAPd2kQhsn5jNI5q6OgBKr5SURjPlKXfMV1xl7T0W42nKmKffAJI YmXdxNLvwQ80Vb0Woom9cccmJw7AC0DG/GLxXbFrSEv8UkzFrZWQfWoVOry+R7hfsGKs8DlCrV4K zkumAKCWMq/VI1sJyzYT2ddMjmR+hrsjL2P70r0Q3nKmrENqzouICf8NezaIYDq3l17uslsn620w sDcbHW04eC+0cWsMYpE7+tWaqxeRJiWox8OtYFBpvhIbYDvtK2jjMzvtSiDtmFEC0zZB5cJLRf0s fd44k++m+5H6yC3elUX7Z8YCs/kJng+wds9EvBpTjZmzsXUBO7mIv2I+wgMN5S1/opWd/4HoTzvx OeWnaWRNfVC31Ee73mATh3rrgO+CXm/1EvvvDwZQrm3qeSfbTf/pU3kErf1ToyxykzMD/T//g3Xv 8QNd/tqL3Wy/bsoff6BcxXI4eOQX0RrvYlf6G6gnvwSQbAP9adqlLwtCHOi/OaiN7+DyjmBk+J3i LJvskp+NFMxs36A0ms3zepo9c1hG81pUCqNm5B1yaMJMnnATEqL51rjy2KvBsP+dd9lxJtLYp72q s5Pjc39PwcIx9+O9pGhgzkN4tcsZTOuqzmTyztWhfTSbYeVXaXq6+HSyMIR3pvxAPxtHtkqzLpsy hFP+tQsWULYmmjDFBwcVnz05+bSwFQZvp+GdI+o5BMunjsNy/pFwsb2gx5agt26lg/ysuP9m41gC G1iYubbvEWYda+oySutxMBrWDbzx1oZYfM1slnXLVkW8ohtAl0MlOT+OfoYX+iYKMkW+lYShLf6q yCcaaqGy93eJbm7pNigEqjdDLGsIElkbsCf1PIbemo6tqXLMiUhMvYKYxqlS2xGNVk1rSA+drLdy fIX7W61OLaZJg3CxMi5Xic6t5Te0JuJ1op02EY3qxF67Yr8dU2O2ZAo6F1U66mepLBzJd7P9SDVa W6aKd/Rhq15fxOtMr02I34GxMX0Rdm47PpH6c6Ne7m3tBZw3KWzrT28BBsf+Rr6xP+94zEVYb8W0 mOsP2i7XtvS8k+2mufTJ+Rq09k+OsBj8OtLeXz2WpBk8J2JgV7GT656+L39Iw8DIO92tA7q/5bbe OP3LMTZALY+6EfzbSu/X0ZVTFTmHzf4Gbw2NQZ1KcvHOxZI+lfGUnwFtaIgRmevyFWOkofdgCcex +aEArvDKuLVGFaGzVKNGZ7ybcBiXwsQXFdO7vYf+1+ehhSy+Nhr2vfFdGwcrnSztI6O5LCrWlWxj Ijx8W76AfbjQzlWAK7l+/FmSUwqLHcL4WmI+Bifvwa4DP+HALnbw3LKN0sN16NP0FZzIn6d+2syP CMXncQU1Hyp7kSpUfnlT389Aka095ke8nsqGl6BvXus8nD8lSR8TB/alxSK6whDVga24WMZeOqYk SssiR+Lf4zpJ8uTi0E7xhSR6tsStpSJviigrbEVbC+27s1n6lJPYfewkTtXeJazGioqNRWpSElb9 cBSD/1Tmp9Gszi1SLE7WW63gJvSn1jlv9qY33N15vC+EN09MBzFNJFw/HjsPtDEnoBPttDGJfngG 0q7YaceMAvq1KRwufqMVHFA/ywOnAPLddD/SQ7SKlanqVBePvToEr/f/AljxMX5a0BdVN81XDhR9 Kk4/WaSEbdlgV39ajuim81CU9VaEZbE/aLVc29LzTrabFtPnsQQVQvvnMZ6isfS2md2SNGlbvlbc d+o9CAMHDtT89VL2eH+9chc7p9bpKwwRDSMR2TAClYxjcE1kLhw/lize91+Jj8Y8qBnkM+sbv+J7 P4N83nPGb9liGJr//z16QLnjx1eOXe7vD0Kj8ebW/5OC/xTTvvqPLiplQM5G2ObfU4aLAxQ+pB0Z uKQLkd3cOAV2aLuXS60choaL+UtM8uzNnpzasMritpYx6D9iDGYt3YD83F+xYkJ3ycGn+O7I/7SO PZtNNZKevRaOLT9Q7CIGzVZWnDdkYAF+PfyT+LxnJA0UpUz489QujEuVbm6vw87uLbqrQrXqusin bp+i7v/78zfsXSY9rlVNXfmj9eFKw6ToMoiOjhb+ypR5DofkkZLWnVPmkh6fJU5lEdmxr+Aj/dD3 +OorXnlF4525HwrnwKQn/Rtrvxfbj2aj2+BWJexA6q09/alE7W7YtMvnVydkvbtzy37jGR/Zv+GI e3iB3petoGwROPyf0yZDC6SdDpSntXZF5sm/0Taoa5OpNe8sEC7mY/HukvpZMhsn8t2RfqSf+i7L 26TrU9Jp8on48suvsObLrcKjpq+O1J83JXuw9WtXf9qKzLunYtevK+p66x2V+xPb5dqWng+k3XSX 3Ny9nL6gtX/mxAqKKwcG+pn4drl64M7G9UuwdOlSzd8GLJrTVUzMjs9x0NunwYKQ3Irl5f04oYal i2e+/czU/sTp85LcZrgz8fXncvoLf0ax9kMvYKLEauXAWTgml142xOkofW4QO0ZhXYr3wW6BW68k pFIFKcR3kZCiPwbl8oFvlUNbDFmUn6/M2BxK0b/CuZq2w4s/+3Ia4pcsylaqh8f7xymPfS/Hkt6e nLogbFNQPBUDQ7XG90pSvIu1ByU5ZbmuHsDC2SfEO7ZGXO3Syg6K5pfzcZ6FP4lC5BUKlUPNpcfd Xc4RTB32pBLN3NEPFdIiBvEsCz4iX+mNaNVZkQVNP8ILwn5I0erijlXKaqJRD7byLGcB2+fPllim sD1E/B9/5oe1F4fm5FSELOnxKQk1Z6jZtJ3ocOO7GDd7JztEsQfaRkaxmf727MDXDzD+vc3C8873 Nde1H7brrS39aUxLvVb8GTH89RtyvBaYcLTqLLfD67A3S/Qh/z/+7RIHz2GRQg1rgI4DRfOxadPZ Z0Hl2PS/Lpe+QbLdTjvEU5bOd7vifDsmx+vt1zYXbwEWkr0TcpbEfpYWdyDpM1ffNbH9rTWeHy7e zxnyqPL55VH9mV5z8LKrP50Rofj265yoD84w8hVKAPrMpp633W76SobXZ0XQ/nmVJfgPAh7o/3lm l7D/hxe9e792HpeLN46VZ1uP4N+7zwQ/lUKMbLq/zO9i3Csexr8Sf5XkYG/cNk5FRK9PzMm16Sk8 8+FuaYCbjU1T2GGAfJ+cXf2GP6icxCzaFMb/ehix8QUp4E/xvmZWv0nvscp3QJ+J7oVPE48rLyUK XDlI378Bk/qUQewnh3WCNXmgn7Lq4vnoCdiX9afw/OqpLRjSYZLOre4m7G9oJlksGPhPbEi/LNxd Tl+PQS3/qXOqvbErJ5CLxYOa4tk5XyE146Iyi1KQcwxzp38uRRGHqIbeX+uGVKotuvv5NUz68Fuc lb66kJOTp4SnlTWY5tp3xSn5N6HtEIUnn76ZvdopL06mjnjA80AxmMJKcX29Kwn72Vcj9u/fb/jb uf+48iJIdJ7LyqDoLjl5P/YdPidanzqCpP1iGDt3JiNTeXnllqBNR7A7/STSU/fhqzmvokzVO5VO C3ouxsCov7p5CODWlYnknTuFNCUn78ZhSV2cZltGlPQmn1LqFx/TLbd1VL6MAPbt4nfX/CyUqaun 1uOJuLclYeLw6P1elkuytzfuOw/8vtCxIadCpaTHpyTUnOGWOlF4SeO0w+P3C/o8qls3jS1wb8s6 unvb9dam/tRFzm7KV6smWSWi04B/4VDGWZw9m4GMjCxd+WzWvZ/irvtj7yIlR9TzZ3bNReTTq92D deA+DF1ffl+Ns+7DWJN8TtKz7Ks3WceweGQZ3PmhtFJJcBlAO22bp712xX47ZgdtAFzsRGfbj0Ny lsB+lg5pAOkzW9/V+MLQeaRcDyVb9iWYXk62lyxYu/pTkKjAhby8PPbnQoErW9mOd8X1P7iUZ3nM rKZKayq+/TqH6oM2sYVktq/P7Oh5wHa7aTP9wW//bApaGN4C/bKf8v1KNtnl/l13JWzN96RZh5zT foZecWPKoH7v1tf3NVPju3CMFfvTf1fblf6ZZC99+5udWNdCcKf/FrghbO13Nz24F+OaxJ1QP7ds KjXeHPn9TmrBz8r3ufnvsR7RfAc0Y+sb+jR6kNfwTVUmyP450nekJfdRsVGGcAxcmD+VtZ6hyES0 8+TPnpxXuPmx+njYZ930cg77itPgMCLO2cOxuX+9H+ne+O1lo3frNubKrByuez5oOQrm/ou5bNmx 26/6XVF9uXdzFvgtqw99vDDUyxut/649+3avN/Zaf/rv16r8tG605phXVyrfNA88cWIIecnveywj 2niBOH36mFfXyS896hTZ36jVp7yLmOfOtS930I+ytCunIERJj887aS9PrnNrh6u6QSmHTGeo5X0k l+ZBz9utt3b1pz4BernlsmYsn9e5rRMb+i3XzurBfC5xRjefcbq3R7bbaQbFHk/77Yq9dkyfe2bv AuFiNg7RnapzPbXdclgqa317Y1vOkt7Pcix9Zuu7nFP876/cxBaqbuu38Kj2oUNmvVxW9GeyW/9T 1WGqzLzdfbN/8iyrlX6dpv9i1HXmyr5nITzb2q4PnoMzbWunP2hfn1nX83xC7LabvF/r6SuK9o+X tOivv7DKE8DlwlF53zBeRttGFT2HFdoE3cc2Fp+xWbnfvLyV8+xZbyufbF3Jx5LhCpUaSZ5qoYJm Siy0yTBk7PxEmTXlj9kXJ+OjMTthJ1aMvV3w5yvsARMmgHX69FdPdjp+7hTnDoBTljTro1HubmmG l1YMkW4/ReJhdZn3bQ+9hSz2OagRsYprnaFTrxEY9YDxBOR7R/0bO+OHKm5Tk8SNzwPenoOJXsLi Hd8xfDnWTnBfAibyXDS8iRBepXBNJkgx2JOzHBr1eUZZfcAHJS5xFgMdww5YzP7sYd+z3X9riy2Z ezBnbE9JEvUnvCx7+1oIV6g0TVsrvILf0O8dtRHJyyfr0ih76j+NpW/5YK+n5IaEyCfts6X9RuRy MA78hhhmnj0H2lZX/xBSAZIW8Oxcsq1ZQZsP5VCtllgv9Z6iMWDMDHyfkoXtU590fCVNSAUzu/1v 16ePCRja4AnsPrlO+FSZXl5g6vrjmPOYse4p7lim1VJueINUcHR2+hu7cgqhlPT49KhM3IXhrk5D JHeD8UBzaWXQ35qjb2/Jun9H1NcWT8nabr21qz/1iQnDI/GXsPXD0W5641a3LTFheOjdZGydrm53 kcMZM/1tpV0L5TwkUHZo+bcsYl/5Gie3LVDC1wUR1QdDOjbQWQXSTtvjab9dsdeO6ZJr+iYQLqYj kRxSP4uBKIR+lpwPgfUjzdZ3OTb+tx7aKk1PNAb2aK596JDZvv4MCfff1vFCev30taV+ndp/8dTn k/trnvqtdkAFs95q5bPTH7Svz6zreV5Wu+0m79d6+oqi/eMlLfqrDP+uoejFCLIEBXlsWeMFtuax LAquh6BmRB3fB/ndOIjBYa2EPfxzj93Ac5EuZJzMQUjZArbPOxwNI2oEOQHmonPlZOF8di6us72L IeXDUbNWTVQK892Jc+Wcxolfs5HPBgHV/l4PETVC2NcIygtfI2Bv971+Mz0n4yT7UF95lC3IR3hE BKr4jkaXAOtysmWfbMl9Xi6/IfU6cgvKsi8u+DuMURdl8b9hy9XOZmYi93o+WPahWr1G7PBIC1CL fwpLuIS5yEg/i4LwcORfymX5F4ka5voyJZxLCU+ezXobiP60Q9SVdRqnL/F7ZJierxvBymYwdEsB sjLYga9MX4eztjO/QlXUZV+V8Rqz1XZaA8Iez8DaFevtmEZgK8YAuFiJJmC3VuUs6f2sIk3faUyJ ri9uM+2/GLlswoCao4BLuLUArNYHa6E77tq+PrOo53nJbbabdhNdNO2fXWkD91c6B/pWuWkUNFvq g7Etve8Btxp08XevfnbQ10C/+KeDJCQCRIAIEAEiQASKJYGS3s8qwvSd+upFNHxUPIfqze0XMVlz UGyxLAskFBEgAo4R8Poy3bEYKCAiQASIABEgAkSACBABIkAEgkKgIOsg5n6aiNxsdmD27E1SnJPw NA3yg8KfIiECxYUADfTN5ARbOp0puXPpvz5nxvdN7+ZGrpiEKy5+qTxdRIAIEAEiQASIABFwkEBJ 72cFOX2u377BmDde02XQgpT/Y7v16SICRKA0EaCBvpncDquNMV/Mw+M3wtG2iZcDB82Ec1O6qYDo 5+dhepdc1L9fOc3lpkwJCU0EiAARIAJEgAgUQwIlvZ8V5PRVrPcwln9aHX+EhqJcxQjc2zkGjarc UgwznkQiAkSgMAnQHv3CpEthEwEiQASIABEgAkSACBABIkAEiAARCDKBAD+vF2RpKToiQASIABEg AkSACBABIkAEiAARIAJEwCcBGuj7xEMPiQARIAJEgAgQASJABIgAESACRIAI3FwEaI/+zZVftqR1 ZZ1F5qXr/CeThat81bqoUyXMVljkyQwBF86ezEQu+0J03YgIBOUT1WbEIjc3IQHpm7Ss+lar1xA1 ilm1deVk4nxuASqE10INx3UK1aObsMD6FLlwy4vPqOlhsSBQvPVZsUBUwoSw0/8sDXrCDpcSVjQo OUEiQHv0gwS6aKK5gJUTh6L/1K910TeZ9iPSx7fS2Tlxcy51G5IO/Rf8hwmqtHgIvVvWdiLYmy+M q3vRuVI7JDLJ3zt0GRNaVr750kASFw8C7NvLncNaCWVp6t7LeLVNcSpLufgsrjKGJwGFolOoHhWP MuiYFIVcXhyTkwIqNAKFoc8KMvHV3K+ULyN5lt2FcrU7Ydhj97LX79JVcAGbFqzErzfKyDbGX1co 2g8ZhrtryIfYFeDoxqXYcjoPuneuoTXQvFVrtG/ZQG9vDNG6jY/0hVavj1atO6Blw79ZD7fQfdjt f5Z0PWGXS6FnGEVQQgkoOq+Eps/xZB1d/ASinl4N9FyM3I2DUcnxGJwL8OjiUbpBflRsLMokJeHe mhWciwQFOJO8GbPf6YtZ69VgO7CXCYU50C/W+RASgroSivIqEjJpCBTr/NPIWRyMclkKK1ccpPEs Q+MwabmQ58eKraV8p3qkcCtpBrPlpaSlm9IDpW10TJ+5zmHumDHCy1CffJt+hCfYQL+K7Mh1ErNH jvXrb2rMk2ygL79gvYa9s4diPHu56fkajGWHpmGAk5McJtLXfMBHWDPvRTQtRh1SJ/qfJVFPOMHF c9kjWyLgmQAN9D1z8W4rv/29coMNcYvzlYu9i9kLCf4aMB+/LXoWdZ3O7YJfMOXBxnjdQ6NX2WTH XxTQxv+bJh9spK00eKH8KwG5XA6NujyDWJxC8+omXx5SvpeAfLebBBvlxW5U5K/0EGDvGOWXoUA0 ho9tDVxzT/41cHVvh+7Fe1gN9Bk+AI3wV8HxhX3zsT6FN0Zj4PDW4DXaNRZOdG3d3D1CwwXngrtn JzyK6jiD/VM/k14YLMHAu5fgx9XH8eFjt8sOA/vVpS8OYye0AK6Xx7WLezB/2XYh7J+Xj0Kz3FBk b3xWfZERWKwB+g6k/1mS9UQgXALMEvJeagk4PfQr8SBDQjkxjZVD9Y1GsUt5BaVB6te5o/ODfD69 rss4pAzy4zB7zTPIeGcAZgmNZeECuWnygaMq5qkk3DT550n4INvlBTk+89GFIXbc5+zPvA/b+U71 yDzkYuvSenkptkkhwWwTKEx91n3ecsSPbG5OtrKNMCp+meL2+OLLWC+s1nwZn8UP9r8Ev+fLmPOe 5O69f+Gnrz5Ay0ffEsKb8/hz6HVhGzrXUIJ3xNB93hzM0qTv/be24PmG3bGUD33TcHyZ2h/PRYkv LhyJ0HYggfQ/S7KeCISL7cwgj6WcgPOjELbvKWn1Qixc/Q1STv0F1apzqFT3TnTt/TAe6XGf58Ok XKfx1fxZ+GTBDwhv0QK5KSmoEzsML740BG0iKhqziO1Z2rhsE07nlkenfgPRQtk/xTt14ae1K7Hz 7B9oHPsIukZVV/3ze50WrEXmjb+h06CHEbp/DWZ9uhT/yb2ESxdroNtLb2PikPZuy/HFPVmJ5/5A aChwfIk0S75pMebE/z9Uxg0h/Bvsp30/7V4uNVrbJhtc+PRdZE1UKC5jwwYx5pUfzELHMuwtNy8k +6t672N4rI0D++fLVkD9qDsw7Y15GN7nPlQp68ISvt0slIG+A/lglaftjFM9hl37FUmLvsKHS7Yj 99IloGo0Hn99EkbGNVEdGUysDG/8AvELV2MvX4fKXATXojOef3EsHmt9m8F1oBYFWQexYOUe3Ait j0EjeiJv/2rEf7wce4/kgWtwK+5s1gpPvMjqYh33umhFzgDyz259l8BYTp8tPaHNBStcVH9XT27H 7BnvY82+DFSrVg11Wj+Jl5+KRC3VSWAmVv5XzN/I9EMo7mW6qo1Ob7oFzRhsYrqE3796Z+8RiIlg yk+4WD5uXYXdv+ezUKSL6ZQq0b3Q26NOCSDf5fDZb3i5XJxKXIUZc/zpa40nG8a8rGPY/d127Ni+ C2knzrIDNfkrHC1iu+Hhxx5GTKSmPbERvuqF7Q+OZ/uDURP1ql3B2rmrcOTiX9Dp+bcx+ZFK+Py1 17CMLwdV22LSog/RWeEvhmBLTqVc10SnR9vh3KZ5mLfqR0EvcfXaYvD/jcOQDg1UEWWTXX+Cf6vl hXlS4rPSTsvCAoZ61KYvXhrRC9cPJOLnS2UQ3bMf02VK6VU92jRZ1i9KPPb0hOA9GP0sSU676TPk g9P6TOGoGsrcyFdvLJryNauN2Nmn/gf6bFWn6i4cdz0yGWe3/g91uvyL+U7E7BWH0XnMnRal8O3c PX0VG3TDB4lvYGnc24LHG/8zrjO1m39CX9pKP0Sqt/b6n1b1RC7rV32BVJZnoRVb4qkB9xny61Ti Mmw++j/GJQzdhjyFRk5ta7DajwyIi+/yQE+JgCkCnINX3sl1XB+AYxF7/Gsy9bAhNlfG1z79TN1y yuCHyzvAxUlxsAOq3J5f4ebHivGzfeL6Zxp/3mTEmE3cdZ2vS9xML+lxD+NNgyy6gCzd2OOyh2OL ujyy18k6+YAlWcw7vsIt7i3G32P2T+a9mXIZWD7Y4mlKLg+OXAe4QX7yocNbSVy+B69cbhr3jlR+ dXkmhddjWpJb+fQUiDW7vOT3pTITx42d2NNj+WGHrekDtSxnAPmnqbeW6rskseX0aeLzlAeCnUFP SJFZ5iL6O7vzA4/ctfHPOuSu6/RZ4vcub4+iN8d9f86386xvFV2iZ+45Hw26Vgnds3ttumSzQX+a qEdGfa1EbMNwhfsoyrf+HL3sqI1wPXjR5IWcfu+/k7hfdUHYlNNEue4xe5dRL9n1J8jsOf+9lxfm yUR83vI9a/8nfuuRvjzrwNq6saxf+Fhs6gnea9D6WXxk7LKTvqDoM1E8jtPoie7z7NfP1PgnxLIT M5/LlcM2/Kp9HHhyV/AzN0Ju+z09N4RnwkKTPk/9Klf6Z0qZ9/TcTv7ZKp9Mp9nvf1rXE/vntFHS PWq9fpzgOvml8gwxH3HnTWA248RWPzIgLmakIjdEwDcB+H5s4WmO2onkOywdx8zhdhxK4VIObedW fDhaqHSGwQL3GzdRVorst+fbi7h9KSlc4vLJaiVFNPd1ZoFeEI3iM3Z+VUVsUHoaf0Kn6o6R3Ood ydy+hLlKB5jtyOLWndbGl8+d3LeFW7NhA5eQsIGbMUjuCPblFiYkcBuYvfC3JoE7ka31pxfZ2p1N LtwlbockT0LCMm5EC0nWjlO4DYqsa7jtx7KsiWPatQ/2psPw5jCQfLDL05ssfuzdyxkGc6v3pXMp O5bqXmq9uf2iW0DnuTmaQX7zZ2dw3/N1aMd67iWN/bgtfgZpbqH6u81L/VhT38Qy03PCHFZmNrC6 +5ZQN/R1146cAeSfhqel+i4l3HL6NPGZ1xN8ZHa4MG+sI6B9QTp+eSJ37Nhebs6ISF2+GNMuJdD0 zyWlfHWYtsunr5z970px9+X2Zmud5nPp21ZzXyxfw61ZM1vRmwZdq3hxJt+t5YMSuUWDPICO5sZM j+cSduzjUo6x9mjNLCWdvBz69sFiFLJzTRljB2lx+/at170cHDYvidu5YpyUB9HcqtMu2Sf7tSmn Jk6Z53oPeslQzuz6EyS2Wl6YJw/x+W+nmT/2gkBbj0Z/sZXVo0Nc/NgODtcjIWHKP8v6xa6e4GMM Zj9LSqHl9AVNn0kCassL6+skbNvG+moJ+j/WL9p7Ok/y4PnHkYE+q5vx0mQHMJI7op818hyxP1tN +jzp2YyNryjle5aHySbL+We7fAbS/7ShJ1h/V2Wt6bfnn9CMK9zbL3+wfT23248MhIsveegZETBH wLGB/v7pXRVlM3r1cUPsBZl7uC17z+rss3bKnUlwPdw6nln75VlGcIZOqUbxGTolTNF6nVXW+EPz SVyaRgm7Uj9X5Pf1xj990eOiu56LHZ9ZleHY5iIHIPxeVzgE8pZbF6TfGx/s/fq15sBKPjjD04J8 2nLGBvkHtdMDWT+ondH+i3UzB+rgCtywhe4rIs5rGjX3GT4Lsnlwqu8IRHMLDrm9CLp+nvslU+0k OSGnlfzTdvwt1XcprVbTp43Pip6wy+Xk2qcV3TNZN9N+hVs0UH6xCM6Ydg+Z6cdK0dNslkMZv+df 53Jzc7nr19U1JslzJH3ecaaP2ZB8bqXFFTx2891KPvhB4ONxPneavWi+oGJQ3Z7drAz2n1lmbN9U hyZNGh0x98gNwZMy0GgmM/+Ne0d6WavPe5tyauLkByE6vXT2OyV9GLZZP6tv158Bhcnyoo3PQjut rUfjt5zRxH6dWzv8dqWO6VlqnNk0WtUvdvUEL55Sf9kLp0LvZ0k8rKZPmw+Frc8EEbXlRTNxJLzM 0tzrX1ZLidP8KPXP50y82sfxOKPPak7iO+2kssYGmdq2XxOXJaMmfe59uazUVWq9ZWmdm3LVELTV /AukfKqRB9L/NKkn+MjYSyV19eQUoa1KnNBQreseXnyoMlozOdOPDISLNXnJNRGQCfyFKUMHrtPY MD5BDCdmPiZ7OG30ljpt0dVtD+fvaTuluPvileHtdXJUv/dpsNlN4dq5JQ05uqeB34x68xk01Rym Gtr0HrAlV8K1e/+vXiPQ7uOyvxvMa/DCA2e48F+zFy/3fV2y/c38ayUfnOFpj1aP2S/hbu3esOod 8c932omBrViPn5WTiVzYtmCSFEk0nnyoKVx5OcjJkf5c4eg46EXpeRrOOF0hpJC7z1uEoS3d9iGH 1URDZX++M3JayT9JNEd+/KdPH415PWGXSy52LV0kRToFwzr/XSNAOJ4c/7HmPnBjg3b3iYHsOIBT Utn7cVYcwsPDUb7lp5KezUXqNlGfd4hry3aRe7uuQdUy3tzo7e3mu/l80Mdn7a4sIqKiUEM4uaYA eTlZyJLqn6tic3SR2qPjFw1HeluLxs31jQJ+p6/malhZOui1Em6rr7FXjIHL2X3eCL1eqn0/XpvQ UIzh881IcymR6Qx2/YmBWC8v5vNdW48mYVTXf2jkDkOPl1/R3Bee0b9+sasneJmLvp/lP33afCh8 feYpJ1uwc54Mf8zhQ7fKn8jz5Mspu7KoUVMte+pHR104mZqM5NRUpPr7S05GesZVjwJ9/dwAdo7O IAwaNAh9OpdBjagn1M8Dsk8+D/RzEJ///AukfGpFVlsG6/1PC3qiYlvMSf5Eivg11CpTBnFTTwr3 PWb/iLFtnMtzZ/qRgXDR8iUzETBPwJnD+K5eRJoUZ4+HW5n+vMflK1dEXzFdcZfycVNZ+KqIffIJ IGkVUOYKnB5UN410677eUh/tegPx0gF2shRF8VuUXIoivYUdZ1Hy7NzB2FOP7NSdJXmPkGy1I/AH Lp2XSRzB/XU1b6Fka+V3Hc6cZw1GFec/rD74gaZKLJ4NxUNOz7L5t/WfPn0Y5vVE4FyajY42HLwX 2rg12IyFeKqyXjRbd9UjW4Gdb8I6h0twJPMz3B15GduX7gXY5kqkrENqzouICf8NeyQ92Lm9NPiz FZtznsznQ4Bx5rGDYefNwtvj53g9U/QfoWqtDTA2wXv1ym51XWoWfYYdoJz3t2psCD4iKobZ8Z3k 87jGN7huYvEe7Prj/dq57OR7s9FtjPWoXitH65G3tPjXLwHoiWLQz/KfPpVMMPSZGptoYkvbscnh A/Dc4/B3nw8PFfjqTxjeop06KPcTCFt9gPTxrTy4OoJl848Y7DuOWYxF0wa7HSRtcAb/+RdA+TRG FxSbv931PJLjd6DlCDZWkK+e87FkjCd+sgPrv0XZj7QuLfkgAioBZwb6rN8jT1p2bm0c2KjRaU3Z OJbAOphmru17hNmnmnIkZvz4cXMj33g6qR8vQXpctFyClMggRlP8eJb1Mj5X+9XRbEaCX33m6UpB Sko0e8C/GfYSkCdvpuwGo2HdUL8ui15OvyJ6cWAufVrPVvREoFyq1akFZxSyNgVu5urNEMsG9Yns yxh7Us9j6K3p2Joqu0lEYuoVxDRORbxgFY1WTWvID4v010o+2BY07whGht8ppV0KhZ8dFIx8vRPt 8gI42dso22A0lepcvXYd2GNNZ9XoWBLAATnLGNu/mpF3KDF6fZVh158SsjWDnXyv37S+sR7l/ebY yzLvKTCnX2zriSLvZ5lLn8wnKPpMjqzY/LLVUFu2KtIoE1QhIair2Po3NA7zUgObv4zl77Vln5YQ Z4bLVayNO+5phUhlxZ2vsM3ln+3y6SvqQn5211NjAM1Af9zE/qYnHM2JVvz6kebkJldEAMb20BYU ps3kFcg/HmPTkqaWy1RARVnzeVtdI3+zHvVR2YveM8pbgCviN5GMj24Km8LiclMkvhCELFqeoSHG oVvZCt4KvJR89n3eXRv9v513HharxXzPRG3pfUdRZHJqxbJS3y2mTxuNFbOjXEwrPpMS1kL77myW PuUkdh87iVO1dwmzTFGxsUhNSsKqH45i8J/K+iw0q3OLyXBvfmdHV05VBvnDZn+Dt4bGoE4luTLk YkmfynhKWungXGqtl0kn5PSkl1yXPcxEuiXUrj+3YAr1NvdCljH8SrcGYUbfYl5a1RNF3s+ymD5j LjAbp/WZx0iK0DIP509J0cfEoYE8ORV6D5ZwHFtHFdjV/cWh6N+ruc1ALOaf1fJpU6rAvRXgm7de 0QUzY9hUPHt4ChoZu186d+ZvirYfaV5OckkEjASc2aPPvqdeSwr78H9OG2PxaBOGqA5dxCebMnDe MMFQgF8P/yQ+7xmJW+X+lmCjNhaGjseNU0hM8hihs5Z+xmr2IwuEi/1Yb1qffvOhaHkeO5VtQHv6 0A7Fjh9Xy5eyLZa9qTJUB9lRMfh1VE6/+ccnuBjUdxPc7XKR/e3cst94Fkn2bzAu1DQhjFcnZRHZ sa/wNP3Q9/jqK15ZRuOduR+CHfyG9KR/Y+33ycJzfgn0rV7DCfCBqXwPMA5L3l04fkxMN/qvxEdj HtQM8llAN37F944P8i0JKDl2Rs6M34x66b9HDygCafWSYskMdv1pwygss1KPVh3EBbdI/jyfHoQZ fbdIvdzKcvIzEpb0fND7WV4S4MdaTl9w9JkfYYL8+M9TuzAuVYr09joIdzh+6/vdrQsg55/l8mk9 Kkd8nPlmIrpM3a0P6+d30fufm63VL30IbndF2490E4ZuiYAlAs4M9MMaoONAMd5j06Zjy1nPMrhc +matWuN7JYfvYu1Bt9mEqwewcPYJ8XmlSpquPrPKz1dWEBxK0TfpV9N2YL3n6B2yleQ8dQFuRyg5 FD5gm4tjEtgNSF1Kzjm8j9Uokfl8KEqeHy3YqpRVMQ0XkLB4tZScu/F3+Y0/6xJ07Pu4aL9jFNal /M+YZMmmQF+NvLornAdOyWk+/4q2vpulaJdLOFp17ipGsmMd9rpNRh7/donXveJmJXN3V7NpO9Fq 47sYN3sn0LwH2kZGsZn+9sAPH2D8e5uF553va+7Qki+tBBbyXestCOaK5eVzW0IN6T7z7WfFZqDo hJzT5yVB6dALbDPx9ecJImXtTKQbd7v+3IIphNtwtOvGzvThr7RXsNlNf+79MtC5VDHowP/b1RMs 5mD3s2wlNvj6TCtmIP2OEHkFaeVQfX9TG4HW7O4u5wimDntScTF39EOmF8cpnorcEED5LALZ/zyz Dj27zBRjjvkI7EsyYF+mEO7T5vTEyxv+65hURdmPdCwRFFCpJODMQJ+ps64vvy8BTET3ug9jTfI5 6W0aO7046xgWjyyDOz/8SQe59l1xwsFQvOWEtkOwIf2y8Lwg5xhm9mqnDNinjnhArzDD/oZmUkgL Bv5T8Xc5fT0Gtfyn9KRwfkIq1RYD/vk1TPrwW5yVT0XPyXPs7aFtLoWTZN+hujKRvHMn9u/fj+Tk 3TgsfbDgdPIe7Genx/L2+5NPuXUqfQdp5qmVfChSnpuGo/+HP0iD/Wx8884QjJNWnPRb2Af1NIlt 0nusUh+eie6FTxOPK9wKXDlI378Bk/qUQewnhzW+gm90Qk4r+YcirO9W6Nrl0qx7Pykapjsfexcp OX8K92d2zUXk0/JLISuS+HZ7S50ovKRx0uHx+4WT9aO6ddPYAve2rKO7F24KXMjLy2N/LhS4spVl qldc/4NLeZbHzEavvI2lfPccRCHZsjWeZX4Xw17xMP6VKCkyVgOPb5yKiF6fFFK8VoN1SM5NT+GZ D3cremnTlCfwunQGQb/hD3r/0oJVf0qZsFderNC54+FB0nkKAK8/l+8/AxfTmz8uHo0O47dYCapQ 3drVE/yeqqD2s2xSCLY+04r59a4ktd/B9z00fzv3H3d76Z7L2lTRTXLyfuw7fE4M6tQRJO0X+y47 dyYjU/9GTI1u0xHsTj+J9NR9+GrOqyhT9U68LrXtMHECvhpQ8TLZL58BpMOWnjiBNyIell6Ex+H7 tS8K+/LvHfcZZkSJsnzUpyfWZ4jtaQDSCV6LtB8ZqPDkv3QTkL+zF/gv+37ojG4co+n1r8O0Hw3R 7Je/1+zNH/vWuPK9Z43v1PguXuORZWAnsGp8MCP7HmkfKR7jt3SvKN8pN/jThpKzR/fdUjku/tcY ptajNbNdLmosJtOjerBlykt+328+AHHOfE9WK6HFfAicpzZyP2ZNOdOWD735ZS7tujGcjK1v+OXp qR4ZQzJvo35n1/x3fwOW02L+2arvEgLL6dPkn7FO+65X9rhc57ZOVL/9qy8nqj41ymI+j/Uu+e+K q+FOlb81zPJE1o/8d9bTPHxPPtmfvpb0633uulcWwEq+B5APcnRWfl3pn+nrHjsRs4WHdsln+2A2 wjy5LeqrfM9eKafsO95im6eWNW3e25aT8RzkIT368jaJO+Ge73b9MRa2yksA+Z66Yog+Dz2kV8vS bHb5cqfkG4KhP4Pbz+LTbT19QdZnmvKiL8uqjhPto/X9EPYN9jgP5cM9DEU/CoVArZPu7uT7mFdX Ct9z91VmLD3TpM+O7rGefxxnrx3TpkrlZEZm63riOrdxYiOlro/bck4bOced3azJWw86Te/a9F3g /UhrXEwLRg6JgA8CDs3oMxXHFjvGvvI1Tm5bANZZNF5RfTCkYwOD/b2jNiJ5+WTlTbzWQf9p3yB7 +WCPp2feMXw51k5gS011VzRmJ+zEouFNBNtK4ereXtFZiPJ1gPCyxlM6QqVl1EZ/mkj+1hZbMvdg ztieGkvR6ClMgyOTFna5aIOX01MrvILW2lFzSAUzu9BuRwX3rAhUCov54ARP8yKr5WzM9OnCIVA6 v72m4Eju+2iqO3dCdHHbQ28hi33mbESszody06nXCIx6wOyXLRRvPg0hIfJJ+2yLjMl8ClhOi/ln r76LybaePjX/PNVpuV550hP2uIThoXeTsXW6uuxTzrAx099W9GkoZ9RZsjtrv2G4q9MQyctgPNBc 2jD/t+bo21uy7t8R9T1EFxIuKUk/EXr9BJ2lfLefD37E8/g4tMkwZOz8RFlVwx+zL05yi+3KirG3 C/4qObEtiVW0WmJoRlluraRsHWC71oRLm/dOyDlgwgSlXCkC9JyJtFzfB1hZ9WevvNjP9zv6LWR9 kLlqHvKJ6/Qy1mzbgBFKQp01WNcvgD09wcsd3H4WH6P19AVbn6nlhZfX+9VW3w8JqYDG3h0rT2pW 0CrCcqhWS9QDigPBEI0BY2bg+5QsbJ/6pPcVMXpPJu/U9Hlqc/wFYj3/AimfqjRyO2mm/2lVT9w4 vga93vtFiCzm1W/wbte/qxHzptrdsWzrG5Ldu3hj6X/0z23eOdGPtMLFppjkjQjoCJThXwLobBy5 KUBWRgYuFZRFeNkC5Feoiro1qiidF49RsKU7ZzMzkXs9n9+Si2r1GrHDkLQK1qMv5GScRDbKo2xB PsIjIlDFvxfPARVXW5tcimtyilyuouBZkIeMjGyEsLpwne3Fbxhh7pNlrpwsnM/OxXVWIULKh6Nm rZqoFFb8Cngw5byZ6rsdLq6s0zh9iV8rGoJqdSNQw4QOLPI6VdIEEOrrBaB8WRRcD0HNiDooltlg Vc4bBzE4rJVw1sDcYzfwXKQLGSdz/Oslu/6KtFwUsGX7/P6RsgjjdebVH9C5UqzwhQk2o4+xLYvP aZB29ISINnj9LLtZSfrMLrni489++Sw+aXBckqLoRzqeCAqwtBAopIF+acFH6SQCRIAIEAEicBMQ 0AzYLQ127forAiSunNPsCz61EVFDXqUkCrHro27oMJo/bDAaX2ceQrdS9NnIIsgGipIIEAEiQASK CYHiNz1YTMCQGESACBABIkAEiMDNQ+DYsn5oOXofej37Dvr0uAeNqgD7lk3FuPk7xESMmYIHaZB/ 82QoSUoEiAARIAIBEaCBfkD4yDMRIAJEgAgQgZuAANsSlymJ6frDgrx2/VmIwmmnGz97HRs/cwuV nUFwYloP31sI3bzQLREgAkSACBCBm5kALd2/mXOPZCcCRIAIEAEiYIZAQSY2LtuEczfC0fbxJ9Ci yi1mfAF2/ZkL3VFXBXlZOJZ2EIcOn8CFC+dwOZudd1G1AVo/2B3dWzegQb6jtCkwIkAEiAARKO4E aKBf3HOI5CMCRIAIEAEiQASIABEgAkSACBABImCBgIOf17MQKzklAkSACBABIkAEiAARIAJEgAgQ ASJABAqFAA30CwUrBUoEiAARIAJEgAgQASJABIgAESACRKBoCNBAv2i4U6xEgAgQASJABIgAESAC RIAIEAEiQAQKhUChnLp/LnUbkg79F/zBvlVaPITeLWv7Ed6FH9fOxntzv0Wlxo2Rd+IE6j30AsaO eQT1wvx4DeCxdTkDiIx5DV58TvIswI8rPscPF3MRHtENI3vfoYOQk5GCbUkJ2L1tD45k5gGXLoGr H40ujw/BwIdjUdd0/rmwa1E8knPLAK5QtB8yDHfXMHlYlE4iuiECRIAIEAEiQASIABEgAkSACJRu Ag4exleAM8mbMfudvpi1XoXaYdqP2DG+lWphMGVj8chqeDre8IBZjMTB7Hm4m30L17nLrpx2JQh2 fA7zPPc1ytTpIST+vtk/YucYNS+PL34CkU+v9gEmDuuPbUDvyIo+3IiPLu56DzU6TFLcTd17Ga+2 qazck4EIEAEiQASIABEgAkSACBABIkAEzBFwZul+wS+YEheCiLv1g3xehMphIT4l2TWzhzrI7zgJ Cft2YNFYcWAJfIp77vsXLvgMwcLDAOS0EIvqNNjxsZid5rlrwXtSevpi5lB1kM9bXstlM/jS1Wn4 RHy6fA02rFmIEbGybSL6NH0Tx9gXjnxef6bhNc0gn3cbVs6nD3pIBIgAESACRIAIEAEiQASIABEg Al4IODPQd13GoSQ5hjjMXrMcL7WQ7338Xj2I98ftlRxMwonvp6BL6w54atYafCR7S3sFK5KvyHeB /dqV026swY7PaZ6Xt+PN1/cIqe8w7Z9oU0kPolrEvej/1gqcyC5AUvy7GNH/UfR6dAg+TbyCFcNv lxx/gG9+/p/eo9td0tRn4XFBh5s7uiUCRIAIEAEiQASIABEgAkSACBAB/wScGeiXrYD6UXdg2pqd yM7fhjGPPow76/uP/HLat5BX+U/+/iU0kk8MuLgT2zTe//3dUc1dAEabctqOMcjxOc3zp6XTkSgk PhqvDm1vwHBbr8lY/kY/NKrivpc+HA+PGq24/zHltGJ2N9w4/jnihJcJffHFmtkw837IPQy6JwJE gAgQASJABIgAESACRIAIEAGVgDy0Vm3smMKa4YOUVI1P/hg+/9dvh3dKjuIQ27KaZM7FypceVF4A 8JY7t6QhZ3x7BLxV36ackmDWf4Icn6M8bxzErNEJQpqbjp6BB2tYTH5IqOKhetUKillvyMTMx58V rLrPewf9Wu7FEL0DuiMCRIAIEAEiQASIABEgAkSACBABiwScmdG3GKns/PIVaUl+8zjcJo3iLya9 j/7LZBfSb5kryHezolsjASd5Hv/3XCyVopg8+n5YfSN0Yp+45J8PommDmkZhmc3RxS/j9RT+0cuY PbI52/R/w6M7siQCRIAIEAEiQASIABEgAkSACBAB8wSKcKCfjZ8SpP35bCAozOffOILX4t4WpO+3 7CjS10rzu9v34FSe+USVTpcO8mSHCMb3/0LE2H8lejW0WEzYSf0Dnpb8N5uJXlF/NWaJ4EY8sX/y 9xPRiLmglzlGTGRDBIgAESACRIAIEAEiQASIABGwSsDiCM5q8L7ch+OuPk+KDtjEPn82/66Zz4uH sjWfgpkD2AzvpWtKAL7P7leclWKDczzPJMzHLInk3Fd7IswK1YLTmNKlB4SJeuZvwVcjUdfgPxvz n5Pc9FyMlzvL2zYMDsmCCBABIkAEiAARIAJEgAgQASJABCwSKMKB/jWkJX4pintrJWSfWoUO0gnv C1aMFQaH2hlerdliGkuJc6d4ZmLJazNFZj3nY6Cn2XivRLOxeEh9aTk+MHr1cQyNrGhwfWbTNIzY wFtHY92nAyAf5q99mRPKWd0sYIiGLIgAESACRIAIEAEiQASIABEgAqWSQBGOpsqhkjzCO/oZXugr nu8e+VYShrZwX+pdC5W1o8BSmVX+Eu0Mz4u7FisD9akTH1cG4f5iB3Lx1Utt8PQy0WWP2bvw4WPy J/Y0vl1peK2X9CJh2BvoWPUacnIKgLLlkZd1QXGYceEC8vL+hpDyVX1P9QUAAEAASURBVBBWhKVU EYgMRIAIEAEiQASIABEgAkSACBCBm4RAEc7ohyGqwxMippRErBfWeo/Ev8d1ktDl4tDOVaK5Z0vc amn9uBREqfpxgucFrHxjkkiN7a0f2qaySYIFSJrSFY/OPiG4b/rqN1gzpr1nvwXXoBy38PkjqFo+ HFWrVkXV8PKIkM5n4D1O79YA4eFVMStFOrDRc2hkSwSIABEgAkSACBABIkAEiAARIAJuBIpwoA9U qFZdJ87U7VPQVB7Q//kb9kqzw6hVTdjDr3PM37DZ4UnRZRAdHS38lSnzHA4po0iD68Atinl8gfK8 +tNajE4SMY3710B4PivfiPHHOQMRJ227wLMrsX/qg9739bOVGbnGIKzZBDsfrElHrokAESACRIAI EAEiQASIABEgAkVKoJAWRZdTEsWFel9zH9GqM3P3iei26Ud4IUY9lO3ijlXiwXzs6agHW3keOLLZ 4TS2EiBFOfqtocWT283JqSSmmMcXGE+29P6DF6SkTsJzXf+uJNuX4ejioWg9Rlx50WzYSuyb/6Tv 5f6hd2J9djbYYn39xS/dPzhVmdUfv+UUJt3HL933sKog4HzQR013RIAIEAEiQASIABEgAkSACBCB kkTAuYG+KxPJB04hv1w5hIRcxeFfRUynk/dgfzL7Pno+O04vpAaiWzZQBu233NYRc2LZoW38LPKx UXh3TSymPNYcrlPr8YSyjDsOj97/D8/M2TsEeZu/7MD7awXJhQ055bD5ZQXFOb5AeN44vkHZX//M 6mdQT0m0d8O5b95ElPwZPebs/wY3wYn9+/UvW/74A+Ub3oUWdeRD+cqiUpUqHgOtUENdQxBRsyY7 w8H9rAbJm5188BgjWRIBIkAEiAARIAJEgAgQASJABEoeAccG+lePrcLdMf80EPr5s+Fo85lsHYe9 udvQRhktV8Xwz7/E5w2fFObkpz9+B6bLTqXfUas/R4zncaHw4XWrK/XtySkJw95VFO/47PIswHcf DJYSORKje9Z3ywXPt7//54DuwdCYlrp7+abJtB+RPr6VfOv1l+FVrhtlDHP+yjP+TYLVfFA9k4kI EAEiQASIABEgAkSACBABIlCyCTi2Rz+kQrgJUrejgtuUe2iDJ7D75DoM8uB76vrjmPOYj0FnSAhq 6fwpbxB0ttobu3IKYdwE8dnh+ee5TZg0X6TUfd6LaCGfk6AF58FcIdzc8v6WlSt48G20CgkJVSzD y/p4B2UjH5SAyUAEiAARIAJEgAgQASJABIgAESjhBMpw7CoeacxFRvpZFISHI/9SLqrVi0QN/+P2 4iF6sZTCLE92Yv7EToibupuloi9bcfFvzYqLYpkwEooIEAEiQASIABEgAkSACBABIkAEfBAoRgN9 H1LSo8IjcOMIBofdiaUshg5sif0OE0vsC08YCpkIEAEiQASIABEgAkSACBABIkAEAiVAA/1ACZJ/ IkAEiAARIAJEgAgQASJABIgAESACxYiAY3v0i1GaSBQiQASIABEgAkSACBABIkAEiAARIAKllgAN 9Ett1lPCiQARIAJEgAgQASJABIgAESACRKAkEqCBfknMVUoTESACRIAIEAEiQASIABEgAkSACJRa AjTQL7VZTwknAkSACBABIkAEiAARIAJEgAgQgZJIgAb6JTFXKU1EgAgQASJABIgAESACRIAIEAEi UGoJ0EC/1GY9JZwIEAEiQASIABEgAkSACBABIkAESiIBGuiXxFylNBEBIkAEiAARIAJEgAgQASJA BIhAqSVAA/1Sm/WUcCJABIgAESACRIAIEAEiQASIABEoiQRooF8Sc5XSRASIABEgAkSACBABIkAE iAARIAKllgAN9Ett1lPCiQARIAJEgAgQASJABIgAESACRKAkEqCBfknMVUoTESACRIAIEAEiQASI ABEgAkSACJRaAjTQL7VZTwknAkSACBABIkAEiAARIAJEgAgQgZJIgAb6JTFXKU1EgAgQASJABIgA ESACRIAIEAEiUGoJ0EC/1GY9JZwIEAEiQASIABEgAkSACBABIkAESiIBGuiXxFylNBEBIkAEiAAR IAJEgAgQASJABIhAqSVAA/1Sm/WUcCJABIgAESACRIAIEAEiQASIABEoiQRooF8Sc5XSRASIABEg AkSACBABIkAEiAARIAKllgAN9Ett1lPCiQARIAJEgAgQASJABIgAESACRKAkEqCBfknMVUoTESAC RIAIEAEiQASIABEgAkSACJRaAjTQL7VZTwknAkSACBABIkAEiAARIAJEgAgQgZJIgAb6JTFXKU1E gAgQASJABIgAESACRIAIEAEiUGoJ0EC/1GY9JZwIEAEiQASIABEgAkSACBABIkAESiIBGuiXxFyl NBEBIkAEiAARIAJEgAgQASJABIhAqSVAA/1Sm/WUcCJABIgAESACRIAIEAEiQASIABEoiQRooF8S c5XSRASIABEgAkSACBABIkAEiAARIAKllgAN9Ett1lPCiQARIAJEgAgQASJABIgAESACRKAkEqCB fknMVUoTESACRIAIEAEiQASIABEgAkSACJRaAjTQL7VZTwknAkSACBABIkAEiAARIAJEgAgQgZJI gAb6JTFXKU1EgAgQASJABIgAESACRIAIEAEiUGoJ0EC/1GY9JZwIEAEiQASIABEgAkSACBABIkAE SiIBGuiXxFylNBEBIkAEiAARIAJEgAgQASJABIhAqSVQttSmnBJOBIJMwJV1FpmXrgMhYsTlq9ZF nSphQZaCoiMCROBmJ5B39hec+D0XISGSMkE+0yu10TSyNuw16gXIysgAr56q1WuIGqSWbvYiQvKX IALO1/fiDceVk4nzuQWoEF4LNRzvI7lw9mQmcpmmrBsRgUr2FGbxBkjSWSRQstu/Mhy7LBLx4/wC Ns1ZiV9RBnCFov2QYbi7xi1+/Jh9XICjW1fh4O9lUA5/4K+RD6F3m9o6z1dPbsfanb+iXDkwFxHo 3T8WVXQuiv/NuZ3LsHRvNsLcO1uhNXBnu/ZoF3Wbzc5c8U97yZTwAlZOHIr+U7/WJa/JtB+RPr6V zu6muCnIxFdzv0KmT2FdKFe7E4Y9dq9aVguYbljAdMMNphu8XQadwer8xqXYcjoPuurA6kLzVq3R vmUDvb23cAOwP5e6DUmH/sv0CVClBdM5LfU6xxi0Cz+unY335n6LSo0bI+/ECdR76AWMHfMI6ukS YfQZiI11Oa3GxvIv3kf+uVyoHTMIj7npZKuxqO6DHZ8ac3E3HZ5ZD3eNy9CL2fQjZKe9aK+9u3EQ ncNaIZGFOHXvZbzaprI+bLorRQSon1Xc+lmO1/diXZpz8VlcZQxPAgqlj3R1LzpXaifouvcOXcaE lqTrinVxCIZwJb394wf6Tl4FJ5fwLw6Uv37LjjsY/BVuTqwaNprN5M7rQs/nNg3XPEcctzdX5+Cm uEme01Xhp2WpmO8YyX3/S95NkZbiJmTqosdFtj0Xc8EqGkqcUr2Iio3lWjDzsIVHixsec/LkHeDi NHVcKZfudk0/4rK1IebtMeWPDTQ0vq5w87V13j0ODOaWHTqrce+UMZ/LOLSOe6mPVp+A6zDtRz8R XOIWjdD7UfmM5A7qgPgJytRju3KaClzvyET+sY6Z3k8gd8GOLxBZg+z3ZMIH3MCBw7mxY4cLukQo Yz3n29dprgPcIKluzTqkrX9BThhFVwwIUD9LqE/FqJ/leH0vBqXMuwhqm99j9k/enWmeKH0sM/06 0nUacmQUCJTwMuH4opVjOzczHaleK1ftQ/yA21FJtQrIVDlc4z1tGfZkvIQ+EdKKgauHsXq+5jkq y6uktZbF3hwSKicyGsPHxqICL/G1LMyev1yU/einuL/RNRzJXYwWToEt9lQcElCeTb5yAwUOBek7 mFzsXbxadDJgPn5b9CzqOl7rfEvg+FO2WriuEihfRluz8qlYSIZr4OrejvJa67Aa6DN8ABrhr4Lt hX3zsT6FN0Zj4PDWQjm/xsKJrq2f9laqA3P37IRHUR1nsH/qZ8IbeWAJBt69BD+uPo4PH7tdG5t9 c8EvmPJgY7yeZAyicpi8VNr4jLfZNbMHno6XnnWchITpD+H8lzPw9GxeL36Ke+5riPM//x9qSk4C +glATlvxsmXicr7f0XsQ2tXS5S4rA9dQv0V1W0F79BTs+DwKUTwtG3R5CUu7iLIdv/MyIp9mOuZK 8ZSVpLr5CFA/i+VZMepnla76Xg6NujyDWJxC8+pC79d/BQp6v86/SOSCCBQXAg4PObKRJA9q5BRu WoyfcgYjplDWzx/B6oR09BnZXIjt4oFNWCrHWxJ+e76MD2cNVpYmz/pwCj56tj5GL+MTtwQTl4/D ZintJSG5wUhDSCg/oc+uyqH6QahoWwj/K0AeqPbr3PHmH+S7Eeo+bznizZbBso0wKl4ovEIoxxdf xnp+gMLK+Wfxajl3i0K9Ze7mvCe5e+9f+OmrD9Dy0beE53Mefw69LmxD5xqqc9sm12UcUgb5cZi9 5hlkvDMAs4SXEj5CvXoQ74/bKzmYhBPfT0EjXsO2boW82eUxin+S9gpWJD+LsU4sF7QrpyRhID/P v/05nmvB9kcF6Qp2fEFKliPR5Mud3ABDywvQP3kvqQSon1Wc+llO1ffiW1rDEDvuc/ZnXkLb/TrO 4SGQeZHJZTEjUJLbP2dL+cVD+FzqIL+1/Av8MmAIG3gn4ut9vyOm698dzdYWLVogJSUFKz9KwGw2 0KgJF7Z/+bbfOPKyjmH3d9uxY/supJ04yw7k4K9wtIjthocfexgxkR5mpPg9yQvWIvNGTXR6tB3O bZqHeat+RO6lS+DqtcXg/xuHIR0a+I3bsgM268zORlIG+girh1GzNuPzZT3AjznK3GAHMHm8XPhp 4xeIX7gae0/9BdXKXATXojOef3EsHmt9m0cfgmXOMSz++AMsTjqJ8PBw1GzWGSNeHISK6Zvxw4n/ 4bZ2j6BrlIYP47Jx2Saczi2PTv0GooXuLAYmw9qV2Hn2DzSOdfOnSGBTzrzT2LRiCdasSsKRi39B 1QaVcGut+rinbRwe7P4gmtYIVWIAm7fn93gnnvsDocz6+BJpdp29gJoT///Ymo8bgtsb7Kd9P4fO k5DKy0WWc6G4jA0bRHFWfjALHcuw2W8+MvZX9d7HPO9ndp3GV/Nn4ZMFPyCclfNcVs7rxA7Diy8N QZuIipq06Y0FWQexYOUe3Aitj0EjeiJv/2rEf7wce4/kgWtwK+5s1gpPvMjCqOM9DH2I/u+8l0H/ fpUOi3s59+ZV5y4cdz0yGWe3/g91uvyL+UjE7BWH0XnMnd58m7cvWwH1o+7AtDfmYXif+1ClrAtL +PcTfgb6l9O+xXoplsnfvyQO8vn7izuxTbLnf/793VE20G+vsbFptCmnzdh03m7k87oneAP9Qo2P 1bcV8zfiIqut9zId0Eanx3TJZuokk50zsVY4Z+LO3iMQE6HRNVbrbcD60002k7f8OTazZ7yPNfsy UK1aNdRp/SRefioStUz6t+WMnc+RtHohFq7+Bil8m1SdQ6W6d6Jr74fxSI/7DIf/2W2nA2qPLLUr Wgo22zFtECbNtriYDNuTM+pnOdjPkvoFwelHXsA37DyV4+wlYG1v/QxFnjKIuK8/O3tG07fzVBi8 2TmiP8VzIXb/ns+0sHSxPlKV6F6Gc7jEp87068LL5eJU4irMmLMU/8m9hEsXa6DbS29j4pD2jq1C 5uUNdr3l47TfHwxAn1nU87ycsNpuCp7sp69I2j9J5iL7cXKHRsbGFziWEPbXlzuYe0HdWztsM5fv SERXuMW9xf2v/T9cwb0jmVedZoG79nB9hLgHc9Mn9NfIoY34CvdRlLf9s6L96GUe9k2b2JPcY/Yu h9LIcanxT4jyx3jYc1lwWNlL6XH/Um4a946PPc09piVx17VIJLMr42u/+6cN+281XPT7qvlA1X1W Hvc125Sz4Ox3PuVsMvWwW+oucTMN+7o9l4E3dXvD3YKxcsv2FvN78MW64ON38gFDqHw+iOXYs7+p W04Z/MgWecnvS3HGcWMn9vQYvyEPZc9WfjX7mbrP81BfTIbls5wrYah1Hh7rw8/cCJm1p+dKOIEY VBk81jkp6NT4Lgr/7cpe/CvcioFuecnkVB4HIpbBrzk5Dd7MWmjyfeq+c1x+bjZ34cIFLjvXk0Yx G6gPd8GKT3MWwLjvz/kQiD3K+lap21qdZ6veBqI/NVKaq0eih7M7P/CoF7S6yuk9+nkn1/nUaUad HXg7rc0bMeW+2yPr7YqUATbbMU32WTDa5GIhBtGpqkeonwXOo863k++a+q6tb1qzmX6kufr+GzdF bhfdz8qRyoPaXwA3assZy6VE8eCA/uQ4z/00j31HIWLP7rUsZbOhX6dpV2Q3ht8xmzz2k5U0WzIE q97qhVLz10J/0E65lqK1rufZsC3I/d2iaP/0uVI0d39hBdyhy4Xdqz8Rw+rZFc0r1UDbPtImws83 I83lUDRSMFylpujT93Hhbn3if3DxQIIwm9b01cfQKUp5J+gl0miMmR6PhB37kHIsBYlrZoEdLiZc cwbegfUZf+r96fYks0d3jMT6felI2bEUbFAmXJvH3oePkx3eJOnhMNCrKbuV7QmXpbjVnwv4qHcz ZW9x82dn4PtDKUzO9XgpVpLz1Vi8mfC76kUwZeJfEd2lPc9sJfVbK3EohZ2tMLaDzl1j9/3JGi5h Hib35CXrxn3NduV0YcO4ByQ52X7taSuwj81279uxDWu+mCbmRRn+bHTtFY6H923BGjatnpCwATPY iVPi1RcLExLYbPsG8W9NAgY2cWimu2ITfCyFm5CwDCPYqF+4Ok7BBiXONdj+RD3pgfyTibdZPqyX bnu+vUhIX+LyybIDTOjWF1vOupVP+WmIXO7Z7PZ7mwTbnhPmsDg3YMWHbyllXHbuxO/XX67H1sRE bN26Vf+3cSP2ZVx1IgrfYdxyK1r2lpzsSMavDusZ35Hrn16+ItX/5nG4TdqqdDHpffTnVwNorzJX +I+h3dTXBHayfkh4VdSsWRNVw8sjqjc7jyDdqJGcSmShxsfqax9JP+49eNKnyJdPHZAWdvRFpyay grZZb23rT58ien/ITpt+vsPLyvPxyxNx7NhezBkRqdg5bri8F70b9lV0Wscxc7CDb5MObWc6abQY nUFny1LYb6ettUd22hVeRrvtmJw+u78WudiNhvmjfhbYmjz3y2a+a+q7EGKh9iProt/aF0TBj43C dyfFlYtqSgqQtORT6XYknnvgH+ojq6aA9ScfYTh6bluNL5avwZo1s5W+irHvKAvnYL+O5cNq1nfY lzBXiRcfvoat7uMAOWrbv8Grt4KIlvuDNss1H5ktPW+z3ZT5W01fUbR/sqxF/evY+wX2Vq+P9Aax nzTLl5f6uTJ74Mwsgfqmufu841zB2S/F8DsN4kb0bi6Yp+69yJ1c8ZgUL7+yQJvCfO50Sgp3wdPy grOblZniZ9y/FKB7A8hOztaGqZ1hdmjlgvLGtuNM7tfr17nc3FwuN/sCl5owV5GRlRtuwTH9yfs5 +99VeA9b6H5a6XkuXloBAUziftVgyVFmgvm319pTs/O5rRPaK2Ea3mxruBjzV80rd3925eRXCShp iPxSkwLZeIW7kO17djFdc+q+b5dymIH+XldWofib/c7aqeZfj2m7dBFn7Zdn6/mT3/XPZId5qR8r ecWOtOMWHMqSH4m/189zv2Tqy4zegck7Tb7z5dDbn7/VA0o59zkTr5YjjzP6bB1N4jvtJBn6FtJX NlQZ3MuySuyS+kUQ+fRz12FltUE/tlIofe2QYiCnKrFlE5uRknW8tzyfHMjMkLtAQYxv/3TpSycx mi9F5Iu69/p1tcFQvojCdLP8xRfb9VZTj6zoT3dM5uoRx51c+7RSVyfrVi5c4RZpVp0YZXGP0fy9 wpXpidGrjV/gKcjcw23Z6/7VjMDbaWMafNVhe+2K/XbMPD+9S5tc9IGYuFNZUT/LuX4Wp6nvgP1+ pNn6zmn65IaZcd0zz/0JEwVFcaLUcxv6UwlEMeRzK6W+qvf2VnEsGCz167T50HwSl6bpCLo0Yxbj qiB9nObvglVv9RJZ7Q8Gos+U/Leg5223m1IyraavKNo/fY4U3Z1jM/oXDycpb+3v79SY9QOBio3a gi2rFa74zUclkzM//N7gW2rH4h1+tvSHpYjf8DMzDEa3e6ohP89bssoiIioKNYSTCQqQl5OFrJwc 5LA/V8Xm6CLN6hy/eM2rkN3njcDd2pPua9+P1yY0FN3rVi64cDI1GcmpqUj195ecjHRPs5/bX0H9 8uWF/fLhVWsiquvzymz25PXHMTRSOwPtwrYFkyS5o/HkQ03hyhPTxqcvxxWOjoNelJ6n4UyOmsTf Dnwn3fTFpKHa77qXxUOjJkCekFZ9BGKyL6cu1sZZOG04Nj8cNaqE6Zy532j3hQdnVlVdYeBvP/vv aTslcfvileHtdaJXv/dpsE9LCtfOLWnQZJ/OnXzTfd4iDHXfcxdWEw0d3J8vx8Xv4zT8sYcP3SrP eMouC+O3LGrUVGcj2KRJEV3szIA+T4pxs4l9Xo5dM59HPG/TfApmDmAHhl5S9UrRySmKaOu/dCbA W1+w1RpsVvZ0ZiZOp3yPGQObKsFN7jYG+/wVTsW1H0MQ42vQ7j5RmB0HcEo6lefHWXGC7i3f8lOp vuUidVuC4K5DXFvlywlO1ls/RAJ4nItdSxdJ/qdgWOe/a8IKx5PjP9bcO2U8jQ3jRV7sJR0me/gq xi112qIrWx2ivwJvp/XhWbgz3a441I5ZEA0IPhfqZznXz9Jmtfl+pNaXRXPFVhg5tpHgaeerX+IX TX/pTNI6pb/+4qP3WAzY6DwQ/WkM7RrUXpPxqScbu/26UW8+g6aaLmNo03uUMcvu/b96isqGXfDr rbuQ/vuDgegze3reyXbTf/qKov1zz4WiuxeGvIFHX4BDCQulYCYhLlJaxx3WDH2Zoomf/QvS30zA 6Tfao17gkUkh8MO0mujzwhN4fcQq0W7Y42jBUuTzlUIeO+hs3iy8PX6O17O1/hHqvRt+f6vGhhRE RMUwO37J53lc48XiFcfVnzC8RTtlOTyz8Xmx2U+kj9cOsn04Hz0Db/a+3c3BH7h0XrY6gvvrarSX bK38rsOZ80yVVhHz6drlMuITYcuF4kg01GiCHszk5xwyN0++bu3LCfYBtoj6UtibRqF+yCgMmDAD 3dpEIbJ+YzSOaujoASq+UlEYz5Sl3zFdcZe09FuNpypin3wCSGJl3cTS78EPqIMvNQznTeyNOzY5 cQBeAKLlF4vvil1DWuKXYipurYTsU6vQ4fU9wv2CFWOFz9Jp9VJwXjIFANWTV6bPP0hJ1T+pUwev LE3BPS16I27cFvZsHaas+tmZr4EEMb7qka2EZZuJ7GsmRzI/w92Rl7F96V4IbzlT1iE150XEhP+G PRvE5HduL73cZbdO1ls93MK5azY62nDwXmjj1hjEonP0qzVXLyJNSkKPh1vBoNJ8JS/AdtpX0MZn dtqVQNoxowSmbYLKhZeK+ln6vHEm3033I/WRW7wri/bPjAVm8xM8H2Dtnol4NaYaM2dj6wJ2chF/ xXyEBxrKW/5EKzv/A9GfduJzyk/TyJr6oG6pj3a9wSYO9dYB3wW93uol9t8fDKBc29TzTrab/tOn 8gha+6dGWeQmZwb6f/4H697jB7r8tRe72X7dlD/+QLmK5XDwyC+iNd7FrvQ3UE9+CSDZBvrTtEtf FoQ40H9zUBvfweUdwcjwO8VZNtklPxspmNm+QWk0m+f1NHvmsIzmtagURs3IO+TQhJk84UbzDWjl oQ+DYf8777bjTKSxT3tVZyfH5/6egoVj7sd7SdHAnIfwapczmNZVncnknatD+2g2w8qv0vR08elk YQjvTPmBfjaObJVmXTZlCKf8axcsoGxNNGGKDw4qPnty8mlhKwzeTsM7R9RzCJZPHYfl/CPhYntB jy1Bb91KB/lZcf/NxrEENrAwc23fI8w61tRllNbjYDSsG3jjrQ2x+JrZLOuWrYp4RTeALodKcn4c /Qwv9E0UZIp8KwlDW/xVkU801EJl7+8S3dzeDLdlEfvcK8JAn0+1v5UrgaeoEOKr3gyxrCFIZG3A ntTzGHprOrYq7zQSkZh6BTGNU6W2IxqtmtaQkuFkvQ2cjJkQqtWpxTRpEC5WxuUq0bm1/IbWRLxO tNMmolGd2GtX7LdjasyWTEHnokpH/SyVhSP5brYfqUZry1Txjj5s1euLeJ3ptQnxOzA2pi/Czm3H J1J/btT/b+9LwKMo0vdffiYmsCQICKzgGk4NYBLERUHlSPDgvjw5FUVAVw7ZFQRcTzCgq4SwcqPc KIhcCuhqEMIVkEASJLAsgbAGFgIJJCyZbOK//9XndE/3zHTX9BzB6udJprq66jver+qrqu46JvS1 9gLOnRTU/tMdwcDEl1fo+/O2cw5ivRV1MdcfpC7XVH7eznbTnH6yXQPW/skMQ+DXlvb+Wu4O1eA5 DUO6i51cV/0+//EYhsS2cY326f6mO/rizL9yyQC1OhrF8G8r3V9H1yQrco5I+RbvPN8JDaPk4l2C 5f1q4VkvA9qIcD1kjitX9Uwj/ojlHEe+D/lwRdfC7fVqC52levW6Yvq2I7gcKb6omNnjfQwqm4d4 WXw1G3Le+O7Nw5ROlvqRPhyGmo2k2E4xBmfLV5KDC2muSlwt8ZLPkpwSLbIJ4xtpFRiWuRe7Dx7G wd1k47mVm6WHG9Cv5Ws4WTHPebSZFxFC53ENpx1quZEqQn5508TLQLFU/BBjVDbckK660aW4kCdJ 3ykJ5KTFIF2RiOtIZlysJC8ds9OkaZGj8dXELpI8JTiULr6QRO+2uP1Gs03k7eBfHxp7fj+YxHZ+ DfBgT/KVPvsU9uSeQt5tuwVd4hITkbNjB7748SiG/ap8n0arhjdJStlZb9U4mfCf6uR82J3fcE1n eO+HN0/krRvxRMJ1IPcC0N6cgHa003oVveDpS7tC047pBfQa4x9cvLIVErB+lgFOPtjddD/SgK0S Zao6NcKTrw/HXwd9Bqz+Ow4v6Y86WxYqG4o+m6T9WKTQthyg9Z+WGVW5DMGstyJYFvuDVss1lZ+3 s920qJ9hCfJD+2fIJziR7hazW5Lm2NZvlPRd+g7FkCFDVH99lDXe36zZTfaptfuKREyzWMQ2i0GU fgyuYubAidxM8X7QGswZ96hqkE+iy0/jey+DfD5z/i9FIg3V/38fPajc2fpF0fX9QUQC3tr+F4nX fMxY/0+FLx9QBuRkhG3+PWW0OEDhCezKx2X+V32V54Fs2u7mclYOXcNF8qXtMM5GJ6eaVhjuaNsJ g0aNw6wVm1BRchqrJ/eUEszHP7L+q05sHDbVSBpn9U8sP1DsJpImMysu6AxYidNHDovPe8feeANF SlB/zduNiTlS5jsbkr17g3fVqHurhnnyzmnO9X+//oJ9K6XHDeo6Z/6ocziOYWpCNSQkJAh/1aq9 hEPySEmdzq6wnfx+vYLT3uQKND9v8miehyG2c38h5vih77F+Pe+8EvDe3NnCPjDHd3yFL78X249W Y9vjdiWvL/WWzn8qrF0DW3Z7PHVC9rvpWzP0e3wU/YIsV3q+3pM9FhpINI7884xJar60077iaa1d kfHk32jr3LVJbc0n8wUX81zcp2T9LBkbO+xuSz/SS32X5b2r+7PSbvJp+Pzz9Vj3+XbhUcvXR2v3 m5IzUP3S+k8qZu4zhVy/Ltj11j1Urk+oyzWVn/el3XSV3Ny9rF/A2j9zYgUklQ0D/QJ8t0qa+k02 3Nm8cTlWrFih+tuEpandRWV2LcZP7o4GC4C6NavL63EidFMXz363yNT6xJnzdjgH1ILMBfhmsay/ /78o3vbYnzBFwmrNkFnIlUsvGeJ0lo4bxK4x2JDtfrBb6dIrCY+qIVGcjm3Z2m1Qrhz8Ttm0RWei igrli82hbO0rnGvHdrnJRy+njr8UERbVGE8NSlIee56OJb09ybsoLFNQMoVAoG6L+yQppuPLnyQ5 ZbmuHcSnKSfFOzJH3NmllRME55fzsJ+FN4nC5RkKtSLM6eOarjgLySOeUdjMHfuYavmKEm1DQNzL gifkSd+Ydl2dvFrOwZ+E9ZBi1KVdXyizicY82s5Yzkqyzp9Mscwma4j4P37PD2svDs3JqQhplZ+r 41AIASe+muumvqsSBZqfirWZYP2WD4jJNk/HxJR0soliL3SIjSNf+h8kG75+jEnvfy087/pQa037 QV1vqfynXpPG7TpJkb+g2G2BiUa7rnI7vAH7CrV0Tny33MZ9WCTakU3ReYgYzp0xkxwLquUp3zkc 2gaJup22CU9ZLs/tiv3tmMzX3S81Lu4I+ineDjlvxH6WGm5f9DNX31XcbrkfL48U71OHP6Ecvzxm EPFrNl60/tMeEUK3X2dHfbAHI09UfPBnlH6eut30pIbbZ0Fo/9zKEvgHPg/0fz27W1j/w4vec+AD htPFWyTKX1uz8NWes4HXUuBIPvdX+4/Ie/UA/C1N/v5E3rhtTkZMn0/MybXlWbwwe480wC3Clmlk M0C+T06ugSMfVXZiFmP88b8xRm3+k0R4Pj5SfdW/q+945RzQFxL6YH7aCeWlRKWjGMczNmFqv2pI /OSIRrC7HhmozLp4OWEy9hf+Kjy/lrcVwztO1aTV3ETeglZSxJIhf8Ym6RztK8c3YmjbP2uSqm9o 5QRKsGxoS7yYuh45+ZeUryiVxbmYO3OxxCIJcc3cv9YNj5J2eP75DUyd/R3OSacuFBeXKvTUsgYy fNs9SYr9JncYruDJ6/dhnweUgVTyqEeMB4qBFFbi9c3uHcggp0ZkZGTo/tIzTigvgsTkJaQMiuky MzOw/8h5MTovCzsyRBrp6ZkoUF5euSi0JQt7jp/C8Zz9WJ/6OqrVaaN0WtB7GYbE/c4lgw+3jgJk pqcLOmVm7sERyV2cIUtGFH0z85T6xXO66Y7OyskIIGcXT1/3s1CmruVtxNNJ70rCJOGJh91MlyRv b1xXHnh9oUMhp4KKRX5H5/ZGtS5vYF3aYeQXFqPU4UBx4b+wJXUEYvmpocKVhPGD3CzPCjQ/RVFz gZsaxuFVVdKOTz0s+PO4Hj1UscB9bRtq7qnrLaX/1DAnN9Xr1pWi0tBl8N9wKP8czp3LR35+oaZ8 tuo5UEnX88npyC4W/fzZ3XMR+9xaV7I23Eei+4SPnDwbDcC6zPOSnyWn3hTmYtnoamgzW5qpJKT0 oZ2mxpOuXaFvx2ig9QEXGnbUeWyS8wbsZ2kg9UE/s/XdyS8SXUfL9VCKJSfB9LGzvSRkaf2nIFGl A6WlpeTPgUpHkbIc76rjv3Aoz0pJ2KmVOhS6/Tqb6oNaWT+F6f0ZjZ8HqNtNSv0D3/5RCuqPbL6e 7KecX0k+drme667QVp0nTTrknPoYeiWNqYDzvFtP52vmLOjGEazIn/ZcbcfxRVK8dPY32bEuXkin PQtcR1t97qZBepHXVO6k87hlU9q4S+T1nNTKn5XzufnzWLNU54Dmb39Tq6OBvLozVYkgGanSOdJS +rjEOB0dHS4knxNrLYYiJmKcUT46Oa9yCxO1fMixblo5R6znVHDoIS7ey5Fv/9o80r3+7GV9dusx 5sqsTNfVDmochfCgZVyRnNjl13muqLbcuyTz/ZbUh35uMNTKm6A9156c3esOe3U+7fm1TvzUadTh Tq+vUc409105kUJp5keGZUTNF0jS6keyOk59buhT5Hxj1ua5F1F3bnx/7icvzpJWTkEIi/zM1HWj s9IVhQPNT2FsNlDGfTnS6RuUckh8hrO8j+aOGfh52nprBlMj/6nVSCu3XNb05bOM2z6lmddyba8f rODSPujhkadre0TdThNQ6PCkb1fo2jGt9cze+YKLWR5iOqfP9VT2nFhr2xtqOW/0fpZt+pmt72qr n+amxDt928BPj6of2hTWymXFf2a69D+dPswpMx/3UMphY1mt9OtU/Re9rzNX9o2FMI6lrg/G5EzH 0vQH6f2ZdT/PK0LbbvJ5resXjPaPlzT41/+RyuPD5cBRed0wJqBD85rGtCLuQs/xLcRn5KvcL27e yhln1sbKO1tHeZgyXCOquZSpAWqoPolF3DUC+emfKF9N+W32xY/xCUjZlo7V4+8U8nmiPXjyZJBO n/bqTXbHL5lm3wZwypRmLRvl7qZWeHX1cOl2PtKOOKd53/HYOygkx0GNSlRSawJd+ozCmEf0OyDf N+YrpC94Xkmbs0Nc+Dz43VRMcUOLT3z3yFX4crLrFDARz6Uj7xLoRUWrjCBxoJPzZjTv94Iy+4An JU5xFomOIxssFi0a4Plr9y0dsLVgL1LH95Ykcf5Eh5G3r364IqTPtA2ia3ilft+Yzchc9bZGRznT oBlEv1XD3O6SGx4u77RPpvbrIZfJ2PAbrvvybEy0g6b+IbwGJC9gnFyKrV9DbYebUbeBWC+1mRIw eNwH+D67EDuTn7F9Jk14DTOr/e/U6kcEjGj6NPac2iAcVaaVF0jeeAKpT+rrnpKOGE1e0yzGSQVH SaAP0MopULLIr8bv79cLIMd0GYWNhwox2+CsdDkJXyit6OczP4Wx2UAk7ukyXEo8DI+0lmYG3dIa /ftK0YM6o4m6eErRtPWW1n9qNYrE4wsuY/vssS5+43aXJTGReGx6JrbPdC53kemMm/mu0q5FcAYK ygkt/5ITEl77Bqd+WKLQ15CI64fhnZtqonxpp+nwpG9X6Noxjbqmb3zBxTQTKSHrZxEg/NDPku3g Wz/SbH2XufG/jdFBaXoSMKRXa/VDm8L0/jM82ntbxwvp9uhrS/06Z//FqM8n99eM+q00QAWy3qrl o+kP0vsz636el5W23eTzWtcvGO0fL2nwr2r8u4bgixFgCSpLybTGi2TOYxgqy8JRP6ah5438yn/C sMh2whr+ubnleCnWgfxTxQgPqyTrvKPRLKZegBUwx85RXIgLRSUoI2sXw6tHo36D+oiK9NyJcxSf wcnTRaggnfK6v2+MmHrh5DSC6sJpBOTtvtsz04vzT5GD+qojrLIC0TExqO2ZjUYB63KSaZ9kyn1p Cb8gtQwllWHkxAVvmzFqWIb+DZmudq6gACVlFSDmQ93GzcnmkRZADX0Nb3AJS5B//Bwqo6NRcbmE 2C8W9cz1ZUIcl0oyXb8YJSVkA7Kw6qT6lSAsugFiGtb2k9yB5uejGpT11hf/SSOxo/AMzlzm18gQ P98ohpTNQPiWShTmkw1fib+OJm1nRY06aEROlXHL2Wo7rQKCDk/f2hXr7ZhKYCtBH3CxwsbntFbl vNH7WUHV7wymJTQRl5kOWoYS8sHghmiOfC6kASRgtT4EUDQjVvT+zKKf55lTtptGcpuJC077Z0Yy /6T5bQ70rWKpctBkqg/Gt3W/Btwq6dBP7zx20NNAP/T1YBIyBBgCDAGGAEOAIRCSCNzo/awg6pe3 /hU0e0Lch+qtnZfwtmqj2JAsC0wohgBDwDYE3L5Mt40DI8QQYAgwBBgCDAGGAEOAIcAQYAgEBIHK wp8wd34aSorIhtkpWySeU/EcG+QHBH/GhCEQKgiwgb4ZS5Cp0wVSOof29Dkzuat8mvISUYWrDn6q PLsYAgwBhgBDgCHAEGAI2IjAjd7PCrB+jl++xbg339AYaEn2X8hqfXYxBBgCvyUE2EDfjLUjb8O4 z+bhqfJodLjLzYaDZuhUyTQ1kPDyPMzsVoImDyu7uVRJTZjQDAGGAEOAIcAQYAiEIAI3ej8rwPrV bDwAq+bfiv9FRODmmjG4r2snNK99UwganonEEGAI+BMBtkbfn+gy2gwBhgBDgCHAEGAIMAQYAgwB hgBDgCHAEAgwAj4erxdgaRk7hgBDgCHAEGAIMAQYAgwBhgBDgCHAEGAIMAQ8IsAG+h7hYQ8ZAgwB hgBDgCHAEGAIMAQYAgwBhgBDgCFQtRBga/Srlr2opHUUnkPB5TL+yGThql6nERrWjqSixTKZQcCB c6cKQE4YR6OYGATkiGozYrE0VRAB6UxaUn3rNm6GeiFWbR3FBbhQUoka0Q1Qz3afwuqRvwusf+3n b+kZfd8RCG3/wuvH+i++W5lR8I4ATTlj/tM7rixF8BFga/SDbwM/SnARa6Y8j0HJ32h43DXjAI5P aqeJo7pxXETmwUPIPnwQ+8jvyYJS4PJlcE0SkNhvMIY9/hgaR1FRrtqZru1D16gHkEa0eP/QFUxu W6tq68OkDx4C5OzlrpHthLKUvO8KXm8fSmWpBIuSamHkDsA2n6JGmtUjNRp+CPvZfn6QmJG0GYGQ 9i9+7r/YDKVXcpUFWD93vXKCk3F6B26+rQtGPHkf+UwgXZUXsWXJGpwurybH6H8dEXhw+AjcW0/e bK8SRzevwNYzpdC8G46oh9bt7seDbZtq4/UUrcd40C/i1iZod39HtG12i3W6fs9BW86Y//S7aRgD WxBQfIkt1H4DRI4uexpxz60Fei9DyeZhCOVx7NFlYzSD/LjERFTbsQP31a9hi6Wu5a7EvZ3+rKeV nY0fN63AW8MTsCL7RwyJs9+5h7QdwsPRSEKluh4dFkMQCGn7hZiF5LIUeXOICaYSp0WkNF1IFWcU tGR3Vo+MIPRLnFn7+YU5IxpUBELVv/i7/xJw0B3nMXfcOOGlrUfeLefgaTLQry0ncpxCyujxXvMl d3qGDPTlF8HXsS/leUwiL2GNr2FYeWgGBre9zfgxTawJ/VoPnoN1815ByxDqONtRzpj/pCkwLE+g EGADfatIy29Vr5aj0mregKYvwb5l5IUEfw1eiF+WvohG/rJ2XD+MezIJ97WMQc2bS5HxaTLe3/Qz YZyFofGTEV8yD/F2O/YqYwfBAuyfKwLMfq6IVMH7m9G82wtIRB5a32ry5SGzewjZmcJ+ISQ9E+VG RiCA/ZdAwUjehcovVYAEjBx/P3Ddlfl1cI3uhOYDQWQ99Bs5GM3xOyHxxf0LsTGbDyZgyMj7wXve 64ROwm2ab/eIiBaSC+lenPwEbsVZZCQvkl4YLMeQe5fjwNoTmP3knXJC3341+iVh/OR4oKw6rl/a i4Urdwq0f141Bq1KIlC0+UXniwzfuPqY25dyxvynj+Cz7AFCwF9DvwCJH3g24RGcyLRWhNYZB14U LxxrKI5+YNfOfhnk14x7EWfODEVMTD2NLH36PI3uH/RFx0lbSfx8bP15BuJtnnJcZezAsSqmKRzS TZWxn5HwAY4jC2JC9IpE4sTF5M+8eNR2Z/XIPMimU1q3n2nSLGGVQSA0/Yv/+y/BNFDPeauwYHRr cyKENceYBSuVtCeWXcFGYVbpBCxaMMz7FPzeE5D6vpTu/b/h8PqP0faJdwR6qU+9hD4Xf0BXbRdO 4UUb6DkvFbNU+n30zla83KwnVvAEt4zE5zmD8FKc+OKCloc9+XwpZ8x/2mMDRsXfCNg/CiHriXas /RSfrv0W2Xn/h7q3cohq1Abd+w7A470eMt5MynEG6xfOwidLfkR0fDxKyNTvhokj8Mqrw9E+pqYe A7IWaPPKLThTUh1dBg5BvLIuiU/qwOEv1yD93P/QIvFxdI+71ZmfX0O05EsUlN+CLkMHICJjHWbN X4F/llzG5Uv10OPVdzFl+IMu0/HFtU5p5/+HiAjgxHLpK/mWZUhd8P9QC+UC/XLy8+BA9RopJ1vq EAUuvH6XiOuPwBVs2iRyXvPxLHSuRt4e80KSvzr3PYkn29swZSssigzyjT7Vh+GhoSMQTwb6/Itn e6Yc22AHq3hSG86ZMfL6aexYuh6zl+9ECdm/AHUS8NRfp2J00l3ORLoQKcObP8OCT9diH1+Hql0C F98VL78yHk/ef4cuta8RlYU/YcmavSiPaIKho3qjNGMtFvx9FfZllYJrejvatGqHp18hdbGha120 IqcP9qOt7xIwlvWj8hNqK1jBxZnv2qmdSPngI6zbn4+6deui4f3PYMKzsWjgTOJbiJT/1Qs3E/8Q gfuIr2qv8ZsupAkGW4gv4deFtuk7Cp1iiPMTLmLH7V9gz38qCBXpIj6ldkIf9DX0KT7YXaZPfqNv LkFe2hf4INWbv1ZlshQk62AXkHWwqI/Gda/iy7lfIOvS/6HLy+/i7cejsPiNN7CSt0udDpi6dDa6 KniITEoLc7HnHzuxa+duHDt5jmzEyV/RiE/sgQFPDkCnWFU7JGYBlHJWH12eeADnt8zDvC8OCH6C a9wBw/4yEcM7NpVTO39p8wkUrNqPZFL4WWk3neLqynX7/nh1VB+UHUzDz5erIaH3QOJblNLkzEgZ slzfFT509VbIHoh+jyQnrX46O5j1L6VnsGX1cqz7YodQJ+o0jcLtDZrgjx2S8GjPR9Gynk22k8oZ df+Fsn2nxVMpNhSBauUVFLnELBWqWVFkj1bvA30y+9SZLhr3PP42zm3/Lxp2+xvJnYaU1UfQdVwb anmMMrrqV7NpD3yc9iZWJL0rJC//r34+LL0dLNZbn8qZVf9ZQvp/nyGH2CyiZls8O/ghnb3y0lbi 66P/JbhEosfwZ9Fc16W2qJ9skEDVW5kf+w1dBDgbr9JTG7h+AEe0Nfy7K/mIjpsj/xuPeZK35uny cKUHuSSJB9mgyuX5VW5hosi/44wD2meqfO5kxLgtXJkm12XuQzf6uNJ4SyeLhpClGzpc9nJkspQh 9hpZ3z5oSRaaxMXp0xU5ZtmCi292oMKTRnE+j+MgN9SLHTq+s4OrMKJfcox7Tyq/GptJ9HrN2OFS Po2IWIsrzfxIslUSN35Kb8Vuav5kszUtUcty+mA/Vb21VN8liS3rp+KnxkAT1vkJiZllXMR859I/ NsRdzXPWIVdfpzWJ17vSvYrfnPj9ec/JC79TfIkWc2M76nytQt04vVovOazznybqkd5fK4ytBVTY yPK4/53KndZQv8rNifPsd8euPKrJIdyYKGe9Unbr/QRtPoGpsT3c249kMsHPnR0KMz7xWq615UsP k9UYy/WdZ0BZb/msAev38MzIRaMfrX+pPPcPxWcY1QejPp0oJcV/Ugdp+y++tO80eFJop+kX9Jxn 4A9MEs1Z8LRYpzot5Erc5rnKLesr+SSjdJU/c6PkPorRc7d0PTxQ+eteKYd1CR3HFym+wOg5lR1o 6q0P5YzjrPvPjNT2it5jNmrHM45TnyvP0GkOd8EVNRr9CI2A1ltXmdl9yCEA2yQqdnYi+Qah87hU btehbC770E5u9eyxQmHWDRa4X7gpsrMhv73fXcrtz87m0la97Sz8SOC+KajUiqlyKPrOr9PB6ZyJ Kp/QaN09mlu7K5Pbv22uqjFL4DacUfOr4E7t38qt27SJ27ZtE/fBULlD15/7dNs2bhOJF/7WbeNO FqnzaUW2dkeJC3FCuyR5tm1byY2Kl2TtPI3bpMi6jtuZW2hNHDOpKyq4Cv6vrIg7/sMSFZ5J3M4i MwS8pfHFDrR4epPJzXPXcoZh3Nr9x7nsXSs0L7Xe2nnJhcAFLlU1yG/94gfc93wd2rWRe1UVP3Gr l0GaC1Vvt6U5f1fVN7HM9J6cSsrMJlJ33xFsqa27NHL6YD8Vnpbqu6S4Zf1U/Mz7CZ4ZDS4kG+l4 qF+QTlqVxuXm7uNSR8Vq7KLXXVLQ9M9lpXx1nLHbY67iDPlFXX9un6b+VpD6vZb7bNU6bt26FKWe 63ytQt0eu1uzg8LcfEBlc7JhFLd//0bNy7oR83Zw6asnSvZI4L4441DRlgf6Cdy4mQu4bbv2c9m5 pB1bN0vBh5df266Q7Cqesn4bDfyEzu60+QSJrdrPWE7v7SbJR14QqMv12M+2k3J9iFswvqPN5VpQ TPlnub7T1lueYyD7PZKGlvWj9i9l3Pohcn8ngXtxxmqhf7Z/1w/cus9mCLbVtguKCSgDtP0X39p3 y3hSaqep76RPtu2HH0ifcpv2j/Tf9p0p9cjBloE+d5VbIL8IwGguS/t1yyN/tw9VfsmoPcjf/JpS 740+/li3A2V761M/mcJ/En5OrFXji4qTqvGPazvLo0yrX6DrrdsSwR6ECAK2DfQzZnZXKvHYtSd0 6lUW7OW27juniS9UffXt5dLxLMyQvzKC03VKVQ5F1wkiDkx+k6lzNqp8aD2VO6Zybo6cxYr8nr4w HF/6lJiu9zLbv6zK4FDjIhMQfssUHHx5e6wh6e7GccT5dlj14gZI4lYe8sNLBSKHFTvYg6c75Q3i 1eWMDPJ/Ur92L/zR2fkdtEzzRt45uAI34lPXN+IXVI2F6xdFAxksRGkb2ARuiavNyi5w/ypwdj7s kNOK/dQdJEv1XcLAqn5qflb8BC0up758TvE9b2u+tF/lliodbXB63S0YWUqq+Gny9UAZv1eUcSUl JVxZmXOOSWaq5M87f6j/yqCwreDWSJ1Fna9V0mgDtHa3YgctR5N3qjo7N6tcyKR0qFvJGPzCvSe9 PNXaooI7Q15QX3TC52R67mtlsP/CSpd2UcUTpLOt8RPqL6kjvtZ+1afN55RKCpm0n5qfhXZTXa4n bT2r4l7GfTnyTqXMa7FUJaMMWq3vtPWWF0+pT6Td83u/R8LDqn5qO1jzL6rBYOznBta4yl0sUnWi DFLQR5nvv/javlvFk1ondT3S9JPklynir7eXJ4pf8vgl3tkPhmG6Ci7tvQekOkgGmeo+Cq2CKv1c +5yFOV8ofpB/qTk3+5qOi1U7+FJvnczNlzNnHjlk0n/yycnLNucsz2lCm5o2uZnTBxrMeqXXL5j1 VsaG/YYSAv9HKp0N1xlsmrRNpNNpId422MXzpoYd0N1lDed/jqVLvPvjtZEPauS49b7nQL5uClf6 1mMo1jz1/WbMWy+gpWqT0oiWfwSZyiRcezJOu2WgXh9Fv8rKLXnhgT24/E9h4rpeSnlgW6ACJw1p tUFcE4O1qYZprUVasYM9eFqTT07dK+VV3Ktec3VrZ/z5vQfEx6s34mdlJyQHflgyVcqWgGceawlH aTGKi6U/RzQ6D31Fen4MZ+2uEBLlnvOW4vm2LjaLrI9myvp8e+S0Yj9JNFt+vOunZWPeT9DiUoLd K5ZKTKdhRNffqwSIxjOT/q669z3Y9IGHRCK7DiJPKnsHZiUhOjoa1dvOl/xsCXJ+EP15x6QOZNW6 u+s6nF7GXRptPK3dzdtBy4/mrrySX9GquprVkjZejcIdTVTxSjAMMXFxqCfseFOJ0uJCFEr11lGz NbpJ7diJS2RrbDdXz3mjtH7itofxxuRmYurFX+OYwzgjbT6RmnX7mbeDulxPxZjuf1ApEIleE15T 3fsv6L2+09ZbXubg93u866e2gw/+pUUhzuiWVUejXm1VJ8pWMzo9i7f+i53tu3c87VMynuxHpfsj 5B+7XT4izz5eekphqFffWSedh6M6cConE5k5Ocjx9peZieP51/SkScw3Lw0m+/0MxdChQ9GvazXU i3vaeTwgOZp6iJeN+LzbwZd6qxbZfDlT5xLDFvxnzQ5IzfxEIvEGGlSrhqTkU8J9r5QDGK/brNom /QJeb/UosZjgI2DPZnzXLuGYpEuvAe1MH5tx5epVMVen7rhHOTRUBqUOEp95GtjxBVDtKuweVLeM dem+3tQED/QFFkgb2MlSBOM3mLhQ6RvRBiv+lUs2oCLNxfUCZKxZgOeSVxNSHyOhzmnsK/oK7XX2 peJElSmYeHbtqB8ZxHbpSfTYK+jibGD/h8sXZPWy8HAjTx2oDTh7gTRQtW+WM9j2O+yRll5ohYac XoR0+9i7ftqs5v2E77i0Gpug23gvosX9IF8CxN2KtaJR3d0a2w5kfxPS6VqOrIJFuDf2Cnau2AeQ xbHI3oCc4lfQKfoX7JX8YNcHpcEmFTf7Mpm3g+88b63lUveumqBZSjaUnTcL705KFTYgNcrxhwhn bXd9/nC7Fq5R5OVBJxLHdwYv4DrR3XAtAAAkCUlEQVTfALqIxWegzcfnpblo7NBqbHt9uW7cztZy 7U4X7/Xdh3obAv0e7/o5kbHuX2ogRm6+toxBk/AxGDz5A/RoH4fYJi3QIq6Zy8bFTl6BDNnZvlvB 0xcdyQwobLF5Azyr8lTAwLFdO4yR8Q84B+VeiJLZBzg+qZ1BqiysXJili+88bhmWzhjmtdx4t4MP 9VYnVWAibrnnZWQu2IW2o8iYRr56L8TycUb4+aJf1ai3MgTs1/8I2DPQJ/0X+aNl1/vllsGb8EXI 3UY6mGaunXuFr0/1ZSZm8nhJU16hez3tJUegHgcXFzotw9CwWSwaCpmbIZZ0UB99pDUaJvFfqDfg teUHkW7ozOi4WcsVeniGuRmfO/vxCeRNPz+ry+jKRnZ2AnnAv4l2Q8gom6m4YWjWKMJryuDL6VVE NwnM6afObMVP+IpL3YYNYI9DVmvgEr61FRLJoD6NHIexN+cCnr/9OLbnyGnSkJZzFZ1a5GCBEJWA di3ryQ+D+mvFDr4JOgwtpTrQ+IGOhJSqU+aOcGkWRke3kTCTEvFf64QgX1/FuFJPO21X07dH9WPv Vji6fUVAm0+hbC1AY4cmLZvoy3XpL7a9vHKvgbn6Tl1vg97vMaefjI91/xKGx949hveyWuGvO0Qq q5InYpVMEP2xMXc5+sa6nsaiJAhAwM723RqeAVDOjyzIrK2t2xX6yoe08HA0UmK9B1pEuvFMrSdg 1fsdgGviF/Oba96Gu//YDrHKzEBPtM3ZgbreemLt52f3PDsOUA30J04Z5PbDKL1+VaHe+hloRl6D gD39SuIl5BnIB3LJZ0ndNBQNT+mmBmrKHsXdTCX5zHo0QS03/kRPuRJXxbON9I+qRIy/cAms8rcl voKFiVMxknQQdn91BMVkoF87sCJI3IKLZ0S4voqF1XBX4CWRybm3uzd7f+ttP5ykFvMtvrOF8cwi aHKqxbJS3y3qp2ZjJWwrLqYdn0kJG+DBnuQrffYp7Mk9hbzbdgtfb+ISE5GzYwe++PEohv2qzM9C q4Y3maR7oySzXkaOrklWBvkjUr7FO893QsMouRKVYHm/Wnh2k2d8jPyE44rBFzcXMrT5XMj49bbk YqGeftTtAfiib9GWVutt0Ps9FvXTW4HEePEvUS3xRloFhmXuxe6Dh3FwNzmObeVmidIG9Gv5Gk5W zENzfTNnyM3+SDvbdzvwtF9D/1AsxYU8iXKnJJATE8Ur4o9YznFkvpdvV89XnsegPq0piVi0g9V6 SymV79kq8e07r2nIfDAiGS8emea5/tDoF/L1VgMDu/EzAvas0Q+roUzNO/LPMyZFjkRcx25i2i35 uKD7oFGJ00cOi897x+J2ud8kxDgbJ11HpzwPadLbZ5OC0CXzMlajI8rn8gUXeq7+yBkR7Q+qLjS9 2iG4eObmFbkITFZ2HtqlxPHjavlSluGSN1W66iAnCoFfW+X0aj9e4RCo7yZwp8VFzpe+NUO/F0nR L9BPgDQhjNskYYjt3F94evzQ91i/nneWCXhv7myQjeZwfMdX+PL7TOE5P+X6drd0fHxgyu4+8ghI dgdO5Ip4YdAazBn3qGqQTwQoP43vvQzyeTHzf9H7iX8fPahooPYTSqQP+dQ0/BVWyvUXP+GiC5Nf LxwPwBd9F6ZubmU5+S8ElvxuwPs9bhTwEi3rR+9fwnBH204YNGocZq3YhIqS01g9mV9+xl/z8Y+s /4rBoPwPbvseFJVtYPpr3m5MzJEI3dkQ0TbQVJPwtq+COi1tWC7XlustLUMf8539dgq6Je/RUvl5 Ovr++WtDv+O7fqFcb7UwsDv/ImDPQD+yKToPEQXNnTETW88ZC+1waJvRui3ukxJOx5c/uXy9uHYQ n6acFJ9HRam6+iSqokKZQXAoW9uFuHZsFzYas7cpVpIz7yJctmyyiT5AjYttEpgjVOkoNXRQfO5f 87bhI7mDe2ddaTMrc3TNpTJvh2DiOWfJdqWsinpdxLZlayUV78Xv5TfppKnt3P8pMX7XGGzIdt95 qtRWI3Nw2ZbKLjnN2y+49d0scLS4RKNd1+6S3Tdgn8vHzxPfLXe75tusZK7p6rd8QIzaPB0TU9KB 1r3QITaOfOl/EPjxY0x6/2vhedeHWuunXLsSs3xvwe6WaQcnQ83q8n4vETq8zn63yNSAdua8HVA6 doIaBfhmsbghItRf3FxUpM3nQsYPt9F4oAfZY4e/jr2Gr1382b7Pff1mKJL2/T9tvSWcA93voVLW fv8SFtUYTw1KUqShWc6hZLYhEMz2nVZ8zsN+Hd5ohsszXWtFaPvF7jK6pivOQvKIZ5TUc8c+ZnoS n5Ip6AEf6m0QZP/17Ab07vahyLnTHJATb0BO7BDuj6X2xoRN/3aRyn79Qq3euijMbv2IgD0DfeIm uk/4SBIzDT0bDcC6zPPSIJDsQlyYi2Wjq6HN7MMaVW67J0nYGIqPnNxhODYdvyI8ryzOxYd9HlAG 7MmjHtE6oshb0EqitGTIn5V8V45vxNC2f5ae+OcnPOo2kfDPb2Dq7O9wTt4Vvdj9oNeqJNS4WGXk U/oSfNYjGuGJf8Znm3fj1LlClDocZKf4QhzePg+PNntGGaCM6dVOaz+f+IqZrdghqHhuGYlBs3+U BvtF+Pa94ZgozTgZ+Gk/NFZhcVff8Up9eCGhD+annVA6/5WOYhzP2ISp/aoh8ZMjqlyBD9ohpxX7 IYj13Qq6tLi06jlQYkN855PTkV38q3B/dvdcxD4nvxSyIonntDc1jMOrqiQdn3pY2Fk/rkcPVSxw X1tx1w1NZKUDpaWl5M+BSkeRMv3zquO/cCjPSklYk0u5sWR3JVcoB8ic5Wr/EQVcPQB/SzstCUu+ 9G9ORkyfT8wJv+VZvDB7j+Intkx7Gn+V1vYPHPmo+5MPrOZTbERnP3PKiKnuHjBU2qcA4P3Zqoyz cBA/dmDZWHSctNUKKb+mpa23/Oy7gPZ7KFGg9y8lWDa0JV5MXY+c/EvKS32+fzZ35mJJmiTEkVMp gnkFtX2nVPyb3TuQQXatz8jI0P2lZ5xw+ThQQtp+MV1mZgb2Hzkvcs3Lwo4MkUZ6eiYKtG8KnZJt ycKe46dwPGc/1qe+jmp12ih7LsDEDvhOQqEVoq+3PuhB5T9P4s2YAVJ/OAnff/mKsIz1vomL8EGc KMucfr2xMV9s92Xp6PWrGvVW1pP9BgAB+876I+dyftCDIyK7/es444COXYZ8XrO7fOSsceW8Z1Xu nAXd3PKRZdCd7UzO+ewn8dGf3es8e1KXT8WXK96rOQ9U5sX/6mmqM1oL0+Li5GJSH2cGi6Gr3MJE 97ZWcOm90MM53BZZqpNbtIPveKqZewmrypmCg658T+COGRxBnL/9Ta/l2qgeeZHI42Pn+bXmz9P1 WU6L9qOq75LWlvVT2U9fpz3XKzpcyrjtU5xn6rorM3pZPJrVw0P+HHNn3U2Wz/AlNpH9I3+u+zGD c+EzvflrqZw/lHLYmL8Vu/tgB2PmHmJL5bahv3KevVJuyDnUYhvktL3aFo7ji7R1luykGa+r7+B0 7QrRb6hBOq39p3InXe1Am4+oT2U/H+yQs3q4FhsDfdVYerCQ6UeK3RAIfxbYfg8PgnX9aP2Lvo0n x8Fp7TliPWfQjJm2lfuEzrqmqzcGmXxp363jaSCAmShVPdLWcacvFuMTtOfakzPYyfwJLe4G94of F2Rx4ueOV6fX19jbN1PpZ8ZmrpDR2IGuvVVzduJkRmbr/rOM2zyluWK7iVvPq5lz3LmvVbbV+3o6 /YJZb7XqsbvQQMCmL/rElZBJi4mvfYNTPywB6Szqr7h+GN65qS7+vjGbkbnqbeXNvzrBoBnfomjV MMNN3O4euQpfTiZTTTVXAlK2pWPpyLuE2Kho59peMVm4cjpAdJh+95gIaRq1Pp+KyS0dsLVgL1LH 91ZFikEjmrpEJiNocVGTl/VpEF1DHW1TuAb++HIyhvRt7YZeAl7/NA1Fm190/zXKTU5T0RbtYAee puQSEjnL2biZM4VNpzR5+0xDVslHaKnZd0JMccdj76CQHHM2KlGTQ7np0mcUxjxi9mQLJZvHQHi4 vNM+WSLjWmXc5PRZTov2o6vvovDW9XPaz6hOy/XKyE/Q4RKJx6ZnYvtM53RKGfZxM99V/GkEp/dZ cjprv5G4p8twKcswPNJa+iJ3S2v07ytFD+qMJgbswqMlJ+mFoduj5CzZnd4OXsTTPyYFv4EQa6Df 7VHKlHyyiky41LaIuGsE8tM/UWbj8Nvsix/jxfZo9fg7RcoepusOnjxZsbPIgfzv/SGOlXjeqMlq Pjr70dvh7oGfkj7BXCc2vHJdJmDdD5swSlHU3oD1+g7Q1Vte7sD2e3iO1vWj9S83o3m/FzR9s2z5 CAkixziy8WTRogG2z9bjdeQv2c+a6b/40r5bx1OUz/p/Zz3ynLcDaqjb4fAaaOE5g/C0fg21w74Z dRuIfkebNQGDx32A77MLsTP5GZv7Zk79jNpGrRz6Oxo70NdbJ38r5cyq/yw/sQ593v+XwKzT699i evffOxnzodt6YuX2N6W46XhzxT81z+n0C2691SjAbkICgWr8+wb7JalEYX4+LleGITqsEhU16qBR vdpKZ8mQH5kSc66gACVlFfySXNRt3JxsaqR2XIa5UJx/CkVkBXhYZQWiY2JQ23sWY0KhGkuJSyDV 4dfq89N5S64TrpVkQ6OwaDRq1BCRoWiLYOBZWYr8/CKEk7pQRtbiN4upZ8o8juJCXCgqQRmpEOHV o1G/QX1EhSCogZSzKtV3GlwchWdw5jI/BzMcdRvFoJ4JH2iqMLFE/kdAqOcXgephqCwLR/2YhvBo vvKfMCyynbCGf25uOV6KdSD/VLF3P0Gbz/8IeOBQSabt8+s5whDJ+7BrP6JrVKJw4gP5oo/xbYM7 /VstOE29FfMHrt+jltdKmM6/kOWXZIliaQnpmJEWrIT06xqRvpbHsm1FKDvTBqN9t1N+RosaAfp6 S80yoBmt61eF6m1AkfztMfPTQP+3ByTTmCHAEGAIMAQYAqYRUA3YLQ12afOZFsy+hI7iM+REndsQ U0+eNSTS3j2nBzqO5TcbTMA3BYfQ4zd3jKN9GDNKDAGGAEOAIcAQcIdAKH5zdScri2cIMAQYAgwB hgBDoIogkLtyINqO3Y8+L76Hfr3+iOa1gf0rkzFx4S5Rg3HT8Cgb5FcRazIxGQIMAYYAQ6CqIcAG +lXNYkxehgBDgCHAEKj6CJCZ0AWSFo7/WVCHNp8FFnYn3bzor9i8yIUq2YPg5Ixenpf0uWRhtwwB hgBDgCHAEGAImEeATd03jxVLyRBgCDAEGAIMAXsQqCzA5pVbcL48Gh2eehrxtW8yR5c2nznqtqaq JMet5h77CYeOnMTFi+dxpYjsP1GnKe5/tCd63t+UDfJtRZsRYwgwBBgCDAGGgBYBNtDX4sHuGAIM AYYAQ4AhwBBgCDAEGAIMAYYAQ4AhUKURsPF4vSqNAxOeIcAQYAgwBBgCDAGGAEOAIcAQYAgwBBgC NwQCbKB/Q5iRKcEQYAgwBBgCDAGGAEOAIcAQYAgwBBgCDAERAbYZHysJDAGGAEOAIRAkBKSzx8uA uo2boV5kkMRgbBkCDAGGAEOAIcAQYAjcYAj4ZY3++ZwfsOPQv8FvJFw7/jH0bXubF9gcOPBlCt6f +x2iWrRA6cmTaPzYnzB+3ONo7MeOn3U5vajh9nGg9bOTXyUOrF6MHy+VIDqmB0b3vdutljR4Xsvf j89S5mBx2lFwdeuiaXQjNL73PvTu9wS6xnkrN25F8csD6/rZaQfzKlmX0zxto5SB42cnnp7LdXF+ Nn7YsQ17ftiLrIJS4PJlcE0S0O2p4RgyIBGNTPslB3YvXYDMkmqAIwIPDh+Be+uZ3HTNCOwbLY6c Cd81sh3SiF7J+67g9fa1bNfQevm0s5yZV8e6nOZpyyntK9cyRTO/duLJ6q0ZxFkahgBDgCHAEGAI CAhwtl0VXP6hDdyr/cARwspfxxkHvHC4zC0d5UyvzguM5n4q8pLd8mNaOS0zkjIEWj+b+Z37WrHl QylGtqTH8/imtxTaWruT8tByDme76alMSKufzXbwKjutnF4Ju0kQaH424+mhXB9f+pT7cin4tiRu Y26pG1y00YXp0zW0yGBWm+C3fuc4yA2V2otZh+zEhrZ82lzOvNqXVk6vhHUJ7CzXOuJuI2zGk9Vb t0izBwwBhgBDgCHAEHBFAK4RVPcVJ7n3Eo0H671SDnskmf5BB2dHuPNUbtv+XdzS8b2cca0+5C54 pGDhoQ9yWuCiSRpQ/Qhnu/mlv/eAZIv+3L4SjWoc5wOe59LedNqYdPQHv7uU27ZtG7dq/gxuaHyI DPR90M9uO7ggr731QU4tIZN3geZHxLIbT0/lOjO1u1I2u4ycws1ftY7btO5TbpTGx03gjpV5wavy Z26U6qUn/zLL3sGsF/5V4bE/Bvo+lE+7y5lHE/ggp0e6bh7aVq7d0DeKthtPVm+NUGZxDAGGAEOA IcAQMEbAnoF+6UGun9KhTeJS1q3iXuUHayTO40Bfk28qd7JCFrKMm6PQs7FzrOFnQU5ZLKu/Gn6B 1s8GfsU/ckmSHTrO2K3XXqOfFTxPc1MU+yZwK7KLXWiXcRcvur5VcEkSiFta/TT5bLCDN101/KzY wRthN8+Dys8GPL2U63wy02TQO6u5k0WVLgBc5VaPvFN5CTDrp2suz7W3acpLMudLUDbQ12LEkYG+ 3HbYhg1t+dTks6Gcuaiqu9Xw83+9tatc6/RwF6HRzwY8Wb11hzSLZwgwBBgCDAGGgCEC9uy6H1YD TeLuxox16Siq+AHjnhiANk3IMN/LdeXYd9gopXn7+1fRXN4a8FI6flDl/eofR1V3PgQp5aTlGGj9 7OZ3eMVMYe0skIDXn39QDwMlntcOb8X7ErVJG7dgSNwtLrQjUa9elEtcEG4p9bPbDl41p5TTK113 CQLMz248vZXrO/q8jVVvDkTz2q5r6aMxYMxYBZUD2WeUsGug/MRiJP11L4nuj8/WpSDeNUGQ70sL c7F99XxMGTUE/ZKSkCT89cP49xZi1/FLxtJVFmD9gtlITV2G7OJSnNj+KUb3SyR545EQ3xWTP9sD spuB2+vaqZ2YNqoPEhISBH5DJi9E5unraOA2B+UDyvJpdznzKj2lnF7puklgR7l2Q9ow2m48Wb01 hJlFMgQYAgwBhgBDwD0ChsN/nyOvcsv6ev+in7Ogm/R1LInbqSzIJl/Nhji/gBHJOXRa6Kf12ubk pIUj0PrZyk81pbbl2G85ZbKFRzDM4emcQjqMOybQK+OKii6Sr/gXuaIyc5w8iuG3h+b0s9UOVLqY k5OKtGEm//KzFU+qcu1U2nF8kfJFf8zGPOcDTegX7j1pRlPPeUc5xylnHtu+Wmv4Wb25ys2Jc/Gx ygwbMX7syqN6ouQLrTzDR/DLLnmEuHFbOKMVDefSP1Zwc5fXf9iYK5+2ljM9eiZizMlpgpDlJObK tTWytuLJ6q018FlqhgBDgCHAEGAIEATs+aJPem4015WrV8VsrZNwR20xeGnHRxi00oVatauocImq CreB1s9Ofie+mosVEshvj30Y8mQLW3Ef3A7nN6cgoVp11KlTH/Xr10ed6uEY/O4aFFTayimgxOy0 Q0AFD1FmduLpa7k+uZ//Si9eLZvWl4Oa36PLJuCv2XzUBKSMbg1cL9c8D52bBIybuQDbdu1Hdm42 0tbNAhnIC1fqkLuxMf9XrajhQCN1zN2jsXZXJvZvm6vkw+w3sN0137V9eLnjBCXnpFVpyM3dh9RR sUpcKATsLGehoI8VGcyUayv0+LR24snqrVX0WXqGAEOAIcAQYAgAQRzoF+Hwtn2iDUiHuS4fKs/C G0nvCnEDVx7F8S+Hi8937kWepzmhYqoQ+x9o/WzkV/kvLBj0mYjnoDXo08zOYlKEnzZsE2mvGoOu fV+FMCZSWW/1W4Nwe/gb+FeVHOzbaAcVJr/doI14+lquz3+Dwc9J9aLVh+gT9zu9WYQ0a4X4t7+f guYkFHovKWug96psXKw4gpSJI9Gt4/2Ii41D4hPj8cO5r5VB+9e7T+n1k2NaT8Wxg/PwZMd7cH+3 l7A1Z7H0JAvHz1+TUwm/ed8uVC3ROo8ZgxIRG9seY+ZnYOkQTdIg3thYzoKoBRVrM+XaMmEb8WT1 1jL6LANDgCHAEGAIMAR4BOwcwVlENBr39HtGzEM+7JOPRdj94ctYwMe0noYPB5MvYZevi8/Jf/55 1boCrZ99/M5uW4hZEthzX+8N00eGmzJQHST0e1qTctLKAygqKUPJxSykKh3/6Xhzxc+adFXjxj47 VA19/S2lfXj6VK4rz2Bat17KS6kl60drv24LMBRh4UtSmt7LMKGr8PrS3wBR0A9DTFwc6gnTdCpR WlyIwuJiFJM/R83W6JYokjxxyel/XZmMeesFtFQ5hoiWfwQ5YUC49mScViUvwe4VS6X7aRjR9feq Z9F4ZtLfVffBDNpXzoKphWXepsq1Zaokg314snpLgz/LwxBgCDAEGAIMgaAO9K/jWNrnog1uj0JR 3hfoKGxeBSxZPV7oRKu/hKnDVcNwgdbPLn4FWP7GhyLEvReSjfIMvlr6ZIASHEn7QqHQc95hzCBT +GtHRSKqXjzGfHYSr0pP1yzd63FzL4VISAXsskNIKRVEYezC05dyXYRlw5tI0/GBsWtP4PnYmjpM zm6ZgVGb+OgEbJg/GPJ2kuqXlBGcXxbB6GTxGlF6Bus/GEeWzYQjml82U6cOWT5TB9Wjm2DiDjH3 HyLUkmsptox1WbZwUxM80FebxvWu1dgE3cZ7ES3ux1DXhEG5t6ucBUV4SqbmyjUdcbvwZPWWDn+W iyHAEGAIMAQYAvDP0mtzwN6MKLknfHQR/tQ/TcgW+84OPB/vOrhsgFru+5zm2AU8VaD1s4ffpd3L lAFN8pSnlMGKnfApdieThCc+3UZLOqw5hqZ2x6yxZHr/rt047XgR8aovh9rEoXhnjx1CUbPgyGQP nvTlugTrX22P51aK2vdK2Y3ZT96ph8JxDG/0kV6QjXgTnetcJ1/IydqTsOooLbyopM+/eBGlpbcg vHptRAZrzF+ahdHRbcTZU7Jk8fHSyQDZyJbW0pSWu3+9Wl5BdLN41W3YIJgNjhdp7SlnXpiE0GOT 5ZpaYnvwZPWW2gAsI0OAIcAQYAgwBII5dT8ScR2lKdzZadgodC5H46uJXSSzlOBQuvTlt3db3F6l Bnu8CoHWzw5+F7Hmzaki/mQN8vPta0m2sPMn2ml31MLvDAY74RHREsNSXHc/1rBTKBtp2WEHG8Wp 8qTswJO2XFdix7TueCLlpIBiy9e/xbpxDxojWnndOftk8eNkU8lo4Qt5nejqiJH2HeEzzuzRFNHR dTArm6xXCtJ1dE2yMsgfkfItCsiyGS4rC1nC31WQE1MCeIXKG1w7ylkAYfOJlYVyTc3HDjxZvaWG n2VkCDAEGAIMAYYAQSCIa/SBGnVv1Rgheec057rPX3/BPukrGhrUNV6jT76iTU2oJpzLzJ/NXK3a Szjkz037LPILtH6+8rt2+EuMlabtTvzbELhMztXYypeb8IgaSnajcXwF5EFQlLHdSW7HuWxs375d +kvDv0pddghXOAQ+4KsdYLGc+axhiPPzFU/acn2AbBiRJC0nwotrkJH8qPv9Ksh4tcRnQwSiXDtw IjdTlJRstDln3KNoSJbNKFf5aXwvLD9QYnwOOCQK6VszUOxKregXZLnGBene13JWVeqtpXKttoVF P+ErnlWm3lrERQ0pCzMEGAIMAYYAQ8CfCBh8T7WD3c0KEc7DOs+Ydl1Juk/EtC3n4E+dnJtXXdr1 hfLVacyj7Yw72OQr2jEyE4BMNpX4NbO4w7U5ORVlLPILtH6+8SNTOT/+k6TqVLzUXb1ploKAl4A5 PJt35Hf74ncv34DFm0+j/eAmKroF+OaT7eJ9p4fQVF7eoUrBB3PXj0L3sfuV2OR9V/C6X2YgKCxI wJx+vtmBsLFYztQSimFzcir5Qpyfb3jSleujy57H/ePEGUWtRqzB/oXPeF7GEtEGG4uKoJvQzk/d /ylZ+ao/aWsepj7ET903ni0TiHJdszr/Co+fpRChm0p/9rtFyrGaSvnwKRCNdl27A5v4pTgbsK/w FfSo5yR44rvlivd2xtodMlcffCtnROYQr0c8qpbLtdoUFvXzDc8qVG8t4qKGlIUZAgwBhgBDgCHg TwTsG+g7CpB5MA8VN9+M8PBrOCJtvHwmcy8yMsk50hXk2214PSS0baoM2m+6ozNSyZhP+IqcOwbT 1yVi2pOt4cjbiKeV6a5JeOLhPxhjQL6iuY4DvU4EpZBTYW6RX6D184Vf+YlNyjrkF9a+gMaK0l4C FHje1DQJ0wjZN8jfkiH9cffvN+CVrk0QRmitf/dpZY+AXgPIJn1u2IdHxJAnzoF+pLMv7yYHZTSN fjd4uRaQpMBFsUAA6xFNuT7/7VuIk4/RI0L/ZdhdOJmRoX2J+L//oXqzexDfUN6ULwxRtY1La416 zrkxMfXrk71JXPcgUZCB/8s1cfnV/iMyXD0Af3shD68n8S/ayJf+zbMQ21d68eoUyedQq54DiZMn A32koeeT05G14XXE174JZ3fPRexz4lGEPjNxJUBRPn3xnwJ7i+VayEMhp6KqRX505VrhJhx9Y6W9 9QXPKlVvLdpBhSgLMgQYAgwBhgBDwL8IcDZdpZkfcURSL39J3L4SLUPHqc+5eA/5xqzN02ZQ35Ue 5Ppp8vbnfnKhr07Oh2nlFOhQ8Au0fnT8KrgtI2XbjeayylxRc39Pi2dpzmKXspLgck/k8GDLnKVP adLP2nfFvZA+PKHVj84OkqAU5YxWToFjFeBHhydduc5M7a4pW+782l0zDpgqWaU5f1fozTrkuZwG olw7ji9S5BF0i4839MG9Ug5r9XM4/a1ej6vcgr6iD9Hl48q47VOaaXlq/LaYT09Ty97KHW19oCtn kmQhXo98LtcU+tHhWcXqLQUuVsoyS8sQYAgwBBgCDAFaBGxbox9eQ95AzdOLiTtRg7z9Vl8RTZ/G nlMbDI9YSt54AqlPqqd1q3OScHi4y3FNrt8bXNLzWSjlFChR8Au0fjT8fj2/BVMXilj1nPeKpV3u afGsefcLKM1V2925Urf1i3NwrGQe4t2ak3x93HtEZdxh6NjaeCq0KhFVkFY/GjsoAlKUM1o5BZ5V gB8NnrTluka0uWUrbWs595pQbGcQCA+PUGKjwzxNogpMuY64awTy0z8hZ15IF9lmX1z8lICUbelY Pf5O4UGUbtlVuDKDykiPCKm+RkW7OHkyh+ux6ZnYPvMZmaPyO27muyAva4XLzqMHaesDTTlTlAnx euRzuabQjwbPKldvKXBRygwLMAQYAgwBhgBDwI8IVOPfEPiRvgXSJcg/fg6V0dGouFyCuo1jUc/t QM8C2ZBJGmj9zPIjOzBP6YKk5D0Eqf7YV/IV2gcUdwex+0mUVa+L6mVkO7O6jRDjzfC/HsPosNbK Hg4DPz2K1cNbh4yltYKYtYM2F7tzh4BZPINdrt3J7yE+0OW6shT5+eTov+phqCwLR/2Yhojy9B7C g+hmHzkKz+DMZQdJHk6qegzx8X5maFYwXTqz5UyXkUUYImAWzypYbw31ZZEMAYYAQ4AhwBAIPgIh NNAPPhi/SQnKszAsso2wAVfHGQewa1K7kIehPG8FIpsNk+Qcjawy8vVftXF4yCvABPQ/Aqxc+x9j xoEhYDcCVbDe2g0Bo8cQYAgwBBgCDAG7EGADfbuQZHQChsDRZd3IZmnfCvxeWHkCiweLU40DJgBj xBDwAwKsXPsBVEaSIcAQYAgwBBgCDAGGwG8UATbQ/40aviqrfe3UTqz6JgvlEY3Q54XH0ThUZ/9W ZZCZ7AFHgJXrgEPOGDIEGAIMAYYAQ4AhwBC4YRFgA/0b1rRMMYYAQ4AhwBBgCDAEGAIMAYYAQ4Ah wBD4LSJg2677v0XwmM4MAYYAQ4AhwBBgCDAEGAIMAYYAQ4AhwBAINQTYQD/ULMLkYQgwBBgCDAGG AEOAIcAQYAgwBBgCDAGGgA8IsIG+D+CxrAwBhgBDgCHAEGAIMAQYAgwBhgBDgCHAEAg1BNhAP9Qs wuRhCDAEGAIMAYYAQ4AhwBBgCDAEGAIMAYaADwiwgb4P4LGsDAGGAEOAIcAQYAgwBBgCDAGGAEOA IcAQCDUE2EA/1CzC5GEIMAQYAgwBhgBDgCHAEGAIMAQYAgwBhoAPCLCBvg/gsawMAYYAQ4AhwBBg CDAEGAIMAYYAQ4AhwBAINQT+P6wEG9C7DJ7pAAAAAElFTkSuQmCC --Apple-Mail=_C0700171-CEA8-4D57-AEEF-49549F7E6719-- --Apple-Mail=_46C6968C-5824-4C11-AB27-005C7709C5FC-- From nobody Wed Oct 21 15:40:55 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675911B3316 for ; Wed, 21 Oct 2015 15:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC4RgnFqzs0w for ; Wed, 21 Oct 2015 15:40:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955301B330C for ; Wed, 21 Oct 2015 15:40:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 851D9258599; Wed, 21 Oct 2015 15:40:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 2279524EED8; Wed, 21 Oct 2015 15:40:52 -0700 (PDT) To: Richard Li , LISP mailing list list References: <56253E35.6070309@joelhalpern.com> From: Joel Halpern Direct Message-ID: <56281473.8090008@joelhalpern.com> Date: Wed, 21 Oct 2015 18:40:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] looking for clarifications on rfc 6830 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 22:40:54 -0000 Looking at the text, there are two different references. The first part talks about "a Map-Request with n EID that best matches any EID-prefix MUST be returned." This is correct. The Map-Reply must include the EID-prefix which best-matches the EID from the request. The grammar is a bit awkward in trying to say that if any other prefixes need to be returned along with that, they need to go in the same Map-Reply message. But the text is not incorrect. And the later text makes it clear that the prefixes that must be included are the more-specific prefixes within the best-match. The current structure is important in part because conceptually there may be other reasons why a set of prefixes need to be sent. Still, I would ask that you help us keep track of the fact that thsi third paragraph of 5.3 could be worded better. Yours, Joel On 10/21/15 6:16 PM, Richard Li wrote: > Thanks for your answers. > > Speaking about the Best-Match Prefixes, the RFC asks for returning > all best-matched prefixes. For the example in the RFC, The prefix > 10.1.2.0/24, for example, is NOT a best-match prefix, but the RFC > still wants to return it. This is exactly where the confusion comes > from. > > After reading your explanation, it comes to my mind that it is better > off to introduce a concept like "more specific" and "less-specific". > > 10.1.2.0/24 is "more specific" than 10.1.0.0/16, and 10.0.0.0/8 is > "less-specific" than 10.1.0.0/16. > > Using "more specific", the RFC could be rephrased as something like > this: It will return the best-match prefix and all prefixes that are > more specific than the best-match prefix. > > For the example in the spec, a Map-Request for EID 10.1.5.5 would > cause a Map-Reply with a record count of 3 to be returned with > mapping records for EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and > 10.1.2.0/24, since 10.1.0.0/16 is the best-match prefix and the other > two are more specific than the best-match prefix. > > Does the above make sense? > > Richard > > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Monday, October 19, 2015 12:02 PM > To: Richard Li; LISP mailing list list Subject: Re: [lisp] looking > for clarifications on rfc 6830 > > Thank you for reading RFC 6830 carefully. My understanding of the > answers to your questions is in line below. Yours, Joel > > On 10/19/15 2:43 PM, Richard Li wrote: >> Hi Folks, >> >> I have read RFC 6830. I have a few points I could not figure them >> out by myself. Appreciated if you could clarify them. >> ... >> 3.Best-Match Prefixes >> >> Page 35, Section 6.1.5: >> >> A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a >> record count of 3 to be returned with mapping records for >> EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. >> >> Take a look at the EID prefixes in binary: >> >> 00001010.00000000.00000000.00000000 (10.0.0.0/8) >> >> 00001010.00000001.00000000.00000000 (10.1.0.0/16) >> >> 00001010.00000001.00000001.00000000 (10.1.1.0/24) >> >> 00001010.00000001.00000010.00000000 (10.1.2.0/24) >> >> 00001010.00000001.00000101.00000101 (10.1.5.5/32) >> >> Performing the best match of 10.1.5.5/32 against the EID prefix >> database, we will have only 10.1.0.0/16. > > I am not sure what your question is here. The reason the extra > entries (beyond 10.1.0.0/16 have to be returned is not that one of > them matches the request. Youa re correct, and the text agrees, that > there is only one entry matching 10.1.5.5/32. The reason the extra > entries need to be returned is that in the absence of those entries, > later packets which match those other entries will be misdirected. Is > the text insufficiently clear about the reason for sending the > additional entries? If so, can you suggest text improvement for us to > use in the next revision? > >> >> Thanks, >> >> Richard >> >> >> >> _______________________________________________ lisp mailing list >> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >> From nobody Wed Oct 21 16:06:44 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D1F1A8F3C for ; Wed, 21 Oct 2015 16:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUCj8l0R_daQ for ; Wed, 21 Oct 2015 16:06:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0051A8BC0 for ; Wed, 21 Oct 2015 16:06:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZC93673; Wed, 21 Oct 2015 23:06:37 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 22 Oct 2015 00:06:36 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.220]) by SJCEML702-CHM.china.huawei.com ([169.254.4.95]) with mapi id 14.03.0235.001; Wed, 21 Oct 2015 16:06:34 -0700 From: Richard Li To: Joel Halpern Direct , Dino Farinacci Thread-Topic: [lisp] looking for clarifications on rfc 6830 Thread-Index: AdEKnhay+P+VUKtLQsuYBYLz3YP9mwAPT92AAFw2xRAAEAEsgAAOCvrA Date: Wed, 21 Oct 2015 23:06:34 +0000 Message-ID: References: <56253E35.6070309@joelhalpern.com> <56281473.8090008@joelhalpern.com> In-Reply-To: <56281473.8090008@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] looking for clarifications on rfc 6830 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 23:06:43 -0000 Yes. Agreed.=20 With yours and Dino's explanation, I understand why LISP needs those "more = specific" prefixes. The original wording just doesn't seem straightforward = enough.=20 OK. I'll keep track of them for your future revision. Thanks, Richard -----Original Message----- From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]=20 Sent: Wednesday, October 21, 2015 3:41 PM To: Richard Li; LISP mailing list list Subject: Re: [lisp] looking for clarifications on rfc 6830 Looking at the text, there are two different references. The first part ta= lks about "a Map-Request with n EID that best matches any EID-prefix MUST b= e returned." This is correct. The Map-Reply must include the EID-prefix which best-matc= hes the EID from the request. The grammar is a bit awkward in trying to say that if any other prefixes ne= ed to be returned along with that, they need to go in the same Map-Reply me= ssage. But the text is not incorrect. And the later text makes it clear that the prefixes that must be included a= re the more-specific prefixes within the best-match. The current structure = is important in part because conceptually there may be other reasons why a = set of prefixes need to be sent. Still, I would ask that you help us keep track of the fact that thsi third = paragraph of 5.3 could be worded better. Yours, Joel On 10/21/15 6:16 PM, Richard Li wrote: > Thanks for your answers. > > Speaking about the Best-Match Prefixes, the RFC asks for returning all=20 > best-matched prefixes. For the example in the RFC, The prefix=20 > 10.1.2.0/24, for example, is NOT a best-match prefix, but the RFC=20 > still wants to return it. This is exactly where the confusion comes=20 > from. > > After reading your explanation, it comes to my mind that it is better=20 > off to introduce a concept like "more specific" and "less-specific". > > 10.1.2.0/24 is "more specific" than 10.1.0.0/16, and 10.0.0.0/8 is=20 > "less-specific" than 10.1.0.0/16. > > Using "more specific", the RFC could be rephrased as something like > this: It will return the best-match prefix and all prefixes that are=20 > more specific than the best-match prefix. > > For the example in the spec, a Map-Request for EID 10.1.5.5 would=20 > cause a Map-Reply with a record count of 3 to be returned with mapping=20 > records for EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24,=20 > since 10.1.0.0/16 is the best-match prefix and the other two are more=20 > specific than the best-match prefix. > > Does the above make sense? > > Richard > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Monday, October 19, 2015 12:02 PM > To: Richard Li; LISP mailing list list Subject: Re: [lisp] looking for=20 > clarifications on rfc 6830 > > Thank you for reading RFC 6830 carefully. My understanding of the=20 > answers to your questions is in line below. Yours, Joel > > On 10/19/15 2:43 PM, Richard Li wrote: >> Hi Folks, >> >> I have read RFC 6830. I have a few points I could not figure them out=20 >> by myself. Appreciated if you could clarify them. >> ... >> 3.Best-Match Prefixes >> >> Page 35, Section 6.1.5: >> >> A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record=20 >> count of 3 to be returned with mapping records for EID-Prefixes=20 >> 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. >> >> Take a look at the EID prefixes in binary: >> >> 00001010.00000000.00000000.00000000 (10.0.0.0/8) >> >> 00001010.00000001.00000000.00000000 (10.1.0.0/16) >> >> 00001010.00000001.00000001.00000000 (10.1.1.0/24) >> >> 00001010.00000001.00000010.00000000 (10.1.2.0/24) >> >> 00001010.00000001.00000101.00000101 (10.1.5.5/32) >> >> Performing the best match of 10.1.5.5/32 against the EID prefix=20 >> database, we will have only 10.1.0.0/16. > > I am not sure what your question is here. The reason the extra=20 > entries (beyond 10.1.0.0/16 have to be returned is not that one of=20 > them matches the request. Youa re correct, and the text agrees, that=20 > there is only one entry matching 10.1.5.5/32. The reason the extra=20 > entries need to be returned is that in the absence of those entries,=20 > later packets which match those other entries will be misdirected. Is=20 > the text insufficiently clear about the reason for sending the=20 > additional entries? If so, can you suggest text improvement for us to=20 > use in the next revision? > >> >> Thanks, >> >> Richard >> >> >> >> _______________________________________________ lisp mailing list=20 >> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >> From nobody Thu Oct 22 02:02:27 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F6B1B2BCE for ; Thu, 22 Oct 2015 02:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Edm5HAAos8fW for ; Thu, 22 Oct 2015 02:02:24 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5FF1B2BE7 for ; Thu, 22 Oct 2015 02:02:23 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so125850891wic.1 for ; Thu, 22 Oct 2015 02:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oHRjsVEyFiFKhX1gpVN+JG9XzMp1C2XNibTfGo2tsyI=; b=wkncraD68FpZxi/XcD8PRq8a80gO2klnKEAzn5L2v6d4kXrnalEfwfzUKO4OqHgtq1 wR8yExEnKUpSESWReI+Av4HB1p7zm3NmLp9MpgWqejTmMyiKTHrclgGU0tKzSKTmcjN8 UK/tWzhO604JNGbkw+7PQB+7QdhdzY1TkBnUhj2qV5e6MZfJV861aLcaWSfwbelWgM/2 pO31ZJjEFR1/NqeAUlYdb4jMeLrkZBTM5/FCnFHYDHrC5oOHhHPFOIvNcDsXpyfUF3JC 7U9XksH6Z+DgPiPqrdSHjaJCQI08iTuzc9upx5CQxbB2lYHjYJ/jZ5sBF171QDqaWl+2 XbNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=oHRjsVEyFiFKhX1gpVN+JG9XzMp1C2XNibTfGo2tsyI=; b=Td+ITzfYZBRALm/XSrtJFj5VlRHhwEn3hleu2S2kLFHLZGdl2Vkg3ovxWUEBsYTLBm 5Liy6vmR4bNPnRv1wEYaXUMlQ3ve1J21zQvTgB7HQTfPjBNNpFgJiKeiWG6vEQOtYn86 oF8TYOh1XIYqiUScTPo05e+GMwThaFKFdJ7Qm2k0kDsUNNtC0cXh0PnIyc8yKOnwZuoe UXXX7er9pQT2o3zLrMMYw/qezJoKfnNa9/j9qAAWtomeA6cIJ2uOUSEonybw77Y/MJ29 Md3CuPCQUedSn/BvmhHKgRZW+XrpxUF9O3/++CDgZqsq2gp5ETn4ZXtMw4IS8WcZcYOG yONg== X-Gm-Message-State: ALoCoQlhJFNPYoDROkcqqRgwlWAM70x4bJNWeoXqOTW+Gjqwd+Ddj1Jmr4zS1KrOUgaQBr7u/C8b X-Received: by 10.194.209.240 with SMTP id mp16mr16117564wjc.100.1445504542217; Thu, 22 Oct 2015 02:02:22 -0700 (PDT) Received: from ?IPv6:2001:660:330f:38:2474:3be7:17eb:d933? ([2001:660:330f:38:2474:3be7:17eb:d933]) by smtp.gmail.com with ESMTPSA id ds10sm27141889wib.24.2015.10.22.02.02.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 02:02:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: <20151020084725.10777.28272.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 11:02:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <900C4150-4DD2-4023-880E-E60087952653@gigix.net> References: <20151020084725.10777.28272.idtracker@ietfa.amsl.com> To: Terry Manderson X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Terry Manderson's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 09:02:26 -0000 Hi Terry, thanks for the comments. > On 20 Oct 2015, at 10:47, Terry Manderson = wrote: >=20 [snip] > I have two suggestions. >=20 >> =46rom the introduction "The main goal of LISP is to make the routing > infrastructure.." please consider s/is/was/ given the tone of the rest = of > the document and the discussions underway regarding the WG. >=20 Yes, it make sense to make such a change. > Section 2, second paragraph "Provider (interdomain) Aggregatable"; I > think "interdomain" is superfluous here. >=20 Will be delete in the next revision. Thanks Luigi > Thanks > Terry >=20 >=20 From nobody Thu Oct 22 02:08:43 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F17E1B2F66 for ; Thu, 22 Oct 2015 02:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_yTwz0iREgX for ; Thu, 22 Oct 2015 02:08:41 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A221B2F24 for ; Thu, 22 Oct 2015 02:08:40 -0700 (PDT) Received: by wikq8 with SMTP id q8so21707915wik.1 for ; Thu, 22 Oct 2015 02:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ljrdH1Wqo0Pw2n3sVUwQNQZBcQeF5XR4FX95Zz2wv1Y=; b=NMyHHXHvuDj9UttKp4ojqfc72hEmmbJHPeUOEDaDYuv2binPO9C8bdvShMX9FwC7+L QkSJ+uE39gyIdSiFJLk0zdRw+6chcl2texc3ccAA4dStcS6h5mLxK/qkjpGeb6U9C9lj M+bMUFs4bLcZqHFqKgpJDtaoUdzYb7A1D35+1Gr52rK86lMiu/zFv5OOF0XL36Ja2sYE /bivQQCZEoPunUK/DJRFptrjd92Ze6IKifoWkzfO0EUB+cB2r5S9yQeVO+uDdDVkGD2a dgShV7DHfLvOPbEcMfUSLNXyaqUZqJyHQ+4K1nEaNFy/YqDWAct+OE81lpse9h7TNntN 0W3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ljrdH1Wqo0Pw2n3sVUwQNQZBcQeF5XR4FX95Zz2wv1Y=; b=fFT3hC6/m7NsJt3rWbSky8mVCv3xw0fM7oQjFIvsEjU3cjwlDk+yXT5MExfckdibwC IwWGqJGmfe/cIQVBi8qqDfQruyWbtXp2bNQAhoZM4wIlT6Vr4+TAoGYIPhXr1RYugtTa PCbLTnT0DfpCfu3UfsQzkvzMxhgRyuBhdFXYGTgwn0IeMKepv4fSqGL4+JQEvkQaRKgz GBFDRA6a0WARIPxcs6nYAWl7/mdZGUn9UDSeKxNvZnaFK5LuqaEpf/F8yyqnPhMgEbZF x7N+wOWXiAqSChQI2Y084Fe3aILIFNyf2b6bIkjQFuwbB/mLOxzrC7r3n6EcnCh76iKL 6ZHw== X-Gm-Message-State: ALoCoQlh9aIr91I09I154xeViKEn1xgUxTm10saDz7eR7UgbJEd0b4EPBojjsZxIoMzW0yufNhE0 X-Received: by 10.180.206.230 with SMTP id lr6mr16856461wic.69.1445504919340; Thu, 22 Oct 2015 02:08:39 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:69d0:ed82:4a4d:120e? ([2001:660:330f:a4:69d0:ed82:4a4d:120e]) by smtp.gmail.com with ESMTPSA id ht5sm10759086wib.10.2015.10.22.02.08.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 02:08:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: <20151021021458.7620.61602.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 11:08:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2DAE09CA-B090-404C-89D6-D1EB4DA85426@gigix.net> References: <20151021021458.7620.61602.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 09:08:42 -0000 Hi Ben, > On 21 Oct 2015, at 04:14, Ben Campbell wrote: >=20 [snip] >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > It seems odd to me that an "impacts" paper would leave security = impacts > out of scope. Even with the detailed security considerations in > draft-ietf-lisp-threats, it seems like there might be some = higher-level > observations to make, along the lines of the rest of the draft. >=20 Yes you are right. We proposed an updated security section in the reply to Hillarie, who = did the secdir review. The proposed text is: A thorough security and threats analysis of the LISP protocol is carried out in details in [I-D.ietf-lisp-threats].=20 Like for other Internet technologies, also for LISP most of=20= threats can be mitigated using Best Current Practice, meaning=20= with careful deployment an configuration (e.g., filter) and = also=20 by activating only features that are really necessary in the=20= deployment and verifying all the information obtained from = third=20 parties. Unless gleaning features (actually deprecated in RFC 6830 [RFC6830]) are used, the LISP data-plane shows the=20= same level of security as other IP-over-IP technologies. =46rom a security perspective, the control-plane remains the=20= critical part of the LISP architecture. To mitigate the threats on the mapping system, authentication=20= should be used for all control plane messages. The current specification ([RFC6833], [I-D.ietf-lisp-sec]) = defines security=20 mechanisms which can reduce threats in open network = environments.=20 The LISP specification defines a generic authentication data = field=20 for control plane messages [RFC6830] which could be used for = a general authentication mechanisms for the LISP control-plane while = staying backward compatible.=20 > Along those lines, if you want to refer to draft-ietf-lisp-threats for > security considerations, it needs to be a normative reference. >=20 >=20 Absolutely. We will move the document as normative reference. thanks Luigi From nobody Thu Oct 22 02:21:25 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AF31A0169 for ; Thu, 22 Oct 2015 02:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMpREV0q4huQ for ; Thu, 22 Oct 2015 02:21:22 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B341A017D for ; Thu, 22 Oct 2015 02:21:20 -0700 (PDT) Received: by wicll6 with SMTP id ll6so126237499wic.0 for ; Thu, 22 Oct 2015 02:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ry8eaZ4qSaJwsRtOG9AR03Hhd7jvBVMecbMHSLN/Z3o=; b=wSR4fd4tiIO2fOjZZ/5KrkhpbVCo9eyOg+K1o3tHHhqK9DvJJfNOOrQYHKkvIduwxe 9oDjcvlWuHp+fg8Dje8bL5PNR41AQliUMtCvmfVmOBYD0dB3xvA4iQpBlW5gaBGoAdxp 3orBjryrYuRx2+QyFMSChyHi0Eron1l+fAvT5ha/MzBH968ORgsXRoTaGmvlO/cpsoMJ oN/0L2E7D2/nJnLR7k+Ys5eS0kuzdfRp7mat+WwQChZ1ZrwAqDMMIDQ/56OYj0pSax23 4sllcfT6093HEs2lEEviMgzEoENUiRhAIwa+8kj+PEXTo8wl3ZetLwuqap/WejfMyARQ dQAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ry8eaZ4qSaJwsRtOG9AR03Hhd7jvBVMecbMHSLN/Z3o=; b=SYlqoyHkTqaN7vFw48qp3iuhT/A0Q9MlDfTfg2YxF4SFLeMlfBmAoeyzJv8ZyBDzUK BIsDIJstBPECt/L5iIUBTB06e9fF+Jf54gyoC7ZAeL09zY+Nlv/Rn0A97edCfALRS2pF Bd2yTUwkByC+dVZSo4pzjJNpbKtUj0KqIHV6gTzN0GlQfSTleLgJEmEY8J3+E822ABW5 dEY5kyc/lXZRe5YRLxiM5bF6V/O59PQrYIHEqNX0BcYqJkOJ7VoXtvvLK49WC/njJpCw 2UW9li2Qn1SF+RSzfORw0wr2h9Tya4DC2Abn9RnUfi8w6ZVqvaZwtHg0QsyikcNXZZ+5 EoYQ== X-Gm-Message-State: ALoCoQluNuyTh2Sa2DRCjuQg1rzyh11EMecnhZ62a5cFJhaBsT/pAoj4kf3fL1LiofP5tW5Si4QH X-Received: by 10.180.93.2 with SMTP id cq2mr15464852wib.33.1445505679436; Thu, 22 Oct 2015 02:21:19 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:69d0:ed82:4a4d:120e? ([2001:660:330f:a4:69d0:ed82:4a4d:120e]) by smtp.gmail.com with ESMTPSA id w1sm15622350wjz.37.2015.10.22.02.21.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 02:21:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: <20151021164242.13296.32356.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 11:21:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151021164242.13296.32356.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 09:21:23 -0000 Hi Spencer, > On 21 Oct 2015, at 18:42, Spencer Dawkins = wrote: >=20 [snip] >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > "RLOC" is spelled out on second use, but not on first use. >=20 Thanks for pointing this out. We have to fix this and a few other = acronyms that we use first and define later. > "Addresses are semantically separated in two:" was a bit rough for me. > Perhaps something like "Addresses have two components with different > semantic meanings:=E2=80=9D? I fear it could be misinterpreted. Is not the address that has two = =E2=80=9Ccomponents=E2=80=9D, is the addressing space that is split in = two semantically different sub spaces. What is we out the following text: =E2=80=9CAddresses are separated in two sets that have different = semantics meanings=E2=80=9D Would that work? >=20 > In this text: >=20 > Middle boxes/filters: because of encapsulation, the middle boxes = may > not understand the traffic, which can cause a firewall to drop > legitimate packets. In addition, LISP allows triangular or > even rectangular routing, so it is difficult to maintain a > correct state even if the middle box understands LISP. > Finally, filtering may also have problems because they may > think only one host is generating the traffic (the ITR), as > long as it is not de-encapsulated. To deal with LISP > encapsulation, LISP aware firewalls that inspect inner LISP > packets are proposed [lispfirewall]. >=20 > I wonder if we're far enough along with RFC 7258/BCP 188 that we = expect > middleboxes may not understand traffic, whether it's encapsulated or = not, > because of encryption. Perhaps that's worth a thought, if not a = mention. >=20 May be modifying the first sentence as follows: Middle boxes/filters: because of encapsulation or encryption, the = middle boxes may not understand the traffic, which can cause them to drop legitimate packets ([RFC7258]). Would that work? thanks ciao Luigi From nobody Thu Oct 22 02:32:14 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D187D1B3499 for ; Thu, 22 Oct 2015 02:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKGO3P3xW7Sn for ; Thu, 22 Oct 2015 02:32:10 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF051B341B for ; Thu, 22 Oct 2015 02:32:05 -0700 (PDT) Received: by wikq8 with SMTP id q8so22606155wik.1 for ; Thu, 22 Oct 2015 02:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PrSWT+K9L2nCFg9UZUqTTuVhbsbEKQ4jgmA1q7RR/Y4=; b=R7JsiCgqDUXxaF6ixa/8I0pUPeOgGWIBH38FTup1yErf+nO0skmERElUNjnQ/55w7S nIILfWWZthoBvl3qu4h/CenYD/3rgiMkUS6ziJXP7bjQn0HrBzfv2URB2/fdtt2d+Tnw Ao7TX9jAXpw6Zt1L/cJ77e8e247IZwP6iqQBhU45Aqpn08JYu7jVkOgf3XDB0dc3+BDz M2TR31490D6abZ66zZgEvBrIAC8p1j8PCunHv23EPfjehBHhXbjm+Y2TPfJB4R/Q4Y0T LQaiBBgCdfXrNxgAWhH4tB/KjNe2vYLssYhI+fRuAJzbq9eFMYRkSGNlndHib35oXmuV DPrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=PrSWT+K9L2nCFg9UZUqTTuVhbsbEKQ4jgmA1q7RR/Y4=; b=LNygCVOxb95noQrMCMthZPcQs9u5HSQZ7xR9OmfzL47E/nCPmvBeVvwOPKyQIYX/tB 54LFcimPlUDN4iLFKPtp0xjSDsFv6zz1rp5JjAs79VhmygszjM1G+8qLS4ggEsq3pUjq 09ZsTxz/QaUIVWzZ/0bLMOtc+pm2WrvREgJpIQdkJitbgk6JKbkqVZh4pKQVMniQAzFi /1onbve6CEBiFPYkfFAkvf6xlts0D8AOIaEOxHT/GG/lboMSmjzlP+je7PDL/CzelLVz 8IhwmA5GpqHTxy95/7MxNEpQbK1jug60qftEk0IVEfm1cJeuQrBAvHDvD/aICiAejayS luTg== X-Gm-Message-State: ALoCoQntNYwueM8Tq8G5tUkHf0ZRXRlmt5+2iAwirgEs7Tk70YYi8f0Wg54pZsLtGIBziwEIRBuX X-Received: by 10.180.187.237 with SMTP id fv13mr17351064wic.81.1445506323933; Thu, 22 Oct 2015 02:32:03 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:69d0:ed82:4a4d:120e? ([2001:660:330f:a4:69d0:ed82:4a4d:120e]) by smtp.gmail.com with ESMTPSA id q1sm15673400wjy.31.2015.10.22.02.32.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 02:32:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: <20151021165230.18223.65896.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 11:32:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151021165230.18223.65896.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Kathleen Moriarty's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 09:32:12 -0000 Hi Kathleen, > On 21 Oct 2015, at 18:52, Kathleen Moriarty = wrote: >=20 >=20 [snip] >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Hello, >=20 > There was no follow up or changes (it seems) as a result of the SecDir > review. It would be helpful to address the questions on the aim of = this > draft and how it applies to security for the user and impact of LISP. > https://www.ietf.org/mail-archive/web/secdir/current/msg06103.html >=20 >=20 There was actually a follow up (see below) or ami I missing something? Let me know. ciao L. %=E2=80=94=E2=80=94 Last reply to Hilarie on 20th = October=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% Hi Hilarie, Thanks again for your reply. please find our comments inline. ciao Luigi > On 19 Oct 2015, at 21:02, Hilarie Orman wrote: >=20 > [NB: this is in re draft-ietf-lisp-impact-04] >=20 > A few comments and suggestions: >=20 > Unless gleaning features (actually deprecated in > RFC 6830 [RFC6830]) are used,=20 >=20 > I don't see that gleaning is deprecated. In any event, how does = gleaning > undermine security? This is actually discussed in sections 6 and 12 of RFC6830 and analysed = in Section 3.1 of draft-ietf-lisp-threats. >=20 > the LISP data-plane shows the=20 > same level of security as other IP-over-IP technologies. > =46rom a security perspective, the control-plane remains the=20 > critical part of the LISP architecture. >=20 > To maximally mitigate the threats on the mapping >=20 > I doubt authentication is "maximal" mitigation. It just mitigates. Agreed. The sentence will be simplified as just =E2=80=9CTo mitigate the = threats=E2=80=A6." >=20 > system, authentication must be used, whenever possible, for all=20 >=20 > When would it be impossible to use authentication? >=20 The idea was to hint at deployments in ressource constrained = environments. It might in fact be misleading. The whole sentence can be reworded as = follows: To mitigate the threats on the mapping system, authentication=20 should be used for all control plane messages. > control plane messages. >=20 > Current specification already offer security mechanisms=20 > ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce threats=20= > in non-trustable environments such as the Internet. =20 >=20 > "The currenet specification defines security mechanisms which can > reduce threats in open network environments=E2=80=9D Just to keep the references, the sentence can be: The current specification ([RFC6833], [I-D.ietf-lisp-sec]) = defines security=20 mechanisms which can reduce threats in open network = environments.=20 > ? >=20 > Actually, LISP specifications define a generic authentication data = field=20 > control plane messages [RFC6830] allowing to propose a general > authentication mechanisms for the LISP control-plane while staying > backward compatible.=20 >=20 > "The LISP specification defines a generic authentication data field=20 > for control plane messages [RFC6830] which could be used for a = general > authentication mechanisms for the LISP control-plane while staying > backward compatible. " ?? >=20 Reads much better, thanks. Luigi > Hilarie >=20 >> Subject: Re: review of draft-saucez-lisp-impact-04.txt >> From: Luigi Iannone >> Date: Sat, 17 Oct 2015 21:49:24 +0200 >> Cc: Damien Saucez , >> draft-saucez-lisp-impact@tools.ietf.org, secdir@ietf.org, >> The IESG >=20 >> Hi Hilarie, >=20 >> In the current format the security section just states that actually=20= >> security is out of the scope of the document. >> This was actually an outcome of the WG discussion, were it was >> decided to clearly separate security and impact. >=20 >=20 >> Yet, it is true that the security section is poor, while=20 >> security analysis is out of the scope of the document, it does not=20 >> mean that we cannot mention the major security points=20 >> thoroughly analysed in the threats document. >=20 >=20 >> Hence we propose to modify the security section as follows: >=20 >> Old Version: >=20 >> Security and threats analysis of the LISP protocol is out of = the >> scope of the present document. A thorough analysis of LISP = security >> threats is detailed in [I-D.ietf-lisp-threats]. >=20 >=20 >> NEW Version: >=20 >> A thorough security and threats analysis of the LISP protocol >> is carried out in details in [I-D.ietf-lisp-threats].=20 >> Like for other Internet technologies, also for LISP most of=20= >> threats can be mitigated using Best Current Practice, meaning=20= >> with careful deployment an configuration (e.g., filter) and = also=20 >> by activating only features that are really necessary in the=20= >> deployment and verifying all the information obtained from = third=20 >> parties. Unless gleaning features (actually deprecated in >> RFC 6830 [RFC6830]) are used, the LISP data-plane shows the=20= >> same level of security as other IP-over-IP technologies. >> =46rom a security perspective, the control-plane remains the=20= >> critical part of the LISP architecture. >> To maximally mitigate the threats on the mapping >> system, authentication must be used, whenever possible, for = all=20 >> control plane messages. >> Current specification already offer security mechanisms=20 >> ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce = threats=20 >> in non-trustable environments such as the Internet. =20 >> Actually, LISP specifications define a generic authentication = data field=20 >> control plane messages [RFC6830] allowing to propose a = general >> authentication mechanisms for the LISP control-plane while = staying >> backward compatible.=20 >=20 >=20 >> We hope this delivers the information you were looking for. >=20 >> ciao >=20 >> Luigi >=20 >=20 >>> On 13 Oct 2015, at 19:28, Hilarie Orman wrote: >>>=20 >>> Thanks for pointing out my mistake. I have now reviewed >>> draft-ietf-lisp-impact-04 and the same comments about security = apply. >>>=20 >>> Hilarie >>>=20 >>>> From: Damien Saucez >>>> Date: Tue, 13 Oct 2015 08:13:08 +0200 >>>=20 >>>=20 >>>> Thank you for the review. I would have a question regarding the = document you reviewed. Did you review th >>>=20 >>>> draft-sauces-lisp-impact-04 >>>=20 >>>> or=20 >>>=20 >>>> draft-ietf-lisp-impact-04 >>>=20 >>>> Thank you, >>>=20 >>>> Damien Saucez=20 >>>=20 >>>> On 13 Oct 2015, at 05:01, Hilarie Orman wrote: >>>=20 >>>>> Secdir review of LISP Impact >>>>> draft-saucez-lisp-impact-04.txt >>>>>=20 >>>>> Do not be alarmed. I have reviewed this document as part of the >>>>> security directorate's ongoing effort to review all IETF documents >>>>> being processed by the IESG. These comments were written = primarily >>>>> for the benefit of the security area directors. Document editors = and >>>>> WG chairs should treat these comments just like any other last = call >>>>> comments. >>>>>=20 >>>>> A new way of handling routing information has been defined in IETF >>>>> documents about the Locator/Identifier Separation Protocol (LISP). >>>>> The draft under discussion here elaborates on the possible >>>>> consequences of widespread use of LISP. >>>>>=20 >>>>> The draft punts on security considerations and refers to previous >>>>> documents describing threats to LISP and how LISP uses = cryptography >>>>> for protecting the integrity of its messages. >>>>>=20 >>>>> It seems to me that if the purported impact of LISP is to "scale = the >>>>> Internet", then its impact on security should be a major part of = the >>>>> equation. Will it make routing information more or less = vulnerable >>>>> malicious manipulation? How will it affect the stability of a = network >>>>> that is under constant threat of attack? >>>>>=20 >>>>> I don't feel that the draft can achieve its purpose without = addressing >>>>> security. >>>>>=20 >>>>> Hilarie >>>>>=20 >>>>> PS. I was very disappointed to realize that this was not a draft >>>>> about my favorite programming language. From nobody Thu Oct 22 02:58:34 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8CF1B3601 for ; Thu, 22 Oct 2015 02:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7booMG2ew6E6 for ; Thu, 22 Oct 2015 02:58:29 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B591B3604 for ; Thu, 22 Oct 2015 02:58:26 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so127855625wic.1 for ; Thu, 22 Oct 2015 02:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ayhIbgPovXCiW0fqVzzL0NhdHyJL44RK+uqpcRPk9Y8=; b=XMlR1ykR/ojX0Hd63jXT5zdhvmPzhx3Cdmwxf3Ddy/DAVybk0wZDhBeMUIbZ9L2H/K CVIZ6FQq6mU0u45+ATIybG669TN18m/mFpqQFfRT3DwMtVXhMUNuAXIguoB0DkDZxIL8 J/+1+8JQF8yMjK4uHcZSRVV3xT0g14Vyky9QfIUhXsMT/8sDf38qWzUN+DRQBliC3DX4 RkRFvxzW5vkE/k7H3wxdN3iGO7DYxn1Z5GvAZHHGDcubhwCRW4DODyam6lGOnp0S9y6N srFLm9XL346WSMeH5bSHUxUkk6pBZuWUTsydYdgzqyYYCesdVHAMBWz++69PXlstREo7 ezgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ayhIbgPovXCiW0fqVzzL0NhdHyJL44RK+uqpcRPk9Y8=; b=ehM0O0gq0ZL6RCFdzQ48mk0X37pRFbw8lDtyCoMHfnL/TL5Uu77rLNU0xdxOZ4wRqY d/VfhHggby3vtCESdg/XlxC2n7Krl0CCxiWWmJAKU8t85h+jS+Bvf+TuwJdGd8QscqWA amJbyjhUlbnLZN1DQMg9dmLQgG8dsiRR1i+Eio8FIKIIPD/AZHOI9VhL2xqDCcbZkpof h0PoOZ76ko0DqMwgS/Rio48ULtkzZGuzt7PQt/n85yFCePOFRhjsf3y1vWpOoIZw4eka KbOMYhcz6nqsBhhmt/XXOpwdmI9wtl30Vr4sJMyWJ2g6elnMKqNPMAftA5HNys3q005m uo+w== X-Gm-Message-State: ALoCoQmDxO4HP8PjiHIqmwuLlk/tCAmbitVOH05AzLdFkbB8wNS8N/uhdusj5s59qqoxpF3sfO/d X-Received: by 10.194.144.10 with SMTP id si10mr15553859wjb.49.1445507904929; Thu, 22 Oct 2015 02:58:24 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:69d0:ed82:4a4d:120e? ([2001:660:330f:a4:69d0:ed82:4a4d:120e]) by smtp.gmail.com with ESMTPSA id gd10sm15823784wjb.47.2015.10.22.02.58.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 02:58:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: <20151021204139.7539.98645.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 11:58:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151021204139.7539.98645.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Alia Atlas' Abstain on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 09:58:30 -0000 Hi Alia, thanks for your comments, see inline for our replies. ciao Luigi > On 21 Oct 2015, at 22:41, Alia Atlas wrote: >=20 [snip] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The opening of this draft=20 > "The Locator/Identifier Separation Protocol (LISP) relies on three > principles to improve the scalability properties of Internet = routing: > address role separation, encapsulation, and mapping. The main goal > of LISP is to make the routing infrastructure more scalable by > reducing the number of prefixes announced in the Default Free Zone > (DFZ)." > is targeted at solving the Internet scalability issue for Internet > routing. > While the document goes into some details about rather large unknowns > and issues observed, it does not have any indications or caveats up > front that this is still experimental work - certainly as far as = solving > this > Internet-scale problem. >=20 > At a minimum, I think there need to be clear caveats on the = experimental > nature, on the aspects still to be understood, and on the complexity = and > concerns around the operational and security aspects. >=20 > While LISP is a really neat idea and it's good to see how far work and > research on it has progressed, this document reads much more like > marketing than something discussing the engineering and operational > trade-offs. >=20 We did our best to change the tone of the document,=20 trying to be as neutral as possible and just state observed facts. If something still slipped in please point us to the right spot and = we=E2=80=99ll fix it. > 1) There is no discussion of what the "mapping system" is and I think > that some of the discussion is assuming the use of BGP, but it's a bit > hard > to tell. At a minimum, it'd be good to clarify whether an > Internet-scale > deployment must use the same mapping system and what the trade-offs > there are. Fair enough. This is actually an open issue that has been just tackled = by M. Boucaidair in his recent drafts. I would propose to saccutally modify in Sec. 5.2 the = Business/Operational-related paragraph. That paragraph now ends with: =E2=80=9C=E2=80=A6. how will the EIDs be allocated to allow aggregation and hence scalability of the mapping system? Who will operate the mapping system infrastructure and for what benefits?=E2=80=9D We can append the questions: =E2=80=9CWhat is several operators run different mapping = systems? How will they interoperate or share mapping information?=E2=80=9D >=20 > 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the one > with > the highest priority and sends the encapsulated packet to this RLOC. > If several such RLOCs exist, then the traffic is balanced > proportionally to their weight among the RLOCs with the lowest > priority value." >=20 > It is unclear whether the "highest priority" means the lowest priority > value. > Please clarify because it incorrectly sounds like the highest priority > RLOC > is picked - unless there are multiple in which case load-balancing = among > the > lowest priority value RLOCs is done. Excellent catch, thanks. The sentence is indeed misleading.=20 The second sentence should be: =09 =E2=80=9CIf several RLOCs with the highest priority exist, then = the traffic=20 is balanced proportionally to their weight among such RLOCs." >=20 > 3) Sec 5.1 "Proxies cause what is referred to as path stretch and make > troubleshooting harder." This doesn't actually describe what path > stretch > is in any way. I can guess from the name, but that's not sufficient. Sentence can be modified as follows, so to provide a definition of path = stretch: "Proxies cause what is referred to as path stretch (i.e., a = lengthening=20 of the path compared to the topological shortest-path) and make=20= troubleshooting harder." >=20 > 4) In Sec 5.2: "Deployment in the beta network has shown that LISP+ALT > ([RFC6836], [CCR13]) was not easy to maintain and control, > which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt]" > Can you give a reference or indicate what the benefits of DDT are as > compared to ALT in this context? That is the content of [CCR13], but I agree that with the current=20 formulation is not clear that the reader can find such information in = it. The text can be modified as follows: "Deployment in the beta network has shown that LISP+ALT ([RFC6836]) was not easy to maintain and control ([CCR13]), which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt], based on a massively distributed and hierarchical approach=20 ([CCR13]).=E2=80=9D =09 >=20 >=20 From nobody Thu Oct 22 04:07:05 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735291A1B0E; Thu, 22 Oct 2015 04:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug2P8eyeLFrI; Thu, 22 Oct 2015 04:06:58 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8571A1B1F; Thu, 22 Oct 2015 04:06:58 -0700 (PDT) Received: by qkbl190 with SMTP id l190so51619308qkb.2; Thu, 22 Oct 2015 04:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4lERrG+KMIdUPv8mYVKQ7wiqNm8idyUCO7+3bBCBJZg=; b=ZOk3oc37dPnbRhqyLld90/9gY1747N4HH7/QopL6Z5o3s/Fxj7/w8We3kmzhx9cXV9 jdUKwiH5ugxT/HEsP5ddIZMm60f9c/t6LvaeWTWLLdhD/wBa2K7kzER51wwa+x4y7ZgX VT3iRFG5vU4I5kXF14ZTuGuoBve2/sYaCTxKmv/LZJRJYwrvSIGiqA1DWDQk0l/45aMo Jdi5DoFKkf3PH7zibl7AgtDcBECenFPCkRkPB9vEVkxWtvHo/N/keMbRRQXDbcgdZnXG 4IZyNGVXvTEHQf4QnAuPS9Ol5MZhmxWjZId8Tqj18GzOAnQZlFtQvQOpBQVjrSK6C6Uq nNIA== X-Received: by 10.55.195.135 with SMTP id r7mr18225783qkl.4.1445512017449; Thu, 22 Oct 2015 04:06:57 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id h198sm5083285qhc.47.2015.10.22.04.06.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 04:06:56 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Thu, 22 Oct 2015 07:06:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <56C57AAF-DBD9-42D8-987E-2435871DC5C6@gmail.com> References: <20151021165230.18223.65896.idtracker@ietfa.amsl.com> To: Luigi Iannone Archived-At: Cc: "lisp-chairs@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-impact.all@ietf.org" , The IESG , "draft-ietf-lisp-impact@ietf.org" Subject: Re: [lisp] Kathleen Moriarty's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 11:07:01 -0000 Hi Luigi, Thank you! It must not have gone to the SecDir list. I had noticed at leas= t one of the changes. Best regards, Kathleen=20 Sent from my iPhone > On Oct 22, 2015, at 5:32 AM, Luigi Iannone wrote: >=20 > Hi Kathleen, >=20 >> On 21 Oct 2015, at 18:52, Kathleen Moriarty wrote: >=20 > [snip] >=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> Hello, >>=20 >> There was no follow up or changes (it seems) as a result of the SecDir >> review. It would be helpful to address the questions on the aim of this >> draft and how it applies to security for the user and impact of LISP. >> https://www.ietf.org/mail-archive/web/secdir/current/msg06103.html >=20 > There was actually a follow up (see below) or ami I missing something? >=20 > Let me know. >=20 > ciao >=20 > L. >=20 >=20 > %=E2=80=94=E2=80=94 Last reply to Hilarie on 20th October=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% > Hi Hilarie, >=20 > Thanks again for your reply. > please find our comments inline. >=20 > ciao >=20 > Luigi >=20 >=20 >> On 19 Oct 2015, at 21:02, Hilarie Orman wrote: >>=20 >> [NB: this is in re draft-ietf-lisp-impact-04] >>=20 >> A few comments and suggestions: >>=20 >> Unless gleaning features (actually deprecated in >> RFC 6830 [RFC6830]) are used,=20 >>=20 >> I don't see that gleaning is deprecated. In any event, how does gleaning= >> undermine security? >=20 > This is actually discussed in sections 6 and 12 of RFC6830 and analysed in= Section 3.1 of draft-ietf-lisp-threats. >=20 >>=20 >> the LISP data-plane shows the=20 >> same level of security as other IP-over-IP technologies. >> =46rom a security perspective, the control-plane remains the=20 >> critical part of the LISP architecture. >>=20 >> To maximally mitigate the threats on the mapping >>=20 >> I doubt authentication is "maximal" mitigation. It just mitigates. >=20 > Agreed. The sentence will be simplified as just =E2=80=9CTo mitigate the t= hreats=E2=80=A6." >=20 >>=20 >> system, authentication must be used, whenever possible, for all=20 >>=20 >> When would it be impossible to use authentication? >=20 > The idea was to hint at deployments in ressource constrained environments.= > It might in fact be misleading. The whole sentence can be reworded as foll= ows: >=20 > To mitigate the threats on the mapping system, authentication=20 > should be used for all control plane messages. >=20 >=20 >> control plane messages. >>=20 >> Current specification already offer security mechanisms=20 >> ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce threats=20 >> in non-trustable environments such as the Internet. =20 >>=20 >> "The currenet specification defines security mechanisms which can >> reduce threats in open network environments=E2=80=9D >=20 > Just to keep the references, the sentence can be: >=20 > The current specification ([RFC6833], [I-D.ietf-lisp-sec]) defines sec= urity=20 > mechanisms which can reduce threats in open network environments.=20 >=20 >=20 >> ? >=20 >> Actually, LISP specifications define a generic authentication data fiel= d=20 >> control plane messages [RFC6830] allowing to propose a general >> authentication mechanisms for the LISP control-plane while staying >> backward compatible.=20 >>=20 >> "The LISP specification defines a generic authentication data field=20 >> for control plane messages [RFC6830] which could be used for a general >> authentication mechanisms for the LISP control-plane while staying >> backward compatible. " ?? >=20 > Reads much better, thanks. >=20 > Luigi >=20 >> Hilarie >>=20 >>> Subject: Re: review of draft-saucez-lisp-impact-04.txt >>> From: Luigi Iannone >>> Date: Sat, 17 Oct 2015 21:49:24 +0200 >>> Cc: Damien Saucez , >>> draft-saucez-lisp-impact@tools.ietf.org, secdir@ietf.org, >>> The IESG >>=20 >>> Hi Hilarie, >>=20 >>> In the current format the security section just states that actually=20 >>> security is out of the scope of the document. >>> This was actually an outcome of the WG discussion, were it was >>> decided to clearly separate security and impact. >>=20 >>=20 >>> Yet, it is true that the security section is poor, while=20 >>> security analysis is out of the scope of the document, it does not=20 >>> mean that we cannot mention the major security points=20 >>> thoroughly analysed in the threats document. >>=20 >>=20 >>> Hence we propose to modify the security section as follows: >>=20 >>> Old Version: >>=20 >>> Security and threats analysis of the LISP protocol is out of the >>> scope of the present document. A thorough analysis of LISP securi= ty >>> threats is detailed in [I-D.ietf-lisp-threats]. >>=20 >>=20 >>> NEW Version: >>=20 >>> A thorough security and threats analysis of the LISP protocol >>> is carried out in details in [I-D.ietf-lisp-threats].=20 >>> Like for other Internet technologies, also for LISP most of=20 >>> threats can be mitigated using Best Current Practice, meaning=20 >>> with careful deployment an configuration (e.g., filter) and also=20= >>> by activating only features that are really necessary in the=20 >>> deployment and verifying all the information obtained from third=20 >>> parties. Unless gleaning features (actually deprecated in >>> RFC 6830 [RFC6830]) are used, the LISP data-plane shows the=20 >>> same level of security as other IP-over-IP technologies. >>> =46rom a security perspective, the control-plane remains the=20 >>> critical part of the LISP architecture. >>> To maximally mitigate the threats on the mapping >>> system, authentication must be used, whenever possible, for all=20= >>> control plane messages. >>> Current specification already offer security mechanisms=20 >>> ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce threats=20= >>> in non-trustable environments such as the Internet. =20 >>> Actually, LISP specifications define a generic authentication data= field=20 >>> control plane messages [RFC6830] allowing to propose a general >>> authentication mechanisms for the LISP control-plane while staying= >>> backward compatible. >>=20 >>=20 >>> We hope this delivers the information you were looking for. >>=20 >>> ciao >>=20 >>> Luigi >>=20 >>=20 >>>> On 13 Oct 2015, at 19:28, Hilarie Orman wrote: >>>>=20 >>>> Thanks for pointing out my mistake. I have now reviewed >>>> draft-ietf-lisp-impact-04 and the same comments about security apply. >>>>=20 >>>> Hilarie >>>>=20 >>>>> From: Damien Saucez >>>>> Date: Tue, 13 Oct 2015 08:13:08 +0200 >>>>=20 >>>>=20 >>>>> Thank you for the review. I would have a question regarding the docume= nt you reviewed. Did you review th >>>>=20 >>>>> draft-sauces-lisp-impact-04 >>>>=20 >>>>> or >>>>=20 >>>>> draft-ietf-lisp-impact-04 >>>>=20 >>>>> Thank you, >>>>=20 >>>>> Damien Saucez >>>>=20 >>>>> On 13 Oct 2015, at 05:01, Hilarie Orman wrote: >>>>=20 >>>>>> Secdir review of LISP Impact >>>>>> draft-saucez-lisp-impact-04.txt >>>>>>=20 >>>>>> Do not be alarmed. I have reviewed this document as part of the >>>>>> security directorate's ongoing effort to review all IETF documents >>>>>> being processed by the IESG. These comments were written primarily >>>>>> for the benefit of the security area directors. Document editors and= >>>>>> WG chairs should treat these comments just like any other last call >>>>>> comments. >>>>>>=20 >>>>>> A new way of handling routing information has been defined in IETF >>>>>> documents about the Locator/Identifier Separation Protocol (LISP). >>>>>> The draft under discussion here elaborates on the possible >>>>>> consequences of widespread use of LISP. >>>>>>=20 >>>>>> The draft punts on security considerations and refers to previous >>>>>> documents describing threats to LISP and how LISP uses cryptography >>>>>> for protecting the integrity of its messages. >>>>>>=20 >>>>>> It seems to me that if the purported impact of LISP is to "scale the >>>>>> Internet", then its impact on security should be a major part of the >>>>>> equation. Will it make routing information more or less vulnerable >>>>>> malicious manipulation? How will it affect the stability of a networ= k >>>>>> that is under constant threat of attack? >>>>>>=20 >>>>>> I don't feel that the draft can achieve its purpose without addressin= g >>>>>> security. >>>>>>=20 >>>>>> Hilarie >>>>>>=20 >>>>>> PS. I was very disappointed to realize that this was not a draft >>>>>> about my favorite programming language. >=20 >=20 From nobody Thu Oct 22 05:11:31 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BB01A9100; Thu, 22 Oct 2015 05:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B4HBZb1sFvk; Thu, 22 Oct 2015 05:11:28 -0700 (PDT) Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com [IPv6:2607:f8b0:400c:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72581B2CB6; Thu, 22 Oct 2015 05:11:28 -0700 (PDT) Received: by vkfw189 with SMTP id w189so3979346vkf.3; Thu, 22 Oct 2015 05:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kOuM2xJ3kxp39BC/LVMnGoDM7noiBw+MvcGD/7SImQk=; b=EvbjOXkVuuJ5YSA9+aV5lPWu9+CFzYnh4R8buDOT3q6f7tg1BbZbIHi0CsSPCo1EbL rsnvXjagPV4c6tv3tpgJvvWy6j8LxG1kz2VS1SQmBdMFrUxemDQ400uu2rz2dsqHlIxE vIZN2sHgRytxpq6z7NYE205ePS1yZuQX/HcpkzGR4BODXJwi9EwpZRUR+t8EfNkrgW8X TC5EwAVyAgNmaQHJaXqdjjYdVfoyndYWv51UJD2NCdWQ3y9fsom7gVGoSp2gTA7oH8D7 gHx7AIuWw2xwIXFqfqBIePom8dpkRlcsDKwlWk93RGDbM/we1+cqSqNpzi7cSS3OpBgC R5yQ== MIME-Version: 1.0 X-Received: by 10.31.8.21 with SMTP id 21mr8974113vki.82.1445515887866; Thu, 22 Oct 2015 05:11:27 -0700 (PDT) Received: by 10.31.54.8 with HTTP; Thu, 22 Oct 2015 05:11:27 -0700 (PDT) In-Reply-To: References: <20151021164242.13296.32356.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 07:11:27 -0500 Message-ID: From: Spencer Dawkins at IETF To: Luigi Iannone Content-Type: multipart/alternative; boundary=001a114413a2037ce20522b06544 Archived-At: Cc: lisp-chairs@ietf.org, "lisp@ietf.org" , draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 12:11:30 -0000 --001a114413a2037ce20522b06544 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Luigi, On Thu, Oct 22, 2015 at 4:21 AM, Luigi Iannone wrote: > Hi Spencer, > > > > On 21 Oct 2015, at 18:42, Spencer Dawkins > wrote: > > > > [snip] > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > "RLOC" is spelled out on second use, but not on first use. > > > > Thanks for pointing this out. We have to fix this and a few other acronym= s > that we use first and define later. > > > > "Addresses are semantically separated in two:" was a bit rough for me. > > Perhaps something like "Addresses have two components with different > > semantic meanings:=E2=80=9D? > > I fear it could be misinterpreted. Is not the address that has two > =E2=80=9Ccomponents=E2=80=9D, is the addressing space that is split in tw= o semantically > different sub spaces. > > What is we out the following text: > > =E2=80=9CAddresses are separated in two sets that have different = semantics > meanings=E2=80=9D > > Would that work? > Ah, I see - you weren't making the point I thought you were making. Your explanation was actually better than your proposed text, because it said "address SPACE", not just addresses. Perhaps "The address space is divided into two sets that have different semantic meanings"? > > > > > In this text: > > > > Middle boxes/filters: because of encapsulation, the middle boxes may > > not understand the traffic, which can cause a firewall to drop > > legitimate packets. In addition, LISP allows triangular or > > even rectangular routing, so it is difficult to maintain a > > correct state even if the middle box understands LISP. > > Finally, filtering may also have problems because they may > > think only one host is generating the traffic (the ITR), as > > long as it is not de-encapsulated. To deal with LISP > > encapsulation, LISP aware firewalls that inspect inner LISP > > packets are proposed [lispfirewall]. > > > > I wonder if we're far enough along with RFC 7258/BCP 188 that we expect > > middleboxes may not understand traffic, whether it's encapsulated or no= t, > > because of encryption. Perhaps that's worth a thought, if not a mention= . > > > > May be modifying the first sentence as follows: > > Middle boxes/filters: because of encapsulation or encryption, the middl= e > boxes may > not understand the traffic, which can cause them to drop > legitimate packets ([RFC7258]). > > Would that work? One of the nice security ADs may have a better read on this, but I'm thinking the point of citing RFC 7258 is that middleboxes being clueless will be increasingly common. Perhaps Middle boxes/filters: because of increasingly common encryption as a response to pervasive monitoring ([RFC7258]), middle boxes are increasingly likely to be unable to understand encapsulated traffic, which can cause them to drop legitimate packets. Does that make sense? Thanks, Spencer > thanks > > ciao > > Luigi > > --001a114413a2037ce20522b06544 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Luigi,

On Thu, Oct 22, 2015 at 4:21 AM, Luigi Iannone = <ggx@gigix.net>= ; wrote:
Hi Spencer,


> On 21 Oct 2015, at 18:42, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
>

[snip]
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> "RLOC" is spelled out on second use, but not on first use. >

Thanks for pointing this out. We have to fix this and a few other ac= ronyms that we use first and define later.


> "Addresses are semantically separated in two:" was a bit rou= gh for me.
> Perhaps something like "Addresses have two components with differ= ent
> semantic meanings:=E2=80=9D?

I fear it could be misinterpreted. Is not the address that has two = =E2=80=9Ccomponents=E2=80=9D, is the addressing space that is split in two = semantically different sub spaces.

What is we out the following text:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9CAddresses are separated in two sets th= at have different semantics meanings=E2=80=9D

Would that work?

Ah, I see - you weren&= #39;t making the point I thought you were making. Your explanation was actu= ally better than your proposed text, because it said "address SPACE&qu= ot;, not just addresses. Perhaps "The address space is divided into tw= o sets that have different semantic meanings"?
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">>

> In this text:
>
>=C2=A0 =C2=A0Middle boxes/filters:=C2=A0 because of encapsulation, the = middle boxes may
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not understand the traffic, which can= cause a firewall to drop
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0legitimate packets.=C2=A0 In addition= , LISP allows triangular or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0even rectangular routing, so it is di= fficult to maintain a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0correct state even if the middle box = understands LISP.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, filtering may also have prob= lems because they may
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0think only one host is generating the= traffic (the ITR), as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0long as it is not de-encapsulated.=C2= =A0 To deal with LISP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encapsulation, LISP aware firewalls t= hat inspect inner LISP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets are proposed [lispfirewall].<= br> >
> I wonder if we're far enough along with RFC 7258/BCP 188 that we e= xpect
> middleboxes may not understand traffic, whether it's encapsulated = or not,
> because of encryption. Perhaps that's worth a thought, if not a me= ntion.
>

May be modifying the first sentence as follows:

=C2=A0Middle boxes/filters:=C2=A0 because of encapsulation or encryption, t= he middle boxes may
=C2=A0 =C2=A0 =C2=A0 =C2=A0 not understand the traffic, which can cause the= m to drop
=C2=A0 =C2=A0 =C2=A0 =C2=A0 legitimate packets ([RFC7258]).

Would that work?

One of the nice security A= Ds may have a better read on this, but I'm thinking the point of citing= RFC 7258 is that middleboxes being clueless will be increasingly common. P= erhaps

=C2=A0Middle boxes/filters:=C2=A0 because o= f increasingly common encryption as a response to pervasive monitoring ([RF= C7258]), middle boxes are increasingly likely to be unable to understand en= capsulated traffic, which=C2=A0can cause them to drop=C2=A0legitimate packe= ts.

Does that make sense?

Thanks,

Spencer
=C2=A0
thanks

ciao

Luigi


--001a114413a2037ce20522b06544-- From nobody Thu Oct 22 05:18:25 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434FA1B3659 for ; Thu, 22 Oct 2015 05:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5W0XaD9BA67 for ; Thu, 22 Oct 2015 05:18:21 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450271A90CD for ; Thu, 22 Oct 2015 05:18:18 -0700 (PDT) Received: by wicll6 with SMTP id ll6so116254670wic.1 for ; Thu, 22 Oct 2015 05:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=E1eApblnV6HGD0E0RSQu/eBuaYFzYClHcwi2BYearO4=; b=esYb+Cv2i2fcjDIQHfZci8GrgP/+FojV7KyDI0gpzs5meivN3c9PCdDJYa9i0+zI4z ZTNLY2ZWamU0BjKGDrKOLEc6ovAyUL49+QeVvu777OYf/VzptYMeiVKJlUOZYqvq7pYp wRwGc3iryts2wNx9p7VITf2re0bDJa+KNKmUC5FXE2CjNJ70bpAeDDzW6fjgz5/nvy9t eALef3M3E58TdpR4ArDyQfSxk7QlbBRWm8f/se6S6bgAZCGUW5JJs2BeMhT0Qx6Rn270 UZFLK23r63e4LGcVgVgwZtD4rS7epW1YEZsWWf3BWZCo1ul5ExS9/y9TtUb4CU8CN+WN ofwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=E1eApblnV6HGD0E0RSQu/eBuaYFzYClHcwi2BYearO4=; b=BeMyKLkBQ3x0XjrVEBrCP62aBtSUBWjUXNFj7DYLGO9uJx+MQ4vM0rQNBu+VbLQquR YSsQtQ2wulXMZTlNahiILzoyH29hMbeX/6oHEJxZAr3I5LEVquy+FCnlY2JgUKm/q1hA CrwHDEgdoFyCvewoH5Nck2hLaeeNEi2NaazQ49DLxTziIqMqyZo4ZEu+RZp3QuBSkFtO uJOpIbfOkXrrQm3RWquANOr9SOI3qDDfqU0qCvQzQJwHxnKTyF7Is0852Ixjed+d7Tq4 CSttAR6Km2wOf90wqQ7ANN5aomolA6GZgKj38j5IDKhKJMNWVz7Wi+Ya5VC/TNHxYQc+ UEdA== X-Gm-Message-State: ALoCoQnK1tV4tF1s1cDbwDDRJ0BQJbA/eMcRHrkx3m1TO7l9wRKjNZ5nWHVxLmohZM8yEZ/fIFkv X-Received: by 10.194.120.131 with SMTP id lc3mr16203784wjb.99.1445516296825; Thu, 22 Oct 2015 05:18:16 -0700 (PDT) Received: from ?IPv6:2001:660:330f:38:2474:3be7:17eb:d933? ([2001:660:330f:38:2474:3be7:17eb:d933]) by smtp.gmail.com with ESMTPSA id ka10sm16538536wjc.30.2015.10.22.05.18.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 05:18:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C058C936-2367-47AD-B184-F768107F42F4" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: Date: Thu, 22 Oct 2015 14:18:15 +0200 Message-Id: <59D384BE-38C6-4241-B84A-32F402080FBC@gigix.net> References: <20151021164242.13296.32356.idtracker@ietfa.amsl.com> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp-chairs@ietf.org, "lisp@ietf.org" , draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 12:18:22 -0000 --Apple-Mail=_C058C936-2367-47AD-B184-F768107F42F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Spencer, > On 22 Oct 2015, at 14:11, Spencer Dawkins at IETF = wrote: >=20 [snip] > What is we out the following text: >=20 > =E2=80=9CAddresses are separated in two sets that have = different semantics meanings=E2=80=9D >=20 > Would that work? >=20 > Ah, I see - you weren't making the point I thought you were making. = Your explanation was actually better than your proposed text, because it = said "address SPACE", not just addresses. Perhaps "The address space is = divided into two sets that have different semantic meanings"? > =20 Looks pretty good to me. Thanks. > > >=20 [snip] > Middle boxes/filters: because of encapsulation or encryption, the = middle boxes may > not understand the traffic, which can cause them to drop > legitimate packets ([RFC7258]). >=20 > Would that work? >=20 > One of the nice security ADs may have a better read on this, but I'm = thinking the point of citing RFC 7258 is that middleboxes being clueless = will be increasingly common. Perhaps >=20 > Middle boxes/filters: because of increasingly common encryption as a = response to pervasive monitoring ([RFC7258]), middle boxes are = increasingly likely to be unable to understand encapsulated traffic, = which can cause them to drop legitimate packets. >=20 Looks awesome to me. I=E2=80=99ll this text. If any security ADs has further comments they are always welcome ciao L. --Apple-Mail=_C058C936-2367-47AD-B184-F768107F42F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Spencer,

On 22 Oct 2015, at 14:11, = Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:


[snip]

What is we out = the following text:

      =   =E2=80=9CAddresse= s are separated in two sets that have different semantics meanings=E2=80=9D=

Would that work?

Ah, I see - you weren't making the point I thought you were = making. Your explanation was actually better than your proposed text, = because it said "address SPACE", not just addresses. Perhaps "The = address space is divided into two sets that have different semantic = meanings"?
 

Looks pretty good to me. Thanks.


>

<= br class=3D"">
[snip]
 Middle = boxes/filters:  because of encapsulation or encryption, the middle = boxes may
        not understand the traffic, = which can cause them to drop
      =   legitimate = packets ([RFC7258]).

Would that = work?

One= of the nice security ADs may have a better read on this, but I'm = thinking the point of citing RFC 7258 is that middleboxes being clueless = will be increasingly common. Perhaps

 Middle boxes/filters:  = because of increasingly common encryption as a response to pervasive = monitoring ([RFC7258]), middle boxes are increasingly likely to be = unable to understand encapsulated traffic, which can cause them to = drop legitimate packets.


Looks awesome to me. I=E2=80=99ll this = text.
If any security ADs has further comments they are always = welcome

ciao

L.

= --Apple-Mail=_C058C936-2367-47AD-B184-F768107F42F4-- From nobody Thu Oct 22 05:46:53 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFB01B36B2; Thu, 22 Oct 2015 05:46:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151022124652.30711.11416.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 05:46:52 -0700 Archived-At: Cc: draft-ietf-lisp-impact.all@ietf.org, lisp-chairs@ietf.org, draft-ietf-lisp-impact@ietf.org, lisp@ietf.org Subject: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 12:46:52 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-lisp-impact-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 3: "proven by several studies" without references is bad - we don't want blatent assertion in RFCs so please add some references. That could be done via forward pointers to later in the document or just by adding the refs here as well and explaining them more later. Or else delete the sentence as being redundant. - section 3, para starting "Results indicate...": Which results? I can't tell from how it's writen. - section 4: ConteXtream needs a reference as does the tier-1 operator (even if that has to be "private communication"at least I'd know to go ask the authors if I care. - I think you could note that as a map-and-encap scheme LISP also offers the potential for encryption of traffic between xTRs and reference the relevant lisp-crypto draft. That could go where you add a mention of rfc 7258 if you do add that. (In response to I think Spencer's comment.) - As with Kathleen, I think the secdir review deserves a substantive response. Please give it one. From nobody Thu Oct 22 06:07:37 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E801A1B83; Thu, 22 Oct 2015 06:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20SSfNnHaAHk; Thu, 22 Oct 2015 06:07:31 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97031A6F6D; Thu, 22 Oct 2015 06:07:19 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so134824958wic.1; Thu, 22 Oct 2015 06:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=a/xf3b7Lr4R5N2vE8lY1SpfU0cfUe3z4Ea3a6T06kSI=; b=l4pRM9CW7krC8htotT+WhWZulrd0l0QhrrQY5gbuwBgggpvTfX5mcoX8PUZdOvL7rs 8dqNm+LTgwwNAhu6E76qojrO3PVJCD5rKFutnf31CEctjeGFep2CLk0PbAQEw0voOAVU Pw8ezBMC7zN8RKsy4ZHfavuSD0tyyMpupu1e7/cCjplQFHU9SfhdrjoqH9rqhKWKfeh+ GV3IVpkuGTrvo+ktAp/6lQBen7gTIE7q7q48UuoQp1+k1l3vKas8f4wcztuvPb1rfiQR 6m1oMBBJPK3oHkKnFTwj79kxt+DjMp4iZZwOJZqI3FiNAcDA5JqFUMSVH312uuL3pqAG krAw== MIME-Version: 1.0 X-Received: by 10.195.11.72 with SMTP id eg8mr19569074wjd.14.1445519238497; Thu, 22 Oct 2015 06:07:18 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Thu, 22 Oct 2015 06:07:18 -0700 (PDT) In-Reply-To: <56C57AAF-DBD9-42D8-987E-2435871DC5C6@gmail.com> References: <20151021165230.18223.65896.idtracker@ietfa.amsl.com> <56C57AAF-DBD9-42D8-987E-2435871DC5C6@gmail.com> Date: Thu, 22 Oct 2015 09:07:18 -0400 Message-ID: From: Kathleen Moriarty To: Luigi Iannone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "lisp-chairs@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-impact.all@ietf.org" , The IESG , "draft-ietf-lisp-impact@ietf.org" Subject: Re: [lisp] Kathleen Moriarty's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 13:07:33 -0000 Luigi, Just one more question. On Thu, Oct 22, 2015 at 7:06 AM, Kathleen Moriarty wrote: > Hi Luigi, > > Thank you! It must not have gone to the SecDir list. I had noticed at l= east one of the changes. > > Best regards, > Kathleen > > Sent from my iPhone > >> On Oct 22, 2015, at 5:32 AM, Luigi Iannone wrote: >> >> Hi Kathleen, >> >>> On 21 Oct 2015, at 18:52, Kathleen Moriarty wrote: >> >> [snip] >> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Hello, >>> >>> There was no follow up or changes (it seems) as a result of the SecDir >>> review. It would be helpful to address the questions on the aim of thi= s >>> draft and how it applies to security for the user and impact of LISP. >>> https://www.ietf.org/mail-archive/web/secdir/current/msg06103.html >> >> There was actually a follow up (see below) or ami I missing something? >> >> Let me know. >> >> ciao >> >> L. >> >> >> %=E2=80=94=E2=80=94 Last reply to Hilarie on 20th October=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >> Hi Hilarie, >> >> Thanks again for your reply. >> please find our comments inline. >> >> ciao >> >> Luigi >> >> >>> On 19 Oct 2015, at 21:02, Hilarie Orman wrote: >>> >>> [NB: this is in re draft-ietf-lisp-impact-04] >>> >>> A few comments and suggestions: >>> >>> Unless gleaning features (actually deprecated in >>> RFC 6830 [RFC6830]) are used, >>> >>> I don't see that gleaning is deprecated. In any event, how does gleani= ng >>> undermine security? >> >> This is actually discussed in sections 6 and 12 of RFC6830 and analysed = in Section 3.1 of draft-ietf-lisp-threats. Could you add an explicit reference so ti tis clear that this has been documented? It would also be good to see how the impact of LISP on security too as this is an impact draft. Thank you, Kathleen >> >>> >>> the LISP data-plane shows the >>> same level of security as other IP-over-IP technologies. >>> From a security perspective, the control-plane remains the >>> critical part of the LISP architecture. >>> >>> To maximally mitigate the threats on the mapping >>> >>> I doubt authentication is "maximal" mitigation. It just mitigates. >> >> Agreed. The sentence will be simplified as just =E2=80=9CTo mitigate the= threats=E2=80=A6." >> >>> >>> system, authentication must be used, whenever possible, for all >>> >>> When would it be impossible to use authentication? >> >> The idea was to hint at deployments in ressource constrained environment= s. >> It might in fact be misleading. The whole sentence can be reworded as fo= llows: >> >> To mitigate the threats on the mapping system, authentication >> should be used for all control plane messages. >> >> >>> control plane messages. >>> >>> Current specification already offer security mechanisms >>> ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce threats >>> in non-trustable environments such as the Internet. >>> >>> "The currenet specification defines security mechanisms which can >>> reduce threats in open network environments=E2=80=9D >> >> Just to keep the references, the sentence can be: >> >> The current specification ([RFC6833], [I-D.ietf-lisp-sec]) defines s= ecurity >> mechanisms which can reduce threats in open network environments. >> >> >>> ? >> >>> Actually, LISP specifications define a generic authentication data fi= eld >>> control plane messages [RFC6830] allowing to propose a general >>> authentication mechanisms for the LISP control-plane while staying >>> backward compatible. >>> >>> "The LISP specification defines a generic authentication data field >>> for control plane messages [RFC6830] which could be used for a genera= l >>> authentication mechanisms for the LISP control-plane while staying >>> backward compatible. " ?? >> >> Reads much better, thanks. >> >> Luigi >> >>> Hilarie >>> >>>> Subject: Re: review of draft-saucez-lisp-impact-04.txt >>>> From: Luigi Iannone >>>> Date: Sat, 17 Oct 2015 21:49:24 +0200 >>>> Cc: Damien Saucez , >>>> draft-saucez-lisp-impact@tools.ietf.org, secdir@ietf.org, >>>> The IESG >>> >>>> Hi Hilarie, >>> >>>> In the current format the security section just states that actually >>>> security is out of the scope of the document. >>>> This was actually an outcome of the WG discussion, were it was >>>> decided to clearly separate security and impact. >>> >>> >>>> Yet, it is true that the security section is poor, while >>>> security analysis is out of the scope of the document, it does not >>>> mean that we cannot mention the major security points >>>> thoroughly analysed in the threats document. >>> >>> >>>> Hence we propose to modify the security section as follows: >>> >>>> Old Version: >>> >>>> Security and threats analysis of the LISP protocol is out of the >>>> scope of the present document. A thorough analysis of LISP secu= rity >>>> threats is detailed in [I-D.ietf-lisp-threats]. >>> >>> >>>> NEW Version: >>> >>>> A thorough security and threats analysis of the LISP protocol >>>> is carried out in details in [I-D.ietf-lisp-threats]. >>>> Like for other Internet technologies, also for LISP most of >>>> threats can be mitigated using Best Current Practice, meaning >>>> with careful deployment an configuration (e.g., filter) and also >>>> by activating only features that are really necessary in the >>>> deployment and verifying all the information obtained from third >>>> parties. Unless gleaning features (actually deprecated in >>>> RFC 6830 [RFC6830]) are used, the LISP data-plane shows the >>>> same level of security as other IP-over-IP technologies. >>>> From a security perspective, the control-plane remains the >>>> critical part of the LISP architecture. >>>> To maximally mitigate the threats on the mapping >>>> system, authentication must be used, whenever possible, for all >>>> control plane messages. >>>> Current specification already offer security mechanisms >>>> ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce threat= s >>>> in non-trustable environments such as the Internet. >>>> Actually, LISP specifications define a generic authentication da= ta field >>>> control plane messages [RFC6830] allowing to propose a general >>>> authentication mechanisms for the LISP control-plane while stayi= ng >>>> backward compatible. >>> >>> >>>> We hope this delivers the information you were looking for. >>> >>>> ciao >>> >>>> Luigi >>> >>> >>>>> On 13 Oct 2015, at 19:28, Hilarie Orman wrote: >>>>> >>>>> Thanks for pointing out my mistake. I have now reviewed >>>>> draft-ietf-lisp-impact-04 and the same comments about security apply. >>>>> >>>>> Hilarie >>>>> >>>>>> From: Damien Saucez >>>>>> Date: Tue, 13 Oct 2015 08:13:08 +0200 >>>>> >>>>> >>>>>> Thank you for the review. I would have a question regarding the docu= ment you reviewed. Did you review th >>>>> >>>>>> draft-sauces-lisp-impact-04 >>>>> >>>>>> or >>>>> >>>>>> draft-ietf-lisp-impact-04 >>>>> >>>>>> Thank you, >>>>> >>>>>> Damien Saucez >>>>> >>>>>> On 13 Oct 2015, at 05:01, Hilarie Orman wrote: >>>>> >>>>>>> Secdir review of LISP Impact >>>>>>> draft-saucez-lisp-impact-04.txt >>>>>>> >>>>>>> Do not be alarmed. I have reviewed this document as part of the >>>>>>> security directorate's ongoing effort to review all IETF documents >>>>>>> being processed by the IESG. These comments were written primarily >>>>>>> for the benefit of the security area directors. Document editors a= nd >>>>>>> WG chairs should treat these comments just like any other last call >>>>>>> comments. >>>>>>> >>>>>>> A new way of handling routing information has been defined in IETF >>>>>>> documents about the Locator/Identifier Separation Protocol (LISP). >>>>>>> The draft under discussion here elaborates on the possible >>>>>>> consequences of widespread use of LISP. >>>>>>> >>>>>>> The draft punts on security considerations and refers to previous >>>>>>> documents describing threats to LISP and how LISP uses cryptography >>>>>>> for protecting the integrity of its messages. >>>>>>> >>>>>>> It seems to me that if the purported impact of LISP is to "scale th= e >>>>>>> Internet", then its impact on security should be a major part of th= e >>>>>>> equation. Will it make routing information more or less vulnerable >>>>>>> malicious manipulation? How will it affect the stability of a netw= ork >>>>>>> that is under constant threat of attack? >>>>>>> >>>>>>> I don't feel that the draft can achieve its purpose without address= ing >>>>>>> security. >>>>>>> >>>>>>> Hilarie >>>>>>> >>>>>>> PS. I was very disappointed to realize that this was not a draft >>>>>>> about my favorite programming language. >> >> --=20 Best regards, Kathleen From nobody Thu Oct 22 07:01:24 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DD01ACDFE for ; Thu, 22 Oct 2015 07:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVP2nfY_8Doq for ; Thu, 22 Oct 2015 07:01:20 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82761ACCFF for ; Thu, 22 Oct 2015 07:01:19 -0700 (PDT) Received: by wijp11 with SMTP id p11so33668998wij.0 for ; Thu, 22 Oct 2015 07:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1XhVFlSvYmAHYHu4QXlq8cumB4r/nMAX7TbU3g1eWDE=; b=ko0/da1YE38TwPImyKBM3xUGNM+pkq6kTLTek0DDvVdwRjeGJfD66WtD8sqrJW7LNh R6pQyRkk1y+TtyhYE0c1Hi6u8l0njS1NtTgywBuKm9xuTpovvOd9Hl7HKjgQU6L8SUEz V6Hh/jcfhJvD5MO13h7072Xn9kM6jsLZ8TDy3rTe2lAAMiW85WvMB0PQYQmt8igXsFam /u5EWe3JOPje/tmhUoDpTbW0RQVXTLTVbuGYlIj4xeWfnbYbBHRfoQCWcvb0yyxib7KJ ZQTKfq3ynkDH6d/fjQkjvsCUZ3FP3+UEn1xzc6VIINS1enHoVL4HTrQ8arSrRB1G/J0s 5mrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1XhVFlSvYmAHYHu4QXlq8cumB4r/nMAX7TbU3g1eWDE=; b=mCGSv0Whv+fDYDgFXtzAYKMd+3oRG1haB5g7wxZbbqbi8WiTL7wa2QuUrNTrb0NDXn KoFpHyvQz63klYWDCnTDcfTx0692QA0KWrwQy/U5vJt+l01Vp7WVmUOqYzF/oS8m/Foc Ad92tV2JwmndUDw8DT3cjvpxNctZ9xXgB6r1/SQt+yHUQTry/Mzuh1EtgrguTMLnMIeU Q7CndtTQ8qkARfN3AqueRM7yASKaXtLifwPQ5hf/J3iiwsq1oAkR2qn9wHIXuibkldYU u0oNz5EAGh9WrJJhwUOJDjI89/eHHOFZqXeLQFDaOhKcIiBPgGf70uqycvw74ms7NW4a d+Pw== X-Gm-Message-State: ALoCoQmeNeYd0THoojrNqVj/OiZysR3yAUU+Tufi7GPOH7y8R+YfMllNhMy1AA+EgZYLxLmbavms X-Received: by 10.194.178.196 with SMTP id da4mr20661543wjc.41.1445522478317; Thu, 22 Oct 2015 07:01:18 -0700 (PDT) Received: from ?IPv6:2001:660:330f:38:2474:3be7:17eb:d933? ([2001:660:330f:38:2474:3be7:17eb:d933]) by smtp.gmail.com with ESMTPSA id r6sm4775232wia.0.2015.10.22.07.01.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 07:01:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: Date: Thu, 22 Oct 2015 16:01:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <79A908E5-6DAE-47A5-AB86-7DAC84ECE5D9@gigix.net> References: <20151021165230.18223.65896.idtracker@ietfa.amsl.com> <56C57AAF-DBD9-42D8-987E-2435871DC5C6@gmail.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "lisp-chairs@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-impact.all@ietf.org" , The IESG , "draft-ietf-lisp-impact@ietf.org" Subject: Re: [lisp] Kathleen Moriarty's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:01:23 -0000 HI Kathleen, yes, a reference on gleaning and related issues can be added easily. ciao Luigi > On 22 Oct 2015, at 15:07, Kathleen Moriarty = wrote: >=20 > Luigi, >=20 > Just one more question. >=20 > On Thu, Oct 22, 2015 at 7:06 AM, Kathleen Moriarty > wrote: >> Hi Luigi, >>=20 >> Thank you! It must not have gone to the SecDir list. I had noticed = at least one of the changes. >>=20 >> Best regards, >> Kathleen >>=20 >> Sent from my iPhone >>=20 >>> On Oct 22, 2015, at 5:32 AM, Luigi Iannone wrote: >>>=20 >>> Hi Kathleen, >>>=20 >>>> On 21 Oct 2015, at 18:52, Kathleen Moriarty = wrote: >>>=20 >>> [snip] >>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Hello, >>>>=20 >>>> There was no follow up or changes (it seems) as a result of the = SecDir >>>> review. It would be helpful to address the questions on the aim of = this >>>> draft and how it applies to security for the user and impact of = LISP. >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06103.html >>>=20 >>> There was actually a follow up (see below) or ami I missing = something? >>>=20 >>> Let me know. >>>=20 >>> ciao >>>=20 >>> L. >>>=20 >>>=20 >>> %=E2=80=94=E2=80=94 Last reply to Hilarie on 20th = October=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >>> Hi Hilarie, >>>=20 >>> Thanks again for your reply. >>> please find our comments inline. >>>=20 >>> ciao >>>=20 >>> Luigi >>>=20 >>>=20 >>>> On 19 Oct 2015, at 21:02, Hilarie Orman wrote: >>>>=20 >>>> [NB: this is in re draft-ietf-lisp-impact-04] >>>>=20 >>>> A few comments and suggestions: >>>>=20 >>>> Unless gleaning features (actually deprecated in >>>> RFC 6830 [RFC6830]) are used, >>>>=20 >>>> I don't see that gleaning is deprecated. In any event, how does = gleaning >>>> undermine security? >>>=20 >>> This is actually discussed in sections 6 and 12 of RFC6830 and = analysed in Section 3.1 of draft-ietf-lisp-threats. >=20 > Could you add an explicit reference so ti tis clear that this has been > documented? >=20 > It would also be good to see how the impact of LISP on security too as > this is an impact draft. >=20 > Thank you, > Kathleen >=20 >>>=20 >>>>=20 >>>> the LISP data-plane shows the >>>> same level of security as other IP-over-IP technologies. >>>> =46rom a security perspective, the control-plane remains the >>>> critical part of the LISP architecture. >>>>=20 >>>> To maximally mitigate the threats on the mapping >>>>=20 >>>> I doubt authentication is "maximal" mitigation. It just mitigates. >>>=20 >>> Agreed. The sentence will be simplified as just =E2=80=9CTo mitigate = the threats=E2=80=A6." >>>=20 >>>>=20 >>>> system, authentication must be used, whenever possible, for all >>>>=20 >>>> When would it be impossible to use authentication? >>>=20 >>> The idea was to hint at deployments in ressource constrained = environments. >>> It might in fact be misleading. The whole sentence can be reworded = as follows: >>>=20 >>> To mitigate the threats on the mapping system, authentication >>> should be used for all control plane messages. >>>=20 >>>=20 >>>> control plane messages. >>>>=20 >>>> Current specification already offer security mechanisms >>>> ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce threats >>>> in non-trustable environments such as the Internet. >>>>=20 >>>> "The currenet specification defines security mechanisms which can >>>> reduce threats in open network environments=E2=80=9D >>>=20 >>> Just to keep the references, the sentence can be: >>>=20 >>> The current specification ([RFC6833], [I-D.ietf-lisp-sec]) = defines security >>> mechanisms which can reduce threats in open network environments. >>>=20 >>>=20 >>>> ? >>>=20 >>>> Actually, LISP specifications define a generic authentication data = field >>>> control plane messages [RFC6830] allowing to propose a general >>>> authentication mechanisms for the LISP control-plane while staying >>>> backward compatible. >>>>=20 >>>> "The LISP specification defines a generic authentication data field >>>> for control plane messages [RFC6830] which could be used for a = general >>>> authentication mechanisms for the LISP control-plane while staying >>>> backward compatible. " ?? >>>=20 >>> Reads much better, thanks. >>>=20 >>> Luigi >>>=20 >>>> Hilarie >>>>=20 >>>>> Subject: Re: review of draft-saucez-lisp-impact-04.txt >>>>> From: Luigi Iannone >>>>> Date: Sat, 17 Oct 2015 21:49:24 +0200 >>>>> Cc: Damien Saucez , >>>>> draft-saucez-lisp-impact@tools.ietf.org, secdir@ietf.org, >>>>> The IESG >>>>=20 >>>>> Hi Hilarie, >>>>=20 >>>>> In the current format the security section just states that = actually >>>>> security is out of the scope of the document. >>>>> This was actually an outcome of the WG discussion, were it was >>>>> decided to clearly separate security and impact. >>>>=20 >>>>=20 >>>>> Yet, it is true that the security section is poor, while >>>>> security analysis is out of the scope of the document, it does not >>>>> mean that we cannot mention the major security points >>>>> thoroughly analysed in the threats document. >>>>=20 >>>>=20 >>>>> Hence we propose to modify the security section as follows: >>>>=20 >>>>> Old Version: >>>>=20 >>>>> Security and threats analysis of the LISP protocol is out of = the >>>>> scope of the present document. A thorough analysis of LISP = security >>>>> threats is detailed in [I-D.ietf-lisp-threats]. >>>>=20 >>>>=20 >>>>> NEW Version: >>>>=20 >>>>> A thorough security and threats analysis of the LISP protocol >>>>> is carried out in details in [I-D.ietf-lisp-threats]. >>>>> Like for other Internet technologies, also for LISP most of >>>>> threats can be mitigated using Best Current Practice, meaning >>>>> with careful deployment an configuration (e.g., filter) and = also >>>>> by activating only features that are really necessary in the >>>>> deployment and verifying all the information obtained from = third >>>>> parties. Unless gleaning features (actually deprecated in >>>>> RFC 6830 [RFC6830]) are used, the LISP data-plane shows the >>>>> same level of security as other IP-over-IP technologies. >>>>> =46rom a security perspective, the control-plane remains the >>>>> critical part of the LISP architecture. >>>>> To maximally mitigate the threats on the mapping >>>>> system, authentication must be used, whenever possible, for = all >>>>> control plane messages. >>>>> Current specification already offer security mechanisms >>>>> ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce = threats >>>>> in non-trustable environments such as the Internet. >>>>> Actually, LISP specifications define a generic authentication = data field >>>>> control plane messages [RFC6830] allowing to propose a = general >>>>> authentication mechanisms for the LISP control-plane while = staying >>>>> backward compatible. >>>>=20 >>>>=20 >>>>> We hope this delivers the information you were looking for. >>>>=20 >>>>> ciao >>>>=20 >>>>> Luigi >>>>=20 >>>>=20 >>>>>> On 13 Oct 2015, at 19:28, Hilarie Orman wrote: >>>>>>=20 >>>>>> Thanks for pointing out my mistake. I have now reviewed >>>>>> draft-ietf-lisp-impact-04 and the same comments about security = apply. >>>>>>=20 >>>>>> Hilarie >>>>>>=20 >>>>>>> From: Damien Saucez >>>>>>> Date: Tue, 13 Oct 2015 08:13:08 +0200 >>>>>>=20 >>>>>>=20 >>>>>>> Thank you for the review. I would have a question regarding the = document you reviewed. Did you review th >>>>>>=20 >>>>>>> draft-sauces-lisp-impact-04 >>>>>>=20 >>>>>>> or >>>>>>=20 >>>>>>> draft-ietf-lisp-impact-04 >>>>>>=20 >>>>>>> Thank you, >>>>>>=20 >>>>>>> Damien Saucez >>>>>>=20 >>>>>>> On 13 Oct 2015, at 05:01, Hilarie Orman wrote: >>>>>>=20 >>>>>>>> Secdir review of LISP Impact >>>>>>>> draft-saucez-lisp-impact-04.txt >>>>>>>>=20 >>>>>>>> Do not be alarmed. I have reviewed this document as part of = the >>>>>>>> security directorate's ongoing effort to review all IETF = documents >>>>>>>> being processed by the IESG. These comments were written = primarily >>>>>>>> for the benefit of the security area directors. Document = editors and >>>>>>>> WG chairs should treat these comments just like any other last = call >>>>>>>> comments. >>>>>>>>=20 >>>>>>>> A new way of handling routing information has been defined in = IETF >>>>>>>> documents about the Locator/Identifier Separation Protocol = (LISP). >>>>>>>> The draft under discussion here elaborates on the possible >>>>>>>> consequences of widespread use of LISP. >>>>>>>>=20 >>>>>>>> The draft punts on security considerations and refers to = previous >>>>>>>> documents describing threats to LISP and how LISP uses = cryptography >>>>>>>> for protecting the integrity of its messages. >>>>>>>>=20 >>>>>>>> It seems to me that if the purported impact of LISP is to = "scale the >>>>>>>> Internet", then its impact on security should be a major part = of the >>>>>>>> equation. Will it make routing information more or less = vulnerable >>>>>>>> malicious manipulation? How will it affect the stability of a = network >>>>>>>> that is under constant threat of attack? >>>>>>>>=20 >>>>>>>> I don't feel that the draft can achieve its purpose without = addressing >>>>>>>> security. >>>>>>>>=20 >>>>>>>> Hilarie >>>>>>>>=20 >>>>>>>> PS. I was very disappointed to realize that this was not a = draft >>>>>>>> about my favorite programming language. >>>=20 >>>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Thu Oct 22 07:08:54 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A8C1ACE4F for ; Thu, 22 Oct 2015 07:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzFl4zQZXENX for ; Thu, 22 Oct 2015 07:08:50 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827621A70FE for ; Thu, 22 Oct 2015 07:08:50 -0700 (PDT) Received: by wicll6 with SMTP id ll6so120988922wic.1 for ; Thu, 22 Oct 2015 07:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qiOShO3ZGpkT2j4kVgg+KQC4cIMAGo6e2usSR7XIb9U=; b=tAZODitoYSZtRJ1WX5rv5bQm53u3yne+kLkCBNa/6iRkSfVgcu8IuAAJsRs54shr6t JkMkUJChAN1zM8Ltqz6f5X81p/FHUvfZGuOhvPjZiV3CCDubSCGaw8cfr4TCCfAeQ+m8 FHcPlze5Zr/5lw4ndf5ZCXALmj+RlDgUsyZ67I9MgYzgRMKteQy+JJeZm5S7Q+SOxQAo 3U1IrirsqIcb9ba+1zzSX/HEwwEatKjYIsWLNDhzDMEP/TPV1uh8FvT3MZwvq1gUK1vx GzSYJzIX9dZp9wFNr803HHwMT7tNhwvjcx9pgtvL6kALW5fI745vmnviY0u+aeQnP6QM ns9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=qiOShO3ZGpkT2j4kVgg+KQC4cIMAGo6e2usSR7XIb9U=; b=hAi55xGiXj9IR2ChleqIFJX86B7hEffVzU/GWyqny+4XzJHz4Ft7wnttbQK+51pSmR Hy0n4Fi39PBFuoqnks6066CzUvBZbXraGIteEgkQGApfLvnxAGJ4E6aFObacPaYGKqrD Am2nwZKah/Y23uqruAhPWsE5TmUSzd7CFVE7Pt7VYDyvt67ZbuMGpLY3z2ES6vv04BqW iCRO9LDzpvsB0Av76uDCGvO/ZG5w7k5otpB2Wa07RrGQ830XgSNTFmqUfOjRNTNfQ6dL 842+gl65Wzxn6VLKp6V1kHesmIZcQJw/tpipLoW19ZMvo5Ow47cJtdm4nAMjcXzeluq0 +F9Q== X-Gm-Message-State: ALoCoQnqGQMxAkK3EdZ3WhKV31XkGEBWTsvBQKEeQHMp1VdHA36NgIkFc64E6dRvj1wmpIlsMNzo X-Received: by 10.180.211.116 with SMTP id nb20mr18340737wic.50.1445522929019; Thu, 22 Oct 2015 07:08:49 -0700 (PDT) Received: from ?IPv6:2001:660:330f:38:2474:3be7:17eb:d933? ([2001:660:330f:38:2474:3be7:17eb:d933]) by smtp.gmail.com with ESMTPSA id b1sm3438753wjx.12.2015.10.22.07.08.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 07:08:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: <20151022124652.30711.11416.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 16:08:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151022124652.30711.11416.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:08:52 -0000 Hi Stephen, > On 22 Oct 2015, at 14:46, Stephen Farrell = wrote: >=20 [snip] >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 3: "proven by several studies" without references is > bad - we don't want blatent assertion in RFCs so please add > some references. That could be done via forward pointers to > later in the document or just by adding the refs here as well > and explaining them more later. Or else delete the sentence as > being redundant. >=20 You are right. References are already in the document but in the = sentence you are citing we need to either cite them again of put a = forward reference. I am more prone to the second solution, a forward reference. Should be = simpler. > - section 3, para starting "Results indicate...": Which > results? I can't tell from how it's written. There is missing reference there. [CDLC] is the one that needs to be = added. Thanks. >=20 > - section 4: ConteXtream needs a reference as does the tier-1 > operator (even if that has to be "private communication"at > least I'd know to go ask the authors if I care. >=20 I will check with ConteXtream about adding the references you are = asking. > - I think you could note that as a map-and-encap scheme LISP > also offers the potential for encryption of traffic between > xTRs and reference the relevant lisp-crypto draft. That could > go where you add a mention of rfc 7258 if you do add that. > (In response to I think Spencer's comment.) >=20 Excellent idea. I will added a reference to that document and adjust the text = accordingly. > - As with Kathleen, I think the secdir review deserves a > substantive response. Please give it one. >=20 I really confused here! We did provide substantial answer.=20 More specifically for the secdir=E2=80=A6 all my emails are awaiting = moderator decision because I am not a member. >=20 From nobody Thu Oct 22 07:12:51 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328951A8711; Thu, 22 Oct 2015 07:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuCgi1C689yQ; Thu, 22 Oct 2015 07:12:47 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AD11A90B6; Thu, 22 Oct 2015 07:12:46 -0700 (PDT) Received: by wijp11 with SMTP id p11so34222359wij.0; Thu, 22 Oct 2015 07:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IrfX4zTucZR74Hzgqkn5rm3BQqb97uh1Ho2qsODyzRs=; b=A1DSmJhwTOkRZbnISJARts1rtEeRjkM/HLkSM5UNQgzX30klcRWvnI8QDfFbQUo5+e s38gMx+jHlJAq6T5GULCLJi+uPGDPhNPiztb6++ALfQWS+Gb0g/zL6DnkGmhjEnpmB+/ GD4E+azsiRMetdITNtH7/5szHxEsHo5tuIEXcPgr+nq3J4SWsIjVOUvNNEcWsLnmpfj2 a9kgONF5k8eVEkDkgPTGxeoeuJo+bVCx9ZQY82ZDv7V6uX+PhKb1RU8MmKAi42z0wlUT SR/gs0aJ7yUk9IAQLPPziqJWnlMIEPq1UeZfbOWYQiIOf1+61NRjFQvs1WycrHxOmTew xu5w== MIME-Version: 1.0 X-Received: by 10.195.11.72 with SMTP id eg8mr20015159wjd.14.1445523162588; Thu, 22 Oct 2015 07:12:42 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Thu, 22 Oct 2015 07:12:42 -0700 (PDT) In-Reply-To: <79A908E5-6DAE-47A5-AB86-7DAC84ECE5D9@gigix.net> References: <20151021165230.18223.65896.idtracker@ietfa.amsl.com> <56C57AAF-DBD9-42D8-987E-2435871DC5C6@gmail.com> <79A908E5-6DAE-47A5-AB86-7DAC84ECE5D9@gigix.net> Date: Thu, 22 Oct 2015 10:12:42 -0400 Message-ID: From: Kathleen Moriarty To: Luigi Iannone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "lisp-chairs@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-impact.all@ietf.org" , The IESG , "draft-ietf-lisp-impact@ietf.org" Subject: Re: [lisp] Kathleen Moriarty's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:12:50 -0000 Thank you! On Thu, Oct 22, 2015 at 10:01 AM, Luigi Iannone wrote: > HI Kathleen, > > yes, a reference on gleaning and related issues can be added easily. > > ciao > > Luigi > > >> On 22 Oct 2015, at 15:07, Kathleen Moriarty wrote: >> >> Luigi, >> >> Just one more question. >> >> On Thu, Oct 22, 2015 at 7:06 AM, Kathleen Moriarty >> wrote: >>> Hi Luigi, >>> >>> Thank you! It must not have gone to the SecDir list. I had noticed at= least one of the changes. >>> >>> Best regards, >>> Kathleen >>> >>> Sent from my iPhone >>> >>>> On Oct 22, 2015, at 5:32 AM, Luigi Iannone wrote: >>>> >>>> Hi Kathleen, >>>> >>>>> On 21 Oct 2015, at 18:52, Kathleen Moriarty wrote: >>>> >>>> [snip] >>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------= - >>>>> COMMENT: >>>>> ---------------------------------------------------------------------= - >>>>> >>>>> Hello, >>>>> >>>>> There was no follow up or changes (it seems) as a result of the SecDi= r >>>>> review. It would be helpful to address the questions on the aim of t= his >>>>> draft and how it applies to security for the user and impact of LISP. >>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06103.html >>>> >>>> There was actually a follow up (see below) or ami I missing something= ? >>>> >>>> Let me know. >>>> >>>> ciao >>>> >>>> L. >>>> >>>> >>>> %=E2=80=94=E2=80=94 Last reply to Hilarie on 20th October=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94% >>>> Hi Hilarie, >>>> >>>> Thanks again for your reply. >>>> please find our comments inline. >>>> >>>> ciao >>>> >>>> Luigi >>>> >>>> >>>>> On 19 Oct 2015, at 21:02, Hilarie Orman wrote: >>>>> >>>>> [NB: this is in re draft-ietf-lisp-impact-04] >>>>> >>>>> A few comments and suggestions: >>>>> >>>>> Unless gleaning features (actually deprecated in >>>>> RFC 6830 [RFC6830]) are used, >>>>> >>>>> I don't see that gleaning is deprecated. In any event, how does glea= ning >>>>> undermine security? >>>> >>>> This is actually discussed in sections 6 and 12 of RFC6830 and analyse= d in Section 3.1 of draft-ietf-lisp-threats. >> >> Could you add an explicit reference so ti tis clear that this has been >> documented? >> >> It would also be good to see how the impact of LISP on security too as >> this is an impact draft. >> >> Thank you, >> Kathleen >> >>>> >>>>> >>>>> the LISP data-plane shows the >>>>> same level of security as other IP-over-IP technologies. >>>>> From a security perspective, the control-plane remains the >>>>> critical part of the LISP architecture. >>>>> >>>>> To maximally mitigate the threats on the mapping >>>>> >>>>> I doubt authentication is "maximal" mitigation. It just mitigates. >>>> >>>> Agreed. The sentence will be simplified as just =E2=80=9CTo mitigate t= he threats=E2=80=A6." >>>> >>>>> >>>>> system, authentication must be used, whenever possible, for all >>>>> >>>>> When would it be impossible to use authentication? >>>> >>>> The idea was to hint at deployments in ressource constrained environme= nts. >>>> It might in fact be misleading. The whole sentence can be reworded as = follows: >>>> >>>> To mitigate the threats on the mapping system, authentication >>>> should be used for all control plane messages. >>>> >>>> >>>>> control plane messages. >>>>> >>>>> Current specification already offer security mechanisms >>>>> ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce threats >>>>> in non-trustable environments such as the Internet. >>>>> >>>>> "The currenet specification defines security mechanisms which can >>>>> reduce threats in open network environments=E2=80=9D >>>> >>>> Just to keep the references, the sentence can be: >>>> >>>> The current specification ([RFC6833], [I-D.ietf-lisp-sec]) defines = security >>>> mechanisms which can reduce threats in open network environments. >>>> >>>> >>>>> ? >>>> >>>>> Actually, LISP specifications define a generic authentication data f= ield >>>>> control plane messages [RFC6830] allowing to propose a general >>>>> authentication mechanisms for the LISP control-plane while staying >>>>> backward compatible. >>>>> >>>>> "The LISP specification defines a generic authentication data field >>>>> for control plane messages [RFC6830] which could be used for a gener= al >>>>> authentication mechanisms for the LISP control-plane while staying >>>>> backward compatible. " ?? >>>> >>>> Reads much better, thanks. >>>> >>>> Luigi >>>> >>>>> Hilarie >>>>> >>>>>> Subject: Re: review of draft-saucez-lisp-impact-04.txt >>>>>> From: Luigi Iannone >>>>>> Date: Sat, 17 Oct 2015 21:49:24 +0200 >>>>>> Cc: Damien Saucez , >>>>>> draft-saucez-lisp-impact@tools.ietf.org, secdir@ietf.org, >>>>>> The IESG >>>>> >>>>>> Hi Hilarie, >>>>> >>>>>> In the current format the security section just states that actually >>>>>> security is out of the scope of the document. >>>>>> This was actually an outcome of the WG discussion, were it was >>>>>> decided to clearly separate security and impact. >>>>> >>>>> >>>>>> Yet, it is true that the security section is poor, while >>>>>> security analysis is out of the scope of the document, it does not >>>>>> mean that we cannot mention the major security points >>>>>> thoroughly analysed in the threats document. >>>>> >>>>> >>>>>> Hence we propose to modify the security section as follows: >>>>> >>>>>> Old Version: >>>>> >>>>>> Security and threats analysis of the LISP protocol is out of th= e >>>>>> scope of the present document. A thorough analysis of LISP sec= urity >>>>>> threats is detailed in [I-D.ietf-lisp-threats]. >>>>> >>>>> >>>>>> NEW Version: >>>>> >>>>>> A thorough security and threats analysis of the LISP protocol >>>>>> is carried out in details in [I-D.ietf-lisp-threats]. >>>>>> Like for other Internet technologies, also for LISP most of >>>>>> threats can be mitigated using Best Current Practice, meaning >>>>>> with careful deployment an configuration (e.g., filter) and als= o >>>>>> by activating only features that are really necessary in the >>>>>> deployment and verifying all the information obtained from third >>>>>> parties. Unless gleaning features (actually deprecated in >>>>>> RFC 6830 [RFC6830]) are used, the LISP data-plane shows the >>>>>> same level of security as other IP-over-IP technologies. >>>>>> From a security perspective, the control-plane remains the >>>>>> critical part of the LISP architecture. >>>>>> To maximally mitigate the threats on the mapping >>>>>> system, authentication must be used, whenever possible, for all >>>>>> control plane messages. >>>>>> Current specification already offer security mechanisms >>>>>> ([RFC6833], [I-D.ietf-lisp-sec]) able to strongly reduce threa= ts >>>>>> in non-trustable environments such as the Internet. >>>>>> Actually, LISP specifications define a generic authentication d= ata field >>>>>> control plane messages [RFC6830] allowing to propose a general >>>>>> authentication mechanisms for the LISP control-plane while stay= ing >>>>>> backward compatible. >>>>> >>>>> >>>>>> We hope this delivers the information you were looking for. >>>>> >>>>>> ciao >>>>> >>>>>> Luigi >>>>> >>>>> >>>>>>> On 13 Oct 2015, at 19:28, Hilarie Orman wrote: >>>>>>> >>>>>>> Thanks for pointing out my mistake. I have now reviewed >>>>>>> draft-ietf-lisp-impact-04 and the same comments about security appl= y. >>>>>>> >>>>>>> Hilarie >>>>>>> >>>>>>>> From: Damien Saucez >>>>>>>> Date: Tue, 13 Oct 2015 08:13:08 +0200 >>>>>>> >>>>>>> >>>>>>>> Thank you for the review. I would have a question regarding the do= cument you reviewed. Did you review th >>>>>>> >>>>>>>> draft-sauces-lisp-impact-04 >>>>>>> >>>>>>>> or >>>>>>> >>>>>>>> draft-ietf-lisp-impact-04 >>>>>>> >>>>>>>> Thank you, >>>>>>> >>>>>>>> Damien Saucez >>>>>>> >>>>>>>> On 13 Oct 2015, at 05:01, Hilarie Orman wrote: >>>>>>> >>>>>>>>> Secdir review of LISP Impact >>>>>>>>> draft-saucez-lisp-impact-04.txt >>>>>>>>> >>>>>>>>> Do not be alarmed. I have reviewed this document as part of the >>>>>>>>> security directorate's ongoing effort to review all IETF document= s >>>>>>>>> being processed by the IESG. These comments were written primari= ly >>>>>>>>> for the benefit of the security area directors. Document editors= and >>>>>>>>> WG chairs should treat these comments just like any other last ca= ll >>>>>>>>> comments. >>>>>>>>> >>>>>>>>> A new way of handling routing information has been defined in IET= F >>>>>>>>> documents about the Locator/Identifier Separation Protocol (LISP)= . >>>>>>>>> The draft under discussion here elaborates on the possible >>>>>>>>> consequences of widespread use of LISP. >>>>>>>>> >>>>>>>>> The draft punts on security considerations and refers to previous >>>>>>>>> documents describing threats to LISP and how LISP uses cryptograp= hy >>>>>>>>> for protecting the integrity of its messages. >>>>>>>>> >>>>>>>>> It seems to me that if the purported impact of LISP is to "scale = the >>>>>>>>> Internet", then its impact on security should be a major part of = the >>>>>>>>> equation. Will it make routing information more or less vulnerab= le >>>>>>>>> malicious manipulation? How will it affect the stability of a ne= twork >>>>>>>>> that is under constant threat of attack? >>>>>>>>> >>>>>>>>> I don't feel that the draft can achieve its purpose without addre= ssing >>>>>>>>> security. >>>>>>>>> >>>>>>>>> Hilarie >>>>>>>>> >>>>>>>>> PS. I was very disappointed to realize that this was not a draft >>>>>>>>> about my favorite programming language. >>>> >>>> >> >> >> >> -- >> >> Best regards, >> Kathleen > --=20 Best regards, Kathleen From nobody Thu Oct 22 07:16:24 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6E21A21B8; Thu, 22 Oct 2015 07:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9xdzMa0XKPD; Thu, 22 Oct 2015 07:16:17 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134B41ACEDE; Thu, 22 Oct 2015 07:16:17 -0700 (PDT) Received: by obbda8 with SMTP id da8so68009394obb.1; Thu, 22 Oct 2015 07:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ozePPmtRtRK0mmEYPMvjLwVONTlzO0iUq3oRuwSP1Yw=; b=k+LXJFsHcJqozekblZ+JVvLdz1kTH68+9J4BF7YPNEXEutbS8qXCrBQouXT1zwARf+ uLjHVvy1jj5jZ+GqC/VAUcs9XUp+nZHwwDhFtaYM10hAnhGwUYdNYfkZq7PSoMDgb8Ip fAnK50zek5Mg33k9hHrElwnui6CPIk7ZKexaLbNFPyjBUzA4p/5RQ0nDk+dKmaHmNg1R 9e7r1ez+QRaBVk0AfudQ0UVIhYtucGsijNUiuKWwZyWFex8brpTcGpXx5Lhd+ySJzc5p UGc+J3+P01c0xEHoPVB9HscLwRXMxyox8Ev4YW40e6FBNPgIE3tFU+5VZdCmZDHNuVNW TTTQ== MIME-Version: 1.0 X-Received: by 10.60.116.101 with SMTP id jv5mr11260272oeb.24.1445523376348; Thu, 22 Oct 2015 07:16:16 -0700 (PDT) Received: by 10.60.121.74 with HTTP; Thu, 22 Oct 2015 07:16:16 -0700 (PDT) In-Reply-To: References: <20151021204139.7539.98645.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 10:16:16 -0400 Message-ID: From: Alia Atlas To: Luigi Iannone Content-Type: multipart/alternative; boundary=089e0115f0525ca7950522b22399 Archived-At: Cc: lisp-chairs@ietf.org, lisp , draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Alia Atlas' Abstain on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:16:19 -0000 --089e0115f0525ca7950522b22399 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Luigi, Those fixes look good. For the tone of the draft, I think the primary thing that I was looking for was some context and indication in the introduction around the experiments and experimental nature. Given that the WG is willing to admit in the rechartering that trying to solve the general Internet routing scaling problem is not a continuing target for LISP, I'd be interested in some text describing a combination of "When invented, LISP was targeted at solving the Internet routing scaling problem. There have now been years of implementations and experiments examining the impact and open questions of using LISP to improve inter-domain routing scalability. This document describes, at a high level= , the impacts and open questions still seen. This information is particularl= y useful for considering future approaches and to support further experimentation to clarify some large open questions (e.g. around the operations)." Beyond that, there was one section which was a "without lisp, ..." versus a "with lisp" that struck me as incorrect and assuming that the only solution to the problem was lisp. Changing it to "currently" or "as commonly implemented" would help. Thanks for considering my comments. Regards, Alia On Thu, Oct 22, 2015 at 5:58 AM, Luigi Iannone wrote: > Hi Alia, > > thanks for your comments, see inline for our replies. > > ciao > > Luigi > > > > On 21 Oct 2015, at 22:41, Alia Atlas wrote: > > > > [snip] > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > The opening of this draft > > "The Locator/Identifier Separation Protocol (LISP) relies on three > > principles to improve the scalability properties of Internet routing: > > address role separation, encapsulation, and mapping. The main goal > > of LISP is to make the routing infrastructure more scalable by > > reducing the number of prefixes announced in the Default Free Zone > > (DFZ)." > > is targeted at solving the Internet scalability issue for Internet > > routing. > > While the document goes into some details about rather large unknowns > > and issues observed, it does not have any indications or caveats up > > front that this is still experimental work - certainly as far as solvin= g > > this > > Internet-scale problem. > > > > At a minimum, I think there need to be clear caveats on the experimenta= l > > nature, on the aspects still to be understood, and on the complexity an= d > > concerns around the operational and security aspects. > > > > While LISP is a really neat idea and it's good to see how far work and > > research on it has progressed, this document reads much more like > > marketing than something discussing the engineering and operational > > trade-offs. > > > > We did our best to change the tone of the document, > trying to be as neutral as possible and just state observed facts. > If something still slipped in please point us to the right spot and we=E2= =80=99ll > fix it. > > > 1) There is no discussion of what the "mapping system" is and I think > > that some of the discussion is assuming the use of BGP, but it's a bit > > hard > > to tell. At a minimum, it'd be good to clarify whether an > > Internet-scale > > deployment must use the same mapping system and what the trade-offs > > there are. > > Fair enough. This is actually an open issue that has been just tackled by > M. Boucaidair in his recent drafts. > > I would propose to saccutally modify in Sec. 5.2 the > Business/Operational-related paragraph. > > That paragraph now ends with: > > =E2=80=9C=E2=80=A6. how will the EIDs be > allocated to allow aggregation and hence scalability of the > mapping system? Who will operate the mapping system > infrastructure and for what benefits?=E2=80=9D > > We can append the questions: > > =E2=80=9CWhat is several operators run different mapping systems? > How will they interoperate or share mapping information?=E2=80=9D > > > > > > > 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the one > > with > > the highest priority and sends the encapsulated packet to this RLOC. > > If several such RLOCs exist, then the traffic is balanced > > proportionally to their weight among the RLOCs with the lowest > > priority value." > > > > It is unclear whether the "highest priority" means the lowest priority > > value. > > Please clarify because it incorrectly sounds like the highest priority > > RLOC > > is picked - unless there are multiple in which case load-balancing amon= g > > the > > lowest priority value RLOCs is done. > > Excellent catch, thanks. The sentence is indeed misleading. > The second sentence should be: > > =E2=80=9CIf several RLOCs with the highest priority exist, then t= he traffic > is balanced proportionally to their weight among such RLOCs." > > > > > 3) Sec 5.1 "Proxies cause what is referred to as path stretch and make > > troubleshooting harder." This doesn't actually describe what path > > stretch > > is in any way. I can guess from the name, but that's not sufficient. > > Sentence can be modified as follows, so to provide a definition of path > stretch: > > "Proxies cause what is referred to as path stretch (i.e., a > lengthening > of the path compared to the topological shortest-path) and make > troubleshooting harder." > > > > > > 4) In Sec 5.2: "Deployment in the beta network has shown that LISP+ALT > > ([RFC6836], [CCR13]) was not easy to maintain and control, > > which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt]" > > Can you give a reference or indicate what the benefits of DDT are as > > compared to ALT in this context? > > That is the content of [CCR13], but I agree that with the current > formulation is not clear that the reader can find such information in it. > The text can be modified as follows: > > "Deployment in the beta network has shown that LISP+ALT > ([RFC6836]) was not easy to maintain and control ([CCR13]), > which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt], > based on a massively distributed and hierarchical approach > ([CCR13]).=E2=80=9D > > > > > > > > --089e0115f0525ca7950522b22399 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Luigi,

Those fixes look good.
<= div>
For the tone of the draft, I think the primary thing tha= t I was looking for
was some context and indication in the introd= uction around the experiments
and experimental nature.
=
Given that the WG is willing to admit in the rechartering th= at trying to solve
the general Internet routing scaling problem i= s not a continuing target for
LISP, I'd be interested in some= text describing a combination of=C2=A0
"When invented, LISP= was targeted at solving the Internet routing scaling
problem.=C2= =A0 There have now been years of implementations and experiments
= examining the impact and open questions of using LISP to improve
= inter-domain routing scalability.=C2=A0 This document describes, at a high = level,
the impacts and open questions still seen.=C2=A0 This info= rmation is particularly
useful for considering future approaches = and to support further experimentation
to clarify some large open= questions (e.g. around the operations)."

Bey= ond that, there was one section which was a "without lisp, ..." v= ersus
a "with lisp" =C2=A0that struck me as incorre= ct and assuming that the only solution
to the problem was lisp.= =C2=A0 Changing it to "currently" or "as commonly implemente= d"
would help.

Thanks for consi= dering my comments.

Regards,
Alia
<= /div>

On Thu, Oct = 22, 2015 at 5:58 AM, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia,

thanks for your comments, see inline for our replies.

ciao

Luigi


> On 21 Oct 2015, at 22:41, Alia Atlas <akatlas@gmail.com> wrote:
>

[snip]
> -----------------------------------------------------= -----------------
> COMMENT:
> ----------------------------------------------------------------------=
>
> The opening of this draft
> "The Locator/Identifier Separation Protocol (LISP) relies on thre= e
>=C2=A0 =C2=A0principles to improve the scalability properties of Intern= et routing:
>=C2=A0 =C2=A0address role separation, encapsulation, and mapping.=C2=A0= The main goal
>=C2=A0 =C2=A0of LISP is to make the routing infrastructure more scalabl= e by
>=C2=A0 =C2=A0reducing the number of prefixes announced in the Default F= ree Zone
>=C2=A0 =C2=A0(DFZ)."
> is targeted at solving the Internet scalability issue for Internet
> routing.
> While the document goes into some details about rather large unknowns<= br> > and issues observed, it does not have any indications or caveats up > front that this is still experimental work - certainly as far as solvi= ng
> this
> Internet-scale problem.
>
> At a minimum, I think there need to be clear caveats on the experiment= al
> nature, on the aspects still to be understood, and on the complexity a= nd
> concerns around the operational and security aspects.
>
> While LISP is a really neat idea and it's good to see how far work= and
> research on it has progressed, this document reads much more like
> marketing than something discussing the engineering and operational > trade-offs.
>

We did our best to change the tone of the document,
trying to be as neutral as possible and just state observed facts.
If something still slipped in please point us to the right spot and we=E2= =80=99ll fix it.

> 1) There is no discussion of what the "mapping system" is an= d I think
> that some of the discussion is assuming the use of BGP, but it's a= bit
> hard
> to tell.=C2=A0 At a minimum, it'd be good to clarify whether an > Internet-scale
> deployment must use the same mapping system and what the trade-offs > there are.

Fair enough. This is actually an open issue that has been just tackl= ed by M. Boucaidair in his recent drafts.

I would propose to saccutally modify in Sec. 5.2 the Business/Operational-r= elated paragraph.

That paragraph now ends with:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9C=E2=80=A6.=C2=A0 =C2=A0 how will the E= IDs be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allocated to allow aggregation and hence = scalability of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mapping system?=C2=A0 Who will operate th= e mapping system
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0infrastructure and for what benefits?=E2= =80=9D

We can append the questions:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9CWhat is several operators run differen= t mapping systems?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 How will they interoperate or share mapping inf= ormation?=E2=80=9D



>
> 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the= one
> with
>=C2=A0 =C2=A0the highest priority and sends the encapsulated packet to = this RLOC.
>=C2=A0 =C2=A0If several such RLOCs exist, then the traffic is balanced<= br> >=C2=A0 =C2=A0proportionally to their weight among the RLOCs with the lo= west
>=C2=A0 =C2=A0priority value."
>
> It is unclear whether the "highest priority" means the lowes= t priority
> value.
> Please clarify because it incorrectly sounds like the highest priority=
> RLOC
> is picked - unless there are multiple in which case load-balancing amo= ng
> the
> lowest priority value RLOCs is done.

Excellent catch, thanks. The sentence is indeed misleading.
The second sentence should be:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9CIf several RLOCs with the highest prio= rity exist, then the traffic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is balanced proportionally to their weight amon= g such RLOCs."

>
> 3) Sec 5.1 "Proxies cause what is referred to as path stretch and= make
>=C2=A0 =C2=A0troubleshooting harder."=C2=A0 This doesn't actua= lly describe what path
> stretch
> is in any way.=C2=A0 I can guess from the name, but that's not suf= ficient.

Sentence can be modified as follows, so to provide a definition of p= ath stretch:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Proxies cause what is referred to as path= stretch (i.e., a lengthening
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the path compared to the topological shortes= t-path) and make
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0troubleshooting harder."


>
> 4) In Sec 5.2: "Deployment in the beta network has shown that LIS= P+ALT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0([RFC6836], [CCR13]) was not easy to = maintain and control,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which explains the migration to LISP-= DDT [I-D.ietf-lisp-ddt]"
> Can you give a reference or indicate what the benefits of DDT are as > compared to ALT in this context?

That is the content of [CCR13], but I agree that with the current formulation is not clear that the reader can find such information in it. The text can be modified as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Deployment in the beta network has shown = that LISP+ALT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ([RFC6836]) was not easy to maintain and= control ([CCR13]),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which explains the migration to LISP-DDT [I-D.i= etf-lisp-ddt],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 based on a massively distributed and hierarchic= al approach
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ([CCR13]).=E2=80=9D


>
>


--089e0115f0525ca7950522b22399-- From nobody Thu Oct 22 07:20:02 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D212F1ACD04 for ; Thu, 22 Oct 2015 07:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxt3Zu2qTxME for ; Thu, 22 Oct 2015 07:19:55 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4201ACF09 for ; Thu, 22 Oct 2015 07:19:54 -0700 (PDT) Received: by wicll6 with SMTP id ll6so137732220wic.0 for ; Thu, 22 Oct 2015 07:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ljBS3LTxK9aS3VmCMQdP14QFBSYS6BciFXytn6kiNV4=; b=YkNvTNFtePXhyh0KhwlqZBk6qzCNmgqGOjCJ1a9Buvk7pRS4hnvrISXg0wfsXvtlp7 MvkBRU3xwsDaHmKPh0Yx1VxWVFHM9q1Ue79HrrxOZLC9SOsuANDasUMW9fi1eBA9TCrx wlhXA8xzK0GJTLek1deH73Uv/vhozjb3/sEoemZQdlIbI8L1kuY42FzANDBgVUPsJptA 4chwbSWTnW96N2NG+V3jSFJOSq6+vLLtw0rdIIVMqyXbLAx5wtj2sIU6eIZzf1ZERkQu FrHjCv8nnA4zDrDgFZULJl0fOnLWlZuBjfZUSww4AkeNHbm8/dJmKhPeYO+Q1HZSNSIf OArw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ljBS3LTxK9aS3VmCMQdP14QFBSYS6BciFXytn6kiNV4=; b=LJmdIl/1tlwrOsOH4SCpbK/pT76+5qrwMq+lIzhjV3LPof6eh8LjI2/y9H2KcXxho0 hvpkAGDf41/Ef+tTouSbRTbJkTbkjFdob5YePhNlIsd9SurtfdI4aQyKSaqURaRiMGbA 92M5o1jKBYJaNa+BmrTSmyPw8gpO/neOT674g+hbedmhFRdKCr3ml8AWpMxXCzMIAZFb 3/mC3gUiWbBKDsdF+Oo2AOCCkWb8ArqetWQqlO7pEFbfTDs2EP7rvyRvlAI1WDwQTZpl MTnnhMyP4CzB7FeiOBG9r9zVsmqe/GtcH7f/eF9VdsnoZKbS1knX25K09+QWbSJ9/9lD MD/A== X-Gm-Message-State: ALoCoQl/40+KsfmTdIJB9JlOOHEYch7QDBo36evq8WaAXP8K2BsVYBEh05i5bKbe4U6ql6oZHPxn X-Received: by 10.180.90.37 with SMTP id bt5mr41176109wib.7.1445523593286; Thu, 22 Oct 2015 07:19:53 -0700 (PDT) Received: from dhcp164-197.enst.fr (dhcp164-197.enst.fr. [137.194.165.197]) by smtp.gmail.com with ESMTPSA id o3sm28236418wif.22.2015.10.22.07.19.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 07:19:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7A60D14E-9B20-47FB-AE2A-913F914A636A" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: Date: Thu, 22 Oct 2015 16:19:52 +0200 Message-Id: References: <20151021204139.7539.98645.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp-chairs@ietf.org, lisp , draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Alia Atlas' Abstain on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:19:58 -0000 --Apple-Mail=_7A60D14E-9B20-47FB-AE2A-913F914A636A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alia, > On 22 Oct 2015, at 16:16, Alia Atlas wrote: >=20 > Hi Luigi, >=20 > Those fixes look good. >=20 > For the tone of the draft, I think the primary thing that I was = looking for > was some context and indication in the introduction around the = experiments > and experimental nature. >=20 > Given that the WG is willing to admit in the rechartering that trying = to solve > the general Internet routing scaling problem is not a continuing = target for > LISP, I'd be interested in some text describing a combination of=20 > "When invented, LISP was targeted at solving the Internet routing = scaling > problem. There have now been years of implementations and experiments > examining the impact and open questions of using LISP to improve > inter-domain routing scalability. This document describes, at a high = level, > the impacts and open questions still seen. This information is = particularly > useful for considering future approaches and to support further = experimentation > to clarify some large open questions (e.g. around the operations)." >=20 This look great to me. This can be added to the document.=20 thanks > Beyond that, there was one section which was a "without lisp, ..." = versus > a "with lisp" that struck me as incorrect and assuming that the only = solution > to the problem was lisp. Changing it to "currently" or "as commonly = implemented" > would help. >=20 I see. I=E2=80=99ll check that as well and change the tone as you = suggested. Thanks ciao Luigi > Thanks for considering my comments. >=20 > Regards, > Alia >=20 > On Thu, Oct 22, 2015 at 5:58 AM, Luigi Iannone > wrote: > Hi Alia, >=20 > thanks for your comments, see inline for our replies. >=20 > ciao >=20 > Luigi >=20 >=20 > > On 21 Oct 2015, at 22:41, Alia Atlas > wrote: > > >=20 > [snip] > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > The opening of this draft > > "The Locator/Identifier Separation Protocol (LISP) relies on three > > principles to improve the scalability properties of Internet = routing: > > address role separation, encapsulation, and mapping. The main = goal > > of LISP is to make the routing infrastructure more scalable by > > reducing the number of prefixes announced in the Default Free Zone > > (DFZ)." > > is targeted at solving the Internet scalability issue for Internet > > routing. > > While the document goes into some details about rather large = unknowns > > and issues observed, it does not have any indications or caveats up > > front that this is still experimental work - certainly as far as = solving > > this > > Internet-scale problem. > > > > At a minimum, I think there need to be clear caveats on the = experimental > > nature, on the aspects still to be understood, and on the complexity = and > > concerns around the operational and security aspects. > > > > While LISP is a really neat idea and it's good to see how far work = and > > research on it has progressed, this document reads much more like > > marketing than something discussing the engineering and operational > > trade-offs. > > >=20 > We did our best to change the tone of the document, > trying to be as neutral as possible and just state observed facts. > If something still slipped in please point us to the right spot and = we=E2=80=99ll fix it. >=20 > > 1) There is no discussion of what the "mapping system" is and I = think > > that some of the discussion is assuming the use of BGP, but it's a = bit > > hard > > to tell. At a minimum, it'd be good to clarify whether an > > Internet-scale > > deployment must use the same mapping system and what the trade-offs > > there are. >=20 > Fair enough. This is actually an open issue that has been just tackled = by M. Boucaidair in his recent drafts. >=20 > I would propose to saccutally modify in Sec. 5.2 the = Business/Operational-related paragraph. >=20 > That paragraph now ends with: >=20 > =E2=80=9C=E2=80=A6. how will the EIDs be > allocated to allow aggregation and hence scalability of the > mapping system? Who will operate the mapping system > infrastructure and for what benefits?=E2=80=9D >=20 > We can append the questions: >=20 > =E2=80=9CWhat is several operators run different mapping = systems? > How will they interoperate or share mapping information?=E2=80=9D= >=20 >=20 >=20 > > > > 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the = one > > with > > the highest priority and sends the encapsulated packet to this = RLOC. > > If several such RLOCs exist, then the traffic is balanced > > proportionally to their weight among the RLOCs with the lowest > > priority value." > > > > It is unclear whether the "highest priority" means the lowest = priority > > value. > > Please clarify because it incorrectly sounds like the highest = priority > > RLOC > > is picked - unless there are multiple in which case load-balancing = among > > the > > lowest priority value RLOCs is done. >=20 > Excellent catch, thanks. The sentence is indeed misleading. > The second sentence should be: >=20 > =E2=80=9CIf several RLOCs with the highest priority exist, = then the traffic > is balanced proportionally to their weight among such RLOCs." >=20 > > > > 3) Sec 5.1 "Proxies cause what is referred to as path stretch and = make > > troubleshooting harder." This doesn't actually describe what path > > stretch > > is in any way. I can guess from the name, but that's not = sufficient. >=20 > Sentence can be modified as follows, so to provide a definition of = path stretch: >=20 > "Proxies cause what is referred to as path stretch (i.e., a = lengthening > of the path compared to the topological shortest-path) and = make > troubleshooting harder." >=20 >=20 > > > > 4) In Sec 5.2: "Deployment in the beta network has shown that = LISP+ALT > > ([RFC6836], [CCR13]) was not easy to maintain and control, > > which explains the migration to LISP-DDT = [I-D.ietf-lisp-ddt]" > > Can you give a reference or indicate what the benefits of DDT are as > > compared to ALT in this context? >=20 > That is the content of [CCR13], but I agree that with the current > formulation is not clear that the reader can find such information in = it. > The text can be modified as follows: >=20 > "Deployment in the beta network has shown that LISP+ALT > ([RFC6836]) was not easy to maintain and control ([CCR13]), > which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt], > based on a massively distributed and hierarchical approach > ([CCR13]).=E2=80=9D >=20 >=20 > > > > >=20 >=20 --Apple-Mail=_7A60D14E-9B20-47FB-AE2A-913F914A636A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alia,

On 22 Oct 2015, at 16:16, Alia = Atlas <akatlas@gmail.com> wrote:

Hi Luigi,

Those fixes look good.

For the tone of the draft, I think the = primary thing that I was looking for
was some = context and indication in the introduction around the = experiments
and experimental nature.

Given that the WG is = willing to admit in the rechartering that trying to solve
the general Internet routing scaling problem is not a = continuing target for
LISP, I'd be interested in = some text describing a combination of 
"When = invented, LISP was targeted at solving the Internet routing = scaling
problem.  There have now been years of = implementations and experiments
examining the = impact and open questions of using LISP to improve
inter-domain routing scalability.  This document = describes, at a high level,
the impacts and open = questions still seen.  This information is particularly
useful for considering future approaches and to support = further experimentation
to clarify some large open = questions (e.g. around the operations)."


This look great to me. This can be added to the = document. 

thanks


Beyond that, = there was one section which was a "without lisp, ..." versus
a "with lisp"  that struck me as = incorrect and assuming that the only solution
to = the problem was lisp.  Changing it to "currently" or "as commonly = implemented"
would help.


I see. I=E2=80=99ll check that as well and change = the tone as you suggested.

Thanks

ciao

Luigi

Thanks for considering my comments.

Regards,
Alia

On Thu, Oct 22, 2015 at 5:58 AM, Luigi Iannone = <ggx@gigix.net> wrote:
Hi Alia,

thanks for your comments, see inline for our replies.

ciao

Luigi


> On 21 Oct 2015, at 22:41, Alia Atlas <akatlas@gmail.com> = wrote:
>

[snip]
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> The opening of this draft
> "The Locator/Identifier Separation Protocol (LISP) relies on = three
>   principles to improve the scalability properties of = Internet routing:
>   address role separation, encapsulation, and = mapping.  The main goal
>   of LISP is to make the routing infrastructure more = scalable by
>   reducing the number of prefixes announced in the = Default Free Zone
>   (DFZ)."
> is targeted at solving the Internet scalability issue for = Internet
> routing.
> While the document goes into some details about rather large = unknowns
> and issues observed, it does not have any indications or caveats = up
> front that this is still experimental work - certainly as far as = solving
> this
> Internet-scale problem.
>
> At a minimum, I think there need to be clear caveats on the = experimental
> nature, on the aspects still to be understood, and on the = complexity and
> concerns around the operational and security aspects.
>
> While LISP is a really neat idea and it's good to see how far work = and
> research on it has progressed, this document reads much more = like
> marketing than something discussing the engineering and = operational
> trade-offs.
>

We did our best to change the tone of the document,
trying to be as neutral as possible and just state observed facts.
If something still slipped in please point us to the right spot and = we=E2=80=99ll fix it.

> 1) There is no discussion of what the "mapping system" is and I = think
> that some of the discussion is assuming the use of BGP, but it's a = bit
> hard
> to tell.  At a minimum, it'd be good to clarify whether an
> Internet-scale
> deployment must use the same mapping system and what the = trade-offs
> there are.

Fair enough. This is actually an open issue that has been just = tackled by M. Boucaidair in his recent drafts.

I would propose to saccutally modify in Sec. 5.2 the = Business/Operational-related paragraph.

That paragraph now ends with:

        =E2=80=9C=E2=80=A6.    how will = the EIDs be
         allocated to allow aggregation and = hence scalability of the
         mapping system?  Who will operate = the mapping system
         infrastructure and for what = benefits?=E2=80=9D

We can append the questions:

        =E2=80=9CWhat is several operators run = different mapping systems?
        How will they interoperate or share mapping = information?=E2=80=9D



>
> 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the = one
> with
>   the highest priority and sends the encapsulated packet = to this RLOC.
>   If several such RLOCs exist, then the traffic is = balanced
>   proportionally to their weight among the RLOCs with the = lowest
>   priority value."
>
> It is unclear whether the "highest priority" means the lowest = priority
> value.
> Please clarify because it incorrectly sounds like the highest = priority
> RLOC
> is picked - unless there are multiple in which case load-balancing = among
> the
> lowest priority value RLOCs is done.

Excellent catch, thanks. The sentence is indeed misleading.
The second sentence should be:

        =E2=80=9CIf several RLOCs with the highest = priority exist, then the traffic
        is balanced proportionally to their weight = among such RLOCs."

>
> 3) Sec 5.1 "Proxies cause what is referred to as path stretch and = make
>   troubleshooting harder."  This doesn't actually = describe what path
> stretch
> is in any way.  I can guess from the name, but that's not = sufficient.

Sentence can be modified as follows, so to provide a definition = of path stretch:

        "Proxies cause what is referred to as path = stretch (i.e., a lengthening
        of the path compared to the topological = shortest-path) and make
         troubleshooting harder."


>
> 4) In Sec 5.2: "Deployment in the beta network has shown that = LISP+ALT
>         ([RFC6836], [CCR13]) was not easy = to maintain and control,
>         which explains the migration to = LISP-DDT [I-D.ietf-lisp-ddt]"
> Can you give a reference or indicate what the benefits of DDT are = as
> compared to ALT in this context?

That is the content of [CCR13], but I agree that with the = current
formulation is not clear that the reader can find such information in = it.
The text can be modified as follows:

        "Deployment in the beta network has shown = that LISP+ALT
        ([RFC6836]) was not easy to maintain = and control ([CCR13]),
        which explains the migration to LISP-DDT = [I-D.ietf-lisp-ddt],
        based on a massively distributed and = hierarchical approach
        ([CCR13]).=E2=80=9D


>
>



= --Apple-Mail=_7A60D14E-9B20-47FB-AE2A-913F914A636A-- From nobody Thu Oct 22 07:22:21 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C931ACE4F; Thu, 22 Oct 2015 07:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MC0y3Dj_H2C; Thu, 22 Oct 2015 07:22:04 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3B41B37D3; Thu, 22 Oct 2015 07:22:00 -0700 (PDT) Received: by obbda8 with SMTP id da8so68155694obb.1; Thu, 22 Oct 2015 07:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jH23S56pL0ThEat7mEQYomI1r3TtOc99EwsUj+Q52JA=; b=VgUkWjYP5p/c+4KT/hT7av4oJ/kTi2HumLIan5OtrL+4lqZBQUr9SWeysu/p2MvacB rJhEH2mEcKAdPD1m/IqtUsiZHMTRhOIeFfbxxZfHJP6yejp/UdsAgwtb9je/VAkwPJfB ULnzS/v61chMTupIX7hdlubuxl0dDW6pS6tsw26TxxpIeqBvE9eNjUNoKTuS9j23YByO 8C3bu7WIAwb4Sf8fUkzqjl5yymwFfUI6UwsOtje6UsjN+gy+HveFWfDo2CpYIgE6/vlb Lx+KDuNVcYEjOg8HZafH0yDcjFqvCLvvUV+HeoZhMtgNS87hjZsL6qosDnNRS1zgsnBV boQQ== MIME-Version: 1.0 X-Received: by 10.60.135.3 with SMTP id po3mr11117152oeb.68.1445523719608; Thu, 22 Oct 2015 07:21:59 -0700 (PDT) Received: by 10.60.121.74 with HTTP; Thu, 22 Oct 2015 07:21:59 -0700 (PDT) In-Reply-To: References: <20151021204139.7539.98645.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 10:21:59 -0400 Message-ID: From: Alia Atlas To: Luigi Iannone Content-Type: multipart/alternative; boundary=047d7b41890bd25dfa0522b2375e Archived-At: Cc: lisp-chairs@ietf.org, lisp , draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Alia Atlas' Abstain on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:22:14 -0000 --047d7b41890bd25dfa0522b2375e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you. That would make me much happier with seeing this be published. Regards, Alia On Thu, Oct 22, 2015 at 10:19 AM, Luigi Iannone wrote: > Hi Alia, > > On 22 Oct 2015, at 16:16, Alia Atlas wrote: > > Hi Luigi, > > Those fixes look good. > > For the tone of the draft, I think the primary thing that I was looking f= or > was some context and indication in the introduction around the experiment= s > and experimental nature. > > Given that the WG is willing to admit in the rechartering that trying to > solve > the general Internet routing scaling problem is not a continuing target f= or > LISP, I'd be interested in some text describing a combination of > "When invented, LISP was targeted at solving the Internet routing scaling > problem. There have now been years of implementations and experiments > examining the impact and open questions of using LISP to improve > inter-domain routing scalability. This document describes, at a high > level, > the impacts and open questions still seen. This information is > particularly > useful for considering future approaches and to support further > experimentation > to clarify some large open questions (e.g. around the operations)." > > > This look great to me. This can be added to the document. > > thanks > > > Beyond that, there was one section which was a "without lisp, ..." versus > a "with lisp" that struck me as incorrect and assuming that the only > solution > to the problem was lisp. Changing it to "currently" or "as commonly > implemented" > would help. > > > I see. I=E2=80=99ll check that as well and change the tone as you suggest= ed. > > Thanks > > ciao > > Luigi > > Thanks for considering my comments. > > Regards, > Alia > > On Thu, Oct 22, 2015 at 5:58 AM, Luigi Iannone wrote: > >> Hi Alia, >> >> thanks for your comments, see inline for our replies. >> >> ciao >> >> Luigi >> >> >> > On 21 Oct 2015, at 22:41, Alia Atlas wrote: >> > >> >> [snip] >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > The opening of this draft >> > "The Locator/Identifier Separation Protocol (LISP) relies on three >> > principles to improve the scalability properties of Internet routing= : >> > address role separation, encapsulation, and mapping. The main goal >> > of LISP is to make the routing infrastructure more scalable by >> > reducing the number of prefixes announced in the Default Free Zone >> > (DFZ)." >> > is targeted at solving the Internet scalability issue for Internet >> > routing. >> > While the document goes into some details about rather large unknowns >> > and issues observed, it does not have any indications or caveats up >> > front that this is still experimental work - certainly as far as solvi= ng >> > this >> > Internet-scale problem. >> > >> > At a minimum, I think there need to be clear caveats on the experiment= al >> > nature, on the aspects still to be understood, and on the complexity a= nd >> > concerns around the operational and security aspects. >> > >> > While LISP is a really neat idea and it's good to see how far work and >> > research on it has progressed, this document reads much more like >> > marketing than something discussing the engineering and operational >> > trade-offs. >> > >> >> We did our best to change the tone of the document, >> trying to be as neutral as possible and just state observed facts. >> If something still slipped in please point us to the right spot and we= =E2=80=99ll >> fix it. >> >> > 1) There is no discussion of what the "mapping system" is and I think >> > that some of the discussion is assuming the use of BGP, but it's a bit >> > hard >> > to tell. At a minimum, it'd be good to clarify whether an >> > Internet-scale >> > deployment must use the same mapping system and what the trade-offs >> > there are. >> >> Fair enough. This is actually an open issue that has been just tackled b= y >> M. Boucaidair in his recent drafts. >> >> I would propose to saccutally modify in Sec. 5.2 the >> Business/Operational-related paragraph. >> >> That paragraph now ends with: >> >> =E2=80=9C=E2=80=A6. how will the EIDs be >> allocated to allow aggregation and hence scalability of the >> mapping system? Who will operate the mapping system >> infrastructure and for what benefits?=E2=80=9D >> >> We can append the questions: >> >> =E2=80=9CWhat is several operators run different mapping systems= ? >> How will they interoperate or share mapping information?=E2=80= =9D >> >> >> >> > >> > 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the one >> > with >> > the highest priority and sends the encapsulated packet to this RLOC. >> > If several such RLOCs exist, then the traffic is balanced >> > proportionally to their weight among the RLOCs with the lowest >> > priority value." >> > >> > It is unclear whether the "highest priority" means the lowest priority >> > value. >> > Please clarify because it incorrectly sounds like the highest priority >> > RLOC >> > is picked - unless there are multiple in which case load-balancing amo= ng >> > the >> > lowest priority value RLOCs is done. >> >> Excellent catch, thanks. The sentence is indeed misleading. >> The second sentence should be: >> >> =E2=80=9CIf several RLOCs with the highest priority exist, then = the >> traffic >> is balanced proportionally to their weight among such RLOCs." >> >> > >> > 3) Sec 5.1 "Proxies cause what is referred to as path stretch and make >> > troubleshooting harder." This doesn't actually describe what path >> > stretch >> > is in any way. I can guess from the name, but that's not sufficient. >> >> Sentence can be modified as follows, so to provide a definition of path >> stretch: >> >> "Proxies cause what is referred to as path stretch (i.e., a >> lengthening >> of the path compared to the topological shortest-path) and make >> troubleshooting harder." >> >> >> > >> > 4) In Sec 5.2: "Deployment in the beta network has shown that LISP+ALT >> > ([RFC6836], [CCR13]) was not easy to maintain and control, >> > which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt]" >> > Can you give a reference or indicate what the benefits of DDT are as >> > compared to ALT in this context? >> >> That is the content of [CCR13], but I agree that with the current >> formulation is not clear that the reader can find such information in it= . >> The text can be modified as follows: >> >> "Deployment in the beta network has shown that LISP+ALT >> ([RFC6836]) was not easy to maintain and control ([CCR13]), >> which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt], >> based on a massively distributed and hierarchical approach >> ([CCR13]).=E2=80=9D >> >> >> > >> > >> >> > > --047d7b41890bd25dfa0522b2375e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you.=C2=A0 That would make me much happier with seei= ng this
be published.

Regards,
Alia<= /div>

On Thu= , Oct 22, 2015 at 10:19 AM, Luigi Iannone <ggx@gigix.net> wrote:=
Hi A= lia,

On 22 Oct= 2015, at 16:16, Alia Atlas <akatlas@gmail.com> wrote:

Hi Luigi,

Those fixes look good.

For the tone of the draft, I think the primary thing that I was looking = for
was some context and indication in the introduction around th= e experiments
and experimental nature.

G= iven that the WG is willing to admit in the rechartering that trying to sol= ve
the general Internet routing scaling problem is not a continui= ng target for
LISP, I'd be interested in some text describing= a combination of=C2=A0
"When invented, LISP was targeted at= solving the Internet routing scaling
problem.=C2=A0 There have n= ow been years of implementations and experiments
examining the im= pact and open questions of using LISP to improve
inter-domain rou= ting scalability.=C2=A0 This document describes, at a high level,
the impacts and open questions still seen.=C2=A0 This information is parti= cularly
useful for considering future approaches and to support f= urther experimentation
to clarify some large open questions (e.g.= around the operations)."


This look great to me. This can be added to the= document.=C2=A0

thanks


Beyond = that, there was one section which was a "without lisp, ..." versu= s
a "with lisp" =C2=A0that struck me as incorrect a= nd assuming that the only solution
to the problem was lisp.=C2=A0= Changing it to "currently" or "as commonly implemented"= ;
would help.


I see. I=E2=80=99ll check that as well and change = the tone as you suggested.

Thanks

ciao

=
Luigi

Thanks for considering my comments= .

Regards,
Alia

On Thu, Oct 22, 2015 at 5:58 A= M, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia,

thanks for your comments, see inline for our replies.

ciao

Luigi


> On 21 Oct 2015, at 22:41, Alia Atlas <akatlas@gmail.com> wrote:
>

[snip]
> ----------------------------------------------------------------= ------
> COMMENT:
> ----------------------------------------------------------------------=
>
> The opening of this draft
> "The Locator/Identifier Separation Protocol (LISP) relies on thre= e
>=C2=A0 =C2=A0principles to improve the scalability properties of Intern= et routing:
>=C2=A0 =C2=A0address role separation, encapsulation, and mapping.=C2=A0= The main goal
>=C2=A0 =C2=A0of LISP is to make the routing infrastructure more scalabl= e by
>=C2=A0 =C2=A0reducing the number of prefixes announced in the Default F= ree Zone
>=C2=A0 =C2=A0(DFZ)."
> is targeted at solving the Internet scalability issue for Internet
> routing.
> While the document goes into some details about rather large unknowns<= br> > and issues observed, it does not have any indications or caveats up > front that this is still experimental work - certainly as far as solvi= ng
> this
> Internet-scale problem.
>
> At a minimum, I think there need to be clear caveats on the experiment= al
> nature, on the aspects still to be understood, and on the complexity a= nd
> concerns around the operational and security aspects.
>
> While LISP is a really neat idea and it's good to see how far work= and
> research on it has progressed, this document reads much more like
> marketing than something discussing the engineering and operational > trade-offs.
>

We did our best to change the tone of the document,
trying to be as neutral as possible and just state observed facts.
If something still slipped in please point us to the right spot and we=E2= =80=99ll fix it.

> 1) There is no discussion of what the "mapping system" is an= d I think
> that some of the discussion is assuming the use of BGP, but it's a= bit
> hard
> to tell.=C2=A0 At a minimum, it'd be good to clarify whether an > Internet-scale
> deployment must use the same mapping system and what the trade-offs > there are.

Fair enough. This is actually an open issue that has been just tackl= ed by M. Boucaidair in his recent drafts.

I would propose to saccutally modify in Sec. 5.2 the Business/Operational-r= elated paragraph.

That paragraph now ends with:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9C=E2=80=A6.=C2=A0 =C2=A0 how will the E= IDs be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allocated to allow aggregation and hence = scalability of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mapping system?=C2=A0 Who will operate th= e mapping system
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0infrastructure and for what benefits?=E2= =80=9D

We can append the questions:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9CWhat is several operators run differen= t mapping systems?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 How will they interoperate or share mapping inf= ormation?=E2=80=9D



>
> 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the= one
> with
>=C2=A0 =C2=A0the highest priority and sends the encapsulated packet to = this RLOC.
>=C2=A0 =C2=A0If several such RLOCs exist, then the traffic is balanced<= br> >=C2=A0 =C2=A0proportionally to their weight among the RLOCs with the lo= west
>=C2=A0 =C2=A0priority value."
>
> It is unclear whether the "highest priority" means the lowes= t priority
> value.
> Please clarify because it incorrectly sounds like the highest priority=
> RLOC
> is picked - unless there are multiple in which case load-balancing amo= ng
> the
> lowest priority value RLOCs is done.

Excellent catch, thanks. The sentence is indeed misleading.
The second sentence should be:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9CIf several RLOCs with the highest prio= rity exist, then the traffic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is balanced proportionally to their weight amon= g such RLOCs."

>
> 3) Sec 5.1 "Proxies cause what is referred to as path stretch and= make
>=C2=A0 =C2=A0troubleshooting harder."=C2=A0 This doesn't actua= lly describe what path
> stretch
> is in any way.=C2=A0 I can guess from the name, but that's not suf= ficient.

Sentence can be modified as follows, so to provide a definition of p= ath stretch:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Proxies cause what is referred to as path= stretch (i.e., a lengthening
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the path compared to the topological shortes= t-path) and make
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0troubleshooting harder."


>
> 4) In Sec 5.2: "Deployment in the beta network has shown that LIS= P+ALT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0([RFC6836], [CCR13]) was not easy to = maintain and control,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which explains the migration to LISP-= DDT [I-D.ietf-lisp-ddt]"
> Can you give a reference or indicate what the benefits of DDT are as > compared to ALT in this context?

That is the content of [CCR13], but I agree that with the current formulation is not clear that the reader can find such information in it. The text can be modified as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Deployment in the beta network has shown = that LISP+ALT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ([RFC6836]) was not easy to maintain and= control ([CCR13]),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which explains the migration to LISP-DDT [I-D.i= etf-lisp-ddt],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 based on a massively distributed and hierarchic= al approach
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ([CCR13]).=E2=80=9D


>
>



--047d7b41890bd25dfa0522b2375e-- From nobody Thu Oct 22 10:40:35 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A311A912C for ; Thu, 22 Oct 2015 10:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E3ncZY0rOpm for ; Thu, 22 Oct 2015 10:40:32 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4C71B3AA2 for ; Thu, 22 Oct 2015 10:40:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F3089760BD6 for ; Thu, 22 Oct 2015 10:40:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A5717760BCA for ; Thu, 22 Oct 2015 10:40:26 -0700 (PDT) To: "lisp@ietf.org" References: <20151022170347.25090.56933.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <56291F89.3050400@joelhalpern.com> Date: Thu, 22 Oct 2015 13:40:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151022170347.25090.56933.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 17:40:34 -0000 The Authors having been very responsive to IESG member questions and concerns, we have approval on the lisp impact document. My thanks and congratulations to the authors. As the status below indicates, they will be producing a revision to reflect those discussions. I believe several of those changes improve the readability and clarity of the document. And then it will go to the RFC Editor for publication. Congratulations, Joel On 10/22/15 1:03 PM, IETF Secretariat wrote: > IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation > ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ > > From nobody Fri Oct 23 11:34:46 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B557E1A1B1B for ; Fri, 23 Oct 2015 11:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hun_0c1BZj9A for ; Fri, 23 Oct 2015 11:34:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B641B1A007C for ; Fri, 23 Oct 2015 11:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=471; q=dns/txt; s=iport; t=1445625284; x=1446834884; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Laug9kTggNcGIIjFNV7HQ+T8bdlSJZaYFWut00yLJdk=; b=gXukXPsNwkZeuuNGwIgvX6h4jGAa0R9nw7rdDSicHzFYNoJ/U+cDj4Da 2kedq9VNKjSHPei9HhIhr7vOn9NQp65qKR573usTep5EY0M1wqfog1dam iRObsN2IJuATjcvD/jihMyisVMDFwiwcvL4parQYy/gFKK7VZvNKmh577 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQCvfCpW/5xdJa1egzaBSb4mAQ2BWYdeOBQBAQEBAQEBgQqEOTpRAT5CJwSIQ6Nfok0BAQEBAQUBAQEBAQEBARuGd4IQhCuGcYEUBZYrAXmMJJwlAR8BAUKCHoFlhi+BBgEBAQ X-IronPort-AV: E=Sophos;i="5.20,187,1444694400"; d="scan'208";a="38496954" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 23 Oct 2015 18:34:43 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9NIYh5E019965 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Oct 2015 18:34:44 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 23 Oct 2015 13:34:22 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Fri, 23 Oct 2015 13:34:22 -0500 From: "Victor Moreno (vimoreno)" To: LISP mailing list list Thread-Topic: Editorial error in RFC 6830 Thread-Index: AQHRDcFvm1CW0pE9zUWBJGdstXRtHg== Date: Fri, 23 Oct 2015 18:34:22 +0000 Message-ID: <6A4EB81B-2780-4A19-B22D-55A048B2E5FB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.204.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <0950B26ADDDBFF479E516FDA8BAA7844@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lisp] Editorial error in RFC 6830 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 18:34:45 -0000 Hello WG,=20 I found the following editorial error, I understand text fixes to the RFC a= re currently being collected. Negative mapping entries are introduced in section 3 (page 8) and therein i= s a cross-reference to section 6.1.5 for the well defined actions associate= d with a negative map reply. The cross referenced actions are actually docu= mented in section 6.1.4, not 6.1.5. The cross-reference needs to be correct= ed to 6.1.4. Regards, -v From nobody Mon Oct 26 09:25:23 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68531B4CF3 for ; Mon, 26 Oct 2015 09:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STtz8eW6lyxX for ; Mon, 26 Oct 2015 09:25:20 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7AC1B4BAB for ; Mon, 26 Oct 2015 09:25:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8947B288CA3 for ; Mon, 26 Oct 2015 09:25:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 44BE0288C8A for ; Mon, 26 Oct 2015 09:25:20 -0700 (PDT) To: "lisp@ietf.org" From: "Joel M. Halpern" Message-ID: <562E53EF.9070707@joelhalpern.com> Date: Mon, 26 Oct 2015 12:25:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 16:25:22 -0000 It seemed to us that there was likely some confusiona bout how we expect to handle the revision of RCC 6830. The following is what we currently expect. Once we have a new charter approved, the chairs will appoint an editor for the revision of rfc6830. That may be one of the existing authors, or a new person. We will ask for volunteers. Once we have an author, they will submit a starting ID called draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the existing RFC. That may require assistance from the RFC Editor to ensure that we get all the changes they made during final edit. At that point, we will use the trouble ticket system to record issues that people bring up. We will also discuss on the list what changes we wish to make according to the charter. Things will tehn proceed in the usual fashion, using the trouble ticket system to help make sure we do not drop any of the issues. Yours, Joel & Luigi From nobody Wed Oct 28 04:04:57 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94501B509C for ; Wed, 28 Oct 2015 04:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad3FTikg4jep for ; Wed, 28 Oct 2015 04:04:54 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB811A86F2 for ; Wed, 28 Oct 2015 04:04:54 -0700 (PDT) Received: by wmff134 with SMTP id f134so6174279wmf.1 for ; Wed, 28 Oct 2015 04:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LSEtqVGzkP3Gg62Hbdim3XOl3FORYBR9ck1AYwyIiPc=; b=CSkEDU6aV4fv+7seQH3sgCHE3+RXq5ElEiJ+vrQhpnYEz5NDZADI5cUJ8gxvklok6o deWgMSq0B3EMAZMLdh1sziJht+UDxQ6BgoA1agQXZah3wbOm7I7i3MJKvK8wu9B93zVs yyH1a7xDKaCqk3az0kUKJFKSeeeeIyNCdBJNwOnL1U90r+61MQiEvFwjb41szxTGfUW7 zt8zLMFwsLwS0g+YV73BP7AI1qZ0Rm0MMT1bjX43Mw5UPPrxsiUML4AnM3tXxMWlyceZ eDYVdS3kjjJPIvIQJfFivC5rGD4na56zo4+vPsz2sB1Ii6ZsXlwiDgnI85LoJkM54GYV XLTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LSEtqVGzkP3Gg62Hbdim3XOl3FORYBR9ck1AYwyIiPc=; b=Jxt9CTKSFD6ed7OT1aH6JIkp1ezdVm0ZggEkq5qc3/obunhHMeJ+TiGl77AgeLam9K euHOxCO1ZXYBIX3eMu2NDDKg23T+aHD/YSIhZdDwHsRUNmLuRzr85vYDxnLJRrLWE06y Dpgaye9Fe6cU88H8K7z1Luoytx+GgtNR23BI+DNjWgEn+tOtGl8dipks+CStNGiI83Rq CKhHf+K19UVTCMmLL0pGuzNhOU1zfC3XSfJflv68yuElbZ6C7BzFhbClGxw83Og9QL0a YRRqheW83VVyhRqWSrz5H6lnA5QohPNMJWN0BUo4Ev/y36gz1K6oEbsQtjSzBHkI0m3D 4Aaw== X-Gm-Message-State: ALoCoQk58bdqq1bIjAXKeTug4x3v8hKX8h8Xz5yRExbYccWJvi80AKeeCTIbMVvIJX/xoNlW65tX X-Received: by 10.28.23.66 with SMTP id 63mr1094632wmx.4.1446030292670; Wed, 28 Oct 2015 04:04:52 -0700 (PDT) Received: from dhcp164-197.enst.fr (dhcp164-197.enst.fr. [137.194.165.197]) by smtp.gmail.com with ESMTPSA id fl7sm20864569wic.18.2015.10.28.04.04.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Oct 2015 04:04:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A6BAE50-06F0-4057-B2F0-141FF29BE14F" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luigi Iannone In-Reply-To: Date: Wed, 28 Oct 2015 12:05:11 +0100 Message-Id: References: To: LISP mailing list list X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [lisp] Agenda/Slides X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 11:04:55 -0000 --Apple-Mail=_0A6BAE50-06F0-4057-B2F0-141FF29BE14F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, no changes to the agenda have been requested, hence, below you can find = the confirmed agenda.=20 All speakers are invited to send their slides to the chairs = > by Monday at = latest. ciao L. =20 > AGENDA >=20 > Session 1/1 (90 Minutes) > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > Tuesday, November 4, 2015 > 1520-1650, Afternoon Session II, 90 Minutes > Room: 301 >=20 > - Administration =20 > Halpern > - Blue Sheets > - Agenda Bashing > - Status reports for WG drafts > 10 Minutes (Cumulative Time: 10 Minutes)=20 >=20 > o WG Documents Update >=20 > - LCAF Draft Update - draft-ietf-lisp-lcaf-11=20 > 5 Minutes (Cumulative Time: 15 Minutes)=20 > D. Farinacci >=20 > - LISP-crypto - draft-ietf-lisp-crypto-02=20 > 15 minutes (Cumulative Time: 30 Minutes)=20 > D. Farinacci >=20 >=20 > o Rechartering Discussion >=20 > - State of Affairs in Multicast Overlays > RFC 6831 > draft-farinacci-lisp-mr-signaling-06 > draft-farinacci-lisp-signal-free-multicast-03 > 10 minutes (Cumulative Time: 40 Minutes) > D. Farinacci=20 >=20 > - NSH extension draft (draft-ermagan-nsh-00). > 10 Minutes (Cumulative Time: 50 Minutes) > V. Ermagan >=20 > - LISP Subscription > 10 Minutes (Cumulative Time: 60 Minutes) > A. Rodriguez-Natal >=20 > - Overflow Time/ Discussion > 30 Minutes (Cumulative Time: 90 Minutes) >=20 --Apple-Mail=_0A6BAE50-06F0-4057-B2F0-141FF29BE14F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

no = changes to the agenda have been requested, hence, below you can find the = confirmed agenda. 

All speakers are invited to send their slides = to the chairs <lisp-chairs@ietf.org> by Monday at latest.

ciao

L.
 


AGENDA

Session 1/1 (90 Minutes)
=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-

Tuesday, November 4, 2015
1520-1650, Afternoon Session II, 90 Minutes
Room:= 301

- Administration =         
   Halpern
   - = Blue Sheets
   - Agenda Bashing
   - Status reports for WG drafts
= 10 Minutes  (Cumulative Time: 10 = Minutes) 

o WG Documents Update

- LCAF Draft Update - = draft-ietf-lisp-lcaf-11 
5 Minutes  = (Cumulative Time: 15 Minutes) 
D. = Farinacci

- LISP-crypto - = draft-ietf-lisp-crypto-02 
15 = minutes = (Cumulative Time: 30 Minutes) 
D. = Farinacci


o Rechartering = Discussion

- State of Affairs in Multicast = Overlays
RFC 6831
= draft-farinacci-lisp-mr-signaling-06
= draft-farinacci-lisp-signal-free-multicast-03
10 = minutes = (Cumulative Time: 40 Minutes)
D. = Farinacci 

- NSH extension draft = (draft-ermagan-nsh-00).
10 Minutes  = (Cumulative Time: 50 Minutes)
V. = Ermagan

- LISP Subscription
= 10 Minutes  (Cumulative Time: 60 Minutes)
= A. Rodriguez-Natal

- Overflow Time/ = Discussion
       30 = Minutes   (Cumulative Time: 90 Minutes)


= --Apple-Mail=_0A6BAE50-06F0-4057-B2F0-141FF29BE14F-- From nobody Wed Oct 28 05:48:46 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD21F1B54E6 for ; Wed, 28 Oct 2015 05:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw9mSotHd-pK for ; Wed, 28 Oct 2015 05:48:43 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B7D1B54E0 for ; Wed, 28 Oct 2015 05:48:42 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 3254DC01D0; Wed, 28 Oct 2015 13:48:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 0F1091A0064; Wed, 28 Oct 2015 13:48:41 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%19]) with mapi id 14.03.0248.002; Wed, 28 Oct 2015 13:48:39 +0100 From: To: Alberto Rodriguez-Natal , "lisp@ietf.org list" Thread-Topic: [lisp] LISP subscription Thread-Index: AQHQ+8kvZCw302ijakCWjcSoUqVO8J6BBSLw Date: Wed, 28 Oct 2015 12:48:39 +0000 Message-ID: <06077260-0842-43ea-b619-65818a29f8ed@OPEXCLILMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_06077260084243eab61965818a29f8edOPEXCLILMA2corporateadr_" MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] LISP subscription X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 12:48:44 -0000 --_000_06077260084243eab61965818a29f8edOPEXCLILMA2corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxiZXJ0bywNCg0KVGhhbmsgeW91IGZvciBzaGFyaW5nIHRoZSBzbGlkZXMgYW5kIGFsc28g Zm9yIGluY2x1ZGluZyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3Vj YWRhaXItbGlzcC1zdWJzY3JpYmUvIGluIHlvdXIgYW5hbHlzaXMuDQoNCldpdGggcmVnYXJkcyB0 byBkcmFmdC1ib3VjYWRhaXItKiwgSSB3b3VsZCBsaWtlIHRvIG1lbnRpb24gdGhhdCB3ZSB3ZW50 IGZvciB0aGF0IGRlc2lnbiBiZWNhdXNlIHdlIGRvbuKAmXQgd2FudCB0byBvdmVybG9hZCBleGlz dGluZyBwcmltaXRpdmVzIHdpdGggbmV3IGZ1bmN0aW9uYWxpdGllcyB0aGF0IGFyZSBzcGVjaWZp YyB0byBzdWJzY3JpcHRpb24uIEkgZG8gc2VlIGEgdmFsdWUgaW4gaGF2aW5nIGRlZGljYXRlZCBt ZXRob2RzIGZvciBhY2hpZXZpbmcgdGhhdCBmdW5jdGlvbmFsaXR5Lg0KDQpDaGVlcnMsDQpNZWQN Cg0KRGUgOiBsaXNwIFttYWlsdG86bGlzcC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl IEFsYmVydG8gUm9kcmlndWV6LU5hdGFsDQpFbnZvecOpIDogbWVyY3JlZGkgMzAgc2VwdGVtYnJl IDIwMTUgMjM6NDQNCsOAIDogbGlzcEBpZXRmLm9yZyBsaXN0DQpPYmpldCA6IFtsaXNwXSBMSVNQ IHN1YnNjcmlwdGlvbg0KDQpIaSBhbGwsDQpBcyB5b3UgbWF5IGtub3csIHNvbWUgb2YgdXMgaGF2 ZSBiZWVuIHRhbGtpbmcgZm9yIGEgd2hpbGUgYWJvdXQgZGlmZmVyZW50IGFwcHJvYWNoZXMgdG8g c3VwcG9ydCBzdWJzY3JpcHRpb24gaW4gTElTUC4gT24gdGhlIGF0dGFjaGVkIHNsaWRlcyB5b3Ug Y2FuIGZpbmQgYSBzdW1tYXJ5IG9mIG91ciB0aG91Z2h0cyBvbiB0aGUgdG9waWMuDQpXZSBob3Bl IHRoZXkgY2FuIGhlbHAgdG8gdHJpZ2dlciBhIHdpZGVyIGRpc2N1c3Npb24gd2l0aGluIHRoZSBX Ry4gSWYgdGltZSBhbGxvd3MsIHdlIGNhbiBwcmVzZW50IHRoZW0gYXQgWW9rb2hhbWEuDQpUaGFu a3MsDQpBbGJlcnRvDQo= --_000_06077260084243eab61965818a29f8edOPEXCLILMA2corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIEFsYmVydG8sDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UgZm9yIHNoYXJpbmcgdGhlIHNs aWRlcyBhbmQgYWxzbyBmb3IgaW5jbHVkaW5nDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRhaXItbGlzcC1zdWJzY3JpYmUvIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRhaXItbGlzcC1zdWJzY3JpYmUvPC9h PiBpbiB5b3VyIGFuYWx5c2lzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPldpdGggcmVnYXJkcyB0byBkcmFmdC1ib3VjYWRhaXItKiwgSSB3b3Vs ZCBsaWtlIHRvIG1lbnRpb24gdGhhdCB3ZSB3ZW50IGZvciB0aGF0IGRlc2lnbiBiZWNhdXNlIHdl IGRvbuKAmXQgd2FudCB0byBvdmVybG9hZCBleGlzdGluZyBwcmltaXRpdmVzIHdpdGggbmV3IGZ1 bmN0aW9uYWxpdGllcw0KIHRoYXQgYXJlIHNwZWNpZmljIHRvIHN1YnNjcmlwdGlvbi4gSSBkbyBz ZWUgYSB2YWx1ZSBpbiBoYXZpbmcgZGVkaWNhdGVkIG1ldGhvZHMgZm9yIGFjaGlldmluZyB0aGF0 IGZ1bmN0aW9uYWxpdHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbGlzcCBbbWFpbHRvOmxpc3AtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEFsYmVydG8gUm9kcmlndWV6LU5hdGFsPGJy Pg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDMwIHNlcHRlbWJyZSAyMDE1IDIzOjQ0 PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBsaXNwQGlldGYub3JnIGxpc3Q8YnI+DQo8Yj5PYmpldCZu YnNwOzo8L2I+IFtsaXNwXSBMSVNQIHN1YnNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ QXMgeW91IG1heSBrbm93LCBzb21lIG9mIHVzIGhhdmUgYmVlbiB0YWxraW5nIGZvciBhIHdoaWxl IGFib3V0IGRpZmZlcmVudCBhcHByb2FjaGVzIHRvIHN1cHBvcnQgc3Vic2NyaXB0aW9uIGluIExJ U1AuIE9uIHRoZSBhdHRhY2hlZCBzbGlkZXMgeW91IGNhbiBmaW5kIGEgc3VtbWFyeSBvZiBvdXIg dGhvdWdodHMgb24gdGhlIHRvcGljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPldlIGhvcGUgdGhleSBjYW4g aGVscCB0byB0cmlnZ2VyIGEgd2lkZXIgZGlzY3Vzc2lvbiB3aXRoaW4gdGhlIFdHLiBJZiB0aW1l IGFsbG93cywgd2UgY2FuIHByZXNlbnQgdGhlbSBhdCBZb2tvaGFtYS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGJlcnRvPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_06077260084243eab61965818a29f8edOPEXCLILMA2corporateadr_-- From nobody Wed Oct 28 07:17:13 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B641A8961 for ; Wed, 28 Oct 2015 07:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvhepoL7I9HE for ; Wed, 28 Oct 2015 07:17:08 -0700 (PDT) Received: from filtteri6.pp.htv.fi (filtteri6.pp.htv.fi [213.243.153.189]) by ietfa.amsl.com (Postfix) with ESMTP id B4C4D1A8955 for ; Wed, 28 Oct 2015 07:17:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri6.pp.htv.fi (Postfix) with ESMTP id 2F5AE56FB49 for ; Wed, 28 Oct 2015 16:17:06 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri6.pp.htv.fi [213.243.153.189]) (amavisd-new, port 10024) with ESMTP id LXK8kwnYZu4V for ; Wed, 28 Oct 2015 16:17:06 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id F418A5BC010 for ; Wed, 28 Oct 2015 16:17:05 +0200 (EET) Date: Wed, 28 Oct 2015 16:17:03 +0200 From: Ilari Liusvaara To: lisp@ietf.org Message-ID: <20151028141703.GA9632@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: [lisp] Let's review crypto in lisp-crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:17:11 -0000 I did a review of crypto usage of lisp-crypto (-02), and found the following issues (some I have noticed before, some were new to me): - Ciphersuite 1 uses 1024-bit Diffie-Hellman, which is too weak (after you have cracked one key (and it doesn't take that much, especially if you can throw ASICs at the problem), you can crack each subsequent one in a few CPU minutes. With 2048-bit DH, at least the first key tends to be too hard, and with ECDH, tricks like this don't work). - Instead of "homecooked" encryption, use AEAD modes. AES-GCM is a lot faster than AES-CBC + HMAC-SHA1-96. - AEAD_CHACHA20_POLY1305 is not composition of CHACHA20 and POLY1305, it is a single AEAD algorithm (as is AES128-GCM). - How to encode Diffie-Hellman public keys? I presume big-endian integer encoding. - Don't truncate Diffie-Hellman secret, just feed the entiere thing to the KDF. - The NIST SP800-108 KDF handles the counter and length internally, those are not part of the context input. - If you need identifier for association (e.g. for displaying to admin for authentication purposes), you must hash in the (EC)DH public keys used into the identifier. Otherwise MITM attacker can defeat the authentication. - If the same system can be ITR and ETR at once, how one ensures that if two such systems establish associations to each other, the keys won't wind up being the same? This could be solved by requiring separate keys for ITR and ETR operation, or including the public keys in the context in fixed order (e.g. first ITR, then ETR). - AEAD_CHACHA20_POLY1305 IVs are 12 octets, right? That's too short to randomly generate. Instead, the encryptor should just use its preferred generation method that takes long time to cycle (counter, 96-bit LFSR, etc...). - Are the associations unidirectional (data is only ever sent one way) or how is uniqueness of IVs between directions handled? - IV is incremented for every packet? If using CBC mode, predictable IVs are bad (AEAD algorithms do deal with predictable IVs, but not repeating IVs). - What one does feed into "AD" input of AEAD_CHACHA20_POLY1305? Everything that is marked as ICV but not Encrypt? Or just the LISP parts? (One doesn't need to authenticate the IV, but it can sometimes be easier to authenticate it). - AEAD_CHACHA20_POLY1305 encryption already splits out the ICV (a.k.a. tag). - AEAD_CHACHA20_POLY1305 decryption both checks the ICV and if the check passes, decrypts the data. So performing step 2 also performs step 5. - I don't see requirement that ITR nonces must be distinct for the same ITR DH key (otherwise encryption keys will be the same if the ETR DH key is the same)? - The CHACHA-POLY reference should presumably point to RFC7539? - Maybe use the CFRG-CURVES draft (in RFC-EDITOR queue) for Curve25519/X25519. -Ilari From nobody Wed Oct 28 10:10:00 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E281A9151 for ; Wed, 28 Oct 2015 10:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eibrFjJEGtfE for ; Wed, 28 Oct 2015 10:09:55 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED21A9231 for ; Wed, 28 Oct 2015 10:09:54 -0700 (PDT) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id t9SFMMh2003478 for ; Wed, 28 Oct 2015 16:22:22 +0100 Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id 20AE39B for ; Wed, 28 Oct 2015 18:09:53 +0100 (CET) Received: by lbbwb3 with SMTP id wb3so10670793lbb.1 for ; Wed, 28 Oct 2015 10:09:52 -0700 (PDT) X-Received: by 10.112.11.163 with SMTP id r3mr23186767lbb.8.1446052192341; Wed, 28 Oct 2015 10:09:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.59.225 with HTTP; Wed, 28 Oct 2015 10:09:32 -0700 (PDT) In-Reply-To: <06077260-0842-43ea-b619-65818a29f8ed@OPEXCLILMA2.corporate.adroot.infra.ftgroup> References: <06077260-0842-43ea-b619-65818a29f8ed@OPEXCLILMA2.corporate.adroot.infra.ftgroup> From: Alberto Rodriguez-Natal Date: Wed, 28 Oct 2015 18:09:32 +0100 Message-ID: To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=001a11c3c70640541a05232d43c5 Archived-At: Cc: "lisp@ietf.org list" Subject: Re: [lisp] LISP subscription X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 17:09:59 -0000 --001a11c3c70640541a05232d43c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Med, On Wed, Oct 28, 2015 at 1:48 PM, wrote: > Hi Alberto, > > > > Thank you for sharing the slides and also for including > https://datatracker.ietf.org/doc/draft-boucadair-lisp-subscribe/ in your > analysis. > My pleasure, the draft was really relevant. > > > With regards to draft-boucadair-*, I would like to mention that we went > for that design because we don=E2=80=99t want to overload existing primit= ives with > new functionalities that are specific to subscription. I do see a value i= n > having dedicated methods for achieving that functionality. > Absolutely, that's something worth discussing. Hopefully we'll have some time to go over this in Japan. Best, Alberto > > > Cheers, > > Med > > > > *De :* lisp [mailto:lisp-bounces@ietf.org] *De la part de* Alberto > Rodriguez-Natal > *Envoy=C3=A9 :* mercredi 30 septembre 2015 23:44 > *=C3=80 :* lisp@ietf.org list > *Objet :* [lisp] LISP subscription > > > > Hi all, > > As you may know, some of us have been talking for a while about different > approaches to support subscription in LISP. On the attached slides you ca= n > find a summary of our thoughts on the topic. > > We hope they can help to trigger a wider discussion within the WG. If tim= e > allows, we can present them at Yokohama. > > Thanks, > > Alberto > --001a11c3c70640541a05232d43c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Med,

On Wed, Oct 28, 2015 at 1:48 PM, <mohamed.bou= cadair@orange.com> wrote:

Hi Alberto,

=C2=A0

Thank you for sharing the slide= s and also for including https://datatracker.ietf.org/doc/draft-boucadair-lisp-s= ubscribe/ in your analysis.


My pleasure, the dr= aft was really relevant.

=C2=A0

With regards to draft-boucadair= -*, I would like to mention that we went for that design because we don=E2= =80=99t want to overload existing primitives with new functionalities that are specific to subscription. I do see a value in having dedicated me= thods for achieving that functionality.


Absolutely, that= 9;s something worth discussing. Hopefully we'll have some time to go ov= er this in Japan.

Best,
Alberto
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: lisp= [mailto:lisp-bo= unces@ietf.org] De la part de Alberto Rodriguez-Natal
Envoy=C3=A9=C2=A0: mercredi 30 septembre 2015 23:44
=C3=80=C2=A0: lis= p@ietf.org list
Objet=C2=A0: [lisp] LISP subscription

=C2=A0

Hi all,=

As you may know, some= of us have been talking for a while about different approaches to support = subscription in LISP. On the attached slides you can find a summary of our = thoughts on the topic.

We hope they can help= to trigger a wider discussion within the WG. If time allows, we can presen= t them at Yokohama.

Thanks,

Alberto


--001a11c3c70640541a05232d43c5--