From nobody Wed Nov 1 10:22:04 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA1013F9AA; Wed, 1 Nov 2017 10:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 FDvC12faLQUP; Wed, 1 Nov 2017 10:21:51 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4905C13F991; Wed, 1 Nov 2017 10:21:51 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5560358C4F6; Wed, 1 Nov 2017 18:21:46 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 405ABB0D054; Wed, 1 Nov 2017 18:21:46 +0100 (CET) Date: Wed, 1 Nov 2017 18:21:46 +0100 From: Toerless Eckert To: Christian Huitema Cc: Padma Pillay-Esnault , "ideas@ietf.org" , "lisp@ietf.org list" , Dino Farinacci , "ietf@ietf.org" Message-ID: <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> References: <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:21:54 -0000 On Wed, Oct 11, 2017 at 12:34:19PM -0700, Christian Huitema wrote: > Some thing you should be hearing is that "long term identity of device" > has almost the same privacy properties as "long term identity of the > device's owner". You may think that identifying a random piece of > hardware is no big deal, but it turns out that the network activity and > network locations of that piece of hardware can be associated to those > of its human owner. So you need the same kind of protection for these > device identifiers as for human identifiers. Sure, but i don't think it can be generalized: There will be more and more non-individually owned nodes in public and corporate infrastructures where requirements will be quite different from those derived from individual human privacy. If lets say those long term identifiers do not provide good human privacy protection but good communications security properties and managed transpacency for regulators then they could still be a great benefit for those class of nodes. [rant] Trying to get more privacy into network layer is like making tobacco more organic. You can get buried in the organic section of the graveyard after you die of lung cancer. Great success! Aka: Where is the IETF on any warnings, architectures or recommendations on the actual application layer: "Inhaling of this web page / IoT device will expose your personal activities related to it, social security number and credit card information to a "trusted set" of 1000 collaborating web services companies of which 10 at least have already been fined several times for leaking your information - and then made even more money out of it" (sorry, just can't get beyond the fact that equifax is not making money out of their leakage...) Should come with every mayor web page and IoT device. [/rant] Venting aside, i'd actually love to understand better if/what IETF does for privacy inside eg: a TLS payload, besides sipbrandy/dprive/perc ? Cheers Toerless > -- > Christian Huitema > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas From nobody Thu Nov 2 08:30:18 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B9513F82F for ; Thu, 2 Nov 2017 08:30:16 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 HOvcSszJXHI6 for ; Thu, 2 Nov 2017 08:30:15 -0700 (PDT) Received: from mail-ua0-x241.google.com (mail-ua0-x241.google.com [IPv6:2607:f8b0:400c:c08::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 891ED139680 for ; Thu, 2 Nov 2017 08:30:12 -0700 (PDT) Received: by mail-ua0-x241.google.com with SMTP id v27so4246599uav.7 for ; Thu, 02 Nov 2017 08:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0YDnVodjsKJZ2cUlNPs3xCRZ2v1Gqd4oIuQfAYOb0UA=; b=aQP8Ld6FPuvOoizzw+kIms8wQEteGVMMoLsRFy2NgH/9zAG4fNj5cTBBz8iwgS5CMy FqZR2m9r3ZPYrFzKdcOPUgCU0K/M9lmF8G83O/s10V4JFcqzoykaFX4GCmVgj5xyEbn9 lk0cceqw9LBB8ZwbGL9JjSTZoJ4HM2WdhUjluwI8uVdqky7u7DHuoNnX3+ruIM9UUkwt UNBgJVt6KKSO0KbWhEbYERUmNzEpzIpiE11V2DTl3ZW69w/FMdWDsbDyvj7dZao119Eo pvL4JM/L+1Pp5tv786YrPidQsBFP/NfXNxGg7C0sTXMuvtSNAQVIE1x6k2j9lixm/OXa mHIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0YDnVodjsKJZ2cUlNPs3xCRZ2v1Gqd4oIuQfAYOb0UA=; b=N98cGlybm47aBUVCkzubZZXCTw0c7IpuzYgfVoNbx3fEbfzeCpRnMt1RyZQ5KtSECe pvYXVrvEzFmBb0wXzeSpp38Z+xG4w9gTiEWxcEs6/NmZyCqPLdydUhMJz4keWTYVOQOd UIuSrf6iqODg8dq20q6SOmdQ5Pjs9is6NyVpodKcYsEblLmRTFFt6YClJzPzAplqQww5 fLgnEFp060bOKSx/SGFAuepama+jlAA3SoOqiWpBIksUwaDdKg0MqKK2js21mnk/5fvm uU3SDxQJyoyZ05SL1Y2opRqZVgsSIDLz1F9RCGoMrSjfVLdMGvijb/65TbMAKiybM3AI Plfg== X-Gm-Message-State: AMCzsaUtdFm7ewVfHq2Tr1eqx4NMEtIy1naDFtl7abng2D0elglHgTcr IX7CEj65IGDAsGu6HlJc0O0SYv957RIthkHQL5htUQ== X-Google-Smtp-Source: ABhQp+SaVrAbsJKwiDzMP1+5KlJmpV1k4uBCkBZpvil031q2Iy+MRpGrmCvZ8oxQFGIW2i8WWmHjAxDaqOr8QxeJuLA= X-Received: by 10.176.83.206 with SMTP id l14mr3297045uaa.167.1509636611570; Thu, 02 Nov 2017 08:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.69.4 with HTTP; Thu, 2 Nov 2017 08:30:11 -0700 (PDT) In-Reply-To: <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> References: <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> From: Tom Herbert Date: Thu, 2 Nov 2017 08:30:11 -0700 Message-ID: To: Toerless Eckert Cc: Christian Huitema , Padma Pillay-Esnault , "ietf@ietf.org" , "ideas@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 02 Nov 2017 15:30:17 -0000 On Wed, Nov 1, 2017 at 10:21 AM, Toerless Eckert wrote: > On Wed, Oct 11, 2017 at 12:34:19PM -0700, Christian Huitema wrote: >> Some thing you should be hearing is that "long term identity of device" >> has almost the same privacy properties as "long term identity of the >> device's owner". You may think that identifying a random piece of >> hardware is no big deal, but it turns out that the network activity and >> network locations of that piece of hardware can be associated to those >> of its human owner. So you need the same kind of protection for these >> device identifiers as for human identifiers. > > Sure, but i don't think it can be generalized: > > There will be more and more non-individually owned nodes in public and > corporate infrastructures where requirements will be quite different > from those derived from individual human privacy. > Toerless, That maybe true, but personal devices, such as smart phones and cars that are associated with individuals, are hardly going away anytime soon. How addresses are assigned to these devices has a material impact on individual privacy. Even right now there are two long threads on v6ops right now that are delving precisely into privacy of IPv6 addresses that may be relevant. This includes discussion about CGNAT and efforts by some governments to illegalize it because the privacy it gives is too strong for law enforcement. > If lets say those long term identifiers do not provide good human > privacy protection but good communications security properties and > managed transpacency for regulators then they could still be a great > benefit for those class of nodes. > > [rant] > > Trying to get more privacy into network layer is like making > tobacco more organic. You can get buried in the organic section > of the graveyard after you die of lung cancer. Great success! > > Aka: Where is the IETF on any warnings, architectures or recommendations > on the actual application layer: > Maybe there should be something like that. But, not unlike security, if the goal is to derive a system with good privacy characteristics then privacy should be considered at every layer including the networking layer. Tom From nobody Fri Nov 3 01:35:47 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE44A13FD01 for ; Fri, 3 Nov 2017 01:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eBq8gbulY12H for ; Fri, 3 Nov 2017 01:35:39 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id A4B3513FCFC for ; Fri, 3 Nov 2017 01:35:38 -0700 (PDT) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vA38ZaMN008834 for ; Fri, 3 Nov 2017 09:35:37 +0100 Received: from [192.168.1.135] (117.29.15.37.dynamic.jazztel.es [37.15.29.117]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id BAF011A0 for ; Fri, 3 Nov 2017 09:35:31 +0100 (CET) From: =?UTF-8?Q?Albert_L=c3=b3pez?= To: lisp@ietf.org Message-ID: Date: Fri, 3 Nov 2017 09:35:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [lisp] draft-ermagan-lisp-nat-traversal question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 03 Nov 2017 08:35:46 -0000 Dear all, In section 5.3 of the draft draft-ermagan-lisp-nat-traversal which describe the RTR processing, it says that when the RTR receive and ECM-ed Map Notify, once it is validated, it changes the state of the associated map-cache entry to verified for the duration of the Map Register TTL. What does it mean by Map Register TTL? it means the TTL of the record of the Map Register or it is the same concept of the Map Register TTL of the Map Server which is 3 minutes? If I understand correctly, if we don't receive more Encap Map Register / Map Notify to renew this verified period, the map-cache entry of the RTR expires, at least the locator of the map-cache entry associated with the Encap Map register. "Once the authenticity of the message is verified, RTR can confirm that the Map-Register message for the ETR with the matching xTR-ID was accepted by the Map-Server. At this point the RTR can change the state of the associated map-cache entry to verified for the duration of the Map-Register TTL" Thank you in advance. Albert López From nobody Fri Nov 3 10:38:22 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E6813FF04 for ; Fri, 3 Nov 2017 10:38:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 weXSB0Bp99ow for ; Fri, 3 Nov 2017 10:38:18 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 CC8D513FF0E for ; Fri, 3 Nov 2017 10:38:18 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id v78so3058669pgb.5 for ; Fri, 03 Nov 2017 10:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9PJzaK4pmV0IXYmlEfR7X3NK/t8tcHtAQAKaYYXsvGQ=; b=oPdIzv3Kg0hfnnVXUO0PtEPyT0/dEDDXjFFP2jYbNi7M+G/J8ehlLD+ZEVjD+twKOL gbbL3TLOYgxISpJX2Y7/a7i3VpXms3RINVlccsJKaWcVVvwC7/gaLjkrKcO28O9/MZQS IgMnjJ+bIlCiJ8d0QSLvkvo4SVfAAtykp/o0Ei2dtPZerk3JOV7/s2s+Jcf+WjvjzTin k+JATkAPxGGmDunP1e3rYpuiGt4CHPonlRBfKyZumNQZSwaDv3OvwVhyY+BmoPWTNQqp 6uyN/BZb3JEM9uQ8ilOHD/ffhaa06JbhF9Rl7uNPxJIEnZ5Y+23EgaOUnwQd+Hm/g5jX PcxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9PJzaK4pmV0IXYmlEfR7X3NK/t8tcHtAQAKaYYXsvGQ=; b=IPPZPmP9TMOtpGg/xr8WthRAjQ09uX/KC5ETtL+QhESc3VNp385lkjqndqKQPGTDIY CmphY0gOyHBJQdrIZxxjQNj4xDtk4XEHsAW7JBe+5V1bTa3FFkUewqMyxls3LI+jtaP3 Z2Rp4enkMe7F4Kjn7iupR21R4UCfyQFHGXt7wRRemYhSGcEJRG0/3KiUVTiI7N1+Haw9 uDYkwG47JpdAHb6nAAonknrRAMAbVVziI08nCZnL83DQsUpdV+GvC7g9ffb4mj2Cx64d 47NPtTobWuvXQT05X+GTW3Vc1BwtKDG1lmFXmNsRmN0LI/RVtjGD5ldyQ1bjJQ37gWIs c6BA== X-Gm-Message-State: AMCzsaXwo5aTI4LvfKMCzhvJhmof5JZIOjOfEipYLwt655OdkDD6aLXp 4mtaDGSMR2r8ou+XK8tHy4ZXblAU X-Google-Smtp-Source: ABhQp+Qh81kuz6WL8fVR0nq7oq/Xuh2qQGetcanAweLuJoaGQrcJzg59KAKKLvi/q0FJzprXohdkGw== X-Received: by 10.98.202.74 with SMTP id n71mr8475988pfg.202.1509730698440; Fri, 03 Nov 2017 10:38:18 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id p17sm10481055pgc.66.2017.11.03.10.38.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Nov 2017 10:38:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Dino Farinacci In-Reply-To: Date: Fri, 3 Nov 2017 10:38:17 -0700 Cc: lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Albert Lopez X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [lisp] draft-ermagan-lisp-nat-traversal question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 03 Nov 2017 17:38:20 -0000 The TTL in the Map-Register is the TTL returned in Map-Replies. So it is = the expiry time for a map-cache entry. Note it is the =E2=80=9CRecord = TTL=E2=80=9D in the EID-record which both appear in Map-Register and = Map-Reply messages. Dino > On Nov 3, 2017, at 1:35 AM, Albert L=C3=B3pez = wrote: >=20 > Dear all, >=20 > In section 5.3 of the draft draft-ermagan-lisp-nat-traversal which = describe the RTR processing, it says that when the RTR receive and = ECM-ed Map Notify, once it is validated, it changes the state of the = associated map-cache entry to verified for the duration of the Map = Register TTL. What does it mean by Map Register TTL? it means the TTL = of the record of the Map Register or it is the same concept of the Map = Register TTL of the Map Server which is 3 minutes? If I understand = correctly, if we don't receive more Encap Map Register / Map Notify to = renew this verified period, the map-cache entry of the RTR expires, at = least the locator of the map-cache entry associated with the Encap Map = register. >=20 > "Once the authenticity of the message is verified, > RTR can confirm that the Map-Register message for the ETR with the > matching xTR-ID was accepted by the Map-Server. At this point the > RTR can change the state of the associated map-cache entry to > verified for the duration of the Map-Register TTL" >=20 > Thank you in advance. >=20 > Albert L=C3=B3pez >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Nov 3 10:53:18 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9C513FF0F; Fri, 3 Nov 2017 10:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 Zdsrjj_Hox1d; Fri, 3 Nov 2017 10:53:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3344C13FF0E; Fri, 3 Nov 2017 10:53:03 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0E70058C4B2; Fri, 3 Nov 2017 18:52:59 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id E996CB0D084; Fri, 3 Nov 2017 18:52:58 +0100 (CET) Date: Fri, 3 Nov 2017 18:52:58 +0100 From: Toerless Eckert To: Tom Herbert Cc: Christian Huitema , Padma Pillay-Esnault , "ietf@ietf.org" , "ideas@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Message-ID: <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 03 Nov 2017 17:53:05 -0000 Thanks, Tom, inline On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote: > Toerless, > > That maybe true, but personal devices, such as smart phones and cars > that are associated with individuals, are hardly going away anytime > soon. How addresses are assigned to these devices has a material > impact on individual privacy. Even right now there are two long > threads on v6ops right now that are delving precisely into privacy of > IPv6 addresses that may be relevant. This includes discussion about > CGNAT and efforts by some governments to illegalize it because the > privacy it gives is too strong for law enforcement. Sure. All i was saying is that we should not dismiss solutions if they do not help to improve privacy. It reminds me of the congestion control principles and the fact that a lot of money is made with video in controlled networks without congestion control. As in: "Sorry, we couldn't build a great solution for sensor devices in manufacturing plants because those solutions wouldn't pass the privacy bar". I am not even aware if we have good characterizations of solutions vs. privacy like IMHO we have for congestion control, but of course its a more complex topic. (IMHO: lot more cases IMHO to distinguish). That being said, i would of course love to see that we leverage IDEAs to also create options that (could) enhance privacy, i just don't think that we will make a lot of progress if we can not do this work in a WG but if all the complex issues have to be resolved on pre-wg mailing lists before even charters are accepted. This is part of whats wrong with the IETF if i may say so. For example, Christian contested that long lived identifiers help to improve privacy (for device = individual case) and those arguments about privacy had the IESG turn their opinions. IMHO: The long-lived identifiers are meant to be functionally limited. You do increase the bar of identifying an individual when you do this because the web applications need to do more work to correlate application layer information across multiple functional identifiers. So, how & where do we even create a common understanding about the qualitative and quantitative privacy benefits of technology options if not in a WG. Functional identifiers just being one example. Even more fundamentally: If each individual application layer function requires authentication via e.g.: government, google or facebook ID, and all those web services are free to correlate their information in the backend, any network layer privacy work is just like growing organic tobacco. Which is why i really would like to know what the state of requirements/BCP etc. is re. privacy at app layer in the IETF, because without that knowledge, i can only define the privacy benefits of a network layer enhancement under the ASSUMPTION of particular application behavior. My impression of IETF policy is "you have to trust the web services provider (not to share/correlate/abuse user/client information)" and in the same breath "you can not trust the network service provider (to behave in the same way)". Would love to get pointed to documents proving this impression to be wrong. Especially the option that there can be network providers that users may want to trust more than arbitrary web services providers should IMHO be acknowledged. And thats definitely an option i think is worthwhile to build solutions against. Cheers Toerless > Tom From nobody Sat Nov 4 09:34:25 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B42A13FB7D for ; Sat, 4 Nov 2017 09:34:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 Re-3rrVk6AI2 for ; Sat, 4 Nov 2017 09:34:11 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 D966B13FB8E for ; Sat, 4 Nov 2017 09:34:08 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id n66so1979235qki.8 for ; Sat, 04 Nov 2017 09:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N2cJJmGPQB3YYPqVgzmP/XInW/7BxdRmLIQi8CY91Pg=; b=SLVMLd1oUhfPI8BfXMj5rbfed6hDXq6K4OR06KM95pN1s8sRFVay6VEUu3Eknxkenb nEcdMNlogGqHmeEGA3lu/Lbru7Csbu0m4jjrERRBAStnd4yWFmhgARpNTFx65+7adnnD Y+iemAysANswGEvnUCNRo8NtcUxwkLkgG2liqPH+fhtUXJ//dQttkxSZBfvH8dLXypvk jN051OnphMpC/0WdXjYUGsFcTo7iSuKSD5lQuYXJhGvPqCPneYdDC/T+MsqzVlgFRwVx KXbNca05EGG46tXUUy3s46pl0wkTcWfHZxe6bQGZK9/OVrLgMGjxsjyU6vgT8gaOj318 2urg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N2cJJmGPQB3YYPqVgzmP/XInW/7BxdRmLIQi8CY91Pg=; b=X1JqaDd7+MY6vhogcE16ZHTM5f+RCaF7F+k3azjUOzMMsDXyPOnIWF47vXk++a+mHJ tipdm0FJinHiuO9s22VkZDV2z/uzx90GChc9ZExDut0u3a4cy1PDaUdmehivB01vppeZ tQNpipYnSIfmYU2gvf6w5GGfg3a31rfQVgsP9/yoyXc+TA5VTwNheqHFiRQLyCULQdmS oC6/aI8eTbt1l48VNObU23sCX364G9gpsciJvBjCxlYcXyVa54mHon01MQHjrL8nUyUF nSLAXZJ+WdV37/YwgDxGIL9jUfs05U/QzbN7eQQrt9lQyEgbXn2tQAAyYdPT9sEMSR7o WUow== X-Gm-Message-State: AJaThX6tfRhZFB6uWEgyvNI82uumUd5YsORs+COVeW8Rf4ZVRgrCUc7a C50+gpjyyyZ2paH2x+JztuTO+oQyHxL+GiC6kUCdNg== X-Google-Smtp-Source: ABhQp+T6kd5WKzMvnG7nDu0/M2o48uS3IEAY6PhlJ7ZYBWKFNSM1x/PE0uCmDI0e8xl2J4KRyHvmd9jjUPl/5+tz73o= X-Received: by 10.55.148.70 with SMTP id w67mr15088843qkd.102.1509813247785; Sat, 04 Nov 2017 09:34:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Sat, 4 Nov 2017 09:34:07 -0700 (PDT) In-Reply-To: <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> From: Tom Herbert Date: Sat, 4 Nov 2017 09:34:07 -0700 Message-ID: To: Toerless Eckert Cc: Christian Huitema , Padma Pillay-Esnault , "ietf@ietf.org" , "ideas@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 04 Nov 2017 16:34:12 -0000 On Fri, Nov 3, 2017 at 10:52 AM, Toerless Eckert wrote: > Thanks, Tom, inline > > On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote: >> Toerless, >> >> That maybe true, but personal devices, such as smart phones and cars >> that are associated with individuals, are hardly going away anytime >> soon. How addresses are assigned to these devices has a material >> impact on individual privacy. Even right now there are two long >> threads on v6ops right now that are delving precisely into privacy of >> IPv6 addresses that may be relevant. This includes discussion about >> CGNAT and efforts by some governments to illegalize it because the >> privacy it gives is too strong for law enforcement. > > Sure. All i was saying is that we should not dismiss solutions if they > do not help to improve privacy. It reminds me of the congestion control > principles and the fact that a lot of money is made with video in > controlled networks without congestion control. As in: "Sorry, we couldn't > build a great solution for sensor devices in manufacturing plants because > those solutions wouldn't pass the privacy bar". > > I am not even aware if we have good characterizations of solutions > vs. privacy like IMHO we have for congestion control, but of course its > a more complex topic. (IMHO: lot more cases IMHO to distinguish). > > That being said, i would of course love to see that we leverage IDEAs to > also create options that (could) enhance privacy, i just don't think that > we will make a lot of progress if we can not do this work in a WG but > if all the complex issues have to be resolved on pre-wg mailing lists before > even charters are accepted. This is part of whats wrong with the IETF > if i may say so. > > For example, Christian contested that long lived identifiers help to > improve privacy (for device = individual case) and those arguments about > privacy had the IESG turn their opinions. > > IMHO: The long-lived identifiers are meant to be functionally limited. You do > increase the bar of identifying an individual when you do this because the > web applications need to do more work to correlate application layer > information across multiple functional identifiers. > > So, how & where do we even create a common understanding about the qualitative and > quantitative privacy benefits of technology options if not in a WG. Functional > identifiers just being one example. > > Even more fundamentally: If each individual application layer function requires > authentication via e.g.: government, google or facebook ID, and all those > web services are free to correlate their information in the backend, any > network layer privacy work is just like growing organic tobacco. > > Which is why i really would like to know what the state of requirements/BCP etc. > is re. privacy at app layer in the IETF, because without that knowledge, i can > only define the privacy benefits of a network layer enhancement under the > ASSUMPTION of particular application behavior. > I don't think that's true. Privacy enhancements at the network layer are needed to prevent inferences of PII by third party using just network layer information that might be passively intercepted. Knowledge of the application is not needed. In the base case scenario, it should be impossible for a random intermediate node in the Internet to determine who is communicating to whom (identity), where someone is communicating from (location), and what they are saying (content). > My impression of IETF policy is "you have to trust the web services > provider (not to share/correlate/abuse user/client information)" and in the > same breath "you can not trust the network service provider (to behave in the > same way)". Would love to get pointed to documents proving this impression to > be wrong. Especially the option that there can be network providers that > users may want to trust more than arbitrary web services providers should IMHO > be acknowledged. And thats definitely an option i think is worthwhile to build > solutions against. > I doubt there's any IETF RFC or BCP stating whom were required to trust as a MUST. Personally, I don't inherently trust web service providers, network service providers, government, vendors, or really anyone else involved in communications (including myself :-) ). Some trust is needed out of necessity to do anything useful, but we should always be searching for ways to further minimize that. A good example is turning up the TLS on the Internet; this eliminated the need to trust the network with our plaintext. I believe a similar thing will happen with addressing, we'll figure out how to eliminate all PII from addresses so that we don't have to trust the network to not be making inferences that breaks privacy. Tom From nobody Sat Nov 4 14:37:36 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490D413FB06; Sat, 4 Nov 2017 14:37:28 -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 autolearn_force=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 K6xc3ak-BtB0; Sat, 4 Nov 2017 14:37:27 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12AA313FADA; Sat, 4 Nov 2017 14:37:26 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eB67z-0005ws-Fk; Sat, 04 Nov 2017 17:37:19 -0400 Date: Sat, 04 Nov 2017 17:37:12 -0400 From: John C Klensin To: Tom Herbert , Toerless Eckert cc: ideas@ietf.org, "lisp@ietf.org list" , Christian Huitema , Dino Farinacci , ietf@ietf.org Message-ID: In-Reply-To: References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 04 Nov 2017 21:37:28 -0000 --On Saturday, November 4, 2017 09:34 -0700 Tom Herbert wrote: >... > A good example > is turning up the TLS on the Internet; this eliminated the > need to trust the network with our plaintext. And, for many people, replaces it with the need to trust firewall and security appliance providers who have concluded that they need to intercept and decrypt traffic in order to identify malware and other undesirable traffic. At least in principle, one does get to choose which vendor to trust and does know (by virtue of having to install special certificates) which vendor or provider is being trusted, but those options may not be meaningful for typical users. I worry with that example and several others that the IETF is not adequately distinguishing between "increasing privacy" or "preventing mass surveillance" on the one hand and forcing users into a "who do your trust" or even "who does someone trust on your behalf" shell game on the other. best, john From nobody Mon Nov 6 00:58:56 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89913FB56 for ; Mon, 6 Nov 2017 00:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Vth14JPZcT2S for ; Mon, 6 Nov 2017 00:58:45 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id D4A1D13FADF for ; Mon, 6 Nov 2017 00:58:44 -0800 (PST) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vA68wgtg022269; Mon, 6 Nov 2017 09:58:42 +0100 Received: from [147.83.35.39] (sirius.ac.upc.es [147.83.35.39]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 70406325; Mon, 6 Nov 2017 09:58:37 +0100 (CET) To: Dino Farinacci Cc: lisp@ietf.org References: From: =?UTF-8?Q?Albert_L=c3=b3pez?= Message-ID: <2b946dce-7c33-5317-8f3b-9ffd2568381e@ac.upc.edu> Date: Mon, 6 Nov 2017 10:01:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] draft-ermagan-lisp-nat-traversal question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 06 Nov 2017 08:58:50 -0000 In that case, I think that It would be better if the validation time / expiration time of the locator associated with the ECM-ed Map Register & ECM-ed Map Notify is related with the periodic time of sending ECM-ed Map Registers. Usually a hole in the nat box is less than two minutes so we send periodic ECM Mag register to maintain this hole opened apart from maintaining the status in the Map Server. If we use the TTL of the record to maintain an entry in the Map Cacahe of the RTR, it is possible we maintain an entry which is no longer valid or send packets to an invalid rloc.  What do you think? Regards Albert El 03/11/17 a les 18:38, Dino Farinacci ha escrit: > The TTL in the Map-Register is the TTL returned in Map-Replies. So it is the expiry time for a map-cache entry. Note it is the “Record TTL” in the EID-record which both appear in Map-Register and Map-Reply messages. > > Dino > >> On Nov 3, 2017, at 1:35 AM, Albert López wrote: >> >> Dear all, >> >> In section 5.3 of the draft draft-ermagan-lisp-nat-traversal which describe the RTR processing, it says that when the RTR receive and ECM-ed Map Notify, once it is validated, it changes the state of the associated map-cache entry to verified for the duration of the Map Register TTL. What does it mean by Map Register TTL? it means the TTL of the record of the Map Register or it is the same concept of the Map Register TTL of the Map Server which is 3 minutes? If I understand correctly, if we don't receive more Encap Map Register / Map Notify to renew this verified period, the map-cache entry of the RTR expires, at least the locator of the map-cache entry associated with the Encap Map register. >> >> "Once the authenticity of the message is verified, >> RTR can confirm that the Map-Register message for the ETR with the >> matching xTR-ID was accepted by the Map-Server. At this point the >> RTR can change the state of the associated map-cache entry to >> verified for the duration of the Map-Register TTL" >> >> Thank you in advance. >> >> Albert López >> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Nov 6 12:02:02 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D6913FB3E; Mon, 6 Nov 2017 12:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 R41QdZQirOvw; Mon, 6 Nov 2017 12:01:51 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0450713AF75; Mon, 6 Nov 2017 12:01:50 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4950D58C4FA; Mon, 6 Nov 2017 21:01:45 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 320C6B0D0C7; Mon, 6 Nov 2017 21:01:45 +0100 (CET) Date: Mon, 6 Nov 2017 21:01:45 +0100 From: Toerless Eckert To: Tom Herbert Cc: "ideas@ietf.org" , "lisp@ietf.org list" , Christian Huitema , Dino Farinacci , Padma Pillay-Esnault , "ietf@ietf.org" Message-ID: <20171106200144.GA21604@faui40p.informatik.uni-erlangen.de> References: <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 06 Nov 2017 20:01:54 -0000 On Sat, Nov 04, 2017 at 09:34:07AM -0700, Tom Herbert wrote: > On Fri, Nov 3, 2017 at 10:52 AM, Toerless Eckert wrote: > > Thanks, Tom, inline > > > > On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote: > >> Toerless, > >> > >> That maybe true, but personal devices, such as smart phones and cars > >> that are associated with individuals, are hardly going away anytime > >> soon. How addresses are assigned to these devices has a material > >> impact on individual privacy. Even right now there are two long > >> threads on v6ops right now that are delving precisely into privacy of > >> IPv6 addresses that may be relevant. This includes discussion about > >> CGNAT and efforts by some governments to illegalize it because the > >> privacy it gives is too strong for law enforcement. > > > > Sure. All i was saying is that we should not dismiss solutions if they > > do not help to improve privacy. It reminds me of the congestion control > > principles and the fact that a lot of money is made with video in > > controlled networks without congestion control. As in: "Sorry, we couldn't > > build a great solution for sensor devices in manufacturing plants because > > those solutions wouldn't pass the privacy bar". > > > > I am not even aware if we have good characterizations of solutions > > vs. privacy like IMHO we have for congestion control, but of course its > > a more complex topic. (IMHO: lot more cases IMHO to distinguish). > > > > That being said, i would of course love to see that we leverage IDEAs to > > also create options that (could) enhance privacy, i just don't think that > > we will make a lot of progress if we can not do this work in a WG but > > if all the complex issues have to be resolved on pre-wg mailing lists before > > even charters are accepted. This is part of whats wrong with the IETF > > if i may say so. > > > > For example, Christian contested that long lived identifiers help to > > improve privacy (for device = individual case) and those arguments about > > privacy had the IESG turn their opinions. > > > > IMHO: The long-lived identifiers are meant to be functionally limited. You do > > increase the bar of identifying an individual when you do this because the > > web applications need to do more work to correlate application layer > > information across multiple functional identifiers. > > > > So, how & where do we even create a common understanding about the qualitative and > > quantitative privacy benefits of technology options if not in a WG. Functional > > identifiers just being one example. > > > > Even more fundamentally: If each individual application layer function requires > > authentication via e.g.: government, google or facebook ID, and all those > > web services are free to correlate their information in the backend, any > > network layer privacy work is just like growing organic tobacco. > > > In the base case scenario, > it should be impossible for a random intermediate node in the Internet > to determine who is communicating to whom (identity), where someone is > communicating from (location), and what they are saying (content). As an individual i agree. An individual who needs to VPN across his home gateway routers in different countries to get access to entertainment options when being abroad. But then there are so many paychecks people want to live off: There is a lot of "Internet" business riding on geo-location of locators (for better or worse). So, when it comes to IESG review of proposed work, how would a scheme be vetted wrt. those business models ? If we would take this geo-location awareness away from the network layer, i can already see how any web browser would become even more DRM encumbered, reaching down into the system to also protect reading of GPS location, and i have to run from my hotel room outside to the street to catch a GPS signal to let me watch my movie. Like those pico-cells from ATT. Likewise, service-provider want to have subscriber-IDs to be able to treat traffic from multiple subscribers fairly because there is really no good way to do this without an explicit subscriber-ID if you want real address anonymity (whether its identifier or locators). And that requirement i actually agree to as an individual even a lot more than the geoloc one. IMHO we must as the IETF be a lot more flexibility with allowing different requirements and business models, else we will just see ore and more of the counter reaction nicely summarized in http://queue.acm.org/detail.cfm?id=1242499> I like a well standardized and documented IETF solution that exposes end-user data a lot more than the secret dealings at application level that happen today. Especially when we could start thinking of how to guarantee that we provide means for the end-user/app to device what to present to whom and why. > > Which is why i really would like to know what the state of requirements/BCP etc. > > is re. privacy at app layer in the IETF, because without that knowledge, i can > > only define the privacy benefits of a network layer enhancement under the > > ASSUMPTION of particular application behavior. > > I don't think that's true. Privacy enhancements at the network layer > are needed to prevent inferences of PII by third party using just > network layer information that might be passively intercepted. > Knowledge of the application is not needed. Right. I can make life for those third parties harder by introducing what i called functional identifiers, where ultimately every type of interaction you do uses a different identifier and can therefore at network layer by passive observers not be correlated into a single identity. But introducing that type of work into network layer makes only sense if we want to assume that there is no correlation across multiple functions at the application layer anyhow. That was the example. > > My impression of IETF policy is "you have to trust the web services > > provider (not to share/correlate/abuse user/client information)" and in the > > same breath "you can not trust the network service provider (to behave in the > > same way)". Would love to get pointed to documents proving this impression to > > be wrong. Especially the option that there can be network providers that > > users may want to trust more than arbitrary web services providers should IMHO > > be acknowledged. And thats definitely an option i think is worthwhile to build > > solutions against. > > > I doubt there's any IETF RFC or BCP stating whom were required to > trust as a MUST. Personally, I don't inherently trust web service > providers, network service providers, government, vendors, or really > anyone else involved in communications (including myself :-) ). +1 > Some trust is needed out of necessity to do anything useful, but we should > always be searching for ways to further minimize that. The more you want to do across the Internet, the more you need to trust those web services providers with your data. The real challenge is create more transparency in those web service providers to allow for more verification of what they do. And why the heck should i not be able to get better services from network service providers ? What they would need to know for interesting services is so much less than what app providers are collecting about me. Why would i oppose a subscriber ID so a network service provider can provide fairness better ? > A good example > is turning up the TLS on the Internet; this eliminated the need to > trust the network with our plaintext. The problem with TLS is that it is evolving in a way that will again lead to a weapons race. For example the fact that 1.3 removed totally the option for no-encryption. Therefore eliminating the option of apps who need observable, authenticated traffic to rely on just TLS. Or the fact that it mandates encryption of certs so you can not even authenticate the identify of a web service (not the client). There are good reasons why you want to have this profile, but there are also good reason why you want othre profiles, and those get consistently shot down in the IETF. And thats bad politics. > I believe a similar thing will > happen with addressing, we'll figure out how to eliminate all PII from > addresses so that we don't have to trust the network to not be making > inferences that breaks privacy. The VPN service providers to access netflix abroad are an interesting data point in this battle. Obviously i need to trust them to keep my identify "private". Netflix did recently block a lot of them. What would happen if ever more subscriber would use SPs offering that type of locators. Would the OOT provider like hulu/netflix wake up and relax geo-locking Or do we get the GPS geoloc as i fear ? In any case: a) if we want to get more addressing privacy, it would be good to discuss the expectable outcomes of that, and b) i can not see how to create that privacy without putting more trust into some entities (such as the access==VPN SP). Cheers Toerless > Tom > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas -- --- tte@cs.fau.de From nobody Tue Nov 7 07:24:01 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB3713FFD5 for ; Tue, 7 Nov 2017 07:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Ydq_LyEaf1YN for ; Tue, 7 Nov 2017 07:23:58 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA6813FF50 for ; Tue, 7 Nov 2017 07:16:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 458935C460E for ; Tue, 7 Nov 2017 07:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1510067802; bh=fLcSn6iCcEVNi/oeVqdtGcIHcYNYyQ1chv0fGjvTE5w=; h=To:From:Subject:Date:From; b=jdCCnLBNVHLcaL73zcfLQrZYxr0JM+RfyuOBJJueny/xYRUg67kVWecwJh6DrZsvV 9mPQWr+XY/pSdGU4PJVgv8+FsZd4h8X+l3GeQe71yIMTDxzt4ldKiz+Nyu4n303Qve Vk724U/MfFpX8BVWODNpgAwIA/QNkTNDBPTFddGY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 E15D35C4644 for ; Tue, 7 Nov 2017 07:16:41 -0800 (PST) To: "lisp@ietf.org" From: "Joel M. Halpern" Message-ID: <0302bfce-ac14-8322-2d71-c2dba4307a7f@joelhalpern.com> Date: Tue, 7 Nov 2017 10:16:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] presentations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 07 Nov 2017 15:23:59 -0000 Please send your presentations to the chairs and WG secretaries. I know we are not meeting till Friday, but it would still be good to get them in early. Also, please make sure you have slide numbers on your slides. It helps with many things. Thank you, Joel From nobody Tue Nov 7 10:14:40 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9409133053; Tue, 7 Nov 2017 10:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 KJWoC2QxwWM1; Tue, 7 Nov 2017 10:14:31 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC35126B6D; Tue, 7 Nov 2017 10:14:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8F5C57E0025; Tue, 7 Nov 2017 10:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1510078470; bh=IqXSaKeVlDiv8motqEv7BYbNRsLYBotxDREMBzYiSFI=; h=Subject:References:To:From:Date:In-Reply-To:From; b=H+z17EjOOBOQN+WAkSqHZon605YVgwGqPU99Sgu3q7O0Jj7Xd/i6bHnB+dxcNer5N ZjAmLu9FHDm30Ryl42KZJABSuozrImPzeGEPwWGHsAvxffkNsp0zwBtUPpuRGwpKCm 11lk5xtgokV3Ro/Eh2RB887bNyTFkwcGeIOawJKo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 1BCF27E003A; Tue, 7 Nov 2017 10:14:30 -0800 (PST) References: <151006354277.18561.585049119013667650.idtracker@ietfa.amsl.com> To: "lisp@ietf.org" , "sfc@ietf.org" From: Joel Halpern X-Forwarded-Message-Id: <151006354277.18561.585049119013667650.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 7 Nov 2017 13:14:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <151006354277.18561.585049119013667650.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Fwd: NomCom Second Call for Feedback and Office Hours: IETF 100 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 07 Nov 2017 18:14:33 -0000 (Forwarding information sent to ietf list by nomcom chair.) All - Please consider entering your feedback for the 2017-2018 NomCom early this week. We'll be doing on-site interviews in Singapore and would appreciate your inputs as we sort through our options. We have nominees to consider for the the IESG, IAB, and IAOC this cycle: https://datatracker.ietf.org/nomcom/2017/feedback/ If you have general feedback areas or positions please send email to: nomcom-2017 at ietf dot org On-site in Singapore you can also give your feedback directly to the NomCom either by talking with any NomCom Member (identified with an orange dot on their badge). The full list of members can be found here: https://datatracker.ietf.org/nomcom/2017/ or drop by during our open office hours: MONDAY 11/13/17 1515-1540 Partial overlap with the beverage and snack break NomCom Office Hour: Fullerton Room TUESDAY 11/14/167 1515-1540 Partial overlap with the beverage and snack break NomCom Office Hour: Fullerton Room WEDNESDAY 11/15/17 1200-1335 Lunch break 1515-1540 Partial overlap with the beverage and snack break NomCom Office Hours: Fullerton Room THURSDAY 11/16/17 1250-1335 Lunch break 1515-1540 Partial overlap with the beverage and snack break NomCom Office Hours: Fullerton Room Thanks - Peter Yee NomCom Chair 2017-2018 peter at akayla dot com (preferred if you have SPF problems with my MTA) nomcom-chair-2017 at ietf dot org From nobody Wed Nov 8 12:33:48 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68070129BCF for ; Wed, 8 Nov 2017 12:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 3ynsovNasIt2 for ; Wed, 8 Nov 2017 12:33:45 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844C4129BC5 for ; Wed, 8 Nov 2017 12:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3260; q=dns/txt; s=iport; t=1510173225; x=1511382825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=at2G4FzsiBPxtR9EipvQYoksX4q8Y7AwVyotKMkqGMQ=; b=Nfr6zirzjYe4WtZrcahF4KJk8L9MH16qzelwAAKYVw95P/09AqCZ4cFY KpDQV5VMzCW1mMJiRTMQjOsC5K4x/GFljVRMCmheWfKyLn+jPiU7bPL4K vNwnYbepK0U8i3BOuQxb5yYSf97+qnD3r3faa1Hq4s04PpZ6Dq23ySkhw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAABraQNa/5hdJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDNGRuJweOFY8lgXyWTBCCAQoYC4UYAoR8PxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUfAQEBAwEBbAsQAgEIGC4nCyUCBAENBYojEKwnixsBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYMwggeBVIFpgh2BDYRdIhaFeAWSLoZciRAClHyTOJV0AhEZAYE?= =?us-ascii?q?4AR84gXF6FUmCZIJcHIEoP3eJRgIFIAeBBYERAQEB?= X-IronPort-AV: E=Sophos;i="5.44,365,1505779200"; d="scan'208";a="321783769" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2017 20:33:44 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA8KXig9025895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Nov 2017 20:33:44 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 8 Nov 2017 14:33:44 -0600 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.1320.000; Wed, 8 Nov 2017 14:33:44 -0600 From: "Vina Ermagan (vermagan)" To: =?iso-8859-1?Q?Albert_L=F3pez?= , Dino Farinacci CC: "lisp@ietf.org" Thread-Topic: [lisp] draft-ermagan-lisp-nat-traversal question Thread-Index: AQHTVH7CnNCB5I/GnkyA06tVaRWOBKMDP+SAgAQ3ZgCAA1/rgA== Date: Wed, 8 Nov 2017 20:33:44 +0000 Message-ID: References: <2b946dce-7c33-5317-8f3b-9ffd2568381e@ac.upc.edu> In-Reply-To: <2b946dce-7c33-5317-8f3b-9ffd2568381e@ac.upc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.71.191] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <405A9447C00DEF40AC681117C4108532@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-ermagan-lisp-nat-traversal question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 20:33:47 -0000 Hi Albert, =B3Map Register TTL=B2 in the referenced paragraph is indeed the TTL for wh= ich a Map Register stays valid in a Map Server. Suggested time in the RFC for periodic Map Registers is 1 minute. And MS will expire the registration after 3 minutes if it does not receive a renewal. So this TTL in RTR should be set no larger than 3 minutes, and no smaller than 1 minute. Unfortunately NAPT devices don=B9t have a standard TTL for expiring their address associations; some use 2 minutes as the threshold. So the 3 minute recommendation for expiring a Map Register seems suitable here. Hope this clarifies it. Best, Vina On 11/6/17, 1:01 AM, "lisp on behalf of Albert L=F3pez" wrote: >In that case, I think that It would be better if the validation time / >expiration time of the locator associated with the ECM-ed Map Register & >ECM-ed Map Notify is related with the periodic time of sending ECM-ed >Map Registers. >Usually a hole in the nat box is less than two minutes so we send >periodic ECM Mag register to maintain this hole opened apart from >maintaining the status in the Map Server. If we use the TTL of the >record to maintain an entry in the Map Cacahe of the RTR, it is possible >we maintain an entry which is no longer valid or send packets to an >invalid rloc. What do you think? > >Regards > >Albert > >El 03/11/17 a les 18:38, Dino Farinacci ha escrit: >> The TTL in the Map-Register is the TTL returned in Map-Replies. So it >>is the expiry time for a map-cache entry. Note it is the =B3Record TTL=B2= in >>the EID-record which both appear in Map-Register and Map-Reply messages. >> >> Dino >> >>> On Nov 3, 2017, at 1:35 AM, Albert L=F3pez wrote: >>> >>> Dear all, >>> >>> In section 5.3 of the draft draft-ermagan-lisp-nat-traversal which >>>describe the RTR processing, it says that when the RTR receive and >>>ECM-ed Map Notify, once it is validated, it changes the state of the >>>associated map-cache entry to verified for the duration of the Map >>>Register TTL. What does it mean by Map Register TTL? it means the TTL >>>of the record of the Map Register or it is the same concept of the Map >>>Register TTL of the Map Server which is 3 minutes? If I understand >>>correctly, if we don't receive more Encap Map Register / Map Notify to >>>renew this verified period, the map-cache entry of the RTR expires, at >>>least the locator of the map-cache entry associated with the Encap Map >>>register. >>> >>> "Once the authenticity of the message is verified, >>> RTR can confirm that the Map-Register message for the ETR with the >>> matching xTR-ID was accepted by the Map-Server. At this point the >>> RTR can change the state of the associated map-cache entry to >>> verified for the duration of the Map-Register TTL" >>> >>> Thank you in advance. >>> >>> Albert L=F3pez >>> >>> >>> _______________________________________________ >>> 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 Nov 9 00:03:45 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938BE12EC8B for ; Thu, 9 Nov 2017 00:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 PcYGdlONZgb4 for ; Thu, 9 Nov 2017 00:03:39 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 893FD12EC2D for ; Thu, 9 Nov 2017 00:03:38 -0800 (PST) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vA983XTO028382; Thu, 9 Nov 2017 09:03:33 +0100 Received: from [147.83.35.39] (sirius.ac.upc.es [147.83.35.39]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 66954F96; Thu, 9 Nov 2017 09:03:28 +0100 (CET) To: "Vina Ermagan (vermagan)" , Dino Farinacci Cc: "lisp@ietf.org" References: <2b946dce-7c33-5317-8f3b-9ffd2568381e@ac.upc.edu> From: =?UTF-8?Q?Albert_L=c3=b3pez?= Message-ID: <5e54af9e-c7cb-6a27-5ad8-922e687ab401@ac.upc.edu> Date: Thu, 9 Nov 2017 09:06:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] draft-ermagan-lisp-nat-traversal question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 09 Nov 2017 08:03:42 -0000 Hi Vina, It make sense for me. Thank you very much. Albert El 08/11/17 a les 21:33, Vina Ermagan (vermagan) ha escrit: > Hi Albert, > > ³Map Register TTL² in the referenced paragraph is indeed the TTL for which > a Map Register stays valid in a Map Server. Suggested time in the RFC for > periodic Map Registers is 1 minute. And MS will expire the registration > after 3 minutes if it does not receive a renewal. So this TTL in RTR > should be set no larger than 3 minutes, and no smaller than 1 minute. > Unfortunately NAPT devices don¹t have a standard TTL for expiring their > address associations; some use 2 minutes as the threshold. So the 3 minute > recommendation for expiring a Map Register seems suitable here. > > Hope this clarifies it. > > Best, > Vina > > > On 11/6/17, 1:01 AM, "lisp on behalf of Albert López" > wrote: > >> In that case, I think that It would be better if the validation time / >> expiration time of the locator associated with the ECM-ed Map Register & >> ECM-ed Map Notify is related with the periodic time of sending ECM-ed >> Map Registers. >> Usually a hole in the nat box is less than two minutes so we send >> periodic ECM Mag register to maintain this hole opened apart from >> maintaining the status in the Map Server. If we use the TTL of the >> record to maintain an entry in the Map Cacahe of the RTR, it is possible >> we maintain an entry which is no longer valid or send packets to an >> invalid rloc. What do you think? >> >> Regards >> >> Albert >> >> El 03/11/17 a les 18:38, Dino Farinacci ha escrit: >>> The TTL in the Map-Register is the TTL returned in Map-Replies. So it >>> is the expiry time for a map-cache entry. Note it is the ³Record TTL² in >>> the EID-record which both appear in Map-Register and Map-Reply messages. >>> >>> Dino >>> >>>> On Nov 3, 2017, at 1:35 AM, Albert López wrote: >>>> >>>> Dear all, >>>> >>>> In section 5.3 of the draft draft-ermagan-lisp-nat-traversal which >>>> describe the RTR processing, it says that when the RTR receive and >>>> ECM-ed Map Notify, once it is validated, it changes the state of the >>>> associated map-cache entry to verified for the duration of the Map >>>> Register TTL. What does it mean by Map Register TTL? it means the TTL >>>> of the record of the Map Register or it is the same concept of the Map >>>> Register TTL of the Map Server which is 3 minutes? If I understand >>>> correctly, if we don't receive more Encap Map Register / Map Notify to >>>> renew this verified period, the map-cache entry of the RTR expires, at >>>> least the locator of the map-cache entry associated with the Encap Map >>>> register. >>>> >>>> "Once the authenticity of the message is verified, >>>> RTR can confirm that the Map-Register message for the ETR with the >>>> matching xTR-ID was accepted by the Map-Server. At this point the >>>> RTR can change the state of the associated map-cache entry to >>>> verified for the duration of the Map-Register TTL" >>>> >>>> Thank you in advance. >>>> >>>> Albert López >>>> >>>> >>>> _______________________________________________ >>>> 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 Fri Nov 10 01:12:34 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F4C129C26 for ; Fri, 10 Nov 2017 01:12:32 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 7EKBurx1VZl5 for ; Fri, 10 Nov 2017 01:12:28 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 64289129432 for ; Fri, 10 Nov 2017 01:12:28 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id y9so8001771wrb.2 for ; Fri, 10 Nov 2017 01:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kH3/hJ8mm0o1DzK6Rui/ZkE7Wlk69CduUz3xH+GPGJ8=; b=wF91x+cNHhG5r57Z7GPgPufdXNsu/dWZj/Uwq2H3L+iZozSoVo0p0xXLmvtayUSP8a LqnRQemeuAuuJjVc5IOJ77dFsX3rxl/x7HWdTWuWB2NWYkJoWJfeE8n7frL03ihmZ1Tg SatGiYRCikaaJQe39VAkji4lNZjdvifctxJnSQCagSrf0MtOp5FkTdtB1lTe6bq/5BGj xyV2t5Yw1XA+Dk030nyjKFMlawVkXJGEp8rHjU+i5XnniqQggDKeytC2cR7bI8l2SGOG 68TAMBrof6+euHRwIUmMdc8ulPaWlKsy//q+IcWewGjw1+NNQy3P240RFFwzPcPde0CT mq5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kH3/hJ8mm0o1DzK6Rui/ZkE7Wlk69CduUz3xH+GPGJ8=; b=J4OUmjvNTZUHIvip3+8SLyzJAX2IfaIPMZIIaWfP+tebu/XBxkgYOqar8EbrE8kYB1 ALarztOkDDFpOaLiKPp3/tuc0LxqxzYPgVDFyPYm7ySECt3Z8e96BauxEAEQU1l8ISZB RZk63yWkI0tHxEnP+e+kuP2B6WDFs/6QGAzswx2CnuN1upnbBYNJFzfZo5dNmzIiKjpa yfGGwgxtNyCAQ89qwswlnS+SB0IRNRa6Lz58jGj56RU3BqeFUVStQOQh8TSq47p/AKjq X8N918bJ++MDdp0CRsO/3vGWiu77mjPX54cboPk4MPOMnkvQ1lKePer8W+tK8Hwq8PQh ZbCg== X-Gm-Message-State: AJaThX6c1BhCULtNuHVm/HntpP+wS+rdtEfSDWPXgkZNoNWZKg+9NLrK ciecHlSeR54OMcYC/1DJ+D+A1qTXMpQ= X-Google-Smtp-Source: ABhQp+RQDP89izGcXfyNeXmhpv7pNabeAJgtl/9GDQttcVk7HitCJOyZkF51UQ4TdalE4G9cAs9qnw== X-Received: by 10.223.136.51 with SMTP id d48mr2683765wrd.150.1510305146404; Fri, 10 Nov 2017 01:12:26 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:dd84:ed14:d1dd:fbd7? ([2001:660:330f:a4:dd84:ed14:d1dd:fbd7]) by smtp.gmail.com with ESMTPSA id 34sm3384035wra.39.2017.11.10.01.12.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 01:12:25 -0800 (PST) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_79C132B8-F632-4380-ACF9-D7970AE22883" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Fri, 10 Nov 2017 10:12:22 +0100 In-Reply-To: <19B94AC7-74AE-4A81-BE52-7EC0C45AB250@gigix.net> Cc: lisp-chairs@ietf.org To: "lisp@ietf.org list" References: <19B94AC7-74AE-4A81-BE52-7EC0C45AB250@gigix.net> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [lisp] 100th IETF LISP WG Please send slides X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 10 Nov 2017 09:12:32 -0000 --Apple-Mail=_79C132B8-F632-4380-ACF9-D7970AE22883 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To all presenters of the meeting, Thanks to who already sent their slides For the other please send your slides to the chairs = > by Wednesday = evening at latest. So that we have time to upload everything on the material page.=20 Have a safe trip to Singapore ciao L. > On 31 Oct 2017, at 14:23, Luigi Iannone wrote: >=20 > Hi All, >=20 > The preliminary agenda for our next meeting is now online: = https://datatracker.ietf.org/doc/agenda-100-lisp/ > (also copied hereafter) >=20 > We have a pretty packed schedule, thank you all for the interest. > Unfortunately this means that we had to adjust a bit the requested = slots so to give time to all the people presenters. >=20 > Please have a look and send an email, if you spot any error, mistake, = or missing item. >=20 > Ciao >=20 > L. >=20 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >=20 > CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) > Luigi Iannone ( ggx AT gigix.net ) >=20 > SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com ) > Padma Pillay-Esnault ( padma.ietf AT gmail.com ) >=20 >=20 > AGENDA >=20 > Session 1/1 (120 Minutes) > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > Friday, November 17, 2017 > 9:30 - 11:30, Morning Session I, 120 Minutes > Room: Olivia >=20 > - Administration > Halpern/Iannone > - Blue Sheets > - Agenda Bashing > - Status reports for WG drafts > 5 Minutes (Cumulative Time: 5 Minutes) >=20 >=20 >=20 > o WG Items >=20 > - Update on LISP 6830bis & 6833bis > draft-ietf-lisp-6830bis > draft-ietf-lisp-6833bis > (To be extended if needed) > 15 Minutes (Cumulative Time: 20 Minutes) > Dino Farinacci & Albert Cabellos >=20 > - LISP-Security - draft-ietf-lisp-sec-14.txt > 5 minutes (Cumulative Time: 25 Minutes) > Fabio Maino >=20 > - LISP YANG Model - draft-ietf-lisp-yang-05 > 5 minutes (Cumulative Time: 30 Minutes) > Reshad Rahman >=20 >=20 > o Non WG Items >=20 > - LISP Map Server Reliable Transport - = draft-kouvelas-lisp-map-server-reliable-transport-04.txt > 10 minutes (Cumulative Time: 40 Minutes) > Reshad Rahman >=20 > - Ground-based LISP for the Aeronautical Telecommunications Network > 15 minutes (Cumulative Time: 55 Minutes) > Reshad Rahmen >=20 > - LISP Control-Plane ECDSA Authentication and Authorization - = draft-farinacci-lisp-ecdsa-auth-00.txt > 10 minutes (Cumulative Time: 65 Minutes) > Dino Farinacci >=20 > - LISP for the Mobile Network - = draft-farinacci-lisp-mobile-network-00.txt > 10 minutes (Cumulative Time: 75 Minutes) > Dino Farinacci >=20 > - Publish/Subscribe Functionality for LISP - = draft-rodrigueznatal-lisp-pubsub-01.txt > 15 minutes (Cumulative Time: 90 Minutes) > Fabio Maino >=20 > - LISP Traffic Engineering > 15 minutes (Cumulative Time: 105 Minutes) > Yan Filyurin >=20 > - LISP on Android & iOS > 10 minutes (Cumulative Time: 115 Minutes) > Albert Cabellos >=20 > - VXLAN GPE - draft-brockners-ioam-vxlan-gpe-00.txt > 5 minutes (Cumulative Time:120 Minutes) > Franck Brockners >=20 > - Overflow Time/ Discussion > 0 Minutes (Cumulative Time: 120 Minutes) >=20 --Apple-Mail=_79C132B8-F632-4380-ACF9-D7970AE22883 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
To all presenters of the meeting,

Thanks to = who already sent their slides

For the other please send your slides to the chairs <lisp-chairs@ietf.org> by Wednesday evening at = latest.
So that we have time to upload everything = on the material page. 

Have a safe trip to Singapore

ciao

L.

On 31 Oct 2017, at 14:23, Luigi = Iannone <ggx@gigix.net> wrote:

Hi = All,

The preliminary agenda for our next = meeting is now online: https://datatracker.ietf.org/doc/agenda-100-lisp/
(also copied hereafter)

We have = a pretty packed schedule, thank you all for the interest.
Unfortunately this means that we had to adjust a bit the = requested slots so to give time to all the people presenters.

Please have a look and send an email, if you = spot any error, mistake, or missing item.

Ciao

L.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
=             &n= bsp;  Luigi Iannone ( ggx AT gigix.net )

SECRETARY: = Wassim Haddad ( wassim.haddad AT ericsson.com )
=            =   Padma Pillay-Esnault ( padma.ietf AT gmail.com )


AGENDA

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

Friday, November 17, 2017
9:30 - = 11:30, Morning Session I, 120 Minutes
Room: Olivia

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



o WG Items

- Update on LISP 6830bis & 6833bis
=  draft-ietf-lisp-6830bis
=  draft-ietf-lisp-6833bis
 (To be extended if = needed)
15 Minutes = (Cumulative Time: 20 Minutes)
 Dino Farinacci = & Albert Cabellos

- LISP-Security - = draft-ietf-lisp-sec-14.txt
 5 minutes (Cumulative = Time: 25 Minutes)
 Fabio Maino

- LISP YANG Model - draft-ietf-lisp-yang-05
=  5 minutes (Cumulative Time: 30 Minutes)
=  Reshad Rahman


o Non WG = Items

- LISP Map Server Reliable Transport = - =        draft-kouvelas-lisp-map-server-r= eliable-transport-04.txt
 10 minutes (Cumulative = Time: 40 Minutes)
 Reshad Rahman

- Ground-based LISP for the Aeronautical Telecommunications = Network
 15 minutes (Cumulative Time: 55 Minutes)
 Reshad Rahmen

- LISP = Control-Plane ECDSA Authentication and Authorization - = draft-farinacci-lisp-ecdsa-auth-00.txt
 10 minutes = (Cumulative Time: 65 Minutes)
 Dino Farinacci

- LISP for the Mobile Network - = draft-farinacci-lisp-mobile-network-00.txt
 10 = minutes (Cumulative Time: 75 Minutes)
 Dino = Farinacci

- Publish/Subscribe Functionality = for LISP - =             &n= bsp;   draft-rodrigueznatal-lisp-pubsub-01.txt
 15 minutes (Cumulative Time: 90 Minutes)
=  Fabio Maino

- LISP Traffic = Engineering
 15 minutes (Cumulative Time: 105 = Minutes)
 Yan Filyurin

- = LISP on Android & iOS
 10 minutes (Cumulative = Time: 115 Minutes)
 Albert Cabellos

- VXLAN GPE - draft-brockners-ioam-vxlan-gpe-00.txt
 5 minutes (Cumulative Time:120 Minutes)
=  Franck Brockners

- Overflow Time/ = Discussion
 0 Minutes (Cumulative Time: 120 = Minutes)


= --Apple-Mail=_79C132B8-F632-4380-ACF9-D7970AE22883-- From nobody Sat Nov 11 16:52:09 2017 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 84EBD126C22; Sat, 11 Nov 2017 16:52:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151044792347.30864.11640003420303589205@ietfa.amsl.com> Date: Sat, 11 Nov 2017 16:52:03 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 00:52:04 -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 WG of the IETF. Title : The Locator/ID Separation Protocol (LISP) Authors : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Albert Cabellos Filename : draft-ietf-lisp-rfc6830bis-07.txt Pages : 54 Date : 2017-11-11 Abstract: This document describes the data-plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local map-cache. The map-cache is populated by the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-07 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-07 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 Nov 13 20:55:22 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EE01289C3 for ; Mon, 13 Nov 2017 20:55:21 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 5XOz7ss1KNfc for ; Mon, 13 Nov 2017 20:55:19 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 AA06A1286C7 for ; Mon, 13 Nov 2017 20:55:19 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id d28so13559253pfe.2 for ; Mon, 13 Nov 2017 20:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UhJHH+UXr6RU58VJZvkqiwMF4o6Gf4jRqpDBG7/wVec=; b=mXw8cvCExBkFhAFmGrsIJ6b7GRJj+n6Vy+A5FlCIt+cPw6QzFFMQIP675A2T9tKtnS +MVbqj6y3gUBsGJdcu9FwoqkUV9phxyFyilASjUhtwBb0j3pyn8atEASkGqXc4LWgs/0 V9buNnvGBxxmkaxSH7ceCbTcjYJLhVdl7ek9GKYt6TpAEcvc2SF7LgqHb5GDzvh65K1N NOFtDpjnzmKWjneu+jwwfal2ONKjh3Ipn+XpRWEo1fOcXP95Qa/zCDML7v3IgZcPkjaE v520QAAarW8HVrQO819cRhnrX8sqVRoowA94YblPZHoOnaqAhpq77lCBMSzYhqfW/e4F sGKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UhJHH+UXr6RU58VJZvkqiwMF4o6Gf4jRqpDBG7/wVec=; b=FVcB/lUwvNsv4HbVbh1QLtI9xo70ZNzJJyNXiYP1bF5OUsEWhiyogiDeHxoZNvIVlD 0vytz8qIgqjrmOX/v4FZ/s9xLkvoGc9DSqjBFbprrtq/GjOuywC9NSI29oSx/1FZfmJE feVZCcD5lEU4Y/3eU4nieXZids1y/bEvH2pHYguZx/gbxG0wTqzht4FQXt1nrYFgOhdt ENURg54p4ogHUh5UqWBCEqnxTw163svIUGZGWDvbSGEG3uF+QMib83Sc2wZfXnPq+M7A AnDRaF5ShKdqaSDQhwqEFOz8qHo9A8Vam/gfmnwg3tUu9vf6Ktdt/0kyp4vSqDiQpAmh E9gw== X-Gm-Message-State: AJaThX7pdLjwzjWT3qsBqPQ5rt8bSCgZY9Kv1M8yzzLC9Gji+yFpghhx sdBom+XQ1HcJETl8IARyZPTebxWlmVA= X-Google-Smtp-Source: AGs4zMbK1NFW7Zr+VX3nQdvDgrEMTXYlozglj9M8dKCOYD2KYi0eHPtgCKqDeRgSxzK21PH1+3MTnQ== X-Received: by 10.84.230.135 with SMTP id e7mr10825334plk.299.1510635318442; Mon, 13 Nov 2017 20:55:18 -0800 (PST) Received: from [10.10.12.243] ([103.26.221.241]) by smtp.gmail.com with ESMTPSA id v81sm370896pgb.77.2017.11.13.20.55.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 20:55:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Luigi Iannone In-Reply-To: <19B94AC7-74AE-4A81-BE52-7EC0C45AB250@gigix.net> Date: Tue, 14 Nov 2017 12:55:14 +0800 Cc: lisp-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <19B94AC7-74AE-4A81-BE52-7EC0C45AB250@gigix.net> To: "lisp@ietf.org list" X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] 100th IETF LISP WG Preliminary Agenda Available X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 14 Nov 2017 04:55:21 -0000 Hi All, we had request to change a bit the schedule of our agenda. Hereafter the new one (also available online) Please have a look. Ciao L. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) Luigi Iannone ( ggx AT gigix.net ) SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com ) Padma Pillay-Esnault ( padma.ietf AT gmail.com ) AGENDA Session 1/1 (120 Minutes) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Friday, November 17, 2017 9:30 - 11:30, Morning Session I, 120 Minutes Room: Olivia - Administration Halpern/Iannone - Blue Sheets - Agenda Bashing - Status reports for WG drafts 5 Minutes (Cumulative Time: 5 Minutes) o WG Items - Update on LISP 6830bis & 6833bis draft-ietf-lisp-6830bis draft-ietf-lisp-6833bis (To be extended if needed) 15 Minutes (Cumulative Time: 20 Minutes) Dino Farinacci & Albert Cabellos - LISP-Security - draft-ietf-lisp-sec-14.txt 5 minutes (Cumulative Time: 25 Minutes) Fabio Maino - LISP YANG Model - draft-ietf-lisp-yang-05 5 minutes (Cumulative Time: 30 Minutes) Reshad Rahman o Non WG Items - LISP Map Server Reliable Transport - = draft-kouvelas-lisp-map-server-reliable-transport-04.txt 10 minutes (Cumulative Time: 40 Minutes) Reshad Rahman - Ground-based LISP for the Aeronautical Telecommunications Network 15 minutes (Cumulative Time: 55 Minutes) Reshad Rahman - VXLAN GPE - draft-brockners-ioam-vxlan-gpe-00.txt 5 minutes (Cumulative Time:60 Minutes) Franck Brockners - Publish/Subscribe Functionality for LISP - = draft-rodrigueznatal-lisp-pubsub-01.txt 15 minutes (Cumulative Time: 75 Minutes) Fabio Maino - LISP Traffic Engineering 15 minutes (Cumulative Time: 90 Minutes) Yan Filyurin - LISP on Android & iOS 10 minutes (Cumulative Time: 100 Minutes) Oriol Mari - LISP Control-Plane ECDSA Authentication and Authorization - = draft-farinacci-lisp-ecdsa-auth-00.txt 10 minutes (Cumulative Time: 110 Minutes) Dino Farinacci - LISP for the Mobile Network - = draft-farinacci-lisp-mobile-network-00.txt 10 minutes (Cumulative Time: 120 Minutes) Dino Farinacci - Overflow Time/ Discussion 0 Minutes (Cumulative Time: 120 Minutes) From nobody Mon Nov 13 21:34:03 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF6B12700F for ; Mon, 13 Nov 2017 21:34:01 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 zGmG9_2mF6HW for ; Mon, 13 Nov 2017 21:33:58 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 A1C581275F4 for ; Mon, 13 Nov 2017 21:33:55 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id u132so12272520ita.0 for ; Mon, 13 Nov 2017 21:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qy0VhekGCvFHUxaxNdktN8IlE35TPEvucxTwl+nnTmg=; b=IcheKn9j1ZP1q7LApEiFqAGctPurjNg87H4ZCZGRs58eAUBCgCVq5qAb3S4tBKPXMB g+7baslgeJZqGqPgZFsOqGklrCVXeP5uMKlfZTteSrlmdx3F8VUS4FRNISrikx1/l1x1 QGXRjFQ6g775Rv6rhlnZ5AxtHI8dz+v5w+zy6ybSsc4VuS4vupBjqj8I1YqUEElvQWhy o457wD464BNDE+Neg8cVSL3I4UZ7qXGyvpN5FxH+P6rSgxGyhVyXjIRh7NUhbIkN73N2 Z8jB0hkXzVhxd4NRi4GQxlR8vz/Eo1oIEOzC05YR8dyXsWe/S24h+8IyZzU9GKW3ibvK cPvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qy0VhekGCvFHUxaxNdktN8IlE35TPEvucxTwl+nnTmg=; b=rkdmWJVzYfRJb3OUMggIHbXmclnjsmUBEka9MO7dlObN75wM0xmn6mpxqonVBCZPQZ n8hqinUXBPj23SqJoSfN+KHEvdt0SFIMhnglNppq7axNJ+TFD3vvjI9vFAlryTz2/e9s ZfFxThxjrqMjMa563PqEXGDxmcuyrWJ5wKDQXsGypKUbrvM6tPAL1nVlEaIvmZUilvuh vpqLWi1JyOQa6C2VcNfl3TKGCZ4zmfeZzh4YEfFBlwHwNC8O9cHRuMMFFFweH9Dhfptz BbwyJ8HAKdoaskU3xRk7V6rMRT0txmzjgXmUN2/anfxcBZZ14vWptVQPUTExVvVa9q6d JAvA== X-Gm-Message-State: AJaThX5IfR+twr6lJN8w0Jo1uBXbQjDKMHT+oR6MQMlIeqEs0nTmHjSc q0oHQPJmz+psYK0XI6cVZZTZ58loljE= X-Google-Smtp-Source: AGs4zMYPhflb/u2XahlS0d9g0vd+qP/XeEEF6tZ0iD10XSGkLQtMh23X0Dq/73+LMev0ZQ2YbFt28A== X-Received: by 10.36.83.202 with SMTP id n193mr13923085itb.134.1510637634442; Mon, 13 Nov 2017 21:33:54 -0800 (PST) Received: from [10.10.12.243] ([103.26.221.241]) by smtp.gmail.com with ESMTPSA id c28sm8337729iod.48.2017.11.13.21.33.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 21:33:53 -0800 (PST) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A8FCD7D4-2425-4E48-9C69-1662D3E2F591" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Tue, 14 Nov 2017 13:33:50 +0800 In-Reply-To: Cc: lisp-chairs@ietf.org To: "lisp@ietf.org list" References: <19B94AC7-74AE-4A81-BE52-7EC0C45AB250@gigix.net> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] 100th IETF LISP WG Please send slides X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 14 Nov 2017 05:34:02 -0000 --Apple-Mail=_A8FCD7D4-2425-4E48-9C69-1662D3E2F591 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just a reminder for those who did not yet send the slides. Ciao L. > On 10 Nov 2017, at 17:12, Luigi Iannone wrote: >=20 > To all presenters of the meeting, >=20 > Thanks to who already sent their slides >=20 > For the other please send your slides to the chairs = > by Wednesday = evening at latest. > So that we have time to upload everything on the material page.=20 >=20 > Have a safe trip to Singapore >=20 > ciao >=20 > L. >=20 >> On 31 Oct 2017, at 14:23, Luigi Iannone > wrote: >>=20 >> Hi All, >>=20 >> The preliminary agenda for our next meeting is now online: = https://datatracker.ietf.org/doc/agenda-100-lisp/ = >> (also copied hereafter) >>=20 >> We have a pretty packed schedule, thank you all for the interest. >> Unfortunately this means that we had to adjust a bit the requested = slots so to give time to all the people presenters. >>=20 >> Please have a look and send an email, if you spot any error, mistake, = or missing item. >>=20 >> Ciao >>=20 >> L. >>=20 >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>=20 >> CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com = ) >> Luigi Iannone ( ggx AT gigix.net ) >>=20 >> SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com = ) >> Padma Pillay-Esnault ( padma.ietf AT gmail.com = ) >>=20 >>=20 >> AGENDA >>=20 >> Session 1/1 (120 Minutes) >> =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >>=20 >> Friday, November 17, 2017 >> 9:30 - 11:30, Morning Session I, 120 Minutes >> Room: Olivia >>=20 >> - Administration >> Halpern/Iannone >> - Blue Sheets >> - Agenda Bashing >> - Status reports for WG drafts >> 5 Minutes (Cumulative Time: 5 Minutes) >>=20 >>=20 >>=20 >> o WG Items >>=20 >> - Update on LISP 6830bis & 6833bis >> draft-ietf-lisp-6830bis >> draft-ietf-lisp-6833bis >> (To be extended if needed) >> 15 Minutes (Cumulative Time: 20 Minutes) >> Dino Farinacci & Albert Cabellos >>=20 >> - LISP-Security - draft-ietf-lisp-sec-14.txt >> 5 minutes (Cumulative Time: 25 Minutes) >> Fabio Maino >>=20 >> - LISP YANG Model - draft-ietf-lisp-yang-05 >> 5 minutes (Cumulative Time: 30 Minutes) >> Reshad Rahman >>=20 >>=20 >> o Non WG Items >>=20 >> - LISP Map Server Reliable Transport - = draft-kouvelas-lisp-map-server-reliable-transport-04.txt >> 10 minutes (Cumulative Time: 40 Minutes) >> Reshad Rahman >>=20 >> - Ground-based LISP for the Aeronautical Telecommunications Network >> 15 minutes (Cumulative Time: 55 Minutes) >> Reshad Rahmen >>=20 >> - LISP Control-Plane ECDSA Authentication and Authorization - = draft-farinacci-lisp-ecdsa-auth-00.txt >> 10 minutes (Cumulative Time: 65 Minutes) >> Dino Farinacci >>=20 >> - LISP for the Mobile Network - = draft-farinacci-lisp-mobile-network-00.txt >> 10 minutes (Cumulative Time: 75 Minutes) >> Dino Farinacci >>=20 >> - Publish/Subscribe Functionality for LISP - = draft-rodrigueznatal-lisp-pubsub-01.txt >> 15 minutes (Cumulative Time: 90 Minutes) >> Fabio Maino >>=20 >> - LISP Traffic Engineering >> 15 minutes (Cumulative Time: 105 Minutes) >> Yan Filyurin >>=20 >> - LISP on Android & iOS >> 10 minutes (Cumulative Time: 115 Minutes) >> Albert Cabellos >>=20 >> - VXLAN GPE - draft-brockners-ioam-vxlan-gpe-00.txt >> 5 minutes (Cumulative Time:120 Minutes) >> Franck Brockners >>=20 >> - Overflow Time/ Discussion >> 0 Minutes (Cumulative Time: 120 Minutes) >>=20 >=20 --Apple-Mail=_A8FCD7D4-2425-4E48-9C69-1662D3E2F591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = a reminder for those who did not yet send the slides.

Ciao

L.


On 10 Nov 2017, at 17:12, Luigi Iannone <ggx@gigix.net> = wrote:

To all = presenters of the meeting,

Thanks to who already = sent their slides

For = the other please send your slides to the chairs <lisp-chairs@ietf.org> by Wednesday evening at = latest.
So that we have time to upload everything = on the material page. 

Have a safe trip to Singapore

ciao

L.

On 31 Oct 2017, at 14:23, Luigi = Iannone <ggx@gigix.net> wrote:

Hi = All,

The preliminary agenda for our next = meeting is now online: https://datatracker.ietf.org/doc/agenda-100-lisp/
(also copied hereafter)

We have = a pretty packed schedule, thank you all for the interest.
Unfortunately this means that we had to adjust a bit the = requested slots so to give time to all the people presenters.

Please have a look and send an email, if you = spot any error, mistake, or missing item.

Ciao

L.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
=             &n= bsp;  Luigi Iannone ( ggx AT gigix.net )

SECRETARY: = Wassim Haddad ( wassim.haddad AT ericsson.com )
=            =   Padma Pillay-Esnault ( padma.ietf AT gmail.com )


AGENDA

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

Friday, November 17, 2017
9:30 - = 11:30, Morning Session I, 120 Minutes
Room: Olivia

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



o WG Items

- Update on LISP 6830bis & 6833bis
=  draft-ietf-lisp-6830bis
=  draft-ietf-lisp-6833bis
 (To be extended if = needed)
15 Minutes = (Cumulative Time: 20 Minutes)
 Dino Farinacci = & Albert Cabellos

- LISP-Security - = draft-ietf-lisp-sec-14.txt
 5 minutes (Cumulative = Time: 25 Minutes)
 Fabio Maino

- LISP YANG Model - draft-ietf-lisp-yang-05
=  5 minutes (Cumulative Time: 30 Minutes)
=  Reshad Rahman


o Non WG = Items

- LISP Map Server Reliable Transport = - =        draft-kouvelas-lisp-map-server-r= eliable-transport-04.txt
 10 minutes (Cumulative = Time: 40 Minutes)
 Reshad Rahman

- Ground-based LISP for the Aeronautical Telecommunications = Network
 15 minutes (Cumulative Time: 55 Minutes)
 Reshad Rahmen

- LISP = Control-Plane ECDSA Authentication and Authorization - = draft-farinacci-lisp-ecdsa-auth-00.txt
 10 minutes = (Cumulative Time: 65 Minutes)
 Dino Farinacci

- LISP for the Mobile Network - = draft-farinacci-lisp-mobile-network-00.txt
 10 = minutes (Cumulative Time: 75 Minutes)
 Dino = Farinacci

- Publish/Subscribe Functionality = for LISP - =             &n= bsp;   draft-rodrigueznatal-lisp-pubsub-01.txt
 15 minutes (Cumulative Time: 90 Minutes)
=  Fabio Maino

- LISP Traffic = Engineering
 15 minutes (Cumulative Time: 105 = Minutes)
 Yan Filyurin

- = LISP on Android & iOS
 10 minutes (Cumulative = Time: 115 Minutes)
 Albert Cabellos

- VXLAN GPE - draft-brockners-ioam-vxlan-gpe-00.txt
 5 minutes (Cumulative Time:120 Minutes)
=  Franck Brockners

- Overflow Time/ = Discussion
 0 Minutes (Cumulative Time: 120 = Minutes)



= --Apple-Mail=_A8FCD7D4-2425-4E48-9C69-1662D3E2F591-- From nobody Wed Nov 15 09:01:08 2017 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 27381127241; Wed, 15 Nov 2017 09:01:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151076526708.20966.7686473073513171863@ietfa.amsl.com> Date: Wed, 15 Nov 2017 09:01:07 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-vpn-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 17:01:07 -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 WG of the IETF. Title : LISP Virtual Private Networks (VPNs) Authors : Victor Moreno Dino Farinacci Filename : draft-ietf-lisp-vpn-01.txt Pages : 16 Date : 2017-11-15 Abstract: This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-vpn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-vpn-01 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-vpn-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-vpn-01 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 Wed Nov 15 09:23:09 2017 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 6DD681272E1; Wed, 15 Nov 2017 09:23:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151076658740.20981.16132053569490083375@ietfa.amsl.com> Date: Wed, 15 Nov 2017 09:23:07 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-eid-mobility-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 17:23:07 -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 WG of the IETF. Title : LISP L2/L3 EID Mobility Using a Unified Control Plane Authors : Marc Portoles Comeras Vrushali Ashtaputre Victor Moreno Fabio Maino Dino Farinacci Filename : draft-ietf-lisp-eid-mobility-01.txt Pages : 23 Date : 2017-11-15 Abstract: The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution, as well as analyzing possible deployment options and models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-mobility/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-eid-mobility-01 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-eid-mobility-01 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 Thu Nov 16 00:34:58 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9F4124217 for ; Thu, 16 Nov 2017 00:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1o6a_HXzjHbi for ; Thu, 16 Nov 2017 00:34:54 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 2E050127369 for ; Thu, 16 Nov 2017 00:34:54 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id n134so895994itg.0 for ; Thu, 16 Nov 2017 00:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=YKFsqKb/93Poe7fF4N96fuemmaqs6LbC4Dt62DS0U5Q=; b=L6aIu3rbubKXs3qhH4vI0hTEuP/yyErkz/EhDhCDkyeiNqBnR6iasCXySCclEKdVjw IYibROG3j7HtQzzqN46+5hetvo/mJByCpvv5fbqMEWNBBrmf3QMEQ1eUrYJFn6x5Sigz IdVZ/jqgWcA3eKgkAHt97zIjMa/Byj6qsQpqXQr1A6UYNQ4oAU/zmu+bNTn+8OaBvWW/ dpilhdjh/xQHZSd4Eb0C6Vg/MwpC38U+crGrAlW8F8dAP+tbPdMh4yb6aqEF3bp3ifur Se9bwjbYVTimE/Fq9w+TgBZs0YTQgCsicJgDbNkPlqUNwXCUvPljqVU+oLQVb5JH+Y4g rDBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=YKFsqKb/93Poe7fF4N96fuemmaqs6LbC4Dt62DS0U5Q=; b=NYQ4rYsfhdsQFGxaMD2oC+SAws3MxwJxdpsqFFBJJSuywoLQcByENu3U7uhDHUAkEi NCf13AJ1kSdn2hgxq0gpZeIa0eoi5KJO1xAoxxe6ed6EG+KKZyYQm+mkOkcIce5ZRKJE 3jqg/RwO/tqzqtCi3Mt7UPCtQC2mNx8kq0Y2yTP8xVefln7xgDWlcP11D5X41RZ+pe// WTgPDdK+NwNNY6+jqp48GJA15XFXmQvJYMK0F6feYqI+N1zHdg+HBUFm0fT0PJX8rLKP 2Ji+7XelCHslgGOtjtC4AKzeIZzwiOEJ3HI2w1ikJ1RKHijNfb+3revPNb9uCqy698G4 bQjg== X-Gm-Message-State: AJaThX6fWylrxK6FE5CGKdKjaqD3Cnr1EghYPd0XzST11c5+zR3AGmWi aPQ0bFCqkMn1sI8v3S5lmPPKtAXfB3zPYnvg/kljtxRq X-Google-Smtp-Source: AGs4zMbXBG0pJt4830mo5ne3qFiwisjZm7HPj+y6VT/GUTs3MLMUXPULpyESqG1K1CiZXftInnuZkDJ1MVVfRGqYyyI= X-Received: by 10.36.36.213 with SMTP id f204mr1406855ita.89.1510821293024; Thu, 16 Nov 2017 00:34:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.181.70 with HTTP; Thu, 16 Nov 2017 00:34:32 -0800 (PST) From: Alberto Rodriguez-Natal Date: Thu, 16 Nov 2017 00:34:32 -0800 Message-ID: To: "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [lisp] Review of RFC6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 16 Nov 2017 08:34:56 -0000 Hi all, Wanted to send this before the meeting on Friday. I just completed a review of 6833bis, you can find my comments below. Like last time, extracts from the draft are copied and followed by my comments. Thanks, Alberto Map-Resolver: A network infrastructure component that accepts LISP Encapsulated Map-Requests, =E2=80=A2 [AR] We could remove "Encapsulated" and just use "Map-Request= s". A Map-Resolver may accept non-encapsulated Map-Requests as well. Map-Register message: A LISP message sent by an ETR to a Map-Server to register its associated EID-Prefixes. In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to be used by the Map-Server when forwarding Map-Requests (re-formatted as Encapsulated Map-Requests) received through the database mapping system. =E2=80=A2 [AR] This may give the impression that the RLOCs on the Map-Register are only to forward Map-Requests, which is not the case in proxy-reply mode. I would suggest we rephrase this text as follows: "In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to be used to reach the ETR. The Map-Server uses these RLOCs when it has to forward Map-Requests (potentially re-formatted as Encapsulated Map-Requests) received through the database mapping system." Map-Notify message: A LISP message sent by a Map-Server to an ETR =E2=80=A2 [AR] I would replace "ETR" with "xTR" so we cover the PubSub behavior as well. For definitions of other terms -- notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. =E2=80=A2 [AR] I think that the definitions for Map-Request and Map-Rep= ly should be moved here, and probably we should include the definition for Map-Notify-Ack as well. 6830bis should reference 6833bis for control-plane messages, not the other way around. A Map-Register message contains a list of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR when a Map-Server needs to forward a Map-Request to it. =E2=80=A2 [AR] Since proxy-reply is a common case, I'd not constrain th= e meaning of the RLOCs in the Map-Register. I'd remove the last part of the sentence that says "when a Map-Server needs to forward a Map-Request to it." A Map-Resolver receives Encapsulated Map-Requests from its client ITRs and uses a mapping database system to find the appropriate ETR to answer those requests. =E2=80=A2 [AR] A MR can receive Map-Requests that don't come from ITR and/or that are not encapsulated. If we don't want to change the text, at least I'd add at the beginning: "In a common scenario, a Map-Resolver..." Note that while it is conceivable that a non-LISP-DDT Map-Resolver could cache responses to improve performance, =E2=80=A2 [AR] The discussion on caching or not at the Map-Resolver goe= s beyond DDT. We could rephrase this removing the mention to "non-LISP-DDT". The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. =E2=80=A2 [AR] I would remove the first sentence and re-phrase this paragraph as follows: "When a UDP LISP control message is sent and is not a direct reply to a previous control message, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP LISP control message is sent as a direct reply to a previous message, the source UDP port number is set to 4342 and the destination UDP port number is either set to 4342 or copied from the source port of the invoking LISP control message. See the following subsections for details." The UDP checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register, and Encapsulated Control Message (ECM) control messages. =E2=80=A2 [AR] Shouldn't it be computed for all LISP control messages? EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. =E2=80=A2 [AR] We should probably rephrase this to don't limit it to IP= v4/6 For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the Locator-Set of the Map-Cache entry. =E2=80=A2 [AR] To refresh map-caches before TTL expiration, the destination IP of the Map-Request can be the address of the Map-Server if in proxy-reply. This should be considered here. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-Request. =E2=80=A2 [AR] This could probably be a SHOULD since we use AFI =3D 0 a= s ITR-RLOC to unsubscribe in PubSub. EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family. =E2=80=A2 [AR] We should mention the possibility for address families other than IPv4/6. The RLOCs in the Map-Reply are globally routable IP addresses of all ETRs for the LISP site. =E2=80=A2 [AR] We should remove "globally" here. Maybe also add a "Generally" at the beginning since we might have LCAFs with AFI =3D 0 (LISP-VPN encoding of Home-IID for instance). For example, a requester with two cached EID-Prefixes that are covered by a Map-Reply containing one less-specific prefix replaces the entry with the less-specific EID-Prefix. =E2=80=A2 [AR] Not sure if I follow here. Does this mean that a less-specific received in a Map-Reply will erase from the map-cache previously cached more-specifics that are covered by the less-specific? When more than one EID-Prefix is returned, all SHOULD use the same Time to Live value so they can all time out at the same time. When a more-specific EID-Prefix is received later, its Time to Live value in the Map-Reply record can be stored even when other less-specific entries exist. =E2=80=A2 [AR] We should explain in which cases a more-specific can be received later. The Locator-Set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address. =E2=80=A2 [AR] LCAF addresses (maybe with AFI=3D0) should be discussed = here as well. Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register messages. =E2=80=A2 [AR] Since there may be future cases that benefit from having= a non-zero nonce on the Map-Register, I would suggest to rephrase this sentence to add a CAN. E: This is the to-ETR bit. When set to 1, the Map-Server's intention is to forward the ECM to an authoritative ETR. =E2=80=A2 [AR] Can M and E be set at the same time? LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages are allowed to be encapsulated. =E2=80=A2 [AR] Shall we mention the NAT traversal draft? A Map-Server's configuration must also include a list of the EID-Prefixes for which each ETR is authoritative. =E2=80=A2 [AR] There may be certain cases where this does not need to b= e pre-configured. I suggest we replace the "must" with a "should". Note that this requirement is already a "should" in section 6. See [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets certain flags (such as those indicating whether the message is authoritative and how returned Locators should be treated) when sending a Map-Reply on behalf of an ETR. =E2=80=A2 [AR] It may be useful to discuss at least some of those detai= ls here. From nobody Thu Nov 16 16:24:05 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F7A126CD8 for ; Thu, 16 Nov 2017 16:24:04 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rkXT8LYiFCkJ for ; Thu, 16 Nov 2017 16:24:01 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 C31DB120727 for ; Thu, 16 Nov 2017 16:24:01 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id 17so588048pfn.12 for ; Thu, 16 Nov 2017 16:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y2H0axgs90Z7uheV8KlwYf9ALS9sPy/GG2wkZsaJ6nI=; b=qS3G6kMFvVu9DwYc9gv12tEyYLvMNbGCgoQwCmzbMJcw1YXc7ryWSAfa55urFwXnj3 RA5rBtjC5R00Dj7vd3vKo2wobr6ahnfKTT+k6mJxt/bObN+OJbdi8nOw/VYGlC119aE2 G4HGfnYVbqeQBh0UslsS8wz33Bpkg2aKo47lhBkSu4BcwkjaJynFMEkUTPXaFzbR/w43 1iPBlOBQY6zHjmxSjCrwEXdjjM64xLaJYyyx8PNx53cfQBeUuKL3J6hipGFPwxuR+EKR +j701SHKWjUYCEguWlstXE12thYbk/4Q4uo0+KLR9JbGGrETrpISn7qQeJagoWYG58LS qqUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y2H0axgs90Z7uheV8KlwYf9ALS9sPy/GG2wkZsaJ6nI=; b=jlPgQHGnx7FuguxwYf43EoO/M1rNdShTdq84H+df4ZzAgSJg0fuXwcxCwx6+svz53B t0NXamLnS1qAtlDkL9uQvo5gm8xgcW8XFOwearBzKSTqmpyLVcb6+D6pCnTiRxrYU/1x mr88i7KwjY//d/H7SJiaOrwOmFGLyc2Sbti0iCtLCBXuL8OrXQBKoXiGvDuRDxFdblca GtOHfZUU6MZ3rIblqCTk+0leQ68WTbPv81KmZC1T6BSDF6tY9tQ5o5FjBQ4/shYE2Mx9 wo4wNjC2A5hR74j3G8vIkEjvvHNXJ3EgkfclBito0IlptHLNlhL4Z/39Q5IQl0BaJnYa AG3g== X-Gm-Message-State: AJaThX6Dkby7EcQ/EEYPUuTB3QFddHFK0ZcY4KwlIq52ba0gvHo9BHFc fRtuSYi+upBVg0X6KWwgxpubACzA X-Google-Smtp-Source: AGs4zMaDEnMLJq+eLQ+S8Qo5MS47+7ejjc1vYEaM5yaSKrlnsDfq2TYa9eSD+S8OVpqrcE95niVKJg== X-Received: by 10.101.98.198 with SMTP id m6mr3469147pgv.410.1510878241201; Thu, 16 Nov 2017 16:24:01 -0800 (PST) Received: from [192.168.1.177] ([118.201.241.41]) by smtp.gmail.com with ESMTPSA id a7sm3657711pgc.81.2017.11.16.16.23.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 16:24:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Dino Farinacci In-Reply-To: Date: Thu, 16 Nov 2017 16:23:58 -0800 Cc: "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <15426860-A6E2-499E-B440-AC48F725AB1E@gmail.com> References: To: Alberto Rodriguez-Natal X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [lisp] Review of RFC6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 17 Nov 2017 00:24:04 -0000 Thanks for the comments. We=E2=80=99ll bring this up in the meeting but = I can=E2=80=99t address your comments until next week. Some points: (1) Packets are =E2=80=9Ccontrol-plane=E2=80=9D encapsulated to the = Map-Resolver, so the text is correct. (2) The WG had decided at some point to not include the NAT-traversal = document because its not a WG document. (3) Your comments about clarifying text is valuable and IMO should go = in. Thanks for that. Dino > On Nov 16, 2017, at 12:34 AM, Alberto Rodriguez-Natal = wrote: >=20 > Hi all, >=20 > Wanted to send this before the meeting on Friday. I just completed a > review of 6833bis, you can find my comments below. Like last time, > extracts from the draft are copied and followed by my comments. >=20 > Thanks, > Alberto >=20 >=20 >=20 >=20 > Map-Resolver: A network infrastructure component that accepts LISP > Encapsulated Map-Requests, >=20 > =E2=80=A2 [AR] We could remove "Encapsulated" and just use = "Map-Requests". > A Map-Resolver may accept non-encapsulated Map-Requests as well. >=20 > Map-Register message: A LISP message sent by an ETR to a Map-Server > to register its associated EID-Prefixes. In addition to the set of > EID-Prefixes to register, the message includes one or more RLOCs to be > used by the Map-Server when forwarding Map-Requests (re-formatted as > Encapsulated Map-Requests) received through the database mapping > system. >=20 > =E2=80=A2 [AR] This may give the impression that the RLOCs on the > Map-Register are only to forward Map-Requests, which is not the case > in proxy-reply mode. I would suggest we rephrase this text as follows: > "In addition to the set of EID-Prefixes to register, the message > includes one or more RLOCs to be used to reach the ETR. The Map-Server > uses these RLOCs when it has to forward Map-Requests (potentially > re-formatted as Encapsulated Map-Requests) received through the > database mapping system." >=20 > Map-Notify message: A LISP message sent by a Map-Server to an ETR >=20 > =E2=80=A2 [AR] I would replace "ETR" with "xTR" so we cover the = PubSub > behavior as well. >=20 > For definitions of other terms -- notably Map-Request, Map-Reply, > Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please > consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >=20 > =E2=80=A2 [AR] I think that the definitions for Map-Request and = Map-Reply > should be moved here, and probably we should include the definition > for Map-Notify-Ack as well. 6830bis should reference 6833bis for > control-plane messages, not the other way around. >=20 > A Map-Register message contains a list of EID-Prefixes plus a set of > RLOCs that can be used to reach the ETR when a Map-Server needs to > forward a Map-Request to it. >=20 > =E2=80=A2 [AR] Since proxy-reply is a common case, I'd not = constrain the > meaning of the RLOCs in the Map-Register. I'd remove the last part of > the sentence that says "when a Map-Server needs to forward a > Map-Request to it." >=20 > A Map-Resolver receives Encapsulated Map-Requests from its client ITRs > and uses a mapping database system to find the appropriate ETR to > answer those requests. >=20 > =E2=80=A2 [AR] A MR can receive Map-Requests that don't come from = ITR > and/or that are not encapsulated. If we don't want to change the text, > at least I'd add at the beginning: "In a common scenario, a > Map-Resolver..." >=20 > Note that while it is conceivable that a non-LISP-DDT Map-Resolver > could cache responses to improve performance, >=20 > =E2=80=A2 [AR] The discussion on caching or not at the Map-Resolver = goes > beyond DDT. We could rephrase this removing the mention to > "non-LISP-DDT". >=20 > The LISP UDP-based messages are the Map-Request and Map-Reply > messages. When a UDP Map-Request is sent, the UDP source port is > chosen by the sender and the destination UDP port number is set to > 4342. When a UDP Map-Reply is sent, the source UDP port number is set > to 4342 and the destination UDP port number is copied from the source > port of either the Map-Request or the invoking data packet. >=20 > =E2=80=A2 [AR] I would remove the first sentence and re-phrase this > paragraph as follows: "When a UDP LISP control message is sent and is > not a direct reply to a previous control message, the UDP source port > is chosen by the sender and the destination UDP port number is set to > 4342. When a UDP LISP control message is sent as a direct reply to a > previous message, the source UDP port number is set to 4342 and the > destination UDP port number is either set to 4342 or copied from the > source port of the invoking LISP control message. See the following > subsections for details." >=20 > The UDP checksum is computed and set to non-zero for Map-Request, > Map-Reply, Map-Register, and Encapsulated Control Message (ECM) > control messages. >=20 > =E2=80=A2 [AR] Shouldn't it be computed for all LISP control = messages? >=20 > EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 > octets for an IPv6 address family. When a Map-Request is sent by an > ITR because a data packet is received for a destination where there is > no mapping entry, the EID-Prefix is set to the destination IP address > of the data packet, and the 'EID mask-len' is set to 32 or 128 for > IPv4 or IPv6, respectively. >=20 > =E2=80=A2 [AR] We should probably rephrase this to don't limit it = to IPv4/6 >=20 > For the latter two cases, the destination IP address used for the > Map-Request is one of the RLOC addresses from the Locator-Set of the > Map-Cache entry. >=20 > =E2=80=A2 [AR] To refresh map-caches before TTL expiration, the > destination IP of the Map-Request can be the address of the Map-Server > if in proxy-reply. This should be considered here. >=20 > If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier > MUST drop the Map-Request. >=20 > =E2=80=A2 [AR] This could probably be a SHOULD since we use AFI =3D = 0 as > ITR-RLOC to unsubscribe in PubSub. >=20 > EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 > octets for an IPv6 address family. >=20 > =E2=80=A2 [AR] We should mention the possibility for address = families > other than IPv4/6. >=20 > The RLOCs in the Map-Reply are globally routable IP addresses of all > ETRs for the LISP site. >=20 > =E2=80=A2 [AR] We should remove "globally" here. Maybe also add a > "Generally" at the beginning since we might have LCAFs with AFI =3D 0 > (LISP-VPN encoding of Home-IID for instance). >=20 > For example, a requester with two cached EID-Prefixes that are covered > by a Map-Reply containing one less-specific prefix replaces the entry > with the less-specific EID-Prefix. >=20 > =E2=80=A2 [AR] Not sure if I follow here. Does this mean that a > less-specific received in a Map-Reply will erase from the map-cache > previously cached more-specifics that are covered by the > less-specific? >=20 > When more than one EID-Prefix is returned, all SHOULD use the same > Time to Live value so they can all time out at the same time. When a > more-specific EID-Prefix is received later, its Time to Live value in > the Map-Reply record can be stored even when other less-specific > entries exist. >=20 > =E2=80=A2 [AR] We should explain in which cases a more-specific can = be > received later. >=20 > The Locator-Set MUST be sorted in order of ascending IP address where > an IPv4 locator address is considered numerically 'less than' an IPv6 > locator address. >=20 > =E2=80=A2 [AR] LCAF addresses (maybe with AFI=3D0) should be = discussed here as well. >=20 > Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register = messages. >=20 > =E2=80=A2 [AR] Since there may be future cases that benefit from = having a > non-zero nonce on the Map-Register, I would suggest to rephrase this > sentence to add a CAN. >=20 > E: This is the to-ETR bit. When set to 1, the Map-Server's intention > is to forward the ECM to an authoritative ETR. >=20 > =E2=80=A2 [AR] Can M and E be set at the same time? >=20 > LCM: The format is one of the control message formats described in > this section. At this time, only Map-Request messages are allowed to > be encapsulated. >=20 > =E2=80=A2 [AR] Shall we mention the NAT traversal draft? >=20 > A Map-Server's configuration must also include a list of the > EID-Prefixes for which each ETR is authoritative. >=20 > =E2=80=A2 [AR] There may be certain cases where this does not need = to be > pre-configured. I suggest we replace the "must" with a "should". Note > that this requirement is already a "should" in section 6. >=20 > See [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets > certain flags (such as those indicating whether the message is > authoritative and how returned Locators should be treated) when > sending a Map-Reply on behalf of an ETR. >=20 > =E2=80=A2 [AR] It may be useful to discuss at least some of those = details here. >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Nov 16 18:56:12 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B7D126DFE for ; Thu, 16 Nov 2017 18:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IWjmT6emfTV4 for ; Thu, 16 Nov 2017 18:56:00 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 C07D0126B71 for ; Thu, 16 Nov 2017 18:49:32 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id r127so2428977itb.5 for ; Thu, 16 Nov 2017 18:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=c5wr8QcDaYpmfRUSHVV6Ltmw8JUKTmGojiyQIDdwdLg=; b=hmIA177ly3Q/FLHO10m1bvuZAymeYqwFZDdesoBtF2NJz0IXjgQh4X0nPmBnHyk2v6 7DlxJ7llxOZo2OMUACfk8Xv0fiX+aWIqK9qd1iS91Rs9yb0426+FbWz4eUDTn5kWthYc mm8KjQSAMllVZmJcMg0QQsmES+0TXThbJim3iATuC4fKe/i6gDz3/6ZwcNb0uH6PZNIE 1+MnWvlCu8SxlanfxHUHISzhNZpUdtoXC+85k9CaJRnIY9qUxx+YKzSx5PZ9cWX9MxWw JxH1/sHUibSVHLuECP+eAQVi/+oKNbm8bMn1FCtjPPoeZVRc7KjZP88WxTeK/DN0jDfK XlEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c5wr8QcDaYpmfRUSHVV6Ltmw8JUKTmGojiyQIDdwdLg=; b=EXsk51yaCIt9muUO0yDEa4E/5uVK+jaE/QBIMM4Kw7gv68V3Gop6gkSXn+vnCR48eL M74CvONMHUVikf7Z6lBoHGo27Oikwz8kzO/vcIUM5TcFEwedGp6ac3wQOCOE0MoaXnef TtSMaWkujW3/c0NflQOow54O9RUJNobWkXKLsUIaQKIcTDH9iPocnryLzO9LbIxZrO4e 6qfYFc1vYuiNFnqLk5UYlKiPUFvgvul9Tsrwf8I3DLnEzjx5u5wOok+yG16vJ5Aggc3O 6dPc5rwNN0BLspFOga36Jdn4roL8l1q5cYyo6XIOD6146U2fs2mNFqNOjwb74Xcgw2GK ztyg== X-Gm-Message-State: AJaThX5MCOWUiWwvTU+xweSXjU7wMhDR9b/9sSQgL7zIKOoQj+5WPNcT qPch1MWOjiuVxOuiWqEfhDVY/xP3WcZWTS5lIaJEudEp X-Google-Smtp-Source: AGs4zMYqUst6VBfJ1w3+c3SR3KYd7ypprSN/Kg0penOn/D/hl/O4aQ0wofJlMpyhlCnEWl/iXlIGmp2LxgBZdO/TEfg= X-Received: by 10.36.172.31 with SMTP id s31mr4997575ite.124.1510886971679; Thu, 16 Nov 2017 18:49:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.181.70 with HTTP; Thu, 16 Nov 2017 18:49:11 -0800 (PST) From: Alberto Rodriguez-Natal Date: Thu, 16 Nov 2017 18:49:11 -0800 Message-ID: To: "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [lisp] Nonce in PubSub X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 17 Nov 2017 02:56:02 -0000 Just to clarify what was discussed in the meeting. The nonce used in the Map-Request requesting the subscription will be used in the Map-Notify that confirms the subscription. This is at top of page 6 in the draft. Similarly, a Map-Notify sent as publication will be ack'ed by a Map-Notify-Ack using its nonce. https://tools.ietf.org/html/draft-rodrigueznatal-lisp-pubsub-01 Thanks, Alberto From nobody Thu Nov 16 23:17:18 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1057012741D for ; Thu, 16 Nov 2017 23:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 FH_QXWa_TMbO for ; Thu, 16 Nov 2017 23:17:14 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 A0308127B73 for ; Thu, 16 Nov 2017 23:17:14 -0800 (PST) Received: from [31.133.146.1] (dhcp-9201.meeting.ietf.org [31.133.146.1]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vAH7H9vL024499 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Nov 2017 23:17:11 -0800 To: Alberto Rodriguez-Natal , "lisp@ietf.org list" References: From: Erik Nordmark Message-ID: <826333ea-ed39-96f5-8047-073ac6aad498@acm.org> Date: Fri, 17 Nov 2017 15:17:08 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYUdaa+d0ozgCwneQQuemTKlrDgv8iUW94pxNowZYB16kEdJ+4C30mjYH/OwPJ9MEjvnkRp3A8+CiZnwWtHjmPB X-Sonic-ID: C;qvonU2fL5xGbMoKfRUfeDw== M;3I0WVGfL5xGbMoKfRUfeDw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [lisp] Nonce in PubSub X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 17 Nov 2017 07:17:16 -0000 On 11/17/2017 10:49 AM, Alberto Rodriguez-Natal wrote: > Just to clarify what was discussed in the meeting. The nonce used in > the Map-Request requesting the subscription will be used in the > Map-Notify that confirms the subscription. This is at top of page 6 in > the draft. > > Similarly, a Map-Notify sent as publication will be ack'ed by a > Map-Notify-Ack using its nonce. Albero, My understanding from Dino's comment at the make was that in his implementation the map-notify has the nonce from the original map-request. The reason I asked about this is that there are some additional security benefits if the map-notify has a nonce which corresponds to what the xTR had sent in the map-request. Otherwise you need some other mechanism to guard against receiving spoofed map-notifies. Erik > > https://tools.ietf.org/html/draft-rodrigueznatal-lisp-pubsub-01 > > Thanks, > Alberto > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Fri Nov 17 10:57:46 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E60912717E for ; Fri, 17 Nov 2017 10:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yryQIulZMY3A for ; Fri, 17 Nov 2017 10:57:42 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 A5283126C89 for ; Fri, 17 Nov 2017 10:57:42 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id l196so5207603itl.4 for ; Fri, 17 Nov 2017 10:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L9zjjDjpE1pJ8Et2IT6bbP3ZWzZEUrI+Mg5fHR7vdSY=; b=GSp7VR2MBKqpXB4pEdBnGEpOEgsq8z1EZcqo+pw4qfbSycW6u7ePwcAvTG/5zwfOdu XZzDrr5wWccNIRYRYd0vC25FfXyAk80a0RDwZOp1XsMQNX7yvSMtbT9ZLp5QSuaaYwwp HXkC8kZ4joRZO6xDax6moXSXJygy8K6+6jxvQVH+SsDwtBCsDxdb4PlpouqXJuyi0oa6 0oRYMeM1yIF/VnO+VPG1+gxhSz+rftrBEbrhKnW8wnZFqv8ADJY9dITeZT8tVSMuQ5dc kOe9IF5SzLP6rkzsyBvfKYWstOA4qQRmpzBG2mUXXXRrHoUZtWPS3lWFwob6vp60Ciez hD2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L9zjjDjpE1pJ8Et2IT6bbP3ZWzZEUrI+Mg5fHR7vdSY=; b=n5O+uufHvZ/RIcaYCkbyx7A03TwwfPJH/5L4YiWry1x7K9GbnAaE0Wlnj3wijmSJCd WR40MXnzYNys5jEosIhl9z9b66N/1JR4BXjXLOXsajiWSEhotc6Uw+QKpGYk1GhJ+s7O qVCGUblE/6P4kwax3KWZuKLj2SZVDNBXrw92/G0IZ9Pxdfx0OUiCQyTymPCK6cAIV5qL /OjTl//PB0zPXWCnsTPwzs8c43XbsG0bQ2xyCQrjXJF3a/+s1L8MOiwxFCNJC0KWD4eB 3B2rkwoxzSyQACvqSloySo7DfdWpusAn5ZR4Cc0TMLlOmfl0opOfPb1oaNNPllGsa8fq TwUQ== X-Gm-Message-State: AJaThX5WH+jFA6UUaGBAEANBWRRrwTHGTVJ8ClOkpUNjUkSktXUwutFT We3LrlGoLS/H4usVvUmTRQLYqlWBPYnwXZtkMAA= X-Google-Smtp-Source: AGs4zMa6Y0H1eaE4euTJpXYjKoP0Bxba91LRvA4hNOAlZZYsXJomQ8eyPw/GE+f6qYHuXp+aDIL0S3KO1XMcWXww/58= X-Received: by 10.36.163.138 with SMTP id p132mr7454357ite.57.1510945061867; Fri, 17 Nov 2017 10:57:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.181.70 with HTTP; Fri, 17 Nov 2017 10:57:21 -0800 (PST) In-Reply-To: <826333ea-ed39-96f5-8047-073ac6aad498@acm.org> References: <826333ea-ed39-96f5-8047-073ac6aad498@acm.org> From: Alberto Rodriguez-Natal Date: Fri, 17 Nov 2017 10:57:21 -0800 Message-ID: To: Erik Nordmark Cc: "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lisp] Nonce in PubSub X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 17 Nov 2017 18:57:45 -0000 Hi Erik, I see your point. The draft assumes a security association between the ITR and the MS in order to authenticate the Map-Notifies. I think this addresses your valid concern on spoofed Map-Notifies. How this security association is established is a different discussion :) Note also that, ideally, the Map-Notifies sent as publications should each have a different nonce so the MS can easily correlate them with the Map-Notify-Acks received as responses. Best, Alberto On Thu, Nov 16, 2017 at 11:17 PM, Erik Nordmark wrote: > On 11/17/2017 10:49 AM, Alberto Rodriguez-Natal wrote: >> >> Just to clarify what was discussed in the meeting. The nonce used in >> the Map-Request requesting the subscription will be used in the >> Map-Notify that confirms the subscription. This is at top of page 6 in >> the draft. >> >> Similarly, a Map-Notify sent as publication will be ack'ed by a >> Map-Notify-Ack using its nonce. > > > Albero, > > My understanding from Dino's comment at the make was that in his > implementation the map-notify has the nonce from the original map-request. > > The reason I asked about this is that there are some additional security > benefits if the map-notify has a nonce which corresponds to what the xTR had > sent in the map-request. Otherwise you need some other mechanism to guard > against receiving spoofed map-notifies. > > Erik > >> >> https://tools.ietf.org/html/draft-rodrigueznatal-lisp-pubsub-01 >> >> Thanks, >> Alberto >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > From nobody Fri Nov 17 11:24:58 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97083128D6F for ; Fri, 17 Nov 2017 11:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 B9-WyQ_SfGtQ for ; Fri, 17 Nov 2017 11:24:53 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 99225126C83 for ; Fri, 17 Nov 2017 11:24:53 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id v21so9844262ioi.4 for ; Fri, 17 Nov 2017 11:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8DNfU2/PSa9PPlVqTDW77dOCcTKA64ObotNQYOW4Dpg=; b=bFpFBnYrf8FUzOBlLRM8qTX//FYHudsNinq1Fe8ZJXdN9FcdozSSOq8xl8qwyRp1Q+ uq3ZpPeFZnFPcsUYCaweB4g5l7Ln7/YnR6ZCNgkI+RVpCJKqxx0NEbWs0pfb42x8fu3f y/CcArdovV+JhLm4vr22aTonLRVC7MybHXak1Bn6woO8xCvXCPXBZpH0OHrrwgR16pB3 0IbDnKeTZ0MFRTn5zum4vaR+3nfqpa5Oe5d1VvOZ2T80vrBEInnPw7Lm4efeie/vmQye 0bcRhffj7oaf4sU/ICuUrX2SJ1ZOST2mQnprmSlIsHJjnWlv1nim8S2MRg+gUC1de4W2 zgyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8DNfU2/PSa9PPlVqTDW77dOCcTKA64ObotNQYOW4Dpg=; b=eohfxHM5p/J/MJP56Gendtq0duOAp6nRrMi5VKgADR8vqlwBHkj8hfqkSGbfT5Gyyf H/nkeayVxzjsVEUdEWfLRIziyY9ag1C3yFtukq0E+0aT/8ER5hwibMH38abBAGltLZlc 5nz4c1ta1fo7lPpNX0wAUT1Wa1+5e09rLQm2lvaVfvTpoX3JMGgy0sDPy5v24/yhaeCi /CODxhGr+76WkCKVHhW+ony6532fwmKfCiNDCoLJjf9Aaqh1XOUk6eSmgWlFibYuBEMd LiImuO944FYMZMHwUYJk7G0E33FYFeng1eGF00eKUCgv9IRkk+j0W2ccqj/+2wh/8MP9 gPkQ== X-Gm-Message-State: AJaThX5BF3tXFDB7uwpVHs4I4w2+Y3rngFuWXYzjPxiLJ6hlxkOdM7Gw XoEM+R9OocI0gjG/aX8GCuHvTggEXqUl8E5Wda8= X-Google-Smtp-Source: AGs4zMYg02KxxNXHQ3c4k2O6266JTbtq4m8BnJRyJmEeyVXDb/JBKz0+JJdN1Wo5tJdWWtL6tmfGSFIeh36icCafh20= X-Received: by 10.107.141.77 with SMTP id p74mr4345453iod.40.1510946692197; Fri, 17 Nov 2017 11:24:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.181.70 with HTTP; Fri, 17 Nov 2017 11:24:31 -0800 (PST) In-Reply-To: <15426860-A6E2-499E-B440-AC48F725AB1E@gmail.com> References: <15426860-A6E2-499E-B440-AC48F725AB1E@gmail.com> From: Alberto Rodriguez-Natal Date: Fri, 17 Nov 2017 11:24:31 -0800 Message-ID: To: Dino Farinacci Cc: "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] Review of RFC6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 17 Nov 2017 19:24:57 -0000 No worries Dino, there's no rush. Thanks for your early response. Thanks, Alberto On Thu, Nov 16, 2017 at 4:23 PM, Dino Farinacci wrote= : > Thanks for the comments. We=E2=80=99ll bring this up in the meeting but I= can=E2=80=99t address your comments until next week. > > Some points: > > (1) Packets are =E2=80=9Ccontrol-plane=E2=80=9D encapsulated to the Map-R= esolver, so the text is correct. > (2) The WG had decided at some point to not include the NAT-traversal doc= ument because its not a WG document. > (3) Your comments about clarifying text is valuable and IMO should go in.= Thanks for that. > > Dino > >> On Nov 16, 2017, at 12:34 AM, Alberto Rodriguez-Natal wrote: >> >> Hi all, >> >> Wanted to send this before the meeting on Friday. I just completed a >> review of 6833bis, you can find my comments below. Like last time, >> extracts from the draft are copied and followed by my comments. >> >> Thanks, >> Alberto >> >> >> >> >> Map-Resolver: A network infrastructure component that accepts LISP >> Encapsulated Map-Requests, >> >> =E2=80=A2 [AR] We could remove "Encapsulated" and just use "Map-Reque= sts". >> A Map-Resolver may accept non-encapsulated Map-Requests as well. >> >> Map-Register message: A LISP message sent by an ETR to a Map-Server >> to register its associated EID-Prefixes. In addition to the set of >> EID-Prefixes to register, the message includes one or more RLOCs to be >> used by the Map-Server when forwarding Map-Requests (re-formatted as >> Encapsulated Map-Requests) received through the database mapping >> system. >> >> =E2=80=A2 [AR] This may give the impression that the RLOCs on the >> Map-Register are only to forward Map-Requests, which is not the case >> in proxy-reply mode. I would suggest we rephrase this text as follows: >> "In addition to the set of EID-Prefixes to register, the message >> includes one or more RLOCs to be used to reach the ETR. The Map-Server >> uses these RLOCs when it has to forward Map-Requests (potentially >> re-formatted as Encapsulated Map-Requests) received through the >> database mapping system." >> >> Map-Notify message: A LISP message sent by a Map-Server to an ETR >> >> =E2=80=A2 [AR] I would replace "ETR" with "xTR" so we cover the PubSu= b >> behavior as well. >> >> For definitions of other terms -- notably Map-Request, Map-Reply, >> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please >> consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >> >> =E2=80=A2 [AR] I think that the definitions for Map-Request and Map-R= eply >> should be moved here, and probably we should include the definition >> for Map-Notify-Ack as well. 6830bis should reference 6833bis for >> control-plane messages, not the other way around. >> >> A Map-Register message contains a list of EID-Prefixes plus a set of >> RLOCs that can be used to reach the ETR when a Map-Server needs to >> forward a Map-Request to it. >> >> =E2=80=A2 [AR] Since proxy-reply is a common case, I'd not constrain = the >> meaning of the RLOCs in the Map-Register. I'd remove the last part of >> the sentence that says "when a Map-Server needs to forward a >> Map-Request to it." >> >> A Map-Resolver receives Encapsulated Map-Requests from its client ITRs >> and uses a mapping database system to find the appropriate ETR to >> answer those requests. >> >> =E2=80=A2 [AR] A MR can receive Map-Requests that don't come from ITR >> and/or that are not encapsulated. If we don't want to change the text, >> at least I'd add at the beginning: "In a common scenario, a >> Map-Resolver..." >> >> Note that while it is conceivable that a non-LISP-DDT Map-Resolver >> could cache responses to improve performance, >> >> =E2=80=A2 [AR] The discussion on caching or not at the Map-Resolver g= oes >> beyond DDT. We could rephrase this removing the mention to >> "non-LISP-DDT". >> >> The LISP UDP-based messages are the Map-Request and Map-Reply >> messages. When a UDP Map-Request is sent, the UDP source port is >> chosen by the sender and the destination UDP port number is set to >> 4342. When a UDP Map-Reply is sent, the source UDP port number is set >> to 4342 and the destination UDP port number is copied from the source >> port of either the Map-Request or the invoking data packet. >> >> =E2=80=A2 [AR] I would remove the first sentence and re-phrase this >> paragraph as follows: "When a UDP LISP control message is sent and is >> not a direct reply to a previous control message, the UDP source port >> is chosen by the sender and the destination UDP port number is set to >> 4342. When a UDP LISP control message is sent as a direct reply to a >> previous message, the source UDP port number is set to 4342 and the >> destination UDP port number is either set to 4342 or copied from the >> source port of the invoking LISP control message. See the following >> subsections for details." >> >> The UDP checksum is computed and set to non-zero for Map-Request, >> Map-Reply, Map-Register, and Encapsulated Control Message (ECM) >> control messages. >> >> =E2=80=A2 [AR] Shouldn't it be computed for all LISP control messages= ? >> >> EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 >> octets for an IPv6 address family. When a Map-Request is sent by an >> ITR because a data packet is received for a destination where there is >> no mapping entry, the EID-Prefix is set to the destination IP address >> of the data packet, and the 'EID mask-len' is set to 32 or 128 for >> IPv4 or IPv6, respectively. >> >> =E2=80=A2 [AR] We should probably rephrase this to don't limit it to = IPv4/6 >> >> For the latter two cases, the destination IP address used for the >> Map-Request is one of the RLOC addresses from the Locator-Set of the >> Map-Cache entry. >> >> =E2=80=A2 [AR] To refresh map-caches before TTL expiration, the >> destination IP of the Map-Request can be the address of the Map-Server >> if in proxy-reply. This should be considered here. >> >> If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier >> MUST drop the Map-Request. >> >> =E2=80=A2 [AR] This could probably be a SHOULD since we use AFI =3D 0= as >> ITR-RLOC to unsubscribe in PubSub. >> >> EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 >> octets for an IPv6 address family. >> >> =E2=80=A2 [AR] We should mention the possibility for address families >> other than IPv4/6. >> >> The RLOCs in the Map-Reply are globally routable IP addresses of all >> ETRs for the LISP site. >> >> =E2=80=A2 [AR] We should remove "globally" here. Maybe also add a >> "Generally" at the beginning since we might have LCAFs with AFI =3D 0 >> (LISP-VPN encoding of Home-IID for instance). >> >> For example, a requester with two cached EID-Prefixes that are covered >> by a Map-Reply containing one less-specific prefix replaces the entry >> with the less-specific EID-Prefix. >> >> =E2=80=A2 [AR] Not sure if I follow here. Does this mean that a >> less-specific received in a Map-Reply will erase from the map-cache >> previously cached more-specifics that are covered by the >> less-specific? >> >> When more than one EID-Prefix is returned, all SHOULD use the same >> Time to Live value so they can all time out at the same time. When a >> more-specific EID-Prefix is received later, its Time to Live value in >> the Map-Reply record can be stored even when other less-specific >> entries exist. >> >> =E2=80=A2 [AR] We should explain in which cases a more-specific can b= e >> received later. >> >> The Locator-Set MUST be sorted in order of ascending IP address where >> an IPv4 locator address is considered numerically 'less than' an IPv6 >> locator address. >> >> =E2=80=A2 [AR] LCAF addresses (maybe with AFI=3D0) should be discusse= d here as well. >> >> Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register messages. >> >> =E2=80=A2 [AR] Since there may be future cases that benefit from havi= ng a >> non-zero nonce on the Map-Register, I would suggest to rephrase this >> sentence to add a CAN. >> >> E: This is the to-ETR bit. When set to 1, the Map-Server's intention >> is to forward the ECM to an authoritative ETR. >> >> =E2=80=A2 [AR] Can M and E be set at the same time? >> >> LCM: The format is one of the control message formats described in >> this section. At this time, only Map-Request messages are allowed to >> be encapsulated. >> >> =E2=80=A2 [AR] Shall we mention the NAT traversal draft? >> >> A Map-Server's configuration must also include a list of the >> EID-Prefixes for which each ETR is authoritative. >> >> =E2=80=A2 [AR] There may be certain cases where this does not need to= be >> pre-configured. I suggest we replace the "must" with a "should". Note >> that this requirement is already a "should" in section 6. >> >> See [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets >> certain flags (such as those indicating whether the message is >> authoritative and how returned Locators should be treated) when >> sending a Map-Reply on behalf of an ETR. >> >> =E2=80=A2 [AR] It may be useful to discuss at least some of those det= ails here. >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From nobody Fri Nov 17 15:10:53 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D0B126B7F for ; Fri, 17 Nov 2017 15:10:52 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 G75mmynM4M8b for ; Fri, 17 Nov 2017 15:10:50 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 95D5A120724 for ; Fri, 17 Nov 2017 15:10:50 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id b54so3344923otd.8 for ; Fri, 17 Nov 2017 15:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SULLl9F1I8jz5zVnUFv2eusFyScdJSRiLPESGf9YseY=; b=hTu+etNWy4mF2mqDCteInZpSFwzw1LXEhxX3VEbqZzj8/KRbEy1nHlM3LrygNeRVhv WCVhJJY7SwFGF2rr5Vvn0emvca81HlxGJT0Y3retgQsQ843E3JcXTJQmFx3rZS6jclJL +lN3Ivmhcv1sliM6tzlYe//zO5bZ2g4kJNkZ6YWsTyAthLQpWy+Djh9m7ZRaLofqiJiD Nr/b63L6+24uL6IJnsrC2sx4ZYE5d35mriQHEQ5Koxqlw1nzVg8VIEPao4orp+xt9V6f p3R295T1VSCUsPP/iZvUPUwLzX+5gVvwqsQZD6tXkDyZWj4rqaa6uZI/ROxQRrNfwDu/ v85g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SULLl9F1I8jz5zVnUFv2eusFyScdJSRiLPESGf9YseY=; b=otVv41DMdhDcYxOW05ZtZwKNDkkl4Iq6ciOEU9O/dXOYhakxJacDkyhgHp3n+qiDS+ Yf+8BLEWYq/Q62J8j4MeEZKwbVQ2sVdeWt06JnKV7NNKZ50xpjHuNnYmTORI4jbD4won M+ASCRzfl+/zhGj8QevtxLy0+hO3Ge4uKgKUSGUOtlXgBciVR+wNHmcfAn+3axj4raEM EEDOpIb2KXsnRjPgsnQDmDIfhmJauqKQlXlU6njhZPEvWWuupzW/oBHOeJmB9OtAIz0n 0VvS/l7Anb/bbQxsHz1iGFnjhpVDStNEdBcnK297HvjsI7fTxeMi9ttpGINoshnm63Kb TByQ== X-Gm-Message-State: AJaThX4YzE+2Z6R9wXBdclvzgQYpf26saK4XT9bQUry5dbhXsPaO0pD5 Ga8NwYV1KmFrUDEXTxTlWOc= X-Google-Smtp-Source: AGs4zMaosU9k22fWy68ps7uQM59INkXiEFGK7TnokNEh5K0JuPdaxFneDZYZPm32dS/rq1a8Ocpomw== X-Received: by 10.157.72.138 with SMTP id d10mr2839399otf.73.1510960249962; Fri, 17 Nov 2017 15:10:49 -0800 (PST) Received: from [10.151.160.211] (mobile-107-107-187-254.mycingular.net. [107.107.187.254]) by smtp.gmail.com with ESMTPSA id s30sm2231295otd.12.2017.11.17.15.10.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 15:10:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Sat, 18 Nov 2017 07:10:46 +0800 Cc: Erik Nordmark , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <0592F7D1-1D85-429E-A38B-6A7DE511568B@gmail.com> References: <826333ea-ed39-96f5-8047-073ac6aad498@acm.org> To: Alberto Rodriguez-Natal Archived-At: Subject: Re: [lisp] Nonce in PubSub X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 17 Nov 2017 23:10:52 -0000 > I see your point. The draft assumes a security association between the > ITR and the MS in order to authenticate the Map-Notifies. I think this We can=E2=80=99t assume this. That is, a subscriber may not register its EID= -prefixes to the same map-server that the EID-prefix it Is Map-Requesting is registered to. So there would be no security associatio= n between the two.=20 > addresses your valid concern on spoofed Map-Notifies. How this > security association is established is a different discussion :) You need to store the nonce in the Mao-server. See Fabio=E2=80=99s slide of o= ur demo. My implementation does it the way Erik is suggesting.=20 > Note also that, ideally, the Map-Notifies sent as publications should > each have a different nonce so the MS can easily correlate them with > the Map-Notify-Acks received as responses. It can do that with the Map-Request nonce as well.=20 Dino= From nobody Fri Nov 17 16:04:20 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162051271DF for ; Fri, 17 Nov 2017 16:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 n6_9w6hJk8mO for ; Fri, 17 Nov 2017 16:04:16 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 9F42A1250B8 for ; Fri, 17 Nov 2017 16:04:16 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id m11so3644014iti.1 for ; Fri, 17 Nov 2017 16:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0VQrlltB4Y400bG2tT20JE8iMgy+zB3uOx7WJGg9S74=; b=igJoz9LfNZFdcv0ZQS34B9AORSX5k7KwPjmNZz6syvb/9fFDyFk2zxjmJpvLvKCbBI tDVVftNyYoKrOgBe8fZMyc6bUNn+296Sczu0eBvj5Bh8BKxAW6bftSgU5sQSs25sylSE UShdjxi2Y9RGSR1Z/0t2mxtavDz9xvMjHV88v/mbbMpX2m4QeWUmNzyhhzpwD9CuBjM5 BpBohFLrSFRIm9zVyu26xuVGW+8ouWS0qEnk68D9a5xCPVETjMdjnrF6vofPF9xlr8kI GUKaEDfryjKJ5gwfBTjISugCjQcsRaoXT6tX1+1X+unIDeglgLMrrKFI39aU/YN7LT+N fNOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0VQrlltB4Y400bG2tT20JE8iMgy+zB3uOx7WJGg9S74=; b=pR5jrx3ascEomgJltLz+UOLeu2+T/8jdEYVi+rnGtJRkoXrNqnr4WRENIcU3SZZR5N jwLoMsanvJNvhnEYhiwTLzRuKcdNHK4qmJ59UiO0Pum/XaRisjchqLTu70OxmrZV6Yya 90s4Lc1QN44MzoaskB1MQHI4nA2nXucPCrOuy8W3VIsu8JMVdC5ifgmJgUt0Db8nY+k1 H6Fvq/iAb2PQxaWuK0h6PQb0zrdtz0bXHzj3IcJegl13EIHk5mFngH/SB8+B1mpZezGs ksQxSw1f2Rjo4OhPHHvKf5RkrmjWcIiZKN1NyuULpuNw7gu+CxgCACc5UA7/Dy2nkMpE XCZw== X-Gm-Message-State: AJaThX40YR5S9RPzNtdvR8vLQi/u1Zdz/UmtulLB/o3NCVM5z6dZoJXR 63Lfgrk/U3a52kiLaoHfv59sUrReMKjTjFlKu2c= X-Google-Smtp-Source: AGs4zMZplwZW5fSkvmMsijZNX/9DgUszaZyjGsO7AD+Qb9dhTzhfV3lbppv+T7rcC/ECt64Bwmuzoc5dokjYJIcA7hw= X-Received: by 10.36.252.68 with SMTP id b65mr9209714ith.151.1510963455766; Fri, 17 Nov 2017 16:04:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.181.70 with HTTP; Fri, 17 Nov 2017 16:03:55 -0800 (PST) In-Reply-To: <0592F7D1-1D85-429E-A38B-6A7DE511568B@gmail.com> References: <826333ea-ed39-96f5-8047-073ac6aad498@acm.org> <0592F7D1-1D85-429E-A38B-6A7DE511568B@gmail.com> From: Alberto Rodriguez-Natal Date: Fri, 17 Nov 2017 16:03:55 -0800 Message-ID: To: Dino Farinacci Cc: Erik Nordmark , "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lisp] Nonce in PubSub X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Nov 2017 00:04:18 -0000 Then I'm afraid that your implementation is not following the current specification. But worry not, we can update -02 with Erik's suggestion so your implementation and the draft are in sync :) Alberto From nobody Fri Nov 17 17:10:31 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB872128D16 for ; Fri, 17 Nov 2017 17:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qScBrH8xVwaE for ; Fri, 17 Nov 2017 17:10:28 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 64E9F120725 for ; Fri, 17 Nov 2017 17:10:28 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id x20so2287396ywg.4 for ; Fri, 17 Nov 2017 17:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bK17pZC2cOBCBPBWoIEGAvHd1OCA9vG1DuYsQhRUDos=; b=qtgVYPqKdDXS5s3DrZcizB/aTPGmhgXXEq26W8xz9WY4Csrgx44lcKX0tyhZkun0Ig BlGVD7xUBOJ1bl5J69Byl3Fl9YgvdUffyxkX0hg+ZPb6+abruF29CFDMP9AwSAqtCOFG oopEhhuS0cBrITxfhprg6q9xcccq4rYmP4fDfyYj8qEtICO2kdJK94+c3U38bCKaqY/1 wniyD4LcfZPd92fnQfK+SvMuZvpPI+m6BFgj+vReBZWoSi6gJ23Rl7X27enyEKyDkt/h ABgwduhyqRk3HkOO5VA/3VB92syrqjD9zEPn7S6N74kW5qkSapDR6OTl6wRBz21hEh3F s/OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bK17pZC2cOBCBPBWoIEGAvHd1OCA9vG1DuYsQhRUDos=; b=ZZeiXRdL/r02y/iDGT+xO/9plmHKzzP/65VoP+lchq5oQW2ww2lyPc+wnMOKISOAfg TfHgm6u0gaCSiqDesKEnVeN5xZDwKrHfrG5JoEFc66Q66/VuPJ7DdA1io7kKMXbJOklm BZRqjj7Gn/m8gx8/Xqjv/8OrHJdLZKCEAi5/oAk3MCTh9e2NK7469uLG250Mp48VB7IE avqTMiKWoZ3th+QeqZzwUl+Vo1HRJDSfn/FDvhroHu5hjo7RfO1OrRHaQIRRi1pwllAA py5a3iZX0qHkBn9lkeVDn6389V8/y/Ni97nOgiPB2y/iJ59qyv7T69BTiV36PwZgf7/b ffww== X-Gm-Message-State: AJaThX4nWMZJJdRUJs3qnyI0D7JUvRXRK2TZFxmDLxrfqr51Mk6sNHY0 RC+aY+FpDwQVjmnQJCdioR0= X-Google-Smtp-Source: AGs4zMaMojMRf0BlXGTzPaJzb0uSs52UHAoHRVRGStgIQFoCeb5x64uR49SRhFbmV89nJ/X92kQdQw== X-Received: by 10.13.244.193 with SMTP id d184mr4667644ywf.418.1510967427555; Fri, 17 Nov 2017 17:10:27 -0800 (PST) Received: from ?IPv6:2600:380:5235:e5b2:60b7:bfd3:7def:2608? ([2600:380:5235:e5b2:60b7:bfd3:7def:2608]) by smtp.gmail.com with ESMTPSA id x13sm2157017ywx.36.2017.11.17.17.10.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 17:10:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Sat, 18 Nov 2017 09:10:20 +0800 Cc: Erik Nordmark , "lisp@ietf.org list" Content-Transfer-Encoding: 7bit Message-Id: <9146B201-E108-40FA-B883-9E00BE039344@gmail.com> References: <826333ea-ed39-96f5-8047-073ac6aad498@acm.org> <0592F7D1-1D85-429E-A38B-6A7DE511568B@gmail.com> To: Alberto Rodriguez-Natal Archived-At: Subject: Re: [lisp] Nonce in PubSub X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Nov 2017 01:10:30 -0000 > Then I'm afraid that your implementation is not following the current Well there is one of two ways to fix that. :-) > specification. But worry not, we can update -02 with Erik's suggestion > so your implementation and the draft are in sync :) Thanks a bunch. Dino From nobody Tue Nov 21 06:49:49 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9C12949A for ; Tue, 21 Nov 2017 06:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wSXfFnv1JnBa for ; Tue, 21 Nov 2017 06:49:44 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3634B1294A1 for ; Tue, 21 Nov 2017 06:49:43 -0800 (PST) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vALEna2n005744; Tue, 21 Nov 2017 15:49:36 +0100 Received: from [147.83.35.39] (sirius.ac.upc.es [147.83.35.39]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 9B47E1985; Tue, 21 Nov 2017 15:49:31 +0100 (CET) To: "Vina Ermagan (vermagan)" , Dino Farinacci Cc: "lisp@ietf.org" References: <2b946dce-7c33-5317-8f3b-9ffd2568381e@ac.upc.edu> From: =?UTF-8?Q?Albert_L=c3=b3pez?= Message-ID: Date: Tue, 21 Nov 2017 15:49:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9A6C65A5C08596A015DA1165" Content-Language: en-US Archived-At: Subject: Re: [lisp] draft-ermagan-lisp-nat-traversal question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 21 Nov 2017 14:49:48 -0000 This is a multi-part message in MIME format. --------------9A6C65A5C08596A015DA1165 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, I have some more questions regarding this draft. * 3.1.  LISP NAT Traversal Overview /   The ETR encapsulates the Map-Register message in a LISP ECM header destined// //   to the RTR's RLOC.  The RTR strips the LISP ECM header, re-originates// //   the Map-Register message, and sends it to the Map-Server. /At this point, it seems to me that the RTR sends a simple Map Register (like it does  it previous version of the draft) instead of an Encap Map Register * 4.3.  LISP Map-Register Message /The 6th bit in the ECM LISP header is allocated as the "R"// //   bit.  The R bit indicates that the encapsulated Map-Register is to be// //   processed by an RTR.  The 7th bit in the ECM header is allocated as// //   the "N" bit. /I suppose that are the 6th and 7th bit after the Type field otherwise it overlaps with other flag bits. Maybe it could be indicated in the draft. * /4.4.  LISP Map-Notify// // //   MS-RTR Authentication Data: The message digest used from the output// //   of the Message Authentication Code (MAC) algorithm. //*The entire Map-*//* *//*   Notify payload*//is authenticated./ Do we also refer to  the inner IP and UDP header with entire Map Notify payload? Why the RTR is changing the address of the inner IP header of ECM? Is not possible to use the external IP header to obtain required information like the RTR address in the MS ?     1- Encap Map Reg -> int src ip:  From ETR local locator to RTR address     2- Data Map Notify -> int dst IP:  From RTR address to ETR local locator / / Best regards Albert López El 08/11/17 a les 21:33, Vina Ermagan (vermagan) ha escrit: > Hi Albert, > > ³Map Register TTL² in the referenced paragraph is indeed the TTL for which > a Map Register stays valid in a Map Server. Suggested time in the RFC for > periodic Map Registers is 1 minute. And MS will expire the registration > after 3 minutes if it does not receive a renewal. So this TTL in RTR > should be set no larger than 3 minutes, and no smaller than 1 minute. > Unfortunately NAPT devices don¹t have a standard TTL for expiring their > address associations; some use 2 minutes as the threshold. So the 3 minute > recommendation for expiring a Map Register seems suitable here. > > Hope this clarifies it. > > Best, > Vina > > > On 11/6/17, 1:01 AM, "lisp on behalf of Albert López" > wrote: > >> In that case, I think that It would be better if the validation time / >> expiration time of the locator associated with the ECM-ed Map Register & >> ECM-ed Map Notify is related with the periodic time of sending ECM-ed >> Map Registers. >> Usually a hole in the nat box is less than two minutes so we send >> periodic ECM Mag register to maintain this hole opened apart from >> maintaining the status in the Map Server. If we use the TTL of the >> record to maintain an entry in the Map Cacahe of the RTR, it is possible >> we maintain an entry which is no longer valid or send packets to an >> invalid rloc. What do you think? >> >> Regards >> >> Albert >> >> El 03/11/17 a les 18:38, Dino Farinacci ha escrit: >>> The TTL in the Map-Register is the TTL returned in Map-Replies. So it >>> is the expiry time for a map-cache entry. Note it is the ³Record TTL² in >>> the EID-record which both appear in Map-Register and Map-Reply messages. >>> >>> Dino >>> >>>> On Nov 3, 2017, at 1:35 AM, Albert López wrote: >>>> >>>> Dear all, >>>> >>>> In section 5.3 of the draft draft-ermagan-lisp-nat-traversal which >>>> describe the RTR processing, it says that when the RTR receive and >>>> ECM-ed Map Notify, once it is validated, it changes the state of the >>>> associated map-cache entry to verified for the duration of the Map >>>> Register TTL. What does it mean by Map Register TTL? it means the TTL >>>> of the record of the Map Register or it is the same concept of the Map >>>> Register TTL of the Map Server which is 3 minutes? If I understand >>>> correctly, if we don't receive more Encap Map Register / Map Notify to >>>> renew this verified period, the map-cache entry of the RTR expires, at >>>> least the locator of the map-cache entry associated with the Encap Map >>>> register. >>>> >>>> "Once the authenticity of the message is verified, >>>> RTR can confirm that the Map-Register message for the ETR with the >>>> matching xTR-ID was accepted by the Map-Server. At this point the >>>> RTR can change the state of the associated map-cache entry to >>>> verified for the duration of the Map-Register TTL" >>>> >>>> Thank you in advance. >>>> >>>> Albert López >>>> >>>> >>>> _______________________________________________ >>>> 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 --------------9A6C65A5C08596A015DA1165 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi all,

I have some more questions regarding this draft.

* 3.1.  LISP NAT Traversal Overview

   The ETR encapsulates the Map-Register message in a LISP ECM header destined
   to the RTR's RLOC.  The RTR strips the LISP ECM header, re-originates
   the Map-Register message, and sends it to the Map-Server.

At this point, it seems to me that the RTR sends a simple Map Register (like it does
 it previous version of the draft) instead of an Encap Map Register

* 4.3.  LISP Map-Register Message

   The 6th bit in the ECM LISP header is allocated as the "R"
   bit.  The R bit indicates that the encapsulated Map-Register is to be
   processed by an RTR.  The 7th bit in the ECM header is allocated as
   the "N" bit.

I suppose that are the 6th and 7th bit after the Type field otherwise it overlaps
with other flag bits. Maybe it could be indicated in the draft.


*  4.4.  LISP Map-Notify

   MS-RTR Authentication Data: The message digest used from the output
   of the Message Authentication Code (MAC) algorithm.  The entire Map-
   Notify payload is authenticated.

Do we also refer to  the inner IP and UDP header with entire Map Notify payload?


Why the RTR is changing the address of the inner IP header of ECM? Is not possible to use
the external IP header to obtain required information like the RTR address in the MS ?

    1- Encap Map Reg -> int src ip:  From ETR local locator to RTR address
    2- Data Map Notify -> int dst IP:  From RTR address to ETR local locator

Best regards

Albert López

El 08/11/17 a les 21:33, Vina Ermagan (vermagan) ha escrit:
Hi Albert,

³Map Register TTL² in the referenced paragraph is indeed the TTL for which
a Map Register stays valid in a Map Server. Suggested time in the RFC for
periodic Map Registers is 1 minute. And MS will expire the registration
after 3 minutes if it does not receive a renewal. So this TTL in RTR
should be set no larger than 3 minutes, and no smaller than 1 minute.
Unfortunately NAPT devices don¹t have a standard TTL for expiring their
address associations; some use 2 minutes as the threshold. So the 3 minute
recommendation for expiring a Map Register seems suitable here.

Hope this clarifies it.

Best,
Vina


On 11/6/17, 1:01 AM, "lisp on behalf of Albert López"
<lisp-bounces@ietf.org on behalf of alopez@ac.upc.edu> wrote:


In that case, I think that It would be better if the validation time /
expiration time of the locator associated with the ECM-ed Map Register &
ECM-ed Map Notify is related with the periodic time of sending ECM-ed
Map Registers.
Usually a hole in the nat box is less than two minutes so we send
periodic ECM Mag register to maintain this hole opened apart from
maintaining the status in the Map Server. If we use the TTL of the
record to maintain an entry in the Map Cacahe of the RTR, it is possible
we maintain an entry which is no longer valid or send packets to an
invalid rloc.  What do you think?

Regards

Albert

El 03/11/17 a les 18:38, Dino Farinacci ha escrit:

The TTL in the Map-Register is the TTL returned in Map-Replies. So it
is the expiry time for a map-cache entry. Note it is the ³Record TTL² in
the EID-record which both appear in Map-Register and Map-Reply messages.

Dino


On Nov 3, 2017, at 1:35 AM, Albert López <alopez@ac.upc.edu> wrote:

Dear all,

In section 5.3 of the draft  draft-ermagan-lisp-nat-traversal which
describe the RTR processing, it says that when the RTR receive and
ECM-ed Map Notify, once it is validated, it changes the state of the
associated map-cache entry to verified for the duration of the Map
Register TTL.  What does it mean by Map Register TTL?  it means the TTL
of the record of the Map Register or it is the same concept of the Map
Register TTL of the Map Server which is 3 minutes? If I understand
correctly, if we don't receive more Encap Map Register / Map Notify to
renew this verified period, the map-cache entry of the RTR expires, at
least the locator of the map-cache entry associated with the Encap Map
register.

   "Once the authenticity of the message is verified,
   RTR can confirm that the Map-Register message for the ETR with the
   matching xTR-ID was accepted by the Map-Server.  At this point the
   RTR can change the state of the associated map-cache entry to
   verified for the duration of the Map-Register TTL"

Thank you in advance.

Albert López


_______________________________________________
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


    

    

  


--------------9A6C65A5C08596A015DA1165--


From nobody Tue Nov 28 17:12:40 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48765128656 for ; Tue, 28 Nov 2017 17:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level: 
X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 SWcMfHV2Ww0K for ; Tue, 28 Nov 2017 17:12:34 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 11308120724 for ; Tue, 28 Nov 2017 17:12:34 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id b54so1646478otd.8 for ; Tue, 28 Nov 2017 17:12:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=j3JMvnh5ANYaGm1yH5+qc10BEqQf+LrwEWClxNDAovA=; b=j3ZffYFbT192OliMkbKJbhbeO90yWtQeLIudtQAwm5AcHA7OYYhM/YRHjSfiYHxQP4 1SJiEAokjLIN/YEoqCl2fsz35loYQ+XbSOnKsLF+wcji1JTPLjU3YaUMYUfN0H6hoY3u MmudGph9OaU2GP4oWCxy1QGbNNEyj+t5gW0PYziCWMi1cLUhZXfNp/a15Vb7yJl844vX Bie2YE79hLkBujUqRWBkoiJQSn3M9rT7gNNbE6hwY70pwbH/iMXsgdBeGf34Oi3MZefj qnV1nfDyI+mtzTcNuHs1MOaS24+9RY26eD2F87PkQkiom3gHn/Wlaj3q001gcYcLCnyF hslw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=j3JMvnh5ANYaGm1yH5+qc10BEqQf+LrwEWClxNDAovA=; b=f0/vFnFVx+qb8gzotsjaYL7+ZsHOgyFTF9qbwlM8UTrtyzmDMQqBXBElpVisBIUcw9 cjSKWnhvqXwUwzxt1d0RhtFnlLlY58DA6KL89+EkYxqvYNTn50pN45m5Xoy16r350B8c 1XF1amFRV6nLNzc3Ib0MRqF84d/LA/btptVKlxumqYiX56gIuA1JrabOiyLu6qYInzM3 so1L5oyfTOOtYX/AumyeP578uMFtbBaG8WWA5IbQ2qKbZZBt64PwRjcSJi7FByCPUdZI 2Tm2zC3dVwPKMfisc3RUTBPF2Ux4QpUTYHxHiuFBAXDOcjuy2ukRNJ00FouUFjMwek0M jj/w==
X-Gm-Message-State: AJaThX49ulXLGa592Yif7l/gu4pB3WgHUUCBr9JkGLTdmbJ90UzqBoSX lNeD3wfIauPntSzCmtgOlU4WB2Uz
X-Google-Smtp-Source: AGs4zMact325LH+YWzNNqmDR69eLYbGhS4pPoM1S766/YyUtc1a3YCG5Vo5NdryeS2kXm3qxjlhcaw==
X-Received: by 10.157.32.130 with SMTP id x2mr1039762ota.198.1511917953172; Tue, 28 Nov 2017 17:12:33 -0800 (PST)
Received: from dino-macbook.attlocal.net (adsl-108-94-3-201.dsl.pltn13.sbcglobal.net. [108.94.3.201]) by smtp.gmail.com with ESMTPSA id w4sm285421ote.21.2017.11.28.17.12.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 17:12:31 -0800 (PST)
From: Dino Farinacci 
Message-Id: <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com>
Content-Type: multipart/mixed; boundary="Apple-Mail=_DBF0C28B-2AF8-4A3E-9415-93AA2CB96858"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Date: Tue, 28 Nov 2017 17:12:21 -0800
In-Reply-To: 
Cc: "lisp@ietf.org list" , Dino Farinacci 
To: Alberto Rodriguez-Natal 
References: 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [lisp] Review of RFC6833bis
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 01:12:39 -0000

--Apple-Mail=_DBF0C28B-2AF8-4A3E-9415-93AA2CB96858
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> Hi all,
>=20
> Wanted to send this before the meeting on Friday. I just completed a
> review of 6833bis, you can find my comments below. Like last time,
> extracts from the draft are copied and followed by my comments.
>=20
> Thanks,
> Alberto

Thanks again Alberto for your comments. See my responses inline and a =
-07 diff file.

> Map-Resolver:  A network infrastructure component that accepts LISP
> Encapsulated Map-Requests,
>=20
>    =E2=80=A2 [AR] We could remove "Encapsulated" and just use =
"Map-Requests".
> A Map-Resolver may accept non-encapsulated Map-Requests as well.

No, they are =E2=80=9Ccontrol-plane=E2=80=9D encapsulated. I=E2=80=99ll =
make that more clear.

> Map-Register message:   A LISP message sent by an ETR to a Map-Server
> to register its associated EID-Prefixes.  In addition to the set of
> EID-Prefixes to register, the message includes one or more RLOCs to be
> used by the Map-Server when forwarding Map-Requests (re-formatted as
> Encapsulated Map-Requests) received through the database mapping
> system.
>=20
>    =E2=80=A2 [AR] This may give the impression that the RLOCs on the
> Map-Register are only to forward Map-Requests, which is not the case
> in proxy-reply mode. I would suggest we rephrase this text as follows:
> "In addition to the set of EID-Prefixes to register, the message
> includes one or more RLOCs to be used to reach the ETR. The Map-Server
> uses these RLOCs when it has to forward Map-Requests (potentially
> re-formatted as Encapsulated Map-Requests) received through the
> database mapping system.=E2=80=9D

I reworded.=20

> Map-Notify message:   A LISP message sent by a Map-Server to an ETR
>=20
>    =E2=80=A2 [AR] I would replace "ETR" with "xTR" so we cover the =
PubSub
> behavior as well.

Can=E2=80=99t do that because an ITR does not get Map-Notifies as a =
response to a Map-Register. But I will add that ITRs get Map-Notifies to =
inform them of RLOC-set changes (for pubsub and signal-free-multicast =
use-cases).

>=20
> For definitions of other terms -- notably Map-Request, Map-Reply,
> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please
> consult the LISP specification [I-D.ietf-lisp-rfc6830bis].
>=20
>    =E2=80=A2 [AR] I think that the definitions for Map-Request and =
Map-Reply
> should be moved here, and probably we should include the definition
> for Map-Notify-Ack as well. 6830bis should reference 6833bis for
> control-plane messages, not the other way around.

They did. But the text you identified above was not changed. Changed =
now.
=20
> A Map-Register message contains a list of EID-Prefixes plus a set of
> RLOCs that can be used to reach the ETR when a Map-Server needs to
> forward a Map-Request to it.
>=20
>    =E2=80=A2 [AR] Since proxy-reply is a common case, I'd not =
constrain the
> meaning of the RLOCs in the Map-Register. I'd remove the last part of
> the sentence that says "when a Map-Server needs to forward a
> Map-Request to it.=E2=80=9D

Agree.

> A Map-Resolver receives Encapsulated Map-Requests from its client ITRs
> and uses a mapping database system to find the appropriate ETR to
> answer those requests.
>=20
>    =E2=80=A2 [AR] A MR can receive Map-Requests that don't come from =
ITR
> and/or that are not encapsulated. If we don't want to change the text,
> at least I'd add at the beginning: "In a common scenario, a
> Map-Resolver=E2=80=A6"

I don=E2=80=99t think we should change this. The lig document indicates =
that a lig client can send Map-Requests. This document is for support of =
a data-plane.

> Note that while it is conceivable that a non-LISP-DDT Map-Resolver
> could cache responses to improve performance,
>=20
>    =E2=80=A2 [AR] The discussion on caching or not at the Map-Resolver =
goes
> beyond DDT. We could rephrase this removing the mention to
> "non-LISP-DDT=E2=80=9D.

Agree. Changed.

> The LISP UDP-based messages are the Map-Request and Map-Reply
> messages.  When a UDP Map-Request is sent, the UDP source port is
> chosen by the sender and the destination UDP port number is set to
> 4342.  When a UDP Map-Reply is sent, the source UDP port number is set
> to 4342 and the destination UDP port number is copied from the source
> port of either the Map-Request or the invoking data packet.
>=20
>    =E2=80=A2 [AR] I would remove the first sentence and re-phrase this
> paragraph as follows: "When a UDP LISP control message is sent and is
> not a direct reply to a previous control message, the UDP source port
> is chosen by the sender and the destination UDP port number is set to
> 4342.  When a UDP LISP control message is sent as a direct reply to a
> previous message, the source UDP port number is set to 4342 and the
> destination UDP port number is either set to 4342 or copied from the
> source port of the invoking LISP control message. See the following
> subsections for details.=E2=80=9D

This is not really true. There are too many cases with respect to =
NAT-traversal that make things more complicated. I think we need to be =
specific about each message and not generalize it. Plus, Map-Notify =
messages are response and unsolicited so they vary on whether the =
destination or source port is 4342.=20

I have added text to identify each message that follow the Map-Request =
and Map-Reply port rules.

> The UDP checksum is computed and set to non-zero for Map-Request,
> Map-Reply, Map-Register, and Encapsulated Control Message (ECM)
> control messages.
>=20
>    =E2=80=A2 [AR] Shouldn't it be computed for all LISP control =
messages?

Yes. Added text.

> EID-Prefix:  This prefix is 4 octets for an IPv4 address family and 16
> octets for an IPv6 address family.  When a Map-Request is sent by an
> ITR because a data packet is received for a destination where there is
> no mapping entry, the EID-Prefix is set to the destination IP address
> of the data packet, and the 'EID mask-len' is set to 32 or 128 for
> IPv4 or IPv6, respectively.
>=20
>    =E2=80=A2 [AR] We should probably rephrase this to don't limit it =
to IPv4/6

Good point. Generalized the text a bit.

> For the latter two cases, the destination IP address used for the
> Map-Request is one of the RLOC addresses from the Locator-Set of the
> Map-Cache entry.
>=20
>    =E2=80=A2 [AR] To refresh map-caches before TTL expiration, the
> destination IP of the Map-Request can be the address of the Map-Server
> if in proxy-reply. This should be considered here.

This is not true. The Map-Request has an IP header but it is =
encapsulated in an ECM and that IP header destination address is the =
*Map-Resolvers*.

> If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier
> MUST drop the Map-Request.
>=20
>    =E2=80=A2 [AR] This could probably be a SHOULD since we use AFI =3D =
0 as
> ITR-RLOC to unsubscribe in PubSub.

An AFI=3D0 Is an RLOC address.

> EID-Prefix:  This prefix is 4 octets for an IPv4 address family and 16
> octets for an IPv6 address family.
>=20
>    =E2=80=A2 [AR] We should mention the possibility for address =
families
> other than IPv4/6.

Have that covered.

> The RLOCs in the Map-Reply are globally routable IP addresses of all
> ETRs for the LISP site.
>=20
>    =E2=80=A2 [AR] We should remove "globally" here. Maybe also add a
> "Generally" at the beginning since we might have LCAFs with AFI =3D 0
> (LISP-VPN encoding of Home-IID for instance).

Removed =E2=80=9Cglobally=E2=80=9D. I don=E2=80=99t understand your =
other =E2=80=9CGenerally=E2=80=9D comment.

> For example, a requester with two cached EID-Prefixes that are covered
> by a Map-Reply containing one less-specific prefix replaces the entry
> with the less-specific EID-Prefix.
>=20
>    =E2=80=A2 [AR] Not sure if I follow here. Does this mean that a
> less-specific received in a Map-Reply will erase from the map-cache
> previously cached more-specifics that are covered by the
> less-specific?

Yes, because if the Map-Reply returned a more-specific with the =
less-specific, then it would be replaced so the less-specific replaces =
the more-specifics that ARE NOT in the Map-Reply.

> When more than one EID-Prefix is returned, all SHOULD use the same
> Time to Live value so they can all time out at the same time.  When a
> more-specific EID-Prefix is received later, its Time to Live value in
> the Map-Reply record can be stored even when other less-specific
> entries exist.
>=20
>    =E2=80=A2 [AR] We should explain in which cases a more-specific can =
be
> received later.

I don=E2=80=99t follow. Each EID-record will contain a TTL for the =
length prefix that is encoded. So the new Map-Reply TTL will be used for =
any length entry (and in this case the more-specific).

> The Locator-Set MUST be sorted in order of ascending IP address where
> an IPv4 locator address is considered numerically 'less than' an IPv6
> locator address.
>=20
>    =E2=80=A2 [AR] LCAF addresses (maybe with AFI=3D0) should be =
discussed here as well.

It is discussed in the LCAF draft. Don=E2=80=99t want to repeat it.

> Nonce:  This 8-octet 'Nonce' field is set to 0 in Map-Register =
messages.
>=20
>    =E2=80=A2 [AR] Since there may be future cases that benefit from =
having a
> non-zero nonce on the Map-Register, I would suggest to rephrase this
> sentence to add a CAN.

Not until we identify and describe the use-case. No point to speculate. =
But note, if a Map-Notify is returned, the nonce should be non-zero. =
I=E2=80=99ll fix that.

> E:  This is the to-ETR bit.  When set to 1, the Map-Server's intention
> is to forward the ECM to an authoritative ETR.
>=20
>    =E2=80=A2 [AR] Can M and E be set at the same time?

It can. M bit is set to indicate to avoid DDT procedures. The E bit =
tells the Map-Server what to do with the Map-Request.

> LCM:  The format is one of the control message formats described in
> this section.  At this time, only Map-Request messages are allowed to
> be encapsulated.
>=20
>    =E2=80=A2 [AR] Shall we mention the NAT traversal draft?

No, this is an ECM, not a data-encapsulated control-message.

> A Map-Server's configuration must also include a list of the
> EID-Prefixes for which each ETR is authoritative.
>=20
>    =E2=80=A2 [AR] There may be certain cases where this does not need =
to be
> pre-configured. I suggest we replace the "must" with a "should". Note
> that this requirement is already a "should" in section 6.

Agree.

> See [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets
> certain flags (such as those indicating whether the message is
> authoritative and how returned Locators should be treated) when
> sending a Map-Reply on behalf of an ETR.
>=20
>    =E2=80=A2 [AR] It may be useful to discuss at least some of those =
details here.

It does following this.

I also made the document RFC2119 compliant where the terms for not =
capitalized. There were a few places.

Thanks again,
Dino


--Apple-Mail=_DBF0C28B-2AF8-4A3E-9415-93AA2CB96858
Content-Disposition: attachment;
	filename=rfcdiff-rfc6833bis.html
Content-Type: text/html;
	x-unix-mode=0644;
	name="rfcdiff-rfc6833bis.html"
Content-Transfer-Encoding: quoted-printable



=20
  =20
  =20
  Diff: draft-ietf-lisp-rfc6833bis-06.txt - =
draft-ietf-lisp-rfc6833bis-07.txt=20
  =20
     =20
=20
=20
  =20
  =20
      =

      =

      =

      
< draft-ietf-lisp-rfc6833bis-06.txt  =
 draft-ietf-lisp-rfc6833bis-07.txt >
 =


      
Network Working =
Group                                          V. Fuller =
Network Working Group                           =
               V. Fuller

      
Internet-Draft    =
                                          D. Farinacci Internet-Draft                                           =
   D. Farinacci

      
Intended status: =
Standards Track                           Cisco Systems =
Intended status: Standards Track                =
           Cisco Systems

      

      
Expires: April 8, 2018                                 A. =
Cabellos (Ed.) Expires: June 1, 2018                                  A. =
Cabellos (Ed.)

      
                  =
                                     UPC/BarcelonaTech                                                        =
UPC/BarcelonaTech

      

      
                =
                                         October =
5, 2017                        =
                                November =
28, 2017

      
 =


      
          =
Locator/ID Separation Protocol (LISP) Control-Plane           Locator/ID Separation Protocol (LISP) =
Control-Plane

      

      
                =
     draft-ietf-lisp-rfc6833bis-06 =
                     =
draft-ietf-lisp-rfc6833bis-07

      
 =


      
Abstract =
Abstract

      
 =


      
   This document =
describes the Control-Plane and Mapping Service for the =
   This document describes the Control-Plane =
and Mapping Service for the

      
   Locator/ID =
Separation Protocol (LISP), implemented by two new types =
   Locator/ID Separation Protocol (LISP), =
implemented by two new types

      
   of =
LISP-speaking devices -- the LISP Map-Resolver and LISP =
Map-Server    of LISP-speaking devices =
-- the LISP Map-Resolver and LISP Map-Server

      
   -- that =
provides a simplified "front end" for one or more Endpoint ID =
   -- that provides a simplified "front end" =
for one or more Endpoint ID

      
   to Routing =
Locator mapping databases.    to =
Routing Locator mapping databases.

      
 =


      
   By using this =
control-plane service interface and communicating with    By using this control-plane service interface and =
communicating with

      
 =


      
skipping to =
change at =
page 1, line 46 =C2=B6 =
skipping to change at page 1, line 46 =C2=B6

      
   =
Internet-Drafts are working documents of the Internet =
Engineering    Internet-Drafts are =
working documents of the Internet Engineering

      
   Task Force =
(IETF).  Note that other groups may also distribute    Task Force (IETF).  Note that other groups may also =
distribute

      
   working =
documents as Internet-Drafts.  The list of current Internet- =
   working documents as Internet-Drafts.  The =
list of current Internet-

      
   Drafts is at =
https://datatracker.ietf.org/drafts/current/.    Drafts is at =
https://datatracker.ietf.org/drafts/current/.

      
 =


      
   =
Internet-Drafts are draft documents valid for a maximum of six =
months    Internet-Drafts are draft =
documents valid for a maximum of six months

      
   and may be =
updated, replaced, or obsoleted by other documents at any =
   and may be updated, replaced, or obsoleted =
by other documents at any

      
   time.  It is =
inappropriate to use Internet-Drafts as reference    time.  It is inappropriate to use Internet-Drafts as =
reference

      
   material or to =
cite them other than as "work in progress."    material or to cite them other than as "work in =
progress."

      
 =


      

      
   This =
Internet-Draft will expire on April 8, =
2018.    This Internet-Draft will =
expire on June 1, 2018.

      
 =


      
Copyright =
Notice Copyright Notice

      
 =


      
   Copyright (c) =
2017 IETF Trust and the persons identified as the    Copyright (c) 2017 IETF Trust and the persons =
identified as the

      
   document =
authors.  All rights reserved.    =
document authors.  All rights reserved.

      
 =


      
   This document =
is subject to BCP 78 and the IETF Trust's Legal    This document is subject to BCP 78 and the IETF =
Trust's Legal

      
   Provisions =
Relating to IETF Documents    =
Provisions Relating to IETF Documents

      
   =
(https://trustee.ietf.org/license-info) in effect on the date =
of    =
(https://trustee.ietf.org/license-info) in effect on the date of

      
   publication of =
this document.  Please review these documents    publication of this document.  Please review these =
documents

      
 =


      
skipping to =
change at =
page 2, line 51 =C2=B6 =
skipping to change at page 2, line 51 =C2=B6

      
   7.  IANA =
Considerations . . . . . . . . . . . . . . . . . . . . .  33 =
   7.  IANA Considerations . . . . . . . . . . =
. . . . . . . . . . .  33

      
     7.1.  LISP =
Packet Type Codes  . . . . . . . . . . . . . . . . .  33 =
     7.1.  LISP Packet Type Codes  . . . . . . =
. . . . . . . . . . .  33

      
     7.2.  LISP =
ACT and Flag Fields  . . . . . . . . . . . . . . . .  33 =
     7.2.  LISP ACT and Flag Fields  . . . . . =
. . . . . . . . . . .  33

      
     7.3.  LISP =
Address Type Codes . . . . . . . . . . . . . . . . .  34 =
     7.3.  LISP Address Type Codes . . . . . . =
. . . . . . . . . . .  34

      
     7.4.  LISP =
Algorithm ID Numbers . . . . . . . . . . . . . . . .  34 =
     7.4.  LISP Algorithm ID Numbers . . . . . =
. . . . . . . . . . .  34

      
   8.  References =
 . . . . . . . . . . . . . . . . . . . . . . . . .  34    8.  References  . . . . . . . . . . . . . . . . . . . =
. . . . . .  34

      
     8.1.  =
Normative References  . . . . . . . . . . . . . . . . . .  34 =
     8.1.  Normative References  . . . . . . . =
. . . . . . . . . . .  34

      
     8.2.  =
Informative References  . . . . . . . . . . . . . . . . .  36 =
     8.2.  Informative References  . . . . . . =
. . . . . . . . . . .  36

      
   Appendix A.  =
Acknowledgments  . . . . . . . . . . . . . . . . . .  39 =
   Appendix A.  Acknowledgments  . . . . . . . =
. . . . . . . . . . .  39

      
   Appendix B.  =
Document Change Log  . . . . . . . . . . . . . . . .  39 =
   Appendix B.  Document Change Log  . . . . . =
. . . . . . . . . . .  39

      

      
     B.1.  =
Changes to draft-ietf-lisp-rfc6833bis-06  =
. . . . . . . .  39      B.1.  =
Changes to draft-ietf-lisp-rfc6833bis-07  =
. . . . . . . .  39

      
     B.2.  =
Changes to draft-ietf-lisp-rfc6833bis-05  =
. . . . . . . .  39      B.2.  =
Changes to draft-ietf-lisp-rfc6833bis-06  =
. . . . . . . .  39

      
     B.3.  =
Changes to draft-ietf-lisp-rfc6833bis-04  =
. . . . . . . .  39      B.3.  Changes to draft-ietf-lisp-rfc6833bis-05  . . . . . . . .  =
40

      
     B.4.  =
Changes to draft-ietf-lisp-rfc6833bis-03  =
. . . . . . . .  40      B.4.  =
Changes to draft-ietf-lisp-rfc6833bis-04  =
. . . . . . . .  40

      
     B.5.  =
Changes to draft-ietf-lisp-rfc6833bis-02  =
. . . . . . . .  40      B.5.  =
Changes to draft-ietf-lisp-rfc6833bis-03  =
. . . . . . . .  40

      
     B.6.  =
Changes to draft-ietf-lisp-rfc6833bis-01  =
. . . . . . . .  40      B.6.  =
Changes to draft-ietf-lisp-rfc6833bis-02  =
. . . . . . . .  40

      
     B.7.  =
Changes to draft-ietf-lisp-rfc6833bis-00  =
. . . . . . . .  40      B.7.  =
Changes to draft-ietf-lisp-rfc6833bis-01  =
. . . . . . . .  40

      
     B.8.  =
Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . .  41 =
     B.8.  Changes to draft-ietf-lisp-rfc6833bis-00  . . . . . . . .  =
41

      
   Authors' =
Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41      B.9.  Changes to =
draft-farinacci-lisp-rfc6833bis-00 . . . . . .  41

      
 =
   Authors' Addresses  . . . . . . . . . . . . =
. . . . . . . . . . .  42

      
 =


      
1.  =
Introduction 1.  Introduction

      
 =


      
   The Locator/ID =
Separation Protocol [I-D.ietf-lisp-introduction] and    The Locator/ID Separation Protocol =
[I-D.ietf-lisp-introduction] and

      
   =
[I-D.ietf-lisp-rfc6830bis] specifies an architecture and =
mechanism    =
[I-D.ietf-lisp-rfc6830bis] specifies an architecture and =
mechanism

      
   for replacing =
the addresses currently used by IP with two separate    for replacing the addresses currently used by IP with =
two separate

      
   name spaces: =
Endpoint IDs (EIDs), used within sites; and Routing    name spaces: Endpoint IDs (EIDs), used within sites; =
and Routing

      
   Locators =
(RLOCs), used on the transit networks that make up the    Locators (RLOCs), used on the transit networks that =
make up the

      
   Internet =
infrastructure.  To achieve this separation, LISP defines =
   Internet infrastructure.  To achieve this =
separation, LISP defines

      
   protocol =
mechanisms for mapping from EIDs to RLOCs.  In addition, =
   protocol mechanisms for mapping from EIDs to =
RLOCs.  In addition,

      
 =


      
skipping to =
change at =
page 4, line 18 =C2=B6 =
skipping to change at page 4, line 18 =C2=B6

      
   toolset.  =
Issues and concerns about the deployment of LISP for    toolset.  Issues and concerns about the deployment of =
LISP for

      
   Internet =
traffic are discussed in [I-D.ietf-lisp-rfc6830bis].    Internet traffic are discussed in =
[I-D.ietf-lisp-rfc6830bis].

      
 =


      
2.  Definition of =
Terms 2.  Definition of Terms

      
 =


      
   Map-Server:   =
A network infrastructure component that learns of EID-    Map-Server:   A network infrastructure component that =
learns of EID-

      
      Prefix =
mapping entries from an ETR, via the registration mechanism =
      Prefix mapping entries from an ETR, via =
the registration mechanism

      
      described =
below, or some other authoritative source if one exists. =
      described below, or some other =
authoritative source if one exists.

      
      A =
Map-Server publishes these EID-Prefixes in a mapping database. =
      A Map-Server publishes these EID-Prefixes =
in a mapping database.

      
 =


      

      
   Map-Resolver:   A network infrastructure component that =
accepts LISP 

      
      Encapsulated Map-Requests, typically from an ITR, =
and determines 

      
      whether or not the destination IP address is part =
of the EID 

      
      namespace; if it is not, a Negative Map-Reply is =
returned. 

      
      Otherwise, the Map-Resolver finds the appropriate =
EID-to-RLOC 

      
      mapping by consulting a mapping database =
system. 

      
                =
                                                          =


      
   Encapsulated =
Map-Request:   A LISP Map-Request carried within an    Encapsulated Map-Request:   A LISP Map-Request =
carried within an

      

      
      =
Encapsulated Control Message, which has an =
additional LISP header       =
Encapsulated Control Message (ECM), which =
has an additional LISP

      
      =
prepended.  Sent to UDP destination port 4342.  The "outer" =
      header prepended.  Sent to UDP =
destination port 4342.  The "outer"

      
      addresses =
are globally routable IP addresses, also known as RLOCs. =
      addresses are globally routable IP =
addresses, also known as RLOCs.

      
      Used by an =
ITR when sending to a Map-Resolver and by a Map-Server       Used by an ITR when sending to a Map-Resolver and =
by a Map-Server

      
      when =
forwarding a Map-Request to an ETR.    =
   when forwarding a Map-Request to an ETR.

      
 =


      

      
 =
   Map-Resolver:   A =
network infrastructure component that accepts LISP

      
 =
      Encapsulated =
(ECM) Map-Requests, typically from an ITR, and

      
 =
      determines =
whether or not the destination IP address is part of

      
 =
      the EID =
namespace; if it is not, a Negative Map-Reply is =
returned.

      
 =
      Otherwise, the =
Map-Resolver finds the appropriate EID-to-RLOC

      
 =
      mapping by =
consulting a mapping database system.

      
 =
                                               =
                          

      
   Negative =
Map-Reply:   A LISP Map-Reply that contains an empty    Negative Map-Reply:   A LISP Map-Reply that contains =
an empty

      
      =
Locator-Set. Returned in response to a Map-Request if the =
      Locator-Set. Returned in response to a =
Map-Request if the

      
      destination =
EID does not exist in the mapping database.       destination EID does not exist in the mapping =
database.

      
      Typically, =
this means that the "EID" being requested is an IP       Typically, this means that the "EID" being =
requested is an IP

      
      address =
connected to a non-LISP site.       =
address connected to a non-LISP site.

      
 =


      
   Map-Register =
message:   A LISP message sent by an ETR to a Map-Server =
   Map-Register message:   A LISP message sent =
by an ETR to a Map-Server

      
      to register =
its associated EID-Prefixes.  In addition to the set       to register its associated EID-Prefixes.  In =
addition to the set

      
      of =
EID-Prefixes to register, the message includes one or more =
      of EID-Prefixes to register, the message =
includes one or more

      

      
      RLOCs to =
be used by the Map-Server when forwarding =
Map-Requests       RLOCs to reach ETR(s).  The Map-Server uses these RLOCs when

      
      =
(re-formatted as Encapsulated Map-Requests) =
received through the       =
forwarding Map-Requests (re-formatted as Encapsulated Map-

      
      database mapping system.  An ETR may request that the Map-Server =
      Requests). =
 An ETR MAY request that the Map-Server =
answer Map-

      
      answer =
Map-Requests on its behalf by setting the =
"proxy Map-Reply"       Requests on its behalf by setting the =
"proxy Map-Reply" flag

      
      flag =
(P-bit) in the message.       (P-bit) =
in the message.

      
 =


      
   Map-Notify =
message:   A LISP message sent by a Map-Server to an ETR =
   Map-Notify message:   A LISP message sent by =
a Map-Server to an ETR

      
      to confirm =
that a Map-Register has been received and processed.       to confirm that a Map-Register has been received =
and processed.

      
      An ETR =
requests that a Map-Notify be returned by setting the       An ETR requests that a Map-Notify be returned by =
setting the

      
      =
"want-map-notify" flag (M-bit) in the Map-Register message. =
      "want-map-notify" flag (M-bit) in the =
Map-Register message.

      

      
                                                        =
                  

      
      Unlike a =
Map-Reply, a Map-Notify uses UDP port 4342 for both       Unlike a Map-Reply, a Map-Notify uses UDP port =
4342 for both

      

      
      source =
and destination.       source and =
destination.  Map-Notify messages are also sent =
to ITRs

      
 =
      by Map-Servers =
when there are RLOC-set changes.

      
 =


      

      
   For =
definitions of other terms -- notably =
Map-Request, Map-Reply,    For definitions of other terms, notably Ingress Tunnel Router =
(ITR),

      
   Ingress =
Tunnel Router (ITR), and Egress Tunnel =
Router (ETR) -- please    Egress Tunnel Router (ETR), =
and Re-encapsulating Tunnel Router (RTR),

      
   consult the LISP specification =
[I-D.ietf-lisp-rfc6830bis].    refer to the LISP Data-Plane specification

      
 =
   [I-D.ietf-lisp-rfc6830bis].

      
 =


      
3.  Basic =
Overview 3.  Basic Overview

      
 =


      
   A Map-Server =
is a device that publishes EID-Prefixes in a LISP    A Map-Server is a device that publishes EID-Prefixes =
in a LISP

      
   mapping =
database on behalf of a set of ETRs.  When it receives a Map =
   mapping database on behalf of a set of ETRs. =
 When it receives a Map

      
   Request =
(typically from an ITR), it consults the mapping database to =
   Request (typically from an ITR), it consults =
the mapping database to

      
   find an ETR =
that can answer with the set of RLOCs for an EID-Prefix. =
   find an ETR that can answer with the set of =
RLOCs for an EID-Prefix.

      
   To publish its =
EID-Prefixes, an ETR periodically sends Map-Register    To publish its EID-Prefixes, an ETR periodically =
sends Map-Register

      
   messages to =
the Map-Server.  A Map-Register message contains a list =
   messages to the Map-Server.  A Map-Register =
message contains a list

      

      
   of =
EID-Prefixes plus a set of RLOCs that can be used to reach the ETR    of =
EID-Prefixes plus a set of RLOCs that can be used to reach the

      
   when a Map-Server needs to forward a Map-Request to =
it.    ETRs.

      
 =


      
   When LISP+ALT =
is used as the mapping database, a Map-Server connects    When LISP+ALT is used as the mapping database, a =
Map-Server connects

      
   to the ALT =
network and acts as a "last-hop" ALT-Router.  Intermediate =
   to the ALT network and acts as a "last-hop" =
ALT-Router.  Intermediate

      
   ALT-Routers =
forward Map-Requests to the Map-Server that advertises a =
   ALT-Routers forward Map-Requests to the =
Map-Server that advertises a

      
   particular =
EID-Prefix, and the Map-Server forwards them to the owning =
   particular EID-Prefix, and the Map-Server =
forwards them to the owning

      
   ETR, which =
responds with Map-Reply messages.    =
ETR, which responds with Map-Reply messages.

      
 =


      
   When LISP-DDT =
[RFC8111] is used as the mapping database, a Map-Server =
   When LISP-DDT [RFC8111] is used as the =
mapping database, a Map-Server

      
   sends the =
final Map-Referral messages from the Delegated Database =
   sends the final Map-Referral messages from =
the Delegated Database

      
   Tree. =
   Tree.

      
 =


      
skipping to =
change at =
page 5, line 45 =C2=B6 =
skipping to change at page 5, line 45 =C2=B6

      
   to answer =
those requests.  On a LISP+ALT network, a Map-Resolver acts =
   to answer those requests.  On a LISP+ALT =
network, a Map-Resolver acts

      
   as a =
"first-hop" ALT-Router.  It has Generic Routing Encapsulation =
   as a "first-hop" ALT-Router.  It has Generic =
Routing Encapsulation

      
   (GRE) tunnels =
configured to other ALT-Routers and uses BGP to learn    (GRE) tunnels configured to other ALT-Routers and =
uses BGP to learn

      
   paths to ETRs =
for different prefixes in the LISP+ALT database.  The    paths to ETRs for different prefixes in the LISP+ALT =
database.  The

      
   Map-Resolver =
uses this path information to forward Map-Requests over =
   Map-Resolver uses this path information to =
forward Map-Requests over

      
   the ALT to the =
correct ETRs.  On a LISP-DDT network [RFC8111], a Map-    the ALT to the correct ETRs.  On a LISP-DDT network =
[RFC8111], a Map-

      
   Resolver =
maintains a referral-cache and acts as a "first-hop" DDT- =
   Resolver maintains a referral-cache and acts =
as a "first-hop" DDT-

      
   node.  The =
Map-Resolver uses the referral information to forward Map- =
   node.  The Map-Resolver uses the referral =
information to forward Map-

      
   =
Requests.    Requests.

      
 =


      

      
   Note that =
while it is conceivable that a non-LISP-DDT =
Map-Resolver    Note that while it is =
conceivable that a Map-Resolver could cache

      
   could cache =
responses to improve performance, issues surrounding    responses to improve performance, issues surrounding =
cache management

      
   cache =
management will need to be resolved so that doing so will be =
   will need to be resolved so that doing so =
will be reliable and

      
   reliable and =
practical.  As initially deployed, Map-Resolvers will    practical.  As initially deployed, Map-Resolvers =
will operate only in

      
   operate only =
in a non-caching mode, decapsulating and forwarding    a non-caching mode, decapsulating and forwarding =
Encapsulated Map

      
   Encapsulated =
Map Requests received from ITRs.  Any specification of    Requests received from ITRs.  Any specification of =
caching

      
   caching =
functionality is left for future work. =
   functionality is left for future work.

      
 =


      
   Note that a =
single device can implement the functions of both a Map- =
   Note that a single device can implement the =
functions of both a Map-

      
   Server and a =
Map-Resolver, and in many cases the functions will be    Server and a Map-Resolver, and in many cases the =
functions will be

      
   co-located in =
that way.  Also, there can be ALT-only nodes and DDT-    co-located in that way.  Also, there can be ALT-only =
nodes and DDT-

      
   only nodes, =
when LISP+ALT and LISP-DDT are used, respectively, to    only nodes, when LISP+ALT and LISP-DDT are used, =
respectively, to

      
   connect =
Map-Resolvers and Map-Servers together to make up the Mapping =
   connect Map-Resolvers and Map-Servers =
together to make up the Mapping

      
   =
System.    System.

      
 =


      
   Detailed =
descriptions of the LISP packet types referenced by this =
   Detailed descriptions of the LISP packet =
types referenced by this

      
   document may =
be found in [I-D.ietf-lisp-rfc6830bis]. =
   document may be found in [I-D.ietf-lisp-rfc6830bis].

      
 =


      
skipping to =
change at =
page 8, line 15 =C2=B6 =
skipping to change at page 8, line 15 =C2=B6

      
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
        =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
     / |          =
 Source Port         |         Dest Port             |      / |           Source Port         |         Dest =
Port             |

      
   UDP =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
    UDP =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
     \ |          =
 UDP Length          |        UDP Checksum           |      \ |           UDP Length          |        UDP =
Checksum           |

      
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
        =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
       |          =
                                                     |        |                                                 =
              |

      
       |          =
               LISP Message                          |        |                         LISP Message            =
              |

      
       |          =
                                                     |        |                                                 =
              |

      
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
        =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
 =


      

      
   The LISP UDP-based messages are the Map-Request and =
Map-Reply    When a UDP Map-Request, Map-Register, or Map-Notify (when used as =
a

      
   messages.  When a UDP Map-Request is sent, the UDP source port =
is    =
notification message) are sent, the UDP source port is chosen by =
the

      
   chosen by =
the sender and the destination UDP port number is set to =
   sender and the destination UDP port number =
is set to 4342.  When a

      
   4342.  When =
a UDP Map-Reply is sent, the source UDP =
port number is    UDP Map-Reply Map-Notify (when used as an acknowledgement to a =
Map-

      
 =
   Register), or =
Map-Notify-Ack are sent, the source UDP port number is

      
   set to 4342 =
and the destination UDP port number is copied from the    set to 4342 and the destination UDP port number is =
copied from the

      
   source port of =
either the Map-Request or the invoking data packet.    source port of either the Map-Request or the invoking =
data packet.

      
   =
Implementations MUST be prepared to accept packets when either =
the    Implementations MUST be =
prepared to accept packets when either the

      
   source port or =
destination UDP port is set to 4342 due to NATs    source port or destination UDP port is set to 4342 =
due to NATs

      
   changing port =
number values.    changing port number =
values.

      
 =


      
   The 'UDP =
Length' field will reflect the length of the UDP header and =
   The 'UDP Length' field will reflect the =
length of the UDP header and

      
   the LISP =
Message payload.    the LISP Message =
payload.

      
 =


      

      
   The UDP =
checksum is computed and set to non-zero for Map-Request,  =
  The UDP checksum is computed and set to non-zero for all messages

      
   Map-Reply, Map-Register, and Encapsulated Control =
Message (ECM)    sent to or from port 4342.  It MUST be =
checked on receipt, and if the

      
   control messages.  It MUST be checked on =
receipt, and if the checksum    =
checksum fails, the control message MUST =
be dropped.

      
   fails, the =
packet MUST be dropped. 

      
 =


      
   The format of =
control messages includes the UDP header so the    The format of control messages includes the UDP =
header so the

      
   checksum and =
length fields can be used to protect and delimit message =
   checksum and length fields can be used to =
protect and delimit message

      
   =
boundaries.    boundaries.

      
 =


      
4.1.  LISP =
Control Packet Type Allocations 4.1.  =
LISP Control Packet Type Allocations

      
 =


      
   This section =
defines the LISP control message formats and summarizes =
   This section defines the LISP control =
message formats and summarizes

      
   for IANA the =
LISP Type codes assigned by this document.  For    for IANA the LISP Type codes assigned by this =
document.  For

      
   completeness, =
this document references the LISP Shared Extension    completeness, this document references the LISP =
Shared Extension

      
 =


      
skipping to =
change at =
page 9, line 25 =C2=B6 =
skipping to change at page 9, line 25 =C2=B6

      
    LISP =
Map-Register:                 3     b'0011'     LISP Map-Register:                 3     =
b'0011'

      
    LISP =
Map-Notify:                   4     b'0100'     LISP Map-Notify:                   4     =
b'0100'

      
    LISP =
Map-Notify-Ack:               5     b'0101'     LISP Map-Notify-Ack:               5     =
b'0101'

      
    LISP =
Map-Referral:                 6     b'0110'     LISP Map-Referral:                 6     =
b'0110'

      
    LISP =
Encapsulated Control Message: 8     b'1000'     LISP Encapsulated Control Message: 8     =
b'1000'

      
    Not Assigned  =
                     9-14  b'1001'- b'1110'     Not Assigned                       9-14  b'1001'- =
b'1110'

      
    LISP Shared =
Extension Message:     15    b'1111'           [RFC8113] =
    LISP Shared Extension Message:     15    =
b'1111'           [RFC8113]

      
 =


      
   Values in the =
"Not Assigned" range can be assigned according to    Values in the "Not Assigned" range can be assigned =
according to

      
   procedures in =
[RFC5226].  Documents that request for a new LISP    procedures in [RFC5226].  Documents that request for =
a new LISP

      

      
   packet type =
may indicate a preferred value in Section =
7.3.    packet type MAY indicate a preferred value in Section =
7.3.

      
 =


      

      
   Protocol =
designers experimenting with new message formats should use    =
Protocol designers experimenting with new message formats SHOULD use

      
   the LISP =
Shared Extension Message Type and request a [RFC8113] sub- =
   the LISP Shared Extension Message Type and =
request a [RFC8113] sub-

      
   type =
assignment.    type =
assignment.

      
 =


      
   All LISP =
control-plane messages use Address Family Identifiers (AFI) =
   All LISP control-plane messages use Address =
Family Identifiers (AFI)

      
   [AFI] or LISP =
Canonical Address Format (LCAF) [RFC8060] formats to    [AFI] or LISP Canonical Address Format (LCAF) =
[RFC8060] formats to

      
   encode either =
fixed or variable length addresses.  This includes    encode either fixed or variable length addresses.  =
This includes

      
   explicit =
fields in each control message or part of EID-records or =
   explicit fields in each control message or =
part of EID-records or

      
   RLOC-records =
in commonly formatted messages.    =
RLOC-records in commonly formatted messages.

      
 =


      
   The LISP =
control-plane describes how other data-planes can encode =
   The LISP control-plane describes how other =
data-planes can encode

      
 =


      
skipping to =
change at =
page 12, line 32 =C2=B6 =
skipping to change at page 12, line =
32 =C2=B6

      
      selecting =
the destination address from any address family for the =
      selecting the destination address from =
any address family for the

      
      Map-Reply =
message.  This address MUST be a routable RLOC address       Map-Reply message.  This address MUST be a =
routable RLOC address

      
      of the =
sender of the Map-Request message.     =
  of the sender of the Map-Request message.

      
 =


      
   EID mask-len:  =
This is the mask length for the EID-Prefix.    EID mask-len:  This is the mask length for the =
EID-Prefix.

      
 =


      
   =
EID-Prefix-AFI:  This is the address family of the EID-Prefix =
   EID-Prefix-AFI:  This is the address family =
of the EID-Prefix

      
      according =
to [AFI] and [RFC8060].       =
according to [AFI] and [RFC8060].

      
 =


      
   EID-Prefix:  =
This prefix is 4 octets for an IPv4 address family and    EID-Prefix:  This prefix is 4 octets for an IPv4 =
address family and

      

      
      16 octets =
for an IPv6 address family.  When a Map-Request is sent       16 octets for an IPv6 address family when the EID-Prefix-AFI is 1

      
      by an ITR =
because a data packet is received for a destination       or 2, respectively.  For =
other AFIs [AFI], the length varies and

      
      where =
there is no mapping entry, the EID-Prefix is set to the =
      for the LCAF AFI =
the format is defined in [RFC8060].  When a Map-

      
      =
destination IP address of the data packet, and the 'EID =
mask-len'      =
 Request is sent by an ITR because a data packet is received for =
a

      
      is set to =
32 or 128 for IPv4 or IPv6, respectively.  When an xTR       destination where there is no mapping entry, the =
EID-Prefix is set

      
      wants to =
query a site about the status of a mapping it already has =
      to the destination IP address of the =
data packet, and the 'EID

      
      cached, =
the EID-Prefix used in the Map-Request has the same mask =
      mask-len' is set to 32 or 128 for IPv4 =
or IPv6, respectively.

      
      length as =
the EID-Prefix returned from the site when it sent a       When an xTR wants to query a site about the =
status of a mapping it

      
      Map-Reply =
message.       already has cached, =
the EID-Prefix used in the Map-Request has the

      
 =
      same mask length as the EID-Prefix =
returned from the site when it

      
 =
      sent a Map-Reply message.

      
 =


      
   Map-Reply =
Record:  When the M-bit is set, this field is the size of a =
   Map-Reply Record:  When the M-bit is set, =
this field is the size of a

      
      single =
"Record" in the Map-Reply format.  This Map-Reply record =
      single "Record" in the Map-Reply format.  =
This Map-Reply record

      
      contains =
the EID-to-RLOC mapping entry associated with the Source =
      contains the EID-to-RLOC mapping entry =
associated with the Source

      
      EID.  This =
allows the ETR that will receive this Map-Request to       EID.  This allows the ETR that will receive this =
Map-Request to

      
      cache the =
data if it chooses to do so.       =
cache the data if it chooses to do so.
 =


      
4.3.  EID-to-RLOC =
UDP Map-Request Message 4.3.  =
EID-to-RLOC UDP Map-Request Message

      
 =


      
   A Map-Request =
is sent from an ITR when it needs a mapping for an EID, =
   A Map-Request is sent from an ITR when it =
needs a mapping for an EID,

      
 =


      
skipping to =
change at =
page 13, line 50 =C2=B6 =
skipping to change at page 13, line =
50 =C2=B6

      
   Request for =
the same EID-Prefix be sent no more than once per second. =
   Request for the same EID-Prefix be sent no =
more than once per second.

      
 =


      
   An ITR that is =
configured with mapping database information (i.e., it    An ITR that is configured with mapping database =
information (i.e., it

      
   is also an =
ETR) MAY optionally include those mappings in a Map-    is also an ETR) MAY optionally include those mappings =
in a Map-

      
   Request.  When =
an ETR configured to accept and verify such    Request.  When an ETR configured to accept and verify =
such

      
   "piggybacked" =
mapping data receives such a Map-Request and it does    "piggybacked" mapping data receives such a =
Map-Request and it does

      
   not have this =
mapping in the map-cache, it MAY originate a "verifying =
   not have this mapping in the map-cache, it =
MAY originate a "verifying

      
   Map-Request", =
addressed to the map-requesting ITR and the ETR MAY add =
   Map-Request", addressed to the =
map-requesting ITR and the ETR MAY add
   a Map-Cache =
entry.  If the ETR has a Map-Cache entry that matches the =
   a Map-Cache entry.  If the ETR has a =
Map-Cache entry that matches the

      
   "piggybacked" =
EID and the RLOC is in the Locator-Set for the entry,    "piggybacked" EID and the RLOC is in the Locator-Set =
for the entry,

      

      
   then it =
may send the "verifying Map-Request" =
directly to the    then it MAY send the "verifying Map-Request" directly to =
the

      
   originating =
Map-Request source.  If the RLOC is not in the Locator- =
   originating Map-Request source.  If the RLOC =
is not in the Locator-

      
   Set, then the =
ETR MUST send the "verifying Map-Request" to the    Set, then the ETR MUST send the "verifying =
Map-Request" to the

      
   "piggybacked" =
EID.  Doing this forces the "verifying Map-Request" to    "piggybacked" EID.  Doing this forces the "verifying =
Map-Request" to

      
   go through the =
mapping database system to reach the authoritative    go through the mapping database system to reach the =
authoritative

      
   source of =
information about that EID, guarding against RLOC-spoofing =
   source of information about that EID, =
guarding against RLOC-spoofing

      
   in the =
"piggybacked" mapping data.    in the =
"piggybacked" mapping data.

      
 =


      
4.4.  Map-Reply =
Message Format 4.4.  Map-Reply Message =
Format

      
 =


      
        0         =
          1                   2                   3         0                   1                   2        =
           3

      
 =


      
skipping =
to change at page 16, line =
43 =C2=B6 =
skipping to change at page 16, line =
43 =C2=B6

      
      =
Prefix.       Prefix.

      
 =


      
   EID mask-len:  =
This is the mask length for the EID-Prefix.    EID mask-len:  This is the mask length for the =
EID-Prefix.

      
 =


      
   ACT:  This =
3-bit field describes Negative Map-Reply actions.  In any =
   ACT:  This 3-bit field describes Negative =
Map-Reply actions.  In any

      
      other =
message type, these bits are set to 0 and ignored on       other message type, these bits are set to 0 and =
ignored on

      
      receipt.  =
These bits are used only when the 'Locator Count' field =
      receipt.  These bits are used only when =
the 'Locator Count' field

      
      is set to =
0.  The action bits are encoded only in Map-Reply       is set to 0.  The action bits are encoded only in =
Map-Reply

      
      messages.  =
The actions defined are used by an ITR or PITR when a       messages.  The actions defined are used by an ITR =
or PITR when a

      
      destination =
EID matches a negative Map-Cache entry.  Unassigned       destination EID matches a negative Map-Cache =
entry.  Unassigned

      

      
      values =
should cause a Map-Cache entry to be =
created, and when       values SHOULD cause a Map-Cache entry to be created, =
and when

      
      packets =
match this negative cache entry, they will be dropped.       packets match this negative cache entry, they will =
be dropped.

      
      The current =
assigned values are:       The current =
assigned values are:

      
 =


      
      (0) =
No-Action:  The map-cache is kept alive, and no packet       (0) No-Action:  The map-cache is kept alive, and =
no packet

      
          =
encapsulation occurs.           =
encapsulation occurs.

      
 =


      
      (1) =
Natively-Forward:  The packet is not encapsulated or dropped =
      (1) Natively-Forward:  The packet is not =
encapsulated or dropped

      
          but =
natively forwarded.           but =
natively forwarded.

      
 =


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

      
 =


      
skipping =
to change at page 18, line =
49 =C2=B6 =
skipping to change at page 18, line =
49 =C2=B6

      
      probed and =
MAY be different from the source address of the Map-       probed and MAY be different from the source =
address of the Map-

      
      Reply.  An =
ITR that RLOC-probes a particular Locator MUST use this =
      Reply.  An ITR that RLOC-probes a =
particular Locator MUST use this

      
      Locator for =
retrieving the data structure used to store the fact       Locator for retrieving the data structure used to =
store the fact

      
      that the =
Locator is reachable.  The p-bit is set for a single       that the Locator is reachable.  The p-bit is set =
for a single

      
      Locator in =
the same Locator-Set. If an implementation sets more       Locator in the same Locator-Set. If an =
implementation sets more

      
      than one =
p-bit erroneously, the receiver of the Map-Reply MUST       than one p-bit erroneously, the receiver of the =
Map-Reply MUST

      
      select the =
first Locator.  The p-bit MUST NOT be set for Locator-       select the first Locator.  The p-bit MUST NOT be =
set for Locator-

      
      Set records =
sent in Map-Request and Map-Register messages.       Set records sent in Map-Request and Map-Register =
messages.

      
 =


      
   R: This is set =
when the sender of a Map-Reply has a route to the    R: This is set when the sender of a Map-Reply has a =
route to the

      

      
      Locator =
in the Locator data record.  This receiver may find this  =
     Locator in the Locator data record.  This receiver MAY find this

      
      useful to =
know if the Locator is up but not necessarily reachable =
      useful to know if the Locator is up but =
not necessarily reachable

      
      from the =
receiver's point of view.  See also EID-Reachability       from the receiver's point of view.  See also =
EID-Reachability

      

      
      =
[I-D.ietf-lisp-rfc6830bis] for another way the R-bit may be used.  =
     [I-D.ietf-lisp-rfc6830bis] for another way the R-bit MAY be used.

      
 =


      
   Locator:  This =
is an IPv4 or IPv6 address (as encoded by the 'Loc-    Locator:  This is an IPv4 or IPv6 address (as encoded =
by the 'Loc-

      
      AFI' field) =
assigned to an ETR.  Note that the destination RLOC       AFI' field) assigned to an ETR.  Note that the =
destination RLOC

      
      address MAY =
be an anycast address.  A source RLOC can be an       address MAY be an anycast address.  A source RLOC =
can be an

      
      anycast =
address as well.  The source or destination RLOC MUST NOT =
      anycast address as well.  The source or =
destination RLOC MUST NOT

      
      be the =
broadcast address (255.255.255.255 or any subnet broadcast =
      be the broadcast address (255.255.255.255 =
or any subnet broadcast

      
      address =
known to the router) and MUST NOT be a link-local       address known to the router) and MUST NOT be a =
link-local

      
      multicast =
address.  The source RLOC MUST NOT be a multicast       multicast address.  The source RLOC MUST NOT be a =
multicast

      
      address.  =
The destination RLOC SHOULD be a multicast address if it =
      address.  The destination RLOC SHOULD be =
a multicast address if it

      
      is being =
mapped from a multicast destination EID.       is being mapped from a multicast destination =
EID.

      
 =


      
4.5.  EID-to-RLOC =
UDP Map-Reply Message 4.5.  =
EID-to-RLOC UDP Map-Reply Message

      
 =


      
   A Map-Reply =
returns an EID-Prefix with a prefix length that is less =
   A Map-Reply returns an EID-Prefix with a =
prefix length that is less

      
   than or equal =
to the EID being requested.  The EID being requested is =
   than or equal to the EID being requested.  =
The EID being requested is

      
   either from =
the destination field of an IP header of a Data-Probe or =
   either from the destination field of an IP =
header of a Data-Probe or

      
   the EID record =
of a Map-Request.  The RLOCs in the Map-Reply are    the EID record of a Map-Request.  The RLOCs in the =
Map-Reply are

      

      
   globally routable IP addresses of all ETRs for =
the LISP site.  Each    routable IP =
addresses of all ETRs for the LISP site.  Each RLOC

      
   RLOC conveys =
status reachability but does not convey path    conveys status reachability but does not convey path =
reachability

      
   reachability =
from a requester's perspective.  Separate testing of    from a requester's perspective.  Separate testing of =
path

      
   path =
reachability is required.  See RLOC-reachability    reachability is required.  See =
RLOC-reachability

      
   =
[I-D.ietf-lisp-rfc6830bis] for details. =
   [I-D.ietf-lisp-rfc6830bis] for details.

      
 =


      

      
   Note that a =
Map-Reply may contain different EID-Prefix =
granularity    Note that a Map-Reply =
MAY contain different EID-Prefix =
granularity

      
   (prefix + =
length) than the Map-Request that triggers it.  This might =
   (prefix + length) than the Map-Request that =
triggers it.  This might

      
   occur if a =
Map-Request were for a prefix that had been returned by an =
   occur if a Map-Request were for a prefix =
that had been returned by an

      
   earlier =
Map-Reply.  In such a case, the requester updates its cache =
   earlier Map-Reply.  In such a case, the =
requester updates its cache

      
   with the new =
prefix information and granularity.  For example, a    with the new prefix information and granularity.  For =
example, a

      
   requester with =
two cached EID-Prefixes that are covered by a Map-    requester with two cached EID-Prefixes that are =
covered by a Map-

      
   Reply =
containing one less-specific prefix replaces the entry with the =
   Reply containing one less-specific prefix =
replaces the entry with the

      
   less-specific =
EID-Prefix.  Note that the reverse, replacement of one    less-specific EID-Prefix.  Note that the reverse, =
replacement of one

      
   less-specific =
prefix with multiple more-specific prefixes, can also    less-specific prefix with multiple more-specific =
prefixes, can also

      
   occur, not by =
removing the less-specific prefix but rather by adding    occur, not by removing the less-specific prefix but =
rather by adding

      
   the =
more-specific prefixes that, during a lookup, will override the =
   the more-specific prefixes that, during a =
lookup, will override the

      
 =


      
skipping =
to change at page 23, line =
44 =C2=B6 =
skipping to change at page 23, line =
44 =C2=B6

      
      sending a =
Map-Register message.  The Map-Notify message sent by a =
      sending a Map-Register message.  The =
Map-Notify message sent by a

      
      Map-Server =
is used to acknowledge receipt of a Map-Register       Map-Server is used to acknowledge receipt of a =
Map-Register

      
      =
message.       message.

      
 =


      
   Record Count:  =
This is the number of records in this Map-Register    Record Count:  This is the number of records in this =
Map-Register

      
      message.  A =
record is comprised of that portion of the packet       message.  A record is comprised of that portion of =
the packet

      
      labeled =
'Record' above and occurs the number of times equal to       labeled 'Record' above and occurs the number of =
times equal to

      
      Record =
Count.       Record Count.

      
 =


      
   Nonce:  This =
8-octet 'Nonce' field is set to 0 in Map-Register    Nonce:  This 8-octet 'Nonce' field is set to 0 in =
Map-Register

      

      
      messages.  Since the Map-Register message is =
authenticated, the       messages if no Map-Notify message is expected to =
acknowledge it.

      
      'Nonce' =
field is not currently used for any security function but =
      Since the Map-Register message is =
authenticated, the 'Nonce' field

      
      may be in the future as part of an anti-replay =
solution.       is not currently used =
for any security function but MAY be in =
the

      
 =
      future as part of an anti-replay =
solution.

      
 =


      
   Key ID:  This =
is a configured key-id value that corresponds to a    Key ID:  This is a configured key-id value that =
corresponds to a

      
      =
shared-secret password that is used to authenticate the sender. =
      shared-secret password that is used to =
authenticate the sender.

      
      Multiple =
shared-secrets can be used to roll over keys in a non-       Multiple shared-secrets can be used to roll over =
keys in a non-

      
      disruptive =
way.       disruptive way.

      
 =


      
   Algorithm ID:  =
This is the configured Message Authentication Code    Algorithm ID:  This is the configured Message =
Authentication Code

      
      (MAC) =
algorithm value used for the authentication function.  See =
      (MAC) algorithm value used for the =
authentication function.  See

      
      Algorithm =
ID Numbers in the Section 7.3 for codepoint assignments. =
      Algorithm ID Numbers in the Section 7.3 =
for codepoint assignments.

      
 =


      
 =


      
skipping =
to change at page 27, line =
39 =C2=B6 =
skipping to change at page 27, line =
39 =C2=B6

      
         control =
packet being encapsulated.  When the control packet is          control packet being encapsulated.  When the =
control packet is

      
         a =
Map-Request or Map-Register, the source port is selected by =
         a Map-Request or Map-Register, the =
source port is selected by

      
         the =
ITR/PITR and the destination port is 4342.  When the          the ITR/PITR and the destination port is 4342.  =
When the

      
         control =
packet is a Map-Reply, the source port is 4342 and the          control packet is a Map-Reply, the source port =
is 4342 and the

      
         =
destination port is assigned from the source port of the =
         destination port is assigned from the =
source port of the

      
         invoking =
Map-Request.  Port number 4341 MUST NOT be assigned to          invoking Map-Request.  Port number 4341 MUST =
NOT be assigned to

      
         either =
port.  The checksum field MUST be non-zero.          either port.  The checksum field MUST be =
non-zero.

      
 =


      
   LCM:  The =
format is one of the control message formats described in =
   LCM:  The format is one of the control =
message formats described in

      
         this =
section.  At this time, only Map-Request messages are          this section.  At this time, only Map-Request =
messages are

      

      
         =
allowed to be encapsulated.  In the future, PIM Join/Prune =
         allowed to be control-plane (ECM) encapsulated.  In the =
future,

      
         =
messages [RFC6831] might be allowed.  Encapsulating other types =
         PIM Join/Prune messages [RFC6831] =
might be allowed.

      
         of =
LISP control messages is for further study.  When Map-          =
Encapsulating other types of LISP control messages is for

      
         Requests are sent for RLOC-Probing =
purposes (i.e., the probe- =
         further study.  When Map-Requests are sent for RLOC-Probing

      
         bit is set), they MUST NOT be sent =
inside Encapsulated Control          =
purposes (i.e., the probe-bit is set), =
they MUST NOT be sent

      
         =
Messages.          inside =
Encapsulated Control Messages.

      
 =


      
5.  Interactions =
with Other LISP Components 5.  =
Interactions with Other LISP Components

      
 =


      
5.1.  ITR =
EID-to-RLOC Mapping Resolution 5.1.  =
ITR EID-to-RLOC Mapping Resolution

      
 =


      
   An ITR is =
configured with one or more Map-Resolver addresses.  These =
   An ITR is configured with one or more =
Map-Resolver addresses.  These

      

      
   addresses =
are "Locators" (or RLOCs) and must be =
routable on the    addresses are =
"Locators" (or RLOCs) and MUST be routable =
on the

      
   underlying =
core network; they must not need to be =
resolved through    underlying core =
network; they MUST NOT need to be resolved =
through

      
   LISP =
EID-to-RLOC mapping, as that would introduce a circular =
   LISP EID-to-RLOC mapping, as that would =
introduce a circular

      
   dependency.  =
When using a Map-Resolver, an ITR does not need to    dependency.  When using a Map-Resolver, an ITR does =
not need to

      
   connect to any =
other database mapping system.  In particular, the ITR    connect to any other database mapping system.  In =
particular, the ITR

      
   need not =
connect to the LISP+ALT infrastructure or implement the BGP =
   need not connect to the LISP+ALT =
infrastructure or implement the BGP

      
   and GRE =
protocols that it uses.    and GRE =
protocols that it uses.

      
 =


      
   An ITR sends =
an Encapsulated Map-Request to a configured Map-Resolver =
   An ITR sends an Encapsulated Map-Request to =
a configured Map-Resolver

      
   when it needs =
an EID-to-RLOC mapping that is not found in its local    when it needs an EID-to-RLOC mapping that is not =
found in its local

      
   map-cache.  =
Using the Map-Resolver greatly reduces both the    map-cache.  Using the Map-Resolver greatly reduces =
both the

      
   complexity of =
the ITR implementation and the costs associated with    complexity of the ITR implementation and the costs =
associated with

      
 =


      
skipping =
to change at page 28, line =
51 =C2=B6 =
skipping to change at page 28, line =
51 =C2=B6

      
      registered, =
a 1-minute TTL is returned.  If the requested EID       registered, a 1-minute TTL is returned.  If the =
requested EID

      
      matches a =
non-delegated part of the authoritative EID-Prefix, then =
      matches a non-delegated part of the =
authoritative EID-Prefix, then

      
      it is not a =
LISP EID and a 15-minute TTL is returned.  See       it is not a LISP EID and a 15-minute TTL is =
returned.  See

      
      Section 5.2 =
for discussion of aggregate EID-Prefixes and details       Section 5.2 for discussion of aggregate =
EID-Prefixes and details

      
      of =
Map-Server EID-Prefix matching.       =
of Map-Server EID-Prefix matching.

      
 =


      
   o  A LISP =
Map-Reply from the ETR that owns the EID-to-RLOC mapping or =
   o  A LISP Map-Reply from the ETR that owns =
the EID-to-RLOC mapping or

      
      possibly =
from a Map-Server answering on behalf of the ETR.  See       possibly from a Map-Server answering on behalf of =
the ETR.  See

      
      Section 5.4 =
for more details on Map-Resolver message processing.       Section 5.4 for more details on Map-Resolver =
message processing.

      
 =


      

      
   Note that an =
ITR may be configured to both use a =
Map-Resolver and to    Note that an =
ITR MAY be configured to both use a =
Map-Resolver and to

      
   participate in =
a LISP+ALT logical network.  In such a situation, the    participate in a LISP+ALT logical network.  In such a =
situation, the

      

      
   ITR should send Map-Requests through the ALT network =
for any EID-    ITR SHOULD send Map-Requests through the ALT network =
for any EID-

      
   Prefix learned =
via ALT BGP.  Such a configuration is expected to be    Prefix learned via ALT BGP.  Such a configuration is =
expected to be

      
   very rare, =
since there is little benefit to using a Map-Resolver if =
   very rare, since there is little benefit to =
using a Map-Resolver if

      
   an ITR is =
already using LISP+ALT.  There would be, for example, no =
   an ITR is already using LISP+ALT.  There =
would be, for example, no

      
   need for such =
an ITR to send a Map-Request to a possibly non-existent =
   need for such an ITR to send a Map-Request =
to a possibly non-existent

      
   EID (and rely =
on Negative Map-Replies) if it can consult the ALT    EID (and rely on Negative Map-Replies) if it can =
consult the ALT

      
   database to =
verify that an EID-Prefix is present before sending that =
   database to verify that an EID-Prefix is =
present before sending that

      
   =
Map-Request.    Map-Request.

      
 =


      
5.2.  EID-Prefix =
Configuration and ETR Registration 5.2. =
 EID-Prefix Configuration and ETR Registration

      
 =


      
   An ETR =
publishes its EID-Prefixes on a Map-Server by sending LISP =
   An ETR publishes its EID-Prefixes on a =
Map-Server by sending LISP

      
   Map-Register =
messages.  A Map-Register message includes    Map-Register messages.  A Map-Register message =
includes

      
   authentication =
data, so prior to sending a Map-Register message, the    authentication data, so prior to sending a =
Map-Register message, the

      

      
   ETR and =
Map-Server must be configured with a =
shared secret or other    ETR and =
Map-Server SHOULD be configured with a =
shared secret or other

      
   relevant =
authentication information.  A Map-Server's configuration =
   relevant authentication information.  A =
Map-Server's configuration

      

      
   must also include a list of the EID-Prefixes for =
which each ETR is    SHOULD also include a list of the EID-Prefixes =
for which each ETR is

      
   authoritative. =
 Upon receipt of a Map-Register from an ETR, a Map-    authoritative.  Upon receipt of a Map-Register from =
an ETR, a Map-

      
   Server accepts =
only EID-Prefixes that are configured for that ETR.    Server accepts only EID-Prefixes that are configured =
for that ETR.

      
   Failure to =
implement such a check would leave the mapping system    Failure to implement such a check would leave the =
mapping system

      
   vulnerable to =
trivial EID-Prefix hijacking attacks.  As developers    vulnerable to trivial EID-Prefix hijacking attacks.  =
As developers

      
   and operators =
gain experience with the mapping system, additional,    and operators gain experience with the mapping =
system, additional,

      

      
   stronger =
security measures may be added to the =
registration process.    stronger =
security measures MAY be added to the =
registration process.

      
 =


      

      
   In addition =
to the set of EID-Prefixes defined for each ETR that may    In =
addition to the set of EID-Prefixes defined for each ETR that MAY

      
   register, a =
Map-Server is typically also configured with one or more =
   register, a Map-Server is typically also =
configured with one or more

      
   aggregate =
prefixes that define the part of the EID numbering space =
   aggregate prefixes that define the part of =
the EID numbering space

      
   assigned to =
it.  When LISP+ALT is the database in use, aggregate EID- =
   assigned to it.  When LISP+ALT is the =
database in use, aggregate EID-

      
   Prefixes are =
implemented as discard routes and advertised into ALT    Prefixes are implemented as discard routes and =
advertised into ALT

      
   BGP.  The =
existence of aggregate EID-Prefixes in a Map-Server's    BGP.  The existence of aggregate EID-Prefixes in a =
Map-Server's

      

      
   database =
means that it may receive Map Requests for =
EID-Prefixes that    database means =
that it MAY receive Map Requests for =
EID-Prefixes that

      
   match an =
aggregate but do not match a registered prefix; Section 5.3 =
   match an aggregate but do not match a =
registered prefix; Section 5.3

      
   describes how =
this is handled.    describes how this =
is handled.

      
 =


      
   Map-Register =
messages are sent periodically from an ETR to a Map-    Map-Register messages are sent periodically from an =
ETR to a Map-

      
   Server with a =
suggested interval between messages of one minute.  A    Server with a suggested interval between messages of =
one minute.  A

      

      
   Map-Server =
should time out and remove an ETR's =
registration if it has    Map-Server =
SHOULD time out and remove an ETR's =
registration if it has

      
   not received a =
valid Map-Register message within the past    not received a valid Map-Register message within the =
past

      
   three minutes. =
 When first contacting a Map-Server after restart or    three minutes.  When first contacting a Map-Server =
after restart or

      

      
   changes to =
its EID-to-RLOC database mappings, an ETR may initially  =
  changes to its EID-to-RLOC database mappings, an ETR MAY initially

      
   send =
Map-Register messages at an increased frequency, up to one =
every    send Map-Register messages at =
an increased frequency, up to one every

      
   20 seconds.  =
This "quick registration" period is limited to    20 seconds.  This "quick registration" period is =
limited to

      
   five minutes =
in duration.    five minutes in =
duration.

      
 =


      

      
   An ETR may request that a Map-Server explicitly =
acknowledge receipt    An ETR MAY request that a Map-Server explicitly =
acknowledge receipt

      
   and processing =
of a Map-Register message by setting the "want-map-    and processing of a Map-Register message by setting =
the "want-map-

      
   notify" =
(M-bit) flag.  A Map-Server that receives a Map-Register with =
   notify" (M-bit) flag.  A Map-Server that =
receives a Map-Register with

      
   this flag set =
will respond with a Map-Notify message.  Typical use of =
   this flag set will respond with a Map-Notify =
message.  Typical use of

      
   this flag by =
an ETR would be to set it for Map-Register messages sent =
   this flag by an ETR would be to set it for =
Map-Register messages sent

      
   during the =
initial "quick registration" with a Map-Server but then =
   during the initial "quick registration" with =
a Map-Server but then

      
   set it only =
occasionally during steady-state maintenance of its    set it only occasionally during steady-state =
maintenance of its

      
   association =
with that Map-Server.  Note that the Map-Notify message =
   association with that Map-Server.  Note that =
the Map-Notify message

      
   is sent to UDP =
destination port 4342, not to the source port    is sent to UDP destination port 4342, not to the =
source port

      
   specified in =
the original Map-Register message.    =
specified in the original Map-Register message.

      
 =


      
   Note that a =
one-minute minimum registration interval during    Note that a one-minute minimum registration interval =
during

      
   maintenance of =
an ETR-Map-Server association places a lower bound on    maintenance of an ETR-Map-Server association places a =
lower bound on

      
   how quickly =
and how frequently a mapping database entry can be    how quickly and how frequently a mapping database =
entry can be

      

      
   updated.  =
This may have implications for what sorts =
of mobility can    updated.  This =
MAY have implications for what sorts of =
mobility can

      
   be supported =
directly by the mapping system; shorter registration    be supported directly by the mapping system; shorter =
registration

      
   intervals or =
other mechanisms might be needed to support faster    intervals or other mechanisms might be needed to =
support faster

      
   mobility in =
some cases.  For a discussion on one way that faster    mobility in some cases.  For a discussion on one way =
that faster

      

      
   mobility =
may be implemented for individual devices, =
please see    mobility MAY be implemented for individual devices, =
please see

      
   =
[I-D.ietf-lisp-mn].    =
[I-D.ietf-lisp-mn].

      
 =


      

      
   An ETR may also request, by setting the "proxy =
Map-Reply" flag    An ETR MAY also request, by setting the "proxy =
Map-Reply" flag

      
   (P-bit) in the =
Map-Register message, that a Map-Server answer Map-    (P-bit) in the Map-Register message, that a =
Map-Server answer Map-

      
   Requests =
instead of forwarding them to the ETR.  See    Requests instead of forwarding them to the ETR.  =
See

      
   =
[I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server =
sets    [I-D.ietf-lisp-rfc6830bis] for =
details on how the Map-Server sets

      
   certain flags =
(such as those indicating whether the message is    certain flags (such as those indicating whether the =
message is

      

      
   =
authoritative and how returned Locators should be treated) when    authoritative and how returned Locators SHOULD be treated) when

      
   sending a =
Map-Reply on behalf of an ETR.  When an ETR requests proxy =
   sending a Map-Reply on behalf of an ETR.  =
When an ETR requests proxy

      

      
   reply =
service, it should include all RLOCs for =
all ETRs for the EID-    reply =
service, it SHOULD include all RLOCs for =
all ETRs for the EID-

      
   Prefix being =
registered, along with the routable flag ("R-bit")    Prefix being registered, along with the routable flag =
("R-bit")

      
   setting for =
each RLOC.  The Map-Server includes all of this    setting for each RLOC.  The Map-Server includes all =
of this

      
   information in =
Map-Reply messages that it sends on behalf of the ETR.    information in Map-Reply messages that it sends on =
behalf of the ETR.

      
   This differs =
from a non-proxy registration, since the latter need    This differs from a non-proxy registration, since the =
latter need

      
   only provide =
one or more RLOCs for a Map-Server to use for forwarding =
   only provide one or more RLOCs for a =
Map-Server to use for forwarding

      
   Map-Requests; =
the registration information is not used in Map-    Map-Requests; the registration information is not =
used in Map-

      
   Replies, so it =
being incomplete is not incorrect.    =
Replies, so it being incomplete is not incorrect.

      
 =


      
   An ETR that =
uses a Map-Server to publish its EID-to-RLOC mappings    An ETR that uses a Map-Server to publish its =
EID-to-RLOC mappings

      
   does not need =
to participate further in the mapping database    does not need to participate further in the mapping =
database

      
 =


      
skipping =
to change at page 31, line =
14 =C2=B6 =
skipping to change at page 31, line =
14 =C2=B6

      
 =


      
5.3.  Map-Server =
Processing 5.3.  Map-Server =
Processing

      
 =


      
   Once a =
Map-Server has EID-Prefixes registered by its client ETRs, it =
   Once a Map-Server has EID-Prefixes =
registered by its client ETRs, it

      
   can accept and =
process Map-Requests for them.    can =
accept and process Map-Requests for them.

      
 =


      
   In response to =
a Map-Request (received over the ALT if LISP+ALT is in    In response to a Map-Request (received over the ALT =
if LISP+ALT is in

      
   use), the =
Map-Server first checks to see if the destination EID    use), the Map-Server first checks to see if the =
destination EID

      
   matches a =
configured EID-Prefix.  If there is no match, the Map-    matches a configured EID-Prefix.  If there is no =
match, the Map-

      
   Server returns =
a Negative Map-Reply with action code "Natively-    Server returns a Negative Map-Reply with action code =
"Natively-

      

      
   Forward" and =
a 15-minute TTL.  This may occur if a Map =
Request is    Forward" and a =
15-minute TTL.  This MAY occur if a Map =
Request is

      
   received for a =
configured aggregate EID-Prefix for which no more-    received for a configured aggregate EID-Prefix for =
which no more-

      
   specific =
EID-Prefix exists; it indicates the presence of a non-LISP =
   specific EID-Prefix exists; it indicates the =
presence of a non-LISP

      
   "hole" in the =
aggregate EID-Prefix.    "hole" in the =
aggregate EID-Prefix.

      
 =


      
   Next, the =
Map-Server checks to see if any ETRs have registered the =
   Next, the Map-Server checks to see if any =
ETRs have registered the

      
   matching =
EID-Prefix.  If none are found, then the Map-Server returns =
   matching EID-Prefix.  If none are found, =
then the Map-Server returns

      
   a Negative =
Map-Reply with action code "Natively-Forward" and a    a Negative Map-Reply with action code =
"Natively-Forward" and a

      
   1-minute =
TTL.    1-minute TTL.

      
 =


      
   If any of the =
registered ETRs for the EID-Prefix have requested proxy =
   If any of the registered ETRs for the =
EID-Prefix have requested proxy

      
   reply service, =
then the Map-Server answers the request instead of    reply service, then the Map-Server answers the =
request instead of

      
   forwarding it. =
 It returns a Map-Reply with the EID-Prefix, RLOCs,    forwarding it.  It returns a Map-Reply with the =
EID-Prefix, RLOCs,

      
   and other =
information learned through the registration process.    and other information learned through the =
registration process.

      
 =


      
   If none of the =
ETRs have requested proxy reply service, then the Map-    If none of the ETRs have requested proxy reply =
service, then the Map-

      
   Server =
re-encapsulates and forwards the resulting Encapsulated Map- =
   Server re-encapsulates and forwards the =
resulting Encapsulated Map-

      
   Request to one =
of the registered ETRs.  It does not otherwise alter    Request to one of the registered ETRs.  It does not =
otherwise alter

      
   the =
Map-Request, so any Map-Reply sent by the ETR is returned to =
the    the Map-Request, so any =
Map-Reply sent by the ETR is returned to the

      
   RLOC in the =
Map-Request, not to the Map-Server.  Unless also acting =
   RLOC in the Map-Request, not to the =
Map-Server.  Unless also acting

      

      
   as a =
Map-Resolver, a Map-Server should never =
receive Map-Replies; any    as a =
Map-Resolver, a Map-Server SHOULD never =
receive Map-Replies; any

      
   such =
messages should be discarded without =
response, perhaps    such messages =
SHOULD be discarded without response, =
perhaps

      
   accompanied by =
the logging of a diagnostic message if the rate of    accompanied by the logging of a diagnostic message if =
the rate of

      
   Map-Replies is =
suggestive of malicious traffic.    =
Map-Replies is suggestive of malicious traffic.

      
 =


      
5.4.  =
Map-Resolver Processing 5.4.  =
Map-Resolver Processing

      
 =


      
   Upon receipt =
of an Encapsulated Map-Request, a Map-Resolver    Upon receipt of an Encapsulated Map-Request, a =
Map-Resolver

      
   decapsulates =
the enclosed message and then searches for the requested =
   decapsulates the enclosed message and then =
searches for the requested

      
   EID in its =
local database of mapping entries (statically configured =
   EID in its local database of mapping entries =
(statically configured

      
   or learned =
from associated ETRs if the Map-Resolver is also a Map- =
   or learned from associated ETRs if the =
Map-Resolver is also a Map-

      
   Server =
offering proxy reply service).  If it finds a matching entry, =
   Server offering proxy reply service).  If it =
finds a matching entry,

      
   it returns a =
LISP Map-Reply with the known mapping.  =
  it returns a LISP Map-Reply with the known mapping.

      
 =


      
   If the =
Map-Resolver does not have the mapping entry and if it can =
   If the Map-Resolver does not have the =
mapping entry and if it can

      
   determine that =
the EID is not in the mapping database (for example,    determine that the EID is not in the mapping database =
(for example,

      
   if LISP+ALT is =
used, the Map-Resolver will have an ALT forwarding    if LISP+ALT is used, the Map-Resolver will have an =
ALT forwarding

      
   table that =
covers the full EID space), it immediately returns a    table that covers the full EID space), it immediately =
returns a

      
   negative LISP =
Map-Reply, with action code "Natively-Forward" and a    negative LISP Map-Reply, with action code =
"Natively-Forward" and a

      
   15-minute TTL. =
 To minimize the number of negative cache entries    15-minute TTL.  To minimize the number of negative =
cache entries

      

      
   needed by an =
ITR, the Map-Resolver should return the =
least-specific    needed by an ITR, =
the Map-Resolver SHOULD return the =
least-specific

      
   prefix that =
both matches the original query and does not match any    prefix that both matches the original query and does =
not match any

      
   EID-Prefix =
known to exist in the LISP-capable infrastructure.    EID-Prefix known to exist in the LISP-capable =
infrastructure.

      
 =


      
   If the =
Map-Resolver does not have sufficient information to know =
   If the Map-Resolver does not have sufficient =
information to know

      
   whether the =
EID exists, it needs to forward the Map-Request to    whether the EID exists, it needs to forward the =
Map-Request to

      
   another device =
that has more information about the EID being    another device that has more information about the =
EID being

      
   requested.  To =
do this, it forwards the unencapsulated Map-Request,    requested.  To do this, it forwards the =
unencapsulated Map-Request,

      
   with the =
original ITR RLOC as the source, to the mapping database =
   with the original ITR RLOC as the source, to =
the mapping database

      
   system.  Using =
LISP+ALT, the Map-Resolver is connected to the ALT    system.  Using LISP+ALT, the Map-Resolver is =
connected to the ALT

      
   network and =
sends the Map-Request to the next ALT hop learned from    network and sends the Map-Request to the next ALT hop =
learned from

      
 =


      
skipping =
to change at page 32, line =
28 =C2=B6 =
skipping to change at page 32, line =
28 =C2=B6

      
   Server that =
receives the Map-Request over the ALT and responds will =
   Server that receives the Map-Request over =
the ALT and responds will

      
   do so directly =
to the ITR.    do so directly to the =
ITR.

      
 =


      
5.4.1.  Anycast =
Map-Resolver Operation 5.4.1.  Anycast =
Map-Resolver Operation

      
 =


      
   A Map-Resolver =
can be set up to use "anycast", where the same address    A Map-Resolver can be set up to use "anycast", where =
the same address

      
   is assigned to =
multiple Map-Resolvers and is propagated through IGP    is assigned to multiple Map-Resolvers and is =
propagated through IGP

      
   routing, to =
facilitate the use of a topologically close Map-Resolver =
   routing, to facilitate the use of a =
topologically close Map-Resolver

      
   by each =
ITR.    by each ITR.

      
 =


      

      
   Note that =
Map-Server associations with ETRs should =
not use anycast    Note that =
Map-Server associations with ETRs SHOULD =
not use anycast

      
   addresses, as =
registrations need to be established between an ETR and =
   addresses, as registrations need to be =
established between an ETR and

      
   a specific set =
of Map-Servers, each identified by a specific    a specific set of Map-Servers, each identified by a =
specific

      
   registration =
association.    registration =
association.

      
 =


      
6.  Security =
Considerations 6.  Security =
Considerations

      
 =


      
   The 2-way LISP =
header nonce exchange documented in    =
The 2-way LISP header nonce exchange documented in

      
   =
[I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing =
attacks.    [I-D.ietf-lisp-rfc6830bis] =
can be used to avoid ITR spoofing attacks.

      
 =


      
   To publish an =
authoritative EID-to-RLOC mapping with a Map-Server, an =
   To publish an authoritative EID-to-RLOC =
mapping with a Map-Server, an

      
   ETR includes =
authentication data that is a hash of the message using =
   ETR includes authentication data that is a =
hash of the message using

      

      
   a pair-wise =
shared key.  An implementation must =
support use of HMAC-    a pair-wise =
shared key.  An implementation MUST =
support use of HMAC-

      
   SHA-1-96 =
[RFC2104] and should support use of =
HMAC-SHA-256-128    SHA-1-96 =
[RFC2104] and SHOULD support use of =
HMAC-SHA-256-128

      
   [RFC6234] =
(SHA-256 truncated to 128 bits).    =
[RFC6234] (SHA-256 truncated to 128 bits).

      
 =


      

      
   As noted in =
Section 5.2, a Map-Server should verify =
that all EID-    As noted in Section =
5.2, a Map-Server SHOULD verify that all =
EID-

      
   Prefixes =
registered by an ETR match the configuration stored on the =
   Prefixes registered by an ETR match the =
configuration stored on the

      
   =
Map-Server.    Map-Server.

      
 =


      
   The currently =
defined authentication mechanism for Map-Register    The currently defined authentication mechanism for =
Map-Register

      
   messages does =
not provide protection against "replay" attacks by a    messages does not provide protection against "replay" =
attacks by a

      
   =
"man-in-the-middle".  Additional work is needed in this area. =
   "man-in-the-middle".  Additional work is =
needed in this area.

      
 =


      
   =
[I-D.ietf-lisp-sec] defines a proposed mechanism for providing =
origin    [I-D.ietf-lisp-sec] defines =
a proposed mechanism for providing origin

      
   =
authentication, integrity, anti-replay protection, and prevention =
of    authentication, integrity, =
anti-replay protection, and prevention of

      
   =
man-in-the-middle and "overclaiming" attacks on the =
Map-Request/Map-    man-in-the-middle =
and "overclaiming" attacks on the Map-Request/Map-

      
   Reply =
exchange.  Work is ongoing on this and other proposals for =
   Reply exchange.  Work is ongoing on this and =
other proposals for

      
   resolving =
these open security issues.    =
resolving these open security issues.

      
 =


      
   While beyond =
the scope of securing an individual Map-Server or Map-    While beyond the scope of securing an individual =
Map-Server or Map-

      

      
   Resolver, it =
should be noted that a BGP-based LISP+ALT =
network (if    Resolver, it SHOULD be noted that a BGP-based LISP+ALT =
network (if

      
   ALT is used as =
the mapping database infrastructure) can take    ALT is used as the mapping database infrastructure) =
can take

      
   advantage of =
standards work on adding security to BGP.    advantage of standards work on adding security to =
BGP.

      
 =


      
   A complete =
LISP threat analysis has been published in [RFC7835].    A complete LISP threat analysis has been published in =
[RFC7835].

      
   Please refer =
to it for more security related details.    Please refer to it for more security related =
details.

      
 =


      
7.  IANA =
Considerations 7.  IANA =
Considerations

      
 =


      
   This section =
provides guidance to the Internet Assigned Numbers    This section provides guidance to the Internet =
Assigned Numbers

      
   Authority =
(IANA) regarding registration of values related to this =
   Authority (IANA) regarding registration of =
values related to this

      
   LISP =
control-plane specification, in accordance with BCP 26    LISP control-plane specification, in accordance with =
BCP 26

      
   =
[RFC5226].    [RFC5226].

      
 =


      
   There are =
three namespaces (listed in the sub-sections below) in LISP =
   There are three namespaces (listed in the =
sub-sections below) in LISP

      
   that have been =
registered.    that have been =
registered.

      
 =


      

      
   o  LISP IANA =
registry allocations should not be made =
for purposes    o  LISP IANA registry =
allocations SHOULD not be made for =
purposes

      
      unrelated =
to LISP routing or transport protocols. =
      unrelated to LISP routing or transport protocols.

      
 =


      
   o  The =
following policies are used here with the meanings defined in =
   o  The following policies are used here with =
the meanings defined in

      
      BCP 26: =
"Specification Required", "IETF Review", "Experimental       BCP 26: "Specification Required", "IETF Review", =
"Experimental

      
      Use", and =
"First Come First Served".       Use", =
and "First Come First Served".

      
 =


      
7.1.  LISP Packet =
Type Codes 7.1.  LISP Packet Type =
Codes

      
 =


      
   It is being =
requested that the IANA be authoritative for LISP Packet =
   It is being requested that the IANA be =
authoritative for LISP Packet

      
   Type =
definitions and that it refers to this document as well as =
   Type definitions and that it refers to this =
document as well as

      
 =


      
skipping =
to change at page 36, line =
51 =C2=B6 =
skipping to change at page 36, line =
51 =C2=B6

      
              =
numbers/address-family-numbers.xhtml?, Febuary 2007.               numbers/address-family-numbers.xhtml?, =
Febuary 2007.

      
 =


      
   =
[I-D.ermagan-lisp-nat-traversal]    =
[I-D.ermagan-lisp-nat-traversal]

      
              =
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, =
              Ermagan, V., Farinacci, D., =
Lewis, D., Skriver, J., Maino,

      
              F., =
and C. White, "NAT traversal for LISP", draft-ermagan-               F., and C. White, "NAT traversal for =
LISP", draft-ermagan-

      
              =
lisp-nat-traversal-13 (work in progress), September 2017. =
              lisp-nat-traversal-13 (work in =
progress), September 2017.

      
 =


      
   =
[I-D.ietf-lisp-eid-mobility]    =
[I-D.ietf-lisp-eid-mobility]

      
              =
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, =
              Portoles-Comeras, M., Ashtaputre, =
V., Moreno, V., Maino,

      
              F., =
and D. Farinacci, "LISP L2/L3 EID Mobility Using a               F., and D. Farinacci, "LISP L2/L3 EID =
Mobility Using a

      

      
              =
Unified Control Plane", draft-ietf-lisp-eid-mobility-00 =
              Unified Control Plane", draft-ietf-lisp-eid-mobility-01

      
              =
(work in progress), May 2017. =
              (work in progress), November 2017.
 =


      
   =
[I-D.ietf-lisp-introduction]    =
[I-D.ietf-lisp-introduction]

      
              =
Cabellos-Aparicio, A. and D. Saucez, "An Architectural               Cabellos-Aparicio, A. and D. Saucez, "An =
Architectural

      
              =
Introduction to the Locator/ID Separation Protocol               Introduction to the Locator/ID Separation =
Protocol

      
              =
(LISP)", draft-ietf-lisp-introduction-13 (work in               (LISP)", draft-ietf-lisp-introduction-13 =
(work in

      
              =
progress), April 2015.               =
progress), April 2015.

      
 =


      
   =
[I-D.ietf-lisp-mn]    =
[I-D.ietf-lisp-mn]

      
              =
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP =
              Farinacci, D., Lewis, D., Meyer, =
D., and C. White, "LISP

      

      
              =
Mobile Node", draft-ietf-lisp-mn-00 (work =
in progress),               Mobile =
Node", draft-ietf-lisp-mn-01 (work in =
progress),

      
              =
April 2017.               October =
2017.

      
 =


      
   =
[I-D.ietf-lisp-rfc6830bis]    =
[I-D.ietf-lisp-rfc6830bis]

      
              =
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. =
              Farinacci, D., Fuller, V., Meyer, =
D., Lewis, D., and A.

      
              =
Cabellos-Aparicio, "The Locator/ID Separation Protocol               Cabellos-Aparicio, "The Locator/ID =
Separation Protocol

      

      
              =
(LISP)", draft-ietf-lisp-rfc6830bis-05 =
(work in progress),               =
(LISP)", draft-ietf-lisp-rfc6830bis-07 =
(work in progress),

      
              =
August 2017.               November =
2017.

      
 =


      
   =
[I-D.ietf-lisp-sec]    =
[I-D.ietf-lisp-sec]

      
              =
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.               Maino, F., Ermagan, V., Cabellos-Aparicio, =
A., and D.

      

      
              =
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-13               Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14

      
              =
(work in progress), September =
2017.               (work in =
progress), October 2017.

      
 =


      
   =
[I-D.ietf-lisp-signal-free-multicast]  =
  [I-D.ietf-lisp-signal-free-multicast]

      
              =
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", =
              Moreno, V. and D. Farinacci, =
"Signal-Free LISP Multicast",

      
              =
draft-ietf-lisp-signal-free-multicast-06 (work in               draft-ietf-lisp-signal-free-multicast-06 =
(work in

      
              =
progress), August 2017.               =
progress), August 2017.

      
 =


      
   =
[I-D.lewis-lisp-gpe]    =
[I-D.lewis-lisp-gpe]

      
              =
Lewis, D., Agarwal, P., Kreeger, L., Maino, F., Quinn, P., =
              Lewis, D., Agarwal, P., Kreeger, =
L., Maino, F., Quinn, P.,

      
              =
Smith, M., and N. Yadav, "LISP Generic Protocol               Smith, M., and N. Yadav, "LISP Generic =
Protocol

      
              =
Extension", draft-lewis-lisp-gpe-02 (work in progress), =
              Extension", =
draft-lewis-lisp-gpe-02 (work in progress),

      
 =


      
skipping =
to change at page 37, line =
47 =C2=B6 =
skipping to change at page 37, line =
47 =C2=B6

      
 =


      
   =
[I-D.quinn-vxlan-gpe]    =
[I-D.quinn-vxlan-gpe]

      
              =
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., =
              Quinn, P., Manur, R., Kreeger, =
L., Lewis, D., Maino, F.,

      
              =
Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, =
              Smith, M., Agarwal, P., Yong, L., =
Xu, X., Elzur, U., Garg,

      
              P., =
and D. Melman, "Generic Protocol Extension for VXLAN",               P., and D. Melman, "Generic Protocol =
Extension for VXLAN",

      
              =
draft-quinn-vxlan-gpe-04 (work in progress), February               draft-quinn-vxlan-gpe-04 (work in =
progress), February

      
              =
2015.               2015.

      
 =


      
   =
[I-D.rodrigueznatal-lisp-pubsub]    =
[I-D.rodrigueznatal-lisp-pubsub]

      
              =
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., =
              Rodriguez-Natal, A., Ermagan, V., =
Leong, J., Maino, F.,

      

      
              =
Cabellos-Aparicio, A., Barkai, S., and D. =
Farinacci,               =
Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,

      
              =
"Publish-Subscribe mechanism for LISP", =
draft-               Boucadair, M., =
Jacquenet, C., and s.

      
              rodrigueznatal-lisp-pubsub-00 =
(work in progress), August =
              =
stefano.secci@lip6.fr, "Publish/Subscribe Functionality

      
              =
2017.               for LISP", draft-rodrigueznatal-lisp-pubsub-01 (work =
in

      
 =
              progress), October 2017.

      
 =


      
   =
[LISP-CONS]    [LISP-CONS]

      
              =
Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, =
              Brim, S., Chiappa, N., Farinacci, =
D., Fuller, V., Lewis,

      
              D., =
and D. Meyer, "LISP-CONS: A Content distribution               D., and D. Meyer, "LISP-CONS: A Content =
distribution

      
              =
Overlay Network Service for LISP", Work in Progress, April =
              Overlay Network Service for =
LISP", Work in Progress, April

      
              =
2008.               2008.

      
 =


      
Appendix A.  =
Acknowledgments Appendix A.  =
Acknowledgments

      
 =


      
   The authors =
would like to thank Greg Schudel, Darrel Lewis, John    The authors would like to thank Greg Schudel, Darrel =
Lewis, John

      
 =


      
skipping =
to change at page 39, line =
19 =C2=B6 =
skipping to change at page 39, line =
19 =C2=B6

      
   Fabio Maino, =
and members of the lisp@ietf.org mailing list for their =
   Fabio Maino, and members of the =
lisp@ietf.org mailing list for their

      
   feedback and =
helpful suggestions.    feedback and =
helpful suggestions.

      
 =


      
   Special thanks =
are due to Noel Chiappa for his extensive work on    Special thanks are due to Noel Chiappa for his =
extensive work on

      
   caching with =
LISP-CONS, some of which may be used by Map-Resolvers.    caching with LISP-CONS, some of which may be used by =
Map-Resolvers.

      
 =


      
Appendix B.  =
Document Change Log Appendix B.  =
Document Change Log

      
 =


      
   [RFC Editor: =
Please delete this section on publication as RFC.]    [RFC Editor: Please delete this section on =
publication as RFC.]

      
 =


      

      
B.1.  Changes =
to draft-ietf-lisp-rfc6833bis-06 B.1. =
 Changes to draft-ietf-lisp-rfc6833bis-07

      
 =


      
 =
   o  Posted November =
2017.

      
 =


      
 =
   o  Make it more =
clear in a couple of places that RLOCs are used to

      
 =
      locate ETRs more =
so than for Map-Server Map-Request forwarding.

      
 =


      
 =
   o  Make it clear =
that "encapsualted" for a control message is an ECM

      
 =
      based =
message.

      
 =


      
 =
   o  Make it more =
clear what messages use source-port 4342 and which

      
 =
      ones use =
destinatino-port 4342.

      
 =


      
 =
   o  Don't make DDT =
references when the mapping transport system can be

      
 =
      of any type and =
the referneced text is general to it.

      
 =


      
 =
   o  Generalize text =
when referring to the format of an EID-prefix.

      
 =
      Can use othe AFIs =
then IPv4 and IPv6.

      
 =


      
 =
   o  Many editorial =
changes to clarify text.

      
 =


      
 =
   o  Changed some =
"must", "should", and "may" to capitalized.

      
 =


      
 =
B.2.  Changes to =
draft-ietf-lisp-rfc6833bis-06

      
 =


      
   o  Posted =
October 2017.    o  Posted October =
2017.

      
 =


      
   o  Spec the =
I-bit to include the xTR-ID in a Map-Request message to =
   o  Spec the I-bit to include the xTR-ID in a =
Map-Request message to

      
      be =
consistent with the Map-Register message and to anticipate the =
      be consistent with the Map-Register =
message and to anticipate the

      
      =
introduction of pubsub functionality to allow Map-Requests to =
      introduction of pubsub functionality to =
allow Map-Requests to

      
      subscribe =
to RLOC-set changes.       subscribe =
to RLOC-set changes.

      
 =


      
   o  Updated =
references for individual submissions that became working =
   o  Updated references for individual =
submissions that became working

      
      group =
documents.       group =
documents.

      
 =


      
   o  Updated =
references for working group documents that became RFCs. =
   o  Updated references for working group =
documents that became RFCs.

      
 =


      

      
B.2.  Changes to =
draft-ietf-lisp-rfc6833bis-05 B.3.  Changes to =
draft-ietf-lisp-rfc6833bis-05

      
 =


      
   o  Posted May =
2017.    o  Posted May 2017.

      
 =


      
   o  Update IANA =
Considerations section based on new requests from this    o  Update IANA Considerations section based on new =
requests from this

      
      document =
and changes from what was requested in [RFC6830].       document and changes from what was requested in =
[RFC6830].

      
 =


      

      
B.3.  Changes to =
draft-ietf-lisp-rfc6833bis-04 B.4.  Changes to =
draft-ietf-lisp-rfc6833bis-04

      
 =


      
   o  Posted May =
2017.    o  Posted May 2017.

      
 =


      
   o  Clarify how =
the Key-ID field is used in Map-Register and Map-    o  Clarify how the Key-ID field is used in =
Map-Register and Map-

      
      Notify =
messages.  Break the 16-bit field into a 8-bit Key-ID field =
      Notify messages.  Break the 16-bit field =
into a 8-bit Key-ID field

      
      and a 8-bit =
Algorithm-ID field.       and a 8-bit =
Algorithm-ID field.

      
 =


      
   o  Move the =
control-plane codepoints from the IANA Considerations    o  Move the control-plane codepoints from the IANA =
Considerations

      
      section of =
RFC6830bis to the IANA Considerations section of this       section of RFC6830bis to the IANA Considerations =
section of this

      
      =
document.       document.

      
 =


      
   o  In the =
"LISP Control Packet Type Allocations" section, indicate =
   o  In the "LISP Control Packet Type =
Allocations" section, indicate

      
      how message =
Types are IANA allocated and how experimental RFC8113       how message Types are IANA allocated and how =
experimental RFC8113

      
      sub-types =
should be requested.       sub-types =
should be requested.

      
 =


      

      
B.4.  Changes to =
draft-ietf-lisp-rfc6833bis-03 B.5.  Changes to =
draft-ietf-lisp-rfc6833bis-03

      
 =


      
   o  Posted =
April 2017.    o  Posted April =
2017.

      
 =


      
   o  Add types =
9-14 and specify they are not assigned. =
   o  Add types 9-14 and specify they are not assigned.

      
 =


      
   o  Add the =
"LISP Shared Extension Message" type and point to RFC8113. =
   o  Add the "LISP Shared Extension Message" =
type and point to RFC8113.

      
 =


      

      
B.5.  Changes to =
draft-ietf-lisp-rfc6833bis-02 B.6.  Changes to =
draft-ietf-lisp-rfc6833bis-02

      
 =


      
   o  Posted =
April 2017.    o  Posted April =
2017.

      
 =


      
   o  Clarify =
that the LISP control-plane document defines how the LISP =
   o  Clarify that the LISP control-plane =
document defines how the LISP

      
      data-plane =
uses Map-Requests with either the SMR-bit set or the       data-plane uses Map-Requests with either the =
SMR-bit set or the

      
      P-bit set =
supporting mapping updates and RLOC-probing.  Indicating =
      P-bit set supporting mapping updates and =
RLOC-probing.  Indicating

      
      that other =
data-planes can use the same mechanisms or their own       that other data-planes can use the same mechanisms =
or their own

      
      defined =
mechanisms to achieve the same functionality.       defined mechanisms to achieve the same =
functionality.

      
 =


      

      
B.6.  Changes to =
draft-ietf-lisp-rfc6833bis-01 B.7.  Changes to =
draft-ietf-lisp-rfc6833bis-01

      
 =


      
   o  Posted =
March 2017.    o  Posted March =
2017.

      
 =


      
   o  Include =
references to new RFCs published.    o =
 Include references to new RFCs published.

      
 =


      
   o  Remove =
references to self.    o  Remove =
references to self.

      
 =


      
   o  Change =
references from RFC6830 to RFC6830bis.  =
  o  Change references from RFC6830 to RFC6830bis.

      
 =


      
   o  Add two new =
action/reasons to a Map-Reply has posted to the LISP    o  Add two new action/reasons to a Map-Reply has =
posted to the LISP

      
      WG mailing =
list.       WG mailing list.

      
 =


      
   o  In intro =
section, add refernece to I-D.ietf-lisp-introduction.    o  In intro section, add refernece to =
I-D.ietf-lisp-introduction.

      
 =


      
   o  Removed =
Open Issues section and references to "experimental".    o  Removed Open Issues section and references to =
"experimental".

      
 =


      

      
B.7.  Changes to =
draft-ietf-lisp-rfc6833bis-00 B.8.  Changes to =
draft-ietf-lisp-rfc6833bis-00

      
 =


      
   o  Posted =
December 2016.    o  Posted December =
2016.

      
 =


      
   o  Created =
working group document from draft-farinacci-lisp    o  Created working group document from =
draft-farinacci-lisp

      
      -rfc6833-00 =
individual submission.  No other changes made.       -rfc6833-00 individual submission.  No other =
changes made.

      
 =


      

      
B.8.  Changes to =
draft-farinacci-lisp-rfc6833bis-00 B.9.  Changes to =
draft-farinacci-lisp-rfc6833bis-00

      
 =


      
   o  Posted =
November 2016.    o  Posted November =
2016.

      
 =


      
   o  This is the =
initial draft to turn RFC 6833 into RFC 6833bis.    o  This is the initial draft to turn RFC 6833 into =
RFC 6833bis.

      
 =


      
   o  The =
document name has changed from the "Locator/ID Separation =
   o  The document name has changed from the =
"Locator/ID Separation

      
      Protocol =
(LISP) Map-Server Interface" to the "Locator/ID       Protocol (LISP) Map-Server Interface" to the =
"Locator/ID

      
      Separation =
Protocol (LISP) Control-Plane".       =
Separation Protocol (LISP) Control-Plane".

      
 =


      
   o  The =
fundamental change was to move the control-plane messages from =
   o  The fundamental change was to move the =
control-plane messages from


     
 

     
 End of changes. 64 change blocks. 

     
125 lines changed or =
deleted 154 lines changed or =
added

     

This =
html diff was produced by rfcdiff 1.46. The latest version is available =
from http://tools.ietf.org/to=
ols/rfcdiff/ 

   

  =20
  =20
=

--Apple-Mail=_DBF0C28B-2AF8-4A3E-9415-93AA2CB96858
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii





--Apple-Mail=_DBF0C28B-2AF8-4A3E-9415-93AA2CB96858--


From nobody Wed Nov 29 08:52:54 2017
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 856B912009C; Wed, 29 Nov 2017 08:52:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: lisp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197437351.7944.17794546083400854990@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:52:53 -0800
Archived-At: 
Subject: [lisp] I-D Action: draft-ietf-lisp-signal-free-multicast-07.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:52:53 -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 WG of the IETF.

        Title           : Signal-Free LISP Multicast
        Authors         : Victor Moreno
                          Dino Farinacci
	Filename        : draft-ietf-lisp-signal-free-multicast-07.txt
	Pages           : 23
	Date            : 2017-11-29

Abstract:
   When multicast sources and receivers are active at LISP sites, the
   core network is required to use native multicast so packets can be
   delivered from sources to group members.  When multicast is not
   available to connect the multicast sites together, a signal-free
   mechanism can be used to allow traffic to flow between sites.  The
   mechanism within here uses unicast replication and encapsulation over
   the core network for the data-plane and uses the LISP mapping
   database system so encapsulators at the source LISP multicast site
   can find decapsulators at the receiver LISP multicast sites.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-signal-free-multicast/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-signal-free-multicast-07
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-signal-free-multicast-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-signal-free-multicast-07


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 Wed Nov 29 10:04:45 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262231289B5 for ; Wed, 29 Nov 2017 10:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3JvW_1NnAYQ6 for ; Wed, 29 Nov 2017 10:04:40 -0800 (PST)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 1C90512896F for ; Wed, 29 Nov 2017 10:04:40 -0800 (PST)
Received: by mail-io0-x22a.google.com with SMTP id s37so4596564ioe.10 for ; Wed, 29 Nov 2017 10:04:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qb1iims7QyihBzqFnulsAeqxWfo6Qn3MA98Y7mjXroc=; b=kTgwXV0pQT5LE5bgt7i4Y4SiBVnFUz7K+YSQYl7Byb9wqP/TJtpnhzyHOViqxJS2aS 2Jxb8qokV+L42rhrCsuLyjYYVOO5uQPJspIfdA+VUezTKSavxZU4X4RVCNJQEAsCMNEA igh5XHpz5ufeuTmdIpJlgrdFxzkxvHS8l/DvHEvtqB1wOoxRe96mXX/VnPPl8AmuOLwl fwxJWbftaD+GI0TngxPkkp3pMVx9rlNioeFjNizBf32PPKzFHn2fXhA+eu8ILiuOnCoP UIvURIkV1M1LqFd8vCiW3C6/+obXSmm25X81Xlcs+gdnludRy8hIzr4QjKyHQU7QSr5y 6gHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qb1iims7QyihBzqFnulsAeqxWfo6Qn3MA98Y7mjXroc=; b=CklKtrnIPLNzl7G5aTF/uW/gOH01D1IAZZxNrHI4VD66cd0X5i2aSeGJiGyhbfrPvw lyJ/ANoCQeVTcNensXELTF/bvS5KEWTB7sFhjwji20apRPPysLZ9B7A+nQCrPHTKRPQt aEwYb01BbOqAT/Ac78vi5n3IJPc26iEH6xOAFH5y/Kkl5o6bdsva08dJYQbqdY9+KYr7 D4SwHoobd45kn5T8cCmf3HGCMauIOwMd8si+SiCUaa4gEjU37UAetN8r4C0nuwVEN+g3 5+XK+HuTa7xcPuqqtNmyQyJlhv0A7p8DnVoJ0vMu3JW9zWH6vdMp/VAZKzc8wj8+hO9l gwyA==
X-Gm-Message-State: AJaThX6ZUuKNNtDgG+oUeRtpYG2ZDMEa7Dqhn1olISv0E1FWikR8GHUf p064KXQp0OZFeFFJLnkQCGJLuhWGFat7AZEwvkA=
X-Google-Smtp-Source: AGs4zMYQrh/7lSoi0Ra1+efCzgsjwMP8mLzb7B7g2Gp9b+kS/5A+zwriKbGNNphPzop/6sLMLySWL8GSwbi6fef9Dq8=
X-Received: by 10.107.1.15 with SMTP id 15mr2475364iob.249.1511978678940; Wed, 29 Nov 2017 10:04:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.181.70 with HTTP; Wed, 29 Nov 2017 10:04:18 -0800 (PST)
In-Reply-To: <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com>
References:  <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com>
From: Alberto Rodriguez-Natal 
Date: Wed, 29 Nov 2017 10:04:18 -0800
Message-ID: 
To: Dino Farinacci 
Cc: "lisp@ietf.org list" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [lisp] Review of RFC6833bis
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 18:04:43 -0000

Thanks for the responses Dino. I'll get back to you later this week.

Alberto

On Tue, Nov 28, 2017 at 5:12 PM, Dino Farinacci  wrote=
:
>> Hi all,
>>
>> Wanted to send this before the meeting on Friday. I just completed a
>> review of 6833bis, you can find my comments below. Like last time,
>> extracts from the draft are copied and followed by my comments.
>>
>> Thanks,
>> Alberto
>
> Thanks again Alberto for your comments. See my responses inline and a -07=
 diff file.
>
>> Map-Resolver:  A network infrastructure component that accepts LISP
>> Encapsulated Map-Requests,
>>
>>    =E2=80=A2 [AR] We could remove "Encapsulated" and just use "Map-Reque=
sts".
>> A Map-Resolver may accept non-encapsulated Map-Requests as well.
>
> No, they are =E2=80=9Ccontrol-plane=E2=80=9D encapsulated. I=E2=80=99ll m=
ake that more clear.
>
>> Map-Register message:   A LISP message sent by an ETR to a Map-Server
>> to register its associated EID-Prefixes.  In addition to the set of
>> EID-Prefixes to register, the message includes one or more RLOCs to be
>> used by the Map-Server when forwarding Map-Requests (re-formatted as
>> Encapsulated Map-Requests) received through the database mapping
>> system.
>>
>>    =E2=80=A2 [AR] This may give the impression that the RLOCs on the
>> Map-Register are only to forward Map-Requests, which is not the case
>> in proxy-reply mode. I would suggest we rephrase this text as follows:
>> "In addition to the set of EID-Prefixes to register, the message
>> includes one or more RLOCs to be used to reach the ETR. The Map-Server
>> uses these RLOCs when it has to forward Map-Requests (potentially
>> re-formatted as Encapsulated Map-Requests) received through the
>> database mapping system.=E2=80=9D
>
> I reworded.
>
>> Map-Notify message:   A LISP message sent by a Map-Server to an ETR
>>
>>    =E2=80=A2 [AR] I would replace "ETR" with "xTR" so we cover the PubSu=
b
>> behavior as well.
>
> Can=E2=80=99t do that because an ITR does not get Map-Notifies as a respo=
nse to a Map-Register. But I will add that ITRs get Map-Notifies to inform =
them of RLOC-set changes (for pubsub and signal-free-multicast use-cases).
>
>>
>> For definitions of other terms -- notably Map-Request, Map-Reply,
>> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please
>> consult the LISP specification [I-D.ietf-lisp-rfc6830bis].
>>
>>    =E2=80=A2 [AR] I think that the definitions for Map-Request and Map-R=
eply
>> should be moved here, and probably we should include the definition
>> for Map-Notify-Ack as well. 6830bis should reference 6833bis for
>> control-plane messages, not the other way around.
>
> They did. But the text you identified above was not changed. Changed now.
>
>> A Map-Register message contains a list of EID-Prefixes plus a set of
>> RLOCs that can be used to reach the ETR when a Map-Server needs to
>> forward a Map-Request to it.
>>
>>    =E2=80=A2 [AR] Since proxy-reply is a common case, I'd not constrain =
the
>> meaning of the RLOCs in the Map-Register. I'd remove the last part of
>> the sentence that says "when a Map-Server needs to forward a
>> Map-Request to it.=E2=80=9D
>
> Agree.
>
>> A Map-Resolver receives Encapsulated Map-Requests from its client ITRs
>> and uses a mapping database system to find the appropriate ETR to
>> answer those requests.
>>
>>    =E2=80=A2 [AR] A MR can receive Map-Requests that don't come from ITR
>> and/or that are not encapsulated. If we don't want to change the text,
>> at least I'd add at the beginning: "In a common scenario, a
>> Map-Resolver=E2=80=A6"
>
> I don=E2=80=99t think we should change this. The lig document indicates t=
hat a lig client can send Map-Requests. This document is for support of a d=
ata-plane.
>
>> Note that while it is conceivable that a non-LISP-DDT Map-Resolver
>> could cache responses to improve performance,
>>
>>    =E2=80=A2 [AR] The discussion on caching or not at the Map-Resolver g=
oes
>> beyond DDT. We could rephrase this removing the mention to
>> "non-LISP-DDT=E2=80=9D.
>
> Agree. Changed.
>
>> The LISP UDP-based messages are the Map-Request and Map-Reply
>> messages.  When a UDP Map-Request is sent, the UDP source port is
>> chosen by the sender and the destination UDP port number is set to
>> 4342.  When a UDP Map-Reply is sent, the source UDP port number is set
>> to 4342 and the destination UDP port number is copied from the source
>> port of either the Map-Request or the invoking data packet.
>>
>>    =E2=80=A2 [AR] I would remove the first sentence and re-phrase this
>> paragraph as follows: "When a UDP LISP control message is sent and is
>> not a direct reply to a previous control message, the UDP source port
>> is chosen by the sender and the destination UDP port number is set to
>> 4342.  When a UDP LISP control message is sent as a direct reply to a
>> previous message, the source UDP port number is set to 4342 and the
>> destination UDP port number is either set to 4342 or copied from the
>> source port of the invoking LISP control message. See the following
>> subsections for details.=E2=80=9D
>
> This is not really true. There are too many cases with respect to NAT-tra=
versal that make things more complicated. I think we need to be specific ab=
out each message and not generalize it. Plus, Map-Notify messages are respo=
nse and unsolicited so they vary on whether the destination or source port =
is 4342.
>
> I have added text to identify each message that follow the Map-Request an=
d Map-Reply port rules.
>
>> The UDP checksum is computed and set to non-zero for Map-Request,
>> Map-Reply, Map-Register, and Encapsulated Control Message (ECM)
>> control messages.
>>
>>    =E2=80=A2 [AR] Shouldn't it be computed for all LISP control messages=
?
>
> Yes. Added text.
>
>> EID-Prefix:  This prefix is 4 octets for an IPv4 address family and 16
>> octets for an IPv6 address family.  When a Map-Request is sent by an
>> ITR because a data packet is received for a destination where there is
>> no mapping entry, the EID-Prefix is set to the destination IP address
>> of the data packet, and the 'EID mask-len' is set to 32 or 128 for
>> IPv4 or IPv6, respectively.
>>
>>    =E2=80=A2 [AR] We should probably rephrase this to don't limit it to =
IPv4/6
>
> Good point. Generalized the text a bit.
>
>> For the latter two cases, the destination IP address used for the
>> Map-Request is one of the RLOC addresses from the Locator-Set of the
>> Map-Cache entry.
>>
>>    =E2=80=A2 [AR] To refresh map-caches before TTL expiration, the
>> destination IP of the Map-Request can be the address of the Map-Server
>> if in proxy-reply. This should be considered here.
>
> This is not true. The Map-Request has an IP header but it is encapsulated=
 in an ECM and that IP header destination address is the *Map-Resolvers*.
>
>> If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier
>> MUST drop the Map-Request.
>>
>>    =E2=80=A2 [AR] This could probably be a SHOULD since we use AFI =3D 0=
 as
>> ITR-RLOC to unsubscribe in PubSub.
>
> An AFI=3D0 Is an RLOC address.
>
>> EID-Prefix:  This prefix is 4 octets for an IPv4 address family and 16
>> octets for an IPv6 address family.
>>
>>    =E2=80=A2 [AR] We should mention the possibility for address families
>> other than IPv4/6.
>
> Have that covered.
>
>> The RLOCs in the Map-Reply are globally routable IP addresses of all
>> ETRs for the LISP site.
>>
>>    =E2=80=A2 [AR] We should remove "globally" here. Maybe also add a
>> "Generally" at the beginning since we might have LCAFs with AFI =3D 0
>> (LISP-VPN encoding of Home-IID for instance).
>
> Removed =E2=80=9Cglobally=E2=80=9D. I don=E2=80=99t understand your other=
 =E2=80=9CGenerally=E2=80=9D comment.
>
>> For example, a requester with two cached EID-Prefixes that are covered
>> by a Map-Reply containing one less-specific prefix replaces the entry
>> with the less-specific EID-Prefix.
>>
>>    =E2=80=A2 [AR] Not sure if I follow here. Does this mean that a
>> less-specific received in a Map-Reply will erase from the map-cache
>> previously cached more-specifics that are covered by the
>> less-specific?
>
> Yes, because if the Map-Reply returned a more-specific with the less-spec=
ific, then it would be replaced so the less-specific replaces the more-spec=
ifics that ARE NOT in the Map-Reply.
>
>> When more than one EID-Prefix is returned, all SHOULD use the same
>> Time to Live value so they can all time out at the same time.  When a
>> more-specific EID-Prefix is received later, its Time to Live value in
>> the Map-Reply record can be stored even when other less-specific
>> entries exist.
>>
>>    =E2=80=A2 [AR] We should explain in which cases a more-specific can b=
e
>> received later.
>
> I don=E2=80=99t follow. Each EID-record will contain a TTL for the length=
 prefix that is encoded. So the new Map-Reply TTL will be used for any leng=
th entry (and in this case the more-specific).
>
>> The Locator-Set MUST be sorted in order of ascending IP address where
>> an IPv4 locator address is considered numerically 'less than' an IPv6
>> locator address.
>>
>>    =E2=80=A2 [AR] LCAF addresses (maybe with AFI=3D0) should be discusse=
d here as well.
>
> It is discussed in the LCAF draft. Don=E2=80=99t want to repeat it.
>
>> Nonce:  This 8-octet 'Nonce' field is set to 0 in Map-Register messages.
>>
>>    =E2=80=A2 [AR] Since there may be future cases that benefit from havi=
ng a
>> non-zero nonce on the Map-Register, I would suggest to rephrase this
>> sentence to add a CAN.
>
> Not until we identify and describe the use-case. No point to speculate. B=
ut note, if a Map-Notify is returned, the nonce should be non-zero. I=E2=80=
=99ll fix that.
>
>> E:  This is the to-ETR bit.  When set to 1, the Map-Server's intention
>> is to forward the ECM to an authoritative ETR.
>>
>>    =E2=80=A2 [AR] Can M and E be set at the same time?
>
> It can. M bit is set to indicate to avoid DDT procedures. The E bit tells=
 the Map-Server what to do with the Map-Request.
>
>> LCM:  The format is one of the control message formats described in
>> this section.  At this time, only Map-Request messages are allowed to
>> be encapsulated.
>>
>>    =E2=80=A2 [AR] Shall we mention the NAT traversal draft?
>
> No, this is an ECM, not a data-encapsulated control-message.
>
>> A Map-Server's configuration must also include a list of the
>> EID-Prefixes for which each ETR is authoritative.
>>
>>    =E2=80=A2 [AR] There may be certain cases where this does not need to=
 be
>> pre-configured. I suggest we replace the "must" with a "should". Note
>> that this requirement is already a "should" in section 6.
>
> Agree.
>
>> See [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets
>> certain flags (such as those indicating whether the message is
>> authoritative and how returned Locators should be treated) when
>> sending a Map-Reply on behalf of an ETR.
>>
>>    =E2=80=A2 [AR] It may be useful to discuss at least some of those det=
ails here.
>
> It does following this.
>
> I also made the document RFC2119 compliant where the terms for not capita=
lized. There were a few places.
>
> Thanks again,
> Dino
>
>
>
>
>
>


From nobody Wed Nov 29 11:09:11 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A48F12420B for ; Wed, 29 Nov 2017 11:09:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 2iumDwHP8Ew8 for ; Wed, 29 Nov 2017 11:09:07 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3807127342 for ; Wed, 29 Nov 2017 11:09:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18972; q=dns/txt; s=iport; t=1511982547; x=1513192147; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nQxo23pQKBW3ixidbqT34R4g4VdM1bOj04g5sU7BaUM=; b=lzhrrl6IL5BgthCrM7D/SEXQ617Bp41ipp6qEHOn4n5VL51Ycoi9drl2 iEvGCDrUCkS+oOjbaNOC/dni0+3N40yDdUdjqqyN9KMoSUzVlcsH9vu+Q 3Uqerz0wG7uuKzwq+f3Jr0OBcNoX9SjUNCmqOWpNuJOkWJqCZHsrhrEEj I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAABrBR9a/5pdJa1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPGZuJweDeIogjnCBfYhqjgoQggEKGAuFGAIahHo/GAEBAQE?= =?us-ascii?q?BAQEBAWsohR8BAQEBAgEBASERGiALBQsCAQgYAgImAgICHwYKARUQAgQIBgUdB?= =?us-ascii?q?IlpAw0IEKc7gieHNA2DJgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CMoIJgVa?= =?us-ascii?q?BaSmDAoFJgSKCCgUOAhaDFTGCMgWKLok9jiU9AokMglCEN4R5ghaGD4QHhyWNN?= =?us-ascii?q?IhhAhEZAYE5AR85QIERbxU6KgGBfoJSBQcQgWd3hzGBMoEUAQEB?=
X-IronPort-AV: E=Sophos;i="5.45,338,1508803200"; d="scan'208";a="320320350"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2017 19:09:05 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vATJ95Ta008317 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Nov 2017 19:09:05 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.1320.4; Wed, 29 Nov 2017 13:09:05 -0600
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.1320.000; Wed, 29 Nov 2017 13:09:05 -0600
From: "Victor Moreno (vimoreno)" 
To: "lisp@ietf.org list" 
CC: Dino Farinacci , Alberto Rodriguez-Natal 
Thread-Topic: [lisp] Review of RFC6833bis
Thread-Index: AQHTXrXNR7Hy+g3yfUu98/9n+cgnR6MrBWCAgAEavACAABIVgA==
Date: Wed, 29 Nov 2017 19:09:05 +0000
Message-ID: <53F582DF-33D8-41BF-94F4-CCE65D6C7908@cisco.com>
References:  <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com> 
In-Reply-To: 
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.19.157.242]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6DEB05404B5E1A428187F453B6134446@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [lisp] Review of RFC6833bis
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 19:09:10 -0000

SW4gYWRkaXRpb24gdG8gdGhlIGNvbW1lbnRzIHByb3ZpZGVkIGJ5IEFsYmVydG8gYW5kIERpbm8s
IEkgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRoZSB0ZXh0IGluIHNlY3Rpb24gNSBvZiB0aGUgUkZD
LiANCg0KMS4gVGhlIHRleHQgaW4gc2VjdGlvbiA1IGN1cnJlbnRseSBwcmVzY3JpYmVzIHRoYXQg
aW4gcmVzcG9uc2UgdG8gYSBtYXAtcmVxdWVzdCBmb3IgYSBub24tcmVnaXN0ZXJlZCBvciBub24t
ZXhpc3RlbnQgRUlELCBhbiBJVFIgc2hvdWxkIGV4cGVjdCBhbiBOTVIgZnJvbSB0aGUgTWFwLVNl
cnZlciAob3IgUmVzb2x2ZXIpIHdpdGggYWN0aW9uIGNvZGUg4oCcTmF0aXZlbHktRm9yd2FyZOKA
nSAodGhpcyBpcyBzdGF0ZWQgaW4gc2VjdGlvbiA1LjEgYW5kIHJlLXN0YXRlZCBpbiA1LjMgYW5k
IDUuNCkuIFByZXNjcmliaW5nIHRoYXQgdGhpcyBpcyB0byBhbHdheXMgYmUgYW4gTk1SIHdpdGgg
YSBOYXRpdmUtRm9yd2FyZCBhY3Rpb24gaXMgbGltaXRpbmcuIA0KDQpBZnRlciB0cnlpbmcgdG8g
YWRkcmVzcyBhIGZldyB1c2UgY2FzZXMsIGl0IHdvdWxkIGJlIHZlcnkgdXNlZnVsIGlmIHRoZSBz
cGVjaWZpY2F0aW9uIGFsbG93ZWQ6DQoNCmEuIEFzIGFuIGFsdGVybmF0aXZlIHRvIHJlc3BvbmRp
bmcgd2l0aCBhbiBOTVIsIGFuIGltcGxlbWVudGF0aW9uIG1heSByZXNwb25kIHRvIGEgTWFwLVJl
cXVlc3QgZm9yIGEgbm9uLXJlZ2lzdGVyZWQgb3Igbm9uLWV4aXN0ZW50IEVJRCB3aXRoIGEg4oCc
cG9zaXRpdmUiIG1hcC1yZXBseSBpbmNsdXNpdmUgb2YgYW4gUkxPQy1zZXQgdGhhdCBjYW4gYmUg
Y29uZmlndXJlZCBpbiB0aGUgTWFwcGluZy1TeXN0ZW0uIFRoZSBpbW1lZGlhdGUgdXNlIGNhc2Ug
dGhpcyB3b3VsZCBhZGRyZXNzIGlzIHRoYXQgb2Ygbm90IGhhdmluZyB0byBjb25maWd1cmUgYSBQ
RVRSIHN0YXRpY2FsbHkgYXQgZXZlcnkgSVRSLCBidXQgaGF2ZSB0aGUgbWFwLXJlcGxpZXMgaW5j
bHVkZSB0aGUgUEVUUidzIFJMT0MgaW5mb3JtYXRpb24uIFRoaXMgTWFwLVJlcGx5IHNob3VsZCBo
YXZlIHNob3J0IFRUTHMgYW5kIGluY2x1ZGUgY292ZXJpbmcvaG9sZSBFSUQgcHJlZml4ZXMganVz
dCBhcyBzcGVjaWZpZWQgZm9yIHRoZSBjdXJyZW50IE5NUnMsIGhlbmNlIHRoaXMgZGlmZmVycyBm
cm9tIGEgbWFwLXJlcGx5IGZvciByZWdpc3RlcmVkIDAvMCBFSURzLg0KDQpiLiBUaGUgdXNlIG9m
IGFsbCBhY3Rpb24gY29kZXMgcG9zc2libGUgd2l0aCB0aGUgQUNUIGJpdHMgKGFzIGRlZmluZWQg
aW4gc2VjdGlvbiA0LjQpIHdoZW4gTWFwLVJlcGx5aW5nIHdpdGggYW4gTk1SIHRvIGEgTWFwLVJl
cXVlc3QgZm9yIGEgbm9uLXJlZ2lzdGVyZWQgb3Igbm9uLWV4aXN0ZW50IEVJRC4gQXMgSSByZWFk
IHRoZSB0ZXh0IGluIHNlY3Rpb24gNSwgaXQgaXNu4oCZdCBjbGVhciB0aGF0IG90aGVyIGFjdGlv
biBjb2RlcyBhcmUgYWxsb3dlZCwgdGhlIHRleHQgaXMgZm9jdXNlZCBzb2xlbHkgb24gTmF0aXZl
bHktRm9yd2FyZCwgdGhlcmUgYXJlIHN0cm9uZyByZXF1aXJlbWVudHMgdG8gbGV2ZXJhZ2UgdGhl
IERyb3AgYWN0aW9uIGFuZCBwYXJ0aWN1bGFybHkgRHJvcC9Qb2xpY3ktRGVuaWVkLg0KDQoyLiBU
aGVyZSBhcmUgbXVsdGlwbGUgcmVmZXJlbmNlcyB0byBMSVNQLUFMVCBpbiB0aGUgdGV4dC4gRG8g
d2Ugd2FudCB0byBrZWVwIHRob3NlIHJlZmVyZW5jZXMgbW92aW5nIGZvcndhcmQ/IE9yIGNhbiB0
aGVzZSBiZSByZW1vdmVkPyBUaGUgaW1wbGVtZW50YXRpb25zIEkgd29yayB3aXRoIGRvIG5vdCB1
c2UgQUxULCBidXQgbWF5YmUgdGhlcmUgYXJlIG90aGVycyB0aGF0IGRvPw0KDQozLiBTZWN0aW9u
IDUuMy4gUGFyYWdyYXBoIDIgaXMgZGVzY3JpYmluZyB0aGUgYmVoYXZpb3IgZm9yIHRoZSBNUyB3
aGVuIHRoZXJlIGlzIGEgbWF0Y2ggb24gYW4gRUlEIOKAnGhvbGXigJ0uIFNlY3Rpb24gNS4zLiBz
dWdnZXN0cyBhIDE1IG1pbnV0ZSBUVEwsIG1lYW53aGlsZSBzZWN0aW9uIDUuMS4gc3VnZ2VzdHMg
YSAxIG1pbnV0ZSBUVEwgZm9yIHRoZSBzYW1lIEVJRC4gSSB0aGluayBpdCBzaG91bGQgYmUgMSBt
aW51dGUgaW4gYm90aCBjYXNlcy4gDQoNCkkgY2FuIGNvbnRyaWJ1dGUgd2l0aCB0ZXh0IHN1Z2dl
c3Rpb25zIG9uY2Ugd2UgZGlzY3VzcyB0aGUgYWJvdmUgb24gdGhlIGxpc3QuIA0KDQotdg0KDQoN
Cj4gT24gTm92IDI5LCAyMDE3LCBhdCAxMDowNCBBTSwgQWxiZXJ0byBSb2RyaWd1ZXotTmF0YWwg
PHJvZHJpZ3Vlem5hdGFsQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGFua3MgZm9yIHRoZSBy
ZXNwb25zZXMgRGluby4gSSdsbCBnZXQgYmFjayB0byB5b3UgbGF0ZXIgdGhpcyB3ZWVrLg0KPiAN
Cj4gQWxiZXJ0bw0KPiANCj4gT24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgNToxMiBQTSwgRGlubyBG
YXJpbmFjY2kgPGZhcmluYWNjaUBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IEhpIGFsbCwNCj4+PiAN
Cj4+PiBXYW50ZWQgdG8gc2VuZCB0aGlzIGJlZm9yZSB0aGUgbWVldGluZyBvbiBGcmlkYXkuIEkg
anVzdCBjb21wbGV0ZWQgYQ0KPj4+IHJldmlldyBvZiA2ODMzYmlzLCB5b3UgY2FuIGZpbmQgbXkg
Y29tbWVudHMgYmVsb3cuIExpa2UgbGFzdCB0aW1lLA0KPj4+IGV4dHJhY3RzIGZyb20gdGhlIGRy
YWZ0IGFyZSBjb3BpZWQgYW5kIGZvbGxvd2VkIGJ5IG15IGNvbW1lbnRzLg0KPj4+IA0KPj4+IFRo
YW5rcywNCj4+PiBBbGJlcnRvDQo+PiANCj4+IFRoYW5rcyBhZ2FpbiBBbGJlcnRvIGZvciB5b3Vy
IGNvbW1lbnRzLiBTZWUgbXkgcmVzcG9uc2VzIGlubGluZSBhbmQgYSAtMDcgZGlmZiBmaWxlLg0K
Pj4gDQo+Pj4gTWFwLVJlc29sdmVyOiAgQSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGNvbXBvbmVu
dCB0aGF0IGFjY2VwdHMgTElTUA0KPj4+IEVuY2Fwc3VsYXRlZCBNYXAtUmVxdWVzdHMsDQo+Pj4g
DQo+Pj4gICDigKIgW0FSXSBXZSBjb3VsZCByZW1vdmUgIkVuY2Fwc3VsYXRlZCIgYW5kIGp1c3Qg
dXNlICJNYXAtUmVxdWVzdHMiLg0KPj4+IEEgTWFwLVJlc29sdmVyIG1heSBhY2NlcHQgbm9uLWVu
Y2Fwc3VsYXRlZCBNYXAtUmVxdWVzdHMgYXMgd2VsbC4NCj4+IA0KPj4gTm8sIHRoZXkgYXJlIOKA
nGNvbnRyb2wtcGxhbmXigJ0gZW5jYXBzdWxhdGVkLiBJ4oCZbGwgbWFrZSB0aGF0IG1vcmUgY2xl
YXIuDQo+PiANCj4+PiBNYXAtUmVnaXN0ZXIgbWVzc2FnZTogICBBIExJU1AgbWVzc2FnZSBzZW50
IGJ5IGFuIEVUUiB0byBhIE1hcC1TZXJ2ZXINCj4+PiB0byByZWdpc3RlciBpdHMgYXNzb2NpYXRl
ZCBFSUQtUHJlZml4ZXMuICBJbiBhZGRpdGlvbiB0byB0aGUgc2V0IG9mDQo+Pj4gRUlELVByZWZp
eGVzIHRvIHJlZ2lzdGVyLCB0aGUgbWVzc2FnZSBpbmNsdWRlcyBvbmUgb3IgbW9yZSBSTE9DcyB0
byBiZQ0KPj4+IHVzZWQgYnkgdGhlIE1hcC1TZXJ2ZXIgd2hlbiBmb3J3YXJkaW5nIE1hcC1SZXF1
ZXN0cyAocmUtZm9ybWF0dGVkIGFzDQo+Pj4gRW5jYXBzdWxhdGVkIE1hcC1SZXF1ZXN0cykgcmVj
ZWl2ZWQgdGhyb3VnaCB0aGUgZGF0YWJhc2UgbWFwcGluZw0KPj4+IHN5c3RlbS4NCj4+PiANCj4+
PiAgIOKAoiBbQVJdIFRoaXMgbWF5IGdpdmUgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUgUkxPQ3Mg
b24gdGhlDQo+Pj4gTWFwLVJlZ2lzdGVyIGFyZSBvbmx5IHRvIGZvcndhcmQgTWFwLVJlcXVlc3Rz
LCB3aGljaCBpcyBub3QgdGhlIGNhc2UNCj4+PiBpbiBwcm94eS1yZXBseSBtb2RlLiBJIHdvdWxk
IHN1Z2dlc3Qgd2UgcmVwaHJhc2UgdGhpcyB0ZXh0IGFzIGZvbGxvd3M6DQo+Pj4gIkluIGFkZGl0
aW9uIHRvIHRoZSBzZXQgb2YgRUlELVByZWZpeGVzIHRvIHJlZ2lzdGVyLCB0aGUgbWVzc2FnZQ0K
Pj4+IGluY2x1ZGVzIG9uZSBvciBtb3JlIFJMT0NzIHRvIGJlIHVzZWQgdG8gcmVhY2ggdGhlIEVU
Ui4gVGhlIE1hcC1TZXJ2ZXINCj4+PiB1c2VzIHRoZXNlIFJMT0NzIHdoZW4gaXQgaGFzIHRvIGZv
cndhcmQgTWFwLVJlcXVlc3RzIChwb3RlbnRpYWxseQ0KPj4+IHJlLWZvcm1hdHRlZCBhcyBFbmNh
cHN1bGF0ZWQgTWFwLVJlcXVlc3RzKSByZWNlaXZlZCB0aHJvdWdoIHRoZQ0KPj4+IGRhdGFiYXNl
IG1hcHBpbmcgc3lzdGVtLuKAnQ0KPj4gDQo+PiBJIHJld29yZGVkLg0KPj4gDQo+Pj4gTWFwLU5v
dGlmeSBtZXNzYWdlOiAgIEEgTElTUCBtZXNzYWdlIHNlbnQgYnkgYSBNYXAtU2VydmVyIHRvIGFu
IEVUUg0KPj4+IA0KPj4+ICAg4oCiIFtBUl0gSSB3b3VsZCByZXBsYWNlICJFVFIiIHdpdGggInhU
UiIgc28gd2UgY292ZXIgdGhlIFB1YlN1Yg0KPj4+IGJlaGF2aW9yIGFzIHdlbGwuDQo+PiANCj4+
IENhbuKAmXQgZG8gdGhhdCBiZWNhdXNlIGFuIElUUiBkb2VzIG5vdCBnZXQgTWFwLU5vdGlmaWVz
IGFzIGEgcmVzcG9uc2UgdG8gYSBNYXAtUmVnaXN0ZXIuIEJ1dCBJIHdpbGwgYWRkIHRoYXQgSVRS
cyBnZXQgTWFwLU5vdGlmaWVzIHRvIGluZm9ybSB0aGVtIG9mIFJMT0Mtc2V0IGNoYW5nZXMgKGZv
ciBwdWJzdWIgYW5kIHNpZ25hbC1mcmVlLW11bHRpY2FzdCB1c2UtY2FzZXMpLg0KPj4gDQo+Pj4g
DQo+Pj4gRm9yIGRlZmluaXRpb25zIG9mIG90aGVyIHRlcm1zIC0tIG5vdGFibHkgTWFwLVJlcXVl
c3QsIE1hcC1SZXBseSwNCj4+PiBJbmdyZXNzIFR1bm5lbCBSb3V0ZXIgKElUUiksIGFuZCBFZ3Jl
c3MgVHVubmVsIFJvdXRlciAoRVRSKSAtLSBwbGVhc2UNCj4+PiBjb25zdWx0IHRoZSBMSVNQIHNw
ZWNpZmljYXRpb24gW0ktRC5pZXRmLWxpc3AtcmZjNjgzMGJpc10uDQo+Pj4gDQo+Pj4gICDigKIg
W0FSXSBJIHRoaW5rIHRoYXQgdGhlIGRlZmluaXRpb25zIGZvciBNYXAtUmVxdWVzdCBhbmQgTWFw
LVJlcGx5DQo+Pj4gc2hvdWxkIGJlIG1vdmVkIGhlcmUsIGFuZCBwcm9iYWJseSB3ZSBzaG91bGQg
aW5jbHVkZSB0aGUgZGVmaW5pdGlvbg0KPj4+IGZvciBNYXAtTm90aWZ5LUFjayBhcyB3ZWxsLiA2
ODMwYmlzIHNob3VsZCByZWZlcmVuY2UgNjgzM2JpcyBmb3INCj4+PiBjb250cm9sLXBsYW5lIG1l
c3NhZ2VzLCBub3QgdGhlIG90aGVyIHdheSBhcm91bmQuDQo+PiANCj4+IFRoZXkgZGlkLiBCdXQg
dGhlIHRleHQgeW91IGlkZW50aWZpZWQgYWJvdmUgd2FzIG5vdCBjaGFuZ2VkLiBDaGFuZ2VkIG5v
dy4NCj4+IA0KPj4+IEEgTWFwLVJlZ2lzdGVyIG1lc3NhZ2UgY29udGFpbnMgYSBsaXN0IG9mIEVJ
RC1QcmVmaXhlcyBwbHVzIGEgc2V0IG9mDQo+Pj4gUkxPQ3MgdGhhdCBjYW4gYmUgdXNlZCB0byBy
ZWFjaCB0aGUgRVRSIHdoZW4gYSBNYXAtU2VydmVyIG5lZWRzIHRvDQo+Pj4gZm9yd2FyZCBhIE1h
cC1SZXF1ZXN0IHRvIGl0Lg0KPj4+IA0KPj4+ICAg4oCiIFtBUl0gU2luY2UgcHJveHktcmVwbHkg
aXMgYSBjb21tb24gY2FzZSwgSSdkIG5vdCBjb25zdHJhaW4gdGhlDQo+Pj4gbWVhbmluZyBvZiB0
aGUgUkxPQ3MgaW4gdGhlIE1hcC1SZWdpc3Rlci4gSSdkIHJlbW92ZSB0aGUgbGFzdCBwYXJ0IG9m
DQo+Pj4gdGhlIHNlbnRlbmNlIHRoYXQgc2F5cyAid2hlbiBhIE1hcC1TZXJ2ZXIgbmVlZHMgdG8g
Zm9yd2FyZCBhDQo+Pj4gTWFwLVJlcXVlc3QgdG8gaXQu4oCdDQo+PiANCj4+IEFncmVlLg0KPj4g
DQo+Pj4gQSBNYXAtUmVzb2x2ZXIgcmVjZWl2ZXMgRW5jYXBzdWxhdGVkIE1hcC1SZXF1ZXN0cyBm
cm9tIGl0cyBjbGllbnQgSVRScw0KPj4+IGFuZCB1c2VzIGEgbWFwcGluZyBkYXRhYmFzZSBzeXN0
ZW0gdG8gZmluZCB0aGUgYXBwcm9wcmlhdGUgRVRSIHRvDQo+Pj4gYW5zd2VyIHRob3NlIHJlcXVl
c3RzLg0KPj4+IA0KPj4+ICAg4oCiIFtBUl0gQSBNUiBjYW4gcmVjZWl2ZSBNYXAtUmVxdWVzdHMg
dGhhdCBkb24ndCBjb21lIGZyb20gSVRSDQo+Pj4gYW5kL29yIHRoYXQgYXJlIG5vdCBlbmNhcHN1
bGF0ZWQuIElmIHdlIGRvbid0IHdhbnQgdG8gY2hhbmdlIHRoZSB0ZXh0LA0KPj4+IGF0IGxlYXN0
IEknZCBhZGQgYXQgdGhlIGJlZ2lubmluZzogIkluIGEgY29tbW9uIHNjZW5hcmlvLCBhDQo+Pj4g
TWFwLVJlc29sdmVy4oCmIg0KPj4gDQo+PiBJIGRvbuKAmXQgdGhpbmsgd2Ugc2hvdWxkIGNoYW5n
ZSB0aGlzLiBUaGUgbGlnIGRvY3VtZW50IGluZGljYXRlcyB0aGF0IGEgbGlnIGNsaWVudCBjYW4g
c2VuZCBNYXAtUmVxdWVzdHMuIFRoaXMgZG9jdW1lbnQgaXMgZm9yIHN1cHBvcnQgb2YgYSBkYXRh
LXBsYW5lLg0KPj4gDQo+Pj4gTm90ZSB0aGF0IHdoaWxlIGl0IGlzIGNvbmNlaXZhYmxlIHRoYXQg
YSBub24tTElTUC1ERFQgTWFwLVJlc29sdmVyDQo+Pj4gY291bGQgY2FjaGUgcmVzcG9uc2VzIHRv
IGltcHJvdmUgcGVyZm9ybWFuY2UsDQo+Pj4gDQo+Pj4gICDigKIgW0FSXSBUaGUgZGlzY3Vzc2lv
biBvbiBjYWNoaW5nIG9yIG5vdCBhdCB0aGUgTWFwLVJlc29sdmVyIGdvZXMNCj4+PiBiZXlvbmQg
RERULiBXZSBjb3VsZCByZXBocmFzZSB0aGlzIHJlbW92aW5nIHRoZSBtZW50aW9uIHRvDQo+Pj4g
Im5vbi1MSVNQLUREVOKAnS4NCj4+IA0KPj4gQWdyZWUuIENoYW5nZWQuDQo+PiANCj4+PiBUaGUg
TElTUCBVRFAtYmFzZWQgbWVzc2FnZXMgYXJlIHRoZSBNYXAtUmVxdWVzdCBhbmQgTWFwLVJlcGx5
DQo+Pj4gbWVzc2FnZXMuICBXaGVuIGEgVURQIE1hcC1SZXF1ZXN0IGlzIHNlbnQsIHRoZSBVRFAg
c291cmNlIHBvcnQgaXMNCj4+PiBjaG9zZW4gYnkgdGhlIHNlbmRlciBhbmQgdGhlIGRlc3RpbmF0
aW9uIFVEUCBwb3J0IG51bWJlciBpcyBzZXQgdG8NCj4+PiA0MzQyLiAgV2hlbiBhIFVEUCBNYXAt
UmVwbHkgaXMgc2VudCwgdGhlIHNvdXJjZSBVRFAgcG9ydCBudW1iZXIgaXMgc2V0DQo+Pj4gdG8g
NDM0MiBhbmQgdGhlIGRlc3RpbmF0aW9uIFVEUCBwb3J0IG51bWJlciBpcyBjb3BpZWQgZnJvbSB0
aGUgc291cmNlDQo+Pj4gcG9ydCBvZiBlaXRoZXIgdGhlIE1hcC1SZXF1ZXN0IG9yIHRoZSBpbnZv
a2luZyBkYXRhIHBhY2tldC4NCj4+PiANCj4+PiAgIOKAoiBbQVJdIEkgd291bGQgcmVtb3ZlIHRo
ZSBmaXJzdCBzZW50ZW5jZSBhbmQgcmUtcGhyYXNlIHRoaXMNCj4+PiBwYXJhZ3JhcGggYXMgZm9s
bG93czogIldoZW4gYSBVRFAgTElTUCBjb250cm9sIG1lc3NhZ2UgaXMgc2VudCBhbmQgaXMNCj4+
PiBub3QgYSBkaXJlY3QgcmVwbHkgdG8gYSBwcmV2aW91cyBjb250cm9sIG1lc3NhZ2UsIHRoZSBV
RFAgc291cmNlIHBvcnQNCj4+PiBpcyBjaG9zZW4gYnkgdGhlIHNlbmRlciBhbmQgdGhlIGRlc3Rp
bmF0aW9uIFVEUCBwb3J0IG51bWJlciBpcyBzZXQgdG8NCj4+PiA0MzQyLiAgV2hlbiBhIFVEUCBM
SVNQIGNvbnRyb2wgbWVzc2FnZSBpcyBzZW50IGFzIGEgZGlyZWN0IHJlcGx5IHRvIGENCj4+PiBw
cmV2aW91cyBtZXNzYWdlLCB0aGUgc291cmNlIFVEUCBwb3J0IG51bWJlciBpcyBzZXQgdG8gNDM0
MiBhbmQgdGhlDQo+Pj4gZGVzdGluYXRpb24gVURQIHBvcnQgbnVtYmVyIGlzIGVpdGhlciBzZXQg
dG8gNDM0MiBvciBjb3BpZWQgZnJvbSB0aGUNCj4+PiBzb3VyY2UgcG9ydCBvZiB0aGUgaW52b2tp
bmcgTElTUCBjb250cm9sIG1lc3NhZ2UuIFNlZSB0aGUgZm9sbG93aW5nDQo+Pj4gc3Vic2VjdGlv
bnMgZm9yIGRldGFpbHMu4oCdDQo+PiANCj4+IFRoaXMgaXMgbm90IHJlYWxseSB0cnVlLiBUaGVy
ZSBhcmUgdG9vIG1hbnkgY2FzZXMgd2l0aCByZXNwZWN0IHRvIE5BVC10cmF2ZXJzYWwgdGhhdCBt
YWtlIHRoaW5ncyBtb3JlIGNvbXBsaWNhdGVkLiBJIHRoaW5rIHdlIG5lZWQgdG8gYmUgc3BlY2lm
aWMgYWJvdXQgZWFjaCBtZXNzYWdlIGFuZCBub3QgZ2VuZXJhbGl6ZSBpdC4gUGx1cywgTWFwLU5v
dGlmeSBtZXNzYWdlcyBhcmUgcmVzcG9uc2UgYW5kIHVuc29saWNpdGVkIHNvIHRoZXkgdmFyeSBv
biB3aGV0aGVyIHRoZSBkZXN0aW5hdGlvbiBvciBzb3VyY2UgcG9ydCBpcyA0MzQyLg0KPj4gDQo+
PiBJIGhhdmUgYWRkZWQgdGV4dCB0byBpZGVudGlmeSBlYWNoIG1lc3NhZ2UgdGhhdCBmb2xsb3cg
dGhlIE1hcC1SZXF1ZXN0IGFuZCBNYXAtUmVwbHkgcG9ydCBydWxlcy4NCj4+IA0KPj4+IFRoZSBV
RFAgY2hlY2tzdW0gaXMgY29tcHV0ZWQgYW5kIHNldCB0byBub24temVybyBmb3IgTWFwLVJlcXVl
c3QsDQo+Pj4gTWFwLVJlcGx5LCBNYXAtUmVnaXN0ZXIsIGFuZCBFbmNhcHN1bGF0ZWQgQ29udHJv
bCBNZXNzYWdlIChFQ00pDQo+Pj4gY29udHJvbCBtZXNzYWdlcy4NCj4+PiANCj4+PiAgIOKAoiBb
QVJdIFNob3VsZG4ndCBpdCBiZSBjb21wdXRlZCBmb3IgYWxsIExJU1AgY29udHJvbCBtZXNzYWdl
cz8NCj4+IA0KPj4gWWVzLiBBZGRlZCB0ZXh0Lg0KPj4gDQo+Pj4gRUlELVByZWZpeDogIFRoaXMg
cHJlZml4IGlzIDQgb2N0ZXRzIGZvciBhbiBJUHY0IGFkZHJlc3MgZmFtaWx5IGFuZCAxNg0KPj4+
IG9jdGV0cyBmb3IgYW4gSVB2NiBhZGRyZXNzIGZhbWlseS4gIFdoZW4gYSBNYXAtUmVxdWVzdCBp
cyBzZW50IGJ5IGFuDQo+Pj4gSVRSIGJlY2F1c2UgYSBkYXRhIHBhY2tldCBpcyByZWNlaXZlZCBm
b3IgYSBkZXN0aW5hdGlvbiB3aGVyZSB0aGVyZSBpcw0KPj4+IG5vIG1hcHBpbmcgZW50cnksIHRo
ZSBFSUQtUHJlZml4IGlzIHNldCB0byB0aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzcw0KPj4+IG9m
IHRoZSBkYXRhIHBhY2tldCwgYW5kIHRoZSAnRUlEIG1hc2stbGVuJyBpcyBzZXQgdG8gMzIgb3Ig
MTI4IGZvcg0KPj4+IElQdjQgb3IgSVB2NiwgcmVzcGVjdGl2ZWx5Lg0KPj4+IA0KPj4+ICAg4oCi
IFtBUl0gV2Ugc2hvdWxkIHByb2JhYmx5IHJlcGhyYXNlIHRoaXMgdG8gZG9uJ3QgbGltaXQgaXQg
dG8gSVB2NC82DQo+PiANCj4+IEdvb2QgcG9pbnQuIEdlbmVyYWxpemVkIHRoZSB0ZXh0IGEgYml0
Lg0KPj4gDQo+Pj4gRm9yIHRoZSBsYXR0ZXIgdHdvIGNhc2VzLCB0aGUgZGVzdGluYXRpb24gSVAg
YWRkcmVzcyB1c2VkIGZvciB0aGUNCj4+PiBNYXAtUmVxdWVzdCBpcyBvbmUgb2YgdGhlIFJMT0Mg
YWRkcmVzc2VzIGZyb20gdGhlIExvY2F0b3ItU2V0IG9mIHRoZQ0KPj4+IE1hcC1DYWNoZSBlbnRy
eS4NCj4+PiANCj4+PiAgIOKAoiBbQVJdIFRvIHJlZnJlc2ggbWFwLWNhY2hlcyBiZWZvcmUgVFRM
IGV4cGlyYXRpb24sIHRoZQ0KPj4+IGRlc3RpbmF0aW9uIElQIG9mIHRoZSBNYXAtUmVxdWVzdCBj
YW4gYmUgdGhlIGFkZHJlc3Mgb2YgdGhlIE1hcC1TZXJ2ZXINCj4+PiBpZiBpbiBwcm94eS1yZXBs
eS4gVGhpcyBzaG91bGQgYmUgY29uc2lkZXJlZCBoZXJlLg0KPj4gDQo+PiBUaGlzIGlzIG5vdCB0
cnVlLiBUaGUgTWFwLVJlcXVlc3QgaGFzIGFuIElQIGhlYWRlciBidXQgaXQgaXMgZW5jYXBzdWxh
dGVkIGluIGFuIEVDTSBhbmQgdGhhdCBJUCBoZWFkZXIgZGVzdGluYXRpb24gYWRkcmVzcyBpcyB0
aGUgKk1hcC1SZXNvbHZlcnMqLg0KPj4gDQo+Pj4gSWYgdGhlIElUUiBlcnJvbmVvdXNseSBwcm92
aWRlcyBubyBJVFItUkxPQyBhZGRyZXNzZXMsIHRoZSBNYXAtUmVwbGllcg0KPj4+IE1VU1QgZHJv
cCB0aGUgTWFwLVJlcXVlc3QuDQo+Pj4gDQo+Pj4gICDigKIgW0FSXSBUaGlzIGNvdWxkIHByb2Jh
Ymx5IGJlIGEgU0hPVUxEIHNpbmNlIHdlIHVzZSBBRkkgPSAwIGFzDQo+Pj4gSVRSLVJMT0MgdG8g
dW5zdWJzY3JpYmUgaW4gUHViU3ViLg0KPj4gDQo+PiBBbiBBRkk9MCBJcyBhbiBSTE9DIGFkZHJl
c3MuDQo+PiANCj4+PiBFSUQtUHJlZml4OiAgVGhpcyBwcmVmaXggaXMgNCBvY3RldHMgZm9yIGFu
IElQdjQgYWRkcmVzcyBmYW1pbHkgYW5kIDE2DQo+Pj4gb2N0ZXRzIGZvciBhbiBJUHY2IGFkZHJl
c3MgZmFtaWx5Lg0KPj4+IA0KPj4+ICAg4oCiIFtBUl0gV2Ugc2hvdWxkIG1lbnRpb24gdGhlIHBv
c3NpYmlsaXR5IGZvciBhZGRyZXNzIGZhbWlsaWVzDQo+Pj4gb3RoZXIgdGhhbiBJUHY0LzYuDQo+
PiANCj4+IEhhdmUgdGhhdCBjb3ZlcmVkLg0KPj4gDQo+Pj4gVGhlIFJMT0NzIGluIHRoZSBNYXAt
UmVwbHkgYXJlIGdsb2JhbGx5IHJvdXRhYmxlIElQIGFkZHJlc3NlcyBvZiBhbGwNCj4+PiBFVFJz
IGZvciB0aGUgTElTUCBzaXRlLg0KPj4+IA0KPj4+ICAg4oCiIFtBUl0gV2Ugc2hvdWxkIHJlbW92
ZSAiZ2xvYmFsbHkiIGhlcmUuIE1heWJlIGFsc28gYWRkIGENCj4+PiAiR2VuZXJhbGx5IiBhdCB0
aGUgYmVnaW5uaW5nIHNpbmNlIHdlIG1pZ2h0IGhhdmUgTENBRnMgd2l0aCBBRkkgPSAwDQo+Pj4g
KExJU1AtVlBOIGVuY29kaW5nIG9mIEhvbWUtSUlEIGZvciBpbnN0YW5jZSkuDQo+PiANCj4+IFJl
bW92ZWQg4oCcZ2xvYmFsbHnigJ0uIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHlvdXIgb3RoZXIg4oCc
R2VuZXJhbGx54oCdIGNvbW1lbnQuDQo+PiANCj4+PiBGb3IgZXhhbXBsZSwgYSByZXF1ZXN0ZXIg
d2l0aCB0d28gY2FjaGVkIEVJRC1QcmVmaXhlcyB0aGF0IGFyZSBjb3ZlcmVkDQo+Pj4gYnkgYSBN
YXAtUmVwbHkgY29udGFpbmluZyBvbmUgbGVzcy1zcGVjaWZpYyBwcmVmaXggcmVwbGFjZXMgdGhl
IGVudHJ5DQo+Pj4gd2l0aCB0aGUgbGVzcy1zcGVjaWZpYyBFSUQtUHJlZml4Lg0KPj4+IA0KPj4+
ICAg4oCiIFtBUl0gTm90IHN1cmUgaWYgSSBmb2xsb3cgaGVyZS4gRG9lcyB0aGlzIG1lYW4gdGhh
dCBhDQo+Pj4gbGVzcy1zcGVjaWZpYyByZWNlaXZlZCBpbiBhIE1hcC1SZXBseSB3aWxsIGVyYXNl
IGZyb20gdGhlIG1hcC1jYWNoZQ0KPj4+IHByZXZpb3VzbHkgY2FjaGVkIG1vcmUtc3BlY2lmaWNz
IHRoYXQgYXJlIGNvdmVyZWQgYnkgdGhlDQo+Pj4gbGVzcy1zcGVjaWZpYz8NCj4+IA0KPj4gWWVz
LCBiZWNhdXNlIGlmIHRoZSBNYXAtUmVwbHkgcmV0dXJuZWQgYSBtb3JlLXNwZWNpZmljIHdpdGgg
dGhlIGxlc3Mtc3BlY2lmaWMsIHRoZW4gaXQgd291bGQgYmUgcmVwbGFjZWQgc28gdGhlIGxlc3Mt
c3BlY2lmaWMgcmVwbGFjZXMgdGhlIG1vcmUtc3BlY2lmaWNzIHRoYXQgQVJFIE5PVCBpbiB0aGUg
TWFwLVJlcGx5Lg0KPj4gDQo+Pj4gV2hlbiBtb3JlIHRoYW4gb25lIEVJRC1QcmVmaXggaXMgcmV0
dXJuZWQsIGFsbCBTSE9VTEQgdXNlIHRoZSBzYW1lDQo+Pj4gVGltZSB0byBMaXZlIHZhbHVlIHNv
IHRoZXkgY2FuIGFsbCB0aW1lIG91dCBhdCB0aGUgc2FtZSB0aW1lLiAgV2hlbiBhDQo+Pj4gbW9y
ZS1zcGVjaWZpYyBFSUQtUHJlZml4IGlzIHJlY2VpdmVkIGxhdGVyLCBpdHMgVGltZSB0byBMaXZl
IHZhbHVlIGluDQo+Pj4gdGhlIE1hcC1SZXBseSByZWNvcmQgY2FuIGJlIHN0b3JlZCBldmVuIHdo
ZW4gb3RoZXIgbGVzcy1zcGVjaWZpYw0KPj4+IGVudHJpZXMgZXhpc3QuDQo+Pj4gDQo+Pj4gICDi
gKIgW0FSXSBXZSBzaG91bGQgZXhwbGFpbiBpbiB3aGljaCBjYXNlcyBhIG1vcmUtc3BlY2lmaWMg
Y2FuIGJlDQo+Pj4gcmVjZWl2ZWQgbGF0ZXIuDQo+PiANCj4+IEkgZG9u4oCZdCBmb2xsb3cuIEVh
Y2ggRUlELXJlY29yZCB3aWxsIGNvbnRhaW4gYSBUVEwgZm9yIHRoZSBsZW5ndGggcHJlZml4IHRo
YXQgaXMgZW5jb2RlZC4gU28gdGhlIG5ldyBNYXAtUmVwbHkgVFRMIHdpbGwgYmUgdXNlZCBmb3Ig
YW55IGxlbmd0aCBlbnRyeSAoYW5kIGluIHRoaXMgY2FzZSB0aGUgbW9yZS1zcGVjaWZpYykuDQo+
PiANCj4+PiBUaGUgTG9jYXRvci1TZXQgTVVTVCBiZSBzb3J0ZWQgaW4gb3JkZXIgb2YgYXNjZW5k
aW5nIElQIGFkZHJlc3Mgd2hlcmUNCj4+PiBhbiBJUHY0IGxvY2F0b3IgYWRkcmVzcyBpcyBjb25z
aWRlcmVkIG51bWVyaWNhbGx5ICdsZXNzIHRoYW4nIGFuIElQdjYNCj4+PiBsb2NhdG9yIGFkZHJl
c3MuDQo+Pj4gDQo+Pj4gICDigKIgW0FSXSBMQ0FGIGFkZHJlc3NlcyAobWF5YmUgd2l0aCBBRkk9
MCkgc2hvdWxkIGJlIGRpc2N1c3NlZCBoZXJlIGFzIHdlbGwuDQo+PiANCj4+IEl0IGlzIGRpc2N1
c3NlZCBpbiB0aGUgTENBRiBkcmFmdC4gRG9u4oCZdCB3YW50IHRvIHJlcGVhdCBpdC4NCj4+IA0K
Pj4+IE5vbmNlOiAgVGhpcyA4LW9jdGV0ICdOb25jZScgZmllbGQgaXMgc2V0IHRvIDAgaW4gTWFw
LVJlZ2lzdGVyIG1lc3NhZ2VzLg0KPj4+IA0KPj4+ICAg4oCiIFtBUl0gU2luY2UgdGhlcmUgbWF5
IGJlIGZ1dHVyZSBjYXNlcyB0aGF0IGJlbmVmaXQgZnJvbSBoYXZpbmcgYQ0KPj4+IG5vbi16ZXJv
IG5vbmNlIG9uIHRoZSBNYXAtUmVnaXN0ZXIsIEkgd291bGQgc3VnZ2VzdCB0byByZXBocmFzZSB0
aGlzDQo+Pj4gc2VudGVuY2UgdG8gYWRkIGEgQ0FOLg0KPj4gDQo+PiBOb3QgdW50aWwgd2UgaWRl
bnRpZnkgYW5kIGRlc2NyaWJlIHRoZSB1c2UtY2FzZS4gTm8gcG9pbnQgdG8gc3BlY3VsYXRlLiBC
dXQgbm90ZSwgaWYgYSBNYXAtTm90aWZ5IGlzIHJldHVybmVkLCB0aGUgbm9uY2Ugc2hvdWxkIGJl
IG5vbi16ZXJvLiBJ4oCZbGwgZml4IHRoYXQuDQo+PiANCj4+PiBFOiAgVGhpcyBpcyB0aGUgdG8t
RVRSIGJpdC4gIFdoZW4gc2V0IHRvIDEsIHRoZSBNYXAtU2VydmVyJ3MgaW50ZW50aW9uDQo+Pj4g
aXMgdG8gZm9yd2FyZCB0aGUgRUNNIHRvIGFuIGF1dGhvcml0YXRpdmUgRVRSLg0KPj4+IA0KPj4+
ICAg4oCiIFtBUl0gQ2FuIE0gYW5kIEUgYmUgc2V0IGF0IHRoZSBzYW1lIHRpbWU/DQo+PiANCj4+
IEl0IGNhbi4gTSBiaXQgaXMgc2V0IHRvIGluZGljYXRlIHRvIGF2b2lkIEREVCBwcm9jZWR1cmVz
LiBUaGUgRSBiaXQgdGVsbHMgdGhlIE1hcC1TZXJ2ZXIgd2hhdCB0byBkbyB3aXRoIHRoZSBNYXAt
UmVxdWVzdC4NCj4+IA0KPj4+IExDTTogIFRoZSBmb3JtYXQgaXMgb25lIG9mIHRoZSBjb250cm9s
IG1lc3NhZ2UgZm9ybWF0cyBkZXNjcmliZWQgaW4NCj4+PiB0aGlzIHNlY3Rpb24uICBBdCB0aGlz
IHRpbWUsIG9ubHkgTWFwLVJlcXVlc3QgbWVzc2FnZXMgYXJlIGFsbG93ZWQgdG8NCj4+PiBiZSBl
bmNhcHN1bGF0ZWQuDQo+Pj4gDQo+Pj4gICDigKIgW0FSXSBTaGFsbCB3ZSBtZW50aW9uIHRoZSBO
QVQgdHJhdmVyc2FsIGRyYWZ0Pw0KPj4gDQo+PiBObywgdGhpcyBpcyBhbiBFQ00sIG5vdCBhIGRh
dGEtZW5jYXBzdWxhdGVkIGNvbnRyb2wtbWVzc2FnZS4NCj4+IA0KPj4+IEEgTWFwLVNlcnZlcidz
IGNvbmZpZ3VyYXRpb24gbXVzdCBhbHNvIGluY2x1ZGUgYSBsaXN0IG9mIHRoZQ0KPj4+IEVJRC1Q
cmVmaXhlcyBmb3Igd2hpY2ggZWFjaCBFVFIgaXMgYXV0aG9yaXRhdGl2ZS4NCj4+PiANCj4+PiAg
IOKAoiBbQVJdIFRoZXJlIG1heSBiZSBjZXJ0YWluIGNhc2VzIHdoZXJlIHRoaXMgZG9lcyBub3Qg
bmVlZCB0byBiZQ0KPj4+IHByZS1jb25maWd1cmVkLiBJIHN1Z2dlc3Qgd2UgcmVwbGFjZSB0aGUg
Im11c3QiIHdpdGggYSAic2hvdWxkIi4gTm90ZQ0KPj4+IHRoYXQgdGhpcyByZXF1aXJlbWVudCBp
cyBhbHJlYWR5IGEgInNob3VsZCIgaW4gc2VjdGlvbiA2Lg0KPj4gDQo+PiBBZ3JlZS4NCj4+IA0K
Pj4+IFNlZSBbSS1ELmlldGYtbGlzcC1yZmM2ODMwYmlzXSBmb3IgZGV0YWlscyBvbiBob3cgdGhl
IE1hcC1TZXJ2ZXIgc2V0cw0KPj4+IGNlcnRhaW4gZmxhZ3MgKHN1Y2ggYXMgdGhvc2UgaW5kaWNh
dGluZyB3aGV0aGVyIHRoZSBtZXNzYWdlIGlzDQo+Pj4gYXV0aG9yaXRhdGl2ZSBhbmQgaG93IHJl
dHVybmVkIExvY2F0b3JzIHNob3VsZCBiZSB0cmVhdGVkKSB3aGVuDQo+Pj4gc2VuZGluZyBhIE1h
cC1SZXBseSBvbiBiZWhhbGYgb2YgYW4gRVRSLg0KPj4+IA0KPj4+ICAg4oCiIFtBUl0gSXQgbWF5
IGJlIHVzZWZ1bCB0byBkaXNjdXNzIGF0IGxlYXN0IHNvbWUgb2YgdGhvc2UgZGV0YWlscyBoZXJl
Lg0KPj4gDQo+PiBJdCBkb2VzIGZvbGxvd2luZyB0aGlzLg0KPj4gDQo+PiBJIGFsc28gbWFkZSB0
aGUgZG9jdW1lbnQgUkZDMjExOSBjb21wbGlhbnQgd2hlcmUgdGhlIHRlcm1zIGZvciBub3QgY2Fw
aXRhbGl6ZWQuIFRoZXJlIHdlcmUgYSBmZXcgcGxhY2VzLg0KPj4gDQo+PiBUaGFua3MgYWdhaW4s
DQo+PiBEaW5vDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+IA0KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBsaXNwIG1haWxpbmcgbGlz
dA0KPiBsaXNwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbGlzcA0KDQo=


From nobody Wed Nov 29 13:36:23 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A6B126CD6 for ; Wed, 29 Nov 2017 13:36:22 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 YCeSssorrSyn for ; Wed, 29 Nov 2017 13:36:18 -0800 (PST)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 59875124239 for ; Wed, 29 Nov 2017 13:36:18 -0800 (PST)
Received: by mail-pf0-x22c.google.com with SMTP id a90so2160552pfk.1 for ; Wed, 29 Nov 2017 13:36:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=81DcdDn4c7wHosFFvt5uxUfy94f8F1JwB6vAIvVUcWo=; b=DYHeiBhTHjKTggm7WDkYfzA/F1Izh3YDB8kWim7gVeuLFtXyJr3M4bZjzuf8upx95T c4uzji0vbMsJ1qkLb9I4YfRNGFRVIoMgV4TyW8GYy8EEYSni/i5cwdnBNlUpiU2veQqG wujS2v9fsKERCejKpJ6mpJqJHf1fAbyUnsqtcE0jxNcRn3zm6HBbD+o9k1lu2Kr1rLro zCFZZwO/2wAFtlD/KMbQjOxlgqUtKzlGhtSQoOK20An0D3CJx3QbFVHMmw36cAjlLURX 455SCmZjlA4TaAsSCI4rEssOYvKhcy45YIz0RGZGBNTe9sduOl0OIrOtClxnfP2LxpHb xGUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=81DcdDn4c7wHosFFvt5uxUfy94f8F1JwB6vAIvVUcWo=; b=Y9scSGJUBZBTAeGoHXVLK+0/abofjeKTKTBomQ/2CJw/Z/pjc2HKdT47PbhzR4C1z3 L4n2WgbBOWbh7kGmiIhoyGBdOgYTP2SpyW5OnyzlMjJavq6J6XJsNRLDXLMG3WvYVSn7 ng2o04lRVo9/AB79kUeKAKuBZsq1ivcZTwhQ/+iTvR9mm40iU4rjnjLgGLzQdIgG8+Ba tzp3Eu6Y/csZ8/K4dSSQk2qUMzpNQzmzYkeg+9C4u98LFOExilvB2m4TJ4sJntCaFqNO 1GDIyNkW0XkbfZ++0jRBVttLRd2UFgOKA2Jp/XypUJriEukDwalwV+Hxil3gwcl+na6O jhZg==
X-Gm-Message-State: AJaThX670W3bY1NLXPqlbnIiVPRKF3ma376sI7+4/QoIX7+QsIwm1Mhn ZGHXy5hRGJlFJc+gtDIyh8s=
X-Google-Smtp-Source: AGs4zMaSLY3Jioun1w2rYxVhVyETi9nrAd+qI5yoZzlaV2+L1X4Wu9yAoyHFmKJnvNCyblFvv1ke8Q==
X-Received: by 10.101.78.2 with SMTP id r2mr285083pgt.320.1511991377315; Wed, 29 Nov 2017 13:36:17 -0800 (PST)
Received: from dino-macbook.lan (c-67-180-23-75.hsd1.ca.comcast.net. [67.180.23.75]) by smtp.gmail.com with ESMTPSA id d6sm4791032pfc.29.2017.11.29.13.36.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 13:36:16 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Dino Farinacci 
In-Reply-To: <53F582DF-33D8-41BF-94F4-CCE65D6C7908@cisco.com>
Date: Wed, 29 Nov 2017 13:36:15 -0800
Cc: "lisp@ietf.org list" , Alberto Rodriguez-Natal , Dino Farinacci 
Content-Transfer-Encoding: quoted-printable
Message-Id: <36D472D5-8E64-4CB7-A98F-60C850724974@gmail.com>
References:  <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com>  <53F582DF-33D8-41BF-94F4-CCE65D6C7908@cisco.com>
To: Victor Moreno 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [lisp] Review of RFC6833bis
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 21:36:22 -0000

> On Nov 29, 2017, at 11:09 AM, Victor Moreno (vimoreno) =
 wrote:
>=20
> In addition to the comments provided by Alberto and Dino, I have some =
comments on the text in section 5 of the RFC.=20
>=20
> 1. The text in section 5 currently prescribes that in response to a =
map-request for a non-registered or non-existent EID, an ITR should =
expect an NMR from the Map-Server (or Resolver) with action code =
=E2=80=9CNatively-Forward=E2=80=9D (this is stated in section 5.1 and =
re-stated in 5.3 and 5.4). Prescribing that this is to always be an NMR =
with a Native-Forward action is limiting.=20

I can go along with this Victor. I would like to hear what the working =
group says about this. See technical details below.

I have also asked myself the question many times if we need or should =
distinguish between not-registered or not-assigned. We did this in DDT =
with Map-Referrals but not in negative Map-Replies.

The problem with =E2=80=9Cnot-assigned=E2=80=9D is that a big EID-prefix =
block may be configured in a map-server with =E2=80=9Caccept-more-specific=
s=E2=80=9D semantics. Which means you don=E2=80=99t know if the more =
specifics are assigned or not. So what would always be returned is a =
=E2=80=9Cnot-registered=E2=80=9D action.

So I think we could introduce this, I think in practice it could never =
be used. And as you say a negative prefix that is built for a hole that =
needs to point to a PETR, is that a EID-prefix or not? So it would be =
hard to distinguish between not-assigned here versus not-registered =
unless the EID-record had a flag that said what is being registered.

> After trying to address a few use cases, it would be very useful if =
the specification allowed:
>=20
> a. As an alternative to responding with an NMR, an implementation may =
respond to a Map-Request for a non-registered or non-existent EID with a =
=E2=80=9Cpositive" map-reply inclusive of an RLOC-set that can be =
configured in the Mapping-System. The immediate use case this would =
address is that of not having to configure a PETR statically at every =
ITR, but have the map-replies include the PETR's RLOC information. This =
Map-Reply should have short TTLs and include covering/hole EID prefixes =
just as specified for the current NMRs, hence this differs from a =
map-reply for registered 0/0 EIDs.

Why configure a map-server with something it may not have control over. =
An mapping system provider may not be associaed with data-plane =
provider, so it unilaterally (or even if agreed upon) should register =
*to itself*. There is no reason why the data-plane provider register any =
length EID-prefix with any RLOC-set it determines. Then a LISP site just =
encapsulates.=20

The architecture already supports this.

> b. The use of all action codes possible with the ACT bits (as defined =
in section 4.4) when Map-Replying with an NMR to a Map-Request for a =
non-registered or non-existent EID. As I read the text in section 5, it =
isn=E2=80=99t clear that other action codes are allowed, the text is =
focused solely on Natively-Forward, there are strong requirements to =
leverage the Drop action and particularly Drop/Policy-Denied.

As well as Auth-Failure. I can make this more clear in the section =
describing the ACT bits.

> 2. There are multiple references to LISP-ALT in the text. Do we want =
to keep those references moving forward? Or can these be removed? The =
implementations I work with do not use ALT, but maybe there are others =
that do?

Since LISP-ALT and LISP-DDT are the only RFC=E2=80=99ed mapping database =
transport systems, we should include both IMO. What do you think? We =
have done this for other areas as well.

> 3. Section 5.3. Paragraph 2 is describing the behavior for the MS when =
there is a match on an EID =E2=80=9Chole=E2=80=9D. Section 5.3. suggests =
a 15 minute TTL, meanwhile section 5.1. suggests a 1 minute TTL for the =
same EID. I think it should be 1 minute in both cases.=20

Will fix.

> I can contribute with text suggestions once we discuss the above on =
the list.=20

Thanks for that. If you want to take a crack at (b) above that would be =
great.

Dino

>=20
> -v
>=20
>=20
>> On Nov 29, 2017, at 10:04 AM, Alberto Rodriguez-Natal =
 wrote:
>>=20
>> Thanks for the responses Dino. I'll get back to you later this week.
>>=20
>> Alberto
>>=20
>> On Tue, Nov 28, 2017 at 5:12 PM, Dino Farinacci  =
wrote:
>>>> Hi all,
>>>>=20
>>>> Wanted to send this before the meeting on Friday. I just completed =
a
>>>> review of 6833bis, you can find my comments below. Like last time,
>>>> extracts from the draft are copied and followed by my comments.
>>>>=20
>>>> Thanks,
>>>> Alberto
>>>=20
>>> Thanks again Alberto for your comments. See my responses inline and =
a -07 diff file.
>>>=20
>>>> Map-Resolver:  A network infrastructure component that accepts LISP
>>>> Encapsulated Map-Requests,
>>>>=20
>>>>  =E2=80=A2 [AR] We could remove "Encapsulated" and just use =
"Map-Requests".
>>>> A Map-Resolver may accept non-encapsulated Map-Requests as well.
>>>=20
>>> No, they are =E2=80=9Ccontrol-plane=E2=80=9D encapsulated. I=E2=80=99l=
l make that more clear.
>>>=20
>>>> Map-Register message:   A LISP message sent by an ETR to a =
Map-Server
>>>> to register its associated EID-Prefixes.  In addition to the set of
>>>> EID-Prefixes to register, the message includes one or more RLOCs to =
be
>>>> used by the Map-Server when forwarding Map-Requests (re-formatted =
as
>>>> Encapsulated Map-Requests) received through the database mapping
>>>> system.
>>>>=20
>>>>  =E2=80=A2 [AR] This may give the impression that the RLOCs on the
>>>> Map-Register are only to forward Map-Requests, which is not the =
case
>>>> in proxy-reply mode. I would suggest we rephrase this text as =
follows:
>>>> "In addition to the set of EID-Prefixes to register, the message
>>>> includes one or more RLOCs to be used to reach the ETR. The =
Map-Server
>>>> uses these RLOCs when it has to forward Map-Requests (potentially
>>>> re-formatted as Encapsulated Map-Requests) received through the
>>>> database mapping system.=E2=80=9D
>>>=20
>>> I reworded.
>>>=20
>>>> Map-Notify message:   A LISP message sent by a Map-Server to an ETR
>>>>=20
>>>>  =E2=80=A2 [AR] I would replace "ETR" with "xTR" so we cover the =
PubSub
>>>> behavior as well.
>>>=20
>>> Can=E2=80=99t do that because an ITR does not get Map-Notifies as a =
response to a Map-Register. But I will add that ITRs get Map-Notifies to =
inform them of RLOC-set changes (for pubsub and signal-free-multicast =
use-cases).
>>>=20
>>>>=20
>>>> For definitions of other terms -- notably Map-Request, Map-Reply,
>>>> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- =
please
>>>> consult the LISP specification [I-D.ietf-lisp-rfc6830bis].
>>>>=20
>>>>  =E2=80=A2 [AR] I think that the definitions for Map-Request and =
Map-Reply
>>>> should be moved here, and probably we should include the definition
>>>> for Map-Notify-Ack as well. 6830bis should reference 6833bis for
>>>> control-plane messages, not the other way around.
>>>=20
>>> They did. But the text you identified above was not changed. Changed =
now.
>>>=20
>>>> A Map-Register message contains a list of EID-Prefixes plus a set =
of
>>>> RLOCs that can be used to reach the ETR when a Map-Server needs to
>>>> forward a Map-Request to it.
>>>>=20
>>>>  =E2=80=A2 [AR] Since proxy-reply is a common case, I'd not =
constrain the
>>>> meaning of the RLOCs in the Map-Register. I'd remove the last part =
of
>>>> the sentence that says "when a Map-Server needs to forward a
>>>> Map-Request to it.=E2=80=9D
>>>=20
>>> Agree.
>>>=20
>>>> A Map-Resolver receives Encapsulated Map-Requests from its client =
ITRs
>>>> and uses a mapping database system to find the appropriate ETR to
>>>> answer those requests.
>>>>=20
>>>>  =E2=80=A2 [AR] A MR can receive Map-Requests that don't come from =
ITR
>>>> and/or that are not encapsulated. If we don't want to change the =
text,
>>>> at least I'd add at the beginning: "In a common scenario, a
>>>> Map-Resolver=E2=80=A6"
>>>=20
>>> I don=E2=80=99t think we should change this. The lig document =
indicates that a lig client can send Map-Requests. This document is for =
support of a data-plane.
>>>=20
>>>> Note that while it is conceivable that a non-LISP-DDT Map-Resolver
>>>> could cache responses to improve performance,
>>>>=20
>>>>  =E2=80=A2 [AR] The discussion on caching or not at the =
Map-Resolver goes
>>>> beyond DDT. We could rephrase this removing the mention to
>>>> "non-LISP-DDT=E2=80=9D.
>>>=20
>>> Agree. Changed.
>>>=20
>>>> The LISP UDP-based messages are the Map-Request and Map-Reply
>>>> messages.  When a UDP Map-Request is sent, the UDP source port is
>>>> chosen by the sender and the destination UDP port number is set to
>>>> 4342.  When a UDP Map-Reply is sent, the source UDP port number is =
set
>>>> to 4342 and the destination UDP port number is copied from the =
source
>>>> port of either the Map-Request or the invoking data packet.
>>>>=20
>>>>  =E2=80=A2 [AR] I would remove the first sentence and re-phrase =
this
>>>> paragraph as follows: "When a UDP LISP control message is sent and =
is
>>>> not a direct reply to a previous control message, the UDP source =
port
>>>> is chosen by the sender and the destination UDP port number is set =
to
>>>> 4342.  When a UDP LISP control message is sent as a direct reply to =
a
>>>> previous message, the source UDP port number is set to 4342 and the
>>>> destination UDP port number is either set to 4342 or copied from =
the
>>>> source port of the invoking LISP control message. See the following
>>>> subsections for details.=E2=80=9D
>>>=20
>>> This is not really true. There are too many cases with respect to =
NAT-traversal that make things more complicated. I think we need to be =
specific about each message and not generalize it. Plus, Map-Notify =
messages are response and unsolicited so they vary on whether the =
destination or source port is 4342.
>>>=20
>>> I have added text to identify each message that follow the =
Map-Request and Map-Reply port rules.
>>>=20
>>>> The UDP checksum is computed and set to non-zero for Map-Request,
>>>> Map-Reply, Map-Register, and Encapsulated Control Message (ECM)
>>>> control messages.
>>>>=20
>>>>  =E2=80=A2 [AR] Shouldn't it be computed for all LISP control =
messages?
>>>=20
>>> Yes. Added text.
>>>=20
>>>> EID-Prefix:  This prefix is 4 octets for an IPv4 address family and =
16
>>>> octets for an IPv6 address family.  When a Map-Request is sent by =
an
>>>> ITR because a data packet is received for a destination where there =
is
>>>> no mapping entry, the EID-Prefix is set to the destination IP =
address
>>>> of the data packet, and the 'EID mask-len' is set to 32 or 128 for
>>>> IPv4 or IPv6, respectively.
>>>>=20
>>>>  =E2=80=A2 [AR] We should probably rephrase this to don't limit it =
to IPv4/6
>>>=20
>>> Good point. Generalized the text a bit.
>>>=20
>>>> For the latter two cases, the destination IP address used for the
>>>> Map-Request is one of the RLOC addresses from the Locator-Set of =
the
>>>> Map-Cache entry.
>>>>=20
>>>>  =E2=80=A2 [AR] To refresh map-caches before TTL expiration, the
>>>> destination IP of the Map-Request can be the address of the =
Map-Server
>>>> if in proxy-reply. This should be considered here.
>>>=20
>>> This is not true. The Map-Request has an IP header but it is =
encapsulated in an ECM and that IP header destination address is the =
*Map-Resolvers*.
>>>=20
>>>> If the ITR erroneously provides no ITR-RLOC addresses, the =
Map-Replier
>>>> MUST drop the Map-Request.
>>>>=20
>>>>  =E2=80=A2 [AR] This could probably be a SHOULD since we use AFI =3D =
0 as
>>>> ITR-RLOC to unsubscribe in PubSub.
>>>=20
>>> An AFI=3D0 Is an RLOC address.
>>>=20
>>>> EID-Prefix:  This prefix is 4 octets for an IPv4 address family and =
16
>>>> octets for an IPv6 address family.
>>>>=20
>>>>  =E2=80=A2 [AR] We should mention the possibility for address =
families
>>>> other than IPv4/6.
>>>=20
>>> Have that covered.
>>>=20
>>>> The RLOCs in the Map-Reply are globally routable IP addresses of =
all
>>>> ETRs for the LISP site.
>>>>=20
>>>>  =E2=80=A2 [AR] We should remove "globally" here. Maybe also add a
>>>> "Generally" at the beginning since we might have LCAFs with AFI =3D =
0
>>>> (LISP-VPN encoding of Home-IID for instance).
>>>=20
>>> Removed =E2=80=9Cglobally=E2=80=9D. I don=E2=80=99t understand your =
other =E2=80=9CGenerally=E2=80=9D comment.
>>>=20
>>>> For example, a requester with two cached EID-Prefixes that are =
covered
>>>> by a Map-Reply containing one less-specific prefix replaces the =
entry
>>>> with the less-specific EID-Prefix.
>>>>=20
>>>>  =E2=80=A2 [AR] Not sure if I follow here. Does this mean that a
>>>> less-specific received in a Map-Reply will erase from the map-cache
>>>> previously cached more-specifics that are covered by the
>>>> less-specific?
>>>=20
>>> Yes, because if the Map-Reply returned a more-specific with the =
less-specific, then it would be replaced so the less-specific replaces =
the more-specifics that ARE NOT in the Map-Reply.
>>>=20
>>>> When more than one EID-Prefix is returned, all SHOULD use the same
>>>> Time to Live value so they can all time out at the same time.  When =
a
>>>> more-specific EID-Prefix is received later, its Time to Live value =
in
>>>> the Map-Reply record can be stored even when other less-specific
>>>> entries exist.
>>>>=20
>>>>  =E2=80=A2 [AR] We should explain in which cases a more-specific =
can be
>>>> received later.
>>>=20
>>> I don=E2=80=99t follow. Each EID-record will contain a TTL for the =
length prefix that is encoded. So the new Map-Reply TTL will be used for =
any length entry (and in this case the more-specific).
>>>=20
>>>> The Locator-Set MUST be sorted in order of ascending IP address =
where
>>>> an IPv4 locator address is considered numerically 'less than' an =
IPv6
>>>> locator address.
>>>>=20
>>>>  =E2=80=A2 [AR] LCAF addresses (maybe with AFI=3D0) should be =
discussed here as well.
>>>=20
>>> It is discussed in the LCAF draft. Don=E2=80=99t want to repeat it.
>>>=20
>>>> Nonce:  This 8-octet 'Nonce' field is set to 0 in Map-Register =
messages.
>>>>=20
>>>>  =E2=80=A2 [AR] Since there may be future cases that benefit from =
having a
>>>> non-zero nonce on the Map-Register, I would suggest to rephrase =
this
>>>> sentence to add a CAN.
>>>=20
>>> Not until we identify and describe the use-case. No point to =
speculate. But note, if a Map-Notify is returned, the nonce should be =
non-zero. I=E2=80=99ll fix that.
>>>=20
>>>> E:  This is the to-ETR bit.  When set to 1, the Map-Server's =
intention
>>>> is to forward the ECM to an authoritative ETR.
>>>>=20
>>>>  =E2=80=A2 [AR] Can M and E be set at the same time?
>>>=20
>>> It can. M bit is set to indicate to avoid DDT procedures. The E bit =
tells the Map-Server what to do with the Map-Request.
>>>=20
>>>> LCM:  The format is one of the control message formats described in
>>>> this section.  At this time, only Map-Request messages are allowed =
to
>>>> be encapsulated.
>>>>=20
>>>>  =E2=80=A2 [AR] Shall we mention the NAT traversal draft?
>>>=20
>>> No, this is an ECM, not a data-encapsulated control-message.
>>>=20
>>>> A Map-Server's configuration must also include a list of the
>>>> EID-Prefixes for which each ETR is authoritative.
>>>>=20
>>>>  =E2=80=A2 [AR] There may be certain cases where this does not need =
to be
>>>> pre-configured. I suggest we replace the "must" with a "should". =
Note
>>>> that this requirement is already a "should" in section 6.
>>>=20
>>> Agree.
>>>=20
>>>> See [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server =
sets
>>>> certain flags (such as those indicating whether the message is
>>>> authoritative and how returned Locators should be treated) when
>>>> sending a Map-Reply on behalf of an ETR.
>>>>=20
>>>>  =E2=80=A2 [AR] It may be useful to discuss at least some of those =
details here.
>>>=20
>>> It does following this.
>>>=20
>>> I also made the document RFC2119 compliant where the terms for not =
capitalized. There were a few places.
>>>=20
>>> Thanks again,
>>> Dino
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
>=20


From nobody Wed Nov 29 14:32:45 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F571120046 for ; Wed, 29 Nov 2017 14:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 mnPOOrfDI7b0 for ; Wed, 29 Nov 2017 14:32:42 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8BF1201FA for ; Wed, 29 Nov 2017 14:32:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7848; q=dns/txt; s=iport; t=1511994762; x=1513204362; h=to:from:subject:message-id:date:mime-version; bh=uiMb7zlyb8VKpOeYzH5Gg8MsWLxxuoyk+2rpoZ/qi6w=; b=L5FcBfX5J1sOnNgPygz7dRLXB0T/fjZKII1xhs9GyjVwOU18pfWPokv0 L+4ZCL7JvpoFrp4k1ePJVHmQ/reUSRuRGOz3QRXdKtEZcsFvc4+gacton L0iapb8DLGux0qJSaHGD9J1dDhP0kdbYdNKIj3kVsGu9yAnQSRpl3LS7K 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJGgBdNB9a/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm6EJpkRgU4JkVCFSoIRCiOBOQGIdUEWAQEBAQEBAQEBax0?= =?us-ascii?q?LhUlvRAJfDQgBAYoeEIlhnWyCJyaKQAEBAQEGAQEBAQEeBYNBggmBVoFpKQuEQ?= =?us-ascii?q?IMwgzyCYwWTDY9Ah3SNGoIWiXKHSYo5gkCJSYE6JgQugVEyGggbFYJkgl2CGCC?= =?us-ascii?q?HZoJHAQEB?=
X-IronPort-AV: E=Sophos; i="5.45,339,1508803200"; d="scan'208,217"; a="38260389"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2017 22:32:41 +0000
Received: from [10.24.21.142] ([10.24.21.142]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vATMWelH007930 for ; Wed, 29 Nov 2017 22:32:41 GMT
To: "lisp@ietf.org" 
From: Fabio Maino 
Message-ID: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>
Date: Wed, 29 Nov 2017 14:32:40 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------3B40B72BD350C40739564A02"
Content-Language: en-US
Archived-At: 
Subject: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 22:32:45 -0000

This is a multi-part message in MIME format.
--------------3B40B72BD350C40739564A02
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I would like to suggest a way to address mutiprotocol support in 
RFC6830bis, that may address what was discussed in Singapore.

This is based on using the last reserved bit in the LISP header as P bit 
to indicate support for multiprotocol encapsulation, as specified in the 
LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).

The header, as specified in section 5.1, would look like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L|N|L|E|V|I|P|K|K|Nonce/Map-Version/Next-Protocol|
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / |Instance ID/Locator-Status-Bits|
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


and the text in section 5.3 that reserves the 6th bit would be replaced by:

P: The P-bit is the Next Protocol bit. When this bit is set to
1, the V-bit MUST be set to 0 and the Nonce length, when used, is
       limited to 16 bits. Refer to[draft-lewis-lisp-gpe] for more details.
       The P-bit is set to 1to indicate the presence of the 8 bit Next
       Protocol field encoded as:

x x x 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K|         Nonce | Next-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Instance ID/Locator-Status-Bits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the allocations 
of the KK bits according to RFC8061 and Nonce. One of the K bits was 
used by LISP-GPE to indicate OAM packets, but that same functionality 
can be done using the Next-Protocol field.

The use of the P-bit is not compatible with the Map-Versioning feature, 
but an equivalent function can be specified (if needed) with a 
Next-Protocol shim header. I can add text to the LISP-GPE draft to 
reflect that.

This would address the multiprotocol working item included in the 
current charter.

I can very quickly update the LISP-GPE draft to reflect this, but I 
wanted to hear what the group thinks first.

Thanks,
Fabio









--------------3B40B72BD350C40739564A02
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
I would like to suggest a way to address mutiprotocol support in
      RFC6830bis, that may address what was discussed in Singapore. 

    

    
This is based on using the last reserved bit in the LISP header
      as P bit to indicate support for multiprotocol encapsulation, as
      specified in the LISP-GPE draft
      (https://tools.ietf.org/html/draft-lewis-lisp-gpe). 

    

    
The header, as specified in section 5.1, would look like: 

    

    
 

    
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             L   |N|L|E|V|I|P|K|K|           
          Nonce/Map-Version/Next-Protocol    |

             I \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             S / |                 Instance
          ID/Locator-Status-Bits              
          |

             P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        

     

     and the text in section 5.3 that reserves the 6th bit
      would be replaced by: 

     

     
    
   P:
          The P-bit is the Next Protocol bit. When this bit is set to

                1, the V-bit MUST
          be set to 0 and the Nonce length, when used, is 

                limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for
          more details. 

                The P-bit is set to 1 to indicate the presence
          of the 8 bit Next 

                Protocol field encoded as: 

           x x
        x 0 x 1 x x

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            |N|L|E|V|I|P|K|K|           Nonce               | Next-Protocol |

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            |                 Instance
        ID/Locator-Status-Bits              
        |

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        

        

      I will have to refresh the LISP-GPE draft, and reflect
    the allocations of the KK bits according to RFC8061 and Nonce. One
    of the K bits was used by LISP-GPE to indicate OAM packets, but that
    same functionality can be done using the Next-Protocol field. 

    

    The use of the P-bit is not compatible with the Map-Versioning
    feature, but an equivalent function can be specified (if needed)
    with a Next-Protocol shim header. I can add text to the LISP-GPE
    draft to reflect that. 

    

    This would address the multiprotocol working item included in the
    current charter. 

    

    I can very quickly update the LISP-GPE draft to reflect this, but I
    wanted to hear what the group thinks first. 

    

    Thanks,

    Fabio

    

    

    

    

    

    

    

    

    
  


--------------3B40B72BD350C40739564A02--


From nobody Wed Nov 29 14:36:55 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB863126B6D for ; Wed, 29 Nov 2017 14:36:54 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 baOBjLICa__L for ; Wed, 29 Nov 2017 14:36:53 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 E40C6126E01 for ; Wed, 29 Nov 2017 14:36:52 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id u25so2216580pfg.5 for ; Wed, 29 Nov 2017 14:36:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gZeXsxO/+Ivgx9diTwHg5wVr2fQ5eVxeKK/YLqBw3fc=; b=NR90hrRFgnp9gwpKDmpBKuUSAf4odMlc7lBcERDbtqrLuOCK1WlHBUhgzpPyEdg4X4 to5vHIIGLdltUBi69pu1WLuXKw/QbuhILNx+pd3c48faeQXfaQGlFlNnV5+P9Jxx0yOR U715wsiQNyon1RlYU7WQpRokWJBiA/2Iq/u2d3Zh45BQD0GYb9LATkaL1qGw+jjc19Qd Vftb5S3b9Fec5nQEftDJfVGxBTcSXPtkJJrC9W6UDoZ6iLebAdO9clG6fNZnuPkY+EOD FlPXqLBS/oKmdqQ08O45Isy5ROdox6ENCBEL6rRM97logBud08Q9YGxQrffCzBbR2Xcu 9wRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gZeXsxO/+Ivgx9diTwHg5wVr2fQ5eVxeKK/YLqBw3fc=; b=E+qtgh4IczsqppXpMF99wIuFKF/7ns67aLIZNIFSK78y3FYMMxMV4fdJNRLmlXC6IS ZXBP6n4WxWMHrQIq4YOl67wG7IJfDEViSHs4iCEzWZX4caaX1yAd2UkTym3Q8NjifK3q OQ3eReghuupA34Sc2B+DKPWCGWz8DEjs/29eY4GWp2qsJWtUKoI6uaZRRIOB9ggEmIEP ypb90AEWgjB64wbB6+sGScsxXLClR+eyMw9soXhqxZDq3nLARIOwEGHZSamgx4OStPGH uED1T6vJVdVrMTHZy+eX44kACqJETAPAjVGzEnIeT3+mY7yDWZMJAeVMCNPNzCsP7Gnu Zk0g==
X-Gm-Message-State: AJaThX5s0sMPSB4tZA/AWo+mipTJ0dgva536i4VRgeC9sjeZUsU8UBUN FJIoppiNAutZqhL7Grx4CIM=
X-Google-Smtp-Source: AGs4zMY+TyTnQbyENQrTvjQrHJ8rYI5w8NVvHfftHta5d063BG1TdPMmXymO9WbLkkO0+onST2DzOw==
X-Received: by 10.101.100.77 with SMTP id s13mr404813pgv.15.1511995012487; Wed, 29 Nov 2017 14:36:52 -0800 (PST)
Received: from dino-macbook.lan (c-67-180-23-75.hsd1.ca.comcast.net. [67.180.23.75]) by smtp.gmail.com with ESMTPSA id n12sm4541683pfb.5.2017.11.29.14.36.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 14:36:51 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Dino Farinacci 
In-Reply-To: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>
Date: Wed, 29 Nov 2017 14:36:51 -0800
Cc: "lisp@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>
To: Fabio Maino 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 22:36:55 -0000

> The use of the P-bit is not compatible with the Map-Versioning =
feature, but an equivalent function can be specified (if needed) with a =
Next-Protocol shim header. I can add text to the LISP-GPE draft to =
reflect that.=20

Well it could be. Just like you did with the Nonce field. Make the =
Version field the middle 16-bits. So V and P can be set at the same as =
well as N and P.

Dino


From nobody Wed Nov 29 14:38:36 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8FB120721 for ; Wed, 29 Nov 2017 14:38:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 z1UPrMhAOh7k for ; Wed, 29 Nov 2017 14:38:33 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0A01201FA for ; Wed, 29 Nov 2017 14:38:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=514; q=dns/txt; s=iport; t=1511995113; x=1513204713; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=VN188NVK2UFNAOF9CYRoq+bbL3vtQTJQ8zUevRJihNA=; b=kyuft8+GeXaJpK8NFiaeBy1buNj46Nosy0vrZDNAO3C6SqIkfsXdNeM3 Z2WovrQ+u+UlNXJonRwYgjChs6wDVcpklbkf/W3Ile9V1efTX8gTG1Xof ComKSNGXV7q0v180iHkQbCdqMGIL3AOhcPAucEe4VInBUwzGWNFj4wsmv Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAQBENh9a/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8gVSEJpkRgU4vmQUKhTsChRVCFQEBAQEBAQEBAWsohSABBSM?= =?us-ascii?q?VQRALGAICJgICVwYNCAEBih6nVYInimUBAQEBAQEBAQEBAQEBAQEBAQEggQ+CM?= =?us-ascii?q?oIJgVaBaSmDAoFJhmyCYwEEkw2GHYkjlQ6BfYoLh0mWQoE6NSOBUTIaCBsVgmS?= =?us-ascii?q?CUQwQggggii0BAQE?=
X-IronPort-AV: E=Sophos;i="5.45,339,1508803200"; d="scan'208";a="37617901"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2017 22:38:33 +0000
Received: from [10.24.21.142] ([10.24.21.142]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vATMcVak030044; Wed, 29 Nov 2017 22:38:32 GMT
To: Dino Farinacci 
Cc: "lisp@ietf.org" 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> 
From: Fabio Maino 
Message-ID: 
Date: Wed, 29 Nov 2017 14:38:31 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 22:38:35 -0000

On 11/29/17 2:36 PM, Dino Farinacci wrote:
>> The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that.
> Well it could be. Just like you did with the Nonce field. Make the Version field the middle 16-bits. So V and P can be set at the same as well as N and P.
>
> Dino
>
Good point, shortening versions to 8 bits...

Seems fine to me.


Fabio





From nobody Wed Nov 29 14:49:22 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BDF124BE8 for ; Wed, 29 Nov 2017 14:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 N4BERkG3TrmF for ; Wed, 29 Nov 2017 14:49:20 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71BA120721 for ; Wed, 29 Nov 2017 14:49:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4349; q=dns/txt; s=iport; t=1511995759; x=1513205359; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=IkSsfikKjLgzNOkWYJdA/brc1j5kxnudxu8lr0s2nC0=; b=QW+AVM5QwBFSJz8oPwKXSRy/3IHIn4v426Y6f64+8cIrdFPITm5Tvu+/ 3wxPNm/HaRzRuZOebXEDy/4bzpZd0Dow1Y3pRScwgRGFwAIcHrAQZ4+Jg w9UK7Gw8QFd0O8TQ834dHyYVnMiTFb0sfVHcOuQRUikSa1RipmsCYJJqX Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AgCmOB9a/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4ng3+ZEYFOCSaRKoVKghEKGAEKhRgChRVBFgEBAQEBAQE?= =?us-ascii?q?BAWsdC4UgAQEBAwEBIUsbCQIEFCoCAicwBg0GAgEBih4QiVOdbIInJoo/AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDQYIJgVaBaSkLgneBSYMwgzyCYwWTDYYdiSO?= =?us-ascii?q?VDowIh0mWQoE6JgcrgVEyGggbFTqCKYJSDBCCCCA2hzCCRwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.45,339,1508803200";  d="scan'208,217";a="108653707"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2017 22:49:18 +0000
Received: from [10.24.21.142] ([10.24.21.142]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vATMnHbw013598 for ; Wed, 29 Nov 2017 22:49:18 GMT
To: "lisp@ietf.org" 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>  
From: Fabio Maino 
Message-ID: <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com>
Date: Wed, 29 Nov 2017 14:49:17 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------6F63845B6BEC83E96D88FFAE"
Content-Language: en-US
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 22:49:22 -0000

This is a multi-part message in MIME format.
--------------6F63845B6BEC83E96D88FFAE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Definition of the P bit will look like:

P: The P-bit is the Next Protocol bit. When this bit is set to
1, Nonce length, when used, is limited to 16 bits and the lenght
       of the Source and Destination Map-Version fields, when used, is 
limited
       to 8 bits. Refer to[draft-lewis-lisp-gpe] for more details.
       The P-bit is set to 1to indicate the presence of the 8 bit Next 
Protocol field encoded as:



Do you think the overall proposed extension makes sense?

Thanks,
Fabio

On 11/29/17 2:38 PM, Fabio Maino wrote:
> On 11/29/17 2:36 PM, Dino Farinacci wrote:
>>> The use of the P-bit is not compatible with the Map-Versioning 
>>> feature, but an equivalent function can be specified (if needed) 
>>> with a Next-Protocol shim header. I can add text to the LISP-GPE 
>>> draft to reflect that.
>> Well it could be. Just like you did with the Nonce field. Make the 
>> Version field the middle 16-bits. So V and P can be set at the same 
>> as well as N and P.
>>
>> Dino
>>
> Good point, shortening versions to 8 bits...
>
> Seems fine to me.
>
>
> Fabio
>
>
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp



--------------6F63845B6BEC83E96D88FFAE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Definition of the P bit will look like:
      

      

           P: The P-bit is the Next
          Protocol bit. When this bit is set to

                1, Nonce length,
          when used, is limited to 16 bits and the lenght 

                of the Source and Destination Map-Version fields, when
          used, is limited 

                to 8 bits. Refer to
        [draft-lewis-lisp-gpe] for
        more details. 

              The P-bit is set to 1 to
        indicate the presence of the 8 bit Next Protocol field encoded
        as: 

      

      

      

      Do you think the overall proposed extension makes sense? 

      

      Thanks,

      Fabio

      

      On 11/29/17 2:38 PM, Fabio Maino wrote:

    

    
On
      11/29/17 2:36 PM, Dino Farinacci wrote:
      

      

        
The use of the P-bit is not compatible
          with the Map-Versioning feature, but an equivalent function
          can be specified (if needed) with a Next-Protocol shim header.
          I can add text to the LISP-GPE draft to reflect that.
          

        

        Well it could be. Just like you did with the Nonce field. Make
        the Version field the middle 16-bits. So V and P can be set at
        the same as well as N and P.
        

        

        Dino
        

        

      

      Good point, shortening versions to 8 bits...
      

      

      Seems fine to me.
      

      

      

      Fabio
      

      

      

      

      

      _______________________________________________
      

      lisp mailing list
      

      lisp@ietf.org
      

      https://www.ietf.org/mailman/listinfo/lisp
      

    

    


    

  


--------------6F63845B6BEC83E96D88FFAE--


From nobody Wed Nov 29 15:05:05 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B412741D for ; Wed, 29 Nov 2017 15:05:04 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 L1A7Smf3hyqj for ; Wed, 29 Nov 2017 15:05:02 -0800 (PST)
Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (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 2DD2A12711A for ; Wed, 29 Nov 2017 15:05:02 -0800 (PST)
Received: by mail-pl0-x22b.google.com with SMTP id bi12so2996255plb.6 for ; Wed, 29 Nov 2017 15:05:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IkloBrTFiUB/5IjlRKjW9ZW4QDo4XyZbjIb37mEvA9Y=; b=Z0p7Ba2b+8CZ5yEGqib7qQbGUd3lTWmOcOilLLZtWe5psHn8ZWu0m1lKgcfsnt2Ajr V2EeOw8tEcDhakGvlTb2MXhJfhWscSYx6UHCCytL3VUSK1wX8c4HQZ4PBeB6OEwcHlvI 7FLcOmCaGq8+eY1N5+EPQfK+UWccjTFE+4gjMnp4Krp+nesonoBS3rvMtUzQBOEnfvxK ywnSiT//TU+0HmL1+ZQiNm3JyMbxFUqFFI1lYi8UgA/znRnOZizY0dM70d4qnJMAZ/t5 qhxGZHcq/0KBuvERjH+tw+3MaRCzWEKm0YMHw7cmh1ylfCoTwPtSkTdyopQlSvSEmyCk y3JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IkloBrTFiUB/5IjlRKjW9ZW4QDo4XyZbjIb37mEvA9Y=; b=MvJJDMilB3jryS6KiQ6lrnz0l7rS5awhSnXweaH2ZUkChp8guUA8ojYWZSNRP0D2CB tn/Ozyi1f/IVhlkR2HklWQzUJ6RkmTTv0OrUUAiSdNjovPdpar8PBo/Uz0K7e3jE4N6p 3DZ/mfbIm407+LZ4QB1Yn1U/zBwH4oB/rq7mKDxvYkB5GveUv8JjNwXLga0ahU18HqVZ 5yWl+c7gHXj1W5X0E0jeFccbun62kEJek2zffJjvl4X1GUI9LXHGcRHEDyAVMcEEt85F uqSU4DBFB8YZ+BbW0IzE281xYy0UBvUOCDG8K+3nsBp3G5MQyWRD2FAkNLLM3rqITW7Y TjZg==
X-Gm-Message-State: AJaThX5veUHmRPwSFT/GjKrM/H+O5lXiBu0Bgj5/9btuB4oAhrRXIunE 5zHThzxdoN9KhCtcz/hxS+c=
X-Google-Smtp-Source: AGs4zMZYZ4lexgG7Wqyr8maCmGp7YwKH7kYV0lb6mAQEyhX60oqQuIsKOaVS9lmeMKHTrRpf8osPqw==
X-Received: by 10.159.252.204 with SMTP id o12mr493589pls.148.1511996701684; Wed, 29 Nov 2017 15:05:01 -0800 (PST)
Received: from dino-macbook.lan (c-67-180-23-75.hsd1.ca.comcast.net. [67.180.23.75]) by smtp.gmail.com with ESMTPSA id m22sm4784229pfg.120.2017.11.29.15.05.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 15:05:01 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Dino Farinacci 
In-Reply-To: <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com>
Date: Wed, 29 Nov 2017 15:05:00 -0800
Cc: "lisp@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com>
To: Fabio Maino 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 23:05:04 -0000

How about this wording Fabio:

P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is =
used for the Next Protocol field. When the N-bit is also set with the =
P-bit, the Nonce field is the middle 16 bits. When the V bit is also set =
with the P-bit, the Version field is the middle 16 bits. Details on Next =
Protocol field usage are described in [draft-lewis-lisp-gpe].

Comments?

Dino

> On Nov 29, 2017, at 2:49 PM, Fabio Maino  wrote:
>=20
> Definition of the P bit will look like:=20
>=20
>    P: The P-bit is the Next Protocol bit. When this bit is set to
>       1, Nonce length, when used, is limited to 16 bits and the lenght=20=

>       of the Source and Destination Map-Version fields, when used, is =
limited=20
>       to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.=20
>       The P-bit is set to 1 to indicate the presence of the 8 bit Next =
Protocol field encoded as:=20
>=20
>=20
>=20
> Do you think the overall proposed extension makes sense?=20
>=20
> Thanks,
> Fabio
>=20
> On 11/29/17 2:38 PM, Fabio Maino wrote:
>> On 11/29/17 2:36 PM, Dino Farinacci wrote:=20
>>>> The use of the P-bit is not compatible with the Map-Versioning =
feature, but an equivalent function can be specified (if needed) with a =
Next-Protocol shim header. I can add text to the LISP-GPE draft to =
reflect that.=20
>>> Well it could be. Just like you did with the Nonce field. Make the =
Version field the middle 16-bits. So V and P can be set at the same as =
well as N and P.=20
>>>=20
>>> Dino=20
>>>=20
>> Good point, shortening versions to 8 bits...=20
>>=20
>> Seems fine to me.=20
>>=20
>>=20
>> Fabio=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________=20
>> lisp mailing list=20
>> lisp@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/lisp=20
>=20
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp


From nobody Wed Nov 29 15:07:52 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A3F1271FD for ; Wed, 29 Nov 2017 15:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 9bvQCkFV84Qg for ; Wed, 29 Nov 2017 15:07:49 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47619120721 for ; Wed, 29 Nov 2017 15:07:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2031; q=dns/txt; s=iport; t=1511996869; x=1513206469; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=eviRexoyxSPOZ2E0YpEGrQZaDFoPE83kPnSC2oTN+s4=; b=Oy7evzEqvw15u2GSRrJKH2bVvaPJeTA2NxorGuw/p3/blfDA6exL9mkH cMc1zlBe3BNWZZRW0GFD7P1QwMUB+s7c7xvG3sXPjJbaN9QcxWHd0bLZt 38oM8xvPiJo/kZ0ON8We2hsSP1rWvPqhSLpEGWynKQ+o+ykFuvR8hisoq I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAQCWPB9a/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4ng3+ZEYFOL5Z0ghEKGAuFGAKFFUAXAQEBAQEBAQEBayi?= =?us-ascii?q?FHwEBAQECAQEBIRU2CxALGAICJgICJzAGDQYCAQGKFggQpzyCJ4pmAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEZBYEPgjKCCYFWgWkpgwKBSYMwgzyCYwWTDYYdiSOLXok?= =?us-ascii?q?wjAiHSZZCgTogATeBUTIaCBsVOoIpglIMEIIIIDaHMIJHAQEB?=
X-IronPort-AV: E=Sophos;i="5.45,339,1508803200"; d="scan'208";a="326602974"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2017 23:07:48 +0000
Received: from [10.24.21.142] ([10.24.21.142]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vATN7lGZ007531; Wed, 29 Nov 2017 23:07:47 GMT
To: Dino Farinacci 
Cc: "lisp@ietf.org" 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>
From: Fabio Maino 
Message-ID: 
Date: Wed, 29 Nov 2017 15:07:46 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 23:07:51 -0000

On 11/29/17 3:05 PM, Dino Farinacci wrote:
> How about this wording Fabio:
>
> P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is used for the Next Protocol field. When the N-bit is also set with the P-bit, the Nonce field is the middle 16 bits. When the V bit is also set with the P-bit, the Version field is the middle 16 bits. Details on Next Protocol field usage are described in [draft-lewis-lisp-gpe].
>
> Comments?

much better.

Thanks,
Fabio

>
> Dino
>
>> On Nov 29, 2017, at 2:49 PM, Fabio Maino  wrote:
>>
>> Definition of the P bit will look like:
>>
>>     P: The P-bit is the Next Protocol bit. When this bit is set to
>>        1, Nonce length, when used, is limited to 16 bits and the lenght
>>        of the Source and Destination Map-Version fields, when used, is limited
>>        to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.
>>        The P-bit is set to 1 to indicate the presence of the 8 bit Next Protocol field encoded as:
>>
>>
>>
>> Do you think the overall proposed extension makes sense?
>>
>> Thanks,
>> Fabio
>>
>> On 11/29/17 2:38 PM, Fabio Maino wrote:
>>> On 11/29/17 2:36 PM, Dino Farinacci wrote:
>>>>> The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that.
>>>> Well it could be. Just like you did with the Nonce field. Make the Version field the middle 16-bits. So V and P can be set at the same as well as N and P.
>>>>
>>>> Dino
>>>>
>>> Good point, shortening versions to 8 bits...
>>>
>>> Seems fine to me.
>>>
>>>
>>> Fabio
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Nov 29 15:14:11 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB0C1289B5 for ; Wed, 29 Nov 2017 15:14:04 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yZZryHFov76b for ; Wed, 29 Nov 2017 15:13:59 -0800 (PST)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 4D0981287A3 for ; Wed, 29 Nov 2017 15:13:59 -0800 (PST)
Received: by mail-pf0-x22c.google.com with SMTP id n6so2258474pfa.4 for ; Wed, 29 Nov 2017 15:13:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1RnVTQyorMxwnsztUEXyk4h5cWR91minw7zZLlhgU8Q=; b=dPyFIt66L3nzS1T6IvFIJg3kvT7Mclhilcojo3+p4udcP8J0WOfydNcn1Sd0useOpw vu/QZ6/dVLUp+bmR62plFMmOUhMB2qpQo40cQ3+kn+adlEQPNPCRmJ+mI8ZvY+ApG1/s OoCT0gBtnC3daCOZ5O3i40fMo6X06hP2RpLEuRcGAGMDjhAupweGtEAsoihCOGogrSoD Rb4zOx2LEUTroPGcYqK7pfgkIPa6LY13HvfL/KTIA4QX3HsKR6hJa4hvRCYw2FAssCX1 grtLAN7ySnpemZkD+XN0KW7YVMMd0aKBz9cZ78HGPCij+ABiluLUidlmjXK7K8LTrnOV FX1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1RnVTQyorMxwnsztUEXyk4h5cWR91minw7zZLlhgU8Q=; b=gxdH6nOtbxAKynVCEJUlr3DO8kcibuxwksip2EU7/ZOZb5jGBXNqrCNWSab98SI4LN 11M1xdhtzs7sfGWMmIu/M3VGf8j534cX/4j5CRsIi+u1kHlz7qgjVekNxqD8KrF4EEtl mNHPluYbuLoOrXyrd9D+PkYsS7YnyRylM0WXJgJ9npbXkU0guR0wTng4RuF/8ShqP/Ls n5sLbrC4zQAtot4GeCSFfsyC7nR1KfNsyybGb3n6e0wzRSpUPogmubyMf0h42EN3BLBc wzefUxhnuJwSR448yUlpvXLCqXZG7F2i3WG9sZgFl6EYB8rNAHALm36/jxO47ILv0s2F U6lw==
X-Gm-Message-State: AJaThX5qrSFD83wQP7F1K4CEVkdjlhj0zDMb+JqwcewP5yFobQkrARr8 7neK91emXuBUEXg5zUjDMCCXJVvc
X-Google-Smtp-Source: AGs4zMa5946PASvcoHzX1n1YrUJiSDwfNr5zsPSnLNBZTyR+5+MTQPbX6x5h76P+eKHK/0t0iaj7hQ==
X-Received: by 10.99.66.68 with SMTP id p65mr482182pga.339.1511997238831; Wed, 29 Nov 2017 15:13:58 -0800 (PST)
Received: from dino-macbook.lan (c-67-180-23-75.hsd1.ca.comcast.net. [67.180.23.75]) by smtp.gmail.com with ESMTPSA id t6sm4576684pfl.76.2017.11.29.15.13.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 15:13:58 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Dino Farinacci 
In-Reply-To: 
Date: Wed, 29 Nov 2017 15:13:57 -0800
Cc: "lisp@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com> 
To: Fabio Maino 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 23:14:05 -0000

I=E2=80=99d also add before the last sentence:

If the N-bit and V-bit are 0 when the P-bit is set, the middle 16-bits =
are set to 0.

Dino

> On Nov 29, 2017, at 3:07 PM, Fabio Maino  wrote:
>=20
> On 11/29/17 3:05 PM, Dino Farinacci wrote:
>> How about this wording Fabio:
>>=20
>> P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits =
is used for the Next Protocol field. When the N-bit is also set with the =
P-bit, the Nonce field is the middle 16 bits. When the V bit is also set =
with the P-bit, the Version field is the middle 16 bits. Details on Next =
Protocol field usage are described in [draft-lewis-lisp-gpe].
>>=20
>> Comments?
>=20
> much better.
>=20
> Thanks,
> Fabio
>=20
>>=20
>> Dino
>>=20
>>> On Nov 29, 2017, at 2:49 PM, Fabio Maino  wrote:
>>>=20
>>> Definition of the P bit will look like:
>>>=20
>>>    P: The P-bit is the Next Protocol bit. When this bit is set to
>>>       1, Nonce length, when used, is limited to 16 bits and the =
lenght
>>>       of the Source and Destination Map-Version fields, when used, =
is limited
>>>       to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.
>>>       The P-bit is set to 1 to indicate the presence of the 8 bit =
Next Protocol field encoded as:
>>>=20
>>>=20
>>>=20
>>> Do you think the overall proposed extension makes sense?
>>>=20
>>> Thanks,
>>> Fabio
>>>=20
>>> On 11/29/17 2:38 PM, Fabio Maino wrote:
>>>> On 11/29/17 2:36 PM, Dino Farinacci wrote:
>>>>>> The use of the P-bit is not compatible with the Map-Versioning =
feature, but an equivalent function can be specified (if needed) with a =
Next-Protocol shim header. I can add text to the LISP-GPE draft to =
reflect that.
>>>>> Well it could be. Just like you did with the Nonce field. Make the =
Version field the middle 16-bits. So V and P can be set at the same as =
well as N and P.
>>>>>=20
>>>>> Dino
>>>>>=20
>>>> Good point, shortening versions to 8 bits...
>>>>=20
>>>> Seems fine to me.
>>>>=20
>>>>=20
>>>> Fabio
>>>>=20
>>>>=20
>>>>=20
>>>>=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
>=20


From nobody Wed Nov 29 16:54:16 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300051286B1 for ; Wed, 29 Nov 2017 16:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 svVDZHQivUHQ for ; Wed, 29 Nov 2017 16:54:11 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C4A124D6C for ; Wed, 29 Nov 2017 16:54:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2437; q=dns/txt; s=iport; t=1512003251; x=1513212851; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Awq3+5CczgAuUPgcMMmIuI+eXYbv3eCI/Im5PaIVocA=; b=F8fuvG9368CCzaJnxatEl/Uc6chbeTCf5kQSMNyIcLhK4eaIX78+gEah PvW3PxUU/gA2fp3hgdf/rpBW3DqWOzhmsqjHO1O6cHgWVOkaOPp1DPhop mCBzFB4qAMshXGlkVQxzuvSZ1Bsvff0RbDo0xRv1wY7nBLidS1suOUlwU I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAQB0Vh9a/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4ng3+ZEYFOL5Z0ghEKGAuFGAKFFUAXAQEBAQEBAQEBayi?= =?us-ascii?q?FIAEBAQMBASEPAQU2CxALGAICJgICJzAGDQYCAQGKHhCnIYInimUBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARkFgQ+CMoIJgVaBaSmDAoFJgzCDPIJjBZMNhh2JI4teiTC?= =?us-ascii?q?MCIdJlkKBOiABN4FRMhoIGxU6gimCUgwQggggNocwgkcBAQE?=
X-IronPort-AV: E=Sophos;i="5.45,339,1508803200"; d="scan'208";a="37642937"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2017 00:53:53 +0000
Received: from [10.24.21.142] ([10.24.21.142]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vAU0rqgL021495; Thu, 30 Nov 2017 00:53:53 GMT
To: Dino Farinacci 
Cc: "lisp@ietf.org" 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>  <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>
From: Fabio Maino 
Message-ID: 
Date: Wed, 29 Nov 2017 16:53:51 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 00:54:13 -0000

sounds good.

Fabio

On 11/29/17 3:13 PM, Dino Farinacci wrote:
> I’d also add before the last sentence:
>
> If the N-bit and V-bit are 0 when the P-bit is set, the middle 16-bits are set to 0.
>
> Dino
>
>> On Nov 29, 2017, at 3:07 PM, Fabio Maino  wrote:
>>
>> On 11/29/17 3:05 PM, Dino Farinacci wrote:
>>> How about this wording Fabio:
>>>
>>> P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is used for the Next Protocol field. When the N-bit is also set with the P-bit, the Nonce field is the middle 16 bits. When the V bit is also set with the P-bit, the Version field is the middle 16 bits. Details on Next Protocol field usage are described in [draft-lewis-lisp-gpe].
>>>
>>> Comments?
>> much better.
>>
>> Thanks,
>> Fabio
>>
>>> Dino
>>>
>>>> On Nov 29, 2017, at 2:49 PM, Fabio Maino  wrote:
>>>>
>>>> Definition of the P bit will look like:
>>>>
>>>>     P: The P-bit is the Next Protocol bit. When this bit is set to
>>>>        1, Nonce length, when used, is limited to 16 bits and the lenght
>>>>        of the Source and Destination Map-Version fields, when used, is limited
>>>>        to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.
>>>>        The P-bit is set to 1 to indicate the presence of the 8 bit Next Protocol field encoded as:
>>>>
>>>>
>>>>
>>>> Do you think the overall proposed extension makes sense?
>>>>
>>>> Thanks,
>>>> Fabio
>>>>
>>>> On 11/29/17 2:38 PM, Fabio Maino wrote:
>>>>> On 11/29/17 2:36 PM, Dino Farinacci wrote:
>>>>>>> The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that.
>>>>>> Well it could be. Just like you did with the Nonce field. Make the Version field the middle 16-bits. So V and P can be set at the same as well as N and P.
>>>>>>
>>>>>> Dino
>>>>>>
>>>>> Good point, shortening versions to 8 bits...
>>>>>
>>>>> Seems fine to me.
>>>>>
>>>>>
>>>>> Fabio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Nov 29 22:20:54 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C53E12025C for ; Wed, 29 Nov 2017 22:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 MXrzZpH439TN for ; Wed, 29 Nov 2017 22:20:51 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FED51200F1 for ; Wed, 29 Nov 2017 22:20:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23487; q=dns/txt; s=iport; t=1512022851; x=1513232451; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=071gFV2SkoC/3lXM9plmQXSLHCBPmR/nvjSE5gMkNL4=; b=eaAWuEu8fjZFtT5n4WgbEm0Wo+h6ZHyuX56NKkEri9AJOW969c7x6gDS /3FwIqv3ncBq/J8Ya/bTwFRSPMuO33FVfdyB4b/4HxLnzq2BgzjTeFXsd LXPjRdeF4IMmgsUe42hVaksEonYXohaMP7P7a+wHQDZGJ/YptYO9Qn0GH 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAACKoh9a/4ENJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4UE4N/iiCOcZhzghEKGAEKhRgCGoR7PxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUgAgEDAQEhSwsQAgEIPwMCAgIlCxQRAgQOBYk+ZBCnCoInimUBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYNBggmBVoFpKYMCgUmDMIM8MYIyBZktiSYCi1yJMgy?= =?us-ascii?q?TRpYVAhEZAYE5AR85gVFvFToqAYF+glIMEIFnd4dAgkcBAQE?=
X-IronPort-AV: E=Sophos; i="5.45,340,1508803200"; d="scan'208,217"; a="37732421"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2017 06:20:50 +0000
Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAU6Knjh025247 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 06:20:50 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 30 Nov 2017 00:20:48 -0600
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.1320.000; Thu, 30 Nov 2017 00:20:48 -0600
From: "Victor Moreno (vimoreno)" 
To: "Fabio Maino (fmaino)" 
CC: Dino Farinacci , "lisp@ietf.org" 
Thread-Topic: [lisp] RFC6830bis and multiprotocol support
Thread-Index: AQHTaWIHscZfF7JJck2FRHekp70Oo6MsVuqAgAAAd4CAAAMCgIAABGQAgAAAxgCAAAG6gIAAG+qA///2xUw=
Date: Thu, 30 Nov 2017 06:20:48 +0000
Message-ID: 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>  <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_E2CCB598341A42ECA2E4DEDEFCA4807Bciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 06:20:53 -0000

--_000_E2CCB598341A42ECA2E4DEDEFCA4807Bciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gc3Ryb25nbHkgc3VwcG9ydGl2ZSBvZiB0aGlzIHByb3Bvc2FsIGFzIGl0IGNvbXBsZXRl
cyB0aGUgbmVjZXNzYXJ5IHNwZWNpZmljYXRpb25zIHRvIHN1cHBvcnQgdGhlIEwyIHNlcnZpY2Vz
IHByb3Bvc2VkIGluIHRoZSBlaWQtbW9iaWxpdHkgZHJhZnQuDQoNClZpY3Rvcg0KDQpPbiBOb3Yg
MjksIDIwMTcsIGF0IDQ6NTQgUE0sIEZhYmlvIE1haW5vIChmbWFpbm8pIDxmbWFpbm9AY2lzY28u
Y29tPG1haWx0bzpmbWFpbm9AY2lzY28uY29tPj4gd3JvdGU6DQoNCnNvdW5kcyBnb29kLg0KDQpG
YWJpbw0KDQpPbiAxMS8yOS8xNyAzOjEzIFBNLCBEaW5vIEZhcmluYWNjaSB3cm90ZToNCknigJlk
IGFsc28gYWRkIGJlZm9yZSB0aGUgbGFzdCBzZW50ZW5jZToNCg0KSWYgdGhlIE4tYml0IGFuZCBW
LWJpdCBhcmUgMCB3aGVuIHRoZSBQLWJpdCBpcyBzZXQsIHRoZSBtaWRkbGUgMTYtYml0cyBhcmUg
c2V0IHRvIDAuDQoNCkRpbm8NCg0KT24gTm92IDI5LCAyMDE3LCBhdCAzOjA3IFBNLCBGYWJpbyBN
YWlubyA8Zm1haW5vQGNpc2NvLmNvbTxtYWlsdG86Zm1haW5vQGNpc2NvLmNvbT4+IHdyb3RlOg0K
DQpPbiAxMS8yOS8xNyAzOjA1IFBNLCBEaW5vIEZhcmluYWNjaSB3cm90ZToNCkhvdyBhYm91dCB0
aGlzIHdvcmRpbmcgRmFiaW86DQoNClA6IFRoZSBQLWJpdCBpcyB0aGUgTmV4dCBQcm90b2NvbCBi
aXQuIFdoZW4gc2V0LCB0aGUgbG93LW9yZGVyIDggYml0cyBpcyB1c2VkIGZvciB0aGUgTmV4dCBQ
cm90b2NvbCBmaWVsZC4gV2hlbiB0aGUgTi1iaXQgaXMgYWxzbyBzZXQgd2l0aCB0aGUgUC1iaXQs
IHRoZSBOb25jZSBmaWVsZCBpcyB0aGUgbWlkZGxlIDE2IGJpdHMuIFdoZW4gdGhlIFYgYml0IGlz
IGFsc28gc2V0IHdpdGggdGhlIFAtYml0LCB0aGUgVmVyc2lvbiBmaWVsZCBpcyB0aGUgbWlkZGxl
IDE2IGJpdHMuIERldGFpbHMgb24gTmV4dCBQcm90b2NvbCBmaWVsZCB1c2FnZSBhcmUgZGVzY3Jp
YmVkIGluIFtkcmFmdC1sZXdpcy1saXNwLWdwZV0uDQoNCkNvbW1lbnRzPw0KbXVjaCBiZXR0ZXIu
DQoNClRoYW5rcywNCkZhYmlvDQoNCkRpbm8NCg0KT24gTm92IDI5LCAyMDE3LCBhdCAyOjQ5IFBN
LCBGYWJpbyBNYWlubyA8Zm1haW5vQGNpc2NvLmNvbTxtYWlsdG86Zm1haW5vQGNpc2NvLmNvbT4+
IHdyb3RlOg0KDQpEZWZpbml0aW9uIG9mIHRoZSBQIGJpdCB3aWxsIGxvb2sgbGlrZToNCg0KICAg
UDogVGhlIFAtYml0IGlzIHRoZSBOZXh0IFByb3RvY29sIGJpdC4gV2hlbiB0aGlzIGJpdCBpcyBz
ZXQgdG8NCiAgICAgIDEsIE5vbmNlIGxlbmd0aCwgd2hlbiB1c2VkLCBpcyBsaW1pdGVkIHRvIDE2
IGJpdHMgYW5kIHRoZSBsZW5naHQNCiAgICAgIG9mIHRoZSBTb3VyY2UgYW5kIERlc3RpbmF0aW9u
IE1hcC1WZXJzaW9uIGZpZWxkcywgd2hlbiB1c2VkLCBpcyBsaW1pdGVkDQogICAgICB0byA4IGJp
dHMuIFJlZmVyIHRvIFtkcmFmdC1sZXdpcy1saXNwLWdwZV0gZm9yIG1vcmUgZGV0YWlscy4NCiAg
ICAgIFRoZSBQLWJpdCBpcyBzZXQgdG8gMSB0byBpbmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgdGhl
IDggYml0IE5leHQgUHJvdG9jb2wgZmllbGQgZW5jb2RlZCBhczoNCg0KDQoNCkRvIHlvdSB0aGlu
ayB0aGUgb3ZlcmFsbCBwcm9wb3NlZCBleHRlbnNpb24gbWFrZXMgc2Vuc2U/DQoNClRoYW5rcywN
CkZhYmlvDQoNCk9uIDExLzI5LzE3IDI6MzggUE0sIEZhYmlvIE1haW5vIHdyb3RlOg0KT24gMTEv
MjkvMTcgMjozNiBQTSwgRGlubyBGYXJpbmFjY2kgd3JvdGU6DQpUaGUgdXNlIG9mIHRoZSBQLWJp
dCBpcyBub3QgY29tcGF0aWJsZSB3aXRoIHRoZSBNYXAtVmVyc2lvbmluZyBmZWF0dXJlLCBidXQg
YW4gZXF1aXZhbGVudCBmdW5jdGlvbiBjYW4gYmUgc3BlY2lmaWVkIChpZiBuZWVkZWQpIHdpdGgg
YSBOZXh0LVByb3RvY29sIHNoaW0gaGVhZGVyLiBJIGNhbiBhZGQgdGV4dCB0byB0aGUgTElTUC1H
UEUgZHJhZnQgdG8gcmVmbGVjdCB0aGF0Lg0KV2VsbCBpdCBjb3VsZCBiZS4gSnVzdCBsaWtlIHlv
dSBkaWQgd2l0aCB0aGUgTm9uY2UgZmllbGQuIE1ha2UgdGhlIFZlcnNpb24gZmllbGQgdGhlIG1p
ZGRsZSAxNi1iaXRzLiBTbyBWIGFuZCBQIGNhbiBiZSBzZXQgYXQgdGhlIHNhbWUgYXMgd2VsbCBh
cyBOIGFuZCBQLg0KDQpEaW5vDQoNCkdvb2QgcG9pbnQsIHNob3J0ZW5pbmcgdmVyc2lvbnMgdG8g
OCBiaXRzLi4uDQoNClNlZW1zIGZpbmUgdG8gbWUuDQoNCg0KRmFiaW8NCg0KDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxpc3AgbWFpbGluZyBs
aXN0DQpsaXNwQGlldGYub3JnPG1haWx0bzpsaXNwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KbGlzcCBtYWlsaW5nIGxpc3QNCmxpc3BAaWV0Zi5vcmc8bWFp
bHRvOmxpc3BAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2xpc3ANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KbGlzcCBtYWlsaW5nIGxpc3QNCmxpc3BAaWV0Zi5vcmc8bWFpbHRvOmxpc3BAaWV0Zi5vcmc+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCg==

--_000_E2CCB598341A42ECA2E4DEDEFCA4807Bciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpJ
4oCZbSBzdHJvbmdseSBzdXBwb3J0aXZlIG9mIHRoaXMgcHJvcG9zYWwgYXMgaXQgY29tcGxldGVz
IHRoZSBuZWNlc3Nhcnkgc3BlY2lmaWNhdGlvbnMgdG8gc3VwcG9ydCB0aGUgTDIgc2VydmljZXMg
cHJvcG9zZWQgaW4gdGhlIGVpZC1tb2JpbGl0eSBkcmFmdC4gJm5ic3A7PGJyPg0KPGJyPg0KPGRp
diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5WaWN0b3I8L2Rpdj4NCjxkaXY+PGJyPg0KT24gTm92
IDI5LCAyMDE3LCBhdCA0OjU0IFBNLCBGYWJpbyBNYWlubyAoZm1haW5vKSAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmZtYWlub0BjaXNjby5jb20iPmZtYWlub0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8
YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5z
b3VuZHMgZ29vZC48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPkZhYmlvPC9z
cGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5PbiAxMS8yOS8xNyAzOjEzIFBNLCBE
aW5vIEZhcmluYWNjaSB3cm90ZTo8L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+
PHNwYW4+SeKAmWQgYWxzbyBhZGQgYmVmb3JlIHRoZSBsYXN0IHNlbnRlbmNlOjwvc3Bhbj48YnI+
DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJy
Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SWYgdGhlIE4t
Yml0IGFuZCBWLWJpdCBhcmUgMCB3aGVuIHRoZSBQLWJpdCBpcyBzZXQsIHRoZSBtaWRkbGUgMTYt
Yml0cyBhcmUgc2V0IHRvIDAuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48c3Bhbj5EaW5vPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPk9uIE5v
diAyOSwgMjAxNywgYXQgMzowNyBQTSwgRmFiaW8gTWFpbm8gJmx0OzxhIGhyZWY9Im1haWx0bzpm
bWFpbm9AY2lzY28uY29tIj5mbWFpbm9AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxi
cj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+PHNwYW4+T24gMTEvMjkvMTcgMzowNSBQTSwgRGlubyBGYXJpbmFjY2kgd3Jv
dGU6PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj48c3Bhbj5Ib3cgYWJvdXQgdGhpcyB3b3JkaW5nIEZhYmlvOjwvc3Bhbj48YnI+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv
YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5QOiBUaGUgUC1iaXQgaXMgdGhl
IE5leHQgUHJvdG9jb2wgYml0LiBXaGVuIHNldCwgdGhlIGxvdy1vcmRlciA4IGJpdHMgaXMgdXNl
ZCBmb3IgdGhlIE5leHQgUHJvdG9jb2wgZmllbGQuIFdoZW4gdGhlIE4tYml0IGlzIGFsc28gc2V0
IHdpdGggdGhlIFAtYml0LCB0aGUgTm9uY2UgZmllbGQgaXMgdGhlIG1pZGRsZSAxNiBiaXRzLiBX
aGVuIHRoZSBWIGJpdCBpcyBhbHNvIHNldCB3aXRoIHRoZSBQLWJpdCwNCiB0aGUgVmVyc2lvbiBm
aWVsZCBpcyB0aGUgbWlkZGxlIDE2IGJpdHMuIERldGFpbHMgb24gTmV4dCBQcm90b2NvbCBmaWVs
ZCB1c2FnZSBhcmUgZGVzY3JpYmVkIGluIFtkcmFmdC1sZXdpcy1saXNwLWdwZV0uPC9zcGFuPjxi
cj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkNvbW1lbnRzPzwvc3Bh
bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPm11Y2gg
YmV0dGVyLjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48
YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlRoYW5rcyw8L3NwYW4+PGJyPg0KPC9i
bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5GYWJpbzwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+RGlubzwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+
PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPk9uIE5v
diAyOSwgMjAxNywgYXQgMjo0OSBQTSwgRmFiaW8gTWFpbm8gJmx0OzxhIGhyZWY9Im1haWx0bzpm
bWFpbm9AY2lzY28uY29tIj5mbWFpbm9AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxi
cj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx
dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu
Pjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj48c3Bhbj5EZWZpbml0aW9uIG9mIHRoZSBQIGJpdCB3aWxsIGxvb2sgbGlrZTo8L3NwYW4+
PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j
a3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw
YW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwO1A6IFRoZSBQLWJpdCBpcyB0aGUgTmV4dCBQ
cm90b2NvbCBiaXQuIFdoZW4gdGhpcyBiaXQgaXMgc2V0IHRvPC9zcGFuPjxicj4NCjwvYmxvY2tx
dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzEsIE5vbmNlIGxlbmd0aCwgd2hlbiB1c2VkLCBpcyBs
aW1pdGVkIHRvIDE2IGJpdHMgYW5kIHRoZSBsZW5naHQ8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgdGhlIFNvdXJjZSBhbmQgRGVzdGluYXRpb24gTWFwLVZl
cnNpb24gZmllbGRzLCB3aGVuIHVzZWQsIGlzIGxpbWl0ZWQ8L3NwYW4+PGJyPg0KPC9ibG9ja3F1
b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dG8gOCBiaXRzLiBSZWZlciB0byBbZHJhZnQtbGV3aXMt
bGlzcC1ncGVdIGZvciBtb3JlIGRldGFpbHMuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwv
YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO1RoZSBQLWJpdCBpcyBzZXQgdG8gMSB0byBpbmRpY2F0ZSB0aGUgcHJl
c2VuY2Ugb2YgdGhlIDggYml0IE5leHQgUHJvdG9jb2wgZmllbGQgZW5jb2RlZCBhczo8L3NwYW4+
PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j
a3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw
YW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j
a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+RG8geW91IHRoaW5rIHRoZSBvdmVyYWxs
IHByb3Bvc2VkIGV4dGVuc2lvbiBtYWtlcyBzZW5zZT88L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwv
YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlRoYW5r
cyw8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+PHNwYW4+RmFiaW88L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwv
YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPk9uIDExLzI5LzE3IDI6MzggUE0s
IEZhYmlvIE1haW5vIHdyb3RlOjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8
YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPk9u
IDExLzI5LzE3IDI6MzYgUE0sIERpbm8gRmFyaW5hY2NpIHdyb3RlOjwvc3Bhbj48YnI+DQo8L2Js
b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8
YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UaGUgdXNlIG9mIHRoZSBQLWJpdCBpcyBub3Qg
Y29tcGF0aWJsZSB3aXRoIHRoZSBNYXAtVmVyc2lvbmluZyBmZWF0dXJlLCBidXQgYW4gZXF1aXZh
bGVudCBmdW5jdGlvbiBjYW4gYmUgc3BlY2lmaWVkIChpZiBuZWVkZWQpIHdpdGggYSBOZXh0LVBy
b3RvY29sIHNoaW0gaGVhZGVyLiBJIGNhbiBhZGQgdGV4dCB0byB0aGUgTElTUC1HUEUgZHJhZnQg
dG8gcmVmbGVjdCB0aGF0Ljwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+PHNwYW4+V2VsbCBpdCBjb3VsZCBiZS4gSnVzdCBsaWtlIHlvdSBkaWQgd2l0aCB0aGUgTm9u
Y2UgZmllbGQuIE1ha2UgdGhlIFZlcnNpb24gZmllbGQgdGhlIG1pZGRsZSAxNi1iaXRzLiBTbyBW
IGFuZCBQIGNhbiBiZSBzZXQgYXQgdGhlIHNhbWUgYXMgd2VsbCBhcyBOIGFuZCBQLjwvc3Bhbj48
YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwv
YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N
CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp
dGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48
c3Bhbj5EaW5vPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv
Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0K
PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5Hb29k
IHBvaW50LCBzaG9ydGVuaW5nIHZlcnNpb25zIHRvIDggYml0cy4uLjwvc3Bhbj48YnI+DQo8L2Js
b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr
cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlNlZW1zIGZpbmUgdG8gbWUuPC9zcGFuPjxicj4N
CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxv
Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv
YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx
dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+RmFiaW88L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1
b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9i
bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1
b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K
PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j
a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh
bj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48
YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmxpc3AgbWFpbGluZyBs
aXN0PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEg
aHJlZj0ibWFpbHRvOmxpc3BAaWV0Zi5vcmciPmxpc3BAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4N
CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2xpc3A8L2E+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv
Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjwvYmxv
Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmxpc3AgbWFp
bGluZyBsaXN0PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv
Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYub3JnIj5saXNwQGll
dGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js
b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2xpc3AiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlz
cDwvYT48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1
b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1
b3RlPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPmxpc3AgbWFpbGluZyBsaXN0
PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYub3JnIj5saXNwQGll
dGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2xpc3AiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbGlzcDwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_E2CCB598341A42ECA2E4DEDEFCA4807Bciscocom_--


From nobody Wed Nov 29 22:33:09 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC9127419 for ; Wed, 29 Nov 2017 22:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NR04uhClNUTD for ; Wed, 29 Nov 2017 22:33:05 -0800 (PST)
Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e: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 0231812025C for ; Wed, 29 Nov 2017 22:33:05 -0800 (PST)
Received: by mail-pl0-x230.google.com with SMTP id b12so3679060plm.3 for ; Wed, 29 Nov 2017 22:33:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3T4TYEODHo8l2J2DdK9dEAxdyUUaeATlLae2AkAKIGo=; b=RPxQI5wxYgrRhpSAijG0syidjMo+R3z8BAushefTTKSRM+uQHASF1AS3g1NSX0jJBk /1ewwzyzxIJk2eMo4lQllfffqFwz88fnT7VcSIeZZHkkqyUEuNYfjFSO09MeZQSK8sSI ZeG7Ma2ETJbX/Lp9hEtDLIbjdbGLPkXxLjseQu3zaUfVi/egfFeFF+rhtDeIvV98TU7j RdxUUMbdJOz2+WXLyvMvUDsL2sjcBX8Jp2yO80mJLGouj58Uze4El5il2y3GQW1HqHIy OLHe9d4om9NYUohazuuulbhTPhSRJRz6i3okerh8TDq1qLyshtnCgLEcSwAEgpdDhSIc WcMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3T4TYEODHo8l2J2DdK9dEAxdyUUaeATlLae2AkAKIGo=; b=Kao0aLbw9LunJWzfFAek7BRC58dl1QvSDq7OyK/EEksYNFM59Gywj/eYrAmrDNewZ7 smLHbqGxAkpJ3q9YOxC9KT29rL17syK3svYHY2OcwFC8EF0EEUGMW13lnnG0sVJiGQBR QXiUiG+MgpKwewJbFJBt4jkTmlRB43mRCWM/8xd8CwgxLC8l4QbJ2TC7wOeDnSUog5Fo 5Yk4bNvlOqjiWrHbQiD5Ph/1U/yjzJTmbRdK8WkWDyW7QP3L083Df5+C8dl2lOydFjfR hWQRr4H0Gj0W2lPwuw8DASwi6+3s83+5b/8m3ZLmeVobxTsYtk+p/S6g21vwN0tXFWa9 Kc0w==
X-Gm-Message-State: AJaThX6S6K598SRm7BzvnSvHFHSVzu1ud19TmdIGYofa3Wo9jUaoOUNU 13J69nas8OMAfl1espxzIe8=
X-Google-Smtp-Source: AGs4zMY549l439Salae91waXRYURcYeHfmOZsnHhmKzzS6XIKRznGynWPlQ9qih1pq2LDNtt7Nb57A==
X-Received: by 10.84.138.193 with SMTP id 59mr1559691plp.446.1512023584546; Wed, 29 Nov 2017 22:33:04 -0800 (PST)
Received: from ?IPv6:2001:420:c0c8:1008::108? ([2001:420:c0c8:1008::108]) by smtp.gmail.com with ESMTPSA id o184sm5698308pga.3.2017.11.29.22.33.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 22:33:04 -0800 (PST)
From: Florin Coras 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_20F68D00-19F6-4CB5-99E4-A55FE0008D25"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Wed, 29 Nov 2017 22:32:51 -0800
In-Reply-To: 
Cc: "Fabio Maino (fmaino)" , "lisp@ietf.org" 
To: "Victor Moreno (vimoreno)" 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>  <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>  
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 06:33:08 -0000

--Apple-Mail=_20F68D00-19F6-4CB5-99E4-A55FE0008D25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1

The LISP implementation in FD.io  VPP makes use of it to =
distinguish between Ethernet, IP and NSH payloads.=20

Florin

> On Nov 29, 2017, at 10:20 PM, Victor Moreno (vimoreno) =
 wrote:
>=20
> I=E2=80=99m strongly supportive of this proposal as it completes the =
necessary specifications to support the L2 services proposed in the =
eid-mobility draft. =20
>=20
> Victor
>=20
> On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) > wrote:
>=20
>> sounds good.
>>=20
>> Fabio
>>=20
>> On 11/29/17 3:13 PM, Dino Farinacci wrote:
>>> I=E2=80=99d also add before the last sentence:
>>>=20
>>> If the N-bit and V-bit are 0 when the P-bit is set, the middle =
16-bits are set to 0.
>>>=20
>>> Dino
>>>=20
>>>> On Nov 29, 2017, at 3:07 PM, Fabio Maino > wrote:
>>>>=20
>>>> On 11/29/17 3:05 PM, Dino Farinacci wrote:
>>>>> How about this wording Fabio:
>>>>>=20
>>>>> P: The P-bit is the Next Protocol bit. When set, the low-order 8 =
bits is used for the Next Protocol field. When the N-bit is also set =
with the P-bit, the Nonce field is the middle 16 bits. When the V bit is =
also set with the P-bit, the Version field is the middle 16 bits. =
Details on Next Protocol field usage are described in =
[draft-lewis-lisp-gpe].
>>>>>=20
>>>>> Comments?
>>>> much better.
>>>>=20
>>>> Thanks,
>>>> Fabio
>>>>=20
>>>>> Dino
>>>>>=20
>>>>>> On Nov 29, 2017, at 2:49 PM, Fabio Maino > wrote:
>>>>>>=20
>>>>>> Definition of the P bit will look like:
>>>>>>=20
>>>>>>    P: The P-bit is the Next Protocol bit. When this bit is set to
>>>>>>       1, Nonce length, when used, is limited to 16 bits and the =
lenght
>>>>>>       of the Source and Destination Map-Version fields, when =
used, is limited
>>>>>>       to 8 bits. Refer to [draft-lewis-lisp-gpe] for more =
details.
>>>>>>       The P-bit is set to 1 to indicate the presence of the 8 bit =
Next Protocol field encoded as:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Do you think the overall proposed extension makes sense?
>>>>>>=20
>>>>>> Thanks,
>>>>>> Fabio
>>>>>>=20
>>>>>> On 11/29/17 2:38 PM, Fabio Maino wrote:
>>>>>>> On 11/29/17 2:36 PM, Dino Farinacci wrote:
>>>>>>>>> The use of the P-bit is not compatible with the Map-Versioning =
feature, but an equivalent function can be specified (if needed) with a =
Next-Protocol shim header. I can add text to the LISP-GPE draft to =
reflect that.
>>>>>>>> Well it could be. Just like you did with the Nonce field. Make =
the Version field the middle 16-bits. So V and P can be set at the same =
as well as N and P.
>>>>>>>>=20
>>>>>>>> Dino
>>>>>>>>=20
>>>>>>> Good point, shortening versions to 8 bits...
>>>>>>>=20
>>>>>>> Seems fine to me.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Fabio
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=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
>>=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


--Apple-Mail=_20F68D00-19F6-4CB5-99E4-A55FE0008D25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1

The =
LISP implementation in FD.io VPP makes use of it to distinguish between =
Ethernet, IP and NSH payloads. 

Florin

On Nov =
29, 2017, at 10:20 PM, Victor Moreno (vimoreno) <vimoreno@cisco.com> =
wrote:







I=E2=80=99m strongly supportive of this proposal as it completes the =
necessary specifications to support the L2 services proposed in the =
eid-mobility draft.  




Victor




On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <fmaino@cisco.com> =
wrote:








sounds good.



Fabio



On 11/29/17 3:13 PM, Dino Farinacci wrote:


I=E2=80=99d also =
add before the last sentence:









If the N-bit and =
V-bit are 0 when the P-bit is set, the middle 16-bits are set to =
0.









Dino











On Nov 29, 2017, =
at 3:07 PM, Fabio Maino <fmaino@cisco.com> wrote:

















On 11/29/17 3:05 =
PM, Dino Farinacci wrote:










How about this =
wording Fabio:

























P: The P-bit is =
the Next Protocol bit. When set, the low-order 8 bits is used for the =
Next Protocol field. When the N-bit is also set with the P-bit, the =
Nonce field is the middle 16 bits. When the V bit is also set with the =
P-bit,
 the Version field is the middle 16 bits. Details on Next Protocol field =
usage are described in [draft-lewis-lisp-gpe].

























Comments?










much =
better.

















Thanks,








Fabio



















Dino



























On Nov 29, 2017, =
at 2:49 PM, Fabio Maino <fmaino@cisco.com> wrote:

































Definition of the =
P bit will look like:

































   P:=
 The P-bit is the Next Protocol bit. When this bit is set to
















      1, Nonce length, when =
used, is limited to 16 bits and the lenght
















      of the Source and =
Destination Map-Version fields, when used, is limited
















      to 8 bits. Refer to =
[draft-lewis-lisp-gpe] for more details.
















      The P-bit is set to 1 to =
indicate the presence of the 8 bit Next Protocol field encoded =
as:



































































Do you think the =
overall proposed extension makes sense?

































Thanks,
















Fabio

































On 11/29/17 2:38 =
PM, Fabio Maino wrote:


















On 11/29/17 2:36 =
PM, Dino Farinacci wrote:
























The use of the =
P-bit is not compatible with the Map-Versioning feature, but an =
equivalent function can be specified (if needed) with a Next-Protocol =
shim header. I can add text to the LISP-GPE draft to reflect =
that.


























Well it could be. =
Just like you did with the Nonce field. Make the Version field the =
middle 16-bits. So V and P can be set at the same as well as N and =
P.

















































Dino















































Good point, =
shortening versions to 8 bits...









































Seems fine to =
me.






























































Fabio








































































































_______________________________________________




















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

=

--Apple-Mail=_20F68D00-19F6-4CB5-99E4-A55FE0008D25--


From nobody Thu Nov 30 00:48:02 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A159B1200C5 for ; Thu, 30 Nov 2017 00:48:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lQR1xElJ9Hrl for ; Thu, 30 Nov 2017 00:47:57 -0800 (PST)
Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCD8128E00 for ; Thu, 30 Nov 2017 00:47:56 -0800 (PST)
Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vAU8loim017974; Thu, 30 Nov 2017 09:47:50 +0100
Received: from [147.83.35.39] (sirius.ac.upc.es [147.83.35.39]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 24A632B2; Thu, 30 Nov 2017 09:47:45 +0100 (CET)
To: Florin Coras , "Victor Moreno (vimoreno)" 
Cc: "lisp@ietf.org" 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>  <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>   
From: =?UTF-8?Q?Albert_L=c3=b3pez?= 
Message-ID: <13f18cab-7017-0af3-6da6-074aed8cb24f@ac.upc.edu>
Date: Thu, 30 Nov 2017 09:47:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B0556AE3C9DB3DB2CB256ECF"
Content-Language: en-US
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 08:48:00 -0000

This is a multi-part message in MIME format.
--------------B0556AE3C9DB3DB2CB256ECF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

+1

I also support extending RFC 6830bis as suggested. We have an initial 
implementation of LISP-GPE in OOR and we think this extension could be 
really useful.

Albert López



El 30/11/17 a les 07:32, Florin Coras ha escrit:
> +1
>
> The LISP implementation in FD.io  VPP makes use of it to 
> distinguish between Ethernet, IP and NSH payloads.
>
> Florin
>
>> On Nov 29, 2017, at 10:20 PM, Victor Moreno (vimoreno) 
>> > wrote:
>>
>> I’m strongly supportive of this proposal as it completes the 
>> necessary specifications to support the L2 services proposed in the 
>> eid-mobility draft.
>>
>> Victor
>>
>> On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) > > wrote:
>>
>>> sounds good.
>>>
>>> Fabio
>>>
>>> On 11/29/17 3:13 PM, Dino Farinacci wrote:
>>>> I’d also add before the last sentence:
>>>>
>>>> If the N-bit and V-bit are 0 when the P-bit is set, the middle 
>>>> 16-bits are set to 0.
>>>>
>>>> Dino
>>>>
>>>>> On Nov 29, 2017, at 3:07 PM, Fabio Maino >>>> > wrote:
>>>>>
>>>>> On 11/29/17 3:05 PM, Dino Farinacci wrote:
>>>>>> How about this wording Fabio:
>>>>>>
>>>>>> P: The P-bit is the Next Protocol bit. When set, the low-order 8 
>>>>>> bits is used for the Next Protocol field. When the N-bit is also 
>>>>>> set with the P-bit, the Nonce field is the middle 16 bits. When 
>>>>>> the V bit is also set with the P-bit, the Version field is the 
>>>>>> middle 16 bits. Details on Next Protocol field usage are 
>>>>>> described in [draft-lewis-lisp-gpe].
>>>>>>
>>>>>> Comments?
>>>>> much better.
>>>>>
>>>>> Thanks,
>>>>> Fabio
>>>>>
>>>>>> Dino
>>>>>>
>>>>>>> On Nov 29, 2017, at 2:49 PM, Fabio Maino >>>>>> > wrote:
>>>>>>>
>>>>>>> Definition of the P bit will look like:
>>>>>>>
>>>>>>>    P: The P-bit is the Next Protocol bit. When this bit is set to
>>>>>>>       1, Nonce length, when used, is limited to 16 bits and the 
>>>>>>> lenght
>>>>>>>       of the Source and Destination Map-Version fields, when 
>>>>>>> used, is limited
>>>>>>>       to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.
>>>>>>>       The P-bit is set to 1 to indicate the presence of the 8 
>>>>>>> bit Next Protocol field encoded as:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Do you think the overall proposed extension makes sense?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Fabio
>>>>>>>
>>>>>>> On 11/29/17 2:38 PM, Fabio Maino wrote:
>>>>>>>> On 11/29/17 2:36 PM, Dino Farinacci wrote:
>>>>>>>>>> The use of the P-bit is not compatible with the 
>>>>>>>>>> Map-Versioning feature, but an equivalent function can be 
>>>>>>>>>> specified (if needed) with a Next-Protocol shim header. I can 
>>>>>>>>>> add text to the LISP-GPE draft to reflect that.
>>>>>>>>> Well it could be. Just like you did with the Nonce field. Make 
>>>>>>>>> the Version field the middle 16-bits. So V and P can be set at 
>>>>>>>>> the same as well as N and P.
>>>>>>>>>
>>>>>>>>> Dino
>>>>>>>>>
>>>>>>>> Good point, shortening versions to 8 bits...
>>>>>>>>
>>>>>>>> Seems fine to me.
>>>>>>>>
>>>>>>>>
>>>>>>>> Fabio
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp


--------------B0556AE3C9DB3DB2CB256ECF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
+1  

      

      I also support extending RFC 6830bis as suggested. We have an
      initial implementation of LISP-GPE in OOR and we think this
      extension could be really useful.

      

      Albert López

      

      

      

      El 30/11/17 a les 07:32, Florin Coras ha escrit:

    

    

      
      +1
      


      

      
The LISP implementation in FD.io VPP makes use of it
        to distinguish between Ethernet, IP and NSH payloads. 

      


      

      
Florin

        


          

            
On Nov 29, 2017, at 10:20 PM, Victor Moreno
              (vimoreno) <vimoreno@cisco.com>
              wrote:

            

            

              
              

                I’m strongly supportive of this proposal as it completes
                the necessary specifications to support the L2 services
                proposed in the eid-mobility draft.  

                

                
Victor

                


                  On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <fmaino@cisco.com>
                  wrote:

                  

                

                

                  
sounds good.

                    

                    Fabio

                    

                    On 11/29/17 3:13 PM, Dino Farinacci
                      wrote:

                    
I’d
                        also add before the last sentence:

                    

                    


                    

                    
If
                        the N-bit and V-bit are 0 when the P-bit is set,
                        the middle 16-bits are set to 0.

                    

                    


                    

                    
Dino

                    

                    


                    

                    

                      
On
                          Nov 29, 2017, at 3:07 PM, Fabio Maino <fmaino@cisco.com>
                          wrote:

                      

                    

                    

                      


                      

                    

                    

                      
On
                          11/29/17 3:05 PM, Dino Farinacci wrote:

                      

                    

                    

                      

                        
How
                            about this wording Fabio:

                        

                      

                    

                    

                      

                        


                        

                      

                    

                    

                      

                        
P:
                            The P-bit is the Next Protocol bit. When
                            set, the low-order 8 bits is used for the
                            Next Protocol field. When the N-bit is also
                            set with the P-bit, the Nonce field is the
                            middle 16 bits. When the V bit is also set
                            with the P-bit, the Version field is the
                            middle 16 bits. Details on Next Protocol
                            field usage are described in
                            [draft-lewis-lisp-gpe].

                        

                      

                    

                    

                      

                        


                        

                      

                    

                    

                      

                        
Comments?

                        

                      

                    

                    

                      
much
                          better.

                      

                    

                    

                      


                      

                    

                    

                      
Thanks,

                      

                    

                    

                      
Fabio

                      

                    

                    

                      


                      

                    

                    

                      

                        
Dino

                        

                      

                    

                    

                      

                        


                        

                      

                    

                    

                      

                        

                          
On Nov 29, 2017, at 2:49 PM,
                              Fabio Maino <fmaino@cisco.com>
                              wrote:

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
Definition of the P bit will look
                              like:

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
   P: The P-bit is the Next
                              Protocol bit. When this bit is set to

                          

                        

                      

                    

                    

                      

                        

                          
      1, Nonce length, when used,
                              is limited to 16 bits and the lenght

                          

                        

                      

                    

                    

                      

                        

                          
      of the Source and
                              Destination Map-Version fields, when used,
                              is limited

                          

                        

                      

                    

                    

                      

                        

                          
      to 8 bits. Refer to
                              [draft-lewis-lisp-gpe] for more details.

                          

                        

                      

                    

                    

                      

                        

                          
      The P-bit is set to 1 to
                              indicate the presence of the 8 bit Next
                              Protocol field encoded as:

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
Do you think the overall proposed
                              extension makes sense?

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
Thanks,

                          

                        

                      

                    

                    

                      

                        

                          
Fabio

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
On 11/29/17 2:38 PM, Fabio Maino
                              wrote:

                          

                        

                      

                    

                    

                      

                        

                          

                            
On 11/29/17 2:36 PM, Dino
                                Farinacci wrote:

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              

                                
The use of the P-bit is not
                                    compatible with the Map-Versioning
                                    feature, but an equivalent function
                                    can be specified (if needed) with a
                                    Next-Protocol shim header. I can add
                                    text to the LISP-GPE draft to
                                    reflect that.

                                

                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              
Well it could be. Just like
                                  you did with the Nonce field. Make the
                                  Version field the middle 16-bits. So V
                                  and P can be set at the same as well
                                  as N and P.

                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              


                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              
Dino

                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              


                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
Good point, shortening versions
                                to 8 bits...

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
Seems fine to me.

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
Fabio

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
_______________________________________________

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
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

            

          

        

        

      

      

      

      

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


    

    

  


--------------B0556AE3C9DB3DB2CB256ECF--


From nobody Thu Nov 30 01:33:18 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D24B128DF3 for ; Thu, 30 Nov 2017 01:33:16 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com
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 qy-fiI1CFESB for ; Thu, 30 Nov 2017 01:33:14 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c: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 5AC321200C5 for ; Thu, 30 Nov 2017 01:33:14 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id l141so11719847wmg.1 for ; Thu, 30 Nov 2017 01:33:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=RJcAdYmgO7i+FeDPKOHZbEMRvpNHK0iLtzqaY1dLKV0=; b=FgqimCLRWl/vFU7Xvp5DtD9dJSfSia4ftlz+ij/+gJ1nH/5wqiiD8kRgdxDkBS3EsO ojkmiM0ytvxHSE5L5wM5VBEkYkwkJQuyYJLba/W/leYTiuqyPzrWMRGpznIjyYbRFw5z yEX3VKdJiO5JxjzAIqhmtxJ9mdHyZYEQ16QoVGLb98GlTQQyNuKcx6+cRrTEjwyc+eD5 EauLN5lqrSx4gUU23bp6iUhBQWIoOCBZ3BCEDKPKzGL/ccs6w3bAkxSJw/H704oBhDOi yiKcgOXnAtrg7gt9+aLRV5Laatap5IO7YZxmvIvAPaoEQXDrX5zD216mEPrwY/JIwfbr gFXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=RJcAdYmgO7i+FeDPKOHZbEMRvpNHK0iLtzqaY1dLKV0=; b=dEeMEhKYE9LO4mKpaLZO4GANEJp8r2iaYu/POZB/gOHxZqQqrgYF+C3DcOhTf/L8LY 3Gxco8iTEcKP3Govgd9XfdtlLQJU96tc6sQ8O2Ea/fm05iaJt2suNM4+xLPCcG0KJnyH vCZfemDTkhuzkD/fSmZhsTOYjq6PiBtLZ8pBCAUgjJnsBWheVaGrvTluzbL3bu0H7y1K U5BCyJL0BVysmY7t4IA6dMHFwCadDMpOBnbUYCtimCwmTDIxYM4aEGSixnyoKr044CK3 7mQ1qYptHS23d/UXsc0sfIUu/FtkKAykkE8aDD7JvJo+Cod4ewRhqn0vk1qKh0FWTNyD ixUg==
X-Gm-Message-State: AJaThX5BFF6QdacjM56yVdxP4I0CfkAu1dfumtFNtcVWj2af79fIkgd2 CVCShP7vlA1K8uvofzR/KqRYvHPAhLo=
X-Google-Smtp-Source: AGs4zMb4Zqe/2yAwdnamkJCgBR6PYtPTADGgne7FSWgGq2x6hSiMJn20V8vQ2j27ywKYUpre3eZykA==
X-Received: by 10.80.226.198 with SMTP id q6mr12006325edl.290.1512034392445; Thu, 30 Nov 2017 01:33:12 -0800 (PST)
Received: from ?IPv6:2001:660:330f:a4:18d:f14a:90e7:53bf? ([2001:660:330f:a4:18d:f14a:90e7:53bf]) by smtp.gmail.com with ESMTPSA id j27sm2815490eda.59.2017.11.30.01.33.10 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 01:33:11 -0800 (PST)
From: Luigi Iannone 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Thu, 30 Nov 2017 10:33:26 +0100
References: <151197437351.7944.17794546083400854990@ietfa.amsl.com>
To: "lisp@ietf.org list" 
In-Reply-To: <151197437351.7944.17794546083400854990@ietfa.amsl.com>
Message-Id: <4289A7FC-B6F4-429C-8F29-3B1B941C1B1B@gigix.net>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
Subject: [lisp] I-D Action: draft-ietf-lisp-signal-free-multicast-07.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 09:33:16 -0000

Folks,

As shepherd of the Signal Free document I asked the authors to fix some =
editorial issues as well as the use of RFC2119 notation.

Changing the use of RFC 2119 notation is to be considered a technical =
change, however, the aim of the document did not change at all, it just =
made specifications clearer.

With this mail the chairs open a 2 week period to check if anybody has =
any objection to the changes.
Without any further comment we will consider that rough consensus  for =
the 06 document still holds for 07.

Thanks

Luigi



> On 29 Nov 2017, at 17:52, 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 WG of =
the IETF.
>=20
>        Title           : Signal-Free LISP Multicast
>        Authors         : Victor Moreno
>                          Dino Farinacci
> 	Filename        : draft-ietf-lisp-signal-free-multicast-07.txt
> 	Pages           : 23
> 	Date            : 2017-11-29
>=20
> Abstract:
>   When multicast sources and receivers are active at LISP sites, the
>   core network is required to use native multicast so packets can be
>   delivered from sources to group members.  When multicast is not
>   available to connect the multicast sites together, a signal-free
>   mechanism can be used to allow traffic to flow between sites.  The
>   mechanism within here uses unicast replication and encapsulation =
over
>   the core network for the data-plane and uses the LISP mapping
>   database system so encapsulators at the source LISP multicast site
>   can find decapsulators at the receiver LISP multicast sites.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> =
https://datatracker.ietf.org/doc/draft-ietf-lisp-signal-free-multicast/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lisp-signal-free-multicast-07
> =
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-signal-free-multicas=
t-07
>=20
> A diff from the previous version is available at:
> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-signal-free-multicast-=
07
>=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 Thu Nov 30 02:47:01 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A40129432 for ; Thu, 30 Nov 2017 02:46:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nihArF_P4o_6 for ; Thu, 30 Nov 2017 02:46:57 -0800 (PST)
Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::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 443111293FD for ; Thu, 30 Nov 2017 02:46:57 -0800 (PST)
Received: by mail-yb0-x236.google.com with SMTP id p128so2526882yba.7 for ; Thu, 30 Nov 2017 02:46:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Na3FyiLx2W627rwlXED4dxh+9g4t4m9mIpWsYDa/SG4=; b=mFkjXl/6TZBFTyPqXGNcRX/5exd+dauA7sv3Fu8UOAOLV5k0IqErUNCFvw7jiGc/ax XAz62dXE3DEHXKQQRUWIfd1Wd3UEWsMlxU3UMOWbMNtsdBmYTgybYmmK6lMXRm2L3hQ6 yuo7shJVsoHMs2xKOPSyB1a0mt0ZnZ+jpx1EuXoytm+p17TRGQspS/ThoElEzvwdNGC+ 3zn1aQZHaVqtF7QD50LEo4VzWge5pAnv8f4eFaKs9qHYzsu6cl1wpHAsupA84jRuRtta tPXkyPYb6nwScAjL6i3LGi98OjI0s4u/SHE79iyoaWRa2y/nJzrW7Xx2SjfhqlI8RZnx 0tKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Na3FyiLx2W627rwlXED4dxh+9g4t4m9mIpWsYDa/SG4=; b=AxwrmWKOAs6JYQ9StqS2hp9XFMHN0VgfvRBkR4P7SEJOymH4admqFVhz5CyXWp75yS 9gn6cXLHFitgisZX7kaeArGiKK/tumOadNuQElIxx8QILd4fCfH42Ggkw13fEyPZ0PVC ZkSWTmY9vvY2Q8XWrLIG21eGREnTkS6KQLXXY6iiozKdNd0sx1weeL8zt8yeyfC6665R y61IiZYMcOmfGifaddGdHuCTDEA7gGIqs4hKtnwHu+s4K76Ot9ECv2IR2u4KIXFOWysn JA378ZI5OnsCJ/boxSiljzxzdeWD5D7TiyFyn8aryB2HB30dbSiE+x2s4PkuybYC7+Dr Cqvg==
X-Gm-Message-State: AJaThX7QlHDV6uCdb2wp1w12ba3fBakwtgBNZiyiBaaHJgAb3tsXCgVs 1vr3wCyimo09+lEujCF8Q7nDAG8EWhjWGHZhIs4=
X-Google-Smtp-Source: AGs4zMa9WVfjV+6Ohaga9FGbe1SD7xqjrHkKZIKvE0zCUQ+p6NuflY+aRkUWm7+CT5E1lurLz05/YJyYKS0DQj2jnSo=
X-Received: by 10.37.76.198 with SMTP id z189mr1134888yba.129.1512038816486; Thu, 30 Nov 2017 02:46:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.231.213 with HTTP; Thu, 30 Nov 2017 02:46:56 -0800 (PST)
In-Reply-To: <13f18cab-7017-0af3-6da6-074aed8cb24f@ac.upc.edu>
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>  <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>    <13f18cab-7017-0af3-6da6-074aed8cb24f@ac.upc.edu>
From: Albert Cabellos 
Date: Thu, 30 Nov 2017 11:46:56 +0100
Message-ID: 
To: =?UTF-8?Q?Albert_L=C3=B3pez?= 
Cc: Florin Coras , "Victor Moreno (vimoreno)" ,  "lisp@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113e54268b1a12055f30f838"
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 10:47:00 -0000

--001a113e54268b1a12055f30f838
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all

Support proposed 6830bis extension.

This is indeed implmemented in OOR.

Albert

On Thu, Nov 30, 2017 at 9:47 AM, Albert L=C3=B3pez  wrot=
e:

> +1
>
> I also support extending RFC 6830bis as suggested. We have an initial
> implementation of LISP-GPE in OOR and we think this extension could be
> really useful.
>
> Albert L=C3=B3pez
>
>
>
> El 30/11/17 a les 07:32, Florin Coras ha escrit:
>
> +1
>
> The LISP implementation in FD.io VPP makes use of it to distinguish
> between Ethernet, IP and NSH payloads.
>
> Florin
>
> On Nov 29, 2017, at 10:20 PM, Victor Moreno (vimoreno) 
> wrote:
>
> I=E2=80=99m strongly supportive of this proposal as it completes the nece=
ssary
> specifications to support the L2 services proposed in the eid-mobility
> draft.
>
> Victor
>
> On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) 
> wrote:
>
> sounds good.
>
> Fabio
>
> On 11/29/17 3:13 PM, Dino Farinacci wrote:
>
> I=E2=80=99d also add before the last sentence:
>
>
> If the N-bit and V-bit are 0 when the P-bit is set, the middle 16-bits ar=
e
> set to 0.
>
>
> Dino
>
>
> On Nov 29, 2017, at 3:07 PM, Fabio Maino  wrote:
>
>
> On 11/29/17 3:05 PM, Dino Farinacci wrote:
>
> How about this wording Fabio:
>
>
> P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is
> used for the Next Protocol field. When the N-bit is also set with the
> P-bit, the Nonce field is the middle 16 bits. When the V bit is also set
> with the P-bit, the Version field is the middle 16 bits. Details on Next
> Protocol field usage are described in [draft-lewis-lisp-gpe].
>
>
> Comments?
>
> much better.
>
>
> Thanks,
>
> Fabio
>
>
> Dino
>
>
> On Nov 29, 2017, at 2:49 PM, Fabio Maino  wrote:
>
>
> Definition of the P bit will look like:
>
>
>    P: The P-bit is the Next Protocol bit. When this bit is set to
>
>       1, Nonce length, when used, is limited to 16 bits and the lenght
>
>       of the Source and Destination Map-Version fields, when used, is
> limited
>
>       to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.
>
>       The P-bit is set to 1 to indicate the presence of the 8 bit Next
> Protocol field encoded as:
>
>
>
>
> Do you think the overall proposed extension makes sense?
>
>
> Thanks,
>
> Fabio
>
>
> On 11/29/17 2:38 PM, Fabio Maino wrote:
>
> On 11/29/17 2:36 PM, Dino Farinacci wrote:
>
> The use of the P-bit is not compatible with the Map-Versioning feature,
> but an equivalent function can be specified (if needed) with a
> Next-Protocol shim header. I can add text to the LISP-GPE draft to reflec=
t
> that.
>
> Well it could be. Just like you did with the Nonce field. Make the Versio=
n
> field the middle 16-bits. So V and P can be set at the same as well as N
> and P.
>
>
> Dino
>
>
> Good point, shortening versions to 8 bits...
>
>
> Seems fine to me.
>
>
>
> Fabio
>
>
>
>
>
> _______________________________________________
>
> 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
>
>
>
>
> _______________________________________________
> lisp mailing listlisp@ietf.orghttps://www.ietf.org/mailman/listinfo/lisp
>
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>
>

--001a113e54268b1a12055f30f838
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all

Support proposed 6830bis extensi=
on.

This is indeed implmemented in OOR.
=

Albert

On Thu, Nov 30, 2017 at 9:47 AM, Albert L=C3=B3pez <alope=
z@ac.upc.edu> wrote:

 =20
   =20
 =20
  

    
+1=C2=A0 

      

      I also support extending RFC 6830bis as suggested. We have an
      initial implementation of LISP-GPE in OOR and we think this
      extension could be really useful.

      

      Albert L=C3=B3pez

      

      

      

      El 30/11/17 a les 07:32, Florin Coras ha escrit:

    

    

     =20
      +1
      


      

      
The LISP implementation in FD.io=C2=A0VPP makes use of it
        to distinguish between Ethernet, IP and NSH payloads.=C2=A0

      


      

      
Florin

        


          

            
On Nov 29, 2017, at 10:20 PM, Victor Moreno
              (vimoreno) <vimoreno@cisco.com>
              wrote:

            

            

             =20
              

                I=E2=80=99m strongly supportive of this proposal as it comp=
letes
                the necessary specifications to support the L2 services
                proposed in the eid-mobility draft. =C2=A0

                

                
Victor

                


                  On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <fmaino@cisco.com>
                  wrote:

                  

                

                

                  
sounds good.

                    

                    Fabio

                    

                    On 11/29/17 3:13 PM, Dino Farinacci
                      wrote:

                    
I=E2=80=99d
                        also add before the last sentence:

                    

                    


                    

                    
If
                        the N-bit and V-bit are 0 when the P-bit is set,
                        the middle 16-bits are set to 0.

                    

                    


                    

                    
Dino

                    

                    


                    

                    

                      
On
                          Nov 29, 2017, at 3:07 PM, Fabio Maino <fmaino@cisco.com>
                          wrote:

                      

                    

                    

                      


                      

                    

                    

                      
On
                          11/29/17 3:05 PM, Dino Farinacci wrote:
                      

                    

                    

                      

                        
How
                            about this wording Fabio:

                        

                      

                    

                    

                      

                        


                        

                      

                    

                    

                      

                        
P:
                            The P-bit is the Next Protocol bit. When
                            set, the low-order 8 bits is used for the
                            Next Protocol field. When the N-bit is also
                            set with the P-bit, the Nonce field is the
                            middle 16 bits. When the V bit is also set
                            with the P-bit, the Version field is the
                            middle 16 bits. Details on Next Protocol
                            field usage are described in
                            [draft-lewis-lisp-gpe].

                        

                      

                    

                    

                      

                        


                        

                      

                    

                    

                      

                        
Comments?
                        

                      

                    

                    

                      
much
                          better.

                      

                    

                    

                      


                      

                    

                    

                      
Thanks,

                      

                    

                    

                      
Fabio

                      

                    

                    

                      


                      

                    

                    

                      

                        
Dino

                        

                      

                    

                    

                      

                        


                        

                      

                    

                    

                      

                        

                          
On Nov 29, 2017, =
at 2:49 PM,
                              Fabio Maino <fmaino@cisco.com>
                              wrote:

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
Definition of the=
 P bit will look
                              like:

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
=C2=A0=C2=A0=C2=
=A0P: The P-bit is the Next
                              Protocol bit. When this bit is set to<=
br>
                          

                        

                      

                    

                    

                      

                        

                          
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A01, Nonce length, when used,
                              is limited to 16 bits and the lenght
                          

                        

                      

                    

                    

                      

                        

                          
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0of the Source and
                              Destination Map-Version fields, when used,
                              is limited

                          

                        

                      

                    

                    

                      

                        

                          
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0to 8 bits. Refer to
                              [draft-lewis-lisp-gpe] for more details.

                          

                        

                      

                    

                    

                      

                        

                          
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0The P-bit is set to 1 to
                              indicate the presence of the 8 bit Next
                              Protocol field encoded as:

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
Do you think the =
overall proposed
                              extension makes sense?

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
Thanks,
                          

                        

                      

                    

                    

                      

                        

                          
Fabio

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
On 11/29/17 2:38 =
PM, Fabio Maino
                              wrote:

                          

                        

                      

                    

                    

                      

                        

                          

                            
On 11/29/17 2:3=
6 PM, Dino
                                Farinacci wrote:

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              

                                
The use of =
the P-bit is not
                                    compatible with the Map-Versioning
                                    feature, but an equivalent function
                                    can be specified (if needed) with a
                                    Next-Protocol shim header. I can add
                                    text to the LISP-GPE draft to
                                    reflect that.

                                

                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              
Well it could=
 be. Just like
                                  you did with the Nonce field. Make the
                                  Version field the middle 16-bits. So V
                                  and P can be set at the same as well
                                  as N and P.

                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              


                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              
Dino
                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              


                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
Good point, sho=
rtening versions
                                to 8 bits...

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
Seems fine to m=
e.

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
Fabio
                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
_______________=
________________________________

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
lisp mailing li=
st

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
lisp@ietf.org

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
https://www.ietf.=
org/mailman/listinfo/lisp

                            

                          

                        

                      

                    

                    

                      

                        

                          
_________________=
______________________________

                          

                        

                      

                    

                    

                      

                        

                          
lisp mailing list=


                          

                        

                      

                    

                    

                      

                        

                          
lisp@ietf.org

                          

                        

                      

                    

                    

                      

                        

                          
https://www.ietf.or=
g/mailman/listinfo/lisp

                          

                        

                      

                    

                    

                      


                      

                    

                    

                    ____________________________________________=
___

                    lisp mailing list

                    lisp@ietf.org

                    https://www.ietf.org/mailman/listinfo/lisp=


                  

                

              

              _______________________________________________

              lisp mailing list

              lisp@ietf.=
org

              https://w=
ww.ietf.org/mailman/listinfo/lisp

            

          

        

        

      

      

      

      

      
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mai=
lman/listinfo/lisp


    

    

  



_______________________________________________

lisp mailing list

lisp@ietf.org

https://www.ietf.org/mailman/listinfo/lisp





--001a113e54268b1a12055f30f838--


From nobody Thu Nov 30 07:32:34 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9944129447 for ; Thu, 30 Nov 2017 07:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dzJsSiSRF76F for ; Thu, 30 Nov 2017 07:32:30 -0800 (PST)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 12628129439 for ; Thu, 30 Nov 2017 07:32:30 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id e14so3126213pgr.9 for ; Thu, 30 Nov 2017 07:32:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ngtqRpcyYe3WxiQP1Esj8mmVwvU756ILMubjUNhyiHQ=; b=HS4ixvvlc7+tzbBEGHrT3hEmGaRZBnnR/6eQfIPzX5ejOsEkxmaT7ztqj+o6tVKZQC 0NsJoJ8qWyz+2N4zjsEy0DtD9aw0YeYzSp2Qjxn36+KaQ5I4ckOI1EmBdPVgsia90Ct7 7oVHG1SGZ4L6eIYDRXnLaAnJXwbKMsspwpr1/gOXPQF6NQAWI8H6OSFTNeQPrGDubVGj /u67XV/MHpCiUED6fuHCAg5SJF2Nj+xQSsVZ9sdQ7IuptbUeSaJVpQ6B6IHUew2Bxenq xDkFojjNyibWUo1lBbkaim/kQtZu5k4DGR2ugW4dyX+PxczlczHrvsCcjmO47+REZfSu jaFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ngtqRpcyYe3WxiQP1Esj8mmVwvU756ILMubjUNhyiHQ=; b=SQiXNfFTBPE3VLTHNR14hbiQxAc0LHdhMCOzqBs9P9e+PAMiC6o3nN6yAKlN490D2t omP/SgdccFbg2pJtI3yPT7HAd+67EAqY2yChtvumjwLb5RoSqX342IWUQVXYd9TScwLN iQY5Oj9MD+0k6M2XYDHzqOZ3q9hDb+6YbCGk6GZw+QXbHWd79ZIzuJZV0dlwG10rxHoO SU0VNSm63/ZZ1kbU2xqkoteC3bmLzKjr4U9zbclptcVxIPdoAp+BJofCdCIE0W1RZhF7 IDNKN8KcHa1uNP7fP7uzsnYBPmbum0GqiiCYzZnUyuof8T8SJfi1xlcS1zuIVv9epwlf sZgA==
X-Gm-Message-State: AJaThX4gbr/uLPnrUwdze0NqamMaO/IIuBft/ta/BlmnbfL9cqJvGBzj FxaXrrh+d2MTHwHK1/vxOtWX4ykP
X-Google-Smtp-Source: AGs4zMaEX60CDiZNqhlvIOKFg7xCwS5cMb4/POwy1Nm+rZEvN09uzFtZU/nBzySLP9LoUZNF2e+Q8A==
X-Received: by 10.99.149.12 with SMTP id p12mr2619995pgd.381.1512055949358; Thu, 30 Nov 2017 07:32:29 -0800 (PST)
Received: from ?IPv6:2603:3024:151c:55f0:c02c:4473:52ce:5ba7? ([2603:3024:151c:55f0:c02c:4473:52ce:5ba7]) by smtp.gmail.com with ESMTPSA id u13sm7278839pgb.68.2017.11.30.07.32.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 07:32:28 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-BCFC7E06-A04F-412B-A5F7-41B1C662F754
Mime-Version: 1.0 (1.0)
From: Dino Farinacci 
X-Mailer: iPhone Mail (15B202)
In-Reply-To: 
Date: Thu, 30 Nov 2017 07:32:27 -0800
Cc: =?utf-8?Q?Albert_L=C3=B3pez?= , "lisp@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>  <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>    <13f18cab-7017-0af3-6da6-074aed8cb24f@ac.upc.edu> 
To: Albert Cabellos 
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 15:32:33 -0000

--Apple-Mail-BCFC7E06-A04F-412B-A5F7-41B1C662F754
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1 here too. I can do an implantation so I can interoperate with the other i=
mplementations.=20

Dino

> On Nov 30, 2017, at 2:46 AM, Albert Cabellos  w=
rote:
>=20
> Hi all
>=20
> Support proposed 6830bis extension.
>=20
> This is indeed implmemented in OOR.
>=20
> Albert
>=20
>> On Thu, Nov 30, 2017 at 9:47 AM, Albert L=C3=B3pez  wr=
ote:
>> +1 =20
>>=20
>> I also support extending RFC 6830bis as suggested. We have an initial imp=
lementation of LISP-GPE in OOR and we think this extension could be really u=
seful.
>>=20
>> Albert L=C3=B3pez
>>=20
>>=20
>>=20
>> El 30/11/17 a les 07:32, Florin Coras ha escrit:
>>> +1
>>>=20
>>> The LISP implementation in FD.io VPP makes use of it to distinguish betw=
een Ethernet, IP and NSH payloads.=20
>>>=20
>>> Florin
>>>=20
>>>> On Nov 29, 2017, at 10:20 PM, Victor Moreno (vimoreno)  wrote:
>>>>=20
>>>> I=E2=80=99m strongly supportive of this proposal as it completes the ne=
cessary specifications to support the L2 services proposed in the eid-mobili=
ty draft. =20
>>>>=20
>>>> Victor
>>>>=20
>>>> On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino)  wr=
ote:
>>>>=20
>>>>> sounds good.
>>>>>=20
>>>>> Fabio
>>>>>=20
>>>>>> On 11/29/17 3:13 PM, Dino Farinacci wrote:
>>>>>> I=E2=80=99d also add before the last sentence:
>>>>>>=20
>>>>>> If the N-bit and V-bit are 0 when the P-bit is set, the middle 16-bit=
s are set to 0.
>>>>>>=20
>>>>>> Dino
>>>>>>=20
>>>>>>> On Nov 29, 2017, at 3:07 PM, Fabio Maino  wrote:
>>>>>>>=20
>>>>>>> On 11/29/17 3:05 PM, Dino Farinacci wrote:
>>>>>>>> How about this wording Fabio:
>>>>>>>>=20
>>>>>>>> P: The P-bit is the Next Protocol bit. When set, the low-order 8 bi=
ts is used for the Next Protocol field. When the N-bit is also set with the P=
-bit, the Nonce field is the middle 16 bits. When the V bit is also set with=
 the P-bit, the Version field is the middle 16 bits. Details on Next Protoco=
l field usage are described in [draft-lewis-lisp-gpe].
>>>>>>>>=20
>>>>>>>> Comments?
>>>>>>> much better.
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> Fabio
>>>>>>>=20
>>>>>>>> Dino
>>>>>>>>=20
>>>>>>>>> On Nov 29, 2017, at 2:49 PM, Fabio Maino  wrote:=

>>>>>>>>>=20
>>>>>>>>> Definition of the P bit will look like:
>>>>>>>>>=20
>>>>>>>>>    P: The P-bit is the Next Protocol bit. When this bit is set to
>>>>>>>>>       1, Nonce length, when used, is limited to 16 bits and the le=
nght
>>>>>>>>>       of the Source and Destination Map-Version fields, when used,=
 is limited
>>>>>>>>>       to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.=

>>>>>>>>>       The P-bit is set to 1 to indicate the presence of the 8 bit N=
ext Protocol field encoded as:
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Do you think the overall proposed extension makes sense?
>>>>>>>>>=20
>>>>>>>>> Thanks,
>>>>>>>>> Fabio
>>>>>>>>>=20
>>>>>>>>> On 11/29/17 2:38 PM, Fabio Maino wrote:
>>>>>>>>>> On 11/29/17 2:36 PM, Dino Farinacci wrote:
>>>>>>>>>>>> The use of the P-bit is not compatible with the Map-Versioning f=
eature, but an equivalent function can be specified (if needed) with a Next-=
Protocol shim header. I can add text to the LISP-GPE draft to reflect that.
>>>>>>>>>>> Well it could be. Just like you did with the Nonce field. Make t=
he Version field the middle 16-bits. So V and P can be set at the same as we=
ll as N and P.
>>>>>>>>>>>=20
>>>>>>>>>>> Dino
>>>>>>>>>>>=20
>>>>>>>>>> Good point, shortening versions to 8 bits...
>>>>>>>>>>=20
>>>>>>>>>> Seems fine to me.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Fabio
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=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
>>>>>=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
>>>=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
>>=20
>=20
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

--Apple-Mail-BCFC7E06-A04F-412B-A5F7-41B1C662F754
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


+1 here too. I can do an im=
plantation so I can interoperate with the other implementations. 
=


Dino

On Nov 30, 2017, at 2:46 AM, Albert C=
abellos <albert.cabellos@gma=
il.com> wrote:

Hi all

Support proposed 6830bis extension.

This is indeed implmemented in OOR.

Albert

On Thu, Nov 30, 2017 at 9:47 AM, Albert L=C3=B3pez <<=
a href=3D"mailto:alopez@ac.upc.edu" target=3D"_blank">alopez@ac.upc.edu&=
gt; wrote:

 =20
   =20
 =20
  

    
+1  

      

      I also support extending RFC 6830bis as suggested. We have an
      initial implementation of LISP-GPE in OOR and we think this
      extension could be really useful.

      

      Albert L=C3=B3pez

      

      

      

      El 30/11/17 a les 07:32, Florin Coras ha escrit:

    

    

     =20
      +1
      


      

      
The LISP implementation in FD.io VPP makes use of it
        to distinguish between Ethernet, IP and NSH payloads. 

      


      

      
Florin

        


          

            
On Nov 29, 2017, at 10:20 PM, Victor Moreno
              (vimoreno) <vimoreno@cisco.com>
              wrote:

            

            

             =20
              

                I=E2=80=99m strongly supportive of this proposal as it compl=
etes
                the necessary specifications to support the L2 services
                proposed in the eid-mobility draft.  

                

                
Victor

                


                  On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <fmaino@cisco.com>
                  wrote:

                  

                

                

                  
sounds good.

                    

                    Fabio

                    

                    On 11/29/17 3:13 PM, Dino Farinacci
                      wrote:

                    
I=E2=80=99d
                        also add before the last sentence:

                    

                    


                    

                    
If
                        the N-bit and V-bit are 0 when the P-bit is set,
                        the middle 16-bits are set to 0.

                    

                    


                    

                    
Dino

                    

                    


                    

                    

                      
On
                          Nov 29, 2017, at 3:07 PM, Fabio Maino <fmaino@cisco.com>
                          wrote:

                      

                    

                    

                      


                      

                    

                    

                      
On
                          11/29/17 3:05 PM, Dino Farinacci wrote:
=

                      

                    

                    

                      

                        
How
                            about this wording Fabio:

                        

                      

                    

                    

                      

                        


                        

                      

                    

                    

                      

                        
P:
                            The P-bit is the Next Protocol bit. When
                            set, the low-order 8 bits is used for the
                            Next Protocol field. When the N-bit is also
                            set with the P-bit, the Nonce field is the
                            middle 16 bits. When the V bit is also set
                            with the P-bit, the Version field is the
                            middle 16 bits. Details on Next Protocol
                            field usage are described in
                            [draft-lewis-lisp-gpe].

                        

                      

                    

                    

                      

                        


                        

                      

                    

                    

                      

                        
Comments?
=

                        

                      

                    

                    

                      
much
                          better.

                      

                    

                    

                      


                      

                    

                    

                      
Thanks,

                      

                    

                    

                      
Fabio

                      

                    

                    

                      


                      

                    

                    

                      

                        
Dino

                        

                      

                    

                    

                      

                        


                        

                      

                    

                    

                      

                        

                          
On Nov 29, 2017, a=
t 2:49 PM,
                              Fabio Maino <fmaino@cisco.com>
                              wrote:

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
Definition of the P=
 bit will look
                              like:

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
   =
P: The P-bit is the Next
                              Protocol bit. When this bit is set to
                          

                        

                      

                    

                    

                      

                        

                          
   =
   1, Nonce length, when used,
                              is limited to 16 bits and the lenght
                          

                        

                      

                    

                    

                      

                        

                          
   =
   of the Source and
                              Destination Map-Version fields, when used,
                              is limited

                          

                        

                      

                    

                    

                      

                        

                          
   =
   to 8 bits. Refer to
                              [draft-lewis-lisp-gpe] for more details.

                          

                        

                      

                    

                    

                      

                        

                          
   =
   The P-bit is set to 1 to
                              indicate the presence of the 8 bit Next
                              Protocol field encoded as:

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
Do you think the o=
verall proposed
                              extension makes sense?

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
Thanks,
=

                          

                        

                      

                    

                    

                      

                        

                          
Fabio

                          

                        

                      

                    

                    

                      

                        

                          


                          

                        

                      

                    

                    

                      

                        

                          
On 11/29/17 2:38 P=
M, Fabio Maino
                              wrote:

                          

                        

                      

                    

                    

                      

                        

                          

                            
On 11/29/17 2:36=
 PM, Dino
                                Farinacci wrote:

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              

                                
The use of t=
he P-bit is not
                                    compatible with the Map-Versioning
                                    feature, but an equivalent function
                                    can be specified (if needed) with a
                                    Next-Protocol shim header. I can add
                                    text to the LISP-GPE draft to
                                    reflect that.

                                

                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              
Well it could b=
e. Just like
                                  you did with the Nonce field. Make the
                                  Version field the middle 16-bits. So V
                                  and P can be set at the same as well
                                  as N and P.

                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              


                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              
Dino
                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            

                              


                              

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
Good point, shor=
tening versions
                                to 8 bits...

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
Seems fine to me=
.

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
Fabio
=

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            


                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
________________=
_______________________________

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
lisp mailing lis=
t

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
lisp@ietf.org

                            

                          

                        

                      

                    

                    

                      

                        

                          

                            
https://www.ietf.or=
g/mailman/listinfo/lisp

                            

                          

                        

                      

                    

                    

                      

                        

                          
__________________=
_____________________________

                          

                        

                      

                    

                    

                      

                        

                          
lisp mailing list<=
/span>

                          

                        

                      

                    

                    

                      

                        

                          
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.o=
rg

              https://www.i=
etf.org/mailman/listinfo/lisp

            

          

        

        

      

      

      

      

      
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailm=
an/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
=

--Apple-Mail-BCFC7E06-A04F-412B-A5F7-41B1C662F754--


From nobody Thu Nov 30 07:36:55 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0046512878D for ; Thu, 30 Nov 2017 07:36:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 1RNNB-cdU0VU for ; Thu, 30 Nov 2017 07:36:52 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3214B128A32 for ; Thu, 30 Nov 2017 07:36:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20366; q=dns/txt; s=iport; t=1512056212; x=1513265812; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Tv96k4guqiJ8GjCEw6Hr1a+fOndO7s41or+BNeOUl+8=; b=GmyV27fNzo7HkR9+iCGNBWl4dypyffMiXYKF6pm+muCyYDW1WVlVBHcy PEADYC3YxlHA1LGdmJcuveOf/YdgjETuqfog082tGJa5ZfW/+f6zgphVm AlMLUkf4xpYkJHyLA9lFfdlKUaR4b+OU5/ZkBgF7Qvpm77FbfS+EMRKMp Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAAACJSBa/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuJweDeIogjnKBfZErhUuCEQojgTkBg14CGoUHPxgBAQE?= =?us-ascii?q?BAQEBAQFrHQuFHwEBAQQjClwCAQgRAwECKAMCAgIwFAkIAgQTCIk2ZBCmNYInJ?= =?us-ascii?q?opAAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDQYIJgVaBaYMrgUmDMD4JFoJfgmM?= =?us-ascii?q?FolsCh3KNFIIfkT2KOYJBiR4CERkBgTkBHzmBUW8VgmOEVXiHPIEzgRQBAQE?=
X-IronPort-AV: E=Sophos; i="5.45,341,1508803200"; d="scan'208,217"; a="37941473"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2017 15:36:51 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vAUFaprA025282 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 30 Nov 2017 15:36:51 GMT
Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 30 Nov 2017 09:36:50 -0600
Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1320.000; Thu, 30 Nov 2017 09:36:50 -0600
From: "Frank Brockners (fbrockne)" 
To: "lisp@ietf.org" 
Thread-Topic: [lisp] RFC6830bis and multiprotocol support
Thread-Index: AQHTaXpzYekKQRtar0ydwRpW9frRFqMtDZHg
Date: Thu, 30 Nov 2017 15:36:50 +0000
Message-ID: <3be13180c987450a9b625e7143fe0225@XCH-RCD-008.cisco.com>
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <7cf2e668-ca68-8ae4-054e-02b9f4f5b644@cisco.com>
In-Reply-To: <7cf2e668-ca68-8ae4-054e-02b9f4f5b644@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.117.10]
Content-Type: multipart/alternative; boundary="_000_3be13180c987450a9b625e7143fe0225XCHRCD008ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 15:36:54 -0000

--_000_3be13180c987450a9b625e7143fe0225XCHRCD008ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RmFiaW8sDQoNCmV4dGVuZGluZyBMSVNQIGVuY2FwIHdpdGggbXVsdGlwcm90b2NvbCBzdXBwb3J0
IHdvdWxkIGJlIGJlbmVmaWNpYWwuIEl0IHdvdWxkIGFsc28gZ2l2ZSB1cyBhIHdheSB0byBpbnRy
b2R1Y2UgSU9BTSBpbnRvIExJU1Ag4oCTIGFsb25nIHZlcnkgc2ltaWxhciBsaW5lcyB0byB3aGF0
IHdlIGRpc2N1c3NlZCBpbiBTaW5nYXBvcmUgYXMgcGFydCBvZiB0aGUgSU9BTSB3aXRoIFZYTEFO
LUdQRSBlbmNhcCBkaXNjdXNzaW9uLg0KDQpUaGFua3MsIEZyYW5rDQoNClN1YmplY3Q6DQoNClts
aXNwXSBSRkM2ODMwYmlzIGFuZCBtdWx0aXByb3RvY29sIHN1cHBvcnQNCg0KRGF0ZToNCg0KV2Vk
LCAyOSBOb3YgMjAxNyAxNDozMjo0MCAtMDgwMA0KDQpGcm9tOg0KDQpGYWJpbyBNYWlubyA8Zm1h
aW5vQGNpc2NvLmNvbT48bWFpbHRvOmZtYWlub0BjaXNjby5jb20+DQoNClRvOg0KDQpsaXNwQGll
dGYub3JnPG1haWx0bzpsaXNwQGlldGYub3JnPiA8bGlzcEBpZXRmLm9yZz48bWFpbHRvOmxpc3BA
aWV0Zi5vcmc+DQoNCg0KDQpJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCBhIHdheSB0byBhZGRyZXNz
IG11dGlwcm90b2NvbCBzdXBwb3J0IGluIFJGQzY4MzBiaXMsIHRoYXQgbWF5IGFkZHJlc3Mgd2hh
dCB3YXMgZGlzY3Vzc2VkIGluIFNpbmdhcG9yZS4NCg0KVGhpcyBpcyBiYXNlZCBvbiB1c2luZyB0
aGUgbGFzdCByZXNlcnZlZCBiaXQgaW4gdGhlIExJU1AgaGVhZGVyIGFzIFAgYml0IHRvIGluZGlj
YXRlIHN1cHBvcnQgZm9yIG11bHRpcHJvdG9jb2wgZW5jYXBzdWxhdGlvbiwgYXMgc3BlY2lmaWVk
IGluIHRoZSBMSVNQLUdQRSBkcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWxld2lzLWxpc3AtZ3BlKS4NCg0KVGhlIGhlYWRlciwgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24g
NS4xLCB3b3VsZCBsb29rIGxpa2U6DQoNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgTCAgIHxOfEx8RXxW
fEl8UHxLfEt8ICAgICAgICAgICAgTm9uY2UvTWFwLVZlcnNpb24vTmV4dC1Qcm90b2NvbCAgICB8
DQogICBJIFwgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSsNCiAgIFMgLyB8ICAgICAgICAgICAgICAgICBJbnN0YW5jZSBJRC9M
b2NhdG9yLVN0YXR1cy1CaXRzICAgICAgICAgICAgICAgfA0KICAgUCAgICstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCmFu
ZCB0aGUgdGV4dCBpbiBzZWN0aW9uIDUuMyB0aGF0IHJlc2VydmVzIHRoZSA2dGggYml0IHdvdWxk
IGJlIHJlcGxhY2VkIGJ5Og0KDQogICBQOiBUaGUgUC1iaXQgaXMgdGhlIE5leHQgUHJvdG9jb2wg
Yml0LiBXaGVuIHRoaXMgYml0IGlzIHNldCB0bw0KICAgICAgMSwgdGhlIFYtYml0IE1VU1QgYmUg
c2V0IHRvIDAgYW5kIHRoZSBOb25jZSBsZW5ndGgsIHdoZW4gdXNlZCwgaXMNCiAgICAgIGxpbWl0
ZWQgdG8gMTYgYml0cy4gUmVmZXIgdG8gW2RyYWZ0LWxld2lzLWxpc3AtZ3BlXSBmb3IgbW9yZSBk
ZXRhaWxzLg0KICAgICAgVGhlIFAtYml0IGlzIHNldCB0byAxIHRvIGluZGljYXRlIHRoZSBwcmVz
ZW5jZSBvZiB0aGUgOCBiaXQgTmV4dA0KICAgICAgUHJvdG9jb2wgZmllbGQgZW5jb2RlZCBhczoN
CiAgICAgeCB4IHggMCB4IDEgeCB4DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8TnxMfEV8VnxJfFB8S3xL
fCAgICAgICAgICAgTm9uY2UgICAgICAgICAgICAgICB8IE5leHQtUHJvdG9jb2wgfA0KICAgICst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rDQogICAgfCAgICAgICAgICAgICAgICAgSW5zdGFuY2UgSUQvTG9jYXRvci1TdGF0dXMt
Qml0cyAgICAgICAgICAgICAgIHwNCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCkkgd2lsbCBoYXZlIHRvIHJl
ZnJlc2ggdGhlIExJU1AtR1BFIGRyYWZ0LCBhbmQgcmVmbGVjdCB0aGUgYWxsb2NhdGlvbnMgb2Yg
dGhlIEtLIGJpdHMgYWNjb3JkaW5nIHRvIFJGQzgwNjEgYW5kIE5vbmNlLiBPbmUgb2YgdGhlIEsg
Yml0cyB3YXMgdXNlZCBieSBMSVNQLUdQRSB0byBpbmRpY2F0ZSBPQU0gcGFja2V0cywgYnV0IHRo
YXQgc2FtZSBmdW5jdGlvbmFsaXR5IGNhbiBiZSBkb25lIHVzaW5nIHRoZSBOZXh0LVByb3RvY29s
IGZpZWxkLg0KDQpUaGUgdXNlIG9mIHRoZSBQLWJpdCBpcyBub3QgY29tcGF0aWJsZSB3aXRoIHRo
ZSBNYXAtVmVyc2lvbmluZyBmZWF0dXJlLCBidXQgYW4gZXF1aXZhbGVudCBmdW5jdGlvbiBjYW4g
YmUgc3BlY2lmaWVkIChpZiBuZWVkZWQpIHdpdGggYSBOZXh0LVByb3RvY29sIHNoaW0gaGVhZGVy
LiBJIGNhbiBhZGQgdGV4dCB0byB0aGUgTElTUC1HUEUgZHJhZnQgdG8gcmVmbGVjdCB0aGF0Lg0K
DQpUaGlzIHdvdWxkIGFkZHJlc3MgdGhlIG11bHRpcHJvdG9jb2wgd29ya2luZyBpdGVtIGluY2x1
ZGVkIGluIHRoZSBjdXJyZW50IGNoYXJ0ZXIuDQoNCkkgY2FuIHZlcnkgcXVpY2tseSB1cGRhdGUg
dGhlIExJU1AtR1BFIGRyYWZ0IHRvIHJlZmxlY3QgdGhpcywgYnV0IEkgd2FudGVkIHRvIGhlYXIg
d2hhdCB0aGUgZ3JvdXAgdGhpbmtzIGZpcnN0Lg0KDQpUaGFua3MsDQpGYWJpbw0KDQoNCg0KDQoN
Cg0KDQo=

--_000_3be13180c987450a9b625e7143fe0225XCHRCD008ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l
dyBcLHNlcmlmIjt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
O30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIi
Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4w
cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7
fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn
aW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxp
Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN
Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30N
CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K
CWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIy
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAy
LjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K
LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl
eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6
ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t
Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2
bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+RmFiaW8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUyI+ZXh0ZW5kaW5nIExJU1AgZW5jYXAgd2l0aCBtdWx0aXByb3RvY29sIHN1cHBv
cnQgd291bGQgYmUgYmVuZWZpY2lhbC4gSXQgd291bGQgYWxzbyBnaXZlIHVzIGEgd2F5IHRvIGlu
dHJvZHVjZSBJT0FNIGludG8NCiBMSVNQIOKAkyBhbG9uZyB2ZXJ5IHNpbWlsYXIgbGluZXMgdG8g
d2hhdCB3ZSBkaXNjdXNzZWQgaW4gU2luZ2Fwb3JlIGFzIHBhcnQgb2YgdGhlIElPQU0gd2l0aCBW
WExBTi1HUEUgZW5jYXAgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLCBGcmFuazxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt
YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRi
b2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNt
IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9
InRleHQtYWxpZ246cmlnaHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJqZWN0Og0KPG86cD48
L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw
Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5bbGlzcF0g
UkZDNjgzMGJpcyBhbmQgbXVsdGlwcm90b2NvbCBzdXBwb3J0PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0i
cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp
Z2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkRhdGU6
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow
Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
PldlZCwgMjkgTm92IDIwMTcgMTQ6MzI6NDAgLTA4MDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk
aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi
IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbToNCjxv
OnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw
Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RmFi
aW8gTWFpbm8gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpmbWFpbm9AY2lzY28uY29tIj4mbHQ7Zm1h
aW5vQGNpc2NvLmNvbSZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N
Cjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWdu
OnJpZ2h0Ij48Yj5UbzogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk
ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFp
bHRvOmxpc3BAaWV0Zi5vcmciPmxpc3BAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpsaXNw
QGlldGYub3JnIj4NCiZsdDtsaXNwQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv
dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SSB3b3Vs
ZCBsaWtlIHRvIHN1Z2dlc3QgYSB3YXkgdG8gYWRkcmVzcyBtdXRpcHJvdG9jb2wgc3VwcG9ydCBp
biBSRkM2ODMwYmlzLCB0aGF0IG1heSBhZGRyZXNzIHdoYXQgd2FzIGRpc2N1c3NlZCBpbiBTaW5n
YXBvcmUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgaXMgYmFzZWQgb24gdXNpbmcgdGhlIGxh
c3QgcmVzZXJ2ZWQgYml0IGluIHRoZSBMSVNQIGhlYWRlciBhcyBQIGJpdCB0byBpbmRpY2F0ZSBz
dXBwb3J0IGZvciBtdWx0aXByb3RvY29sIGVuY2Fwc3VsYXRpb24sIGFzIHNwZWNpZmllZCBpbiB0
aGUgTElTUC1HUEUgZHJhZnQgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1sZXdpcy1saXNwLWdwZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxl
d2lzLWxpc3AtZ3BlPC9hPikuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBoZWFkZXIsIGFzIHNw
ZWNpZmllZCBpbiBzZWN0aW9uIDUuMSwgd291bGQgbG9vayBsaWtlOiA8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcLHNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m
IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz
Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m
IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz
Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsiPjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXCxzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IEwm
bmJzcDsmbmJzcDsgfE58THxFfFZ8SXw8L3NwYW4+PC90dD48L3NwYW4+PHR0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2VyaWYm
cXVvdDs7Y29sb3I6I0NDMDAwMCI+UDwvc3Bhbj48L3R0Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcLHNlcmlmJnF1b3Q7Ij58
S3xLfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KICZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO05vbmNlL01hcC1WZXJzaW9uPC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2Vy
aWYmcXVvdDs7Y29sb3I6I0NDMDAwMCI+L05leHQtUHJvdG9jb2w8L3NwYW4+PC90dD48dHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcg
XCxzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC90dD48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcLHNlcmlm
JnF1b3Q7Ij48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3IFwsc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBJIFwgJiM0MzstJiM0MzstJiM0MzstJiM0
MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst
JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0
MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst
JiM0Mzs8L3NwYW4+PC90dD48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBTIC8gfCZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbnN0YW5jZSBJRC9Mb2NhdG9yLVN0YXR1cy1C
aXRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC90dD48YnI+DQo8dHQ+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsiPiZu
YnNwOyZuYnNwOyBQJm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj
NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7
LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj
NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFu
PjwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PGJyPg0KPHR0PmFuZCB0aGUg
dGV4dCBpbiBzZWN0aW9uIDUuMyB0aGF0IHJlc2VydmVzIHRoZSA2dGggYml0IHdvdWxkIGJlIHJl
cGxhY2VkIGJ5OiA8L3R0Pg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwO1A6IFRoZSBQ
LWJpdCBpcyB0aGUgTmV4dCBQcm90b2NvbCBiaXQuIFdoZW4gdGhpcyBiaXQgaXMgc2V0IHRvPC9z
cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcgXCxzZXJpZiZxdW90OyI+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyBcLHNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgMSwgdGhlIFYtYml0IE1VU1QgYmUgc2V0IHRvIDAgYW5kIHRoZSBOb25jZSBs
ZW5ndGgsIHdoZW4gdXNlZCwgaXMNCjwvc3Bhbj48L3R0Pjxicj4NCjx0dD48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXCxzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpbWl0ZWQgdG8gMTYgYml0cy4gUmVmZXIgdG88L3NwYW4+IFtk
cmFmdC1sZXdpcy1saXNwLWdwZV0gZm9yIG1vcmUgZGV0YWlscy4NCjwvdHQ+PC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7LHNlcmlmIj48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBQ
LWJpdCBpcyBzZXQgdG8gMSB0byBpbmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgdGhlIDggYml0IE5l
eHQgPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByb3RvY29s
IGZpZWxkIGVuY29kZWQgYXM6IDwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48dHQ+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXCxzZXJpZiZx
dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7eCB4IHggMCB4IDEgeCB4PC9zcGFu
PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcgXCxzZXJpZiZxdW90OyI+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyBcLHNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJiM0
MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst
JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0
MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst
JiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PC90dD48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNw
OyZuYnNwOyB8TnxMfEV8VnxJfFB8S3xLfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOb25jZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB8IE5leHQtUHJvdG9jb2wgfDwvc3Bhbj48L3R0Pjxicj4NCjx0dD48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXCxzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj
NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7
LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj
NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjwvdHQ+PGJyPg0KPHR0Pjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcLHNlcmlmJnF1b3Q7Ij4m
bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBJbnN0YW5jZSBJRC9Mb2NhdG9yLVN0YXR1cy1CaXRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHw8L3NwYW4+PC90dD48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3IFwsc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQz
Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m
IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz
Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m
IzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48L3R0Pjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj5JIHdp
bGwgaGF2ZSB0byByZWZyZXNoIHRoZSBMSVNQLUdQRSBkcmFmdCwgYW5kIHJlZmxlY3QgdGhlIGFs
bG9jYXRpb25zIG9mIHRoZSBLSyBiaXRzIGFjY29yZGluZyB0byBSRkM4MDYxIGFuZCBOb25jZS4g
T25lIG9mIHRoZSBLIGJpdHMgd2FzIHVzZWQgYnkgTElTUC1HUEUgdG8gaW5kaWNhdGUgT0FNIHBh
Y2tldHMsIGJ1dCB0aGF0IHNhbWUgZnVuY3Rpb25hbGl0eSBjYW4gYmUgZG9uZSB1c2luZyB0aGUg
TmV4dC1Qcm90b2NvbCBmaWVsZC4NCjxicj4NCjxicj4NClRoZSB1c2Ugb2YgdGhlIFAtYml0IGlz
IG5vdCBjb21wYXRpYmxlIHdpdGggdGhlIE1hcC1WZXJzaW9uaW5nIGZlYXR1cmUsIGJ1dCBhbiBl
cXVpdmFsZW50IGZ1bmN0aW9uIGNhbiBiZSBzcGVjaWZpZWQgKGlmIG5lZWRlZCkgd2l0aCBhIE5l
eHQtUHJvdG9jb2wgc2hpbSBoZWFkZXIuIEkgY2FuIGFkZCB0ZXh0IHRvIHRoZSBMSVNQLUdQRSBk
cmFmdCB0byByZWZsZWN0IHRoYXQuDQo8YnI+DQo8YnI+DQpUaGlzIHdvdWxkIGFkZHJlc3MgdGhl
IG11bHRpcHJvdG9jb2wgd29ya2luZyBpdGVtIGluY2x1ZGVkIGluIHRoZSBjdXJyZW50IGNoYXJ0
ZXIuDQo8YnI+DQo8YnI+DQpJIGNhbiB2ZXJ5IHF1aWNrbHkgdXBkYXRlIHRoZSBMSVNQLUdQRSBk
cmFmdCB0byByZWZsZWN0IHRoaXMsIGJ1dCBJIHdhbnRlZCB0byBoZWFyIHdoYXQgdGhlIGdyb3Vw
IHRoaW5rcyBmaXJzdC4NCjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpGYWJpbzxicj4NCjxicj4N
Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_3be13180c987450a9b625e7143fe0225XCHRCD008ciscocom_--


From nobody Thu Nov 30 08:32:32 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA61292D3 for ; Thu, 30 Nov 2017 08:32:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gak_tqLuNoUz for ; Thu, 30 Nov 2017 08:32:28 -0800 (PST)
Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::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 3C11B128B93 for ; Thu, 30 Nov 2017 08:32:28 -0800 (PST)
Received: by mail-pl0-x22e.google.com with SMTP id s10so4533793plj.5 for ; Thu, 30 Nov 2017 08:32:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PR7BVxOFqb0Y3QnTXeM61Pb+BChqvdSjohvbbcaCahw=; b=NE/Dmtxf1pR1+aLf68SM1uxTQ+9wOpayllfd+O1CpN/OqedobfqjkWIq2ZjlduGIax U073FwZKzu+lZOHy1s49NA7Q0JSWWGX93Q0a7TljCFcsbtaTJPMHKI6EB79yvRnKYn41 LKDb/va+iL1E1gWLvuezby2dg+xi3F+RRrPyOUrT/sVfxH3mSqlVuzCVbCpJVFl4DBuu XClqV+UaEMA2lVUWNOQGruvbQZf8IIo2N6cwhZHjdbn/jnhwU6tQmB0/3znRjiZ0Z0RH MAAKDBL/ytG8CN3pghtCAq4v69ibasM6eBo6/i3UPlok0S5oPF6csfbdL9My1H9xDCnC IOMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PR7BVxOFqb0Y3QnTXeM61Pb+BChqvdSjohvbbcaCahw=; b=Q2Gkxn7APogDoggzWnMHvvq28UvB84egb27S3bvz/WXSr9jIf8eSB7u4h80t8G27fj b16/HM9V7+1NMkb9M2dMi2p+Brp8Y181CRs7Wwx9kbRZ0oz2F65cBzM8fum/dkBLFQRk 1mik5OSZ6hL6WBP0qJuQmWzXLkOnAPnyfIXzNOB7Oa1V5txNyBi6Xa/Dj261Lputq6W0 lVgdknDcxiM166en1/5CbndW92MOIw7lwJO6vo7ShoT1fxEGRM1IPiqIFkqA5Zv9VLsd WR3ZP87e9p044dMAj09pe3fsf1PK76X/nd1JQNUdQ2FusHTF82h9UtBh/UX7vxsMxiKs Y30Q==
X-Gm-Message-State: AJaThX7we9ZupBRhmi0ApofWlaMaVwOTaBJlQmBxehd+Q/GrWhfQdLB2 m3Ho8oWqoVO7MHQrYIp7tfF/5YGD
X-Google-Smtp-Source: AGs4zMYU4JDMyZ2vkIESpSPQuPEc2+BXBEojfHiRfANYsLkbA+TkM3xBQY5CEiJWz4cnPjislrLz+A==
X-Received: by 10.84.165.171 with SMTP id y40mr3275821pla.362.1512059547560; Thu, 30 Nov 2017 08:32:27 -0800 (PST)
Received: from ?IPv6:2603:3024:151c:55f0:c02c:4473:52ce:5ba7? ([2603:3024:151c:55f0:c02c:4473:52ce:5ba7]) by smtp.gmail.com with ESMTPSA id 62sm7663791pgh.31.2017.11.30.08.32.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 08:32:26 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-D45357D8-CAEA-4287-B834-41FFC3EDB0F0
Mime-Version: 1.0 (1.0)
From: Dino Farinacci 
X-Mailer: iPhone Mail (15B202)
In-Reply-To: <3be13180c987450a9b625e7143fe0225@XCH-RCD-008.cisco.com>
Date: Thu, 30 Nov 2017 08:32:26 -0800
Cc: "lisp@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: <779AC172-FE1C-45B0-AA0C-35B8438CE787@gmail.com>
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <7cf2e668-ca68-8ae4-054e-02b9f4f5b644@cisco.com> <3be13180c987450a9b625e7143fe0225@XCH-RCD-008.cisco.com>
To: "Frank Brockners (fbrockne)" 
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 16:32:31 -0000

--Apple-Mail-D45357D8-CAEA-4287-B834-41FFC3EDB0F0
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I strongly suggest that the proponents for the P-bit do not couple this with=
 IOAM because there is a lot more machinery to be described which may be too=
 late for 6830bis.=20

When RFC 8061 LISP-crypto was written, the authors anticipated the P-bit and=
 hence why the two low-order bits in the flags filed was selected.=20

We are now out of flag bits.=20

Dino

> On Nov 30, 2017, at 7:36 AM, Frank Brockners (fbrockne)  wrote:
>=20
> Fabio,
> =20
> extending LISP encap with multiprotocol support would be beneficial. It wo=
uld also give us a way to introduce IOAM into LISP =E2=80=93 along very simi=
lar lines to what we discussed in Singapore as part of the IOAM with VXLAN-G=
PE encap discussion.
> =20
> Thanks, Frank
> =20
> Subject:
> [lisp] RFC6830bis and multiprotocol support
> Date:
> Wed, 29 Nov 2017 14:32:40 -0800
> From:
> Fabio Maino 
> To:
> lisp@ietf.org 
> =20
>=20
> I would like to suggest a way to address mutiprotocol support in RFC6830bi=
s, that may address what was discussed in Singapore.
>=20
> This is based on using the last reserved bit in the LISP header as P bit t=
o indicate support for multiprotocol encapsulation, as specified in the LISP=
-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).
>=20
> The header, as specified in section 5.1, would look like:
>=20
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    L   |N|L|E|V|I|P|K|K|            Nonce/Map-Version/Next-Protocol    |
>    I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    S / |                 Instance ID/Locator-Status-Bits               |
>    P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>=20
> and the text in section 5.3 that reserves the 6th bit would be replaced by=
:
>=20
>    P: The P-bit is the Next Protocol bit. When this bit is set to
>       1, the V-bit MUST be set to 0 and the Nonce length, when used, is=20=

>       limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details=
.=20
>       The P-bit is set to 1 to indicate the presence of the 8 bit Next=20
>       Protocol field encoded as:
>=20
>      x x x 0 x 1 x x
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |N|L|E|V|I|P|K|K|           Nonce               | Next-Protocol |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                 Instance ID/Locator-Status-Bits               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>=20
> I will have to refresh the LISP-GPE draft, and reflect the allocations of t=
he KK bits according to RFC8061 and Nonce. One of the K bits was used by LIS=
P-GPE to indicate OAM packets, but that same functionality can be done using=
 the Next-Protocol field.=20
>=20
> The use of the P-bit is not compatible with the Map-Versioning feature, bu=
t an equivalent function can be specified (if needed) with a Next-Protocol s=
him header. I can add text to the LISP-GPE draft to reflect that.=20
>=20
> This would address the multiprotocol working item included in the current c=
harter.=20
>=20
> I can very quickly update the LISP-GPE draft to reflect this, but I wanted=
 to hear what the group thinks first.=20
>=20
> Thanks,
> Fabio
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

--Apple-Mail-D45357D8-CAEA-4287-B834-41FFC3EDB0F0
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I strongly suggest that the=
 proponents for the P-bit do not couple this with IOAM because there is a lo=
t more machinery to be described which may be too late for 6830bis. 

When RFC 8061 LISP-crypto was written, the authors an=
ticipated the P-bit and hence why the two low-order bits in the flags filed w=
as selected. 

We are now out of flag bits.&nbs=
p;

Dino

On Nov 30, 2017, at 7:36 AM, =
Frank Brockners (fbrockne) <fbrockn=
e@cisco.com> wrote:











Fabio,<=
/o:p>


 <=
/o:p>


extending LISP encap with multiprotocol support would be beneficial. It w=
ould also give us a way to introduce IOAM into
 LISP =E2=80=93 along very similar lines to what we discussed in Singapore a=
s part of the IOAM with VXLAN-GPE encap discussion.


 


Thanks, Frank




 








Subject:





[lisp] RFC6830bis and multiproto=
col support








Date:





Wed, 29 Nov 2017 14:32:40 -0800<=
o:p>








From:





Fabio Maino <fmaino@cisco.com>








To: 




lisp@ietf.org 
<lisp@ietf.org>








 


I would like to suggest a way to address mutiprotocol support in RFC6830b=
is, that may address what was discussed in Singapore.



This is based on using the last reserved bit in the LISP header as P bit t=
o indicate support for multiprotocol encapsulation, as specified in the LISP=
-GPE draft (htt=
ps://tools.ietf.org/html/draft-lewis-lisp-gpe).



The header, as specified in section 5.1, would look like: 
=


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
br>
  =
 L   |N|L|E|V|I|P|K|K|       
     Nonce/Map-Version/Ne=
xt-Protocol    |

  =
 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  =
 S / |           &nbs=
p;     Instance ID/Locator-Status-Bits   =
            |<=
/tt>

  =
 P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+




and the text in section 5.3 that reserves the 6th bit would be replaced b=
y: 



   P: The P-bit is the Next Pr=
otocol bit. When this bit is set to

  =
    1, the V-bit MUST be set to 0 and the Nonce length, when u=
sed, is


  =
    limited to 16 bits. Refer to [draft-lewis-lisp-gpe=
] for more details.


      The P-bit is set to 1 to indicate the pre=
sence of the 8 bit Next 

      Protocol field encoded as: 


   =
;  x x x 0 x 1 x x

  =
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  =
  |N|L|E|V|I|P|K|K|        &nbs=
p;  Nonce          &n=
bsp;    | Next-Protocol |

  =
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  =
  |           &n=
bsp;     Instance ID/Locator-Status-Bits  &nbs=
p;            |

  =
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





I will have to refresh the LISP-GPE draft, and reflect the allocation=
s of the KK bits according to RFC8061 and Nonce. One of the K bits was used b=
y LISP-GPE to indicate OAM packets, but that same functionality can be done u=
sing the Next-Protocol field.




The use of the P-bit is not compatible with the Map-Versioning feature, but a=
n equivalent function can be specified (if needed) with a Next-Protocol shim=
 header. I can add text to the LISP-GPE draft to reflect that.




This would address the multiprotocol working item included in the current ch=
arter.




I can very quickly update the LISP-GPE draft to reflect this, but I wanted t=
o hear what the group thinks first.




Thanks,

Fabio
























____________________=
___________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman=
/listinfo/lisp
=

--Apple-Mail-D45357D8-CAEA-4287-B834-41FFC3EDB0F0--


From nobody Thu Nov 30 10:46:58 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71249126CC4 for ; Thu, 30 Nov 2017 10:46:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 LPcFGnGjrEvE for ; Thu, 30 Nov 2017 10:46:55 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E6612945D for ; Thu, 30 Nov 2017 10:46:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21969; q=dns/txt; s=iport; t=1512067598; x=1513277198; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=mGMUklmc6ouVMbciH/iY5tVNIvCAjoT2W3ytesb7u9s=; b=dWPnfjnrIW6KK++OrBm/BKhOduZ8dUR3q8yr+vTZjTGMzE78wKhiy/WA vRSr0iIlCmPu8zkNRILNyh0f4vuBw/p5D4IRzjWVL7+/XIodK9QatADVJ 3gue1JGe0SXwVT6NZbTyoffvE8hhgoBO+GUhFxlRFmqayFPvRaZDXjXqZ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAABjUSBa/4wNJK0UBUMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgkpELmZuJ4N/iiCOc4F9lnaCEQoYAQqBOQGDXgKFIT8YAQE?= =?us-ascii?q?BAQEBAQEBayiFHwEBAQQBASEKQRsJAhEDAQIBIAcDAgInHwkIEwYCAQGKHhCDL?= =?us-ascii?q?YR4nWyCJyaKQAEBAQEBAQEBAgEBAQEBAQEBAQEZBYNBgQ57gVaBaSmDAoFJgzB?= =?us-ascii?q?HFoJfgmMFkxSGHYkqh3SDa4kyghaJc4dKijmCQYlLgTofOYFRMhoIGxU6gimCX?= =?us-ascii?q?oIYIDeHPIJHAQEB?=
X-IronPort-AV: E=Sophos;i="5.45,341,1508803200";  d="scan'208,217";a="320778102"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2017 18:46:37 +0000
Received: from [10.155.70.45] (dhcp-10-155-70-45.cisco.com [10.155.70.45]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vAUIkaHb012095 for ; Thu, 30 Nov 2017 18:46:36 GMT
To: lisp@ietf.org
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <7cf2e668-ca68-8ae4-054e-02b9f4f5b644@cisco.com> <3be13180c987450a9b625e7143fe0225@XCH-RCD-008.cisco.com> <779AC172-FE1C-45B0-AA0C-35B8438CE787@gmail.com>
From: Fabio Maino 
Message-ID: <1cfc9b0d-854d-c249-d06f-eff58b3d4d93@cisco.com>
Date: Thu, 30 Nov 2017 10:46:39 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <779AC172-FE1C-45B0-AA0C-35B8438CE787@gmail.com>
Content-Type: multipart/alternative; boundary="------------527DE6B0244E3C398104769A"
Content-Language: en-US
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 18:46:57 -0000

This is a multi-part message in MIME format.
--------------527DE6B0244E3C398104769A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

100% agree Dino.

The proposed changes to RFC6830bis, as discussed so far, are:
- allocate the last reserved bit in RFC6830bis as a P-bit,
- use the last 8-bit of the first word as nonce, and
- use 16 bits only to allocate nonce and versioning fields (when used).

LISP-GPE will reflect the KK bits and will be bit-aligned with 
RFC6830bis (including NLEV bits). This will mean that the OAM bit in 
LISP-GPE will not be there anymore.

What Frank is saying is that this will enable the IOAM use case with 
LISP, because IOAM doesn't actually use the OAM bit, but relies only on 
the Next Protocol field.


Thanks,
Fabio




On 11/30/17 8:32 AM, Dino Farinacci wrote:
> I strongly suggest that the proponents for the P-bit do not couple 
> this with IOAM because there is a lot more machinery to be described 
> which may be too late for 6830bis.
>
> When RFC 8061 LISP-crypto was written, the authors anticipated the 
> P-bit and hence why the two low-order bits in the flags filed was 
> selected.
>
> We are now out of flag bits.
>
> Dino
>
> On Nov 30, 2017, at 7:36 AM, Frank Brockners (fbrockne) 
> > wrote:
>
>> Fabio,
>>
>> extending LISP encap with multiprotocol support would be beneficial. 
>> It would also give us a way to introduce IOAM into LISP – along very 
>> similar lines to what we discussed in Singapore as part of the IOAM 
>> with VXLAN-GPE encap discussion.
>>
>> Thanks, Frank
>>
>> *Subject: *
>>
>> 	
>>
>> [lisp] RFC6830bis and multiprotocol support
>>
>> *Date: *
>>
>> 	
>>
>> Wed, 29 Nov 2017 14:32:40 -0800
>>
>> *From: *
>>
>> 	
>>
>> Fabio Maino  
>>
>> *To: *
>>
>> 	
>>
>> lisp@ietf.org   
>> 
>>
>> I would like to suggest a way to address mutiprotocol support in 
>> RFC6830bis, that may address what was discussed in Singapore.
>>
>> This is based on using the last reserved bit in the LISP header as P 
>> bit to indicate support for multiprotocol encapsulation, as specified 
>> in the LISP-GPE draft 
>> (https://tools.ietf.org/html/draft-lewis-lisp-gpe).
>>
>> The header, as specified in section 5.1, would look like:
>>
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    L   |N|L|E|V|I|P|K|K|     Nonce/Map-Version/Next-Protocol    |
>>    I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    S / |                 Instance ID/Locator-Status-Bits               |
>>    P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>> and the text in section 5.3 that reserves the 6th bit would be 
>> replaced by:
>>
>>    P: The P-bit is the Next Protocol bit. When this bit is set to
>>       1, the V-bit MUST be set to 0 and the Nonce length, when used, is
>>       limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more 
>> details.
>>       The P-bit is set to 1 to indicate the presence of the 8 bit Next
>>       Protocol field encoded as:
>>
>>      x x x 0 x 1 x x
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |N|L|E|V|I|P|K|K| Nonce               | Next-Protocol |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |                 Instance ID/Locator-Status-Bits               |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>> I will have to refresh the LISP-GPE draft, and reflect the 
>> allocations of the KK bits according to RFC8061 and Nonce. One of the 
>> K bits was used by LISP-GPE to indicate OAM packets, but that same 
>> functionality can be done using the Next-Protocol field.
>>
>> The use of the P-bit is not compatible with the Map-Versioning 
>> feature, but an equivalent function can be specified (if needed) with 
>> a Next-Protocol shim header. I can add text to the LISP-GPE draft to 
>> reflect that.
>>
>> This would address the multiprotocol working item included in the 
>> current charter.
>>
>> I can very quickly update the LISP-GPE draft to reflect this, but I 
>> wanted to hear what the group thinks first.
>>
>> Thanks,
>> Fabio
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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



--------------527DE6B0244E3C398104769A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
100% agree Dino. 

      

      The proposed changes to RFC6830bis, as discussed so far, are: 

      - allocate the last reserved bit in RFC6830bis as a P-bit, 

      - use the last 8-bit of the first word as nonce, and 

      - use 16 bits only to allocate nonce and versioning fields (when
      used). 

      

      LISP-GPE will reflect the KK bits and will be bit-aligned with
      RFC6830bis (including NLEV bits). This will mean that the OAM bit
      in LISP-GPE will not be there anymore. 

      

      What Frank is saying is that this will enable the IOAM use case
      with LISP, because IOAM doesn't actually use the OAM bit, but
      relies only on the Next Protocol field. 

      

      

      Thanks,

      Fabio

      

      

      

      

      On 11/30/17 8:32 AM, Dino Farinacci wrote:

    

    

      
      
I strongly suggest that the proponents for the P-bit do not
        couple this with IOAM because there is a lot more machinery to
        be described which may be too late for 6830bis. 

      


      

      
When RFC 8061 LISP-crypto was written, the authors
        anticipated the P-bit and hence why the two low-order bits in
        the flags filed was selected. 

      


      

      
We are now out of flag bits. 

      


      

      
Dino

      


        On Nov 30, 2017, at 7:36 AM, Frank Brockners (fbrockne) <fbrockne@cisco.com>
        wrote:

        

      

      

        

          
          
          

            
Fabio,

            
 

            
extending LISP encap with multiprotocol
                support would be beneficial. It would also give us a way
                to introduce IOAM into LISP – along very similar lines
                to what we discussed in Singapore as part of the IOAM
                with VXLAN-GPE encap discussion.

            
 

            
Thanks, Frank

            

              
 

              

                
                  

                    
                      
Subject:
                            

                    		
                    
                      
[lisp]
                          RFC6830bis and multiprotocol support

                    		
                  

                  

                    
                      
Date:
                            

                    		
                    
                      
Wed, 29
                          Nov 2017 14:32:40 -0800

                    		
                  

                  

                    
                      
From:
                            

                    		
                    
                      
Fabio
                          Maino <fmaino@cisco.com>

                    		
                  

                  

                    
                      
To: 

                    		
                    
                      
lisp@ietf.org 
                          <lisp@ietf.org>

                    		
                  

                
              

              
 

              
I would like to suggest a way to address mutiprotocol
                support in RFC6830bis, that may address what was
                discussed in Singapore.
                

              
This is based on using the last reserved bit in the
                LISP header as P bit to indicate support for
                multiprotocol encapsulation, as specified in the
                LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).
                

              
The header, as specified in section 5.1, would look
                like: 

              
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     L   |N|L|E|V|I|P|K|K|       
                        Nonce/Map-Version/Next-Protocol    |

                     I \
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     S / |                 Instance
                      ID/Locator-Status-Bits               |

                     P  
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              


                  and the text in section 5.3 that reserves the 6th
                    bit would be replaced by: 
                

              
   P: The P-bit is the Next
                    Protocol bit. When this bit is set to

                        1, the V-bit MUST be set to 0
                      and the Nonce length, when used, is
                    

                        limited to 16 bits. Refer to
                    [draft-lewis-lisp-gpe] for more details.
                  

                        The P-bit is set to 1 to indicate the
                    presence of the 8 bit Next 

                        Protocol field encoded as: 

              
     x x x 0 x 1 x x

                     
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      |N|L|E|V|I|P|K|K|          
                      Nonce               | Next-Protocol |

                     
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      |                 Instance
                      ID/Locator-Status-Bits               |

                     
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  

                  

                I will have to refresh the LISP-GPE draft, and
                reflect the allocations of the KK bits according to
                RFC8061 and Nonce. One of the K bits was used by
                LISP-GPE to indicate OAM packets, but that same
                functionality can be done using the Next-Protocol field.
                

                

                The use of the P-bit is not compatible with the
                Map-Versioning feature, but an equivalent function can
                be specified (if needed) with a Next-Protocol shim
                header. I can add text to the LISP-GPE draft to reflect
                that.
                

                

                This would address the multiprotocol working item
                included in the current charter.
                

                

                I can very quickly update the LISP-GPE draft to reflect
                this, but I wanted to hear what the group thinks first.
                

                

                Thanks,

                Fabio

                

                

                

                

                

                

                

                

            

          

        

      

      

        
_______________________________________________

          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


    

    


    

  


--------------527DE6B0244E3C398104769A--


From nobody Thu Nov 30 10:49:25 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAA1127444 for ; Thu, 30 Nov 2017 10:49:22 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 v-SaGbaT-C96 for ; Thu, 30 Nov 2017 10:49:21 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 77DE6126CC4 for ; Thu, 30 Nov 2017 10:49:21 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id y89so3495377pfk.0 for ; Thu, 30 Nov 2017 10:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9wNrkZ8FWB/uDyvJXXP+tjx8TetOtoaUnMQXMpj8qq4=; b=JDSLcyj0/se56zzpuUDmznLsgvFmViddYO/t7Va/U0cKCp8fW8k0kw/vECpHEEpuI6 UMBddvyqlSAtsuu3TSmqvdPbXF5xgp58H2cMrwIpfb6gM36qN9ViZDefQ9Yo9g3AcyUV IV2EIDv0h93b5VU1TIiQywC4Hd1lRljK4zsfNv/JfmYilMQEASC4mP1EJP4O0R5Trq6i xynHlKALt993/Dsn4+yjVXQBI5uR/6qAF3+xskjhvmRX17GT11YhPtsYA2UqaSze2zNs 8qOYLtSABy6W0Q1FhUYy0SMauKOhNJsKaIKyuNTm3HKfBz8PjtMvz12PgopRPTL9FBse JxUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9wNrkZ8FWB/uDyvJXXP+tjx8TetOtoaUnMQXMpj8qq4=; b=rE8VwzFyhDMI2Ty1c2inFoTA+6yXpViPCZX/e6Ja58qrzPenvTz1qonJUxQ9C9bLHu vqlvMhbVbUEpvyywuVMTUe0R6/VLpK+uCwbPFwH4tCH0lduWCnrl9r4KTq0tuGzDXKnN Wf+MYKoN3mC4QDN+ZPbyIAPHJkCdOUbfaQbAsDAoC40YGEzkNPLKKSZUUtV20ec+zouj QCCkmn6vfJ93Qx0Ra/4jlrkv2b4YBeQ8w7cxyx62ihlceV2DoQkit3SYa8bx1pV43AL5 U4WEu5YFNTF2vXEJ+Y6w6651EuU2XsghqSPu6qtU3XKnRuo5ucVJaOH8apQYPqjydTKp MrvA==
X-Gm-Message-State: AJaThX6LbV83qVJSM2s8u842teFt0HS09IPBrHdkI9Kv96lt+PUDoWoa sGjkgBo9yiHSdej9eXyTWTs=
X-Google-Smtp-Source: AGs4zMZ2XyMgw3YuzwRblgOuPrGSQSGUMKgTTzorlUpHgGV+0K41xZ622Jlekb1zl6Lh1dTolrIkRw==
X-Received: by 10.99.183.15 with SMTP id t15mr3379481pgf.128.1512067761020; Thu, 30 Nov 2017 10:49:21 -0800 (PST)
Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by smtp.gmail.com with ESMTPSA id c73sm8224869pfd.181.2017.11.30.10.49.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 10:49:19 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Dino Farinacci 
In-Reply-To: <1cfc9b0d-854d-c249-d06f-eff58b3d4d93@cisco.com>
Date: Thu, 30 Nov 2017 10:49:18 -0800
Cc: lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6352C57B-27A4-4B33-8F86-1962A1A24A68@gmail.com>
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <7cf2e668-ca68-8ae4-054e-02b9f4f5b644@cisco.com> <3be13180c987450a9b625e7143fe0225@XCH-RCD-008.cisco.com> <779AC172-FE1C-45B0-AA0C-35B8438CE787@gmail.com> <1cfc9b0d-854d-c249-d06f-eff58b3d4d93@cisco.com>
To: Fabio Maino 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 18:49:23 -0000

> 100% agree Dino.=20
>=20
> The proposed changes to RFC6830bis, as discussed so far, are:=20
> - allocate the last reserved bit in RFC6830bis as a P-bit,=20
> - use the last 8-bit of the first word as nonce, and=20

I think you mean the Next Protocol field and not the nonce.

> - use 16 bits only to allocate nonce and versioning fields (when =
used).=20
>=20
> LISP-GPE will reflect the KK bits and will be bit-aligned with =
RFC6830bis (including NLEV bits). This will mean that the OAM bit in =
LISP-GPE will not be there anymore.=20
>=20
> What Frank is saying is that this will enable the IOAM use case with =
LISP, because IOAM doesn't actually use the OAM bit, but relies only on =
the Next Protocol field.=20

Agree. Ack.

Dino



From nobody Thu Nov 30 10:54:55 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B9F1294A8 for ; Thu, 30 Nov 2017 10:54:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 rGeLJhJH-fH2 for ; Thu, 30 Nov 2017 10:54:37 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95108128959 for ; Thu, 30 Nov 2017 10:54:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=790; q=dns/txt; s=iport; t=1512068077; x=1513277677; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=i5X9QPgLcqFyIF1q184ghOKLRo98C7nLY2XoWay9th4=; b=lDTmB9ghtlaHhuEWgkADw/09S4vMQ62MUWik7yJm8Vh2axVnDBBObsi4 k15vKyeFbscsG2wOs8a7RQpoRZvZP9zhrLDOuV7MCwx157R61BwznPP/x lmFDHmiPFKtnNoeQ8BypUWP+T4OTzXL3fym72Nj/KtGYkgXL/5oFqOk1k U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQCzUiBa/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8gVSEJpkTgX2ZBwqFOwKFIUIVAQEBAQEBAQEBayiFIAEFIxV?= =?us-ascii?q?BEAsYAgImAgJXBg0IAQGKHqYkgieKZgEBAQEBAQEBAQEBAQEBAQEBASCBD4Iyg?= =?us-ascii?q?gmBVoFpKYMCgUmGbIJjBZMUj0eVEYwJh0qWRYE6NSOBUTIaCBsVgmSCXYIYIIo?= =?us-ascii?q?6AQEB?=
X-IronPort-AV: E=Sophos;i="5.45,341,1508803200"; d="scan'208";a="38036874"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 18:54:37 +0000
Received: from [10.155.70.45] (dhcp-10-155-70-45.cisco.com [10.155.70.45]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vAUIsas5029453; Thu, 30 Nov 2017 18:54:36 GMT
To: Dino Farinacci 
Cc: lisp@ietf.org
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <7cf2e668-ca68-8ae4-054e-02b9f4f5b644@cisco.com> <3be13180c987450a9b625e7143fe0225@XCH-RCD-008.cisco.com> <779AC172-FE1C-45B0-AA0C-35B8438CE787@gmail.com> <1cfc9b0d-854d-c249-d06f-eff58b3d4d93@cisco.com> <6352C57B-27A4-4B33-8F86-1962A1A24A68@gmail.com>
From: Fabio Maino 
Message-ID: <8504622d-25b7-791c-2ea8-9d52a4fa7d55@cisco.com>
Date: Thu, 30 Nov 2017 10:54:39 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <6352C57B-27A4-4B33-8F86-1962A1A24A68@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 18:54:54 -0000

On 11/30/17 10:49 AM, Dino Farinacci wrote:
>> 100% agree Dino.
>>
>> The proposed changes to RFC6830bis, as discussed so far, are:
>> - allocate the last reserved bit in RFC6830bis as a P-bit,
>> - use the last 8-bit of the first word as nonce, and
> I think you mean the Next Protocol field and not the nonce.

yes!

>
>> - use 16 bits only to allocate nonce and versioning fields (when used).
>>
>> LISP-GPE will reflect the KK bits and will be bit-aligned with RFC6830bis (including NLEV bits). This will mean that the OAM bit in LISP-GPE will not be there anymore.
>>
>> What Frank is saying is that this will enable the IOAM use case with LISP, because IOAM doesn't actually use the OAM bit, but relies only on the Next Protocol field.
> Agree. Ack.
>
> Dino
>
>


From nobody Thu Nov 30 10:55:19 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770D3128E19 for ; Thu, 30 Nov 2017 10:55:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Ux5Nma6B7rIl for ; Thu, 30 Nov 2017 10:55:14 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B329129423 for ; Thu, 30 Nov 2017 10:55:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25649; q=dns/txt; s=iport; t=1512068114; x=1513277714; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bhGU4Mya2IFcu7iv0djwOpEfzE+0wuPKTZ9M3je+1cI=; b=f7HNAkThEJSb4HT9c3vYtFoylkE46qYxRnm7U/fKchTS7sXrUNKrYwuS cuW+qGQJS33SYEKW4YxNKytpqWw3v2u8Fhhyy1PMKQH0c4G4GuqwbmERt ImdBfWOuAThFL0iD2Yb7tUyLNq7rjoOJN+z6euuPwg/A75HrFFAzHd5mx s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAAAZUyBa/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuJweOGI5zgX2Ia44LghEKGAEKgzqBXgKFIT8YAQEBAQE?= =?us-ascii?q?BAQEBax0LhR8BAQEEAQFsGwIBCBEDAQIhBwchBgsUCQgCBBMJiTVMAxUQqDgmh?= =?us-ascii?q?w8NgyQBAQEBAQUBAQEBAQEig0GCCYFWgWmCHYEOgUmBEBI5gVURNoVYBZJNhmS?= =?us-ascii?q?IbT0Ch3KDa4Q4hHqTU403iGECERkBgTkBHzmBUW8VOoIpCYIQOQwQgWd4hzyBM?= =?us-ascii?q?4EUAQEB?=
X-IronPort-AV: E=Sophos;i="5.45,341,1508803200";  d="scan'208,217";a="325128848"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2017 18:55:13 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAUItCe8029169 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 30 Nov 2017 18:55:13 GMT
Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 30 Nov 2017 12:55:12 -0600
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.1320.000; Thu, 30 Nov 2017 12:55:12 -0600
From: "Vina Ermagan (vermagan)" 
To: "lisp@ietf.org" 
Thread-Topic: [lisp] RFC6830bis and multiprotocol support
Thread-Index: AQHTaWIHLCRHqI/Gk0e/qgtFSEBuU6MsVuqAgAAAd4CAAAMCgIAABGQAgAAAxgCAAAG6gIAAG+qAgABbWQCAAANegIAAJbGAgAAhTACAAE/GgP//soUA
Date: Thu, 30 Nov 2017 18:55:12 +0000
Message-ID: 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>  <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>    <13f18cab-7017-0af3-6da6-074aed8cb24f@ac.upc.edu>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.9.160926
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.155.73.42]
Content-Type: multipart/alternative; boundary="_000_D64590E8DA8DCvermaganciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 18:55:17 -0000

--_000_D64590E8DA8DCvermaganciscocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1 on proposed extension.

This would enable LISP to carry L2 payload and NSH as well, which are all i=
mplemented in FD.io (VPP) and and interoperable with ODL Mapping Server.

Best,
Vina

From: lisp > on behalf =
of Dino Farinacci >
Date: Thursday, November 30, 2017 at 7:32 AM
To: Albert Cabellos >
Cc: "lisp@ietf.org" >
Subject: Re: [lisp] RFC6830bis and multiprotocol support

+1 here too. I can do an implantation so I can interoperate with the other =
implementations.

Dino

On Nov 30, 2017, at 2:46 AM, Albert Cabellos > wrote:

Hi all

Support proposed 6830bis extension.

This is indeed implmemented in OOR.

Albert

On Thu, Nov 30, 2017 at 9:47 AM, Albert L=F3pez > wrote:
+1

I also support extending RFC 6830bis as suggested. We have an initial imple=
mentation of LISP-GPE in OOR and we think this extension could be really us=
eful.

Albert L=F3pez



El 30/11/17 a les 07:32, Florin Coras ha escrit:
+1

The LISP implementation in FD.io VPP makes use of it to disti=
nguish between Ethernet, IP and NSH payloads.

Florin

On Nov 29, 2017, at 10:20 PM, Victor Moreno (vimoreno) > wrote:

I'm strongly supportive of this proposal as it completes the necessary spec=
ifications to support the L2 services proposed in the eid-mobility draft.

Victor

On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) > wrote:

sounds good.

Fabio

On 11/29/17 3:13 PM, Dino Farinacci wrote:
I'd also add before the last sentence:

If the N-bit and V-bit are 0 when the P-bit is set, the middle 16-bits are =
set to 0.

Dino

On Nov 29, 2017, at 3:07 PM, Fabio Maino > wrote:

On 11/29/17 3:05 PM, Dino Farinacci wrote:
How about this wording Fabio:

P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is us=
ed for the Next Protocol field. When the N-bit is also set with the P-bit, =
the Nonce field is the middle 16 bits. When the V bit is also set with the =
P-bit, the Version field is the middle 16 bits. Details on Next Protocol fi=
eld usage are described in [draft-lewis-lisp-gpe].

Comments?
much better.

Thanks,
Fabio

Dino

On Nov 29, 2017, at 2:49 PM, Fabio Maino > wrote:

Definition of the P bit will look like:

   P: The P-bit is the Next Protocol bit. When this bit is set to
      1, Nonce length, when used, is limited to 16 bits and the lenght
      of the Source and Destination Map-Version fields, when used, is limit=
ed
      to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.
      The P-bit is set to 1 to indicate the presence of the 8 bit Next Prot=
ocol field encoded as:



Do you think the overall proposed extension makes sense?

Thanks,
Fabio

On 11/29/17 2:38 PM, Fabio Maino wrote:
On 11/29/17 2:36 PM, Dino Farinacci wrote:
The use of the P-bit is not compatible with the Map-Versioning feature, but=
 an equivalent function can be specified (if needed) with a Next-Protocol s=
him header. I can add text to the LISP-GPE draft to reflect that.
Well it could be. Just like you did with the Nonce field. Make the Version =
field the middle 16-bits. So V and P can be set at the same as well as N an=
d P.

Dino

Good point, shortening versions to 8 bits...

Seems fine to me.


Fabio




_______________________________________________
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




_______________________________________________
lisp mailing list
lisp@ietf.orghttps://www.ietf.org/mailman/listinfo/li=
sp


_______________________________________________
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

--_000_D64590E8DA8DCvermaganciscocom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <53982CF1ADE9344EABA91D1EEE562188@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







+1 on proposed extension.







This would enable LISP to carry L2 payload and NSH as well, which are =
all implemented in FD.io (VPP) and and interoperable with ODL Mapping Serve=
r. 







Best,


Vina









From: lisp <lisp-bounces@ietf.org> on behalf of Dino Farina=
cci <farinacci@gmail.com><=
br>
Date: Thursday, November 30, 2017 a=
t 7:32 AM

To: Albert Cabellos <albert.cabellos@gmail.com>

Cc: "lisp@ietf.org" <lisp@i=
etf.org>

Subject: Re: [lisp] RFC6830bis and =
multiprotocol support

















+1 here too. I can do an implantation so I can interoperate with t=
he other implementations. 







Dino




On Nov 30, 2017, at 2:46 AM, Albert Cabellos <albert.cabellos@gmail.com> wrote:










Hi all






Support proposed 6830bis extension.







This is indeed implmemented in OOR.







Albert







On Thu, Nov 30, 2017 at 9:47 AM, Albert L=F3pez =

<alopez@ac.upc.ed=
u> wrote:






+1  



I also support extending RFC 6830bis as suggested. We have an initial imple=
mentation of LISP-GPE in OOR and we think this extension could be really us=
eful.



Albert L=F3pez







El 30/11/17 a les 07:32, Florin Coras ha escrit:








+1






The LISP implementation in =
FD.io VPP makes use of it to distinguish between Ethernet, IP and =
NSH payloads. 







Florin







On Nov 29, 2017, at 10:20 PM, Victor Moreno (vimoreno) <vimoreno@cisco.com> wro=
te:






I’m strongly supportive of this proposal as it comp=
letes the necessary specifications to support the L2 services proposed in t=
he eid-mobility draft.  




Victor




On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <fmaino@cisco.com> wrote:








sounds good.



Fabio



On 11/29/17 3:13 PM, Dino Farinacci wrote:


I’d also add before the last sentence=
:









If the N-bit and V-bit are 0 when the P-bit=
 is set, the middle 16-bits are set to 0.









Dino











On Nov 29, 2017, at 3:07 PM, Fabio Maino &l=
t;fmaino@cisco.com> wrote:

















On 11/29/17 3:05 PM, Dino Farinacci wrote:<=
/span>










How about this wording Fabio:

























P: The P-bit is the Next Protocol bit. When=
 set, the low-order 8 bits is used for the Next Protocol field. When the N-=
bit is also set with the P-bit, the Nonce field is the middle 16 bits. When=
 the V bit is also set with the P-bit,
 the Version field is the middle 16 bits. Details on Next Protocol field us=
age are described in [draft-lewis-lisp-gpe].

























Comments?










much better.

















Thanks,








Fabio



















Dino



























On Nov 29, 2017, at 2:49 PM, Fabio Maino &l=
t;fmaino@cisco.com> wrote:

































Definition of the P bit will look like:

































   P: The P-bit is the Next =
Protocol bit. When this bit is set to
















      1, Nonc=
e length, when used, is limited to 16 bits and the lenght
















      of the =
Source and Destination Map-Version fields, when used, is limited
















      to 8 bi=
ts. Refer to [draft-lewis-lisp-gpe] for more details.
















      The P-b=
it is set to 1 to indicate the presence of the 8 bit Next Protocol field en=
coded as:



































































Do you think the overall proposed extension=
 makes sense?

































Thanks,
















Fabio

































On 11/29/17 2:38 PM, Fabio Maino wrote:


















On 11/29/17 2:36 PM, Dino Farinacci wrote:<=
/span>
























The use of the P-bit is not compatible with=
 the Map-Versioning feature, but an equivalent function can be specified (i=
f needed) with a Next-Protocol shim header. I can add text to the LISP-GPE =
draft to reflect that.


























Well it could be. Just like you did with th=
e Nonce field. Make the Version field the middle 16-bits. So V and P can be=
 set at the same as well as N and P.

















































Dino















































Good point, shortening versions to 8 bits..=
.









































Seems fine to me.






























































Fabio








































































































______________________________________=
_________




















lisp mailing list




















lisp@ietf.org




















https://www.ietf.org/mailman/listinfo/li=
sp


















______________________________________=
_________
















lisp mailing list
















lisp@ietf.org
















https://www.ietf.org/mailman/listinfo/li=
sp




















_______________________________________________

lisp mailing list

lisp@ietf.org<=
/span>

https://www.ietf.org/mailman/listinfo/lisp







_______________________________________________

lisp mailing list

lisp@ietf.org

https://www.ietf.org/mai=
lman/listinfo/lisp














 <=
br>

_______________________________________________
lisp mailing list
lisp@ietf.orghttps://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.ie=
tf.org/mailman/listinfo/lisp















--_000_D64590E8DA8DCvermaganciscocom_--


From nobody Thu Nov 30 11:35:25 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CB11294B5 for ; Thu, 30 Nov 2017 11:35:24 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 d6sAAMUjh7ge for ; Thu, 30 Nov 2017 11:35:22 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 564B81294AC for ; Thu, 30 Nov 2017 11:35:22 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id d14so8738154ioc.5 for ; Thu, 30 Nov 2017 11:35:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=3tQaidI/XwiNAw1Ay0IcpDJvDfVzIXIt9C2pgkk4tVY=; b=sDcd8+6UWkiQb5MO9qIePEno49BBSTQRQxhAp4Y4Hj2XJoZ9K5thoqH6QVrCa+neO3 FnGs/Bxt735IOzksT5anBrrByF2gso1uIo+Z/SgdkFZ8qbOSdGKWlSoUz139hMw1pf4n GaX6JY7Y90yavGn9xPZ14iod8sJE2EZ/xm03JW1qEqbXMiWwY/xCXAJZcJYHzt5A3FNo 5VcWPbHhZ/pGXB8exUGg0tXLrqs/41rJ3gBdAkrrN0Qc8NSwCwwZUg0jvVXcYPwcjFOw fAlKB4dvbB2We0ukDpm1fZAZGnYrcmIdp0iMiZn+Zf9Nsa7IIhec5MH/Q/d8A3VnBYe9 lTqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3tQaidI/XwiNAw1Ay0IcpDJvDfVzIXIt9C2pgkk4tVY=; b=Mz7AuKFLnpdDWx/iP4GA9BsDqXNLxCFcsiY44S8Mea88ogzoA/HXcTEj6dItki8yB1 q4IRd8Smq8BrOlpsfx9zqZTOhitgS6Y5jWsBpMbvHC6qrRLKlfLISTns3lrM5uGx2sSH L1AsMuXWy1NPv4iUWKMTa6kxcAEz4wEjWylTu8uw6X1xT5ZxRruioyL34rJSQHuBBe+7 v/P+yS9kAsztbwHYFx9rYhC1/HOWFNe9gA84tAgsANZr28AGWCounr09lKXXLV6/spu7 OW64Cm2sa55Z0AsQGnPOJWMtavfsNuFJcpH45v+00IJ6ZmD3UNGkcTNaQ3vadq50232P lbqg==
X-Gm-Message-State: AKGB3mIJ4IOdIom+Ie5BjvuXzF4djF4BMc7Hum3EzGBgcXJxPteiqiUA DbbYy6sMwx7+OHiMzOSSEz5IBODiVwt9n+BZc2qJSA==
X-Google-Smtp-Source: AGs4zMbPTJBS6ujJGZHIeGOfnwksTlGlqpRLGocmIBpDUBki09ndsKEYp50F8aT5qeL5zoZjKuDMh78izzb4R4Y6LM4=
X-Received: by 10.107.141.77 with SMTP id p74mr5660584iod.40.1512070521115; Thu, 30 Nov 2017 11:35:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.181.70 with HTTP; Thu, 30 Nov 2017 11:35:00 -0800 (PST)
In-Reply-To: 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>  <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>    <13f18cab-7017-0af3-6da6-074aed8cb24f@ac.upc.edu> 
From: Alberto Rodriguez-Natal 
Date: Thu, 30 Nov 2017 11:35:00 -0800
Message-ID: 
To: "lisp@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 19:35:24 -0000

The addition of the P-bit/next-protocol is more than welcome. In my
experience with OOR and VPP I can confirm that this feature is already
working flawlessly in both. It is indeed a really flexible thing to
have.

Thanks,
Alberto


From nobody Thu Nov 30 11:58:11 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86101294BC for ; Thu, 30 Nov 2017 11:58:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com
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 01tF2mHSQGaT for ; Thu, 30 Nov 2017 11:58:09 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 A4A8A1294B3 for ; Thu, 30 Nov 2017 11:58:08 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id g130so2903376wme.0 for ; Thu, 30 Nov 2017 11:58:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=R4WIurnfBD6H/3wCoChzGwFGGvgJabJEMPLfSE2tZLY=; b=WMaG92lvYqqgYrw+dWNc5DnevqqRMq5wj41m2ZjDysepWvd8i9BQLgjhAIIhCY+qnP NwhG03CxF6ljVNjii0EUcs5BInv7ODjzLBQvXEtKkNmWjKzyITuYL1EFzTTlsp4jq5cC pTmP0lhDif9kbo0mfH+lGbiH3CHcBdtJrJtIQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=R4WIurnfBD6H/3wCoChzGwFGGvgJabJEMPLfSE2tZLY=; b=ZXAbMi+hePayxllBuWI1jy0on2EGOcxpEATKN5joK9A35qyH9tPXufT7tYTEUjLWiw OQwkWlElhwflrbMCq+HaRyDqBj81Tij0XA0Jp9ZIJDpqaE5LUz5Y4KTfQbejc5fH3wYu Iyn7Zn4Zqy6anSBmw9qESs6zTtIu1vBnIXoQlhGLVXmBk+FjaBhuaRI1u3qdsgeEo5Ig 6TYqlailP17yLOp2J5ZzwuAohwblZDGNhOa2BPS1PclnLbjiO/NnriZloY0HUjsonrHw h6x1DNcAvX1azptACC5465bSUfBalO5Bx91/FoC2eYKBYt/SKm1vKdQzwPqymKgS6Xgu a1bg==
X-Gm-Message-State: AJaThX5KSAdi+kVzx5d6LsJF0KeSeNSV7L7klxovESgOedFwFu9uemPA Z5KGfcuGG3RyqDja4r2OxITl9+lgM0wB4P3fFyqvm6jC
X-Google-Smtp-Source: AGs4zMZKvQ/G9QghXvIEAw2ulyKP5+XTBLXw5+QFBopZdARrazipqqC6JctUU3crXyxiZ0q/s70scclQ0yhLQCfpuqE=
X-Received: by 10.28.194.11 with SMTP id s11mr1433044wmf.143.1512071886824; Thu, 30 Nov 2017 11:58:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.173.106 with HTTP; Thu, 30 Nov 2017 11:58:06 -0800 (PST)
In-Reply-To: 
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com>   <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com>  <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com>    <13f18cab-7017-0af3-6da6-074aed8cb24f@ac.upc.edu>  
From: John Lemon 
Date: Thu, 30 Nov 2017 11:58:06 -0800
Message-ID: 
Cc: "lisp@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114b133eb09fe9055f38abb5"
Archived-At: 
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 30 Nov 2017 19:58:11 -0000

--001a114b133eb09fe9055f38abb5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Fabio,

+1 more on supporting this proposed extension, and with using it to
bring IOAM into LISP.
Both very useful.


Thanks, John



Subject: [lisp] RFC6830bis and multiprotocol support
Date: Thu, 30 November 2017 15:36 UTC
From: "Frank Brockners (fbrockne)" 
To: lisp@ietf.org 


Fabio,

extending LISP encap with multiprotocol support would be beneficial.
It would also give us a way to introduce IOAM into LISP =E2=80=93 along ver=
y
similar lines to what we discussed in Singapore as part of the IOAM
with VXLAN-GPE encap discussion.

Thanks, Frank

Subject: [lisp] RFC6830bis and multiprotocol support
Date: Wed, 29 Nov 2017 14:32:40 -0800
From: Fabio Maino 
To: lisp@ietf.org 

I would like to suggest a way to address mutiprotocol support in
RFC6830bis, that may address what was discussed in Singapore.

This is based on using the last reserved bit in the LISP header as P
bit to indicate support for multiprotocol encapsulation, as specified
in the LISP-GPE draft
(https://tools.ietf.org/html/draft-lewis-lisp-gpe).

The header, as specified in section 5.1, would look like:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|P|K|K|            Nonce/Map-Version/Next-Protocol    |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and the text in section 5.3 that reserves the 6th bit would be replaced by:

   P: The P-bit is the Next Protocol bit. When this bit is set to
      1, the V-bit MUST be set to 0 and the Nonce length, when used, is
      limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details.
      The P-bit is set to 1 to indicate the presence of the 8 bit Next
      Protocol field encoded as:
     x x x 0 x 1 x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|P|K|K|           Nonce               | Next-Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator-Status-Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the allocations
of the KK bits according to RFC8061 and Nonce. One of the K bits was
used by LISP-GPE to indicate OAM packets, but that same functionality
can be done using the Next-Protocol field.

The use of the P-bit is not compatible with the Map-Versioning
feature, but an equivalent function can be specified (if needed) with
a Next-Protocol shim header. I can add text to the LISP-GPE draft to
reflect that.

This would address the multiprotocol working item included in the
current charter.

I can very quickly update the LISP-GPE draft to reflect this, but I
wanted to hear what the group thinks first.

Thanks,
Fabio

--001a114b133eb09fe9055f38abb5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Fabio,

+1 more on supporting this proposed extension, and with using it to bring I=
OAM into LISP.

Both very useful.

Thanks, John


Subject: [lisp] RFC6830bis and multiprotocol support
Date: Thu, 30 November 2017 15:36 UTC
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com><fbrockne@cisco.com>
To: lisp@ietf.org<mailto:lisp@ietf.org> <lisp@ietf.org><mailto:lis=
p@ietf.org>

Fabio,

extending LISP encap with multiprotocol support would be beneficial. It wou=
ld also give us a way to introduce IOAM into LISP =E2=80=93 along very simi=
lar lines to what we discussed in Singapore as part of the IOAM with VXLAN-=
GPE encap discussion.

Thanks, Frank

Subject: [lisp] RFC6830bis and multiprotocol support
Date: Wed, 29 Nov 2017 14:32:40 -0800
From: Fabio Maino <fmaino@cisco.com<=
/a>><mailto:fmaino@cisco.com&=
gt;
To: lisp@ietf.org<mailto:lisp@ietf.org> <lisp@ietf.org><mailto:lis=
p@ietf.org>

I would like to suggest a way to address mutiprotocol support in RFC6830bis=
, that may address what was discussed in Singapore.

This is based on using the last reserved bit in the LISP header as P bit to=
 indicate support for multiprotocol encapsulation, as specified in the LISP=
-GPE draft (ht=
tps://tools.ietf.org/html/draft-lewis-lisp-gpe).

The header, as specified in section 5.1, would look like:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|P|K|K|            Nonce/Map-Version/Next-Protocol    |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and the text in section 5.3 that reserves the 6th bit would be replaced by:

   P: The P-bit is the Next Protocol bit. When this bit is set to
      1, the V-bit MUST be set to 0 and the Nonce length, when used, is
      limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details.
      The P-bit is set to 1 to indicate the presence of the 8 bit Next
      Protocol field encoded as:
     x x x 0 x 1 x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|P|K|K|           Nonce               | Next-Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator-Status-Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the allocations of t=
he KK bits according to RFC8061 and Nonce. One of the K bits was used by LI=
SP-GPE to indicate OAM packets, but that same functionality can be done usi=
ng the Next-Protocol field.

The use of the P-bit is not compatible with the Map-Versioning feature, but=
 an equivalent function can be specified (if needed) with a Next-Protocol s=
him header. I can add text to the LISP-GPE draft to reflect that.

This would address the multiprotocol working item included in the current c=
harter.

I can very quickly update the LISP-GPE draft to reflect this, but I wanted =
to hear what the group thinks first.

Thanks,
Fabio=



--001a114b133eb09fe9055f38abb5--


From nobody Thu Nov 30 17:29:41 2017
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 534341241FC; Thu, 30 Nov 2017 17:29:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: lisp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151209177931.11783.8816262843356725451@ietfa.amsl.com>
Date: Thu, 30 Nov 2017 17:29:39 -0800
Archived-At: 
Subject: [lisp] I-D Action: draft-ietf-lisp-predictive-rlocs-01.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
List-Id: 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, 01 Dec 2017 01:29:39 -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 WG of the IETF.

        Title           : LISP Predictive RLOCs
        Authors         : Dino Farinacci
                          Padma Pillay-Esnault
	Filename        : draft-ietf-lisp-predictive-rlocs-01.txt
	Pages           : 14
	Date            : 2017-11-30

Abstract:
   This specification will describe a method to achieve near-zero packet
   loss when an EID is roaming quickly across RLOCs.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-predictive-rlocs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-predictive-rlocs-01
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-predictive-rlocs-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-predictive-rlocs-01


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 Thu Nov 30 17:31:14 2017
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26AC124D68 for ; Thu, 30 Nov 2017 17:31:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zF_CyON-DuSK for ; Thu, 30 Nov 2017 17:31:06 -0800 (PST)
Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::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 2FD9D1241FC for ; Thu, 30 Nov 2017 17:31:06 -0800 (PST)
Received: by mail-pl0-x234.google.com with SMTP id d21so5350344pll.1 for ; Thu, 30 Nov 2017 17:31:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:references:to:date; bh=lxFHydU7yYsuK79UOz+wF/X4Hb4/IoauS7wp/9zr3JQ=; b=N8fQRUbYbxBfT0y/5LySVVu/1N8krU7qnXv+QCcQrqtYpkqcHtSRr8e/XyzgEK9+eE 3LDr2BZUyX0pffubQULpgAUYFEt7WWMys/nHFry4XyJN9ZYPT1ah9LRGDSN5fJf8nuLV ivtu1CvxjOIEFRi97Wu/24iZsH2+zGPzJ4L9kcqRBmg68ssrgmGZzBt1jfa2ZnabW+bB h3tnvVZPzhCchrviEYXWWlbTOJTp6b+IuhfmEmwiaT4mNVO+xBINtkoV2tEToLGIcxfr pGZfM/cmkJHlvfYLHmDOtYKAhU7NL8vzPMw51sGc1gJyMiYK+uHt6PrJrp4E2MVpbVgd ahMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=lxFHydU7yYsuK79UOz+wF/X4Hb4/IoauS7wp/9zr3JQ=; b=aVqdsoE14uxEEt4Z2GU1fMaD/eonjvdXXFXMhglGEiRl+Lmrg4ZWKaGsNtNNuUc5uI hey0nVnt2HFarAh3NyNnn20X1A18P+NNYx0zHCgCU5gZd9EqF8zWt43xYPA5ZTT8SlcU D6Z45FM/WZnfFsiDQF0F/LCNhRI/SmL13CHmkutkb65PNi7KEuqAq8tFVKIMIAVFjtWb hewPbOoUhwOZoCI0XYjQS8OBzdH5kAtJTgb4AohRX7hQYxh6oH9TTnND7g0bnDZFIF0t Mmkqs7magnhLNpeNdVoDlDRPOwZQreR8rGjhk45w2OsWlIW4cX/NxF5k7MS54rAukCyS 9yWA==
X-Gm-Message-State: AJaThX5ykVruPALvNDgUOZq6VJs0lfS6ZqdyL7cUawaTHtgGVB7jqRYA ggAxlJq6Ncdr3lBb6HVUIJ6O/XJG
X-Google-Smtp-Source: AGs4zMaBy7O9iYIbOnOG2IoZFqjAKK6ctTlJ2SXsnrzs6YVjTY7+XxEMdoKfPCLZ4+lDGYVCxWU6zQ==
X-Received: by 10.84.235.140 with SMTP id p12mr4411622plk.153.1512091865514; Thu, 30 Nov 2017 17:31:05 -0800 (PST)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id e26sm8764024pfi.10.2017.11.30.17.31.03 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 17:31:04 -0800 (PST)
From: Dino Farinacci 
Content-Type: multipart/alternative; boundary="Apple-Mail=_90968E2F-417B-40AA-942B-EF3859B86846"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Message-Id: <6ECADB8E-0DAD-4BF2-BD85-93F899D1E89D@gmail.com>
References: <151209177931.11783.8816262843356725451@ietfa.amsl.com>
To: "lisp@ietf.org list" 
Date: Thu, 30 Nov 2017 17:31:03 -0800
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: [lisp] Fwd:  I-D Action: draft-ietf-lisp-predictive-rlocs-01.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: 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, 01 Dec 2017 01:31:11 -0000

--Apple-Mail=_90968E2F-417B-40AA-942B-EF3859B86846
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Folks, here is an update to reflect comments from Prague IETF meeting. =
Changes include:



See diff file below. Comments welcome.

Thanks,
Dino/Padma




> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: [lisp] I-D Action: draft-ietf-lisp-predictive-rlocs-01.txt
> Date: November 30, 2017 at 5:29:39 PM PST
> To: 
> Cc: lisp@ietf.org
>=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 WG of =
the IETF.
>=20
>        Title           : LISP Predictive RLOCs
>        Authors         : Dino Farinacci
>                          Padma Pillay-Esnault
> 	Filename        : draft-ietf-lisp-predictive-rlocs-01.txt
> 	Pages           : 14
> 	Date            : 2017-11-30
>=20
> Abstract:
>   This specification will describe a method to achieve near-zero =
packet
>   loss when an EID is roaming quickly across RLOCs.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-predictive-rlocs/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lisp-predictive-rlocs-01
> =
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-predictive-rlocs-01
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-predictive-rlocs-01
>=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


--Apple-Mail=_90968E2F-417B-40AA-942B-EF3859B86846
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_92711963-EDE1-4AD2-8A2D-BC4468D0943A"


--Apple-Mail=_92711963-EDE1-4AD2-8A2D-BC4468D0943A
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Folks, here is an update to reflect comments from Prague IETF meeting. Changes include:


--Apple-Mail=_92711963-EDE1-4AD2-8A2D-BC4468D0943A
Content-Disposition: inline;
	filename=PastedGraphic-63.png
Content-Type: image/png;
	x-unix-mode=0666;
	name="PastedGraphic-63.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAA7wAAAFeCAYAAACmUBOXAAAMI2lDQ1BJQ0MgUHJvZmlsZQAASImV
VwdUk8kWnr8kISGhBUKREnoTpEiXXiMISAcbIQkklBACQcWOLCqwFlQsWNFVEdtaAFlsWLAtgr0v
iKAo62LBBsqbJICu+8p595z55zt37r3z3Wn/DADKkWyRKBNVASBLmCeOCvZjJiQmMUkdgAL0gArQ
BqZsTq7INzIyDEAZqf8u728DRFrfsJHG+mf7fxVVLi+XAwASCXEKN5eTBfFRAHBnjkicBwChF+qN
Z+aJICZClkBdDAlCbCLFaXLsKsUpchwms4mJ8oc4GQAFKpstTgNAScqLmc9Jg3GUyiC2E3IFQogb
Ifbi8NlciAchHpuVlQ2xsgXEFinfxUn7W8yU0ZhsdtooluciE4UAQa4okz37/xyO/y1ZmZKRPoxh
ofLFIVHSnKXjlpEdKsVUiC8KU8IjIFaD+KaAK7OX4m6+JCR22P4jJ9cfjhlgAIBSueyAUIh1ITaS
ZMT6DmMvtljmC+3RpAJ+TLw8PioUZ0cNx0cLhJnhYcNxyvg81giu4uUGRo/YpAqCWBDDOUTrBXms
mOGYF/MFceEQK0H8MDcjOnTY90UB3z98tC9JlJQznHMMZOWO5IKZpIqDouT2mDNfwAof1ofl8WNC
5L7YdA5bxkEL4nRebkLYCB8uLyBQzgcr5Aljh3li5aI8v6hh+52izMhhe6yRlxks1RtB3JKbHz3i
25cHF5s8FxyksydGyvvF1UV5kTFybjgThAF/EACYQAJLCsgG6UDQ0lvXC0ZaggAbiEEa4AGbYc2I
R7ysRQi/0aAA/AkRD+SO+vnJWnkgH+q/jGrlXxuQKmvNl3lkgG6Is3Ad3Av3wMPg1wcWB9wVdxvx
YyqP9EoMJAYQQ4hBRMsZgkLxD3GZgAMzyIRFDEJhzYNZSTkIR7h/i0PoJrQRnhBuEdoJ90AceArt
BP/I8Fs0wahuEmiHUYOGs0v5PjvcDLJ2wv1wT8gfcscZuA6wwcfDTHxxb5ibE9R+G7V/x10ywpps
R0bJmmQfssWPdkpWSk6jPtLcvucp55Uymon/aMuPvfl/lxsX1qE/WmJLsSNYM3YGu4Q1YnWAiZ3C
6rGr2AkpHl0bT2VrY6S3KBmfDBhHMGJjV2PXYzf4Q9/s4f7FsvkHebxZedKN458tmi0WpPHzmL7w
tOYxWUKO7Vimg529CwDSs19+tLxlyM50hHH5my7nNABuJVCZ9k3HhmfQ8W4A6O+/6YzfwC2wEoAT
rRyJOF+uw6UfAvyrKMOdog304dllATNyAM7AA/iAQDARRIAYkAimw3HmgyzIeiaYCxaBYlAKVoK1
YCPYCnaAPWA/OAzqQCM4Ay6AK6AV3AIP4FrpAi9BH3gPBhAEISE0hI5oIwaIKWKNOCCuiBcSiIQh
UUgikoykIUJEgsxFFiOlSDmyEdmOVCO/IseRM8glpA25h3QgPcgb5DOKoVRUHdVDzdBxqCvqi4ai
Meg0NA3NQQvQInQ5uh6tQvehtegZ9Ap6C21HX6L9GMAUMQZmiNlgrpg/FoElYamYGJuPlWAVWBV2
AGuAM30Da8d6sU84EafjTNwGrtcQPBbn4Dn4fLwM34jvwWvxc/gNvAPvw78SaARdgjXBncAiJBDS
CDMJxYQKwi7CMcJ5uKe6CO+JRCKDaE50gXs1kZhOnEMsI24mHiSeJrYRO4n9JBJJm2RN8iRFkNik
PFIxaQNpH+kU6Tqpi/RRQVHBQMFBIUghSUGoUKhQobBX4aTCdYVnCgNkFbIp2Z0cQeaSZ5NXkHeS
G8jXyF3kAYoqxZziSYmhpFMWUdZTDlDOUx5S3ioqKhopuilOVhQoLlRcr3hI8aJih+InqhrViupP
nUqVUJdTd1NPU+9R39JoNDOaDy2JlkdbTqumnaU9pn1UoivZKrGUuEoLlCqVapWuK71SJiubKvsq
T1cuUK5QPqJ8TblXhaxipuKvwlaZr1Kpclzljkq/Kl3VXjVCNUu1THWv6iXV52okNTO1QDWuWpHa
DrWzap10jG5M96dz6IvpO+nn6V3qRHVzdZZ6unqp+n71FvU+DTWN8RpxGrM0KjVOaLQzMIYZg8XI
ZKxgHGbcZnzW1NP01eRpLtM8oHld84PWGC0fLZ5WidZBrVtan7WZ2oHaGdqrtOu0H+ngOlY6k3Vm
6mzROa/TO0Z9jMcYzpiSMYfH3NdFda10o3Tn6O7Qvarbr6evF6wn0tugd1avV5+h76Ofrr9G/6R+
jwHdwMtAYLDG4JTBC6YG05eZyVzPPMfsM9Q1DDGUGG43bDEcMDI3ijUqNDpo9MiYYuxqnGq8xrjJ
uM/EwGSSyVyTGpP7pmRTV1O+6TrTZtMPZuZm8WZLzOrMnptrmbPMC8xrzB9a0Cy8LXIsqixuWhIt
XS0zLDdbtlqhVk5WfKtKq2vWqLWztcB6s3XbWMJYt7HCsVVj79hQbXxt8m1qbDpsGbZhtoW2dbav
xpmMSxq3alzzuK92TnaZdjvtHtir2U+0L7RvsH/jYOXAcah0uOlIcwxyXOBY7/h6vPV43vgt4+86
0Z0mOS1xanL64uziLHY+4NzjYuKS7LLJ5Y6rumuka5nrRTeCm5/bArdGt0/uzu557ofd//Kw8cjw
2OvxfIL5BN6EnRM6PY082Z7bPdu9mF7JXtu82r0NvdneVd5PfIx9uD67fJ75Wvqm++7zfeVn5yf2
O+b3wd/df57/6QAsIDigJKAlUC0wNnBj4OMgo6C0oJqgvmCn4DnBp0MIIaEhq0LusPRYHFY1q2+i
y8R5E8+FUkOjQzeGPgmzChOHNUxCJ02ctHrSw3DTcGF4XQSIYEWsjngUaR6ZE/nbZOLkyMmVk7uj
7KPmRjVH06NnRO+Nfh/jF7Mi5kGsRawktilOOW5qXHXch/iA+PL49oRxCfMSriTqJAoS65NISXFJ
u5L6pwROWTula6rT1OKpt6eZT5s17dJ0nemZ00/MUJ7BnnEkmZAcn7w3eZAdwa5i96ewUjal9HH8
Oes4L7k+3DXcHp4nr5z3LNUztTz1eZpn2uq0Hr43v4LfK/AXbBS8Tg9J35r+ISMiY3fGUGZ85sEs
hazkrONCNWGG8Fy2fvas7DaRtahY1J7jnrM2p08cKt6Vi+ROy63PU4eX7KsSC8lPko58r/zK/I8z
42YemaU6Szjr6myr2ctmPysIKvhlDj6HM6dpruHcRXM75vnO2z4fmZ8yv2mB8YKiBV0LgxfuWURZ
lLHo90K7wvLCd4vjFzcU6RUtLOr8KfinmmKlYnHxnSUeS7YuxZcKlrYsc1y2YdnXEm7J5VK70orS
wTJO2eWf7X9e//PQ8tTlLSucV2xZSVwpXHl7lfeqPeWq5QXlnasnra5dw1xTsubd2hlrL1WMr9i6
jrJOsq59fdj6+g0mG1ZuGNzI33ir0q/y4CbdTcs2fdjM3Xx9i8+WA1v1tpZu/bxNsO3u9uDttVVm
VRU7iDvyd3TvjNvZ/IvrL9W7dHaV7vqyW7i7fU/UnnPVLtXVe3X3rqhBayQ1Pfum7mvdH7C//oDN
ge0HGQdLD4FDkkMvfk3+9fbh0MNNR1yPHDhqenTTMfqxklqkdnZtXx2/rr0+sb7t+MTjTQ0eDcd+
s/1td6NhY+UJjRMrTlJOFp0cOlVwqv+06HTvmbQznU0zmh6cTTh789zkcy3nQ89fvBB04Wyzb/Op
i54XGy+5Xzp+2fVy3RXnK7VXna4e+93p92Mtzi2111yu1be6tTa0TWg7ed37+pkbATcu3GTdvHIr
/Fbb7djbd+9MvdN+l3v3+b3Me6/v598feLDwIeFhySOVRxWPdR9X/WH5x8F25/YTHQEdV59EP3nQ
yel8+TT36WBXUTetu+KZwbPq5w7PG3uCelpfTHnR9VL0cqC3+E/VPze9snh19C+fv672JfR1vRa/
HnpT9lb77e5349819Uf2P36f9X7gQ8lH7Y97Prl+av4c//nZwMxB0uD6L5ZfGr6Gfn04lDU0JGKL
2bKrAAYLmpoKwJvdANAS4d2hFQDKFPnbTCaI/D0pQ+A/Yfn7TSbOAOz2ASB2IQBh8I6yBRZTiKmw
ll7HY3wA6ug4WoYlN9XRQR6LCl84hI9DQ2/1ACA1APBFPDQ0sHlo6MtOSPYeAKdz5G9CqUjfoNvG
SVFr1yvwo/wL/Wdw9t/+zNMAAAAJcEhZcwAAFiUAABYlAUlSJPAAAAGdaVRYdFhNTDpjb20uYWRv
YmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJY
TVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcv
MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFi
b3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8x
LjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjk1NjwvZXhpZjpQaXhlbFhEaW1l
bnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj4zNTA8L2V4aWY6UGl4ZWxZRGlt
ZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0
YT4Kd7LmHQAAABxpRE9UAAAAAgAAAAAAAACvAAAAKAAAAK8AAACvAABVsKxnIjUAAEAASURBVHgB
7L1/jBzHeef9GCB9JGPSpn45R1tgHCKydK81fkNBYHKwTjf0vYicAzRC4OAC3wgXxcBIed+DNPAf
Pqxx8SEbwLq5AInHMF6MArzvCAlXsG+VnMYv/I6cNyvFq9x5CWNoeHjw8uyhswRveeelvYxnHe6K
s3a9VTNd1U/3VM/207uz5M5+F5idqqefqn6eT1X39NNVXf0Opf8IfyAAAiAAAiAAAiAAAiAAAiAA
AvuewHbCQ2nZJH2f3CczjRWX87xJv0P/Q8C777s1AIAACIAACIAACIAACIAACIDAcAApYSINLZP0
fXKfzNgWl/O8SSPglbQgdEEABEAABEAABEAABEAABEBgggnwgFHqprRskr5P7pMZ++JynjdpBLzS
VoQ+CIAACIAACIAACIAACIAACEwoAR4wSl2Ulk3S98l9MmNfXM7zJo2AV9qK0AcBEAABEAABEAAB
EAABEACBCSXAA0api9KySfo+uU9m7IvLed6kEfBKWxH6IAACIAACIAACIAACIAACIDChBHjAKHVR
WjZJ3yf3yYx9cTnPmzQCXmkrQh8EQAAEQAAEQAAEQAAEQAAEJpQADxilLkrLJun75D6ZsS8u53mT
RsArbUXogwAIgAAIgAAIgAAIgAAIgMCEEuABo9RFadkkfZ/cJzP2xeU8b9IIeKWtCH0QAAEQAAEQ
AAEQAAEQAAEQmFACPGCUuigtm6Tvk/tkxr64nOdNGgGvtBWhDwIgAAIgAAIgAAIgAAIgAAITSoAH
jFIXpWWT9H1yn8zYF5fzvEkj4JW2IvRBAARAAARAAARAAARAAARAYEIJ8IBR6qK0bJK+T+6TGfvi
cp43aQS80laEPgiAAAiAAAiAAAiAAAiAAAhMKAEeMEpdlJZN0vfJfTJjX1zO8yaNgFfaitAHARAA
ARAAARAAARAAARAAgQklwANGqYvSskn6PrlPZuyLy3nepBHwSlsR+iAAAiAAAiAAAiAAAiAAAiAw
oQR4wCh1UVo2Sd8n98mMfXE5z5s0Al5pK0IfBEAABEAABEAABEAABEAABCaUAA8YpS5Kyybp++Q+
mbEvLud5k0bAK21F6IMACIAACIAACIAACIAACIDAhBLgAaPURWnZJH2f3Ccz9sXlPG/SCHilrQh9
EAABEAABEAABEAABEAABEJhQAjxglLooLZuk75P7ZMa+uJznTRoBr7QVt9Bfu3GDNjY36cCBQ3T0
+FE6wPTXrl2m7/3Pm3T3B36JTh4/xLYgOfEENq7Txe9cpYPvvp8ePHXvbXP3+uXz9PW/Ok/f//EG
HTp0iI4dO0GnHvsoPXbq+K7adP3CV6j+1UuUe+oZeuLh28cj7vTO8dmgK5e+R91edA/H3v+QPvb5
WSG63ebuVD7Wvj3/vcXxeKfxv9Ps2fn2397xsvP27G6Nmxs36MYa6euFTaJDx+n40a3PEbtrIfYG
AiCw3wjwgFHqu7Rskr5P7pMZ++JynjfpkQHvtbdept8/9226++7DfV/X9f/Dh99DJ+//RfpfH3uc
zuzkhfvaJXrpxZfo0o9u0gf+xWfo+bMn+/vcG/826eLr/xf9h3/zHJ1rc4tzVKr+MVWfP0smvL3w
hbP0yAtvUq6yQN/+9BmuiPSEE1i78AU69sgLRLkqrX77edrd8NLAXaNXP1Og33zxzSHSu98f1+il
s8foOWPKbeMRx7DDfNbO04eP/QpFTgfG3UpLH/un4zuP5e9EPjET93h29PF4p/G/0+wZQ+Nv63gZ
gz27VuUGvfHSFH30uc9H9liqzrnrhsgGm9nT10vWCXyDAAjcyQR4wCi1U1o2Sd8n98mMfXE5z/fT
+l/iX6taUKaOpE95tpNYVrJhuTWrCmw/+WpLUvw2666qejHKKJfLhcxyVbUaWNiuFfvywp7y7zbj
TbH7xZlSn2uxduf2m267NugThZrqpvBpp1UsI3Ms54rTarbZVI3ZupouFdTU7GJkd1Z3fDy7qp4P
jplCfcd5ZLHflknDJwIrKdNbUrVySZVKZVUuD457U3e6Y3+8fJJM3k/y0cfjePnbvpb++BqvPXdE
u2/reLkjPMhgxLpqTPFrhZzKseugXLmh1j21jvt6Sd4/PUaOEI27/hG7xiYQAAEBgZ/97Gcq6+en
P/2pknw2NzeV79Pr9VT8c+vWLeX7vP3224p/NjY2lP2sr68rExEn/tkAjXJlNd9eVO12SzVnKirv
TsoF1fKdkRNrjG7orbZVpchO+EG96S4Ko3XdrlyrFt4UyJVqqrPaG5jSW1edhVk1XW26Hy3Lcy/5
d7u4Sva7F7i6C+z87Qh4l9V0bhBg5qeaKuihiYh3g2evu6zarbZa3sb5I8kBuf0yPkn7TZavq3ph
wD/tsT9OPsl27p8tWx2P4+Qv759KjdOeO6/V5cfLnefD1hYtN6fcjfFCZS64TuiquWp4g2yqueQq
2q3rpSz90xmZIjHu+lOYABUQAIEUBLIGu6acJNg1ur5g18jiwa7J+4JdI+PBrknbYNd8pw949SgM
vy51FwuUV83lrS6fk6l2W1V3wi9WG6pRGQSPaS8Kk2vepS0rc+EdWT1yZ0dyk/aOE30Sme3J9wLX
3mJ90NdvR8DbbQUzKHJqdmnr43Uv8BzVY8T2C/mM2rd/W1fVhAGvvx5Id4rA7Twexf1zp5zeM/Xs
h+NlVdXsLJd8OAvMNNF6q+Kui4ht263rpXH3z3HXv2e6OQwFgTucwKQFvCOf4b340tOUe+4cUb5G
3TeepaN6Tl7/b+MiPX04R+coT3Mrf0ln7822wMLG5a/Q1Bf/Bz1d/gSdPnmULun9PaT3pwNeeu35
rZ5zs8bcvu+LL2s+z2g++m+2s04fPzV6ISrLs1Bta/8epmsXXqdzr/4nunj1Jt3zwEfo6U/+Kzp9
wl/HtUtv0V9//Vv03/uLDb2b7jnxD+ld77xF7/rA43Q2WPTn+sW36Ov/7Qd0/y//mn6++qio/huX
L9DcW9+k76/8WC9m9G46ds/ddNe73knvPP6/0D977FRk8S3zPOiF1/+cXv3aN+jqD28SHbmfCr/z
LH38zElvY1zXtv/FbJP+5rtX9fYjdOSeI/T+DzxIj37kCXritL+Mt6IE4SXdDg/pdijUNNdnH07Q
CsVreuGmV175krbnh33hPfc/Sr/xyad3dOGmCM9330d06U/phc+/SdpI6r4WHktXzr9O37x6iz74
+K/Tw/o4unL+K/Tlxpu6T/yQjhy5h049/lv0qU+cifEnStMfnMeb+ng9aI7XIi32/owe3OJwlfJ0
+9kicUP3g7nv3qB3Wr1bt+j4h/SCWQ9u9USzrL+J7Rfysean/16jl586Rs80dPOPOLdl5ZPu+Nqk
y+f/ir6l+9qHPvokGeSDvvbV/vnn/oc/Rp/83U+QPm1k/MtWf7b+L+sPxqE0x2NW/qb+jWsX6Evn
XqVvXNTnuCP6HHf3++nBD32YHj3zGJ2OLQiXtn9K7Ln81uv0rR/8hO76YPh7YOzif8bGv/wv3yd6
74foycceZJvkPFnhkcms7ZvmeLE7znI+l7RXuuPLWpPue/Pa6/TI+z7Wf8Z/em6Ffu+sXbjvCn3m
w79AL7qH/3PUWGrRkycP0G5dL6Xpn5s3LtH/O/ddIn0NcvyB4XP49Ytv0Nf/9id6+/vp1544HV47
ajxp6k9HEVogAALjJKDj8czVS8sm6fvkPpkxNC7n+X5a/0v8s3fidMAbGb3szJYNBf0pqjYf+k2s
Kd0Gu7+9McKrn6sKRm2oOBMZAU/y1vpXqs2ppvf5aM+IuX62qRp7RnjAfjBFUi845HbXqub77VLQ
06ibbFpUqO+pX62omfKgXKg3qLufZ88g93e0uqBKbko709MyMy0rPn44H4zae+umSqRfOUfSJFYX
1UytpmZm6qoc3Ck3z6bWZ2ZUvV4ffPT2ZnslUlurbvtu1HZjX6m+MGR/pHCqzBY8IyO8XVUNphrX
Wp3o81yWcZy/oD+stJuqVtMsalNuJkK5WlczAR+zbcHOKc7IMxWSQKlVGX58gfdfb11p+1sG+0V8
vMalFYbnilHntix80h9frK8tLOq+5jvmi2phq2kqiS5nqZ+VSdv/0/YHZ2f64zELfz3ZWLVmks8p
elG2wTkuQ/+U2NMo2fPZlAonwToIOrGuZu3vSHE23CDmGRbdOpWhffuVpjtejKr8fJ6yvQLn0h9f
QYGUX91WsKaDniU3z44537op1RZTYPXb64lR5xSmPjop7Z+634TrrhTUPP+ZXW663xsqzQ6ujaT1
j7YWW0EABHaBwKSN8KZ7hpddpHfmwmnIO3KiZY22oydwVu9Ykr1FF/gVUi6WZP3jwV+pUlezOiCx
snw1DGCVXs7HBdU6AMoVp/qLDTUbM2qqMAgeeBukqZ/rm4u15hQLQvIlVW/oYLkxqyrl4NnkyCJL
K6pip2Fpe6Zn5tRip6XqLGCuttiSTPpH0T7vbYLR5kJbdTqLamG+qeqVsiqUZzIvWNRdYNO+bHDo
+54OeS7PTTvOlJ9Sc+2O6rTn1LS9caHLTzWXt9FdUvBkx1K8fW0fmKrNqtnqYCEuc7MpJCrrD74L
ZrsP+z0dRDhZeEpBLetn2qvVmqrVa6qcaopv+v6WxX4JH6mvUf2w3aLHX1RLzEd0fIU22LY332Xd
HpVSGPzmpuaiRqXOZanfXya5/6fvDwOzZcejmL/eiV2Ap880X1az8y21uNhW8029fkNJn1uD4zdL
/5TYs96Zcee2SiT6CBpwueGCkPqivUst5Zm6MwSK0va19YflRh4vGc7nadurb4no+LK2p/sOA94p
1QnuEveWZl0bVpsNVQ5+z3Yj4M3SP9cXwz6nl59Xg1/OJbdeBFHoW5b605GEFgiAwLgI7M+AV594
c/m8ygWjUf0f91JjB0bDos1kA7ZRP3LRErcx55770yODM4upDLH+DS44C6rRCUOZ+engolNfINn7
uTxAK9Wio4+L9eEVn1PVz0aj19vBc6W6ffPTTRZY6VDY88zpkhvZJ1WL3HXWFyh29MDe0dVEwmeO
cqrJ7wCnorWFUrejmrOzqqEvDGzAmitW+vlGQz8Prj+zevt8x9EMf4gLVT2uzf9W3DOWRNPBDzff
ni4t5Tkc8BbVfPBMPOfvPGAXeGn6w2pnXjPQLPRCc3b1z6m6Zub4NFR7JbjaEvNMxyRJy9d/47qi
/pbBfhGfuHGifLoLeF5lGj6y4yu0YXD+MX3NBj7s+KWScvEQN2jLdJb6fWUG/dHX/0X9QdsrPx5D
J9PwV3yUq1h35+2wFn0e1Qts9P8y9E9ez9b2MJaelc99vy9SntyedGlmUz94G31+C+sMyyVfC4QL
zennBNKdzyXtpY2RHV+h9WlSbbvYpbuhvKKq9mayvrYyI/L2ZnfSDXX7e5/MKI0lgU7G/rnIrgny
0/pG7bRdxDOnGny9iIz1CzyAKgiAwA4T2LcB7+AiyU6bMt8FNdu2l+I7Q3lHT+A7Y1JyLestVQzu
wKYdFbT+GZYzsavKlflgxNL9AHbVjA0ii/WhKdO2Lv5jZ2Uj62cB9Zwd3c0NB3luYTI3wqinxJkR
i77PWl9fx5lVz8xHLxquWsErlyLT31fn3Qiv6S/VxoJasdfYyWTFW9zFYK2dWJbfPa+1wxsNtgC/
OJ7pZDNSxtPsObyw029oVfo5cGtOeLHuLl7l/cFV1msHfVU/ghBcf7ttnkQanoNiXdWa06830q84
ag59dKDdbEVuovBd2b7K+y/fbi74xP0tqCC9/UGB1Hyy+hu2c7K/Ue+35qP1RcdXaIPpa5GLUVOV
mzFRUAvu8JD4m61+e1G/df+X9wf58Ri2QRr+4Q1J2Q09cf/UZqWxx/2GmN8Xdi7RkZubfqqfFw2c
lPM05yvZ8R7tE6PPbyF7fl5MOl6ynM/F7SU6voz96fm4qcv6996c9TvBq/XM7+Rg0k3ILuk1jWn6
BKeaNi3rn/rVSmV7XRBeH041/BPrjQ2y+tNaDT0QAIGdJrA/A14dEHW6XbW8tKjmGzX34zm4cAov
0rcLe1wn8O3a5S3PAt6kH+V4Oetffno+vkkNBZi6fvuMjG+Kmq2L79vKUtWvxzErwYh92fPjNGSP
/jG3K80O3/wIf+giAa/+KW/akevg5oApWyxX9XTi7UwdjuKzfnMWUQ19KeKemSr6X6W1boNCUklT
yOJ1RvNSnqZ0eFFTrHuCdT065OLTDP3B2ef6qn6NmAtm3NahRBqe/ULdBTdynNQn5hP2t/U+svS3
gStb1x1zOS2fzP6G7Tyqj3Kr0vkgOb5CG4r1Rb6rftod7+aC27aZyN8M9Uv6v/j8k+V4DLGk4e+C
FraSblhDcipN3fHS6cosqangPMunpofTePnzvRmOL1F/MB7wPrHF+S3icFgu6XjJcj6Xt5fk+DLu
pj8fupsTeirw0vK8+613v8V6rYap4PfZ9/tvcKXrExGwqTLyesN+Z34HcvrVd6P+5PWPqg3bQAAE
xkVgfwa8btQxwKqnBtnRTb0y7o6x3lsnQv1ageA5xK1O8BaQ88/zzK+74LQjqu4iPHa3PqisHSx6
xS8IRPWzu/6+EU93QWHtYRcv5ketUCyqQqEQ++S9z+UutxrumWMeGOVK9f5IseWT9XuU37ZOx1df
0HuDPsY7U8Ar5mksCy/sfG1gbe9/M/siozeBkq8/uPKubILvTnGQSMNzoLmqmrWqfi434VNrxKYa
hjty+6i2QmEkFbKR9jdXt+c4i+zCZlLzyepv6As/Xu3ufd/Oh0Q+Yal0x1dog6+vhccHvyEk8TdL
/aPLhB6aVKibqj9kOh7DPabhH05LrWvr0v+5utP2T121K7NFfwiDW72QUH8C1pJ7FrQYefRGyLPv
nqQ/mALhPnx9rl+l919YLul4CftrwjnNHdPhDcys7ZXu+DKOpOcT2s9uFuvrLDdnjo0uJ/0epe0T
XsQjhK7e1P0zGvCSGSBxd2qHdySvf7gOSEAABMZPYH8GvC7osYD1YiB2GktR9mNva/B9uxPhFj/q
vrK3Q7ZQsYu92GlIo60Y5Z/7AbSs3Q/28PRDpdfhtHfy+Q2HbPXr53GHpviGwbxddMVcvNgAn+9z
tMfRrd3lRb0YU7hisLlw9Y02RUttnbN++0a2bWnHN7Yqpt3Op4cmXWA4XV/CtVdanqaS8MJuy326
+tP3B2emK5twcegUB4k0PGNFxFm7j6QL2u30N1v3qP4QMVjIJ1I2VSZs52R/oxVZH9Lqm9Kjj6/Q
Bl9fc894uin0UXu2zmWpf3SZ6D6F5x/XppLjMdxjGv7h2wpKorcV2LpT909tli2zZX9ggX5xppMw
Vd34KeQZohGkJO3Lqw3LJfmb5Xyetb2sZaOPL6uV7juy4FN/VD56Xg8fMSBVX/TfTkndJ9KZ5LRs
ven6Z2xhuL4vOohna3m4ioOErP54aeRBAAR2i8D+DHjjI7z6PqRdrddMnUq6mbeip0AvduwzQ1s3
kT0RJv3IxWuQ1h8vv938ul3YSZ/kc9Nbr246yj/3A24DXnbhEn1GWD8zw18pohehsj+HWesvxkbp
F/grjaw9GlYY4JfVYlKjp4Gqp2tVU63Sm6Yy80yQb0XjWFnG0zd9mI+MuCmdsSpGZnn9KXmKAl5W
f9r+4Ox1F//pAt5UPF3l2RKj+qqtMWt/E9sv5GPtS/+99QV8vK40fOJlXN57fIU2RFZS14V6S+EK
vtFRQFdjikSW+nkZN7aVuC9Rf2DHS9rzG99xGv7rbftqGT3jJfVoWMrzFTdGp9PYY4u4mxfmdykI
QHKex2hEPG3lom9Z+4ZVh+USrwV4+3oeB/Gdz7O2V2hXkPIeX0NaWwj0ols2ONTf0T7aY8/F8mno
0SolfcKUTHu9JDl/LjXCN0xMN9tqjr2GMGkxT0n9UY+RAwEQ2E0C+zPgzesl583zhHqBotXltqqx
19CUZjte/u1gFeHBKF7StOdeZOGjhWCabr4yr5/+5NuGd5Gu/uFyOysxC3+EU5KmZtuR4L/XXVIL
Cx0nG/UDNRTwstcemfcdzy111fpqR9XcwlHBfnVAai8VRfXrUjW7KqQe9TQLkPXWl9kqi0H97GbH
eid8bQKVamqJPb7d6y6r+ZlpPaV5NgzAdR/Iab2WvukRiY/Xl1QlCHiTFuSQtJNjp/2YYQupra+0
9WJKtk34neicqs2HzxAvL9TdhSGVs64+LucpCngz9AfHUBjQpePpas+UsH2VH+t2QVtbobS/2XJi
+4V87H7Sf4cX8Hl9Y8yd2+IOswrT8DHnwPTHV2hDZc72/Z5aWphhC8vJRiqZuTqZpf6wjG/UOVq/
XsZMdP7JcjyGe0zDX7F1EMzvXKk2r1aDE12v11VL7Xk102hFz32GlAuUR52vQltMKp09gzLmBoax
J/xERw9tzTKetpTkW9a+Yc1hueTjJcv5PHyuO017yY6v0Pq0KTfFWrdVmb0Ob2WBvfoxciOFXxP1
1Liul9L2T36jLOd+NzVjd11hFue0t+NDKmnrD0sgBQIgcDsI7M+AN/LjyX5I9WId/vHb1XCJfVM2
YVGP8MTH6hzaVz5cRMW1eLr6nfo4E/pOc4nbrN9lW6lW1FQpWJ4/VxUHpDaAtasZhhcullNRv8s0
uLPKAlJ7UeS7K+5YswA5XLXS1mu/89qHoH42wmswtu1oauBz/1nePFulUS/CYe13i4T0dXMqXyiq
UtG+tmCwrzQXuls1X29ljl2061cs6f0UnE2hPWa1Ut5W5lVbeadn7CkGK2RutUf/9tE8y4MLUMbf
BAl2mngaDtL+4KzUAd1gATS2IJHbOJxIzXO4aGqJ7au8b/tufkj6m9252H4hH7uf9N9hO3N/w8cF
hmtKw0d2fIVBRMQGdu6qR141NmzTaEmW+kMuafq/2b+kP8iPx9DDNPz72ivhgkOWa+T1fez8b2sX
90/jt10Fn7WX73gZ7GM9XOHf6LNX0Vkb7LeEpy2T/lvevoO6w3KWaf879luU6XwuaC/Z8ZWeitPs
ddzCVMa/QnlaTZf572P4HltTxv2Gsz4Q4dOXb/96KVX/NLY7O6J2qsjvsb6JFot5U9XvICEBAiBw
uwjsq4A3nBZkA6HBtwkoKvU5ZV/h6WuMcLqUnlalR2x9f132HtjhE7fdp15EJXbCNHWlqd+3z7HI
uot61Jv/UFnb9Td7Js5etBQ9U7Aci2LdjZCagKhZGbxv1/LJFabUgr7L0OvYl76HozLy+vXrhGaC
QMz+eOmAfU4P3bpniIZuVvRUu1GJBJjWtnyxrGYXwtcRdBebqly0zzkzJv196dcUNReHRj+ytk+3
01RF/p7owJ9ixYyosT/dVtXSsE25YlV5bkazgmmSfp5N/YoQ115F3r76wjQYsY++1zhpX7L+4Gpx
I5h8QSK31ZtIzdNbemshn6Fh+090Wp+tI31/syXMt8j+DHz4vrZOm3aO9//ouSFeRxo+suMrOSDN
F6fVvJ5Bsr2/LPVL+7+xUNIfpMdjSCANf6vd0zNJqgnn/7ye8RI5/wSFRP1Tl5HYY3bhFh3U58HR
5xYJz8D41F9Z2tdULjheMpzP07aX7PhKDSWqqO2fZiOi9lxI+emhQNFdI9jfau/3zlwvbdU/w5uv
ef2Ks+EevjIfjlLnKwtRn3Vuq/qHCkAAAiCw6wQmLeB9hyGoT7Jj+Fuji+e/QzfpCD1w5mE6vuN7
GHf9coM3blyj7/zXy9T7uXfSrb8nOnHqF+nkiXvpgLyqSIm169dotUd0kA7TiRM7T3JT2728Pqj/
Pl2/sfetPzhL/+Szb5JegZpan3vC48MGXbuyTN31Hh08fIzueu99dPxQgqeba3R9ZZVu9g4SbXZp
88DddPLk9rlEIPUzm3TjmrZJkzqoeR197wk6emhYy0jWrl+h5S5poptEx+6jk/ce9StmkPp4Zqgm
sci4+0O44/Q8wzLjSgn6mzPhTrLfGbXziVTH1xq9/NQxeqZBVJlfpk89epTW1jfpwOGj+hhJOG5F
lo67/rgx6fvDuI9Ha9nm2nVaXrmpz4dEPf27d9ddx7dgeyf1z/Q8rb930neW83nq9kp1fG2HxiZd
vjBP3/u7n9PXSTfo79/zS/SPT5+ihJ+ujDvKcr007v457vozokIxEACBPoHthIfSskn6PrlPZgyO
y3nepMcY8KLH3NEENi7Rf3hhln710/+aHjsVDaKvX3iZ/tkjz1BbO6Cf0aaXPn7qjnYFxoEACGxF
IAxI9aJV9PzpnbvBM9jzuOvfyj9sBwEQAAEQAAEQ2CkCPGCU1iktm6Tvk/tkxr64nOdNGgGvtBUn
RX/tPJ099iv0pvEnX6Tppz5Cp44R/ddvfJle/JO+VG8oU6f3x3RqJwaAJoUb/ACBPUmAB6SrOuCN
3uTavkvjrn/7FqIGEAABEAABEACBdAR4wJiuRKglLZuk75P7ZGbPcTnPmzQC3rB99ldq8xq99H8U
6TkX3MbcL0zRwv85TWdOINqNkUEWBPYggTV66ewxek7fy6osrNKnz+x8wDve+vcgcpgMAiAAAiAA
AnuUAA8YpS5Iyybp++Q+mbEvLud5k0bAK23FCdM3zx1/77uX6G+vrtJPbt2id9318/TAQ79MD57c
6QviCQMHd0BgjxHYuHGdftDt0V3v08+2j+E+1rjr32O4YS4IgAAIgAAI7FkCPGCUOiEtm6Tvk/tk
xr64nOdNGgGvtBWhDwIgAAIgAAIgAAIgAAIgAAITSoAHjFIXpWWT9H1yn8zYF5fzvEkj4JW2IvRB
AARAAARAAARAAARAAARAYEIJ8IBR6qK0bJK+T+6TGfvicp43aQS80laEPgiAAAiAAAiAAAiAAAiA
AAhMKAEeMEpdlJZN0vfJfTJjX1zO8yaNgFfaitAHARAAARAAARAAARAAARAAgQklwANGqYvSskn6
PrlPZuyLy3nepBHwSlsR+iAAAiAAAiAAAiAAAiAAAiAwoQR4wCh1UVo2Sd8n98mMfXE5z5s0Al5p
K0IfBEAABEAABEAABEAABEAABCaUAA8YpS5Kyybp++Q+mbEvLud5k0bAK21F6IMACIAACIAACIAA
CIAACIDAhBLgAaPURWnZJH2f3Ccz9sXlPG/SCHilrQh9EAABEAABEAABEAABEAABEJhQAjxglLoo
LZuk75P7ZMa+uJznTRoBr7QVoQ8CIAACIAACIAACIAACIAACE0qAB4xSF6Vlk/R9cp/M2BeX87xJ
I+CVtiL0QQAEQAAEQAAEQAAEQAAEQGBCCfCAUeqitGySvk/ukxn74nKeN2kEvNJWhD4IgAAIgAAI
gAAIgAAIgAAITCgBHjBKXZSWTdL3yX0yY19czvMmjYBX2orQBwEQAAEQAAEQAAEQAAEQAIEJJcAD
RqmL0rJJ+j65T2bsi8t53qQR8EpbEfogAAIgAAIgAAIgAAIgAAIgMKEEeMAodVFaNknfJ/fJjH1x
Oc+bNAJeaStCHwRAAARAAARAAARAAARAAAQmlAAPGKUuSssm6fvkPpmxLy7neZNGwCttReiDAAiA
AAiAAAiAAAiAAAiAwIQS4AGj1EVp2SR9n9wnM/bF5Txv0gh4pa0IfRAAARAAARAAARAAARAAARCY
UAI8YJS6KC2bpO+T+2TGvric500aAa+0FaEPAiAAAiAAAiAAAiAAAiAAAhNKgAeMUhelZZP0fXKf
zNgXl/O8SSPglbYi9EEABEAABEAABEAABEAABEBgQgnwgFHqorRskr5P7pMZ++JynjdpBLzSVoQ+
CIAACIAACIAACIAACIAACEwoAR4wSl2Ulk3S98l9MmNfXM7zJo2AV9qK0AcBEAABEAABEAABEAAB
EACBCSXAA0api9KySfo+uU9m7IvLed6kEfBKWxH6IAACIAACIAACIAACIAACIDChBHjAKHVRWjZJ
3yf3yYx9cTnPmzQCXmkrQh8EQAAEQAAEQAAEQAAEQAAEJpQADxilLkrLJun75D6ZsS8u53mTRsAr
bUXogwAIgAAIgAAIgAAIgAAIgMCEEuABo9RFadkkfZ/cJzP2xeU8b9IIeKWtCH0QAAEQAAEQAAEQ
AAEQAAEQmFACPGCUuigtm6Tvk/tkxr64nOdNGgGvtBWhDwIgAAIgAAIgAAIgAAIgAAITSoAHjFIX
pWWT9H1yn8zYF5fzvEkj4JW2IvRBAARAAARAAARAAARAAARAYEIJ8IBR6qK0bJK+T+6TGfvicp43
aQS80laEPgiAAAiAAAiAAAiAAAiAAAhMKAEeMEpdlJZN0vfJfTJjX1zO8yaNgFfaitAHARAAARAA
ARAAARAAARAAgQklwANGqYvSskn6PrlPZuyLy3nepBHwSlsR+iAAAiAAAiAAAiAAAiAAAiAwoQR4
wCh1UVo2Sd8n98mMfXE5z5s0Al5pK0IfBEAABEAABEAABEAABEAABCaUAA8YpS5Kyybp++Q+mbEv
Lud5k0bAK21F6IMACIAACIAACIAACIAACIDAhBLgAaPURWnZJH2f3Ccz9sXlPG/SCHilrQh9EAAB
EAABEAABEAABEAABEJhQAjxglLooLZuk75P7ZMa+uJznTRoBr7QVoQ8CIAACIAACIAACIAACIAAC
E0qAB4xSF6Vlk/R9cp/M2BeX87xJI+CVtiL0QQAEQAAEQAAEQAAEQAAEQGBCCfCAUeqitGySvk/u
kxn74nKeN2kEvNJWhL6fwMZ1uvidq3Tw3ffTg6fu9etAGiFw48ol+tsf9ejnf+khOnH0QGTbnsts
btDa2jptbG7SgUNH6fjRQyNd2Ny4QTfWiA7QJtGh41p/j/s/0ltsBAEQAAEQAAEQAIG9Q4AHjFKr
pWWT9H1yn8zYF5fzvEkj4JW2ItO/9tbL9Pvnvk133314IF3XX4cP03t+/j568EOP0mP/5DQd3yfX
8WsXvkDHHnmBKFel1W8/T8cZp3TJa/TyZ/6QvvEjosf/9WfpEw9Ha9i89hZ99vfP0Y/u/lX6d9O/
TSf2PNc1+sKHj9ELbaLKwip9+kzU33TMbrPWxjV6/UvnaOa1GTrX0I6wv1y+RH9Q/ff0ZKwdiTbo
jZem6KPPfZ5pE5Wqc1R9/iwlhslrl+ilF1+iSz+6SR/4F5+h58+ejJQ3mStvvESf+/Kl8Hgc0iBa
/9E65T89TU+eOurZChEIgAAIgAAIgAAIgAAPGKU0pGWT9H1yn8zYF5fzfD+t/+EvI4FWtaAM4+RP
SbVWM1a+jWKLM6W+TcVaaxu1yIp227UBh0JNdWVFB9rdlipYlvmqWonV0W1VA855tZBpB7EKb3u2
q+qFQd+p3o5OsgP+h20SHAO5nMrZNux/51Rzucf2tK4aU7nweInp58oNtc60bXK5NRv2DV1vvurv
161qPqw7Ykf0GN2rvC0PfIMACIAACIAACIDAOAn87Gc/U1k/P/3pT5Xks7m5qXyfXq+n4p9bt24p
3+ftt99W/LOxsaHsZ319XWGE19wWyPh38aWnKffcOT2qWab5c8/SvXSTrv1tm/6f//sZ+nwjqLRQ
o9XXns0w4pnRKF3M2lWotui1509nr0hQcu3iS3Qs9xxRvkbdN54l8fjZxgV6+vAjpGn2/6bnVuj3
zoZTo139VKBW9zU6Ld6BwJldUV2jl586Rs/ofqIDMHr+9N4b4V27+DJ95IVv0x+8+Cw99o9+IZjG
vEEXXv1DeuQ3P9unWKwv0p/99oP99LXXP0Pv+9iL/XShMkdf+rQZ0V2jN77wv9NHXxi0/FRziT73
xMm+zuaNi/RHzxfp35yLjh4n9etrb71CX/zry/Sef/AP+uX5v0Nvv04vfPbNvmjPjqhzh5AGARAA
ARAAARAAgTER0MF05pqlZZP0fXKfzBgal/N8P63/4S8jgXatOBhR0qOa0ZGpnpqv2NHfwq6PSFq7
dGCQ0TN5sd5ifcAin3GEd72lipFRuWm1xMxwI8hUUC2M8DIyd2Jy3Y1e56sLgYGrqpYPRlr1CD6f
+LDeqgz6jml/to2PIBerDdUIjqks/Xp13u5DH49853ciPtgEAiAAAiAAAiAAAreRQNbRXVNOMrpr
dH2ju0YWH901ed/orpHx0V2TtqO75nvPjvCuXT5Pr7zyJfqb7/6wf/fhnvsfpd/45NP02KndHSWz
I6neUc218/TUsV8hM9AbH8GT2n/90lv0F7NN7e9VXdsROnLPEXr/Bx6kRz/yBD1x+mSfAf936eWn
6aFnzlGh1qbXnn2Yb0pIr9GF1/+cXv3aN+jqD2/qXdxPhd95lj5+ZrhuW8GNyxdo7q1v0vdXfkyH
3n0f0aU/pRc+/ybpnVJXj2iLB2BjI7xmP+XGEv3xkwMbRo3wpuF5+a3X6Vs/+And9cHH6ezD4cix
9cd8b1y7QH/5X75P9N4P0ZOPDUYlB9u35rN25Tx97T9fpV/8p09R7mCLXvy3X6Tv3nyASpUpeuwE
0flX/oi++B8v0v0fe4Y+++xgZDMc4e3qEd6jdOX8V+jLja/Sxas36f6HP0af/N1PkP9R063tsX5d
Of86ffPqLfrg479OD997INjHm3ofP6QjR+6hU4//Fn3qE2f04lE7+LdxkZ49nKM/0VWWGx3dhqdo
89rr9Mj7PkZmrDY6en+FPvPhX6AX3SBujhpLLXry5AHauPwVmvri/6Cny5+g0yeP0iU9o+IhPaMi
aYQ30YPrb9DZ+z5KundG+lSiPjaAAAiAAAiAAAiAwD4moGPtzN5Lyybp++Q+mTE0Luf5flr/21N/
rXrZtID3U6ovKP7E4LgdsyOpOuAdem61t9xwzzPOdsLxX6n94Uixz+dKOFK2uqhmajU1M1NX5WAk
LVecVvWZGVWv1wcfvb3Zjj0du7qgSgk89bRTD88VNVMe8aykh0Wqdhga4TX+llUnaNCkEd60PBsl
y28qMnIc2rauZouBTnE2FKfkY58fzZenVSln96W/i5p5ffBMte23tbYZog6f4a23OvrZVh/T4vBo
ZEp7Bg50VTWwpdbfB3t+1rZ5LjraGjqeNaWf0y3b/YTP8HZbwTPelFfzbITV9xx80jO29niTjfAu
q4ptj+LM0HGa1UuUAwEQAAEQAAEQAIFJJTBpI7wmIt4zf8tz02Ggm59Sc+2O6rTn1HSw+I8JKKaa
y7vmj70A9wW8duEooqJqBfGu2H4d3OSDwMQEr82Ftup0FtXCfFPVK2VVKIcX8N0FO2WTBVs2qOHf
03aKqcG0oip2mqnWmZ6ZU4udlqqzgLYamT/cU02+6FC+pOqNpmo2ZlWlHEzh3nbAm1OVetX5rZ8B
7benL+CV8FzvzLi+U5mPBf1mD+wGRX3R3qBIz8f1hT7rnCoU7ZT24fYozRifwoDXBsLmu1ytqUop
DH5zU3N9/wf/0tsz0PfvY6o2q2arQRCetb2YVTzZstP8jS+zHbcpDHin3E2M3tKsa5Nqs6HKfXak
di7g7am5acuypNq2WZ1VSIAACIAACIAACIAACMQJIOCNE9m1/LKatiM1hfgqviuq5oLeabVbIa8L
cgr1yDO8S/N2NMuM8M0E2+T2h88w6pEyT4wWQd/tqObsrGrowMHeAMgVK/18o6Gff9SfWb19vhMO
ry3NhqPltchKwTpQsqOdpVnn23o7eE5XByb56WZktGwnn+GtL66o+Wk7SqhvGOhR3p5dBdo9wyvl
yYI/3V7xx4DnbWCkA0BLSMLH9QXNplAzAe0ieya5qNrah0598Mz3YISS2dMP9IpqftlGZIw/lZSN
vyX2DPqGbx+DIXPeXtbfSH/KkFlk/cn0j2Bwvl9TuxbcAHCreK+oqr3ZUmponfC530LC6uKWcdoR
Xn5DJNq/MziHIiAAAiAAAiAAAiCwTwgg4L1NDc1HgwZTQqOG8GBshk0hjmrtbM5egOsHV1VFTxeu
VqZU0V7E94OYshtVymT/6rwb6TT7qDYW1IqNiUa4smgDq1p7hJaewluyQaW+SaCjE/NQt/noRcCV
G6ljAeCcHd3NDd9UcCOwWUcM2ZTmqhmKW51zU8JNALnescH2YNGqLDxX3MJFpCJ9hL0SST9fGjCT
8Qn7QlktmkhP+2Nfs1Tsj+gqZXWGA96caizx8FC770bs7aJnMnsGTvCAN6f41Hp3vHiC/wCA6KvT
mHKjtfmp4dcLuanLwQJvneDVWaZfDxaRCm1Neu1QlN8W5rFjJ1/hsxq2KIfNIAACIAACIAACILDP
CSDgvU0dIJwSGU4Rjpiy3nYjaklTIiP6O5CxF+B8SqpN58tVtciGEbPZv66aduSxH0APpscWdd1z
7eRxbGvX6JGwLhsVH552a/0w07UHI4Dhs5B6Makhejsa8AbTqN2oq54W3mjaUfNBwJuN55KaCjjy
qcLh9HP+fK+Mj2XuViV2AXzBPbNqdeIBr522zaE6niYg7PcjmT2DusIgslj33Pww7zfjO82YXmY3
EszIru+ejLvZkKuopeV5dzPA9aWebptgBod3yrm2LcpvlLHabztDQd+cGe6to8piGwiAAAiAAAiA
AAjsbwIIeG9T+/MAIPJYqbXHBRjJzwBa1Z36thfglCup2bk51WzOqYXWolrpDocR27F/udVQUwU7
GhsGp7lSvT8yG/fH2pU0NXSgHwZDJrgtFIuqUCjEPvnwOWE2CuobYXcB6E6M8Nrp1WyUzgXgOgA0
7Z+VZxjc2kB0yT07akdis/BxzO2roGx/dFN44wFbyN/L003htjd4Qv1U7dV3Iizj20e832TJd9vh
s9Hxacy8vrC9wv6rV/R208cVa+ukG1ZDjPkOWNr1Rd2v6/0FwthGJEEABEAABEAABEAABEYSQMA7
Es/4NoYXzNFVXt0eU1wwO90dStgLcIo9w+urfifs7y4v6sWGptxUXxP4+EYHrV356XmfKYEsHDHU
ry8aoRdssgGc3udw8KTfsWqfod7JgFfv2k2F1fsdBL3xgFfYH1jgXpzpeKYOWxQyPpa5G1W3vFIE
vL4Az41uuynHMnsGXoQBr28f1tPM33pWhVvhu2SfVffXtr4YBsaDdoxO4w6ncOsglU+NYNUNMWbb
wmRPT9UP+opjF25FCgRAAARAAARAAARAYDQBBLyj+YxvKw9UPNMz+cjdYAro+EyxNdsLcN8qzVbH
fe+k/Xr6ZzUIMF2A5Xakl0uyr8HZIvhcqNgVbIPnTlkdQ0lufyxAXqgOFmPqBzJb7HOoXiuwAaIO
bCPBmd5v0QW7JpAZBLyK2yPsDy6Y1PXmgrpznpsDEj62L7j2sP6kCnj7c5YtCdVbCl9pxUedJfYM
KhtvwNuZta9bStF/9FJy06wdi5E+1GOvMuLTyh2SfmKIcXTzINfruBH76bnkaf++oitLi3qVcvsM
t08DMhAAARAAARAAARCYfAIIeG9bG/NX4uRUbT68mF1eqLvAhcqNHXkuMY2b9gI8VcCrrQpf6ZPO
/rZefCpXqqmWvgiPTJJeX1KVIOD1LfDDR5Nn2uEavOsrbT3tuu3qWu+Er4UhvZ8l9vBlr7us5mem
9ZTm2WBFYz2K6xbkyqtZXW9vfVnNTsdev8MCvDQMnY4NEHVQFAl4tYLhMBgVZAFvBp52XyagDOsz
dUZHG62ehI/tC1kC3ooLzHpqaWGGLVQWfZWOxJ6BD+MMeNn7dnWbL62sqOWlZbW8HH6WlpbU8koY
zLuVmnUbl9nrw1YWqq49otPwe5GF1Baqg76Wr8zr54T5Ntti+pvdCKl5n31guizJ+5j3eWemiyQI
gAAIgAAIgAAITDIBBLy3s3X1xaybQqkvmnP5vMrn+bOtxWDF190x0l3Apx3VFNofnc6bU/lCUZVi
73eNB4fG897KHAua9CuEdLmC41QJn5vUum07GhyMvvWf5XW6OhjUiwzZkJm/5iUaMOZVpRq84kiz
sPqiVmCBypBPvUXW7nYRJ127kGdoz7qasYsaGb/dq6NCDZtKy2co4LX+sBsAUZ1winKUpQnAB5+6
fZbZGqO/09ozKBLuY4gpqzNbMqzb2uv9zlXD/qBHX+3CVEa3UJ5W0/b9zX2fw3f0GpvCGzchk+F9
5INFvQIv9I0Tuzp2ep9Xw1ckGTvyzOZscFAKBEAABEAABEAABPYsAQS8t7vpuouqWrJTccML4Vwx
uirybpjpplFLnhUU2N9dbKpycdjXwUW/fk1Rc9GN1sb97XaaqmjfWxwEUKZcsTIXW0W3p9qNSiRA
tkFFvlhWswt8jVv9uqKZ8N29fb18STX1a6B6neAZzWJ96B23cdu8eR3UlgM7fc9wdtw7XqOjnkrA
k++XL2w0+h2t6fjYvlAKXkGkrD8s4HU69UVtSjcadLM2yhen1fxSODLK7da3MwTtpQP74NVTo32M
7iFdjr8mKTwObd9x38VYf9DtNe1mCrBy+WkVX1+qy9777OpjnAYyvagXR8WeK5YsWBVOF9c30vQI
Mv5AAARAAARAAARAYL8SmLSA9x2mIfWF4577W7t+hZa7RIdpk+jYfXTy3qN7ygeR/ZtrdH1llW72
DhJtdmnzwN108uS9dGBLjzfpxrVl6tJBOtgjOvreE3T0UFKhDbp2Reuu9+jg4WN013vvo+OH/HvY
vHGNltdJ13qY7jtxPIUdSfvcObmIZ6bdpucjrX5zc4P0+49pU3flA4eP6jbyc4/WOz57ovsZR26T
Ll+Yp+/93c/RcbpBf/+eX6J/fPoUJXbNcZgwVOcaXTz/HbpJR+iBMw9ru/AHAiAAAiAAAiAAAvuT
wHbCQ2nZJH2f3CczLRSX87xJ79mAd392P3gNAiAAAiAAAiAAAiAAAiAAAuMjwANG6V6kZZP0fXKf
zNgXl/O8SSPglbYi9EEABEAABEAABEAABEAABEBgQgnwgFHqorRskr5P7pMZ++JynjdpBLzSVoQ+
CIAACIAACIAACIAACIAACEwoAR4wSl2Ulk3S98l9MmNfXM7zJo2AV9qK0AcBEAABEAABEAABEAAB
EACBCSXAA0api9KySfo+uU9m7IvLed6kEfBKWxH6IAACIAACIAACIAACIAACIDChBHjAKHVRWjZJ
3yf3yYx9cTnPmzQCXmkrQh8EQAAEQAAEQAAEQAAEQAAEJpQADxilLkrLJun75D6ZsS8u53mTRsAr
bUXogwAIgAAIgAAIgAAIgAAIgMCEEuABo9RFadkkfZ/cJzP2xeU8b9IIeKWtCH0QAAEQAAEQAAEQ
AAEQAAEQmFACPGCUuigtm6Tvk/tkxr64nOdNGgGvtBWhDwIgAAIgAAIgAAIgAAIgAAITSoAHjFIX
pWWT9H1yn8zYF5fzvEkj4JW2IvRBAARAAARAAARAAARAAARAYEIJ8IBR6qK0bJK+T+6TGfvicp43
aQS80laEPgiAAAiAAAiAAAiAAAiAAAhMKAEeMEpdlJZN0vfJfTJjX1zO8yaNgFfaitAHARAAARAA
ARAAARAAARAAgQklwANGqYvSskn6PrlPZuyLy3nepBHwSlsR+iAAAiAAAiAAAiAAAiAAAiAwoQR4
wCh1UVo2Sd8n98mMfXE5z5s0Al5pK0IfBEAABEAABEAABEAABEAABCaUAA8YpS5Kyybp++Q+mbEv
Lud5k0bAK21F6IMACIAACIAACIAACIAACIDAhBLgAaPURWnZJH2f3Ccz9sXlPG/SCHilrQh9EAAB
EAABEAABEAABEAABEJhQAjxglLooLZuk75P7ZMa+uJznTRoBr7QVoQ8CIAACIAACIAACIAACIAAC
E0qAB4xSF6Vlk/R9cp/M2BeX87xJI+CVtiL0QQAEQAAEQAAEQAAEQAAEQGBCCfCAUeqitGySvk/u
kxn74nKeN2kEvNJWhD4IgAAIgAAIgAAIgAAIgAAITCgBHjBKXZSWTdL3yX0yY19czvMmjYBX2orQ
BwEQAAEQAAEQAAEQAAEQAIEJJcADRqmL0rJJ+j65T2bsi8t53qQR8EpbEfogAAIgAAIgAAIgAAIg
AAIgMKEEeMAodVFaNknfJ/fJjH1xOc+bNAJeaStCHwRAAARAAARAAARAAARAAAQmlAAPGKUuSssm
6fvkPpmxLy7neZNGwCttReiDAAiAAAiAAAiAAAiAAAiAwIQS4AGj1EVp2SR9n9wnM/bF5Txv0gh4
pa0IfRAAARAAARAAARAAARAAARCYUAI8YJS6KC2bpO+T+2TGvric500aAa+0FaEPAiAAAiAAAiAA
AiAAAiAAAhNKgAeMUhelZZP0fXKfzNgXl/O8SSPglbYi9EEABEAABEAABEAABEAABEBgQgnwgFHq
orRskr5P7pMZ++JynjdpBLzSVoQ+CIAACIAACIAACIAACIAACEwoAR4wSl2Ulk3S98l9MmNfXM7z
Jo2AV9qK0AcBEAABEAABEAABEAABEACBCSXAA0api9KySfo+uU9m7IvLed6kEfBKWxH6IAACIAAC
IAACIAACIAACIDChBHjAKHVRWjZJ3yf3yYx9cTnPmzQCXmkrQh8EQAAEQAAEQAAEQAAEQAAEJpQA
DxilLkrLJun75D6ZsS8u53mTRsArbUXogwAIgAAIgAAIgAAIgAAIgMCEEuABo9RFadkkfZ/cJzP2
xeU8b9IIeKWtCH0QAAEQAAEQAAEQAAEQAAEQmFACPGCUuigtm6Tvk/tkxr64nOdNGgGvtBWhDwIg
AAIgAAIgAAIgAAIgAAITSoAHjFIXpWWT9H1yn8zYF5fzvEkj4JW2IvRBAARAAARAAARAAARAAARA
YEIJ8IBR6qK0bJK+T+6TGfvicp43aQS80laEPgiAAAiAAAiAAAiAAAiAAAhMKAEeMEpdlJZN0vfJ
fTJjX1zO8yaNgFfaitAHARAAARAAARAAARAAARAAgQklwANGqYvSskn6PrlPZuyLy3nepBHwSlsR
+iAAAiAAAiAAAiAAAiAAAiAwoQR4wCh1UVo2Sd8n98mMfXE5z5s0Al5pK0IfBEAABEAABEAABEAA
BEAABCaUAA8YpS5Kyybp++Q+mbEvLud5k0bAK23FO0V/4zpd/M5VOvju++nBU/feKVaNz4795u/4
SN4RNV+/8BWqf/US5Z56hp54eB/0392mvkePl+uXz9PX/+o8ff/HG3To0CE6duwEnXrso/TYqeO7
TRD7AwEQAAEQAIF9S4AHjFII0rJJ+j65T2bsi8t53qQR8Epb0elfo5c/84f0jR8R/fNPv0hPnjrk
tpjE5rW36LO/f45+dPev0r+b/m06cSCyeduZtQtfoGOPvECUq9Lqt5+nSb8c3G/+bruD3NEVrNFL
Z4/Rc29qI/dJ/93t5th7x8savfqZAv3mi6ZTRP9ylQX69qfPRIXIgQAIgAAIgAAIjI0ADxilO5GW
TdL3yX0yY19czvMmjYBX2opWf+0CPXXsEWrofLW1Ss+fjoac7oKT8rTQfYPOHLUFd+Z77eJLdCz3
HFGhRt3XnqXtVH/plWfpoX/5J1SstejPnj29MwbucC076e8Om3bHVzfu9pXXv0Yv64D3GRPbFOq6
//72tvrvHd8At8HAvXa82D5kUOWK0/R7//JReudP/id9+/97jdb/t39Pn/v4g7eBInYJAiAAAiAA
AvuTAA8YpQSkZZP0fXKfzNgXl/O8SSPglbai1d+4QE8ffoTO6bw34LUBKRWo1X2NTm8nIrX7ZN/u
gjavA943thfwXnzpaco9d44K1Ra99vwdHvDugL8M475Ijrt9s9S/uXaNFr/3I7r7Hz1MJ6KTI/ZF
m4zbyZ08P4zbVqJr9Acffh99tk2Un2rSX37uCdrhCTHjdwF7AAEQAAEQAIEJIsADRqlb0rJJ+j65
T2bsi8t53qQR8Epb0erf5oB389LLdPChZ/QV4v4IeHfSX9uE++U7S0AqYTPu+iW2QHdAYE8dL262
TI5ml1r08ZMId9GPQQAEQAAEQOB2EuABo9QOadkkfZ/cJzP2xeU8b9J7MuBd0wubvPLKl+hvvvvD
fhvcc/+j9BuffHp3FzYRB7ybdPn8X9HwJdR9AAAVcElEQVS3rt6iD330SXpQz4C+cv4r9OXGV+ni
1Zt0/8Mfo0/+7ifoVMJI8I3LF2jurW/S91d+TIfefR/RpT+lFz6v54QmTGm+dukt+uuvf4v+e3/x
l3fTPSf+Ib3rnbfoXR94nM7GFgm69PLT9NAzeoS31qbXnn04Rb9eowuv/zm9+rVv0NUf3iQ6cj8V
fudZ+viZkynKplOR+JulP2xcu0BfOvcqfePiVW3/ETpy9/vpwQ99mB498xidDhbIuXz+9X57ffDx
X6eH741ehK9dOU9f++ZVuuuDA579/H++Sr/4T5+i3MEWvfhvv0jfvfkAlSpT9NgJovOv/BF98T9e
pPs/9gx99tmzFB3UTMfz+sW36Ov/7Qd0/y//Gp3RHeXahdfp3Kv/qd9/7nngI/T0J/8VnfYMl8rb
N10bWa209d/QfXLuuzfonbbgrVt0/EN6QSJzMMT+doOn2eUV3cbf1MekbePBMfmmZvpD3S3uoVOP
/xZ96hNntj3imOZ4zNq+xg/J8WL00/5l45OuPzsbNi/S0wdzerZMkRZ7f0YPRg81pxYm0tc/Tvu3
015pzj9Z/DVlruvj7C9mm/r3UZ/bSJ/b7jlC7//Ag/ToR56gJ07v3Dk6tA8pEAABEACBSSPAA0ap
b9KySfo+uU9m7IvLeb6f1v/21F+rXlbGL9+nVF9Qvd3yZr2lioEdekrz0F677VpgY0G1umZzV1Vz
A7trC4uqMZX3+FBUC0NVraiZsk83YJCv6ZrZX29JVYt+PoaZXgBmoLy6qGZqNTUzU1fl/EBfPzun
6jMzql6vDz56e7O9wirXydUFVUrgX6jM7QB/mb/y/tBTrZnkPqQXUVKDJgjbqzLcKKpVHbSJ5Wnz
+fK0KgXt3O+jRc2wXoq0da3NWkzA0+6jUG2qZrUYqXNwPORVczk4ArK2b7S1k3MZ6m9VckM2W37x
HVlfx8kzcky2OvqYHLYv7A9xC1Pm0x6Pujrrc6r2dbuXHS+uWKpEeAzU0vIR9OeVdlPVavpcU5tS
ueCcUq7W1Uxw/jHbFpbXo5YK6s/UvoL6s7VX2vNP4LbAHlNivlIYOsbC38pKcG6LIkUOBEAABEAA
BOIEfvazn6msn5/+9KdK8tnc3FS+T6/XU/HPrVu3lO/z9ttvK/7Z2NhQ9rO+vq5MRLxn/pbnpsMf
8/yUmmt3VKc9p6YLYYA31VzeHX8yBLx1Zqe9CClXa6pSCgPa3NQcs7+nmvwiPF9S9YYOdhqzqlIO
LmwiAW9X8X3kilNqtmn0Z9RUYXAxr5/T7dffXaiELBMC2L6N00GA3C+1oipBcGy2Tc/MqcVOS9VZ
QF4dRPfMB0lS5m+W/rA4w4LPfFnNzrfU4mJbzTdn1XRJM3I8Q5a+Gxrt2iDgtDxtftCuOVUoJl94
lmYWAygyntF9DPp8qVJXszpgsP3J2pOtfdO3VZb6lxdmVVX391q9psrBsWDtje856ut4eJqAiB8v
luFUbVbNVoN+4vpD3MI0+Wj9o45HU1vU59HtO9i77HhJY3FUJ2r/1nxk/dl3A8Tuw35PR242yeqX
t6+sfnl7KZX+/GNaQmaPuRmZD87l5uZlc6GtOp1FtTDfVPVKWRXKM9Gbo9HGRg4EQAAEQAAEHIGs
wa4pJwl2ja4v2DWyeLBr8r5g18h4sGvSNtg133ss4F1W03bkrFDVlwL8b0XVXDA5rXYl5N12wFtU
8270Ql9YulHZkloMBjXW23UXyOSnm5GLld5isI1dkPMAsFSLjnYv1qMBmup2VHN2VjWaDXfDIFes
9PONRkOZz6zePt8Jh5yXZsOR0VpkVJvZX5pVsTEZ3lAj0zJ/M/QHfUFYsMF9se4d7TAH0+AvvNiX
BryFmgloF90MAKKiautqO7E2kPKMXmAXVKMTjhTPTwc3TYozA/4Z2jdwPN3XNusf6o+xvXJfx8Vz
OCAyx+Sg/fnxFR4BMSO3yIqOR10X91k/qzC6fbW+7HjZwljv5vAYGASgo/lI+/NqZ16fY/S5Zqbi
Rnin6vqc5M4/DdVescejUtL6pe0rrV/aXiYgTX/+kfvbbVWD34ucakZ/IL2tCyEIgAAIgAAIJBFA
wJtEZszy3tKsC/4iU0KD/fKLv5lO1pBL4MS2At6caiyFF3Jmr6tuxLWgFoI4Zs6O7uaGg3g3ZdoF
vF01Y4PmYn0o6LQXZ74RNRd81NojAKyrWTMC2g8YtT3afHPHxHz0hAPVCkY8zQhp1gBB4m+W/hAG
IGkuCMOLfVnAW1aLpml1/7AXt8VgRDfaBnKetrxpgxl7VyRosZX5YMTewz9d+45o+i02Zanf+uLr
j2Z3djvR+HhGA6KcmmXnDXc+KdQjN5q2QME2y4/H0Od07Ss5XphhgmR4DOiXBW3BR96fnSG9dnBz
aHBjyMkjiSz1j9d+aXvJzj8Z/F2ddyO85oZJtbGgVnbhpzDSTMiAAAiAAAhMBAEEvLepGbst+0xs
UbV8P+Lr9qKJlC9A2XGzWUDj258LSPWFh32G106fLNbNCGD0j+sPAt5lVQlGtMuNpaiyzjl9G/Ay
eyrzw7f37cWZL8AYtS3ccZeNoodTyO3UQ/ftCbjCOkalZP5m6Q+tqp0Gbp/THWVPeLHsa984M5vP
V4Mp4O6GSEHNB3cArM6gDeQ8bfn89PyQ4UP9gWnYcr62Z2qZk1nq36qM3T5OnjzgLdY9N3vMsyNZ
qWQ4Hp3PqdpXdrxkcyM8BrbmI+/PziZ2rCQ/EZGl/vHaL2sv84y27PwTzlpKe75dV00708POZNHf
xXJVP/6zK/OeXJMiAQIgAAIgsLcJIOC9Te3nLuhdABkzxF007V7Aaxet8o04c3sHAWx48TVaPwjo
u+EIoVff3gBgAa+1xzfC3Q4utnxBj71wK9QGz/fGyAbZ0H4T3BaKRVUoFGKffPbnxIT+cr7ei2RP
f2jXggvOVKN2ob++gNeNagbPRDuGQd6M8PbboxAuKhbVCetPy9OV97ST42H7A2vEUeWYWuZklvpd
Gcsrtveh7WPgyQNe3zEWM0mWtfaa0Xg2cmwr8R2Pzuc07Ss8Xux+Zd9hH92aT6ibtj87Wxwre3PQ
bWGJLPWHZcZhv6i9tCdZzz9SnsuthluzwZS1n1yp3p+Zw6AiCQIgAAIgAAJeAgh4vVjGL3QX9JR3
I2aRvbLpXL4AJaK7I5nwYso3+uHsdSOeob7PPvcMpg3G3EUgqeGLtdVwtNUGOE5/eLq0fhpMTQUX
PvrVQ0Pe2ws338hhqByOsPjqCPUyppz96fx1fAX9oeOeQS6ptm+WQMR03l7BHHO3XY+uBYt32RsI
lqHNpwl47QhOWp5D+3D2eEb82TZbbnT7sgLCZJb6bRnHK7bPoe22f4y4gSDlyQNe3zEZM0mWtfbq
qcDxxxeSjschn9keXX8fOt7THS+sKkGSHwNbPaiwjfODYzU64B1v+8rtF7WXpi49/8j9jTZtd3lR
L74WroBtAl/f7KJoKeRAAARAAARAQGVeodkEyli0ajs9iI1o+ALMcPXL8BnY7exu67LsAskzSrVi
V5T2BrzRAKq31HCLttjnPRX3NxakLvBX0tgLYKYfXal6PfoKJL2oUXTvenkl+9ocW1eC8wsVu5p0
8Fxlgl4mMbO/KPQ3bX9Yd6+K0iPUnlG0qN1h+0YvEntqbjpcgdkGbEMXv/YiPjFAU0rKc2gfzOCh
gIhtS9u+rIgomaX+Ub6YnQ9tHwPPsQa8rD+nPR6HfGatMNS+rP5UxwurK31SEvDK+7Ozw7Zt0uyd
QFF6vEjbV1q/qL20D7LzzzZ4OrBBwrwaa4tV0Y3mytKiXnV/+HGYeHXIgwAIgAAITD4BjPDetjbm
r+DIqdp8+EzS8kLdBYxUbmR/7k7kW081ynYRp4JqLrEhQ70ap51ebAMifvFVmbO299TSwgxbaISP
POpRXPcKoLyaba+q3vqymmXBVn+qmg2oeovs/bhFNbfUVeurHVVzC00FU9tcAB466y6m9WjpjN6P
/Vtfaatms+14rnfChcOoVFPc5V53Wc3PTOspzbNDAbWtb/S30F9tVfjKprT9IXzu0bAr1ebVavCQ
Zq/XVUvteTXTaDl/F+w7LfMVZWal9rpLkVcwmTps+w5d/NqLeNs+2vm4jpRnvDzn6drQc9PCbdui
fXl9knSW+q0v+cq8XmCtN1j8jD0wa7dbvluPmOuAQtw/ZQGdhInKcDwO+cx26Bi79pUeL6yy1EkZ
Hzn/wBB7rGwR8MrrH6/9svYyvsrOP1J/23oV+Jw+L7d00MoOJX1gLKlKEPDmPTdnjWWmbP/3pD8K
PDwLyOjgDwRAAARAYP8QQMB7O9taj2qU9A+y/WHO5fMqn7dBp5EXVeS1jWO2tcteG2RsKk5Nq8p0
KQy+tT3h86XhxZe1P/5dj7zqR18e2VFi5vOgTF5VqsErglgAa58rjddruNTqwbtaWQBm8fRW5ljQ
TSpf0M/nOq6VyKrLbTsaHNjUf5bX6eo2yEX17T7SfEv9NaPg4v6wMu9WT7accvZ1V8anXLig1XIz
fL+t1bX8i7ERk6GLXzsCx3gP6WgoEp6+8pYrD4jCWxaDrZL2tfVJvrPUb33hXPnFuN3uAt4x8DQ3
oey00R2f0qwBSo/HIZ9ZI/jaV3y8sPrSJeV8JP3Z2aAD3sGK5lvPzpHVP177pe3V91dw/jH6En/d
olj9c3Oufx4vxd4H7u/nq6rqbq7qc2A+PAe6NkICBEAABEBgXxFAwHu7m7u7qKolO7XWBLmDT65Y
VYvxubq7YGunGbwOJrDD2mOCzCZ7Tyof4Q11Brbni9NqXo/IDv/p1/3MhO++7ZfLl3S9ekysMzPw
vVhnI6pd1ayEd+qNfq4wpRb0LDWnT3wUOdxjt9NURR74Bf4UK3OxVxz1VLtRiQTI1p98saxmF4ZX
lA73slVK6q+uL0N/6OmR62o5nJZs7TffeT1CHY7Vd1UjPqKeL2ueemQ+eB7YTo22U+pLwSuIzAhf
2TBkAa/TiazSnZ6nvcAuelYUdjdfirw/hLzTt29YRpKS1s9HlCx/PjXXsRojTz30pWaCGRDR90pL
PB+lKzse5e2b4XgZZe7Qtix80vdntzs3wpuwAr9TNAlJ/eO1X95eA0fSn39k/nYXm6pcHP5tHBxf
+jVFzcXoyO/AnP7/cDq3/s3Qsy7wBwIgAAIgsL8JTFrA+w7TnPoHcc/9rV2/QstdosO0SXTsPjp5
79Hb58PmGl1e/A5d+zuid9LfE917ij784Ek6FLFojV5+6hg90yCqzC/Tpx49Smvrm3Tg8FE6euhA
RDOe2bxxjZbXiQ5qb+87cZxGaxOtXb9Gq72B/gmtn/5vk25cW6au3tNBXf7oe09o25JKb9C1K1p3
vUcHDx+ju957Hx3fwo+kmuJyqb+mfJb+sLl2nZZXbmr7iXp0hO6667i3LSxP09tOinjGPRuVHx/P
cK+S9g1LpU+Nu/70lhDtBs909tj+Y45f2fGYrv4sx0u6mrejNW7+e71+orTnn0ErCPzVv0fXV1bp
Zu+g3kmXNg/cTSdP3rvF78YaXTz/Hbqpz4MPnHmYJL8a2+klKAsCIAACIHBnEthOeCgtm6Tvk/tk
hmBczvMmvWcD3juze4yyKgx4q60uPX/6Ngboo8zENhAAARAAARAAARAAARAAgX1LgAeMUgjSskn6
PrlPZuyLy3nepBHwSlsxsz4PeFd1wIt76JlRoiAIgAAIgAAIgAAIgAAIgMBYCPCAUboDadkkfZ/c
JzP2xeU8b9IIeKWtmFl/jV46e4yee1NPaV5YpU+fQcCbGSUKggAIgAAIgAAIgAAIgAAIjIUADxil
O5CWTdL3yX0yY19czvMmjYBX2orb0N+4cZ1+0O3RXe/Tz8Zu9SDuNvaDoiAAAiAAAiAAAiAAAiAA
AiCQhQAPGKXlpWWT9H1yn8zYF5fzvEkj4JW2IvRBAARAAARAAARAAARAAARAYEIJ8IBR6qK0bJK+
T+6TGfvicp43aQS80laEPgiAAAiAAAiAAAiAAAiAAAhMKAEeMEpdlJZN0vfJfTJjX1zO8yaNgFfa
itAHARAAARAAARAAARAAARAAgQklwANGqYvSskn6PrlPZuyLy3nepBHwSlsR+iAAAiAAAiAAAiAA
AiAAAiAwoQR4wCh1UVo2Sd8n98mMfXE5z5s0Al5pK0IfBEAABEAABEAABEAABEAABCaUAA8YpS5K
yybp++Q+mbEvLud5k0bAK21F6IMACIAACIAACIAACIAACIDAhBLgAaPURWnZJH2f3Ccz9sXlPG/S
CHilrQh9EAABEAABEAABEAABEAABEJhQAjxglLooLZuk75P7ZMa+uJznTRoBr7QVoQ8CIAACIAAC
IAACIAACIAACE0qAB4xSF6Vlk/R9cp/M2BeX87xJI+CVtiL0QQAEQAAEQAAEQAAEQAAEQGBCCfCA
UeqitGySvk/ukxn74nKeN2kEvNJWhD4IgAAIgAAIgAAIgAAIgAAITCgBHjBKXZSWTdL3yX0yY19c
zvMmjYBX2orQBwEQAAEQAAEQAAEQAAEQAIEJJcADRqmL0rJJ+j65T2bsi8t53qQR8EpbEfogAAIg
AAIgAAIgAAIgAAIgMKEEeMAodVFaNknfJ/fJjH1xOc+bNAJeaStCHwRAAARAAARAAARAAARAAAQm
lAAPGKUuSssm6fvkPpmxLy7neZNGwCttReiDAAiAAAiAAAiAAAiAAAiAwIQS4AGj1EVp2SR9n9wn
M/bF5Txv0gh4pa0IfRAAARAAARAAARAAARAAARCYUAI8YJS6KC2bpO+T+2TGvric500aAa+0FaEP
AiAAAiAAAiAAAiAAAiAAAhNKgAeMUhelZZP0fXKfzNgXl/O8SSPglbYi9EEABEAABEAABEAABEAA
BEBgQgnwgFHqorRskr5P7pMZ++JynjdpBLzSVoQ+CIAACIAACIAACIAACIAACEwoAR4wSl2Ulk3S
98l9MmNfXM7zJo2AV9qK0AcBEAABEAABEAABEAABEACBCSXAA0api9KySfo+uU9m7IvLed6kEfBK
WxH6IAACIAACIAACIAACIAACIDChBHjAKHVRWjZJ3yf3yYx9cTnPmzQCXmkrQh8EQAAEQAAEQAAE
QAAEQAAEJpQADxilLkrLJun75D6ZsS8u53mTRsArbUXogwAIgAAIgAAIgAAIgAAIgMCEEuABo9RF
adkkfZ/cJzP2xeU8b9IIeKWtCH0QAAEQAAEQAAEQAAEQAAEQmFACPGCUuigtm6Tvk/tkxr64nOdN
GgGvtBWhDwIgAAIgAAIgAAIgAAIgAAITSoAHjFIXpWWT9H1yn8zYF5fzvEn//wAAAP//HJfzCwAA
QABJREFU7L1/jFvXdSd+AlheSWvJkWQ7qWJBm2rryN/aDKLAULqw4qUSoE6+X4RGkKJFlka/bgDa
xS4cfvOHgzG6LjoFajAFtmFQLOgFtjS2ZpAs3dQMkKVTZOJ61N1QCKjAVBG6yTgdQaWwGdmjDScV
x+LY93su+e6P9959fPc8kjPk6BKYeffdd+6953zOuT/Ouz/eexj+wP0cAg4Bh4BDwCHgEHAIOAQc
Ag4Bh4BD4KZHYBz3kJo2it4Ub4rjygrG6/c8/B785xzem96sHQAOAYeAQ8Ah4BBwCDgEHAIOAYeA
QyDsQFIwobqWUfSmeFMc5y0Yr9/zsHN4KRp0tA4Bh4BDwCHgEHAIOAQcAg4Bh4BDYBcjoDuMVDGp
aaPoTfGmOM5fMF6/52Hn8FK16OgdAg4Bh4BDwCHgEHAIOAQcAg4Bh8AuRUB3GKkiUtNG0ZviTXGc
v2C8fs/DzuGlatHROwQcAg4Bh4BDwCHgEHAIOAQcAg6BXYqA7jBSRaSmjaI3xZviOH/BeP2eh53D
S9Wio3cIOAQcAg4Bh4BDwCHgEHAIOAQcArsUAd1hpIpITRtFb4o3xXH+gvH6PQ87h5eqRUfvEHAI
OAQcAg4Bh4BDwCHgEHAIOAR2KQK6w0gVkZo2it4Ub4rj/AXj9Xsedg4vVYuO3iHgEHAIOAQcAg4B
h4BDwCHgEHAI7FIEdIeRKiI1bRS9Kd4Ux/kLxuv3POwcXqoWHb1DwCHgEHAIOAQcAg4Bh4BDwCHg
ENilCOgOI1VEatooelO8KY7zF4zX73nYObxULTp6h4BDwCHgEHAIOAQcAg4Bh4BDwCGwSxHQHUaq
iNS0UfSmeFMc5y8Yr9/zsHN4qVrcYfqrb5yHV793Hn72i03Yu3cvHDx4FE6c+QScObEPLr3+U+j2
/QwevPteOH7oFn+ku3MIzAgC0fZ8aEY4dGw4BCaPwNUL34byd16H1COPwcP33zn5AlyODgENAWdv
GhgJgxtX3oCf/u/rcOSDv4Zjqr0Jc5nPZM5+5lNv43KtO4zUvKhpo+hN8aY4zl8wXr/nYefwUrUo
6bfg/PPPwl+8tg5H9u0bxvbwguH3vv8YpB48A588dQIm52puwItPZ+C3nn1FciACqUIDXvt9gA8f
/Bi0RKR3TRWa8NpTpwKx7tYhsNMIxNjzU6d3msGxy79y7nn4oxdegyNHgu3DXXDyvgfgzMdPgXsX
NTbMc5jBBjx39iA8wZvyVBHWX3sS3OudOVTj3LDs7M2vKsPYzU8g73q9t2DfySwsPn4GWl87Cx/9
4iswGG/tgv5JChkbcPYTC9EuJdAdRqqI1LRR9KZ4UxznLxiv3w/C+M/9EiHQZaU0MI5x5F++yrqJ
8g4naldyspxUdpFV63VWq5bZYi7DFqptxvqrrJTPsVwuz/L5rKTNFJvhzLY5RvCeLe08L9ss+kwU
N4v4C5543THa80wgNx4TzWJG1kNzG5FjzfXxynCpdx4BYcv27VuXlUXfkSlPrI/YeSQcBxwBuj3Q
cKPn7+zNj/A6K6ZGjNtCY7oC4810qzQcV83CmMovz7TvnP1MG+FZzf/dd99lSf/eeecdRvnb2tpi
pr9+v8+Cfzdu3GCmv7fffpvpf5ubm0z89Xo9xj1i90uEADYCmWGjmcqXWavdZq1Wk9XKBZbWGszC
8lqi3P2JOmzRa6DTC3XW9z803PUkb7PQON+8HYVBNTsQNXv4U+15B0CbQJECd0jl2XKrzdrYPizV
yizvtRsDJzhTGgymJlCcy2KHEBB6prS1/W6HtZot1untENOu2KkhkMQeKMwkyd/Zmx/h1UadVatV
VqvVhn+VAksNxm0pVqh4cfhsQNNYGSROgru/1Pm9c/Yzv7obh/Okzi5PR3F2Oa3J2eVxQWeX35uc
XR6nO7s8LJxdfnUO7ziWgO/lhcObKbX8OXVbLOc5vZRBkD8T7a7bZBmvMa6uxru7DHkreYPqiZSv
sZIkeDN3FEnwmnSamcOfbM+TRmR78hO4Azq1fr+mz5YLYvY3wxqTWgayPWK5UgIICD3PQlsbYM3d
7gAC07aHaee/A5DtfJH9FssOxlhZ1ooYYjncd15NjoPtRWC3ObxzuYd3Aw9u+vrXvwF/95M3cZIE
4I5jD8Bnv/AoHty0nTuhNuD5Rw7CYzUAHOjAS0/q+2SvwtPvuQueRd7S+Oz7vmec4w248PJfwYvf
/QFcfvM6wP5jkPm9x+Fzp4/zh+Hf1kV4dE8KXoAstPt/CSdjNwaP4i2cPZkfzGLzygX4xgsvwg8u
Xkb+98P+I3fjvsQPwwOnz8CpgB5ef/5RuPexF3Dc34KXHr/fxMDYcRR+bOxn49J5+O7/vAy/+m8f
gdSeJjz7B38OP7l+D+QKC3DmKMD5r/8n+PP/fhGOfeoxeObxs9An0vuPvLCzh6sXz8Gr//BzOPaR
34TTJw7AlQsvwwsv/jVcvHwd7rjnQXj0C78Lp476c+bAUvG/+vo5+Fa1jvULdQuo2zv2w90fPAkP
PPgwPHwqwkYpGiTY86XzL8MPL9+ADz30abj/zlvg0vlvwzdrr6DMb6LZ3QEnHvod+NLnT/v2yk9D
v2FU4wW++NyjkHriBWwEStD9/uNwQE+ycR4ewT332HxAsbkOT54atl1J5OXZXkGd/e2rP4J/Ghxm
dzvccfRX4LZbb8BtH3wIzhoORbr2xgVYOvdD+NnaL/Dwu9vh4B1H4PBtt8Kth34dPnlmePbAG4j9
jzTsfexze//hZTj8IVP+dvas5xcXptZHv76o/NDobevXNdTR0k+uwa1C2Bs34NB9eODgSXO/lbS+
8+xt9CvYsLtuwRvnvzewh/s+8RngLA/r4ncG7c+x+z8FX/j9zwM2S75fMnum4U9vr+zyT4q/rT3o
QFHqr23+VHsT/Ni0n5w2KT6inJm6bl6AR/d9FMdYGWh2X4JTATvmvIr2PFPEccyT91v3v5Tx1XbU
F1vck9oPvT7acZTU3mzt2Y6Lm4sK3evEAlPTRtGb4k1xnNFgvH4/COO/ufo1y/nIfXG5csNiue+k
xNVmeIP7ZPttlvdmeBfqHX+B6w05+8v1o/9lCks+/tdadVYqlVm5tOAttwGWL5ZZpYxx+MefNYxr
4kbw5ueGMQI/w6R91qxE6wAPYRku0Vxvs0qpxCoVXMLp7VfjezXLlcqAd85/GZ/XW+Mu+bbkx5Pb
1n6axfRAN+n8Isvp+32yyHNZ7afm+iu1uoxKL9VAwF+UkSnWWb2o9mkrG0qzesd7PZ0QfzXz6LfN
YRnDvUySd2KAbs9dudeq1FxhtYWUr74MeBL2NmX9EkUdkIsZAXR4Q/s0+52arNPVFTH/S5eX790v
Zk268rZbFBoB1tdYJT+0bWU3WnqJp+Kl0AhvNBa2iAe4+PMn2LM/4eg7UZ5tfZS5UfmxpU9Qv5qF
sP2G8JOMM9mmWNV3mc5WvzKBZUDZQ6nRxrposqEs85uKlsay/lL7I3J7ZatfREXYnBX+CexhALxt
/U2QP9XeOD+2/eOA1usjrfAZCDvD/3pNb4Y3w5oRK25Ee54rLWH/K1boaG0naP2vEJVgb3xlnthb
bNvfUeuLYMvmmsR+yPXRhhGPhlQfRZqZ8RcIgs4Q6W6b4Z2rPbydpUU14E0vsKXWCltpLbFFbU9c
yMGcmvFoTqVvSXNPGwzkWEuMZQd8rLGCOKwEHaXFyhJrrzRZWRuAFrXW1tTgBAepi/4RhietxlvQ
GffhQeOHJxUHZgz4SOdZdbnJ2u0WW65X8QAtHNB5g/tuo6B0FXDsfTIsBgbMPv7ib2z54TlR7Ed0
bkNeUyyTNXVww84uV8H9296BFrb0Q8lo+PvL8MoulFkVX4gITMWyykT4Y+cs9p/zlxP1RoutrLRZ
Y7nOyoU8y+QrIcctXkOKgm7Pyo6FfPy6UKqyatF76aA5k9PUr5LCPiT1pfEoUiu7zbKmbCNo8vIB
kthWwXFJZRcGh9nVaxW2kBk6V8IehuX2WV1/aZDOsXINX57UqqyQ9+wbl18Px3sqb5yBFmzLq5DN
nz/NnmVmFgFR3tAO4uvjMEsqP/b0SepXp1FlxWKJlcoluY/bj58fCL/Mo+v7MCVFv/6y4u+UPeh1
MY/yFHLK+U0tLGlZmdNE1V/G7PEfFEJur2j5U/BPYg+U+pskf6q9UdpPjj8FH80oZjNIcHh1+88F
+t90UR/P0OwtaA+inInVFyLyVPvhzvc0xw9Ue6PaMxGem4LcObw7pmZ10A2uIcauUf+tyT2rAIss
MKeqE04wrHXmGTw1GQ9AqFYrbFGbbSks+zlZraqZ0ZJvEIl5iXS5qtzvt76yjHniAQryQAUc7JfV
QQv8WWvNtOFE8TZqQEXlhzdow73EOPjKlo2H7fAN5YNfd4XV+aEQ9Zp8IZHKFgb34qAIjtnySngw
ba0kCj9oFeLgLxv70RvXTKmNLLW9N8B84Dnc57NSVqc2Uum5jFT89TJwIT2rrahX0cuL3qAzWxna
TwL8u82i5zinWN1fwaxVMoqQbs/Kjoedf5YtezPY/XZ5yCs6k0MLmq5+R8kV9UzqC0/ilT4tEq8u
l+QLChD6GmRCkdf/AidX8q9uaWu2KfjrtTzM0DlOL9Z9Ly90PJM6vFR7FnzZXCWWyLtNfeR5Uvkh
0SeoX7qcJv3oz3lYlzm2viM9Tb/B0uLuTbYprBqfif4LcqwtogMvZHi7GV1/6fqitlck/VLxT2AP
+oA8tv4myF/XaLy90dpPnjfVPnV+Zi5Mdngj+l/ZH9HtOezwTra+jIN5vP0g91MeP9DsjW7P4+Cz
W9M6h3eHNNtfrcpBIl9CGvzpnX1FLhEMUk3yPjgAGL6BF2/lyq2gI9djVT4DigO2gVOOfiE/NYz/
4aHbrClmCLUGU3JrcaCCpB0EFG/RDi+dH9VB0xwi2Vj6ZsL9HCe5o/BDtR/VuOZZm/vw2CEKZz+L
M7r8J2g4xiIMYEePGZLtQZUBrKJGlQNe1pa9GXWD/Vjjv74s39DyAXax1mBrcvA6KGYy/6ztWdkx
frCUqaW/2uDe+6zLtPWbRHClrwwr4PL9YmGBZbUVHtxW/CtA7OXlg6OKcDKyZZ9DzXkVZev1f0nM
7qbCLwW7Lc8JR/tJ5vDS7ZmCqZBnevUrOf/W9UsTWMij60d7PAgKGt5n2NR3mn6DpcXd+22zFjg8
cV2u6NEPYfOnGVV/k7SHjNRe0fVLxV8gaGcP9PpLy19QD69Clih7o7afPFeRp619+jmasTuiwxtZ
H+UKGbq9+R3e0f1dovoyBuRC11H2M8iaVB/pzAgebOwtiT3TOdr9KZzDu0M67jbFrIi+BFBjpidO
2QNmWoKnUU4oqHXmmQVWwdldsVeVD86DDSJvzMTJyUOn1+8gyziDw8KdreEJgtH7S/xCKd6iGyg6
P/K7omlvn66/0Mg70VBF8xKZdOQDCj9U+xE8yyVKmg6WvXcZgobLJcK29EnsQZaxuBzCJeywKBKR
Lh7/HquLmeLBi5mhjWbzRdw+4F+toHJPENKw1FbwGzJSdpwtt8LPcTWBWN8wbf2GC4+PEbjLuq1h
mkZM26H3dvby6i9gTJ8+E2UrnXdYwduLnq+thpgP24/ixdSehvOntychJkZEiPKmV7+S8y94U1iP
EMR7ZJNG0KSt6jtVv/E8+imUPWTLwxd++nNpP/iiTJ06rqcZXX+TtId80G/fXtH1S8NfoSHSjbQH
bAPFC1S7+kvMX5EPQnE8UdtPnqnI084+AwzN2q1Fn0STl25vusMb198lqy/JQReyj7RpUn2k8yJ4
sLG3JPZM52j3p3AO7w7pWO9QjYNk2WBtv8MrP0ukHUQDoVkU1fnzAXAmm2WZTCbwlzbvk5SyTdbh
1ff/2fDTKol9fmVvFsjOGERDlSk17RJYUlH4odqP5FnsgRY6kG9wVYfPOwEqvd652dqDLMOAo5RP
ztApEEelU1Qq1GnW5B5Q3VlL5cpMnImlqBOEBJY4ODbWZZmlqjOmVR2SDANS/qg8ZZnD9kFiYqlf
vSzbsCgDUjlWXcKDTupLrNFss7WucNODOdnLq16C4eyfYUVLyztURQ5Q5KeghoeshUoWLxSl/She
TA6vnMUS+GGLQG1PgjyMuhdYSnmEPiPqI71+Jedf8maol1EyyTQSvzClpDHkK+1d6Ius33B5o2MU
Pqa6KPnBZcumPemmNP7yVP627aFIb9de0fMn4S+YweuodJJM2C+fvbepvzKhZf4aPQ9KniLsTekv
ok3W+BXtgczTxj4D/MzcrZQvQn4dQyt56famt1nTrC9JsJe6jrAfPU+7+qinsAtLHizwT2LPdlzc
XFTO4d0hfSsDTjMxw+ZjRVtOIRpk3/OJ36gGTQ7CsIymcAqxI8v6ZqXUGz/pINvyZNEY+7My8xak
ETPOtvysyD3IwcO4/DkH70RDZXozF6Sl3FP4odqP4FnqVuggYoBNpeedGxX/UBkaWFI+MQDWnol0
VPy7nTYeDqVOCOcDUdPsjlaUXVBgGeWcylyUHcfVaSk/npRp0z4ITGz1K1kiBEQZENjDG52FvbzK
4U2x4PJS3D3GFlBXA8dBbCOQmJsc3nVpi+LQOX3wpR+kN+QdZxO9pdkSvwT2HI1D+InAUpYn5Imo
j/T6Ra+PgkvBG6V+iTRSHpGZdh1FI+1d1HeBB+o9PFg26VcryCo42jblGQLeFoNhlqPT+ItNjr/I
Z3R7Rc+fhL9gAq8i3Uh7kPqyrL/U/DV6HhQ8RdmbtCfL9jMuT5mfsM8APzN3K/Vh4fAanL6wvHR7
87e5wS1xQcSS5B/Mw/4+zn5MOY2uj6YUo+NG8RDEX94T7Hl06TfnU+fw7pTetTfYfkdyyJA69VRf
UjVNZlVn7u9E1GATP8DJlrTDfxoFcZqlt8/Tlj2LxtifVRRvfioqPz2xzw8HVZTZ2rb4jM+EOz8S
P0T7CTWuQgcRA2wqPdcEFf9QGZo6ZQNvwHhs/Pv46RvvJHS/rWsMUIICywk6vHhihlwiaNM+hLAU
PEXolyKeoBVlKCdSPIm6qnob5+Dr8vpPptdPiUenFw/FGqyc1vERTrDHRkP/xJW0HzWg8r/k6LOl
RXViuW4PVHuOQsEUL7CU5Vnoi8oPlV7wmaR+heQRmWnXUTSh+k7Wr1aQVVC3Tf9a/P6q+sSWON9g
mKWeJm4AT28PI9mOaK+o+iXhrzFjZQ+avqzqLzV/jZ4HR8kyINX4sWk/4/IM2eegEP+/tdU2fqVC
GyD5H2/vnWhPRvRJozA0yUu1N5rDO8H6YoH0KNljk0fUx9h0AYJRPITwT2DPgeLcLSLgHN4dMwP9
kwspVtJOQO40yvKblpCvyX1902VVdeZyEOYVqPYPDAec4tyf3oo6eAtyJbYqHmC6frfDliuLuKS5
Ohyg6sxbNMY6ud5wpheXcGdFf3hAljhB2SOm86P2ifHZo1xpma17qzP7/S5bbS2zSq0Zwl82RvgC
oKId5tVba+Eyz1aI3i/LqDsKPzT7CTWuQgcRDhGVnktFxT9UhgaNxFg6LOqhfBaDfwtP9k2hXTZx
EOJbdNtbZQXP4U0b3m6rkixDAssRg4thTqqOxTqAyLH65E58+xDCUvAUoV9LyXxkooypOLz4re+c
N4vLT79dWu2y3voKK8mD8YYzvLzsoauBs3zywKw0q2I97Pc6rKo5r7xOgyZ/o+A5tukC46su+91V
3yfUBjPImj1Q7dkHVsyNwFK2tRb6ovJDpRcs29YvQc+vQp50YVm2z4HmWdJImbUMZJmyvtP1q2Vn
EVR1sbAk9vP32Wqjoh10F1z5o9LE198E7SGxvaLqV+jIDn8FodTNqPaWXH+J+SvyQUjIEm1vtPaT
ZyrypOIzSOudIs/bEJODPWB6O/+J9mREn0SVl2pv+rhtGvVlHDiF7NH2g/ZArI9UfgQPdvZGt2cq
PzcDvXN4d1LL+NZGDfLwu5PpNEunxcnHfIAX/PD9NJlVMyDhCoiVLa/4WpQDBN4oeN8P9Qarg72z
ugypQvhzP9gYDw+4sJ29VrwNBrFiYCwHRwoXMj9ry3ImTeSd8g7DGdynwgda9deWtEERfhIlg/uX
pcwGeRV78SEKPwT7CTWu4o2h5hDoNHp4wHQMvRCMgn+oDJEJXuUgSzo46qEt/vIQsIG9pAZ6ygW+
P2zTEauSI0LW9qzs2KrcKeo3QpKR0XKPuaHemRPS5BX7aEU9VNcsfuvV+zazZq/qVHPPGRbtAg7M
C7h0fZBe47VTV993VnnztGmWjZjxp9izGQNzbMj2p1C/eMlJ+LetX7pkQh4d1+DLJEET7l/M9Z2q
X52f+LByXnWe9XDZ96k9niPNnnkKCv5J2itK/lT8Of/8Z2sP1Po7zN0+f0HPr0IWXV9Be+OrRijj
K5GnrX0qftZZUb58w/aEeAimymeCoQk6vPpaBoq9Tbu+jIOW0PUo+0lSHyk8CR6s7Y1ozxRebhZa
5/DutKa7bVbUPnQvKmAqazr1dJrMqmPns4ElgoNSsbINT1bmDbr41Ad/0metWsHnAAoZ0tk8qzbC
J6iq/Xr6gSCjZOuxSi44qMV73/4qkZ7OTx9nZot5taxR8M+vaZyh1iauRSGsu1JnWd0x9gbb2QKf
gR7vR+LH0n7EEvmc9wkihm/k85xnzYGQNHhqqQxb0iuJ7fEXDX7Wtzd8mFNXfGM1Ww6vEEASG/y7
7TrLZ8Wy+6D94GeK6m3/zK8SghaSg4s4e+Z2PHxx5P9u9YjipqTfESVGPhI2Ya53pmRUebusXhh+
C1rUwRSeGN/AVYL9lcrQgcXvoqpPH+HnzyrqW+CDNOkczg738BPb4rNW+gurLqsFZ4DTecwfZ/a8
/fzhrQ329mxCICpOYGlbH1U+VH6o9MOSbOqX4ok7dn69cV0E+xF6fafqV+coLhzt8Kazi2wZVxiE
f1R75jnY45+svbLPn46/QsDOHqj1l5q/orextwG1ZfvJacfBRy33xYkLXOWw4z+9TzKZcmJ57e2N
nzpO7u8I9WUcjG3sJ1l9tOcqkb0R7Nmek5uHcrc5vO/hqsPOdu5+G1cvQacLsA+2AA7eBcfvPDBn
MmzClUsd6Pb6sGffQTj8vrvg0N5bdlAGOj9bG1ehs3Yd+Qfow344fPgQHBgpwxZcu4Iywx7Y0wc4
8L6jSD85kSn8zJ790PGnI2eJ/9YGXF1bh+v9PQBbXdi65QgcP34n7KR1UmWdPf1SJbCn37h6Bdax
Pu3B1vDo0UOxCbeuXYFOb0h/F9JzvZ7747Pw8WdegdRCHZp/8rBP1yJ/3toet8h/yMB22HOsqBoB
lR8qPS/Ksn5pXE0jSNWvHQ8b8PwjB+GxGkBhuQNfeuAAbPS24JZ9B2LafLvcw1QE/BO1V4T8w8xZ
xtjZg6hftvVXFW6Xv6K3D02//dyAi+d/DNdx3HDP6fshvtWy5302Kadtb9POn4BqovpIyD8B6fTt
OQFTc5BkHPeQmjaK3hRviuNwBuP1ex6eW4d3DmzFsegQcAg4BGYDgc3X4StfrMJvPPUf4MwJ//Dy
6oXn4ZMffQxayGmuugLPfe7EbPDsuLBHYOr6VQ4vntoNT56atxfM9lA6SoeAQ8Ah4BAIO5AUTHRn
0yZdFL0p3hTHywjG6/c87BxeG004GoeAQ8AhMM8IbJyHswc/Bq9wGdJZWHzkQThxEODvf/BNePa/
DGLxQR5W+n8GJ+ZpKn+edTJJ3qeuX93hXUeH1//SZJKiuLwcAg4Bh4BDYOcR0B1GKjfUtFH0pnhT
HOcvGK/f87BzeKladPQOAYeAQ2DeENi6As/9+yw8IZ3bgACZBWj850U4fdR5uwFk5uN26vrdgOfO
HoQn8N1IobEOT512Du98GIbj0iHgEHAIJENAdxipOVDTRtGb4k1xnL9gvH7Pw87hpWrR0TsEHAIO
gTlFYBP37/70J6/DP15eh1/euAG3HX4/3HPvR+DkcefAzKlKfWxPU7+b167Cz7t9OPwBPHvBvRfx
4e5uHAIOAYfAbkNAdxipslHTRtGb4k1xnL9gvH7Pw87hpWrR0TsEHAIOAYeAQ8Ah4BBwCDgEHAIO
gV2KgO4wUkWkpo2iN8Wb4jh/wXj9noedw0vVoqN3CDgEHAIOAYeAQ8Ah4BBwCDgEHAK7FAHdYaSK
SE0bRW+KN8Vx/oLx+j0PO4eXqkVH7xBwCDgEHAIOAYeAQ8Ah4BBwCDgEdikCusNIFZGaNoreFG+K
4/wF4/V7HnYOL1WLjt4h4BBwCDgEHAIOAYeAQ8Ah4BBwCOxSBHSHkSoiNW0UvSneFMf5C8br9zzs
HF6qFh29Q8Ah4BBwCDgEHAIOAYeAQ8Ah4BDYpQjoDiNVRGraKHpTvCmO8xeM1+952Dm8VC06eoeA
Q8Ah4BBwCDgEHAIOAYeAQ8AhsEsR0B1GqojUtFH0pnhTHOcvGK/f87BzeKlanFf6zatw8ceXYc/t
x+DkiTsnJsXVN87Dq987Dz/7xSbs3bsXDh48CifOfALOnJjNz5xsbVyB9upbKP8e+Ff3nsTPa2zA
GxdX4TrGHPlX98JR972NidmGy2j2EHD2P3s6uSk5mlJ/tJNYblx5A376v6/DkQ/+Ghw/tHcnWXFl
OwR2HQKufm2/SnWHkVo6NW0UvSneFMf5C8br9zzsHF6qFueUfuPC1+DgR78IkCrC+mtPwvju6Aa8
+HQGfuvZV0KIpAoNeO2p06H4WYi4+NwjkHqiNmCl2OzBk+//G3jPBzKD+3SxCd9/8pTH5hacf/5Z
+IvX1uHIvn3DuB5eMPze9x+D1INn4JOnToDvc5Rbl+C5Z74KF97aB7/99DNw9vjoQc/W1XPw7B98
C9aP7AOvBK9sfulB763D8Nk/XIAzR32laDSjglfg+af/FH6Avv3//dSz8JkTfl62rpyDZ/7oBXjr
yG/AHy7+v5CoiFHFz/Qzg24j+O313oJ9J7Ow+PgZv64j6Gc92t7+Z10Sx988IzD5/miSaCRrH1pf
Owsf/eIrMCv935Vzz8MfvfAaHMH+xfTrvfUWnPztp+Hxsx8I93WmBBin2sPfgCa1f4zI00U7BGwQ
uDBj9cuG53mn0R1GqizUtFH0pnhTHOcvGK/fD8L4z/1uAgS6rRLj9gCZEutOQN52JTfMD/NMZRdZ
tV5ntWqZLeYybKHankAJ08lC4gAZ1ljHMnotluW44F+xySPEr8tK6WH8ADePxhfOV/1YdpsMXWdD
XiJP/7XbLEoMfflqZRUGTPrTWd3F8KLKTrPGJAzCiqlZIVpnxVSMbjUdABSYbhmzIkUSPuztP0nu
Ls08IiDa8mypuW3sSzucUH80WcaTtQ+tUnbQnmeK24fjKLmbhVRs/wKLDcwiibwJ+sdRzO7iZztR
vyYJ56zwv131a1bknaQOk+b17rvvsqR/77zzDqP8bW1tMdNfv99nwb8bN24w09/bb7/N9L/NzU0m
/nq9HnMzvOhp3Ay/jYvPwcHUEwDpEnS//zgcGEvoK/DHH/4APNPC7Bbq8Dd/8vDczH5JHCADje5L
cHrPBXhk30eBz/kWG+vw5Gkx970Bzz9yEB7DB6l8GV54/GMA/evwj83vwVcf+zK84uFXWF6Dp854
S8Q3L8CjmNcLPK8m5nVK5GUGW/GShvJyET72XixCI+3398AHUyfhUJIJ3hheVNkZaCIOp8YzCI3r
+QheOv8y/PDyL+HWW28dMvzL1+E//rsvQwtSUKj8MZy8bRiNjSrceuwj8JnTJ+ZDsBgudb2Ptv+Y
jNzjXYPAxecexVUvLwA6avCSXOEyXfGkHU6kP5o8r0nah53AcZTkm9cuwY//8S3Ys2c/wPUL8MWP
/Tvst9JQwb7mFPY11/t9uP3Y/wUn7twLdHnvovePo5jdxc9mzS6oUM8K/9vFx3aVQ9XDTtCjo5y4
WGraKHpTvCmOMxqM1+8HYfznfjcBAv12efi2Nz2BGV45e5hi1dX+fKHXbXizsHm2MmB9nZUyfLYv
zZbWdFG6rDyIB5YptfQHjHVbLOfNAPre5veaEbPF/uTiTs5y4GxzsydiJ3SN4cVX9k03w2vAuC9m
+rOsNWcmbZAmOsra/qOzcE92FwLbNXOiozbR/kjPeFphi/ZhJ3C0Flfyb9nXSPqo9jBB/2jN7O4i
nGm7sIB6VvjfLj62qxwL6HecJOnsLk9Hmd3ltKbZXR4XnN3l96bZXR6nz+7ysJjd5Vc3w5v43cUw
4dWL5+DVf/g5HPvIb8LpEwfgyoWX4YUX/xouXr4Od9zzIDz6hd+FU0f9eyeHKTfgwst/BS9+9wdw
+U08Lmn/Mcj83uPwudPHIzii0gNce+MCLJ37Ifxs7Rew9/a7AF7/b/DFr74CuKQZui+NOcO7dREe
3ZPCmcwstPt/CSdjZiA38GCrr3/9G/B3P3lzIN8dxx6Az37hUePBVsM3zTfgQw99Gu6/8xZ88/xt
+GbtFcT0Tdi//w448dDvwJc+fzr5jPIGzugexBldObOwAc+dPQhPvOLN+MqZTjXDG575uApPv+cu
eBal8e37jZlVDSpXznLgbPPEZ1ljeBlV9tXXz8G3qnXU12VkeT/sv2M/3P3Bk/DAgw/Dw6fMNnoF
0/ztqz+CfxocXnY73HH0V+C2W2/AbR98CM7eHz4kzWefe2+Hg3ccgcO33Qq3Hvp1+OSZwN5ooNt/
EOvYe4mXWRdXL34f6/o63Hr4Pvj02ZNG+9u8cgH+5n/9DOB9SHPmX6Ptfg9+dPkG3PeJz8BJnOwf
2vJ3Bu3Dsfs/BV/4/c8DNhuGH01ekr6s7d/AFiGKYg8k/gk8CFLb/N/AWX+uL9H2iPT8unHpPHz3
h5fh8IcmYc+B9nnC9m8rr5Dv9ecfhXsfwxneUgteevx+ET3iSrNPnpGvvk+6PxrB6cQexbQPvBw1
M4Q4Pnn/FMcDCaSy4N+Xayx9gv7RVwDthret33jhRfjBReyT9mOfdORuOHnfh+GB02fglOGATJv2
J/n4jcY7pX4lG//Q66MNPkJKCv8izejrJlz8/t/AP/zyNnjo02cBh3kAW1fh3P94FX4Oh1UcbMHr
3/8f8Pc37ob/5+FT8FO5EoVavwB2Vt7RaMzyU/S4E7NHTRtFb4o3xXFGg/H6/SCM/9wvIQLNYppb
A8sU66xeHO7f4ffqL83qncB00XpDzg4qumGaTGGJBahxew2Rnq2xSn7IVzD/wf0YM7xrrTorlcqs
XFpgKU/OfLHMKmWMwz/+rNHxT1U2y3kNDx0bYLlyIyBvV+6tLDVXWG3BsAcpVRxzP+U6qxXyLI86
G3LaZ43yIsstlNiKj3XtDXZwT1a/zfKe/Av1jrKemFlVRTgMTXWWNYaXqLKXC5lIfRn3svZXWTHr
16tud3iAS0DsGPsM6pds/4HibG8lXjgDYpjxbldE/U5hnTZl2mfVnIdDtoK2pdlyo422bKqT2eE+
cj07orxkfWHtsbN/nSlCmGgPdP4JvCCpff5KX6Z986KtH9ue49rnMe3fWt71NquUSqxSKbO8d1YB
P4uhXKkM2nLenpfxeb3lW/YyU/0RzRLGpI5pH3juYmYoV1rC8YCpHZ3AeCCpGBb8+7KOpU/QP/oK
sL3ps2YlegyBh3D6xwOE9kfUadL4zZbtRPVLtUHW4x9if8Fs8UnEvy04HbbojZ/KbW8UtlKR446i
7IBX2cKAbpHxLjdR/ZoJeW1xmT263TbDyz1i90uIgKiA+gA/VyizKjqEIs635BUHOwXtIKTFyhJr
rzRZWXNQVWXnTFHp+6yuO4npHCvX0BmvVVkh73XAYzi8NodgLGqHLHWWFiUOuNmXLbVW2EpriS16
S4U5Rj6HEZ0EsYxY4DegKVVZtegdkjUG/zQ1K178S5p7mvOSYy3dSZaDhOABWOaSdadzeQ0z6vcG
yy740gv+F3r5Yc7GHBvDi1627F+w80x7HREf/NYbLbay0maN5Tor40uCTL7iP6QroK9UdmFweFm9
VmELmeHLCr/9W9in7xAbqv2bobCKlXiZHV6GLznEMvbUwlI4y7UliV2pxT1mZT+6LeeLJVbIKefX
nxdRXrK+wmxPNsYvc6w9TJt/Uv6Kd//hdUOERFs/nj1P2f4J8nYbBdU2e3Vet1MZHhxqJKyEaJ/Y
gk2zPxJcbcs1rn1AJoSNSOwQ1+B4IF3UXwBS8RxDUgv+fbnH0qv6Yt0/+gqwuxEHCA0wTedZdbnJ
2u0WW65X8YBM7GN84wHFE6ePa39s9OWv73Y8c6pk9cvPv7CjhcjxD9V+/PmPwicZ/7b4IB/Z4cth
8XJR13NavCRHGxwcApopD8YdNvry169ZkdcWl9mjcw7v7OlkxzjyV8AMq62oqaHlRW9QO5jtGbK4
WlVvKkuBE4FFAwC5qjfzyBiVvtfy9uliY59erPuck0nsmVpfWWbVao3VKgU5w7tQrrJaDePwjz9r
rQk3Dd/iiZNwM0V03fXfmrdvljd6w7d3w6f+Bgogy5a9GXKd/+05MVfjJYOnUFfR6a5W2KLXUPPO
qLAcmOqTgwSqw2ueIU3a2Q6wjOHF5PCqk5txFtOvMF15Mqy/0MiV/LP17XL4xFKqfVLtXzKWJCDx
inB4MU8hU3i/Nw52PXnxmySerWv2g7YytGXxdgSfSTvKMe8lN7m+U/WVBBZKGqo9TJt/Wv5KX7YO
L9WeqfRU+yfJ211hdWzTavWafAGZyhYG96o9r7LlFdXaUvmhykuxtW2ntWgfrMYD6KAJRKl4jiWz
Bf++/GPpVX0B2/7RV4DFDb7AEV89gGxZ4qan5Pv5xI/a/ljpSxu/iXKsrgnqV/gl6ejxD9V+SPgk
4t8KmQFRqzScgMkUW3jfZxX+8mLQT2JfmRqOCXveuTNiHGSlL61+zZK89sjMFqVzeGdLHzvKjV4B
K2LU6nG0tuy9QZcVsIdLHkWlxgqN7bSaycNlO94nDfgby2GHSKVnbEnM7noNhg6OdHAwf+WW6xSE
cOyBFtiErVZlAzac8fLnrw+GKnItsdaJAh6IJeP514M8Z9572+fPbRp3Oi9hh7TcEsMWrWw5SJiQ
wzvOZ0JieJH2wA/MEgaxvixnKXGzNyvWGoxPPJt/XVYRTlu2LF/SCFpRN0RnxeNp9km3f1F2oqvE
S8MjmJGkwdmDxWXtqVh6BSxfW/XidftJsVrgcLd1OcOGn8ca4J9AXpK+NHanEqTbA5s2/6T8lb5s
HV6aPW+D/ZPkVUYgXuT4Z+rU82GIbp9UfIIlztS9rPvR7YNo8/jAPXI8IFew0PEcCw8L/n35x9Kr
+iIdFeGw4NXYP/oKiL9RDovNC1h6+2OlLzkei+c3isKufvHUOqZx4x+q/dDxEfLY8y9SxF879eHq
v1Ser5ZSq6eGtoT9Jb5wF7PMC/Vhn2qlL1m/ZkveeERmk8I5vLOplx3hSlTAtG/wO2RFOhTSwcTv
1mlLeU2dxCBONrBU+g4reDOqatCtYAnzo56RQ7GdITZWTe+7vzhLazyB2Pj9W9XgZ8v8zV/gh29z
1fvcwLOJ3ypeILPAKji7K/a64YeKQgOaQfESF6rDm2HL61wy//fGxhIJeRFvx00DeGkPusOLbmtd
rEzQBi/ZfBGXo4dns0X++GmmEKuibiiHl2qfVPsPsUCLkLqLHtDyDJvem2l9llc5r3iiqXxBoOwn
W26HeNHxHzq8SeQl6CvEwYQjNHuzswde/rT5p+Sv9GWqL+Pb83bYP0Vepf+wbOqZClHtkyqvKmkm
Qxbtg8BxOuOBMVGx4N9XQiy9qi/W/aOvgPibptgHnQ7s0zUlTdD+0PRlKtQuTpSj+sKodArT+PEP
sT4mwEdwac+/SBF/VRMYFdbx9u9mizXc3jecFMrXVpg4N0NMmAg+rOrXjMkbj8hsUjiHdzb1siNc
iQqYMczEyQGt5vDq+1Mz2SzLZDKBv7S2T1I1ftwRjqWXnwoCJhoIHRTpgEp+9KfEcGxniA5vSzi8
EQ6EzEN3DpXMJhmIXI5JrniRMx+dmlzKLZbd+AoxyuSj8N3EYuSjJt5ovJiw1MseOlwq/06zJvfg
6i9mUrnyYGXCgFLLX83Qqzxa3mBFdvJk+1T4W9m/KjpZSMoTYa8iV/lZH9w2UOCzvLgcy5vp9nfE
iv/R+IsXQoqeKq+VvgT/07pK/HB2S1uZIYoL2YN4gNdp82+Xv8Lf5PDKWQ5xgB3Vnqn0vtkei/Z/
DDxH9WMqW4WPlX2S5VUlzWRI2nd0+zAKR9neyv6XiOe4oFjw7ysill7xb90/+gqIvxHLXsFmVZfk
1779oekrnt8oilHl+NMoTE19RhStVX1MgI8oz55/kcLiKtqHVI4VC8PtT0U8+6JTG277S+WKrDQ4
20asgFJ75K3G27MmrwUks0jiHN5Z1MoO8SQbAjEI0vgwdXBihld2EBp9OKje4FnRaxU83FiKb83i
0lzZ4YZLtI6RZUV3/lJ+/L7tsmH1r76cUQ0wVYOv4qy5mjCh4kU6bViCmuEDFnoLK3HRnfhothRG
0ThGp457ovgP8YlJZdloDyb18Ny7nTYeFqZO5OYdq5ytlLKGl+vi7nPvdEXtG8aS3vRCxmSfRPuP
gyPuueQvXhcNeZJ1li3hywFx0Jf/m9QKf5Mtyz3+cjA3vrwj9RUn/7jPJX6W9mAob9r8j85f15dY
4y+YxNlK77BB2RZIeS3tmUqPDi+tvxC8qutoeRWd6Mf8L2zU82GIyA9Z3mB5M3Yv5YluHwSO0kY0
EfT2dmhdRDy1vBIFLfj35RtLr+qLLu/I/tFXQPzNijzzJHA4pCmp5Ne+/aHpy1SoXZwoZ3T94nkp
TE19hr80ov0kwEeUZ8+/SGFzxTGCOONlsJrMc2w7dTWpMIhfYCvesj7Bh25voqRQ/Zo5eQWn83V1
Du986Wuq3JIqIHLSKIjTWfOsbbE2l0Qv3phxp6TkXw7c0D+ZtE0OL65plktqTQ6XOpVPvcGjNfhT
VS1mrjoffwOrnDl9WeuAG9nImgbBYX5lI82XFculsGG6ZDFah2h4IbMmTtAe4fDKcvurrOgtx5dY
aPr1n7Stn2KNL1jw0I/BAE+jt7VPkv1LZhMGpO6iB7QyZ99eSW9/t3RcBZWyH//J63x/u1opkK2o
5c4Tk9ekL8HWtK6afq3sYRQf0+bfmL+qL/KlzoDHPltaVJ+YMdm/lT1r+FjRY9nbZQ/tst0J+CR+
EsgbNIm11TZ+xSC8XSJIty33Fu3DtMcDY8lpwb8v/1h61b7JOjHIYET/6Csg/qYnV4nxF6fN0Qk0
e7Ntf6j6Gs1A9FPb+qWPOeIdXmL7kAAfIZE9/yKFzVXZD3+Rjh8B916848nTuiOs9askfc2cvDaY
zB6Nc3hnTyc7xhGpAiKXvRV1kBPkSmxVc3L63Q5brizikubq0EEg0+MsmfzkUZpV8VClfq/Dqtpg
TTQswfkLMoCxnSHPUf8kRYqVtBONO42yeouXr2n7clUjaNPgk/kmJVC8+Dt07Jbk/uShQyfVKHEB
tlBtsbW1DlvtdFjH+1tdXWXrPfWmQzm8aVZrd9iaRtvprLLV1Q7rKnIS9xz/mrcfhh9AVdeNDU+/
zA7enuJAQnOG+UnDKbTLJg4yfcX2VlnBc3jTgl77TA8/gXhptct66yusJA9m8xxB6VDT7ZNaX4gA
+cml7iwcXkwpZ2g9HMP7VpX9FJbE/uc+W21U5IwwgH/mgiovSV9+aSd/R7YHXKJGsbcEHFPzlzP3
6cLgm9z97qrvk3GDpYPC/nF4RmtvqfT0/oIqr4BUb4cq2mF8vbUWq9dbsi2g2SddXsEPv3JZBv0V
f4FrOs9BJ96OsEX7MO3xAF3MvncwJp4NsbbsvYDG8yLwJMJ+3KfvYuVV7Zveh3AeI/tHsgBqHzi3
hVxpmQ2OusB8+v0uW20ts0qtObTPJO2Pd1BokP+BDMLZnsAEgW39ojq8pPqYAB+hLnv+RQq7q9yj
jbrVdaDHy08UYZak+jWD8tqhMltUzuGdLX3sKDe2FVBfMtoSb9O9gfJgb25anN6MTgJ+1iQpvTrV
0HM2vDL4TGSh6H0SSTogY0CHneHwwCJ9dtaQH75lE98u5R1WKp1maV1WdJS0z/ZiBmqWZRYcXrmk
UA5yhYzozEtnEtiicGgkLkH81X2qoN5Uq45EPReDPHEV36kTJVOuXXGytWcH2YVFVljMqZcN/EAx
7e2H3tHwg7nSmSzLZdXsFudJ14vY1yh4VdcsK5W9b1HLUxNxr6aYVZZ2KeTm9unRBwYY1PpCwcdH
GzvA81HjJ7LVd3cBcNlV4LE+eFG4CHmH17Lv02TDDCjyUvUVYnHCEVR7mDb/1Pw7dfX9dL/O0iwb
XOGA2FHtmUrP1bMd9tD32TLuTcd6n5Ht9E70R+usKF/eYl2xObRowrYcys6ifdiO8UCIrxERgh+/
LfvboMjtUrHyqr5ad1aG7ET0jyN4jXwkHXXFd0qfAUypA62o7Y/AJ8w/tt6aw6uPxyL5HPHAvn4p
TPV+dkTWpPaBio8o155/kcLuulpT7a0urz5uyVdVz0rV16zJa4fKbFE5h3e29LGj3IgKaHoDLStt
tixnbIfM9lmrVtBmeVRDns7ih9Ub4rMmQjQKPX7eqKK+9Tvo6NI5VsdDZPreSXj8e3aajyMKoV1l
ZygO3BmRvNtmxZxYyq1kTWWLrB1ipCe/x+b/TvGI/Kf2SB37H1yCOCgSnXkxSyr3RePJ07qDbxpo
6LbSEzoJOYAKp/B+bJrAK3Xv81ihMrJoF34FdNt1ls+GdTWUAz9TVG/L2Z4hF11W9w6cELKm8ETr
Bq5ClPbmm8U02+cSzj7Lk45Dg1uK/dOw8VHrNu2HxUembjpS17pO1XM1AyKwEdd0dpEt44y4+Wcv
L11f5hInF0uzh2nzT8+/y2rBFTHpPNozzsx7+wn9Syup9kyl55rZHnvortRZVnckvPYiW1gKfHLM
nh/Oe9L+SC2fxhelg8PhJmeliXKyaB+2Zzxgz73aNqT6E9EGiau57cIyYuVN0D/as+6j7ONKg2Le
/+JV8J/GFXFyhRWObCj9UTJ9+VizvrGrX0nGP5T6SMNHF86Ofz1FfFie1Bx48c5wdjbvtT/6+Ieu
r9mSNx6R2aPYbQ7vezjE2Hi437YjsAlXLnWg2+vDnn0H4fD77oJDe28ZwYU9/da1K9DpAeyBfXDX
0UMwKtcRBU700cbVS9DpAnK0BXDwLjh+54GJ5u8yG4HA1ga80f4xXPk/ALfCPwPceQI+fPI47I1K
gvRX19bhen8PwFYXtm45AseP3xlpRxtXr8B6f2hvR9He4n4m+zz3x2fh48+8AqmFOjT/5GFDWfb2
H1f+JJ5fO/cVOPzxL2NWGWh0X4LTIXPegOcfOQiP1QAKyx340gMHYKO3BbfsOwAHRtZzwR1BXqK+
RAnTulLtAabNPzF/wT9vrY5PwZ6nbv9EeZUdbMG1K9gnYc+xB+vzgfcdRVtVT/0he/s0yevPy3S3
ARfP/xiuw3645/T9EN+qmPKYpzh7POdJqknyurVxFTpr13G8BNBHuzh8+JCxLRX1l49/bPqjSfI4
Oi9K/RqdU/ipvf0kx2ea/IclmlTMzSbvpHDj+YzjHlLTRtGb4k1xJn51Oh52Du8krcPl5RBwCJgR
2HwdvvLFKvzGU/8BzpzwD1+vXngePvnRx6CFKXPVFXjucyfMecxI7NbVc/C5uz4O6MsCLoeDl548
ZeBMObx4aBU8eSrkERvSuKi5QYBqz1T6uQHCMeoQcAg4BBwCuxEB3WGkykdNG0VvijfFcf6C8fo9
DzuHl6pFR+8QcAjQEdg4D2cPfgxe4SnTWVh85EE4cRDg73/wTXj2vwxi8UEeVvp/BidmYUmCT8JN
+P5zfwp//y+Owb9Yew3+85e/OnDOce8u8vsnEfzqDu86Orx+J9+XvbuZPwSo9kylnz9EHMcOAYeA
Q8AhsIsQ0B1GqljUtFH0pnhTHOcvGK/f87BzeKladPQOAYcAHYGtK/Dcv8/CE9K5DWSRWYDGf16E
00dnzttFRq/B1z58GL7Ip6DFL5WHxvf+FE7fGcXvBjx39iA8gb48HjwGT512Dq+AbldcqfZMpd8V
IDkhHAIOAYeAQ2BeEdAdRqoM1LRR9KZ4UxznLxiv3/Owc3ipWnT0DgGHQGIENnF/+U9/8jr84+V1
+OWNG3Db4ffDPfd+BE4en2WHcAveOPc9OI88813Q7z/5Efg3p05E74H20Nm8dhV+3u3D4Q/gXsgo
vzgxki7hLCBAtWcq/SzI6HhwCDgEHAIOgZsPAd1hpEpPTRtFb4o3xXH+gvH6PQ87h5eqRUfvEHAI
OAQcAg4Bh4BDwCHgEHAIOAR2KQK6w0gVkZo2it4Ub4rj/AXj9Xsedg4vVYuO3iHgEHAIOAQcAg4B
h4BDwCHgEHAI7FIEdIeRKiI1bRS9Kd4Ux/kLxuv3POwcXqoWHb1DwCHgEHAIOAQcAg4Bh4BDwCHg
ENilCOgOI1VEatooelO8KY7zF4zX73nYObxULTp6h4BDwCHgEHAIOAQcAg4Bh4BDwCGwSxHQHUaq
iNS0UfSmeFMc5y8Yr9/zsHN4qVp09A4Bh4BDwCHgEHAIOAQcAg4Bh4BDYJcioDuMVBGpaaPoTfGm
OM5fMF6/52Hn8FK16OgdAg4Bh4BDwCHgEHAIOAQcAg4Bh8AuRUB3GKkiUtNG0ZviTXGcv2C8fs/D
zuGlanGH6Lc2r8HaxhbsgT7csvcuOGT5nZONa9dgc2sLbrllLxw4dAB26usoVy98G8rfeR1SjzwG
D99/5w6hOEvFbsKl138K+NUa3+/g3ffC8UPxWnJ4+mBzN3OHwHj2v/Pizjv/O4/gPHEwa+3tzvPj
7H+W7Hfn7WGW0HC8TAoB3WGk5klNG0VvijfFcf6C8fo9DzuHl6pFSb8F559/Fv7itXU4sm/fMLaH
Fwy/9/3HIPXgGfgkfqvT57psXYLnnvkqXHhrH/z208/A2eN7ZW7RgU34/nML8IknvuojyRWXoPjk
2YhvgW7BxZf/K3zly0/ACy09WQpyxT8bkU6nnWR4A547exCeeAXzTBVh/bUnYZa/ujpJySPz2jgP
Hz74MfCph8NTaMJrT52KTDZ84PCMAcg9nnUExrL/GRBu3vmfAQjnh4VZa29ngB9n/zNkvjNgDzOE
hmNlcgjoDiM1V2raKHpTvCmO8xeM1+8HYfznfokQ6LJSGhjHOPIvX2VdPe9uk2U8+mJzXX8SEe6x
2kJKyz/FUlp5qXyN9UIp11k56+cpldLySBWZTcmhbMeK6LKywCpT9mNiyLddyQ1kzpaahqe7JKq/
ykr5HMvl8iyfz0odZ4o2MtPwnDZi866veed/2vqdSv5j2f9UOKJlOu/8a9JS7Z9KrxU1p8HZam8Z
9qCU/nQqoO8i+6fiM237p+c/A/ZABdHRzwUC7777Lkv698477zDK39bWFjP99ft9Fvy7ceMGM/29
/fbbTP/b3Nxk4q/X6zHuEbtfIgSwkckMHctUvsxa7TZrtZqsVi6wtOaUFpbXVO69JssSHN5OfUE6
QunFmucodll9MSPjF+qrKn8MNUvqWSpXYivr/eHzfo+tNKpssVg3OMm+LKZy0+92WKvZYp2whx4q
r1UaOoB2zl8o+RxG9KQt2cpMwXPagMy7vuad/2nrd/r50+1/+jxRSphv/qn2T6WnIDmrtLPU3nKM
Zouf+bZ/qs1N2/6T5D9b9kBF1NHPKgJJnV2ejuLsclqTs8vjgs4uvzc5uzxOd3Z5WDi7/Ooc3rGs
TDm8mVLLn1O3xXKeY+tzYEgO77qaQc6UArOy+MxztiGtzdiuLakZ4FAaP4uzfJekwZ9leeJ5w9UC
nj599hKfcCYo5l1f887/TBjBWEzMt/3zGbebqf66+jKWse/CxPNt/1SFTNv+p50/VV5Hf/MisNsc
XreHly/8TvTbgOcfOQiP1QDQSYGXntT3XV6Fp99zF+hN7FAAAEAASURBVDyL+abx2ffFs80L8Oi+
j8ILGI9LmuHJU9E7WbeuvAwf/cCnBns8F5fX4D+e8R/0dO3cV+Dwx7+MOaWgttqEzxy/BS4+/yik
HuO5A1RXevC5EzZ7hAGuvn4OvlWtw9/95DKm3A/779gPd3/wJDzw4MPw8Knjg/yS/LuG+S795Brc
KhLfuAGH7vsEnDkZLTcnfR3luBflwBcJ8NLj94vUE7leOv8y/PDyDfjQQ5+G+++8BS6d/zZ8s/YK
XLz8JuzffweceOh34EufP+3few0bcOHlv4IXv/sDuPzmdYToGGR+73H43Gkdmy144/z34EeY932f
+AxwEYd5fwfzvg7H7v8UfOH3Pw8nDpjEGGVLij4pnjyHzSsX4BsvvAg/uIg63o86PnI3nLzvw/DA
6TNw6kRYH1dQd3/76o/gn36xCXv33g53HP0VuO3WG3DbBx+Cs4FDx+j6ssFTyT0t+xQlUPnfeOM8
fP3r38D68uYgizuOPQCf/cKjcMaAoyiDeqXgP218OO8UfqiyAtav6LY0nFsS/Kdp/1T+wxKFYzYu
nYfv/s/L8Kv/9hFI7WnCs3/w5/CT6/dArrAAZ44CnP/6f4I//+8X4dinHoNnHg+f5UDRF9X+qfQc
n/j2c4hBsvY5jF8w5o1zL8OPfv5LOPyhcPslaLmN/M3/+hnA++6Dz5w5CeO0txT8RflxVwo/dPuZ
fv+l5Iu3Bzr/Kndbe7t68Ry8+g8/h2Mf+U04jR3zlQsvwwsv/vWgv77jngfh0S/8Lpw6Gh5D0e2f
1n7a5k+xBx86lv1XUnz0slx4vhFAVz+xANS0UfSmeFMcZzQYr98PwvjP/RIhoM3wBvdd9tss783w
LtQ7KnfCDG+3WfKWLWfYsmnTbbcR2A+s+IFsxXrZ8nJBLYHm9uL/KwRmlpUoNqFmQds77OWdKjTM
SdfbrFIqsUqlzPLeft9UdpGVKxVWLpeHf/i83tKWiJtzGhHbZcXUUMZScyWwP9qTPbjHeb0hZ+v9
2ADLFJaYt2Acy9TybrQx73QAS55/ljVMuuR7sixmeEl4ShT6rFnJG3iJkBf3ZhWz3rOQPQCT+kuq
L2s8hwJMzT4T8t8sR2OZKzc0e5AKoAVs8fdynRo+gmsiPyIZ7Wpn/zxPOv5Tsn+fgPb8+5KNuGkW
h+1HOr/Icl6bNWh/stgGlodnHIj2qNTSToqw1RfV/qn0QjZSfdfaUNv2WZQTc63lRJu2wPybgETC
HquKdi9bHUQmam9t8RfFEq4Ufuj2o2E/pf5rIKqlPdD594C0zJ9TizIyuM2rXlTnaIh6hdMVrN7x
evik9m9rDwnyp9iDhw6p/SThIwpw112FwG6b4XV7eBObpzbI8S1p5gdNCWcnx1r6ntVEDu8CW1Fe
leK2vyKd6sEBWOhky2XUtoc9Yecg9htz57LeaLGVlTZrLNdZuZBnmXzF2zesiqWEOrhnuFgssVK5
xPIxDl23UYh2ynTHazHCYbZiTOlMdWrAFkpVVi16g8h0SZN5jRXEYVvIw2JlibVXmqycF/oFVmyK
waY57zzKX8gp+tTCkoFTlXbUkmYKnqIQcQDGQN50nlWXm6zdbrHlOu7nzuELCZ+8ig9On8ousGod
BwO1ClvIDF9eCP6S6YuCJ0owRftMwn9naVHZaHqBLbVW2EpriS2K7QWIme8Fl1CC9dUe/0GWU8Rn
yDKRH2s5g4SqHGFfQQp+nwT/adm/nz87/v1pRt+JZY3DdirFMtnoF5O5StvLTPEx6fqbpL4wRqzv
2ou/odxDJzW6fR6Nof60t1KRddd3roYg6tTkdqBye9hp09tbe/xFsZQrhR+6/fh5F/hPsv+i2AOd
f44kzd78ZQxtLVcos2pJnZ0i2qNk9u/HdNL9KcUeODrU9pOCD8/f/XYfAs7h3X06TSiR1phlFlm1
ik5TtcIWxVtiHPwWlrXZXV4KweFticOncC+ucKn8jKryM9zB1U6AVgMgf4rgXbdZ9AYBKVYfZ+I0
mLHhvl2OOYiqu8LqiGGtXpMORCpbGNzXajXG/zjGyyvGKVJDiaYohdmwQ8+yZe8Nbr9dHmKBDqAo
YbWqZvNKvlO1MR+h51zVm0035S3edmj0kGPeeEpjUKUVHaz20BiMxZOnQodInAoO2bKUS8+QHwAg
fnqHmCv5ZytD5SXQFw1PbtJTtE8y/x22KGbaMkUcWum/NbmHE2CRBWq9TjgyTMIfc5oqPpg/lZ+R
wo18aGP/CfCfpv375LHh35cg9kYfbGZK3KFtywMP+UqRFlbblUCbStIX1f6p9Mgxtb7zVTJipYtN
+xwLoo9Ay9vwpYDlRe+lpNb+68lD7Z/+0AuT8Dekp0TF8UO3Hw0fHLtwG1uWJ0ziM9HfjdF/UeyB
zj/d3vQycGMaq62okZa0B7FaLoH9k+whQf66vcTZA7bm5P6LhI/OjAvvGgScw7trVDmuIMEOQiyZ
Gl7LLeE2aeUQHN5m0Xujb+Hw4j5hnzNtPcu0vixneHmDX6w12Jrw0TS2JxEUjaeNQycbb9/M+SS4
0HWWYrjPWWbaa3kOrxwM4RI3PgM66PzRicEBJj/ljf/hIel4Gra3BEoOkPx511aVI8kLWZcz2BnW
UP2qV75Ka4MPT2SDp+pwbV5odFlFDGqy5dCS+FHl2emLiicKuU32acN/f7Xq2QIw3xJSrgz8SftB
e6lodjV8avM/Af5TxScBPzZiGmni7T8J/ttl/7qjZlt/jTBokaK+AeRZmzcl2HeIl1dZb0ZX0AzL
TK4vG/vXWGN29Anqu8/hjWufdY7swmvLahWRr45qL4sXl/yvskTOfqxFrH5Njr+ei204jh/xnGI/
6mVDik2+/6LZA51/Wv4cZ1UGttmBt9DSVmT/rjRjZ//J7cEuf8WPLktU+5Ok/UyKj58zdzfPCDiH
d561N1He1SANMgusgrO7Yu8pHiQVakAHRRMcXtngpgqB2SQhhHpjN1iipeUd1eiJlOraw08cqeW2
YhlTNl/E5ZpJ56lU7npINJ42vFFo9TLiw0pn2XIrTM6/9yVj1cmTAhfjVXaIet58Rsb/67bUnuzt
cnjlSxP9JG8/W+pOG1CblvyN0smoZ6oAKp485fbYpw3/ak99ljXVexIlXq8lZ+DsvrGtkg5CifCf
Ij6J+AnIZH2r6k5U+5AE/+2y/2k6vOmit4VDtu/qTAef3Y6hL18+Fjqzo09S35UdxLfPFoyGSFbZ
wuAFJm7X0LaWqGXvUft7lXMUZZ/6Cwlq+xli0yIiTgfiubX9aC8bsuVp9F80e0jCvzgp3dhPe3rn
W3jEVIQsY3E5hLjsr5E++H5apIu0BZ7bNtZHXlwcT0naT5FnmogP58f9dgcCzuHdHXqcgBSqc5af
JdL2AUHKsLRRDlr43k/R7JpZkQ0uzryGHSRMozWow7zUp4pSC3VzphGxnWZN7tHUO4tUrjyY2YxI
RooWjefITsLLUdLa7kW25kTpzDRL589G0XJMMtksy2Qygb+0ts9Z0ZvyVvo0OUwqrQ0+nE+JUfDA
NE0ItSy+HOq0NbJhULNN3+yHR9jyVhyY+JO8jNSXktEOT8XhtO3Thn+lvwyT27YVi4P6SPnGtp50
EB4D/6ngMwY/IdliI5RtmOyLJ0+C/3bZ/zQdXomH0Ie24kfabWCFz3Tqr1KiLHfi9V3ZgakNVRwk
DynnVrw4WJVnYYiZc1PuUuao9lboJ2KFx6j201ReXFwcP6Hngr8o+9EcXhP2qv4l7b+Ubm3a/3H4
t8mf4yvLMNixlHeUw2tIJ/Um8E5gD6P4kvkHAjJNhH1KeXA8adt/yTwNcsr8DPgEWHO3c4yAc3jn
WHmTZV014HJQggU0xd5bbOiywVlErRGMc3h7bXXIhqkD0pdQltvDd5CNgpitRSd5tD9thKLbaePh
TQvy8A7ecZje9hoTx0TKxjOiQdaTC1rTm0Wdjh5WOovDnw9ixRtj+UJjZIGj85Z7guSSaT0zlVa3
JZ0iGBYYjaJfkXuQA4enBTPj99I2w8vZcHeUnBkxYSF4Ga0vKp5hJqdlnzb8yw4eT+40npquLS+O
t62wbOPgL3KbKD5j2IPgx/4ab/9J8N8u+58th3da9Vdp06a+0NtPnr+yg0R1SLEYHdKWL2crKzFb
TVQ2QubI9nZb64vmrEX0pyF+BX8WDq8J+/H7L1r7n4R/Wn89GkPZ3hgcOsHbyP5O4I2r/YLLwyfT
nyrb5CHBU5R9SnkI/deoPGV+Bnz8nLm7eUbAObzzrL2J8q46Z38jo5wDfqy9b0uQbATN+wD97OGS
ZXQ4udNpmrGtL4j9pWoZVk8cvMTTLJpOA/aXEHnXx0/TxJyqHJk24sGoxjOYpC0+uzHxxlTpzNSp
B/lQLxC8fXRBAt+9nrd/EVR/VZ0Aap5FUGn9tuQrwHdjg2dPLqPGGWrDW1pfhtpA0L8HXD91HO0R
D/HwS4fH6Vjqi4anjzv/zYTt04p/DZ/QiyzkTp85Mq7I8EsQvtPyp+IfymwS+EySnxCDwQgL+9f4
scV/u+xfd9Rs628QgeB9qH6LviPKYdHwodqPlf1rDNrS0+u7sgOb9lljiRSUzhvvJ0Ufa1i2qWca
0of+kIfHwD+Ylc19HD+h53H243vZ4G/hJ9V/UeyBzj9jlPw5xqEyNOBHOXRW9j+GPVjlr/EaJ8uA
VOPHtv1Mik+ANXc7xwg4h3eOlTdZ1lXnHBzkqP0SQwdBbvkTnQ52sgvVFltb67DVTod1vL/V1VW2
3lO7SOWSPKRfrK9I9lfr6vMofkeGH9wwdJK5o8zLULkx1u+uskZjRca18JTPVK7EmitrMm5QSG+V
FTyHd3Agliw5eUA0nunCMu7M7A8Pf9KZ07KWnQ2+MKhoh3/11lqsXvfLpCWzCCqd2QyoeivqoCJA
nFalIjmWHbZcWcQlzVXPAVR5F5bE/uc+W21UtIPBomZaVdo0vqgQ+PS0E5SDwtnh2WEFcbIw2kOu
tMzWPcz7/S5bbS2zSq051L32WSt+QufSapf11ldYSR7c5dkVvoQILh6w1RcNTxyQbJN92vHfZ+ol
U4qVtBPYO42yHDhDvuavS0HFRd0nwH+q+CTgJ0q0+Hgb+0+C//bYv+7w2tbfOExE/ZZ9i+g7ohze
MfRlZ/+KY1t6an3XcbRpnxVHtBB34Hj/qP5Ms3D+PIU+IvuvMfD3l2R3F8ePeG5tP5rDO63+i2IP
dP5xkRKpv07u8FrZ/xj2YJV/wEwEXpH2ib0Stf8SeUob0sqUPE58UkIrxAV3HAHn8O64CmaFAW2J
TmhZETYueTEDi86qcIBw0CJO2lSdrd7x4hvnAp64LH79FbagOSyZXJ7lc/r3GA3f6MU3eeJ7vIMy
0jlWKBbYgkiXKkqHRR7qMuj8UyydybJc4HuPkxp4iMZTlzvKme6vLWlOIgz4yqQFngXJv4DJ/qp0
ZitXS8xeegOkwV5eyQvqDg8VGzqAatCuy6iHy5H7thVfOr3/G7l+Ka3xXFsO2VxKsynQ7EGcDunj
YSB3Fr+l7H2bUBtwC44o+rLHE7cHiJPKp2yf1vwH6lYqnWZp3RbwRUGSrQQCRyr+08aHyo+Qg361
tP8k+G+D/XNHTSyn9NWdMQaDon7LwaaYodHqX5Amqb6s7d9TLIWeUt91HG3bZ7qt8RQ9dSI9b1vE
p2dGZCaw1vUb7L+S4j+i2MhHcfyI5/b2sz39l6090PkfQmWbP6cOlaGhrTt0wRe8tvaf1B5s89fY
lbKMsk++CkEfG8b1X0nx0fly4flGwDm8862/CXKvjsHPmj6fg42LOMRGOi54kqve4OiNkwiHlpt0
22wx7XeKB7TpRdbyrzxSsmGaUl53jLX02h7SbrvO8lmx71ejGTgY+JmiejvZbJXiRIb4bJSQUVyN
uHkpuit1ltUdswFPuKe4wGdAk/5woOPNWPq/qzsqvz5r1Qo+B1zwn87mWbWxKjgOfENS4ZnOLrJl
nDGN/nG+FL3IHzRdBdNS8OzjzHgxwh7SOEOt8OyyesGvpxSeQN7AL3X0V8SecvMstb2+bPHE4e82
2qc1/1i3irlwnUlli8zbSh9UFeGehv/08aHxQxA0QEqw/wT4T9/+CfwHJI+6FUvk5TfVccYoz9tA
zeGVNPJU3eT6srZ/j2F7evv6PnBEye1zFIKj4/VVWDZ9gV17mxz/0dyGn8bxI23D+4QVi7WfaId3
sv2XnT3Q+RcY2eXPqYVDFxpz4bOu+Exhtuyt4OIp1M/O/pPbg13+ip84e5CUhPZzHHxkeS4w1wjs
Nof3PVwbOMB2v5lGYAveuLAMP/0//xIOwTX45/f+GvybUydgbwzPm9euwI///g3o/8tb4cY/Axw9
8atw/OidcEsw3dYGXF1bh+v9PQBbXdi65QgcP26gC6ab+v0WXLvSgS7sgT19gAPvOwoH4oSeGk+b
cOUS8tLrw559B+Hw++6CQ3t1JDfg+UcOwmM1gMJyB770wAHY6G3BLfsOIM863dQYjM14a+MqdNau
I/8AfdgPhw8fMvK2cfUKrCPee2AfHD16KDZfRUDRVxyeKlfYNvu053/j6iXodAER2gI4eBccv/OA
xvB4QTL+U8aHzM944lulToL/9O3fivWpEyXXl739D4Wg0BPq+9QRmm4ByfGfLl+jc9/u/mva9jDt
/Dmadvaf3B7s8h+tV/PTJO2nOScXu5sRGMc9pKaNojfFm+K4HoLx+j0PO4d3N1urk20bEVADhmKz
C0+empwDtI1CuKIcAg4Bh4BD4KZDwPVfN53KncAOgRgEdIcxhjT0mJo2it4Ub4rjDATj9Xsedg5v
SE0uwiGQBAF9wLCODi9lZjRJeS6NQ8Ah4BBwCDgEJoGA678mgaLLwyGwmxDQHUaqXNS0UfSmeFMc
5y8Yr9/zsHN4qVp09A4BIwIb8NzZg/DEK7ikubEOT512Dq8RJhfpEHAIOAQcAjOGgOu/Zkwhjh2H
wI4joDuMVGaoaaPoTfGmOM5fMF6/52Hn8FK16OgdAhEIbF67Cj/v9uHwB3Cv8Wxs243g1EU7BBwC
DgGHgENAIeD6L4WFCzkEHAJhB5KCie5s2qSLojfFm+J4GcF4/Z6HncNrowlH4xBwCDgEHAIOAYeA
Q8Ah4BBwCDgEbgIEdIeRKi41bRS9Kd4Ux/kLxuv3POwcXqoWHb1DwCHgEHAIOAQcAg4Bh4BDwCHg
ENilCOgOI1VEatooelO8KY7zF4zX73nYObxULTp6h4BDwCHgEHAIOAQcAg4Bh4BDwCGwSxHQHUaq
iNS0UfSmeFMc5y8Yr9/zsHN4qVp09A4Bh4BDwCHgEHAIOAQcAg4Bh4BDYJcioDuMVBGpaaPoTfGm
OM5fMF6/52Hn8FK16OgdAg4Bh4BDwCHgEHAIOAQcAg4Bh8AuRUB3GKkiUtNG0ZviTXGcv2C8fs/D
zuGlatHROwQcAg4Bh4BDwCHgEHAIOAQcAg6BXYqA7jBSRaSmjaI3xZviOH/BeP2eh53DS9XinNFf
feM8vPq98/CzX2zC3r174eDBo3DizCfgzAn/d2KvXvg2lL/zOqQeeQwevv/OOZNy+uw6fKaP8TyV
cLPZw/zJuwmXXv8p4FfCfL+Dd98Lxw9N/pthM4/P5lW4+OPLsOf2Y3DyxOTad9v+xaeEidxsr34n
wvIUMtm4dg02t7bgllv2woFDByDKsmfePkPYOP2GIJmjiPmztzkCdxtZ1R1GarHUtFH0pnhTHOcv
GK/f87BzeKlanBv6DXjx6Qz81rOvhDhOFRrw2lOntXj10XlIFWH9tSfB7w5rpDdl0OETVvsWnH/+
WfiL19bhyL59w8c9vGD4ve8/BqkHz8AnT53wD8C2LsFzz3wVLry1D3776Wfg7PG94Wy1mK2r5+DZ
P/gWrB/ZB14J2tMe9N46DJ/9wwU4czRqmKeRG4JvvPw1+Mp3/1Hy30P+Dx9+Lxy7NwVnPvFJOBHp
GN1s9jCH8m6chw8f/Bi0AnpPFZrY9p0KxI57O/v4bFz4Ghz86Bdhcu07pX8ZF19D+m3Vr6H8HY3a
gosv/1f4ypefgBd8Bp6CXPHPoPjkWfC3rLNvnyE4b2r9htCYs4g5tLc5Q3i72NUdRmqZ1LRR9KZ4
UxznLxiv3w/C+M/9diEC7UqOcf3zv1R2kVXrdVarltliLsMWqu2AxF1WTg9pIVNm3cDT3XYrsMmW
mpai3Vz42IHSZSVhM56dCXuT13zVb0vdJst4tMXmemwx3WZR2rDMM1BWoRGfT1RBrVJmZP6LtZWI
pPNtDzeF/fdXWSmfY7lcnuXzWannTNG2zkeo3hg9+/bQbZWGGGRK/jpplCc+UtiQXf8Snx+ZYgz9
Ct7t238yd1NMsM7KWa+v9trCVCol7RtfaLBwizj79hkCbAz9hvLa5RHTtmd6/nNob7vcRpKK9+67
77Kkf++88w6j/G1tbTHTX7/fZ8G/GzduMNPf22+/zfS/zc1NJv56vR7jHrH77ToEOmwxNewU0wt1
1reQr9/tsFazxTo9C+I5J2mVhgNgyuD3ZsLHTr3YqWW8Fyr5Mmu126zVarJaucDSmlNaWF5T2fWa
LEtxeMUgHdKsvNxi7VYLy1B/zWabrdsYt+LAFxJ2kF6oDPlvNli1tMhSGv+1VXMB82wPQu6bx/57
0lYpMvuMJeZm1u1BOrzpSTi89P4lBr4xH9P0m8T+x2RwYsmb2ku6VK7EVkQD2O+xlUaVLRbrzNSF
z7p9jgaIpt/Ree2+p9O25yT5z7e97T4bSSpRUmeXp6M4u5zW5OzyuKCzy+9Nzi6P051dHhbOLr86
hzepFcx6OjmTlmLViAH7rIswTf6SNODT5Gc+81YOb6bU8ovQbbGc5zT6HIzEDm+GNU2jOH+p5Dtp
B0H+15flTDTkqsYBJLmwGUog5Z7KbOcMCSpZwdUI3ssZnz3K57s/0G+Xh7OAk3B4Z65/oel3bu1/
bUm9jMOZ+vBM7m61Y5p+dysKUXJN256nnX+UXC5+5xHYbQ6v28OLa7Im8du8cgG+8cKL8IOLlwH2
74f9R+6Gk/d9GB44fQZOBQ6I2sCDpL7+9W/A3/3kzUHRdxx7AD77hUfDB0ldPAev/sPP4dhHfhNO
nzgAVy68DC+8+Ndw8fJ1uOOeB+HRL/wunDrq360zyHDrIjy6JwUvQBba/b+EkxFbHK+9fg6WfnIN
bhUA3LgBh+7DA61Oxu/gvfbGBVg690P42dov8DCs2+HgHUfg8G23wq2Hfh0+eWa4d/ON8y/Djy7f
gA899Gm4/04/ExuXzsN3f3gZDn/oITirHZJ1CdP8UEtz6fy34Zu1V1DmNxHWO+DEQ78DX/r8af/e
UOT/Csryt6/+CP5pcDjX7XDH0V+B2269Abd90J8/F/X15x+Fex97AdBRg5cev19IH7omxWfq+g1x
uhMRG/D8IwfhsRoAOhHw0pP6vsir8PR77oJnka00Pvu+eLZ5AR7d91G0SwBc0gxPnhptZxsXn4OD
qSeQOgPN7ktw6sBk5bz43KOQegLtIMQ/wBsv/n/wr3/rq76yk9hDMnvegAsv/xW8+N0fwOU3r2N7
cgwyv/c4fO708UgAKO3PbrB/Sn0HGGWrkZDGPkhiDzzTq9hWfatax/Yf+wrAvuKO/XD3B0/CAw8+
DA+fitZxLEMaga99vv0ubPT+G3zxq69gVSpB96XHwV+ViPZm2b9o7Fi1z0n6i2EZNP3a2r/O/yyE
L2K/lcJ+i/+qKz343AlD368xmsQ+k7VXADbtz3bpl0Ng2z4klVeDeWQwSf624wdRcBJ7tsWHl2Gb
fxJ74/nbyns16XiYF+J+iRBAlztROp6ImjaK3hRvijOVqdMNwvjP/cZCoM+alTy3CvNfYE9NsxxN
mys3fMuPm8X0IM8MLlOqF9U+NFVWmtU7asnlWqvOSqUyK5cW5JvgfLHMKmWMwz/+rKGtWW4WtL0/
Hv94oFUMGmuskh/ypfjQZJfydlnRW1Zt2mcpZPOXp9KUmiusthDmL7RHCff6FAN7mnS+ZP7rbVYp
lVilUmZ5b+8p39tcrlQG2HB8yvi83lJLcJPgM039xihmmx9rM7zBmcJ+m+U9e1qodxRf48zwTmFj
+cg318jrcL8xrpJYGU4v0+0hgT2vN+TsuG7HPJwpLPnahyGwlu3PbrF/2/qurA5DI2zVR0e7odsD
Y8uFUfvGCxOYtYtpn4MzvAR7o/YvAzSt9aXqin1/IfRlod8E9i9yn42rkhGyFatVJ3T7VDqw7n+x
RbIb/6i8p6JfoSRre+MJFE/28oqCbK70/K3HD0nt2RafBPnT7Y0xa3kRbjFmtB0P22jI0YxGYLfN
8Lo9vKP1HftUbOgfDE7TeVZdbrJ2u8WW67ifJocOmzbA6CwtKqc4vcCWWitspbXEFr3ldjwP3UEQ
A3J94JsrlHGf4YLMR1+iZ2pw9LQ8vKgd8tPBPT/FYomVyiWWt1ry12d13QlN51i5hs54rcoKeW8g
Jw9FUR206YAiIZvOvz4w1fleKFVZtegdwqXhGaRPZRcGh3PVaxW2kBk6yyL/bqMgMdPzDoUXlcNP
xWfa+o01xm0lUPr1L2nu4YsK8UIkx1r6UuQxHN7lNcwI96nxfRjiT73qSSa42Qa9vAy8Uu0haJ/C
1qLteY0VtIPAFitLrL3SZGXtBVOx6ff8bduf3WH/yuY4lqPqu98iVDrRHvifJ7sj2wM6l2J/O3/Z
Vm+02MpKmzWW66xcyLNMvjLmgVIW7bOv/aTZG7V/Cdr/aH0pHdn3F0JvKm2UfpPYv8h9Jq74ElFu
E7E8bJFsn9qLIdFW8Wt0e8WYbfuj28I09DvUkbIDu/bBTy9kHiUvzRZo+VPGD8ns2c/PqPqYJH+q
vVHk5biL/lroiV9HjYdpunLUJgScw2tC5WaNwwGMOHUWsmXj23m+wXr4Uwd94BpKpuYR+dM1uccM
YJGJOTF/Bc+w2ooa7C4vek6F9rZ3fWWZVas1VqsU5AzvQrnKajWMwz/+rLUm+PHY8i7tcvxBTr2W
tw8MG5r0Yt03OAvvEVONq30Hp9IMG7UsW/ZmsPX8xd4lvcHMlfyz4yF5uiusXkUs6jX5giGVLQzu
FT5VtrwicqfiM339+jna6TtNVxk8BRyxrVYrbDGrZvsLy8KSPV4NTuQoKeRBO2hveicnwlGD21F5
6s9E/TLmg/t4xeFVJvsN2ZeesQxrGA1kGG3Pq1W1+qPkO8Ua8xG46nuKKe3PLrB/Un2XOuABpQej
rn20yW5s7EGdOp5idX8HkKzQQCpa+8wY1d6o/QtNX0pHpvo2sq7a6HdM+w9Avf23ct80DvIrbXL5
Nvap1xOb/pdR2h9NR1PRLyJCszcOobI5K3nJqFPyJ44fEtgzCZ8E+evwxNsbUV7MXLQBQ13Fj4d1
flw4GQLO4U2G265MpRqQ+AFMf7UqB+2llnJcBTD6YKXiLaHUK3ilrU+VoYu87M1Y4hv7kIvWb3mn
4WZZy+zfimLlVZQ1akC4JGZ3U8opFxlI50TOIKjG3r6DU2nwg5FyKSkvQ+IjP5vUZRXhBGTLoSVe
o+SRjXHwsCIhjOE6Kj9Ovq36NfC3/VG6rsIOabkVskpUYtJTmsP5804vYznTEYXNSJ121csse/sN
lqRjFGfPPVblK0IGjjHWL6y3aiYblw16J4vzFSMCWUr7o3M2n/afvL7rA9tR7ZuOETU80pZEZvgS
Rczw4mZaVqw1GF+4MKkfrX2m25vk06p/oepL1RV6fVNpbfSbxP6l7DsV0NpOfRWYLTtW9ulzAOPa
K93BjB//6HVwOvql2htHTtlN/HjDFmmdzj7/JOMHUZKdPSfBZ1iCXf6Cm+E1zt6SyCvy5H0kaTzs
Z83dERBwDi8BrN1O2ix6y3jTpm/f+aXvNr3vIELWfOJsTzipwESHICp4enHZnxnehR1MjUR2jni6
bdi31ghVUJQVPWDosIK3JzdfW1UJvVCYH9XYC3n0RObyVJpsuaWTD8M4Wy79d5RRzK77Pn3jpTLn
P3w46lm4ULs026rfKCa3NV7pCjILrIKzu2JvNB88BDukAWvSLpWNj2JZ2hQ6B8uDz2/4v8c2Kq3N
s5F2EMPryLSycIVRrD3j4EucJDx0es1Ovu7wUtofyRIG7HjXU8Snmbr9j1Hf9YFtdPvml5d6Z4dp
j9XFypzBi42hjrP5Im5vCayGoDKA64Ko7TPV3iRLsm6M6F/I+lJ1xb6/EByptDb6tdOVyHtGrhJz
fNEXPDPBgkU7mRWO8e0V31NpP/7R6+BU9Eu2Nw4aTV4LmAMk9vknaT9FYVa6TYTPsASr/AUz3jUu
TRJ5RZ7k8XCAN3drj4BzeO2x2vWULfFNPDnrGC2yPng3OqFahyY6BFHBTTNZMj85o6qVLfMaMSDR
yHlQlhXVmWpLqkwz1LIBk/yoxl7Ioxcp3xr6ylNpTGXo6fXZQjEjrj9veZ2xaXAgZSXMEMo0Pn5V
iVIf6JxNXb+q2B0MKV3JPbydmlwGDIZVALrOTDYRFCYW02AC4v1InWoDBJPzPjKt5ENhFGvP2uBr
MHudzbJMJhP4S/v2eVLaH8kSBiTv82T/sk3Dt/veChifTCPquz6wNbUHej5JwxLTiPZBz7fTrMkz
BvSXG6lceTCzr9Nah8don23tTfIidRHR1nFCSWOrL1VXTG2Dub8QHKm0NvqVuiLYvyhp567r8oVY
aqFOZkPKPNI+FY7x7RVvR8S5HWVsveJ+Ku+p6Jdsb5xfxZONvHEShp/b5x/b12nyBfGTuh1lz1p6
avtplX9AeJkmwt6SyCvzNMgp85PjzwBD7jYRAs7hTQTb7ky0IvfcBQ7nMYgrKySkcbbKQKAtdxMN
mqzghkZD5meq4LJxGzEgCbAwqqwBqcwTWLhzUJ2xOqRLNfbBg3ZwMZQ8nMc/QNHTmEDSmJb8pFgt
9K3hVbbgzaBIZ0xLKmQ1vSnUyHxBkcbPryKR+tgO/apidzCkdKVj0hSDIMQ/NEsgdUaf4TW+RBhT
+lE6Xa2J/bQZ1jCM5kalVWwpjESdVs+CITXDa7LZIDW/p7Q/enrB+1zZv7Qden3XB7a6reqYjBsW
mFLy73baeBifOlGfO57ZMn1/5oB3iY99+yxmeG3tTWIkyxrRv0gaW33pdSVY4aL6C8GRSmuDv9AV
xf5FSTt5bRTEYYDYJsV0j0E+hcyj8VE4xrdX1PZHz3sK+iXbG0dI54kIaBBg4719/knGD6JIoduR
9pwIn2EJVvkLZryrSBNlb0nkHZWnzM80Hg7w5m7tEXAOrz1Wu56y1xLLlC32E2pv4EOOACKlTjtU
A+zEFVw2biMGJAHtjCprQKrzH9j72tA/mSQbHDWA9w/i+mxp0XszjAM8f4No30EwjR//nib9lGBc
MoiHegW713bZdOJzAJDALQkfw3LsierX421ttY2n+E7h9JuA7OZbpSu/DtXLBvwKL1vS2ZN2aRqU
h0uRnRifNZ/gXkdRktRp8I0xbi8QJ6Ka7Ienl2kNL6NE/tQBlRrQ5llbrt1XuQVDpPZHSzyX9j9G
fdf14LdVDZQxg3b2EFEI/1SI1Sn5Eel5tIZP1qp9Zoxqb7J0WY9H9C8aP3btc5L+QnAU1RaJ5/5r
EvvnOexse4uT5m11aGRqcckvVMydnX0qHG0cXlr7M2X9ku2NA0aTNwZiw2NC/hr/tuNDUaCVPWv5
29VHkTuOTXfDeKm/xhr1OltqtNW2OCWiC0Ug4BzeCGBuzmi1b4q/nc+VltlgqyGC0e932WprmVVq
Ta+C6Z+MSLGSdoJtp1FWS0HzNVkhR3VS0hmQDqamAZsBiUbOg6KsdGEZD4DqDw7MkQdMD2hxFld+
MiXNqngoUb/XYVXNeR0sz5OfJeIDKrHHp8D4KsR+d9X3iZXBUjqfw0DoILTPNADui15a7bLe+gor
yYN/vD2QiE/w3a3EDh2yina4Um+txer1lsRfhygen23UL9eXd6r2cFaopbO6TWGlq6ATIZe3Y53w
fTNS2iV+6qLaYmtrHbba6bCO97e6usrWe8rT0/VUa3fYmkbb6ayy1dUO6ypystxSp4s11llbY53V
FbZcLcq94Rxb0/IvXpBMG1lfOJXCyGoAuaIOtoNcia1qTn6/22HLlUVc0lzVXuBQ2h/Oz/Cn4zo3
9j9Gfdf1kEZHQbRvPX8DJ+BJdLWxB15nU6jXJr6k8pltb5UVPIc37WsPKazQ2+ce2d48fmQ9HuHw
JtAXvb8Q+Kh6ZqPfRPa/4+0tl5UfNOb1a9g28TZUtyPevzYaK744gZCNfer1xKa9GqzU8s714G3l
6PFPkvGA4N5CvwnsjS6v4Mf2qviOx5M+fhBcWNlzInyGJVjlL5jxrvH2RpdX5Bkcb/AiJY+m8TDW
G3nAKdopf1mk15sA6+5WQ8A5vBoYLogIrC37Bsi84U9pnQCktAOt8C2bnDnidOk0S6fFyay8I8v6
lirZVvCgQ8f3Tw0PdFKzxXG6EmVx/sVfcPClToVVNEPaNCvg0rxBWGtwOnX1vWCRp6DPGmc01Fvg
+A6Cv3kcfkrJn/cQx1LZK1tzwAUG/bUl7bRU/MRSBvdLSj0UQg4yT2eDD59l2Rb9IodF+fIB5bU4
NE3IPrmr0lW4A8LOLK/senHJO5BH2mXQftR9qtCULMpOTLPJoK4L1LV9MnezTvX8s/ipq6iflT2g
ayqWjdrYMy+rJd6mezJn+F5eaZuIUypgn5T2xxNmXu0/aX3nA1uhB12/avtFlJbt423sQR7yM9Bt
atDu5LJqtQvnzdZOTJyNbp+9JfqBF4Bke+MFy3o8un+h6oveXwgUaPql2/8stLeerIE+BtI57HsL
bCHn2ZE+3hDw4NXGPvV6Ym2HhPZn2vql2lsieTVM44PKLq3wDOg2bnwoyre1Zzo+wxJs8xf88KuV
vRHlFXmGxxt+hzc0Hg61/wsstAtOZ96FJQLO4ZVQuIBAoI8zg8W8f+AiBlZpnJHRJmqwZrZZMSf2
4mgD/WyRtQNrb0UFzxqWyHbFN3GzZW3Gx+NIvoGPOBFaMK5d9RlDwXtwaRzO0bJmRext9HjHDncJ
p6LWG+IzSZqDj5zVgjPA6Txr4LeAxTcg/Qdy4Zs4b4bW/x1SjVFfsMvqBb/Tm8ITgxu4jLa/UvEc
d/P+6u5KnWX1FxOeg5Et8Bmg8M8OH0y3HfrFYtRyRHxxgrOM2/9TnzUJ2wnHQX2CSDoW+lJhD29h
a+Kq23pP6lDVE0EnruH95PZIiPol8hpeUziLWmD1mFNz7eyBas+c9z5r1Qq+FzKCv3Q2z6qN8Anp
pPbHg2c+7T9pfed6MNiQxWGDttZkYw/ddp3ls+G2f6hf/ExRfdzldub2uY7La2R7mA32F3R7UwdS
xfUvVH1R+wuhHbp+qfa/8+2tkBWv2MeUIsYbEGHTNvbJZ5Bp/e+QJ/v2Z9r6pdpbMnk1TcQEE+RP
GD/ohdvZMxUfVYJd/orezt6QniCv6K/1MYIoceR4GO26pr2A51utTOdyiLzcVSGw2xze93DRsMN1
vwkgsLVxFTpr12HPPoA+7IfDhw/Bgb23GHPeuHoJOl2AfbAFcPAuOH7nASPdLEZuXbsCnR7AHuT+
rqOHgEt47o/PwsefeQXwBElo/snDgzjB+8bVK7De53f74DjST/on8uf8HCXlvwXXrnSgi5LsQf4O
vO8o6msy3E1fvxtw8fyP4Tra2T2n74fJozoZHFwuSRHYhCuX0DZ7fWxPDsLh990FhyLaElECpf0Z
pplP+09e3wVSO3zd2oCra+twvb8HYKsLW7ccgePH7/S1meNwaGqf///2zj82kuO68y/ArqCVvevo
Z3xrCwubsLMGrDEiwdgksOybdYCT7o9QCBQkSEYIFAOUghwkIn/YoJEzcPwjwuiPi2kExkhAMsJZ
FJKjz2cGSEYBQm1MJTAXxmzgWcNULG5CQcfFhWtxL8NYpHdo11XNdFW97qmeqTfkcGeH3wHIqXrz
qvrVp350ve6u6v75ydtb/zw7GtL6svrDOl94uyXtf/TG2119Hv7+965Q6z230Y0fEZ2e+LA+vx5c
O/Kc4kKx48+w69fmL58PxJXzMLQGmz/EtefB+cTlPwifwcorO9LlV56iwm+/qBPN0Frrj2giPDWX
ZTrm2vtxD6Vp8/RD8pDMVEVWzuMmDId3zBvsgRVv9w16/tkF+qXP/xd6eCLtXl279BL9ykNPUkMf
bGphjV54fOLADouMQAAEQAAEQAAEQAAEQGBQAq8//xh9+guLeuXgAu187XE6oHsbg5pzS6TjDqPU
YGnaPP2QPCQz9mXlPG7CcHiltXhU9bcv0vlTv0gXTPmLJZp97FM0cYroe9/+C3ruxbZU/zCtr5z9
Ma6cHdU2gnKDAAiAAAiAAAiAwKgQ2LtKL/z+o/T0i+aWTJGWNl+j8/eOinGjbQd3GKWWStPm6Yfk
IZmxLyvncROGwyutxaOq3x40SnrQsM5tBsTkDK18dZbOncZzIhkyiIIACIAACIAACIAACBw2gd1L
dP7EQ3ShUKLaN75Kj0zcOssHDxtV9njcYcz+1i8uTZunH5KHZMaerJzHTRgOb79aw+8pAmbd0Js/
eIP+5e0t+vcbN+i9d72fPvqxX6CzZ9KPOacSIQICIAACIAACIAACIAACh0xgd3ubjp08eWD7JByy
+TftcNxhlBohTZunH5KHZMa+rJzHTRgOr7QWoQ8CIAACIAACIAACIAACIAACY0qAO4zSIkrT5umH
5CGZsS8r53EThsMrrUXogwAIgAAIgAAIgAAIgAAIgMCYEuAOo7SI0rR5+iF5SGbsy8p53ITh8Epr
EfogAAIgAAIgAAIgAAIgAAIgMKYEuMMoLaI0bZ5+SB6SGfuych43YTi80lqEPgiAAAiAAAiAAAiA
AAiAAAiMKQHuMEqLKE2bpx+Sh2TGvqycx00YDq+0FqEPAiAAAiAAAiAAAiAAAiAAAmNKgDuM0iJK
0+bph+QhmbEvK+dxE4bDK61F6IMACIAACIAACIAACIAACIDAmBLgDqO0iNK0efoheUhm7MvKedyE
4fBKa5HpX39Lv57nnRa9/yMfo9MnR+H9s9t05fKb9O7xu+kjZ8/Q7czWWzV47cpF+tbfXqR//rdd
uv322+nUqdM08fBn6eGJ0XsN0vbVK/Tm/32X7v7QR+jMneNAfx+tZvcaXf7+23T8fffT2Ykj8Jb3
o1berqaxS2+98SY1W+kfTn3wY7ovjMLYmLarX+zapb+k6l+9QYXHnqRHHjgC7TcBciuNt7wO93av
0+b2Hh2nFh27/T66M/J8vH39Ou3u7dGxY7fTyTtv3mtLjmp743U4bmHMB8atRo9eebjDKC29NG2e
fkgekhn7snIeN2E4vNJadPrb9JVPnKJnG0TllS36/LkRcMC2L9L5U79IF6hIK83X6Nwt/X7tbfr6
Fyfp15+74IjbQKG8Qt/9/DkbHZnvS185Tw89e4FG1b7DBLV96St06qFniQpztPXdZ2gEesdQi3/U
ytsFU489n9Bjjx4OU59Cua776oMp2ehHtumF86foaTP0HJH2S3TQ4+0eXXzpOfqz727R3SdOdKp8
R3/p8M++/34qfOph+pUHJ9Lvxdx7i1740pfp0jsn6De++CU6fybmouEuvfbCDH326S+nmtXU3BLN
PXM+56LvHl1+9U/p+S88TS+nGmyBpub+uEe61CEOMHIU29sB4hvRrEZtPnD19Zfov738Xbr77qQ/
ZrjtvPMOnf2NL9JT5z/Q3Xczuja6s/MOnThbotmnfonq0v5uM8H3yBLgDqPUSGnaPP2QPCQz9mXl
PN4O63/4DESgqaqTpAzjufrWQDkceKKduippe4gmVb154Lkfaoar81NttoZvoTSrFmo1tbhQVbNT
k2pmYfWm2FKq1Hset1EptW2enOut1zOTMfmx2ah06m+yom7xphhVI0etvF1QWuuqMj2lpqam1fR0
px+YvjsKfcGOJf36ry+THtuLnbGdJqtHov1aRgc33jZVxTJsn5MSnjw8vZBm26yryeT3uHPqjlqc
KbjzhL46oQos/8L0otrxlZqEtlS1lLalUGB5FObU4Z/Nj15766qWHgLbNuP7b4/MDuCnWHtGbT5Q
L7N2zvqJ6fPub3ZFE9pScwUm478Hw2WdYoD+fgB1gSyGS+CnP/2pGvTvJz/5iZL87e3tqdBfq9VS
2b8bN26o0N+Pf/xjxf92d3eV/dvZ2VHGI8ZnIAJweAfCFpVoQ80mA25xpqZaUWmGpxR74orVG56l
o5OzcwCLR8zhPSLl7d3SdtzFwFFweAfpl63mhmrUG2qj22PqXfRb8tdhjLf+/FiYrqrG6qpqNOpq
sVpWRTZpLi9vemLugm3cReSN2oybqBdnFxPnualqs5NOPlNb9/nrUL3ifytMVdTaVnJ2ae2otZUF
NTtXCzjJqSyGEjla7U2GcJD+KzuCTDvWnlg92dEH197ZWlf1el33Q90XV+aTflhU88sNtdpotH9b
2+wMeOsrNbWwsKAWFxc7f/Pl5GJSQZXnE5n+ra2zsqaNGqC/D14UpDwkAoM6uyadxNk1uiFn18iy
zq6Jh5xdI+POrglbZ9d8w+HdV6PxHTzuavS+DhaX2E0YbvE7vO5Kf0EtrN9sd1ep2BNXrF5cZd7a
Wq3VamfSeUQcwKNW3t6tU1/tT55+uVUd3t7lG7NfhzLe+vPjZKWRBtZsqKnE6U21D3f+inF4t/wd
ZP0USfqurP4taX9UZHdsN5f8HeCuNGkTERsdAqN2Xo21J1bvppBuNfzTgDEX9Zx+STWCU7IB+vtN
KTgOKiEwbg4v1vDqZzkG+2zTS4+doicXiebqTXrmwZP01sW/pL9Y/Cu6/Pa7dP8Dj9Lnfu+3aCJn
He3VN16nv/vWP9L/aW/G9D665/R/oPfedoPe+6HP0PnAJim7Vy/Rn7/8dfr25beJ7riD7rj7g3T2
45+gT557mB60GzjtXqInTjxEL9Mk1ZvfJG2S++xdu0x//a1/IdLHuO2Dv0yPPHja/RYbuHb5dfrW
P/0r3f8L/4nO6YJdvfQqvfz1/90u7z0f/RQ98bnfoQdPx6y76nPEvcv0xPGCLkeJVltfo7N99rzZ
1htbvfLKn9Pf/+CH7Yzvuf+T9GufeyK4sdVbF1+l77x9g37+M/+ZHrj3WFJnF3QZfqix3kMTn/lN
+oPfOpdaW/bGS0/Qx57UVCsN+uZTD+Qaf/mFJ6jwtNab03rPPDA8PrkW5P8Q0972U7/Xr1yipde/
Q/+8+W90+/vuI3rjf9CzX76gn66vUPObTxFrivlGBn4ZpL5MNqNU3pj2uf3WRfqbf3ibPvwfH6PC
8To994d/Qj9496M0VZ6hh3VXvfjKf6c/+Z+X6f5Hn6QvPZW3NjEAMCC6pseebyzUdH/RYwnpseSe
O+iDHzpLn/zUI3pcOBNIsU2XXv1f9PW/+Ta9/cN3dZL7afJ3n6LHz4V0TXI/NmqHRveFfmt4pfkT
RY2HSUli++91zWXpB9fpNkvgxg268+N6g7yzvVegx9SvyXI//cuaFPMda4/LSzjeunQ9A73awDX6
4s/cR8/p9EXdPl6z7cOdv8w5dUufU/O57119lR76wKPtNeOzy5v0Xx9Obyx2/fXn6a5Pf0EfoUCL
63X61TPH6LIexwt6HDefhbUdenwi7lwl7y/tQ/T9N2h7G5Y9V/S58R/ZuZEXoD0+fedtuuvn7fxk
j65c/Nu2/sc/+6tkuohk/sPz7heO7b82H3H7twkjv2PtGXw+IB8PI033aq6vdc8VvRIL9dUfoL+z
7BEcTQLaOR7YMGnaPP2QPCQzhmblPN4O63/4DETAX9Gq1tf0WqKiaRmZv5JaSV96VkqvdZvLrCHi
6fSGRxlrWqo+P53Jlx2HrzlyV8jTd3hb60tubZQ5VnXANcf1uU4ZJ/VjX7U5v07P219UtY3g5b9M
mcLRzUZNVSpVVa3MKLsWa3ququarWqb/zG8rmWcM69V8NlPVlczj0E23NqXSrrPAmhbLc2tVzVcq
an6+qqaTtWhmLXF1fr5ti7Gnqn+vNfwjefaK7lRlSfPxj84dFJ8wtT5SQXsbrH431fx0qO0nbXRf
d3gF9WUxjFh5Y9unZV+cnlVTfP1USbexql/PbtpSpTH4qujlcqhd2vHErMXKfLZW3N043447+pPl
pUz/smn92Ji6g2d/5t/i/CPHwwH6b2iNW/d4zI3Xj8gKxh9bx8MaP41lEnsGGW/Tpe8V69EGWqtq
OjlXztQ2fCbu/NX/Dm+znuwRoPerWO5qtDrL5oo753WewPL2UGk++rFlcX/xpekbGqS9Dc8eP9bq
TTi7bLdt1/cHr19ZWY2f/3TlnCMYoP+anCTtP+fIYfEA9gw0HxCPh2Fz+0pdX0vPFXPT9dX3/atr
zM/r77kHww+jQmDc7vBiDe/ALct3cD4RnJ6rqPKUdwAKM0vsCOk0hdJMezOm2uK8mpnsOF/ZwcJu
kNA+RnFaLSzX1epqQy3X9HqjKZ2GOxRsUFpJ5sQ7a4tszVRRLawOPlm2Azgv71S5qha0g2plWftZ
4fsGQxMAm6/9nmUn442lWXdcKs6opcaaWmssqVn7OJueVKUmVGydic3PfM9UFtTCXOJUJDybK2Wf
dzI542lcuL3JQ6doMXyKc9kLGn2x7ENB1t5i7E/Xb0vVZthFg+KUqi7qiyGLC6o8nThWvH2KS5K2
3zIP1Vcn67R+v/417PJK2mfaloKaLOU7plPzq2KS7QR6MmXXT5qLN7WVhlpbW1UryzVVLU+ryen5
ZB2kzX5TldnGQ7PzS2p1ra6q7AKHfrrFKrNvXw/p9sJU2kF5/rHj4SD9d0Ov4ZzT43elWlHTEY9k
S+rXFDddx52LBgc5fkrtkY632drrHWdtIPVIs9loyp4fp1SDP07pzl8Sh3dGrYWusbbWnFPddnj1
pNs9Rt1n80FXLnF/cSmjAtL2poZqj6+v0BIt23Z9f/b6dlw2373nP1FY2koD9V/xfGC49lhmnE+2
v6fnA/LxML4EGU3X14bg8Mb294xJiI4eATi8o1cnN8mi7IBfUsvu7qP+zd3FnVKryUmdT0imKum7
j6vVwA6/+gRnd62kUrX77osuuVnA7T58ENPi1tqCu1OqHx5Ti2t8duFSRQfSA/ikzs9Pdpdnk0mM
4Op59sBba8t6EwS9IYLbIEE7o1W/cYL5rbFpy+s3WtHPECt/n9XkuunXcNGs8vcQQnXWyY+vwWxf
326uqZrZtKG26BzoQqncjtuNHMyGDctr/mp4FB/tAPoUWQIHG5e2tyj7Wf3uNJJ1unqiU5ytpZwl
ztO3Emn5BPWlsx6t8sraJ2c/WTEO7Wqyxso4Rp11U2uhMUKAtFmfSy7iFFQt3WGCuawv+KcnKqmn
Qtj4NrUQuFvm681PkLsPIc5fMh4O0H+5hcHxmCvoUcVurBc7/vA6NjvpH+z4KbdHNt6mCh8R8W2A
JvUu+3qsXFiYV7PuvEiqvOxH5naG7vzV3+Ft2M2ncneB98efNA6uW6dMKvaCkbS/REDJVenf3kwR
ZP0392DBHzyvwRze/vOf4GHzhOL+K2//eYcOysX2ZC9w5fR3Nh8Qj4dBQyOFrq8dvMMb3d8jTYXa
zSMAh/fmsR+xI/sThHkdwmJmc6Utd4dwUnXutjbVvD3Zl6pdk0Q7GeITRD+Bj5ugKjeITanFZbsL
n5kwT6ql4KPGTVVf0q/70a/8qXX9acezVk85MdZGc8Vy3nrxSa1sLid3RNkAbnbuk+TvKrjvBgnm
yfAFdwc29Ignd8bmnaOfrjO9jssd0ukHXkPiJiOpK5cuqQtE8cmdoLlsDiggb29R9rP6XbJ3dwv8
okLH/IPZpVlSX6NVXmn79Oyn1aq5BqP7sr3YVUru6FodPkaIGsvWsrvDa8aEucUVlWzKGchmRy2Y
J0jaTzfo+tU2mV3PkLXcAAAUVElEQVQOzZ9+SYDe7TZZ0sDag8/E11u+rfL8xeNhYlBs//X2+8lq
nv3S+jV52/qLHz+5Rb3Dg9jjcowYb51udMC3AX6Hy4arjcBlP3f+6u/w1u2Skdzx1B9frxNu96fO
K/uyT/30KJCov/TIJ+In2zby2ls7i6Ha43nJHd6Y+U8EhByVmP67r/afc9w8cYw9Jq2t05793bVf
+XiYZ1+U3PW1ITi87XNG5wmWnv09ylAo3UwCcHhvJv2ROrY/QZSq5o5M+uMm/Hpi2XZ42QQ29SqG
JJkdHPkJz53U+U6T6cOkY24Q6ww2dh1scI2TSanXOVkdOzBlv5fZ7TlrY3F2OX1ck5V976qeALsk
wvxdpq4c+YOxX8NVUnXvt7os1I7dhZBPnnidNbyuDem75fb+sRWZb1tuXjf8dxu2etF8bMJhfA/Q
3mT2b6hystZ0ejH96g9TnGB7EJdTUF8jVl5p+3Ts7SPvrA/Y/mt1+rXDfMw7+pUt9nFSPyEpTc/p
5QCZu226F7udbgMTGDdODOzwyvMXj4cJiEG49UsjrV9jis1zGOPDIPa4dsLaWvAJdacoCfi+S5Mz
al7f3bV7IZgLxNkLpu2cnR18zA4f011gLZQzT/dYfX/Hr32+ZXnH9x9Jf7HHHezbto3etg3THl9f
Uoc3av4zGJZ2qhg2+2r/Qtti7DFZWr24/i4fD4Vmp9Vdf8ifY6US9NX37Se6v6cOgMgoEoDDO4q1
clNs8h08dIfRTfj144hth8wNGPruKLuzaE1vJFes+QnPP7ZV9U6kTRD6ZsdwE1I9WQ1eTW+n31K1
ypxet5bzV1lMTSbsAN5+RCxzfFde7vDqh3cl+bssXTnyB2N3PH1BIThJc3nwyVPvOnPHzwR6lZur
9tJz9qb48NQHHGblj29vyWP1gTVuXfazRwSD7d9uKrOv8grqa8TK63hFtk/XdszdKPOx5XF3APwE
io8RHWXZ/436otszgI8Thalq+05uJzfP3uhMlkpqcnIy81cMrPs1qX3afFu9Tmz+4vEwweLYBtp1
otL15dLY+shoSOvXJHd5Buxw+Q3YX1z6yPaWKo5ta3lpU8qxEV+/7rVEG4v+AmvgqRDX5nV7Czld
/Mi8vHa/Cv47f0Kik5d/VVFBv9td8onrL5Icu3Vd28hpbzzFcOzx9RVi7+5qOvu8fnD8txfA7fyH
F0AYdmwC/cZmxdtD/HzAppZ9x9hjcuyl5+x1/d3zjB0PZVZntKV9vq++tz+6v2dMQnT0CMDhHb06
uUkW+Q4eOkG4Na32EVk3YHQ//qPUuppJ7qK4wUKXas2tocts7pFXYneMKbWyuszWAOr32Qac7Lxs
8uRuAHcnPa/ZPYD738QhV44cZ1Zn6I6n1ybbO2Cp47DHv3z99K6zVHoWseUOXallav4EN2w+/KB5
Yccwvr3ZcoacFMfbnqBd/qFdg/3kMrWpWp6tuXJBfTl7RqO8jldk++xib8szBIfX4m5urOrN2vyO
6Gai5e/W+DsOfEyyaXt/+3oLtaVOWnn+4vEwMdKy7dd/eZlsmjz7pfVr8u6Vp8vP9i9uTETYpY9s
b6ksbVsblsPLxsO6XXvbbmuZp2ycHf0d3p3V+eglLdVko8aVsn26QT91FXiiOsUkEOndXwIJBKJe
bSMvm4O1x/fZ7o3o9NM8yeZ1vj9w/W6YXfOfvEJEyC2bXv13X+0/wgauEmOP0bd6npnPxdnr+rt8
PPS5DRByfS1/jpXKta++bw+8vD37e+oAiIwiATi8o1grN8Um38GzJ4jWur+Sbdff8U0z0jsH810r
9WOGelMg+0jwjrtKqu+w9Li66YrPByX9bG5606q8dbwudd+AbADvm12+Ai+HhZHVZncYS9XMxEnr
+t1c7RpqkwGvs+6TdPYQNr5qXwvjTk72l/T3vvi0NtWKXke9pF/xEHqsOn2kiBjjE9veRPaz/EuZ
tc0r/JVVfZj1Lomgvpg9I1FeZk9M++xib/vAEB1ex968yimwK7F3EJJ1xS5Bv4CvNz75yaaS5i8e
D5MDxvZfbl9XffAfTVhYvyZJrzy7J8AmheAzgD0ud9vWDsHh5Rd3zUaKS3zzNGdH6CKaszYJ6EeW
k4vEoTu2fvf4GX05ufPZWfWb7BVm+dsTsnn3ief0lz6pev7cq230TGh+PBB7vMPlL3q1M1dLs37H
eN+ffR+Pmv/0LUS+QlT/3U/7zz908Jcoe3TKXnUa6u/S8TBoXKzQ9bXhOrw9+3vG1s31Vf0WAD4g
ZBQQPXQCcHgPHfmoHtAP+OUlu/6tpdZX+GZR7M4sey2C2XV1ab2pdrbWVMVtDJOsqdMOgnfF/DpJ
c/dlqrKsthJvqNVqqvXGsppfrHsHiQ1i9jGvLftoaXtyMKVSm60K0UoHcGH2Xp2VI/h4UluTvxKn
oCpsx8+Nlap/dG560fMZ0OF1Jyc9QZtnm63sbDb0Zl8Nl//gfHb8hma6nsxkbN9O7wDtTWa/vovr
XlmjX3elubR2NtQCmxyZNkvMYfMVHBvyfczfpc9JO3LllbXPLva2DzB+XTo5KPLEDb3Lc2Gqoup6
UpFqXzvrqpw4vO0NfpIMdvQu7+06NPWo062ztfKt5oZanp/VjzQvuAt0/ri+3oq6LZttrtobXvEd
5bWyPH/heJgYFNt/vf1+slosLzv70+bL6tfk3av+nI0DXyCS2+PKa9vaoTi85lqBfYdu5wKva1bO
Dr2x1EJDbW5uqPWNDbWR/K2vr6utHd9y3SPuun3O1tZccdZr/nV16QvFZmOg5Dyr05hj+Ny039hc
Vysra04m7S/OgAECtm3ktzfdfoT9V2rGin1Hd7GszANhhgd/BZkZC0IOb9T8R2oM03d9o+f5dx/t
nx0rJhhnj7y/y8fDGGu5TjIO6z7U2lxONkXU77HWOxe23IaEXJ+FXd/Mc5D9mO/bSCd9bn9n2Zu2
bc81pcANDKaK4CESgMN7iLBH+1D+iqjtqNnvasa7tOtgsnrGAa5Uk3fZsgluu/xuYPIn6kKyWVA7
n8Kcd5DZoGQdXpMHnwAQzbjXJEn52pNydkAz+biTQMphlx4h0dfl6OxQy+/OBvLSV3XtuxUNi0Kx
qIpFu7Os4VXKPLrm66yvA8UO19pcYrvb6lfwTOr1jO44Zcd/cD7erk7b0Hcl+EyM2SIJStub1H6/
a65vmx37i6o8l7zSZl/twXOJqa+RK6+gfXaxt3cs2HjQpSNpDFrXbfqk+4rZOMi046nM+36znBv2
6YZ2mmQtr2v7Oh+9aZC/QGcN8vXWaQ9J+wg4c+L8JeNhYk5s/7XWm2/LmtvPLwa0dQX1y/Mc2vgp
tKddBvMvdrx1CWICvg10l1c7J9N+nJ61F4ydHdnxxMcL5WSNuzGhtaZm2LlwcmpaTU/5u5HmXNf1
jt4MI9LvDi/PldWMTcfOp4P0lxgyIZ2Y9jZsezZqyRwk6eu+7RdVqesJEO/geD1fT0aWnf+Eyh0j
i+6/mbrtPx+IOXq3Tqw9tk6723/+fEk8Hnablyux9uTVl5HnLl9hc8vwTYgB+ruzdEvNuYvnug3F
btLq0iMwLAJweIdF9pbLl70GJXOCKJZm1bK+g9v9aapa2V/JMgNMQe9guaKf4mit2TVJ7K5wkkFL
30mcm+Yncn9iKeo7LN1XyLvzWJ3379Sk6Vq3aRESO2CGrsA17TtZS9XAHZ+IzLmKG1xzdmDmus1V
NTdl12Z5LoXSnEqWbjFtfSc1uaOefq8oU8kJNtdqqsQmV/akUSqbO1idz+B89GPtbAJoHvXjFyxy
TIoQy9qb3H79ehrerkw/0BPImr494NpzaT/tQVpfI1jeyPZpH8F37wjVd6ynDU/m8DqdwK7wEY1B
NVdrarrU3Vc6bVm/pqgWepy+pRqL5dQFH9v2i6VptbBiHxjlFph6833R6pPdz4Cr6vtp0vyjx0N2
nJj+y9Tbd9Oc3cn4nn10v60fWb9GV96/uEWRYYE9LkfJeOsS9Qv416yEudX9HhP2QojeWZ9fwMzy
N/Guc48u7yyfLCd1RcVZ1Qidgo3ZOk0l53zK2+hg/aUfl/Dv/A6XLXeW2/DtaarF7BM6xWk9P9FP
riX7ifg75vkOb/78J1z2GGl0/x2k/ccYkNGJsWew/i4fDzOm5Ubt+cO2r9B3V/+yufExItivBujv
Nm/97R/n1nNi/VQNPqNBYNwc3p8xWHXDx2cfBPb2dkk/skd7e0THTpykk7cf65nb9rWrtNUiOk4n
6PTpO3vq8h/3tq/Rxua7dPwEUYvuoLvuurPvsXj6cQ5vX3uLNpqkiepKOHUfnbn35BCKu0fXr25Q
U9fccV1/J3/utOZ/cIe5/MpTVPjtF3WGM7TW+iOa6N2Mog88aHuLPcDe9au0sdNpz/fp9nxAZsce
vktvFMt7OO2zC0VYsLdN1za36N3WcaK9Ju0du5vOnLm3T73t0tW3dNvfaenx5xTd9XP30Z19xrnw
wfOk8vzl4+Hw+u9I1a9GPGr25NX6wcj36MqlZXrz/72H7qTr9KOf/Qj98oMT1G9o3tXj1ve/d4Va
77mNbvyI6PTEh+nM6UA/GKi/HEzJgrkM2R47fpqz6Znc+ck2vfTYKXpykai8vEF/8MmTtL2zFzX/
CZYpShjffw+n/cfbE1W8lJJ8PEwlv+Ui23T54vfpXT2v/ei5B3Q/xmcUCOzHPZSmzdMPyUMywysr
53EThsM7Cq0KNoCAJvD684/Rp7+gZxClBdr52uN9J2yABgIgAAIgAAKHT8A7vHrTKnrmwWFcYD78
UuGIIAACngB3GL00LiRNm6cfkodkxqqsnMdNGA5vXN1BCwSGR2DvKr3w+4/S0y829DGKtLT5Gp2/
d3iHQ84gAAIgAAIgMDgB7vBuaYcX9+QGZ4mUIDCaBLjDKLVQmjZPPyQPyYx9WTmPmzAcXmktQh8E
DprA7iU6f+IhulAoUe0bX6VHJnC1/KARIz8QAAEQAIGDIrBNL5w/RU9f0I80r2zR58/B4T0ossgH
BEaFAHcYpTZJ0+bph+QhmbEvK+dxE4bDK61F6IPAEAjsbm/TsZMn+6yjHMKBkSUIgAAIgAAICAns
Xr9G/9ps0V0f0HtZ3OyNG4S2Qx0EQKA/Ae4w9tdOa0jT5umH5CGZOXpWzuMmDIc3XUeIgQAIgAAI
gAAIgAAIgAAIgMCRJcAdRikEado8/ZA8JDP2ZeU8bsJweKW1CH0QAAEQAAEQAAEQAAEQAAEQGFMC
3GGUFlGaNk8/JA/JjH1ZOY+bMBxeaS1CHwRAAARAAARAAARAAARAAATGlAB3GKVFlKbN0w/JQzJj
X1bO4yYMh1dai9AHARAAARAAARAAARAAARAAgTElwB1GaRGlafP0Q/KQzNiXlfO4CcPhldYi9EEA
BEAABEAABEAABEAABEBgTAlwh1FaRGnaPP2QPCQz9mXlPG7CcHiltQh9EAABEAABEAABEAABEAAB
EBhTAtxhlBZRmjZPPyQPyYx9WTmPmzAcXmktQh8EQAAEQAAEQAAEQAAEQAAExpQAdxilRZSmzdMP
yUMyY19WzuMmDIdXWovQBwEQAAEQAAEQAAEQAAEQAIExJcAdRmkRpWnz9EPykMzYl5XzuAnD4ZXW
IvRBAARAAARAAARAAARAAARAYEwJcIdRWkRp2jz9kDwkM/Zl5TxuwnB4pbUIfRAAARAAARAAARAA
ARAAARAYUwLcYZQWUZo2Tz8kD8mMfVk5j5swHF5pLUIfBEAABEAABEAABEAABEAABMaUAHcYpUWU
ps3TD8lDMmNfVs7jJgyHV1qL0AcBEAABEAABEAABEAABEACBMSXAHUZpEaVp8/RD8pDM2JeV87gJ
w+GV1iL0QQAEQAAEQAAEQAAEQAAEQGBMCXCHUVpEado8/ZA8JDP2ZeU8bsJweKW1CH0QAAEQAAEQ
AAEQAAEQAAEQGFMC3GGUFlGaNk8/JA/JjH1ZOY+bMBxeaS1CHwRAAARAAARAAARAAARAAATGlAB3
GKVFlKbN0w/JQzJjX1bO4yYMh1dai9AHARAAARAAARAAARAAARAAgTElwB1GaRGlafP0Q/KQzNiX
lfO4CcPhldYi9EEABEAABEAABEAABEAABEBgTAlwh1FaRGnaPP2QPCQz9mXlPG7CcHiltQh9EAAB
EAABEAABEAABEAABEBhTAtxhlBZRmjZPPyQPyYx9WTmPmzAcXmktQh8EQAAEQAAEQAAEQAAEQAAE
xpQAdxilRZSmzdMPyUMyY19WzuMmDIdXWovQBwEQAAEQAAEQAAEQAAEQAIExJcAdRmkRpWnz9EPy
kMzYl5XzuAnD4ZXWIvRBAARAAARAAARAAARAAARAYEwJcIdRWkRp2jz9kDwkM/Zl5TxuwnB4pbUI
fRAAARAAARAAARAAARAAARAYUwLcYZQWUZo2Tz8kD8mMfVk5j5swHF5pLUIfBEAABEAABEAABEAA
BEAABMaUAHcYpUWUps3TD8lDMmNfVs7jJgyHV1qL0AcBEAABEAABEAABEAABEACBMSXAHUZpEaVp
8/RD8pDM2JeV87gJw+GV1iL0QQAEQAAEQAAEQAAEQAAEQGBMCXCHUVpEado8/ZA8JDP2ZeU8bsJw
eKW1CH0QAAEQAAEQAAEQAAEQAAEQGFMC3GGUFlGaNk8/JA/JjH1ZOY+bMBxeaS1CHwRAAARAAARA
AARAAARAAATGlAB3GKVFlKbN0w/JQzJjX1bO4yYMh1dai9AHARAAARAAARAAARAAARAAgTElwB1G
aRGlafP0Q/KQzNiXlfO4CcPhldYi9EEABEAABEAABEAABEAABEBgTAlwh1FaRGnaPP2QPCQz9mXl
PG7CcHiltQh9EAABEAABEAABEAABEAABEBhTAtxhlBZRmjZPPyQPyYx9WTmPmzAcXmktQh8EQAAE
QAAEQAAEQAAEQAAExpQAdxilRZSmzdMPyUMyY19WzuMm/P8B6hCBiTtvDwYAAAAASUVORK5CYII=
--Apple-Mail=_92711963-EDE1-4AD2-8A2D-BC4468D0943A
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii



See diff file below. Comments welcome.

Thanks,
Dino/Padma


--Apple-Mail=_92711963-EDE1-4AD2-8A2D-BC4468D0943A
Content-Disposition: attachment;
	filename=rfcdiff-pred-rlocs.html
Content-Type: text/html;
	x-unix-mode=0644;
	name="rfcdiff-pred-rlocs.html"
Content-Transfer-Encoding: quoted-printable



=20
  =20
  =20
  Diff: draft-ietf-lisp-predictive-rlocs-00.txt - =
draft-ietf-lisp-predictive-rlocs-01.txt=20
  =20
     =20
=20
=20
  =20
  =20
      =

      =

      
< draft-ietf-lisp-predictive-rlocs-00.txt   draft-ietf-lisp-predictive-rlocs-01.txt >
 =


      
Network Working =
Group                                       D. Farinacci =
Network Working Group                           =
            D. Farinacci

      
Internet-Draft    =
                                           lispers.net Internet-Draft                                           =
    lispers.net

      
Intended status: =
Experimental                          P. Pillay-Esnault =
Intended status: Experimental                   =
       P. Pillay-Esnault

      

      
Expires: December 9, 2017                            =
Huawei Technologies Expires: May 31, 2018                                =
Huawei Technologies

      
                =
                                            June =
7, 2017                        =
                                November =
27, 2017

      
 =


      
                  =
       LISP Predictive RLOCs           =
               LISP Predictive RLOCs

      

      
                =
  draft-ietf-lisp-predictive-rlocs-00             =
      draft-ietf-lisp-predictive-rlocs-01

      
 =


      
Abstract =
Abstract

      
 =


      
   This =
specification will describe a method to achieve near-zero =
packet    This specification will =
describe a method to achieve near-zero packet

      
   loss when an =
EID is roaming quickly across RLOCs.   =
 loss when an EID is roaming quickly across RLOCs.

      
 =


      
Requirements =
Language Requirements Language

      
 =


      
   The key words =
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",    The key words "MUST", "MUST NOT", "REQUIRED", =
"SHALL", "SHALL NOT",

      
   "SHOULD", =
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this =
   "SHOULD", "SHOULD NOT", "RECOMMENDED", =
"MAY", and "OPTIONAL" in this

      
   document are =
to be interpreted as described in [RFC2119].    document are to be interpreted as described in =
[RFC2119].

      
 =


      
Status of This =
Memo Status of This Memo

      
 =


      
   This =
Internet-Draft is submitted in full conformance with the =
   This Internet-Draft is submitted in full =
conformance with the

      
   provisions of =
BCP 78 and BCP 79.    provisions of =
BCP 78 and BCP 79.

      
 =


      
   =
Internet-Drafts are working documents of the Internet =
Engineering    Internet-Drafts are =
working documents of the Internet Engineering

      
   Task Force =
(IETF).  Note that other groups may also distribute    Task Force (IETF).  Note that other groups may also =
distribute

      
   working =
documents as Internet-Drafts.  The list of current Internet- =
   working documents as Internet-Drafts.  The =
list of current Internet-

      

      
   Drafts is at =
http://datatracker.ietf.org/drafts/current/.    Drafts is at https://datatracker.ietf.org/drafts/current/.

      
 =


      
   =
Internet-Drafts are draft documents valid for a maximum of six =
months    Internet-Drafts are draft =
documents valid for a maximum of six months

      
   and may be =
updated, replaced, or obsoleted by other documents at any =
   and may be updated, replaced, or obsoleted =
by other documents at any

      
   time.  It is =
inappropriate to use Internet-Drafts as reference    time.  It is inappropriate to use Internet-Drafts as =
reference

      
   material or to =
cite them other than as "work in progress."    material or to cite them other than as "work in =
progress."

      
 =


      

      
   This =
Internet-Draft will expire on December 9, =
2017.    This Internet-Draft =
will expire on May 31, 2018.

      
 =


      
Copyright =
Notice Copyright Notice

      
 =


      
   Copyright (c) =
2017 IETF Trust and the persons identified as the    Copyright (c) 2017 IETF Trust and the persons =
identified as the

      
   document =
authors.  All rights reserved.    =
document authors.  All rights reserved.

      
 =


      
   This document =
is subject to BCP 78 and the IETF Trust's Legal    This document is subject to BCP 78 and the IETF =
Trust's Legal

      
   Provisions =
Relating to IETF Documents    =
Provisions Relating to IETF Documents

      

      
   =
(http://trustee.ietf.org/license-info) in effect on the date of =
   (https://trustee.ietf.org/license-info) in effect on =
the date of

      
   publication of =
this document.  Please review these documents    publication of this document.  Please review these =
documents

      
   carefully, as =
they describe your rights and restrictions with respect =
   carefully, as they describe your rights and =
restrictions with respect

      
   to this =
document.  Code Components extracted from this document must =
   to this document.  Code Components extracted =
from this document must

      
   include =
Simplified BSD License text as described in Section 4.e of =
   include Simplified BSD License text as =
described in Section 4.e of

      
   the Trust =
Legal Provisions and are provided without warranty as    the Trust Legal Provisions and are provided without =
warranty as

      
   described in =
the Simplified BSD License.    =
described in the Simplified BSD License.

      
 =


      
Table of =
Contents Table of Contents

      
 =


      
   1.  =
Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   =
2    1.  Introduction  . . . . . . . . =
. . . . . . . . . . . . . . . .   2

      
   2.  Definition =
of Terms . . . . . . . . . . . . . . . . . . . . .   3    2.  Definition of Terms . . . . . . . . . . . . . . . =
. . . . . .   3

      
   3.  Overview  =
. . . . . . . . . . . . . . . . . . . . . . . . . .   3 =
   3.  Overview  . . . . . . . . . . . . . . . =
. . . . . . . . . . .   3

      
   4.  Design =
Details  . . . . . . . . . . . . . . . . . . . . . . .   5 =
   4.  Design Details  . . . . . . . . . . . . =
. . . . . . . . . . .   5

      
     4.1.  RLE =
Encoding  . . . . . . . . . . . . . . . . . . . . . .   5 =
     4.1.  RLE Encoding  . . . . . . . . . . . =
. . . . . . . . . . .   5

      
     4.2.  Packet =
Delivery Optimizations . . . . . . . . . . . . . .   6      4.2.  Packet Delivery Optimizations . . . . . . . . =
. . . . . .   6

      

      
     4.3.  =
Trading Off Replication Cost  . . . . . . . . . . . . . .   7      4.3.  =
Trading Off Replication Cost  . . . . . . . . . . . . . .   8

      
   5.  =
Directional Paths with Intersections  . . . . . . . . . . . .   8    5.  =
Directional Paths with Intersections  . . . . . . . . . . . .   9

      
   6.  =
Multicast Considerations  . . . . . . . . . . . . . . . . . .   9    6.  =
Multicast Considerations  . . . . . . . . . . . . . . . . . .  10

      
   7.  Multiple =
Address-Family Considerations  . . . . . . . . . . .  10    7.  =
Multiple Address-Family Considerations  . . . . . . . . . . .  11

      
   8.  Scaling =
Considerations  . . . . . . . . . . . . . . . . . . .  10    8.  =
Scaling Considerations  . . . . . . . . . . . . . . . . . . .  11

      
   9.  Security =
Considerations . . . . . . . . . . . . . . . . . . .  11    9.  =
Security Considerations . . . . . . . . . . . . . . . . . . .  12

      
   10. IANA =
Considerations . . . . . . . . . . . . . . . . . . . . .  11    10. =
IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12

      
   11. =
References  . . . . . . . . . . . . . . . . . . . . . . . . .  11    11. =
References  . . . . . . . . . . . . . . . . . . . . . . . . .  12

      
     11.1.  =
Normative References . . . . . . . . . . . . . . . . . .  11      11.1. =
 Normative References . . . . . . . . . . . . . . . . . .  12

      
     11.2.  =
Informative References . . . . . . . . . . . . . . . . .  12 =
     11.2.  Informative References . . . . . . =
. . . . . . . . . . .  12

      

      
   Appendix A.  =
Acknowledgments  . . . . . . . . . . . . . . . . . .  12    Appendix =
A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  13

      
   Appendix B.  =
Document Change Log  . . . . . . . . . . . . . . . .  13 =
   Appendix B.  Document Change Log  . . . . . =
. . . . . . . . . . .  13

      

      
     B.1.  =
Changes to draft-ietf-lisp-predictive-rlocs-00.txt  . . .  =
13      B.1.  Changes to draft-ietf-lisp-predictive-rlocs-01.txt  . . .  =
13

      
     B.2.  =
Changes to draft-farinacci-lisp-predictive-rlocs-02.txt .  =
13      B.2.  Changes to draft-ietf-lisp-predictive-rlocs-00.txt  . . .  =
13

      
     B.3.  =
Changes to draft-farinacci-lisp-predictive-rlocs-01.txt .  =
13      =
B.3.  Changes to draft-farinacci-lisp-predictive-rlocs-02.txt .  =
14

      
     B.4.  =
Changes to draft-farinacci-lisp-predictive-rlocs-00.txt .  13      B.4.  =
Changes to draft-farinacci-lisp-predictive-rlocs-01.txt .  =
14

      
   Authors' =
Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13      B.5.  Changes to =
draft-farinacci-lisp-predictive-rlocs-00.txt .  14

      
 =
   Authors' Addresses  . . . . . . . . . . . . =
. . . . . . . . . . .  14

      
 =


      
1.  =
Introduction 1.  Introduction

      
 =


      
   The LISP =
architecture [RFC6830] specifies two namespaces, End-Point =
   The LISP architecture [RFC6830] specifies =
two namespaces, End-Point

      
   IDs (EIDs) and =
Routing Locators (RLOCs).  An EID identifies a node in    IDs (EIDs) and Routing Locators (RLOCs).  An EID =
identifies a node in

      
   the network =
and the RLOC indicates the EID's topological location.    the network and the RLOC indicates the EID's =
topological location.

      
   When an node =
roams in the network, its EID remains fixed and    When an node roams in the network, its EID remains =
fixed and

      
   unchanged but =
the RLOCs associated with it change to reflect its new    unchanged but the RLOCs associated with it change to =
reflect its new

      
   topological =
attachment point.  This specification will focus EIDs and =
   topological attachment point.  This =
specification will focus EIDs and

      
   RLOCs residing =
in separate nodes.  An EID is assigned to a host node    RLOCs residing in separate nodes.  An EID is assigned =
to a host node

      
 =


      
skipping to =
change at =
page 4, line 25 =C2=B6 =
skipping to change at page 4, line 25 =C2=B6

      
 =


      
   For the send =
direction from roaming-EID to any destination can be    For the send direction from roaming-EID to any =
destination can be

      
   accomplish as =
a local decision.  As long as the roaming-EID is in    accomplish as a local decision.  As long as the =
roaming-EID is in

      
   signal range =
to any xTR along the path, it can use it to forward    signal range to any xTR along the path, it can use it =
to forward

      
   packets.  The =
LISP xTR, acting as an ITR, can forward packets to    packets.  The LISP xTR, acting as an ITR, can forward =
packets to

      
   destinations =
in non-LISP sites as well as to stationary and roaming    destinations in non-LISP sites as well as to =
stationary and roaming

      
   EIDs in LISP =
sites.  This is accomplished by using the LISP overlay    EIDs in LISP sites.  This is accomplished by using =
the LISP overlay

      
   via dynamic =
packet encapsulation.  When the roaming-EID sends    via dynamic packet encapsulation.  When the =
roaming-EID sends

      
   packets, the =
LISP xTR must discover the EID and MAY register the EID =
   packets, the LISP xTR must discover the EID =
and MAY register the EID

      
   with a set of =
RLOCs to the mapping system    with a =
set of RLOCs to the mapping system

      

      
   [I-D.portoles-lisp-eid-mobility].  The discovery =
process is important    [I-D.ietf-lisp-eid-mobility].  The discovery process =
is important

      
   because the =
LISP xTR, acting as an ETR for decapsulating packets that =
   because the LISP xTR, acting as an ETR for =
decapsulating packets that

      
   arrive, needs =
to know what local ports or radios to send packets to    arrive, needs to know what local ports or radios to =
send packets to

      
   the =
roaming-EID.    the =
roaming-EID.

      
 =


      
   Much of the =
focus of this design is on the packet direction to the    Much of the focus of this design is on the packet =
direction to the

      
   roaming-EID.  =
And how remote LISP ITRs find the current location    roaming-EID.  And how remote LISP ITRs find the =
current location

      
   (RLOCs) =
quickly when the roaming-EID is moving at high speed.  This =
   (RLOCs) quickly when the roaming-EID is =
moving at high speed.  This

      
   specification =
solves the fast roaming with the introduction of the    specification solves the fast roaming with the =
introduction of the

      
   =
Predictive-RLOCs algorithm.    =
Predictive-RLOCs algorithm.

      
 =


      
 =


      
skipping to =
change at =
page 5, line 17 =C2=B6 =
skipping to change at page 5, line 17 =C2=B6

      
 =


      
4.  Design =
Details 4.  Design Details

      
 =


      
   Predictive =
RLOCs accommodates for encapsulated packets to be    Predictive RLOCs accommodates for encapsulated =
packets to be

      
   delivered to =
Road-Side-Unit LISP xTRs regardless where the roaming-    delivered to Road-Side-Unit LISP xTRs regardless =
where the roaming-

      
   EID is =
currently positioned.    EID is =
currently positioned.

      
 =


      
   Referring to =
Figure 1, the following sequence is performed:    Referring to Figure 1, the following sequence is =
performed:

      
 =


      
   1.  The =
Predictive RLOCs are registered to the mapping system as a =
   1.  The Predictive RLOCs are registered to =
the mapping system as a

      

      
       LCAF =
encoded Replication List Entry (RLE) Type        LCAF encoded Replication List Entry (RLE) Type =
[RFC8060].  The

      
       [I-D.ietf-lisp-lcaf].  The registration can =
happen by one or more        =
registration can happen by one or more RSUs or by a third-party.

      
       RSUs or =
by a third-party.  When registered by an RSU, and when no =
       When registered by an RSU, and when no =
coordination is desired,

      
       =
coordination is desired, they each register their own RLOC with =
       they each register their own RLOC with =
merge-semantics so the

      
       =
merge-semantics so the list can be created and maintained in =
the        list can be created and =
maintained in the LISP Map-Server.  When

      
       LISP =
Map-Server.  When registered by a third-party, the complete =
       registered by a third-party, the =
complete list of RLOCs can be

      
       list of =
RLOCs can be included in the RLE.     =
   included in the RLE.

      
 =


      
   2.  There can =
be multiple RLEs present each as different RLOC-    2.  There can be multiple RLEs present each as =
different RLOC-

      
       records so =
a remote ITR can select one RLOC-record versus the        records so a remote ITR can select one =
RLOC-record versus the

      
       other =
based in priority and weight policy [RFC6830].        other based in priority and weight policy =
[RFC6830].

      
 =


      
   3.  When a =
remote ITR receives a packet destined for a roaming-EID, =
   3.  When a remote ITR receives a packet =
destined for a roaming-EID,

      
       it =
encapsulates and replicates to each RLOC in the RLE thereby =
       it encapsulates and replicates to each =
RLOC in the RLE thereby

      
       delivering =
the packet to the locations the roaming-EID is about        delivering the packet to the locations the =
roaming-EID is about

      
       to appear. =
 There are some cases where packets will go to        to appear.  There are some cases where packets =
will go to

      
       locations =
where the roaming-EID has already been, but see        locations where the roaming-EID has already been, =
but see

      
 =


      
skipping to =
change at =
page 5, line 45 =C2=B6 =
skipping to change at page 5, line 45 =C2=B6

      
 =


      
   4.  When the =
ETR resident RSU receives an encapsulated packet, it    4.  When the ETR resident RSU receives an =
encapsulated packet, it

      
       =
decapsulates the packet and then determines if the roaming-EID =
       decapsulates the packet and then =
determines if the roaming-EID

      
       had been =
previously discovered.  If the EID has not been        had been previously discovered.  If the EID has =
not been

      
       =
discovered, the ETR drops the packet.  Otherwise, the ETR =
       discovered, the ETR drops the packet.  =
Otherwise, the ETR

      
       delivers =
the decapsulated packet on the port interface the        delivers the decapsulated packet on the port =
interface the

      
       =
roaming-EID was discovered on.        =
roaming-EID was discovered on.

      
 =


      
4.1.  RLE =
Encoding 4.1.  RLE Encoding

      
 =


      

      
   The LCAF =
[I-D.ietf-lisp-lcaf] Replication List =
Entry (RLE) will be    The LCAF [RFC8060] Replication List Entry (RLE) will be =
used to

      
   used to =
encode the Predictive RLOCs in an RLOC-record for Map-    encode the Predictive RLOCs in an RLOC-record for =
Map-Registers, Map-

      
   Registers, Map-Reply, and Map-Notify messages =
[RFC6830].    Reply, and Map-Notify messages =
[RFC6830].

      
 =


      
     0            =
       1                   2                   3      0                   1                   2           =
        3

      
     0 1 2 3 4 5 =
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 =
6 7 8 9 0 1

      
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
    |           =
AFI =3D 16387         |     Rsvd1     |     Flags     | =
    |           AFI =3D 16387         |     =
Rsvd1     |     Flags     |

      
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
    |   Type =3D =
13   |    Rsvd2      |             4 + n             |     |   Type =3D 13   |    Rsvd2      |             4 + =
n             |

      
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
    |             =
 Rsvd3            |     Rsvd4     |  Level Value  |     |              Rsvd3            |     Rsvd4     |  =
Level Value  |

      
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
 =


      
skipping to =
change at =
page 6, line 39 =C2=B6 =
skipping to change at page 6, line 39 =C2=B6

      
   registrations =
come at different times and therefore arrive in    registrations come at different times and therefore =
arrive in

      
   different =
order than the physical RSU path, the level number creates =
   different order than the physical RSU path, =
the level number creates

      
   the necessary =
sequencing.  Each RSU needs to know its position in the =
   the necessary sequencing.  Each RSU needs to =
know its position in the

      
   path relative =
to other RSUs.  For example, in xTR-B, it would    path relative to other RSUs.  For example, in xTR-B, =
it would

      
   register with =
level 1 since it is after xTR-A (and before xTR-C).  So =
   register with level 1 since it is after =
xTR-A (and before xTR-C).  So

      
   if the =
registration order was xTR-B with level 1, xTR-C with level 2, =
   if the registration order was xTR-B with =
level 1, xTR-C with level 2,

      
   and xTR-A with =
level 0, the RLE list stored in the mapping system    and xTR-A with level 0, the RLE list stored in the =
mapping system

      
   would be =
(xTR-A, xTR-B, xTR-C).  It is recommended that level numbers =
   would be (xTR-A, xTR-B, xTR-C).  It is =
recommended that level numbers

      
   be assigned in =
increments of 10 so latter insertion is possible.    be assigned in increments of 10 so latter insertion =
is possible.

      
 =


      

      
   The use of =
Geo-Prefixes and Geo-Points can be used to compare the    The use of Geo-Prefixes and Geo-Points [I-D.farinacci-lisp-geo] can

      
   physical =
presence of each RSU with respect to each other, so they can =
   be used to compare the physical presence of =
each RSU with respect to

      
   choose level =
numbers to sequence themselves.  Also if the xTRs    each other, so they can choose level numbers to =
sequence themselves.

      
   register =
with a Geo-Point in an RLOC-record, then perhaps the Map-    Also =
if the xTRs register with a Geo-Point in an RLOC-record, then

      
   Server could sequence the RLE list. =
   perhaps the Map-Server could sequence the RLE list.

      
 =


      
4.2.  Packet =
Delivery Optimizations 4.2.  Packet =
Delivery Optimizations

      
 =


      
   Since the =
remote ITR will replicate to all RLOCs in the RLE, a    Since the remote ITR will replicate to all RLOCs in =
the RLE, a

      
   situation is =
created where packets go to RLOCs that don't need to.    situation is created where packets go to RLOCs that =
don't need to.

      
   For instance, =
if the roaming-EID is along side of xTR-B and the RLE    For instance, if the roaming-EID is along side of =
xTR-B and the RLE

      
   is (xTR-A, =
xTR-B, xTR-C), there is no reason to replicate to xTR-A =
   is (xTR-A, xTR-B, xTR-C), there is no reason =
to replicate to xTR-A

      
   since the =
roaming-EID has passed it and the the signal range is weak =
   since the roaming-EID has passed it and the =
the signal range is weak

      
   or lost.  =
However, replicating to xTR-B and xTR-C is important to =
   or lost.  However, replicating to xTR-B and =
xTR-C is important to

      
   deliver =
packets to where the roaming-EID resides and where it is =
   deliver packets to where the roaming-EID =
resides and where it is

      
 =


      
skipping to =
change at =
page 7, line 37 =C2=B6 =
skipping to change at page 7, line 37 =C2=B6

      
   header could =
be used to convey this information to the remote xTR.    header could be used to convey this information to =
the remote xTR.

      
   This would =
only occur when the roaming-EID was discovered by both    This would only occur when the roaming-EID was =
discovered by both

      
   xTR-A and =
xTR-B so it was possible for either xTR to reach the    xTR-A and xTR-B so it was possible for either xTR to =
reach the

      
   roaming-EID.  =
Either an IGP like routing protocol would be required    roaming-EID.  Either an IGP like routing protocol =
would be required

      
   to allow each =
xTR to know the other could reach the roaming-EID or a    to allow each xTR to know the other could reach the =
roaming-EID or a

      
   path trace =
tool (i.e. traceroute) could be originated by one xTR    path trace tool (i.e. traceroute) could be originated =
by one xTR

      
   targeted for =
the roaming-EID but MAC-forwarded through the other xTR. =
   targeted for the roaming-EID but =
MAC-forwarded through the other xTR.

      
   These and =
other roaming-EID reachability mechanisms are work in    These and other roaming-EID reachability mechanisms =
are work in

      
   progress and =
for further study.    progress and for =
further study.

      
 =


      

      
 =
   When a remote ITR is =
doing "Directional Mobility" and replicating to

      
 =
   the last RLOC in the =
RLE list, it has a decision to guess where the

      
 =
   roaming-EID will =
move to next.  Conservatively, an ITR can replicate

      
 =
   to the entire set of =
RLOCs in the RLE list and wait to see if the

      
 =
   roaming-EID moves to =
one of the RLOCs in the RLE list.

      
 =


      
 =
   Or more liberally, =
the remote ITR can assume the new roaming

      
 =
   direction.  For =
example, with an RLE list of (xTR-A, xTR-B, xTR-C,

      
 =
   xTR-D) and the =
roaming-EID is at D, the remote ITR can replicate to

      
 =
   all of A, B, C and D =
to determine where the roaming-EID will move to

      
 =
   next.  If the =
roaming-EID moves to C after it was at D, it is

      
 =
   possible that the =
EID is moving in the opposite direction from C to B

      
 =
   to A.  This would be =
known as "Back-n-Forth Mobility".  If an

      
 =
   implementation is =
configured to support this for a particluar EID,

      
 =
   the remote ITR could =
replicate in this sequence as the roaming-EID

      
 =
   moves from A to D =
and back to A: (A, B, C, D), (B, C, D), (C, D), (D,

      
 =
   C, B, A), (C, B, A), =
(B, A), and again (A, B, C, D).
 =


      
 =
   The roaming-EID =
could be doing "Circular Mobility" where it moves

      
 =
   from A to D =
directionally, next from D-to-A, and then back to A to D

      
 =
   directionally again. =
 This form of mobility is just as predicatable

      
 =
   as "Back-n-Forth =
Mobility" since a consistent pattern can be relied

      
 =
   on.  Both of these =
mobility forms can be achieved with near-zero

      
 =
   packet =
loss.

      
 =


      
 =
   On the other hand, =
the roaming-EID can be roaming arbitrarily using

      
 =
   "Random Mobility" =
where it could roam in the following combinations:

      
 =
   A-to-B, A-to-C, =
A-to-D, B-to-A, B-to-C, B-to-D, C-to-A, C-to-B, C-to-

      
 =
   D, D-to-A, D-to-B, =
or D-to-C.  In this situation, when a return

      
 =
   packet arrives at =
the ITR, it could then just replicate to where the

      
 =
   roaming-EID is at =
rest and do so for a short period of time before it

      
 =
   replciates to the =
entire RLE list again.  Using the wrong time period

      
 =
   could lead to packet =
loss.  All these types of mobility can be

      
 =
   supported by the =
remote ITR in a local manner without consulting or

      
 =
   depending on any =
other LISP system.  It is left for further study, if

      
 =
   any of the mobility =
types above should be encoded in the mapping

      
 =
   =
system.

      
 =
                                               =
                          

      
4.3.  Trading Off =
Replication Cost 4.3.  Trading Off =
Replication Cost

      
 =


      
   If RLE lists =
are large, packet replication can occur to locations    If RLE lists are large, packet replication can occur =
to locations

      
   well before =
the roaming-EID arrives.  Making RLE lists small is    well before the roaming-EID arrives.  Making RLE =
lists small is

      
   useful without =
sacrificing hand-off issues or incurring packet loss    useful without sacrificing hand-off issues or =
incurring packet loss

      
   to the =
application.  By having overlapping RLEs in separate RLOC- =
   to the application.  By having overlapping =
RLEs in separate RLOC-

      
   records we a =
simple mechanism to solve this problem.  Here is an    records we a simple mechanism to solve this problem.  =
Here is an

      
   example =
mapping entry to illustrate the point:  =
  example mapping entry to illustrate the point:

      
 =


      
   EID =3D =
<roaming-EID>, RLOC-records:    =
EID =3D <roaming-EID>, RLOC-records:

      
 =


      
skipping to =
change at =
page 11, line 40 =C2=B6 =
skipping to change at page 12, line =
15 =C2=B6

      
   specific EIDs =
which are on the train.  This can be used for    specific EIDs which are on the train.  This can be =
used for

      
   inventory, =
billing, or security purposes.    =
inventory, billing, or security purposes.

      
 =


      
   This =
optimization comes at a cost of a 2-stage lookup.  However, if =
   This optimization comes at a cost of a =
2-stage lookup.  However, if

      
   both sets of =
mapping entries are registered to the same Map-Server, a =
   both sets of mapping entries are registered =
to the same Map-Server, a

      
   combined =
RLOC-set could be returned.  This idea is for further study. =
   combined RLOC-set could be returned.  This =
idea is for further study.

      
 =


      
9.  Security =
Considerations 9.  Security =
Considerations

      
 =


      
   LISP has =
procedures for supporting both control-plane security    LISP has procedures for supporting both control-plane =
security

      

      
   =
[I-D.ietf-lisp-sec] and data-plane security [I-D.ietf-lisp-crypto].    [I-D.ietf-lisp-sec] and data-plane security [RFC8061].

      
 =


      
10.  IANA =
Considerations 10.  IANA =
Considerations

      
 =


      
   At this time =
there are no requests for IANA.    At =
this time there are no requests for IANA.

      
 =


      
11.  =
References 11.  References

      
 =


      
11.1.  Normative =
References 11.1.  Normative =
References

      
 =


      
   [RFC2119]  =
Bradner, S., "Key words for use in RFCs to Indicate    [RFC2119]  Bradner, S., "Key words for use in RFCs to =
Indicate

      
              =
Requirement Levels", BCP 14, RFC 2119,  =
             Requirement Levels", BCP 14, RFC 2119,

      
              DOI =
10.17487/RFC2119, March 1997,          =
     DOI 10.17487/RFC2119, March 1997,

      
              =
<http://www.rfc-editor.org/info/rfc2119>.               <https://www.rfc-editor.org/info/rfc2119>.

      
 =


      
   [RFC6830]  =
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The =
   [RFC6830]  Farinacci, D., Fuller, V., Meyer, =
D., and D. Lewis, "The

      
              =
Locator/ID Separation Protocol (LISP)", RFC 6830,               Locator/ID Separation Protocol (LISP)", =
RFC 6830,

      
              DOI =
10.17487/RFC6830, January 2013,        =
       DOI 10.17487/RFC6830, January 2013,

      

      
              =
<http://www.rfc-editor.org/info/rfc6830>.               <https://www.rfc-editor.org/info/rfc6830>.

      
 =


      
 =
   [RFC8060]  =
Farinacci, D., Meyer, D., and J. Snijders, "LISP =
Canonical

      
 =
              Address =
Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,

      
 =
              February =
2017, <https://www.rfc-editor.org/info/rfc8060>.

      
 =


      
 =
   [RFC8061]  =
Farinacci, D. and B. Weis, "Locator/ID Separation =
Protocol

      
 =
              (LISP) =
Data-Plane Confidentiality", RFC 8061,

      
 =
              DOI =
10.17487/RFC8061, February 2017,

      
 =
              =
<https://www.rfc-editor.org/info/rfc8061>.

      
 =


      
11.2.  =
Informative References 11.2.  =
Informative References

      
 =


      
   =
[I-D.farinacci-lisp-geo]    =
[I-D.farinacci-lisp-geo]

      
              =
Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft-               Farinacci, D., "LISP Geo-Coordinate =
Use-Cases", draft-

      

      
              =
farinacci-lisp-geo-03 (work in progress), =
April 2017.               =
farinacci-lisp-geo-04 (work in progress), =
October 2017.

      
 =


      

      
   [I-D.ietf-lisp-crypto]    [I-D.ietf-lisp-eid-anonymity]

      
              =
Farinacci, D. and B. =
Weis, "LISP Data-Plane =
              Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP

      
              Confidentiality", =
draft-ietf-lisp-crypto-10 (work in               EID Anonymity", =
draft-ietf-lisp-eid-anonymity-01 (work in

      
              =
progress), October 2016.               progress), October 2017.

      
 =


      

      
   [I-D.ietf-lisp-lcaf]    [I-D.ietf-lisp-eid-mobility]

      
              Farinacci, D., Meyer, D., and =
J. Snijders, "LISP Canonical               Portoles-Comeras, M., Ashtaputre, V., =
Moreno, V., Maino,

      
              Address Format (LCAF)", =
draft-ietf-lisp-lcaf-22 (work in               F., and =
D. Farinacci, "LISP L2/L3 EID Mobility Using a

      
              =
progress), November 2016. =
              Unified =
Control Plane", draft-ietf-lisp-eid-mobility-01

      
 =
              (work in progress), November =
2017.

      
 =


      
   =
[I-D.ietf-lisp-sec]    =
[I-D.ietf-lisp-sec]

      
              =
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.               Maino, F., Ermagan, V., Cabellos-Aparicio, =
A., and D.

      

      
              =
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12               Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14

      
              =
(work in progress), November =
2016.               (work in =
progress), October 2017.

      
 =


      
   =
[I-D.ietf-lisp-signal-free-multicast]  =
  [I-D.ietf-lisp-signal-free-multicast]

      
              =
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", =
              Moreno, V. and D. Farinacci, =
"Signal-Free LISP Multicast",

      

      
              =
draft-ietf-lisp-signal-free-multicast-04 =
(work in               draft-ietf-lisp-signal-free-multicast-06 (work =
in

      
              =
progress), May 2017.               progress), August 2017.

      
 

      
   [I-D.portoles-lisp-eid-mobility] =


      
              Portoles-Comeras, M., Ashtaputre, V., =
Moreno, V., Maino, 

      
              F., and D. Farinacci, "LISP L2/L3 EID =
Mobility Using a 

      
              Unified Control Plane", =
draft-portoles-lisp-eid- 

      
              mobility-02 (work in progress), =
April 2017. 

      
 =


      
Appendix A.  =
Acknowledgments Appendix A.  =
Acknowledgments

      
 =


      
   The author =
would like to thank the LISP WG for their review and    The author would like to thank the LISP WG for their =
review and

      
   acceptance of =
this draft.    acceptance of this =
draft.

      
 =


      
Appendix B.  =
Document Change Log Appendix B.  =
Document Change Log

      
 =


      
   [RFC Editor: =
Please delete this section on publication as RFC.]    [RFC Editor: Please delete this section on =
publication as RFC.]

      
 =


      

      
B.1.  Changes =
to draft-ietf-lisp-predictive-rlocs-00.txt B.1.  Changes to draft-ietf-lisp-predictive-rlocs-01.txt

      
 =


      
 =
   o  Posted November =
2017.

      
 =


      
 =
   o  Update document =
timer and references.

      
 =


      
 =
   o  Reflect comments =
from Prague meeting presentation.  There is no

      
 =
      need for "RLE =
Usage Types" as suggested.  The ITR can treat what

      
 =
      RLOCs it =
replicates to as a local matter via implementation

      
 =
      configuration.  =
RLE Directional is default.  Circular rotation,

      
 =
      back-n-forth, and =
random selection of RLOCs is up to the ITR.

      
 =


      
 =
B.2.  Changes to =
draft-ietf-lisp-predictive-rlocs-00.txt

      
 =


      
   o  Posted June =
2017.    o  Posted June 2017.

      
 =


      
   o  Make this =
specification a working group document.  It is a copy of =
   o  Make this specification a working group =
document.  It is a copy of

      
      =
draft-farinacci-lisp-predictive-rlocs-02.       draft-farinacci-lisp-predictive-rlocs-02.

      
 =


      

      
B.2.  Changes to =
draft-farinacci-lisp-predictive-rlocs-02.txt B.3.  Changes to =
draft-farinacci-lisp-predictive-rlocs-02.txt

      
 =


      
   o  Posted May =
2017 to update document timer.    o  =
Posted May 2017 to update document timer.

      
 =


      

      
B.3.  Changes to =
draft-farinacci-lisp-predictive-rlocs-01.txt B.4.  Changes to =
draft-farinacci-lisp-predictive-rlocs-01.txt

      
 =


      
   o  Posted =
November 2016 to update document timer. =
   o  Posted November 2016 to update document timer.

      
 =


      

      
B.4.  Changes to =
draft-farinacci-lisp-predictive-rlocs-00.txt B.5.  Changes to =
draft-farinacci-lisp-predictive-rlocs-00.txt

      
 =


      
   o  Initial =
post April 2016.    o  Initial post =
April 2016.

      
 =


      
Authors' =
Addresses Authors' Addresses

      
 =


      
   Dino =
Farinacci    Dino Farinacci

      
   =
lispers.net    lispers.net

      
   San Jose, =
CA    San Jose, CA

      
   USA =
   USA

      
 =



     
 

     
 End of changes. 25 change blocks. 

     
63 lines changed or =
deleted 118 lines changed or =
added

     

This =
html diff was produced by rfcdiff 1.46. The latest version is available =
from http://tools.ietf.org/to=
ols/rfcdiff/ 

   

  =20
  =20
=

--Apple-Mail=_92711963-EDE1-4AD2-8A2D-BC4468D0943A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii




Begin =
forwarded message:

From: =
internet-drafts@ietf.org
Subject: =
[lisp] I-D =
Action: draft-ietf-lisp-predictive-rlocs-01.txt
Date: =
November 30, 2017 at 5:29:39 PM =
PST
To: =
<i-d-announce@ietf.org>
Cc: lisp@ietf.org


A New =
Internet-Draft is available from the on-line Internet-Drafts =
directories.
This draft is a work item of the Locator/ID =
Separation Protocol WG of the IETF.

 =
       Title =
          : LISP =
Predictive RLOCs
 =
       Authors =
        : Dino Farinacci
 =
            &n=
bsp;           &nbs=
p;Padma Pillay-Esnault
	Filename =
       : =
draft-ietf-lisp-predictive-rlocs-01.txt
	Pages =
          : 14
	=
Date =
           : =
2017-11-30

Abstract:
 =
  This specification will describe a method to achieve =
near-zero packet
   loss when an EID is roaming =
quickly across RLOCs.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-predictive-rlo=
cs/

There are also htmlized versions =
available at:
https://tools.ietf.org/html/draft-ietf-lisp-predictive-rlocs-01=

https://datatracker.ietf.org/doc/html/draft-ietf-lisp-predictiv=
e-rlocs-01

A diff from the previous version =
is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-predictive-=
rlocs-01


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/

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

=

--Apple-Mail=_92711963-EDE1-4AD2-8A2D-BC4468D0943A--

--Apple-Mail=_90968E2F-417B-40AA-942B-EF3859B86846--