From nobody Mon Jun 1 06:49:40 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91261ACDEA for ; Mon, 1 Jun 2015 06:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz6eIxy-DUhz for ; Mon, 1 Jun 2015 06:49:36 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id B48FB1ACDE6 for ; Mon, 1 Jun 2015 06:49:35 -0700 (PDT) Received: from [192.168.21.200] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77756954; Mon, 01 Jun 2015 14:49:33 +0100 From: "Seil Jeon" To: "'Alper Yegin'" References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> In-Reply-To: Date: Mon, 1 Jun 2015 14:49:34 +0100 Message-ID: <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXyJVonWC/jWHjoPLHEPQMMWOBzAGkZzt5AU1BkT0C/VzGWQLvqnHwnL8JImA= Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 13:49:39 -0000 Hi Alper, See inline ">>>" -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Friday, May 29, 2015 9:42 PM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support Hello Seil, > >> >> #49: full on-demand mobility support >> >> The three proposed flags express a "type" of source IP address an > application wants to get to the IP stack. Particularly, the sustained > IP address is proposed to provide on-demand IP session continuity, > which activates IP mobility once the terminal moves across other access network. >> While the terminal stays at the same network where the session is > initiated, regular IP routing is applied. >> >> The on-demand draft does not assure provide the full on-demand >> mobility > for all scenarios by merely indicating the Socket API, > IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned > issue is as follows; >> >> 0. The MN is configured with one or more Nomadic IP addresses. >> >> 1. Once an app. requests "sustained IP address" to the IP stack, and >> it > will obtain a sustained IP address through a protocol procedure > between the terminal and network. >> >> 2. Other app. initiated over the same access network will use the >> same > sustained IP address while the terminal remains connected at the same > access network. >> >> 3. The terminal moves to another access network and a new app. >> requests a > sustained IP address with the Socket API to the IP stack. Since a > sustained IP address is already available in the IP stack, the > sustained IP address is assigned to the new app. >> > > Yes, that's what happens. > You are not pointing to an issue up until this point, right? Because, > you continuing your email with a "Besides" gives the impression that > you are pointing to an issue, but I don't see any issue captured in the above text. > >>> There is an issue. Maybe, we need to be synchronized how have you >>> thought > and defined the meaning of "on-demand mobility". As far as I know, > there are two meanings; one is that by imposing capability among IP > address reachability and IP session continuity, needed for an > application, into a source IP address, on-demand mobility could be > achieved; as the other meaning, it can be rephrased and detailed with > dynamic mobility, which should be applied in the use of sustained IP > address. A new application needs to have non-anchored sustained IP > address. This is our consistent claim. Non-optimal routing issue has > been raised in DMM Requirement document in RFC 7333, which should be critically considered in the solutions. > Sorry, I don't understand what you meant here. >>> You answer doesn't make us progress. Please specify where and what you have understood. >> Besides, in case sustained IP address allocation is used default, >> there > may be multiple sustained IP addresses including newly obtained > sustained IP address over the new access network in the IP stack. > However, when an app. is initiated, the IP stack may not select the > new one in the context of the default source IP address selection mechanism [RFC6724][RFC5014]. >> > > OK, is the issue following: When there are multiple sustained IP > addresses, how does the IP stack pick one among them? (*) > >>> As mentioned and specified in our draft > http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, > if there is no additional preference, we can leave selection to the > default source address selection mechanism. BUT if we have specific > preference among multiple sustained IP addresses and an initiated > application wants to have non-anchored sustained IP address over > currently attached access network, the proposed flag is essential. > I think you are meaning the same thing as I said above (*). Do you agree? >>> Yes. >> For providing the full on-demand mobility, a new flag is needed, >> letting > the IP stack request a new sustained IP address or choose a sustained > IP address not requiring IP mobility anchoring when an application is > initiated, among the existing ones in the IP stack. >> > > Your flag is not a solution to what I captured above. It does > something > else: Instruct the IP stack to go get a new sustained IP address > whether there is already one or more configured on the stack or not. > (**) > >>> Answered in the above. > There's a discrepancy between (*) and your solution (**). Are we talking about (*), (**), or something else? >>> There is no discrepancy between them. I said "a new flag", just an additional flag not intending to get a new sustained IP address all the time. And it should not request a new sustained IP address whether there is already one or more configured on the stack or not. It is given with the same expression in the ticket, though our draft is saying the meaning of a new sustained IP address, which will be revised in next update. The point is that when the IP stack receives a flag with sustained IP address flag, it will check it has a sustained IP address, and if it has one or more, one that does not activate IP mobility will be selected. If not, the MN will be triggered to get a new IP sustained address not activing IP mobility. Seil Jeon > Alper > > > >> -- >> -------------------------+------------------------------------------- >> -------------------------+--- >> -------------------------+--- >> Reporter: | Owner: draft-ietf-dmm-ondemand- >> seiljeon@av.it.pt | mobility@tools.ietf.org >> Type: defect | Status: new >> Priority: critical | Milestone: >> Component: ondemand- | Version: >> mobility | Keywords: on-demand mobility >> Severity: Submitted | >> WG Document | >> -------------------------+------------------------------------------- >> -------------------------+--- >> -------------------------+--- >> >> Ticket URL: >> dmm >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > From nobody Mon Jun 1 06:52:36 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F4E1ACDF3 for ; Mon, 1 Jun 2015 06:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He0DLzgA8UqR for ; Mon, 1 Jun 2015 06:52:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAF71ACDEE for ; Mon, 1 Jun 2015 06:52:29 -0700 (PDT) Received: from BN1AFFO11FD038.protection.gbl (10.58.52.30) by BN1AFFO11HUB027.protection.gbl (10.58.52.137) with Microsoft SMTP Server (TLS) id 15.1.184.11; Mon, 1 Jun 2015 13:52:12 +0000 Authentication-Results: spf=temperror (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of sprint.com: DNS Timeout) Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BN1AFFO11FD038.mail.protection.outlook.com (10.58.52.242) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Mon, 1 Jun 2015 13:52:09 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t51DdRTQ047474; Mon, 1 Jun 2015 08:52:09 -0500 Received: from plswe13m01.ad.sprint.com (plswe13m01.corp.sprint.com [144.229.214.20]) by plsapdm1.corp.sprint.com with ESMTP id 1uqaua805d-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 01 Jun 2015 08:52:09 -0500 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 1 Jun 2015 08:52:08 -0500 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.1044.021; Mon, 1 Jun 2015 08:52:08 -0500 From: "Laporte, Laurent [CTO]" To: Marco Liebsch , "dmm@ietf.org" Thread-Topic: FPC carrier ID and network ID question Thread-Index: AdCZY8eSHKVtCkFuS16oqfq1KLDiYgAsFxugAJdD32A= Date: Mon, 1 Jun 2015 13:52:08 +0000 Message-ID: <2e0fe08253da402d8f8ab8229a476ebf@PLSWE13M01.ad.sprint.com> References: <69756203DDDDE64E987BC4F70B71A26D99AD9C54@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D99AD9C54@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.26] Content-Type: multipart/alternative; boundary="_000_2e0fe08253da402d8f8ab8229a476ebfPLSWE13M01adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD038; 1:fQuAQLr6FLT6BZ+dyUs35qfrQHEuXKzDfEFJrGwTIk/poo9p4nbeQ29DZ9vEHnQKR0j20hiZGr1UHabl19/XmQ28iPXOZa5Ku8inoPjsDBJOYO20pUMl6+ReHYctK7YT/SnwKHuDSjIKtJBdNZ04jXZNUOnRiVk+qjpD+NmvTUYneV8DfTkYwMuNNz3VJjTyON5qNpo2366Phn7grsoNDdQ26bcuqYYmNO4ltSKi+g3EbCZrexWoBQO7eSUldpqCX7FCtr7H2FCj1HqMbdUQ5XP0VuMX6bBTwRff2O2z7vrhS6KnNSj+qKUNZB+WUGVT X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(52604005)(189002)(164054003)(199003)(377454003)(92566002)(5001770100001)(24736003)(85326001)(189998001)(5001960100002)(107886002)(86362001)(5001860100001)(2501003)(68736005)(33646002)(5001830100001)(77156002)(4001540100001)(19300405004)(2900100001)(6806004)(76176999)(4546004)(62966003)(81156007)(97736004)(50986999)(512954002)(64706001)(2950100001)(30436002)(102836002)(15975445007)(5250100002)(46102003)(106466001)(84326002)(19580395003)(19580405001)(108616004)(54356999)(16236675004)(87936001)(19625215002)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB027; H:plsapdm1.corp.sprint.com; FPR:; SPF:TempError; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB027; 2:D0AI4qotl/1gFT4dFmgSyUcKlwN1xpSPf+JSEdkceia6CCbFWeIthH/isE98Ep/+; 2:U7BiHDQxwdl3f+Yc5z7ys75Q6Zn0YCCgCHUBfLTce6mtBI/GHePALoy5VhvhbDfAp/K+JvvtTHWf8gHPokks8B7GMnDC/fFsVqMqAbaWElUTbd/l8giSGKuu032VvnEd14X8XylbTCIk3Iu9fnemqoitn2lQ3qJv+7C9FxqxWKIxzTHEQDRZqGDa76WawtCvi+5eOQf5a2zdbirLHXVnCLLbXSEApWwjP56luAGf7NUOis/sGe7ZbRrFmfzoTybO; 6:wCkXsfuTYl9hpwdI33zUK8Os4SUHAyOJ82z8hMD1POF4gCPYXpkC0eU5USD3DrxQE6l1MexS7TjcdwoCJ7tvepQ/mRAbkWQOXGiyDor99UqJ6JddPWEhRbXcF3AdNb9hJeWhDWgEkkYvTMLDuHIbXUH8NYUQQxkKCkb2yDe+V4y4oX2xDBv60RkscqAC9A/Hl7H50ZpfZFxMGziBlI3xVLL/4Vrde4ET2+8nyKB5dhpiUlb5FvkuajdtidZdNmTV; 3:ZFRuVee26OHpjUnThGGL8uFv8a7CrHg7ZHhOgS/rYyCQAKDGYHXP1WZOGCVUIt5KnF9ZaFjGO+kNdXQo6STBr6yoCxoC0vGERxmjxWEGDMtUxf6EPAbcD3j1UBSqqzf8av1/TL3ununeblUQDEJwuMn3DzBM4D+RVBhe0AADJejWcjoJ17ajUFwRyslwzM2XhK3UUgwNMgqeaKrR8YeRtSTVwHZRupf3IXB/9eonHWPHZtiwRkNvetlSRLEDRsLUSmwV1snpn/cfUV+MSKaIZ184iiUaGfEQuY0EhrUUon1+JCLHf3c4lK3FUD94Mig/ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB027; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1AFFO11HUB027; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB027; X-Forefront-PRVS: 05947791E4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB027; 9:NUM4h96eSVuHTgOyLFGpTTRUEGF9v1fB0L31Et9A?= =?us-ascii?Q?bMfRP50Xp8e1OaW0kuELT9nKBeWuXCxo5Hse8ZLL1JIO9BPX1dj6v8+3YWle?= =?us-ascii?Q?n+kLSjASdw5iza8VGUXM3t7feb8eN/Gb2ZfuFpBbn/I+zak1nMwHcsMdQh1e?= =?us-ascii?Q?PSgVy7tKFug5Mvjgj4YzelB8Ps296ADN+1WiMz9KbB+fAqszRMxgQTlZjgcL?= =?us-ascii?Q?EehGEeTOXpDpNJiPoQsYWtAr3n27eqFSmCyFFLgZmyRESlx/g8iqFM1B9LBW?= =?us-ascii?Q?WzyKH3aHa2jFM9oX36eequxiGyt6a7PlA5qW/gd8cvUBR9nd9zpHO2eiKAGa?= =?us-ascii?Q?dcfgUs6KDsVDebjrX2DKiXwTQl331RXKqKh/dHUqctSislBfvl6gAKFFNqTO?= =?us-ascii?Q?fnVAbE3ns8icpxw5Iq9FT5h2/hHkMMjOFapBHXYGv7Rwt+a6UW306b8ZTq7w?= =?us-ascii?Q?aARFdebTQfMcCslmIWCh8J8FTAaYq3UsUKw0VddzZfvwiaGzBijOm8hrmuS/?= =?us-ascii?Q?+xv4TR9xI7uBCbUw0A4yPmuUU5jHtFjhSRpldrJDoFtnAWjXnQ5JAbps6fzZ?= =?us-ascii?Q?FEz8nkdgI1C5Xlo0mK4VNZfjDuRAFdEFHqiXVMUvXu0o45+lEMO2LSdNwxc7?= =?us-ascii?Q?4y+i9Bd5SFMtwiW9s1yyFHL1r+90mY/TX2IqNEX/ujkcpFLaxWdCLsNXHT+T?= =?us-ascii?Q?GBnEAy87y2G7qNCg/CB62lyFo5Gb63yUCpVBCkcd+oFOJRWbrw1WyiApGLX8?= =?us-ascii?Q?6f4V+uaTVdZ7tFd3N+tmsYarphU6rQWQn3QNvw7uUcfEtejVfO6tM7oWRLZ6?= =?us-ascii?Q?MGJu8v7Mu1tbEF6ngrztoEklqdYZH8LMbBIC9lVG84kMBdaC+RbKVw3FJZ3i?= =?us-ascii?Q?g71g3nSKfsF9t/vrNOxzJKUZqIiUhEnPS7LBEOC2TzLKSDq0D3bHZM1zmRmb?= =?us-ascii?Q?QvvAd6QBAVuIVoBd53D7faFw3UyKzvlHuSnmRwqcy1ettYMI0oY8eDIqPy8B?= =?us-ascii?Q?iFf3Dv5Z5b3ZsY1rheaPGpZ5ieFjmgKz6rPpja9GG8n/Lq++8HjMtz1fhoM6?= =?us-ascii?Q?kNn+Oc3qHPR4GaqnyxGCMDMD6w+9t2w1/ERFXB5SEUvMXeQJsBQJJ5aAr767?= =?us-ascii?Q?ISWL0d1yfQBeVZM3kdsThMwhqYL+4Hvu+b7k+cATtROEi+Jxba+WtOXPiOQw?= =?us-ascii?Q?/hf31Cv9OOB/RlNnzBfzgtjg1GdtSeyKpi2Gt2HT7YZibhn3VViHxBdEnLj0?= =?us-ascii?Q?M+/buvuwi1KWEiC1EQg=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB027; 3:/UqpAaZb/TH6ZKSqcRq5ju5I0ctAl7QD9WVKK1eOa8h7ruv7VVSCH2Y2mFTdu5LwUkuzswa5H7Kk4AOgQQ1lA/c3tpqWeFlaUvaRusNgcJPBZc3pfjDwPu9VDBaYAl6PewLa/7qK4+LzZuNbTC51jg==; 10:Osf+huvDpYtbgHeBFi6fRKLRONNIkGoYghOWoDG5qO4FNz+TTfO7obn+DixYYUTiwCe9loNqy0BcB9sr7V2i2rF5opK2ioMW0UnOnfvt918= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2015 13:52:09.5633 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB027 Archived-At: Subject: Re: [DMM] FPC carrier ID and network ID question X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 13:52:35 -0000 --_000_2e0fe08253da402d8f8ab8229a476ebfPLSWE13M01adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marco, Thanks for explaining your rationale, this helps clarify my thinking. As y= ou noticed, my bias was leading me to a certain interpretation of the meani= ng of the proposed fields. I suspect that there will be use cases of inter= est where, as you mentioned in your next to last paragraph, clients of carr= ier 1 need to connect to an agent of carrier 2. In any event, I am intere= sted in continued discussion on this topic. Best regards, Larry From: Marco Liebsch [mailto:Marco.Liebsch@neclab.eu] Sent: Friday, May 29, 2015 8:34 AM To: Laporte, Laurent [CTO]; dmm@ietf.org Subject: RE: FPC carrier ID and network ID question Hi Larry, thanks for your feedback and valid doubts, as you pointed out an important = point to discuss. First of all, the space for a certain field in the ID can be increased. We = may have a preceding discussion about how the identifier format should look like; as proposed in= this version of the draft or differently. The rationale behind the Client-ID, Agent-ID and DPN-ID to allow unambiguou= s identification of a function instance associated with FPC and its location. 'Location' mea= ns to identify the network, e.g. a certain datacenter, where a function is instantiated and op= erational. Example: An IP switch, which can serve as Data Plane Node for mobility mana= gement, is located in a local POP/datacenter. The datacenter can be identified in the = Network ID field of the complete identifier and should be unique within the carrier's network t= opology. In the example you brought, the Network Code (MNC) identifies rather the carrier instead o= f a certain spot of a single carrier's network topology. In terms of FPC deployment, we may omit the Carrier-ID field in identifiers= in case we do not expose and use these identifiers outside of a single carrier. But= it may be useful to identify the carrier as well in case, for example, a Client of ca= rrier 1 connects to an Agent of Carrier 2. In case we need to keep a Carrier-ID field, it may comprise t= he complete tuple of MCC/MNC as you refer to. I hope that clarifies your question and we can follow up on that thread to = find a suitable format for the complete identifier. Thanks, Marco From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Laporte, Laurent [CTO] Sent: Donnerstag, 28. Mai 2015 18:33 To: dmm@ietf.org Subject: [DMM] FPC carrier ID and network ID question Hello, I have a question regarding the Carrier ID and Network ID elements proposed= in the DMM FPC protocol. I am trying to a) understand the meaning intend= ed for Carrier and Network; and, b) reconcile these names with what is fami= liar to me as someone who works for a mobile service provider. The problem= that I'm basically running into is that there are only 8 bits assigned eac= h for Carrier ID and Network ID. I am accustomed to utilizing a PLMN, whic= h is composed of an MCC and MNC, each having allowed values up to 999. Wit= h only eight bits, there are fewer values than required for either MCC or M= NC. Eight bits for Carrier ID and Network ID seems to be quite constrained= to me. I suspect that something else is meant, but I cannot readily surmise what i= t might be. Thanks, Larry Laporte ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_2e0fe08253da402d8f8ab8229a476ebfPLSWE13M01adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Marco,

 

Thanks for explaining = your rationale, this helps clarify my thinking.  As you noticed, my bi= as was leading me to a certain interpretation of the meaning of the propose= d fields.  I suspect that there will be use cases of interest where, as you mentioned in your next to last paragraph, = clients of carrier 1 need to connect to an agent of carrier 2.   = In any event, I am interested in continued discussion on this topic.

 

Best regards,

 

Larry

 

From: Marco Li= ebsch [mailto:Marco.Liebsch@neclab.eu]
Sent: Friday, May 29, 2015 8:34 AM
To: Laporte, Laurent [CTO]; dmm@ietf.org
Subject: RE: FPC carrier ID and network ID question

 

Hi Larry,

thanks for your feedback and valid doubts, as you pointed out an important = point to discuss.

First of all, the spac= e for a certain field in the ID can be increased. We may have a preceding discussion about how the identifier format should look like; as proposed in= this version of
the draft or differently.

 

The rationale behind t= he Client-ID, Agent-ID and DPN-ID to allow unambiguous identification
of a function instance associated with FPC and its location. ‘Locatio= n’ means to identify the
network, e.g. a certain datacenter, where a function is instantiated and op= erational.

 

Example: An IP switch,= which can serve as Data Plane Node for mobility management, is
located in a local POP/datacenter. The datacenter can be identified in the = Network ID field of
the complete identifier and should be unique within the carrier’s net= work topology. In the example
you brought, the Network Code (MNC) identifies rather the carrier instead o= f a certain
spot of a single carrier’s network topology.

 

In terms of FPC deploy= ment, we may omit the Carrier-ID field in identifiers in case
we do not expose and use these identifiers outside of a single carrier. But= it may be
useful to identify the carrier as well in case, for example, a Client of ca= rrier 1 connects to an Agent
of Carrier 2. In case we need to keep a Carrier-ID field, it may comprise t= he complete
tuple of MCC/MNC as you refer to.

 

I hope that clarifies = your question and we can follow up on that thread to find a suitable
format for the complete identifier.

 

Thanks,

Marco

 

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Laporte, Laurent [CTO]
Sent: Donnerstag, 28. Mai 2015 18:33
To: dmm@ietf.org
Subject: [DMM] FPC carrier ID and network ID question

 

Hello,

 

I have a question regarding the Carrier ID and Netwo= rk ID elements proposed in the DMM FPC protocol.  I am trying to  = ;a) understand the meaning intended for Carrier and Network; and, b) reconc= ile these names with what is familiar to me as someone who works for a mobile service provider.  The problem that= I’m basically running into is that there are only 8 bits assigned ea= ch for Carrier ID and Network ID.  I am accustomed to utilizing a PLMN= , which is composed of an MCC and MNC, each having allowed values up to 999.  With only eight bits, there are fewer valu= es than required for either MCC or MNC.  Eight bits for Carrier ID and= Network ID seems to be quite constrained to me.

 

I suspect that something else is meant, but I cannot= readily surmise what it might be. 

 

Thanks,

 

Larry Laporte

 

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_2e0fe08253da402d8f8ab8229a476ebfPLSWE13M01adsprintcom_-- From nobody Mon Jun 1 09:57:30 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E321B2F1B for ; Mon, 1 Jun 2015 09:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QE4MTi7tB1yb for ; Mon, 1 Jun 2015 09:57:28 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 F3DB31B2F0E for ; Mon, 1 Jun 2015 09:57:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t51GvQ1I021187; Mon, 1 Jun 2015 09:57:26 -0700 Received: from XCH-BLV-402.nw.nos.boeing.com (xch-blv-402.nw.nos.boeing.com [130.247.25.31]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t51GvGbU021138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 1 Jun 2015 09:57:17 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-BLV-402.nw.nos.boeing.com ([169.254.2.201]) with mapi id 14.03.0235.001; Mon, 1 Jun 2015 09:57:15 -0700 From: "Templin, Fred L" To: dmm Thread-Topic: Forwarding/Control Plane separation in AERO Thread-Index: AdCciL+9KgXl56HGQjKHIItP6f1G9Q== Date: Mon, 1 Jun 2015 16:57:14 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E7C88D@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [DMM] Forwarding/Control Plane separation in AERO X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:57:30 -0000 Hi, Much has been said about managing forwarding and control plane separation in DMM. AERO now has a new method for doing this based on DHCPv6. In AERO, the control plane is managed by the AERO Server. AERO Clients use DHCPv6 PD messaging in order to register themselves with AERO Servers and to update their access network addresses based on mobility events. The AERO Server in turn maintains PD state for each AERO Client and also provid= es default forwarding services for each Client. However, it would be desirable for Servers to offload forwarding services to Forwarding Agents that can handle high-speed data plane operations and therefore offload the Server. In order to support this offload, when the AERO Server prepares a Reply to a Client's DHCPv6 Request/Renew/Rebind/Release message, it forwards the Reply to the Forwarding Agent instead of directly to the Client. The Forwarding Agent then creates forwarding state and returns the Reply to the Server, which then forwards the Reply to the Client. Now, the Server and Forwarding Agent both have the necessary state synchronization, or if any control messages are lost the Client will retransmit. Future data packets can then flow through the Forwarding Agent without burdening the Server. This behavior now documented in Section 3.16 of the AERO spec: https://datatracker.ietf.org/doc/draft-templin-aerolink/ With this behavior, the AERO Server and Forwarding Agent act as two halves of a whole router, with the Server handling the control plane and the Forwarding Agent handling the data plane. Each Server can further associate with multiple Forwarding Agents if there is a desire to distribute the data plane function to multiple agents. This is a simple and effective solution for DMM forwarding and control plane separation. I would be happy to talk more about this either on the list or at the upcoming IETF. Comments? Thanks - Fred fred.l.templin@boeing.com From nobody Mon Jun 1 12:50:22 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED251B32E8 for ; Mon, 1 Jun 2015 12:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ND0f4uMczmN for ; Mon, 1 Jun 2015 12:50:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A075C1B3367 for ; Mon, 1 Jun 2015 12:50:13 -0700 (PDT) Received: from [192.168.2.5] ([85.97.51.111]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0LlGWu-1ZY0zl0xVO-00b1SF; Mon, 01 Jun 2015 21:50:12 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> Date: Mon, 1 Jun 2015 22:49:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> To: "Seil Jeon" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:skjEsbuanPMaiwBkBbn70Sb8l5H0wujW/JVCCHtjMDjVkYrP0RU cg83xrWq+lwG8MjVD5IMMy6nV8HjPHv7fllZw0jBgCUVl9C/MPAQltHehfaY8CN2Zffh3IJ XDnlLdNYYX3kilAXjnP6YuRdduewVt8Wtx9RBm+jjq8mCsw6rM/QaVx0UQgB66gUGhampsB H/YeJQ953mzI2oaCgGX8A== X-UI-Out-Filterresults: notjunk:1;V01:K0:Km3PsjX3Qkw=:sF4t9snFO55y8jEjjAt9Fh aLtw3b4hT0M4N/u2484/X6tmFAKtwooY4GagpMTBk0ALzpyYRbYWgQwtiufpifONSJTXl/yrv 4E5sJAQVSzsa1zryt/NMmriBDkaDs9Ztra1uPem1l6HuVk2pkt1XfJV1Od43mh4wEXySfgWmU zoO0o8Ha9I/3nJ6mIb5WpEYIcIR538CUDEEo7rbncw0g6Y0uyLDiPqElFFuErtT0jxfcyC+cb 9q90c+DDRcizufmMMrJVvgoSk7OCtLr1FdOb6pZJ9ad6cQ83Wn0i67YIohPzGGkMLoUCSaBtP M+LBrzVFvg0XkbE5jGcUqIHAqKNuaD5kD73hSJsUrIVsleCh1XezsohWn3hsSWqU1mTmPzr+O gnwKuWPQXYNp1nGJJLHcaNsKcBYYzPdzB6m1txZiGhpWdi15deLgM9hNegCkRAT1Ghb80cpvt 4It89lzLJb3JbzR0vn5pHDMcO8+adJYfyPb4E4+xAJY+FEIv1vUKLZCOFOFrP1RR4sHKN/waw Y7CdAq66Pi4YI+4MPQxwuOEJZ3eD+nfLpmSzPGwb42LPbY+ZTcWmiNfqa5hOEme0XJB25Kitf QNAwLbldCjq3D4FMFbygv9NLWJ0KJk81bHa7g9hNY0bew+XfI/MpbmoVIwCqu0JglwyVWJm/B ptHSusSGxfTP4jyFjJT/IDg2V4Cfd8cWNfsny0n4/NHIKkQ== Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 19:50:21 -0000 > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it = has one > or more, one that does not activate IP mobility will be selected. If = not, > the MN will be triggered to get a new IP sustained address not = activing IP > mobility. So, the idea is, when this flag is set along with a Sustained IP address = request from the app: - if the host stack is already configured with a Sustained IP address = allocated from the serving network, then it gets selected (irrespective = of the presence or absence of any other Sustained IP address). - if the host stack is not already configured with a Sustained IP = address allocated from the serving network (irrespective of the presence = or absence of any Sustained IP address from any other network), then the = host makes an attempt to configure one with the serving network.=20 -- if the configuration succeeds, then the newly configured IP address = is selected. -- if the configuration fails. then the call fails (?? or some other = behavior -- you can define here). Alper >>> #49: full on-demand mobility support >>>=20 >>> The three proposed flags express a "type" of source IP address an >> application wants to get to the IP stack. Particularly, the sustained=20= >> IP address is proposed to provide on-demand IP session continuity,=20 >> which activates IP mobility once the terminal moves across other = access > network. >>> While the terminal stays at the same network where the session is >> initiated, regular IP routing is applied. >>>=20 >>> The on-demand draft does not assure provide the full on-demand=20 >>> mobility >> for all scenarios by merely indicating the Socket API,=20 >> IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned = =20 >> issue is as follows; >>>=20 >>> 0. The MN is configured with one or more Nomadic IP addresses. >>>=20 >>> 1. Once an app. requests "sustained IP address" to the IP stack, and=20= >>> it >> will obtain a sustained IP address through a protocol procedure=20 >> between the terminal and network. >>>=20 >>> 2. Other app. initiated over the same access network will use the=20 >>> same >> sustained IP address while the terminal remains connected at the same=20= >> access network. >>>=20 >>> 3. The terminal moves to another access network and a new app.=20 >>> requests a >> sustained IP address with the Socket API to the IP stack. Since a =20 >> sustained IP address is already available in the IP stack, the=20 >> sustained IP address is assigned to the new app. >>>=20 >>=20 >> Yes, that's what happens. >> You are not pointing to an issue up until this point, right? Because,=20= >> you continuing your email with a "Besides" gives the impression that=20= >> you are pointing to an issue, but I don't see any issue captured in = the > above text. >>=20 >>>> There is an issue. Maybe, we need to be synchronized how have you=20= >>>> thought >> and defined the meaning of "on-demand mobility". As far as I know,=20 >> there are two meanings; one is that by imposing capability among IP=20= >> address reachability and IP session continuity, needed for an=20 >> application, into a source IP address, on-demand mobility could be=20 >> achieved; as the other meaning, it can be rephrased and detailed with=20= >> dynamic mobility, which should be applied in the use of sustained IP=20= >> address. A new application needs to have non-anchored sustained IP=20 >> address. This is our consistent claim. Non-optimal routing issue has=20= >> been raised in DMM Requirement document in RFC 7333, which should be > critically considered in the solutions. >>=20 >=20 > Sorry, I don't understand what you meant here. >=20 >>>> You answer doesn't make us progress. Please specify where and what = you > have understood. >=20 >=20 >>> Besides, in case sustained IP address allocation is used default,=20 >>> there >> may be multiple sustained IP addresses including newly obtained=20 >> sustained IP address over the new access network in the IP stack.=20 >> However, when an app. is initiated, the IP stack may not select the=20= >> new one in the context of the default source IP address selection > mechanism [RFC6724][RFC5014]. >>>=20 >>=20 >> OK, is the issue following: When there are multiple sustained IP=20 >> addresses, how does the IP stack pick one among them? (*) >>=20 >>>> As mentioned and specified in our draft >> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00,=20= >> if there is no additional preference, we can leave selection to the=20= >> default source address selection mechanism. BUT if we have specific=20= >> preference among multiple sustained IP addresses and an initiated=20 >> application wants to have non-anchored sustained IP address over=20 >> currently attached access network, the proposed flag is essential. >>=20 >=20 > I think you are meaning the same thing as I said above (*). > Do you agree? >=20 >>>> Yes. >=20 >>> For providing the full on-demand mobility, a new flag is needed,=20 >>> letting >> the IP stack request a new sustained IP address or choose a sustained=20= >> IP address not requiring IP mobility anchoring when an application is=20= >> initiated, among the existing ones in the IP stack. >>>=20 >>=20 >> Your flag is not a solution to what I captured above. It does=20 >> something >> else: Instruct the IP stack to go get a new sustained IP address=20 >> whether there is already one or more configured on the stack or not.=20= >> (**) >>=20 >>>> Answered in the above.=20 >>=20 >=20 > There's a discrepancy between (*) and your solution (**). >=20 > Are we talking about (*), (**), or something else? >=20 >>>> There is no discrepancy between them. I said "a new flag", just an > additional flag not intending to get a new sustained IP address all = the > time. And it should not request a new sustained IP address whether = there is > already one or more configured on the stack or not. It is given with = the > same expression in the ticket, though our draft is saying the meaning = of a > new sustained IP address, which will be revised in next update. >=20 > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it = has one > or more, one that does not activate IP mobility will be selected. If = not, > the MN will be triggered to get a new IP sustained address not = activing IP > mobility. >=20 >=20 > Seil Jeon >=20 >=20 >=20 >=20 >> Alper >>=20 >>=20 >>=20 >>> -- >>> = -------------------------+------------------------------------------- >>> -------------------------+--- >>> -------------------------+--- >>> Reporter: | Owner: draft-ietf-dmm-ondemand- >>> seiljeon@av.it.pt | mobility@tools.ietf.org >>> Type: defect | Status: new >>> Priority: critical | Milestone: >>> Component: ondemand- | Version: >>> mobility | Keywords: on-demand mobility >>> Severity: Submitted | >>> WG Document | >>> = -------------------------+------------------------------------------- >>> -------------------------+--- >>> -------------------------+--- >>>=20 >>> Ticket URL: >>> dmm >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >>=20 >=20 >=20 From nobody Mon Jun 1 16:12:03 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF6E1A1B12 for ; Mon, 1 Jun 2015 16:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lBYYbcZ-1Oc for ; Mon, 1 Jun 2015 16:11:55 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id D0A351A1A6D for ; Mon, 1 Jun 2015 16:11:54 -0700 (PDT) Received: from [2.81.141.118] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77759714; Tue, 02 Jun 2015 00:11:53 +0100 From: "Seil Jeon" To: "'Alper Yegin'" References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> In-Reply-To: <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> Date: Tue, 2 Jun 2015 00:11:54 +0100 Message-ID: <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01D09CC8.BC2862E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXyJVonWC/jWHjoPLHEPQMMWOBzAGkZzt5AU1BkT0C/VzGWQLvqnHwAhDpQpMCH8V98JyhYZUw Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 23:12:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01D09CC8.BC2862E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alper, Regards, Seil -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Monday, June 01, 2015 8:50 PM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. So, the idea is, when this flag is set along with a Sustained IP address request from the app: - if the host stack is already configured with a Sustained IP address allocated from the serving network, then it gets selected (irrespective of the presence or absence of any other Sustained IP address). >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network. - if the host stack is not already configured with a Sustained IP address allocated from the serving network (irrespective of the presence or absence of any Sustained IP address from any other network), then the host makes an attempt to configure one with the serving network. >> Yes. -- if the configuration succeeds, then the newly configured IP address is selected. >> Yes. -- if the configuration fails. then the call fails (?? or some other behavior -- you can define here). >> You mean the configuration fails when there is no sustained IP address, right? In my opinion, this issue belongs to address configuration mechanism based on definition of the three DMM APIs. Those jobs are/will be asked on each configuration mechanism, according to discussion of the previous teleconference in the WT you're leading. At that time, if I see any something related to our proposal, we will raise our voice. Alper >>> #49: full on-demand mobility support >>> >>> The three proposed flags express a "type" of source IP address an >> application wants to get to the IP stack. Particularly, the sustained >> IP address is proposed to provide on-demand IP session continuity, >> which activates IP mobility once the terminal moves across other >> access > network. >>> While the terminal stays at the same network where the session is >> initiated, regular IP routing is applied. >>> >>> The on-demand draft does not assure provide the full on-demand >>> mobility >> for all scenarios by merely indicating the Socket API, >> IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned >> issue is as follows; >>> >>> 0. The MN is configured with one or more Nomadic IP addresses. >>> >>> 1. Once an app. requests "sustained IP address" to the IP stack, and >>> it >> will obtain a sustained IP address through a protocol procedure >> between the terminal and network. >>> >>> 2. Other app. initiated over the same access network will use the >>> same >> sustained IP address while the terminal remains connected at the same >> access network. >>> >>> 3. The terminal moves to another access network and a new app. >>> requests a >> sustained IP address with the Socket API to the IP stack. Since a >> sustained IP address is already available in the IP stack, the >> sustained IP address is assigned to the new app. >>> >> >> Yes, that's what happens. >> You are not pointing to an issue up until this point, right? Because, >> you continuing your email with a "Besides" gives the impression that >> you are pointing to an issue, but I don't see any issue captured in >> the > above text. >> >>>> There is an issue. Maybe, we need to be synchronized how have you >>>> thought >> and defined the meaning of "on-demand mobility". As far as I know, >> there are two meanings; one is that by imposing capability among IP >> address reachability and IP session continuity, needed for an >> application, into a source IP address, on-demand mobility could be >> achieved; as the other meaning, it can be rephrased and detailed with >> dynamic mobility, which should be applied in the use of sustained IP >> address. A new application needs to have non-anchored sustained IP >> address. This is our consistent claim. Non-optimal routing issue has >> been raised in DMM Requirement document in RFC 7333, which should be > critically considered in the solutions. >> > > Sorry, I don't understand what you meant here. > >>>> You answer doesn't make us progress. Please specify where and what >>>> you > have understood. > > >>> Besides, in case sustained IP address allocation is used default, >>> there >> may be multiple sustained IP addresses including newly obtained >> sustained IP address over the new access network in the IP stack. >> However, when an app. is initiated, the IP stack may not select the >> new one in the context of the default source IP address selection > mechanism [RFC6724][RFC5014]. >>> >> >> OK, is the issue following: When there are multiple sustained IP >> addresses, how does the IP stack pick one among them? (*) >> >>>> As mentioned and specified in our draft >> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, >> if there is no additional preference, we can leave selection to the >> default source address selection mechanism. BUT if we have specific >> preference among multiple sustained IP addresses and an initiated >> application wants to have non-anchored sustained IP address over >> currently attached access network, the proposed flag is essential. >> > > I think you are meaning the same thing as I said above (*). > Do you agree? > >>>> Yes. > >>> For providing the full on-demand mobility, a new flag is needed, >>> letting >> the IP stack request a new sustained IP address or choose a sustained >> IP address not requiring IP mobility anchoring when an application is >> initiated, among the existing ones in the IP stack. >>> >> >> Your flag is not a solution to what I captured above. It does >> something >> else: Instruct the IP stack to go get a new sustained IP address >> whether there is already one or more configured on the stack or not. >> (**) >> >>>> Answered in the above. >> > > There's a discrepancy between (*) and your solution (**). > > Are we talking about (*), (**), or something else? > >>>> There is no discrepancy between them. I said "a new flag", just an > additional flag not intending to get a new sustained IP address all > the time. And it should not request a new sustained IP address whether > there is already one or more configured on the stack or not. It is > given with the same expression in the ticket, though our draft is > saying the meaning of a new sustained IP address, which will be revised in next update. > > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. > > > Seil Jeon > > > > >> Alper >> >> >> >>> -- >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>> Reporter: | Owner: draft-ietf-dmm-ondemand- >>> seiljeon@av.it.pt | mobility@tools.ietf.org >>> Type: defect | Status: new >>> Priority: critical | Milestone: >>> Component: ondemand- | Version: >>> mobility | Keywords: on-demand mobility >>> Severity: Submitted | >>> WG Document | >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>> >>> Ticket URL: < http://trac.tools.ietf.org/wg/dmm/trac/ticket/49> >>> dmm < http://tools.ietf.org/dmm/> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> > > ------=_NextPart_000_0019_01D09CC8.BC2862E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Alper,

 

Regards,

Seil

 

 

-----Original Message-----
From: Alper Yegin = [mailto:alper.yegin@yegin.org]
Sent: Monday, June 01, 2015 8:50 = PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 = (ondemand-mobility): full on-demand mobility support

 

> = The point is that when the IP stack receives a flag with sustained IP =

> address flag, it will check = it has a sustained IP address, and if it

> has one or more, one that does not activate IP = mobility will be

> selected. = If not, the MN will be triggered to get a new IP sustained =

> address not activing IP = mobility.

 

So, the idea is, when this flag is set along with a = Sustained IP address request from the app:

- if the host stack is already configured with a = Sustained IP address allocated from the serving network, then it gets = selected (irrespective of the presence or absence of any other Sustained = IP address).

 

>> No. I said = "one that does not activate IP mobility" over the serving = network, among the existing ones in the IP stack, gets selected. If no = one in the IP stack is not matched, it will make an attempt to get a new = sustained IP address from the serving network.

 

- if the host stack is not already configured with = a Sustained IP address allocated from the serving network (irrespective = of the presence or absence of any Sustained IP address from any other = network), then the host makes an attempt to configure one with the = serving network.

 

>> = Yes.

 

-- if the configuration succeeds, then the newly = configured IP address is selected.

 

>> = Yes.

 

-- if the configuration fails. then the call fails = (?? or some other behavior -- you can define here).

 

>> You mean the = configuration fails when there is no sustained IP address, = right?

In my opinion, this issue belongs to address = configuration mechanism based on definition of the three DMM APIs. Those = jobs are/will be asked on each configuration mechanism, according to = discussion of the previous teleconference in the WT you’re = leading. At that time, if I see any something related to our proposal, = we will raise our voice.

 

 

 

 

Alper

 

 

 

 

 

 

>>> #49: full on-demand mobility = support

>>> =

>>> The three proposed = flags express a "type" of source IP address = an

>> application wants to = get to the IP stack. Particularly, the sustained

>> IP address is proposed to provide = on-demand IP session continuity,

>> which activates IP mobility once the = terminal moves across other

>> access

> network.

>>> While the terminal stays at the same = network where the session is

>> initiated, regular IP routing is = applied.

>>> =

>>> The on-demand draft = does not assure provide the full on-demand

>>> mobility

>> for all scenarios by merely indicating the = Socket API,

>> = IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned =

>> issue is as = follows;

>>> =

>>> 0. The MN is = configured with one or more Nomadic IP addresses.

>>>

>>> 1. Once an app. requests = "sustained IP address" to the IP stack, and

>>> it

>> will obtain a sustained IP address through = a protocol procedure

>> = between  the terminal and network.

>>>

>>> 2. Other app. initiated over the same = access network will use the

>>> same

>> sustained IP address while the terminal = remains connected at the same

>> access network.

>>>

>>> 3. The terminal moves to another = access network and a new app.

>>> requests a

>> sustained IP address with the Socket API = to the IP stack. Since a

>> = sustained IP address is already available in the IP stack, the =

>> sustained  IP = address is assigned to the new app.

>>>

>>

>> Yes, that's what happens.

>> You are not pointing to an issue up until = this point, right? Because,

>> you continuing your email with a = "Besides" gives the impression that

>> you are pointing to an issue, but I don't = see any issue captured in

>> the

> above text.

>>

>>>> There is an issue. Maybe, we need = to be synchronized how have you

>>>> thought

>> and defined the meaning of "on-demand = mobility". As far as I know,

>> there are two meanings; one is that by = imposing capability among IP

>> address reachability and IP session = continuity, needed for an

>> application, into a source IP address, = on-demand mobility could be

>> achieved; as the other meaning, it can be = rephrased and detailed with

>> dynamic mobility, which should be applied = in the use of sustained IP

>> address. A new application needs to have = non-anchored sustained IP

>> address. This is our consistent claim. = Non-optimal routing issue has

>> been raised in DMM Requirement document in = RFC 7333, which should be

> = critically considered in the solutions.

>>

>

> = Sorry, I don't understand what you meant here.

>

>>>> You answer doesn't make us = progress. Please specify where and what

>>>> you

> have understood.

>

> =

>>> Besides, in case = sustained IP address allocation is used default,

>>> there

>> may be multiple sustained IP addresses = including newly obtained

>> = sustained IP address over the new access network in the IP = stack.

>> However, when an = app. is initiated, the IP stack may not select the

>> new one in the context of the default = source IP address selection

> = mechanism [RFC6724][RFC5014].

>>>

>>

>> OK, is the issue following: When there are = multiple sustained IP

>> = addresses, how does the IP stack pick one among them? = (*)

>>

>>>> As mentioned and specified in our = draft

>> http://tools.ietf.org/htm= l/draft-sijeon-dmm-use-cases-api-source-00,

>> if there is no additional preference, we = can leave selection to the

>> default source address selection = mechanism. BUT if we have specific

>> preference among multiple sustained IP = addresses and an initiated

>> application wants to have non-anchored = sustained IP address over

>> currently attached access network, the = proposed flag is essential.

>>

>

> I = think you are meaning the same thing as I said above = (*).

> Do you = agree?

>

>>>> Yes.

>

>>> For providing the full on-demand = mobility, a new flag is needed,

>>> letting

>> the IP stack request a new sustained IP = address or choose a sustained

>> IP address not requiring IP mobility = anchoring when an application is

>> initiated, among the existing ones in the = IP stack.

>>> =

>>

>> Your flag is not a solution to what I = captured above. It does

>> = something

>> else: Instruct = the IP stack to go get a new sustained IP address

>> whether there is already one or more = configured on the stack or not.

>> (**)

>>

>>>> Answered in the above. =

>>

>

> = There's a discrepancy between (*) and your solution = (**).

>

> Are we talking about (*), (**), or something = else?

>

>>>> There is no discrepancy between = them. I said "a new flag", just an

> additional flag not intending to get a new = sustained IP address all

> the = time. And it should not request a new sustained IP address whether =

> there is already one or more = configured on the stack or not. It is

> given with the same expression in the ticket, = though our draft is

> saying = the meaning of a new sustained IP address, which will be revised in next = update.

>

> The point is that when the IP stack receives a = flag with sustained IP

> = address flag, it will check it has a sustained IP address, and if it =

> has one or more, one that = does not activate IP mobility will be

> selected. If not, the MN will be triggered to = get a new IP sustained

> = address not activing IP mobility.

>

> =

> Seil Jeon

>

> =

>

>

>> Alper

>>

>>

>>

>>> --

>>> = -------------------------+------------------------------------------=

>>> = -------------------------+-

>>> = -------------------------+---

>>> = -------------------------+---

>>> = Reporter:          &nbs= p;    |      Owner:  = draft-ietf-dmm-ondemand-

>>> seiljeon@av.it.pt<= /a>      |  mobility@tools.ietf.org

>>>   = Type:  defect       = |     Status:  new

>>> Priority:  = critical     |  Milestone:

>>> Component:  = ondemand-    |    = Version:

>>> = mobility           = ;    |   Keywords:  on-demand = mobility

>>> = Severity:  Submitted    |

>>> WG = Document           = ; |

>>> = -------------------------+------------------------------------------=

>>> = -------------------------+-

>>> = -------------------------+---

>>> = -------------------------+---

>>>

>>> Ticket URL: <http://trac.tools.ietf.or= g/wg/dmm/trac/ticket/49>

>>> dmm <http://tools.ietf.org/dmm= />

>>> =

>>>

>>> = _______________________________________________

>>> dmm mailing list

>>> dmm@ietf.org

>>> https://www.ietf.org/mail= man/listinfo/dmm

>>

>>

>

> =

 

------=_NextPart_000_0019_01D09CC8.BC2862E0-- From nobody Tue Jun 2 12:25:53 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63E31B2B63 for ; Tue, 2 Jun 2015 12:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEgjBWW80ViQ for ; Tue, 2 Jun 2015 12:25:50 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 4560D1B2B27 for ; Tue, 2 Jun 2015 12:25:36 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so111023311lbb.3 for ; Tue, 02 Jun 2015 12:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=k3JbF1LCjrjfl+sHLazG7IxJQUGKYiySgXC+zO4JN1Q=; b=pxKqr0GkKBCBNJhh+r4gA4UbX7TqQTIL8yqAozeeP+tQX9PtyTL6GmGVlkHGZ5NdE/ pUSGWu4Af35qVtQpRYIVyPbdWNq0vcxbYyCTOjiwrCPvNmIxnKoAQVeqylR0J5rCgm82 XX2VJ6eMHfyoGkAY2fqvLt2glmqOqgpd6FZb2NI68O1kjHUiPDQtiF5STyXK14/W1p67 GRz1OiCfrGIywVQKvRCJRK3WCHyYuUAkMsFNkxmjozt2pktnzBg6ejuxa/C5zkj4Suu5 2vXnQpDKPIsX+ttXjAmxbisGux2Ljbw4jlFIU8zB14ZKFSsH/qyRcgKNbAGQo4SCpGf6 mDpA== MIME-Version: 1.0 X-Received: by 10.152.42.140 with SMTP id o12mr19346918lal.15.1433273134645; Tue, 02 Jun 2015 12:25:34 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Tue, 2 Jun 2015 12:25:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jun 2015 14:25:34 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] vepc draft Rev. 04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 19:25:51 -0000 Hi Matsushima-san, On Fri, May 29, 2015 at 8:24 AM, Satoru Matsushima wrote: > Hi Behcet-san, > > On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya > wrote: >> >> Hi Satoru, >> >> Thanks for your reply. >> >> Let me continue the discussion with your text in Section 3.2 where you >> mention >> vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) >> that defines FPCP Agent function and Client function. >> >> I don't understand how you could justify defining a new forwarding >> policy configuration protocol to do this Agent/Client functionality? >> Why not use similar Agent/Client models that are being defined rather >> than defining a new protocol? >> I think this point requires much stronger justification which I could >> not see in Section 3.2. >> > > The text just describes about a part of where FPCP may be applicable in > vEPC. > > > >> >> Are you that we have to to reinvent the wheel, rather than reusing >> something that is already available? How are we going to reinvent that >> wheel also remains to be seen, I think. >> > > Point taken. Which kind of wheel do you have in mind? Please check this draft: https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-02 Regards, Behcet > > cheers, > --satoru > From nobody Tue Jun 2 23:03:25 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46B51B356B for ; Tue, 2 Jun 2015 23:03:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49SyDId_EX4v for ; Tue, 2 Jun 2015 23:03:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C7D1B356A for ; Tue, 2 Jun 2015 23:03:19 -0700 (PDT) Received: from [192.168.2.6] ([85.97.51.111]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0LiVqM-1ZVmc62O0y-00cjHS; Wed, 03 Jun 2015 08:03:13 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4F059796-B4BD-4F0A-A9CC-0263278A0832" From: Alper Yegin In-Reply-To: <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> Date: Wed, 3 Jun 2015 09:02:54 +0300 Message-Id: References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> To: "Seil Jeon" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:yPUHrYx0NUbJWuN3R3Bw78XbfJJeIE1Qgh9LjkFThex9ytRSllW 0DEKora8BxZdqV7T7pSXnoU1cMVnD8UiJJBF+Za95lhMefOHE6xln9g3UWspuV+ua1ijdf4 l2a7jqqOAtA9DuRc5TTFLqI2bT3jXQwqzBf2APDSK1luP63hm3mwPbHG+worjElNMr4sonk 04o2NWcZdmRKSVydMrskg== X-UI-Out-Filterresults: notjunk:1;V01:K0:rsQrViXWGPs=:iFkUSCEi2XIXBxEIlarUL+ EQ9E7ADcQnhmWahi3fzy3q/peyWb366ioUEL3KcoIHX8imq4qMC/FD7HPBBIf77Zg/9Nu4AOu p5Rv08XVp9QagdbY0WbjGoPUq4PSH5G7/Nxj7LGN2fLoFlK1wthyYmIk7qy4k6a6fTzLM1cBW 6OltFJMVQk0VHz8aEGnCbw69u3G8HSqCaigZPNEIBWVX/QA2fqMYRkmX7uje4DR2Qvq5l9Lri 2T2D9ny9HEmCxWHw5d9/BqDMWAOb3xlhCxM++cD1PxcJoaGuGKX+Pm3iXwNjFcakLo7fH2aY8 Lid1B7gxIc3IfF/kaC7AwOAoGcN+/IRKGq4fHQul2qRDpCbL9nTuqerN6G96ija717x4nL+A/ ecAMdF9Zid6kDVW1ULTelOEwuxj0kI/ySosmMVXtgUspUr78QKqVfmQFgiGyFnkuuhhYytUnh qZ7tnDtfDYpNwBbcH9+eJjjwNbMUQxlEIK8cgCVxXpsUvkjSxCKYZ5RloGUZNOXHOCH2F8m27 1lSxaFvFhCw2mMOMNY7tkmTpottW20aXcafkdNJQrnOGbHZkBHbAPaepHqoNQQukdB8P9Xgsh +Ps3dxz+F0GbSYypqTvJSL503eXdt/RM56TiXY4kYNIIcfvGsA1x/InRD3kcbOGoGNJvS4Isy +Xib+BaXVxjuGM3t1nx3evIBX9QmQYNFwOMzNIqHyN1JIzA== Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 06:03:24 -0000 --Apple-Mail=_4F059796-B4BD-4F0A-A9CC-0263278A0832 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > So, the idea is, when this flag is set along with a Sustained IP = address request from the app: > - if the host stack is already configured with a Sustained IP address = allocated from the serving network, then it gets selected (irrespective = of the presence or absence of any other Sustained IP address). > =20 > >> No. I said "one that does not activate IP mobility" over the = serving network, among the existing ones in the IP stack, gets selected. = If no one in the IP stack is not matched, it will make an attempt to get = a new sustained IP address from the serving network. What exactly is "(an IP address) that does not activate IP mobility"? = Please elaborate. Is it - A nomadic IP address? - A Sustained IP address that just got allocated from the currently = serving network (hence the "mobility is not activated" until the MN = moves off link)? - something else? Alper On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote: > Hi Alper, > =20 > Regards, > Seil > =20 > =20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Monday, June 01, 2015 8:50 PM > To: Seil Jeon > Cc: dmm@ietf.org > Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand = mobility support > =20 > > The point is that when the IP stack receives a flag with sustained = IP > > address flag, it will check it has a sustained IP address, and if it > > has one or more, one that does not activate IP mobility will be > > selected. If not, the MN will be triggered to get a new IP sustained > > address not activing IP mobility. > =20 > So, the idea is, when this flag is set along with a Sustained IP = address request from the app: > - if the host stack is already configured with a Sustained IP address = allocated from the serving network, then it gets selected (irrespective = of the presence or absence of any other Sustained IP address). > =20 > >> No. I said "one that does not activate IP mobility" over the = serving network, among the existing ones in the IP stack, gets selected. = If no one in the IP stack is not matched, it will make an attempt to get = a new sustained IP address from the serving network. > =20 > - if the host stack is not already configured with a Sustained IP = address allocated from the serving network (irrespective of the presence = or absence of any Sustained IP address from any other network), then the = host makes an attempt to configure one with the serving network. > =20 > >> Yes. > =20 > -- if the configuration succeeds, then the newly configured IP address = is selected. > =20 > >> Yes. > =20 > -- if the configuration fails. then the call fails (?? or some other = behavior -- you can define here). > =20 > >> You mean the configuration fails when there is no sustained IP = address, right? > In my opinion, this issue belongs to address configuration mechanism = based on definition of the three DMM APIs. Those jobs are/will be asked = on each configuration mechanism, according to discussion of the previous = teleconference in the WT you=92re leading. At that time, if I see any = something related to our proposal, we will raise our voice. > =20 > =20 > =20 > =20 > Alper > =20 > =20 > =20 > =20 > =20 > =20 > >>> #49: full on-demand mobility support > >>> > >>> The three proposed flags express a "type" of source IP address an > >> application wants to get to the IP stack. Particularly, the = sustained > >> IP address is proposed to provide on-demand IP session continuity, > >> which activates IP mobility once the terminal moves across other > >> access > > network. > >>> While the terminal stays at the same network where the session is > >> initiated, regular IP routing is applied. > >>> > >>> The on-demand draft does not assure provide the full on-demand > >>> mobility > >> for all scenarios by merely indicating the Socket API, > >> IPV6_REQ_SUSTAINED_IP. An example scenario raising the = aforementioned > >> issue is as follows; > >>> > >>> 0. The MN is configured with one or more Nomadic IP addresses. > >>> > >>> 1. Once an app. requests "sustained IP address" to the IP stack, = and > >>> it > >> will obtain a sustained IP address through a protocol procedure > >> between the terminal and network. > >>> > >>> 2. Other app. initiated over the same access network will use the > >>> same > >> sustained IP address while the terminal remains connected at the = same > >> access network. > >>> > >>> 3. The terminal moves to another access network and a new app. > >>> requests a > >> sustained IP address with the Socket API to the IP stack. Since a > >> sustained IP address is already available in the IP stack, the > >> sustained IP address is assigned to the new app. > >>> > >> > >> Yes, that's what happens. > >> You are not pointing to an issue up until this point, right? = Because, > >> you continuing your email with a "Besides" gives the impression = that > >> you are pointing to an issue, but I don't see any issue captured in > >> the > > above text. > >> > >>>> There is an issue. Maybe, we need to be synchronized how have you > >>>> thought > >> and defined the meaning of "on-demand mobility". As far as I know, > >> there are two meanings; one is that by imposing capability among IP > >> address reachability and IP session continuity, needed for an > >> application, into a source IP address, on-demand mobility could be > >> achieved; as the other meaning, it can be rephrased and detailed = with > >> dynamic mobility, which should be applied in the use of sustained = IP > >> address. A new application needs to have non-anchored sustained IP > >> address. This is our consistent claim. Non-optimal routing issue = has > >> been raised in DMM Requirement document in RFC 7333, which should = be > > critically considered in the solutions. > >> > > > > Sorry, I don't understand what you meant here. > > > >>>> You answer doesn't make us progress. Please specify where and = what > >>>> you > > have understood. > > > > > >>> Besides, in case sustained IP address allocation is used default, > >>> there > >> may be multiple sustained IP addresses including newly obtained > >> sustained IP address over the new access network in the IP stack. > >> However, when an app. is initiated, the IP stack may not select the > >> new one in the context of the default source IP address selection > > mechanism [RFC6724][RFC5014]. > >>> > >> > >> OK, is the issue following: When there are multiple sustained IP > >> addresses, how does the IP stack pick one among them? (*) > >> > >>>> As mentioned and specified in our draft > >> = http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, > >> if there is no additional preference, we can leave selection to the > >> default source address selection mechanism. BUT if we have specific > >> preference among multiple sustained IP addresses and an initiated > >> application wants to have non-anchored sustained IP address over > >> currently attached access network, the proposed flag is essential. > >> > > > > I think you are meaning the same thing as I said above (*). > > Do you agree? > > > >>>> Yes. > > > >>> For providing the full on-demand mobility, a new flag is needed, > >>> letting > >> the IP stack request a new sustained IP address or choose a = sustained > >> IP address not requiring IP mobility anchoring when an application = is > >> initiated, among the existing ones in the IP stack. > >>> > >> > >> Your flag is not a solution to what I captured above. It does > >> something > >> else: Instruct the IP stack to go get a new sustained IP address > >> whether there is already one or more configured on the stack or = not. > >> (**) > >> > >>>> Answered in the above. > >> > > > > There's a discrepancy between (*) and your solution (**). > > > > Are we talking about (*), (**), or something else? > > > >>>> There is no discrepancy between them. I said "a new flag", just = an > > additional flag not intending to get a new sustained IP address all > > the time. And it should not request a new sustained IP address = whether > > there is already one or more configured on the stack or not. It is > > given with the same expression in the ticket, though our draft is > > saying the meaning of a new sustained IP address, which will be = revised in next update. > > > > The point is that when the IP stack receives a flag with sustained = IP > > address flag, it will check it has a sustained IP address, and if it > > has one or more, one that does not activate IP mobility will be > > selected. If not, the MN will be triggered to get a new IP sustained > > address not activing IP mobility. > > > > > > Seil Jeon > > > > > > > > > >> Alper > >> > >> > >> > >>> -- > >>> = -------------------------+------------------------------------------ > >>> -------------------------+- > >>> -------------------------+--- > >>> -------------------------+--- > >>> Reporter: | Owner: draft-ietf-dmm-ondemand- > >>> seiljeon@av.it.pt | mobility@tools.ietf.org > >>> Type: defect | Status: new > >>> Priority: critical | Milestone: > >>> Component: ondemand- | Version: > >>> mobility | Keywords: on-demand mobility > >>> Severity: Submitted | > >>> WG Document | > >>> = -------------------------+------------------------------------------ > >>> -------------------------+- > >>> -------------------------+--- > >>> -------------------------+--- > >>> > >>> Ticket URL: > >>> dmm > >>> > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >> > >> > > > > --Apple-Mail=_4F059796-B4BD-4F0A-A9CC-0263278A0832 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
So, the idea is, when this flag = is set along with a Sustained IP address request from the = app:
- if the host stack is already configured with a = Sustained IP address allocated from the serving network, then it gets = selected (irrespective of the presence or absence of any other Sustained = IP address).
>> No. I said "one that does not activate IP = mobility" over the serving network, among the existing ones in the IP = stack, gets selected. If no one in the IP stack is not matched, it will = make an attempt to get a new sustained IP address from the serving = network.

=

What exactly is "(an IP address) that does not = activate IP mobility"? Please elaborate.

Is = it
- A nomadic IP address?
- A Sustained IP address = that just got allocated from the currently serving network (hence the = "mobility is not activated" until the MN moves off link)?
- = something = else?

Alper




On Jun 2, 2015, at 2:11 AM, Seil Jeon = wrote:

Hi Alper,
 
Regards,
Seil
 
 
-----Original = Message-----
From: Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Monday, June 01, = 2015 8:50 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 = (ondemand-mobility): full on-demand mobility support
 
> The point is that when the = IP stack receives a flag with sustained IP
> address flag, it will check it has a sustained IP = address, and if it
> has one or more, one that = does not activate IP mobility will be
> selected. If not, the MN will be triggered to get a = new IP sustained
> address not activing IP = mobility.
 
So, the idea is, when this flag is set along with a = Sustained IP address request from the app:
- if the host stack is already configured with a Sustained = IP address allocated from the serving network, then it gets selected = (irrespective of the presence or absence of any other Sustained IP = address).
>> No. I said "one that does not activate IP = mobility" over the serving network, among the existing ones in the IP = stack, gets selected. If no one in the IP stack is not matched, it will = make an attempt to get a new sustained IP address from the serving = network.
- if the host stack is not = already configured with a Sustained IP address allocated from the = serving network (irrespective of the presence or absence of any = Sustained IP address from any other network), then the host makes an = attempt to configure one with the serving network.
>> Yes.
-- if the configuration = succeeds, then the newly configured IP address is = selected.
>> Yes.
-- if the configuration fails. = then the call fails (?? or some other behavior -- you can define = here).
>> You mean the configuration fails when there is no = sustained IP address, right?
In my opinion, = this issue belongs to address configuration mechanism based on = definition of the three DMM APIs. Those jobs are/will be asked on each = configuration mechanism, according to discussion of the previous = teleconference in the WT you=92re leading. At that time, if I see any = something related to our proposal, we will raise our = voice.
 
 
Alper
 
 
 
 
 
 
>>> #49: full on-demand mobility = support
>>>
>>> The three proposed flags express a "type" of = source IP address an
>> application wants to = get to the IP stack. Particularly, the sustained
>> IP address is proposed to provide on-demand IP = session continuity,
>> which activates IP = mobility once the terminal moves across other
>> access
> = network.
>>> While the terminal stays = at the same network where the session is
>> initiated, regular IP routing is = applied.
>>>
>>> The on-demand draft does not assure provide = the full on-demand
>>> = mobility
>> for all scenarios by merely = indicating the Socket API,
>> = IPV6_REQ_SUSTAINED_IP. An example scenario raising the = aforementioned
>> issue is as = follows;
>>>
>>> 0. The MN is configured with one or more = Nomadic IP addresses.
>>> 1. Once an app. = requests "sustained IP address" to the IP stack, = and
>>> it
>> will obtain a sustained IP address through a = protocol procedure
>> between  the = terminal and network.
>>> 2. Other app. = initiated over the same access network will use the
>>> same
>> sustained IP = address while the terminal remains connected at the = same
>> access network.
>>>
>>> 3. The = terminal moves to another access network and a new = app.
>>> requests a
>> sustained IP address with the Socket API to the = IP stack. Since a
>> sustained IP address is = already available in the IP stack, the
>> sustained  IP address is assigned to the new = app.
>>>
>>
>> Yes, that's what = happens.
>> You are not pointing to an = issue up until this point, right? Because,
>> you continuing your email with a "Besides" gives = the impression that
>> you are pointing to an = issue, but I don't see any issue captured in
>> the
> above = text.
>>
>>>> = There is an issue. Maybe, we need to be synchronized how have = you
>>>> thought
>> and defined the meaning of "on-demand mobility". = As far as I know,
>> there are two meanings; = one is that by imposing capability among IP
>> address reachability and IP session continuity, = needed for an
>> application, into a = source IP address, on-demand mobility could be
>> achieved; as the other meaning, it can be = rephrased and detailed with
>> dynamic = mobility, which should be applied in the use of sustained = IP
>> address. A new application needs to have = non-anchored sustained IP
>> address. This is our = consistent claim. Non-optimal routing issue has
>> been raised in DMM Requirement document in RFC = 7333, which should be
> critically considered in = the solutions.
>>
>
> Sorry, I don't understand = what you meant here.
>
>>>> You answer doesn't make us progress. = Please specify where and what
>>>> = you
> have understood.
>
>
>>> Besides, in case sustained IP address = allocation is used default,
>>> = there
>> may be multiple sustained IP addresses = including newly obtained
>> sustained IP address = over the new access network in the IP stack.
>> However, when an app. is initiated, the IP stack = may not select the
>> new one in the context = of the default source IP address selection
> mechanism [RFC6724][RFC5014].
>>>
>> OK, is the issue following: = When there are multiple sustained IP
>> addresses, how does the IP stack pick one among = them? (*)
>>
>>>> As mentioned and specified in our = draft

To: "'Alper Yegin'" References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> In-Reply-To: Date: Wed, 3 Jun 2015 11:12:53 +0100 Message-ID: <005d01d09de5$dadd6b40$909841c0$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01D09DEE.3CADBA20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXyJVonWC/jWHjoPLHEPQMMWOBzAGkZzt5AU1BkT0C/VzGWQLvqnHwAhDpQpMCH8V98AJIAZ16Aps88YqcfKR/QA== Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 10:13:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005E_01D09DEE.3CADBA20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit - A Sustained IP address that just got allocated from the currently serving network (hence the "mobility is not activated" until the MN moves off link)? > Yes. Thanks for your elaboration. Regards, Seil From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, June 03, 2015 7:03 AM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support So, the idea is, when this flag is set along with a Sustained IP address request from the app: - if the host stack is already configured with a Sustained IP address allocated from the serving network, then it gets selected (irrespective of the presence or absence of any other Sustained IP address). >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network. What exactly is "(an IP address) that does not activate IP mobility"? Please elaborate. Is it - A nomadic IP address? - A Sustained IP address that just got allocated from the currently serving network (hence the "mobility is not activated" until the MN moves off link)? - something else? Alper On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote: Hi Alper, Regards, Seil -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Monday, June 01, 2015 8:50 PM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. So, the idea is, when this flag is set along with a Sustained IP address request from the app: - if the host stack is already configured with a Sustained IP address allocated from the serving network, then it gets selected (irrespective of the presence or absence of any other Sustained IP address). >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network. - if the host stack is not already configured with a Sustained IP address allocated from the serving network (irrespective of the presence or absence of any Sustained IP address from any other network), then the host makes an attempt to configure one with the serving network. >> Yes. -- if the configuration succeeds, then the newly configured IP address is selected. >> Yes. -- if the configuration fails. then the call fails (?? or some other behavior -- you can define here). >> You mean the configuration fails when there is no sustained IP address, right? In my opinion, this issue belongs to address configuration mechanism based on definition of the three DMM APIs. Those jobs are/will be asked on each configuration mechanism, according to discussion of the previous teleconference in the WT you're leading. At that time, if I see any something related to our proposal, we will raise our voice. Alper >>> #49: full on-demand mobility support >>> >>> The three proposed flags express a "type" of source IP address an >> application wants to get to the IP stack. Particularly, the sustained >> IP address is proposed to provide on-demand IP session continuity, >> which activates IP mobility once the terminal moves across other >> access > network. >>> While the terminal stays at the same network where the session is >> initiated, regular IP routing is applied. >>> >>> The on-demand draft does not assure provide the full on-demand >>> mobility >> for all scenarios by merely indicating the Socket API, >> IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned >> issue is as follows; >>> >>> 0. The MN is configured with one or more Nomadic IP addresses. >>> >>> 1. Once an app. requests "sustained IP address" to the IP stack, and >>> it >> will obtain a sustained IP address through a protocol procedure >> between the terminal and network. >>> >>> 2. Other app. initiated over the same access network will use the >>> same >> sustained IP address while the terminal remains connected at the same >> access network. >>> >>> 3. The terminal moves to another access network and a new app. >>> requests a >> sustained IP address with the Socket API to the IP stack. Since a >> sustained IP address is already available in the IP stack, the >> sustained IP address is assigned to the new app. >>> >> >> Yes, that's what happens. >> You are not pointing to an issue up until this point, right? Because, >> you continuing your email with a "Besides" gives the impression that >> you are pointing to an issue, but I don't see any issue captured in >> the > above text. >> >>>> There is an issue. Maybe, we need to be synchronized how have you >>>> thought >> and defined the meaning of "on-demand mobility". As far as I know, >> there are two meanings; one is that by imposing capability among IP >> address reachability and IP session continuity, needed for an >> application, into a source IP address, on-demand mobility could be >> achieved; as the other meaning, it can be rephrased and detailed with >> dynamic mobility, which should be applied in the use of sustained IP >> address. A new application needs to have non-anchored sustained IP >> address. This is our consistent claim. Non-optimal routing issue has >> been raised in DMM Requirement document in RFC 7333, which should be > critically considered in the solutions. >> > > Sorry, I don't understand what you meant here. > >>>> You answer doesn't make us progress. Please specify where and what >>>> you > have understood. > > >>> Besides, in case sustained IP address allocation is used default, >>> there >> may be multiple sustained IP addresses including newly obtained >> sustained IP address over the new access network in the IP stack. >> However, when an app. is initiated, the IP stack may not select the >> new one in the context of the default source IP address selection > mechanism [RFC6724][RFC5014]. >>> >> >> OK, is the issue following: When there are multiple sustained IP >> addresses, how does the IP stack pick one among them? (*) >> >>>> As mentioned and specified in our draft >> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, >> if there is no additional preference, we can leave selection to the >> default source address selection mechanism. BUT if we have specific >> preference among multiple sustained IP addresses and an initiated >> application wants to have non-anchored sustained IP address over >> currently attached access network, the proposed flag is essential. >> > > I think you are meaning the same thing as I said above (*). > Do you agree? > >>>> Yes. > >>> For providing the full on-demand mobility, a new flag is needed, >>> letting >> the IP stack request a new sustained IP address or choose a sustained >> IP address not requiring IP mobility anchoring when an application is >> initiated, among the existing ones in the IP stack. >>> >> >> Your flag is not a solution to what I captured above. It does >> something >> else: Instruct the IP stack to go get a new sustained IP address >> whether there is already one or more configured on the stack or not. >> (**) >> >>>> Answered in the above. >> > > There's a discrepancy between (*) and your solution (**). > > Are we talking about (*), (**), or something else? > >>>> There is no discrepancy between them. I said "a new flag", just an > additional flag not intending to get a new sustained IP address all > the time. And it should not request a new sustained IP address whether > there is already one or more configured on the stack or not. It is > given with the same expression in the ticket, though our draft is > saying the meaning of a new sustained IP address, which will be revised in next update. > > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. > > > Seil Jeon > > > > >> Alper >> >> >> >>> -- >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>> Reporter: | Owner: draft-ietf-dmm-ondemand- >>> seiljeon@av.it.pt | mobility@tools.ietf.org >>> Type: defect | Status: new >>> Priority: critical | Milestone: >>> Component: ondemand- | Version: >>> mobility | Keywords: on-demand mobility >>> Severity: Submitted | >>> WG Document | >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>> >>> Ticket URL: < http://trac.tools.ietf.org/wg/dmm/trac/ticket/49> >>> dmm < http://tools.ietf.org/dmm/> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> > > ------=_NextPart_000_005E_01D09DEE.3CADBA20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

- A = Sustained IP address that just got allocated from the currently serving = network (hence the "mobility is not activated" until the MN = moves off link)?

> Yes. Thanks for your elaboration.

 

 

R= egards,

S= eil

 

 

 

 



-----Original= Message-----
From: Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Monday, June = 01, 2015 8:50 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] = [dmm] #49 (ondemand-mobility): full on-demand mobility = support

 

> The = point is that when the IP stack receives a flag with sustained = IP

> address = flag, it will check it has a sustained IP address, and if = it

> has one = or more, one that does not activate IP mobility will = be

> = selected. If not, the MN will be triggered to get a new IP = sustained

> address = not activing IP mobility.

 

So, the idea = is, when this flag is set along with a Sustained IP address request from = the app:

- if the = host stack is already configured with a Sustained IP address allocated = from the serving network, then it gets selected (irrespective of the = presence or absence of any other Sustained IP = address).

&= nbsp;

>> No. I said "one that does not activate IP mobility" = over the serving network, among the existing ones in the IP stack, gets = selected. If no one in the IP stack is not matched, it will make an = attempt to get a new sustained IP address from the serving = network.

&= nbsp;

- if the = host stack is not already configured with a Sustained IP address = allocated from the serving network (irrespective of the presence or = absence of any Sustained IP address from any other network), then the = host makes an attempt to configure one with the serving = network.

&= nbsp;

>> Yes.

&= nbsp;

-- if the = configuration succeeds, then the newly configured IP address is = selected.

&= nbsp;

>> Yes.

&= nbsp;

-- if the = configuration fails. then the call fails (?? or some other behavior -- = you can define here).

 

>> You mean the configuration fails when there is no sustained IP = address, right?

In my opinion, this issue belongs to address configuration mechanism = based on definition of the three DMM APIs. Those jobs are/will be asked = on each configuration mechanism, according to discussion of the previous = teleconference in the WT you’re leading. At that time, if I see = any something related to our proposal, we will raise our = voice.

 

&= nbsp;

&= nbsp;

&= nbsp;

Alper

 

 

 

 

 

 

>>> = #49: full on-demand mobility support

>>><= o:p> 

>>> = The three proposed flags express a "type" of source IP address = an

>> = application wants to get to the IP stack. Particularly, the = sustained

>> IP = address is proposed to provide on-demand IP session = continuity,

>> = which activates IP mobility once the terminal moves across = other

>> = access

> = network.

>>> = While the terminal stays at the same network where the session = is

>> = initiated, regular IP routing is = applied.

>>><= o:p> 

>>> = The on-demand draft does not assure provide the full = on-demand

>>> = mobility

>> for = all scenarios by merely indicating the Socket = API,

>> = IPV6_REQ_SUSTAINED_IP. An example scenario raising the = aforementioned

>> = issue is as follows;

>>><= o:p> 

>>> = 0. The MN is configured with one or more Nomadic IP = addresses.

>>><= o:p> 

>>> = 1. Once an app. requests "sustained IP address" to the IP = stack, and

>>> = it

>> = will obtain a sustained IP address through a protocol = procedure

>> = between  the terminal and = network.

>>><= o:p> 

>>> = 2. Other app. initiated over the same access network will use = the

>>> = same

>> = sustained IP address while the terminal remains connected at the = same

>> = access network.

>>><= o:p> 

>>> = 3. The terminal moves to another access network and a new = app.

>>> = requests a

>> = sustained IP address with the Socket API to the IP stack. Since = a

>> = sustained IP address is already available in the IP stack, = the

>> = sustained  IP address is assigned to the new = app.

>>><= o:p> 

>>=  

>> = Yes, that's what happens.

>> You = are not pointing to an issue up until this point, right? = Because,

>> you = continuing your email with a "Besides" gives the impression = that

>> you = are pointing to an issue, but I don't see any issue captured = in

>> = the

> above = text.

>>=  

>>>&= gt; There is an issue. Maybe, we need to be synchronized how have = you

>>>&= gt; thought

>> and = defined the meaning of "on-demand mobility". As far as I = know,

>> = there are two meanings; one is that by imposing capability among = IP

>> = address reachability and IP session continuity, needed for = an

>> = application, into a source IP address, on-demand mobility could = be

>> = achieved; as the other meaning, it can be rephrased and detailed = with

>> = dynamic mobility, which should be applied in the use of sustained = IP

>> = address. A new application needs to have non-anchored sustained = IP

>> = address. This is our consistent claim. Non-optimal routing issue = has

>> = been raised in DMM Requirement document in RFC 7333, which should = be

> = critically considered in the = solutions.

>>=  

>&nbs= p;

> Sorry, = I don't understand what you meant = here.

>&nbs= p;

>>>&= gt; You answer doesn't make us progress. Please specify where and = what

>>>&= gt; you

> have = understood.

>&nbs= p;

>&nbs= p;

>>> = Besides, in case sustained IP address allocation is used = default,

>>> = there

>> may = be multiple sustained IP addresses including newly = obtained

>> = sustained IP address over the new access network in the IP = stack.

>> = However, when an app. is initiated, the IP stack may not select = the

>> new = one in the context of the default source IP address = selection

> = mechanism [RFC6724][RFC5014].

>>><= o:p> 

>>=  

>> OK, = is the issue following: When there are multiple sustained = IP

>> = addresses, how does the IP stack pick one among them? = (*)

>>=  

>>>&= gt; As mentioned and specified in our = draft

>> if = there is no additional preference, we can leave selection to = the

>> = default source address selection mechanism. BUT if we have = specific

>> = preference among multiple sustained IP addresses and an = initiated

>> = application wants to have non-anchored sustained IP address = over

>> = currently attached access network, the proposed flag is = essential.

>>=  

>&nbs= p;

> I think = you are meaning the same thing as I said above = (*).

> Do you = agree?

>&nbs= p;

>>>&= gt; Yes.

>&nbs= p;

>>> = For providing the full on-demand mobility, a new flag is = needed,

>>> = letting

>> the = IP stack request a new sustained IP address or choose a = sustained

>> IP = address not requiring IP mobility anchoring when an application = is

>> = initiated, among the existing ones in the IP = stack.

>>><= o:p> 

>>=  

>> = Your flag is not a solution to what I captured above. It = does

>> = something

>> = else: Instruct the IP stack to go get a new sustained IP = address

>> = whether there is already one or more configured on the stack or = not.

>> = (**)

>>=  

>>>&= gt; Answered in the above.

>>=  

>&nbs= p;

> There's = a discrepancy between (*) and your solution = (**).

>&nbs= p;

> Are we = talking about (*), (**), or something = else?

>&nbs= p;

>>>&= gt; There is no discrepancy between them. I said "a new flag", = just an

> = additional flag not intending to get a new sustained IP address = all

> the = time. And it should not request a new sustained IP address = whether

> there = is already one or more configured on the stack or not. It = is

> given = with the same expression in the ticket, though our draft = is

> saying = the meaning of a new sustained IP address, which will be revised in next = update.

>&nbs= p;

> The = point is that when the IP stack receives a flag with sustained = IP

> address = flag, it will check it has a sustained IP address, and if = it

> has one = or more, one that does not activate IP mobility will = be

> = selected. If not, the MN will be triggered to get a new IP = sustained

> address = not activing IP mobility.

>&nbs= p;

>&nbs= p;

> Seil = Jeon

>&nbs= p;

>&nbs= p;

>&nbs= p;

>&nbs= p;

>> = Alper

>>=  

>>=  

>>=  

>>> = --

>>> = -------------------------+------------------------------------------=

>>> = -------------------------+-

>>> = -------------------------+---

>>> = -------------------------+---

>>> = Reporter:          &nbs= p;    |      Owner:  = draft-ietf-dmm-ondemand-

>>><= span class=3Dapple-converted-space> seiljeon@av.it.pt<= /a>      |  mobility@tools.ietf.org

>>>&= nbsp;  Type:  defect       = |     Status:  = new

>>> = Priority:  critical     |  = Milestone:

>>> = Component:  ondemand-    |    = Version:

>>> = mobility           = ;    |   Keywords:  on-demand = mobility

>>> = Severity:  Submitted    = |

>>> = WG = Document           = ; |

>>> = -------------------------+------------------------------------------=

>>> = -------------------------+-

>>> = -------------------------+---

>>> = -------------------------+---

>>><= o:p> 

>>><= o:p> 

>>><= o:p> 

>>> = _______________________________________________

>>> = dmm mailing list

>>><= span class=3Dapple-converted-space> dmm@ietf.org

>>><= span class=3Dapple-converted-space> https://www.ietf.org/mail= man/listinfo/dmm

>>=  

>>=  

>&nbs= p;

>&nbs= p;

 

------=_NextPart_000_005E_01D09DEE.3CADBA20-- From nobody Wed Jun 3 03:34:44 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43311A0366 for ; Wed, 3 Jun 2015 03:34:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTlfPUP0GikS for ; Wed, 3 Jun 2015 03:34:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C05B1A0363 for ; Wed, 3 Jun 2015 03:34:34 -0700 (PDT) Received: from [10.119.8.101] ([46.19.140.68]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0MXG1D-1YdE5F2RCn-00WD58; Wed, 03 Jun 2015 12:34:28 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_8FCB3DDD-C777-41F6-A145-4DD676B71EDF" From: Alper Yegin In-Reply-To: <005d01d09de5$dadd6b40$909841c0$@av.it.pt> Date: Wed, 3 Jun 2015 13:34:20 +0300 Message-Id: <3620CF9B-EF59-4DF0-993F-4442D91604DC@yegin.org> References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> <005d01d09de5$dadd6b40$909841c0$@av.it.pt> To: "Seil Jeon" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:Q0273Fs0x4Fcnwz/0+gaZF0JipmhZUBwjFxc1flcmS5gwcqGVSP EyNGeYfspQb2jjw/IUxB6/zRwz27CBSM0qkvvtkBJuJ6jla+ytyrIskv8nyk+Z9dfNAPOit 6R2JPh4m0n+96isIH438zLurIHSvRrVp1P7a98f+Wyhwq3L4v0g8s3pfkKYuhYzNosnfWIp PGJ5aWI6PUqfJdAW2dqhQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 10:34:42 -0000 --Apple-Mail=_8FCB3DDD-C777-41F6-A145-4DD676B71EDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 OK, so now at least I fully understand what this is. My recommendation is: - Please refine the issue definition in the tracker, so that people can = understand this the same way, - And then let's ask the WG members their opinion about the issue = (whether it's something worth tackling or not), - And if they agree to the issue, then we move to the solution space = discussion. Alper On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote: > - A Sustained IP address that just got allocated from the currently = serving network (hence the "mobility is not activated" until the MN = moves off link)? > > Yes. Thanks for your elaboration. > =20 > =20 > Regards, > Seil > =20 > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, June 03, 2015 7:03 AM > To: Seil Jeon > Cc: dmm@ietf.org > Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand = mobility support > =20 > So, the idea is, when this flag is set along with a Sustained IP = address request from the app: > - if the host stack is already configured with a Sustained IP address = allocated from the serving network, then it gets selected (irrespective = of the presence or absence of any other Sustained IP address). > =20 > >> No. I said "one that does not activate IP mobility" over the = serving network, among the existing ones in the IP stack, gets selected. = If no one in the IP stack is not matched, it will make an attempt to get = a new sustained IP address from the serving network. > =20 > =20 > What exactly is "(an IP address) that does not activate IP mobility"? = Please elaborate. > =20 > Is it > - A nomadic IP address? > =20 > - A Sustained IP address that just got allocated from the currently = serving network (hence the "mobility is not activated" until the MN = moves off link)? > =20 > - something else? > =20 > Alper > =20 > =20 > =20 > =20 > On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote: >=20 >=20 > Hi Alper, > =20 > Regards, > Seil > =20 > =20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Monday, June 01, 2015 8:50 PM > To: Seil Jeon > Cc: dmm@ietf.org > Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand = mobility support > =20 > > The point is that when the IP stack receives a flag with sustained = IP > > address flag, it will check it has a sustained IP address, and if it > > has one or more, one that does not activate IP mobility will be > > selected. If not, the MN will be triggered to get a new IP sustained > > address not activing IP mobility. > =20 > So, the idea is, when this flag is set along with a Sustained IP = address request from the app: > - if the host stack is already configured with a Sustained IP address = allocated from the serving network, then it gets selected (irrespective = of the presence or absence of any other Sustained IP address). > =20 > >> No. I said "one that does not activate IP mobility" over the = serving network, among the existing ones in the IP stack, gets selected. = If no one in the IP stack is not matched, it will make an attempt to get = a new sustained IP address from the serving network. > =20 > - if the host stack is not already configured with a Sustained IP = address allocated from the serving network (irrespective of the presence = or absence of any Sustained IP address from any other network), then the = host makes an attempt to configure one with the serving network. > =20 > >> Yes. > =20 > -- if the configuration succeeds, then the newly configured IP address = is selected. > =20 > >> Yes. > =20 > -- if the configuration fails. then the call fails (?? or some other = behavior -- you can define here). > =20 > >> You mean the configuration fails when there is no sustained IP = address, right? > In my opinion, this issue belongs to address configuration mechanism = based on definition of the three DMM APIs. Those jobs are/will be asked = on each configuration mechanism, according to discussion of the previous = teleconference in the WT you=92re leading. At that time, if I see any = something related to our proposal, we will raise our voice. > =20 > =20 > =20 > =20 > Alper > =20 > =20 > =20 > =20 > =20 > =20 > >>> #49: full on-demand mobility support > >>>=20 > >>> The three proposed flags express a "type" of source IP address an > >> application wants to get to the IP stack. Particularly, the = sustained > >> IP address is proposed to provide on-demand IP session continuity, > >> which activates IP mobility once the terminal moves across other > >> access > > network. > >>> While the terminal stays at the same network where the session is > >> initiated, regular IP routing is applied. > >>>=20 > >>> The on-demand draft does not assure provide the full on-demand > >>> mobility > >> for all scenarios by merely indicating the Socket API, > >> IPV6_REQ_SUSTAINED_IP. An example scenario raising the = aforementioned > >> issue is as follows; > >>>=20 > >>> 0. The MN is configured with one or more Nomadic IP addresses. > >>>=20 > >>> 1. Once an app. requests "sustained IP address" to the IP stack, = and > >>> it > >> will obtain a sustained IP address through a protocol procedure > >> between the terminal and network. > >>>=20 > >>> 2. Other app. initiated over the same access network will use the > >>> same > >> sustained IP address while the terminal remains connected at the = same > >> access network. > >>>=20 > >>> 3. The terminal moves to another access network and a new app. > >>> requests a > >> sustained IP address with the Socket API to the IP stack. Since a > >> sustained IP address is already available in the IP stack, the > >> sustained IP address is assigned to the new app. > >>>=20 > >>=20 > >> Yes, that's what happens. > >> You are not pointing to an issue up until this point, right? = Because, > >> you continuing your email with a "Besides" gives the impression = that > >> you are pointing to an issue, but I don't see any issue captured in > >> the > > above text. > >>=20 > >>>> There is an issue. Maybe, we need to be synchronized how have you > >>>> thought > >> and defined the meaning of "on-demand mobility". As far as I know, > >> there are two meanings; one is that by imposing capability among IP > >> address reachability and IP session continuity, needed for an > >> application, into a source IP address, on-demand mobility could be > >> achieved; as the other meaning, it can be rephrased and detailed = with > >> dynamic mobility, which should be applied in the use of sustained = IP > >> address. A new application needs to have non-anchored sustained IP > >> address. This is our consistent claim. Non-optimal routing issue = has > >> been raised in DMM Requirement document in RFC 7333, which should = be > > critically considered in the solutions. > >>=20 > >=20 > > Sorry, I don't understand what you meant here. > >=20 > >>>> You answer doesn't make us progress. Please specify where and = what > >>>> you > > have understood. > >=20 > >=20 > >>> Besides, in case sustained IP address allocation is used default, > >>> there > >> may be multiple sustained IP addresses including newly obtained > >> sustained IP address over the new access network in the IP stack. > >> However, when an app. is initiated, the IP stack may not select the > >> new one in the context of the default source IP address selection > > mechanism [RFC6724][RFC5014]. > >>>=20 > >>=20 > >> OK, is the issue following: When there are multiple sustained IP > >> addresses, how does the IP stack pick one among them? (*) > >>=20 > >>>> As mentioned and specified in our draft > >> = http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, > >> if there is no additional preference, we can leave selection to the > >> default source address selection mechanism. BUT if we have specific > >> preference among multiple sustained IP addresses and an initiated > >> application wants to have non-anchored sustained IP address over > >> currently attached access network, the proposed flag is essential. > >>=20 > >=20 > > I think you are meaning the same thing as I said above (*). > > Do you agree? > >=20 > >>>> Yes. > >=20 > >>> For providing the full on-demand mobility, a new flag is needed, > >>> letting > >> the IP stack request a new sustained IP address or choose a = sustained > >> IP address not requiring IP mobility anchoring when an application = is > >> initiated, among the existing ones in the IP stack. > >>>=20 > >>=20 > >> Your flag is not a solution to what I captured above. It does > >> something > >> else: Instruct the IP stack to go get a new sustained IP address > >> whether there is already one or more configured on the stack or = not. > >> (**) > >>=20 > >>>> Answered in the above. > >>=20 > >=20 > > There's a discrepancy between (*) and your solution (**). > >=20 > > Are we talking about (*), (**), or something else? > >=20 > >>>> There is no discrepancy between them. I said "a new flag", just = an > > additional flag not intending to get a new sustained IP address all > > the time. And it should not request a new sustained IP address = whether > > there is already one or more configured on the stack or not. It is > > given with the same expression in the ticket, though our draft is > > saying the meaning of a new sustained IP address, which will be = revised in next update. > >=20 > > The point is that when the IP stack receives a flag with sustained = IP > > address flag, it will check it has a sustained IP address, and if it > > has one or more, one that does not activate IP mobility will be > > selected. If not, the MN will be triggered to get a new IP sustained > > address not activing IP mobility. > >=20 > >=20 > > Seil Jeon > >=20 > >=20 > >=20 > >=20 > >> Alper > >>=20 > >>=20 > >>=20 > >>> -- > >>> = -------------------------+------------------------------------------ > >>> -------------------------+- > >>> -------------------------+--- > >>> -------------------------+--- > >>> Reporter: | Owner: draft-ietf-dmm-ondemand- > >>> seiljeon@av.it.pt | mobility@tools.ietf.org > >>> Type: defect | Status: new > >>> Priority: critical | Milestone: > >>> Component: ondemand- | Version: > >>> mobility | Keywords: on-demand mobility > >>> Severity: Submitted | > >>> WG Document | > >>> = -------------------------+------------------------------------------ > >>> -------------------------+- > >>> -------------------------+--- > >>> -------------------------+--- > >>>=20 > >>> Ticket URL: > >>> dmm > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >>=20 > >>=20 > >=20 > >=20 --Apple-Mail=_8FCB3DDD-C777-41F6-A145-4DD676B71EDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 OK, so now at least I fully understand what this = is.

My recommendation is:
- Please refine = the issue definition in the tracker, so that people can understand this = the same way,
- And then let's ask the WG members their = opinion about the issue (whether it's something worth tackling or = not),
- And if they agree to the issue, then we move to the = solution space = discussion.

Alper


On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote:

- A Sustained IP address = that just got allocated from the currently serving network (hence the = "mobility is not activated" until the MN moves off link)?
> Yes. = Thanks for your elaboration.
From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, June 03, 2015 = 7:03 AM
To: Seil = Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 = (ondemand-mobility): full on-demand mobility = support
So, the idea is, when this flag = is set along with a Sustained IP address request from the = app:
- if the host stack is already = configured with a Sustained IP address allocated from the serving = network, then it gets selected (irrespective of the presence or absence = of any other Sustained IP = address).
>> No. I said "one that does not activate IP = mobility" over the serving network, among the existing ones in the IP = stack, gets selected. If no one in the IP stack is not matched, it will = make an attempt to get a new sustained IP address from the serving = network.
 
 
What exactly is "(an IP address) that does not activate = IP mobility"? Please elaborate.
 
Is it
- A nomadic IP address?
- A Sustained IP address = that just got allocated from the currently serving network (hence the = "mobility is not activated" until the MN moves off link)?
- something = else?
On Jun 2, 2015, at 2:11 = AM, Seil Jeon wrote:
Hi = Alper,
mailto:alper.yegin@yegin.org] 
Sent: Monday, June 01, = 2015 8:50 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 = (ondemand-mobility): full on-demand mobility = support
> The = point is that when the IP stack receives a flag with sustained = IP
> address flag, it will check = it has a sustained IP address, and if = it
> has one or more, one that = does not activate IP mobility will = be
> selected. If not, the MN = will be triggered to get a new IP = sustained
> address = not activing IP mobility.
 
So, the idea is, when this flag is set along with a = Sustained IP address request from the = app:
- if the host stack is already = configured with a Sustained IP address allocated from the serving = network, then it gets selected (irrespective of the presence or absence = of any other Sustained IP = address).
>> No. I said "one that does not activate IP = mobility" over the serving network, among the existing ones in the IP = stack, gets selected. If no one in the IP stack is not matched, it will = make an attempt to get a new sustained IP address from the serving = network.
- if the = host stack is not already configured with a Sustained IP address = allocated from the serving network (irrespective of the presence or = absence of any Sustained IP address from any other network), then the = host makes an attempt to configure one with the serving = network.
>> Yes. -- if the configuration = succeeds, then the newly configured IP address is = selected.
>> Yes. -- if the configuration fails. = then the call fails (?? or some other behavior -- you can define = here).
>> You mean the configuration fails when there is no = sustained IP address, right?In my = opinion, this issue belongs to address configuration mechanism based on = definition of the three DMM APIs. Those jobs are/will be asked on each = configuration mechanism, according to discussion of the previous = teleconference in the WT you=92re leading. At that time, if I see any = something related to our proposal, we will raise our voice.
>>> = #49: full on-demand mobility = support
>>> The three proposed flags express a "type" of = source IP address an
>> application wants to get to the IP stack. = Particularly, the sustained
>> IP address is proposed to provide on-demand IP = session continuity,
>> which activates IP mobility once the terminal = moves across other
>> access
> network.
>>> While the terminal stays at the same network = where the session is
>> initiated, regular IP routing is = applied.
>>> The on-demand draft does not assure provide = the full on-demand
>>> = mobility
>> for = all scenarios by merely indicating the Socket = API,
>> IPV6_REQ_SUSTAINED_IP. = An example scenario raising the = aforementioned
>> = issue is as follows;
>>> 
>>> 0. The MN is configured with one or more = Nomadic IP addresses.
>>> 
>>> 1. Once an app. requests "sustained IP = address" to the IP stack, and
>>> it
>> will obtain a sustained IP address through a = protocol procedure
>> between  the terminal and = network.
>>> 2. Other app. initiated over the same access = network will use the
>>> same
>> sustained IP address while the terminal remains = connected at the same
>> access = network.
>>> 3. The terminal moves to another access = network and a new app.
>>> requests = a
>> sustained IP address = with the Socket API to the IP stack. Since = a
>> sustained IP address is = already available in the IP stack, = the
>> sustained  IP = address is assigned to the new = app.
>> 
>> Yes, that's what = happens.
>> You = are not pointing to an issue up until this point, right? = Because,
>> you = continuing your email with a "Besides" gives the impression = that
>> you are pointing to an = issue, but I don't see any issue captured = in
>> = the
> above = text.
>>>> There is an issue. Maybe, we need to be = synchronized how have you
>>>> = thought
>> and defined the meaning = of "on-demand mobility". As far as I = know,
>> there are two meanings; = one is that by imposing capability among = IP
>> address reachability = and IP session continuity, needed for = an
>> application, into a = source IP address, on-demand mobility could = be
>> achieved; as the other = meaning, it can be rephrased and detailed = with
>> dynamic mobility, which = should be applied in the use of sustained = IP
>> address. A new = application needs to have non-anchored sustained = IP
>> address. This is our = consistent claim. Non-optimal routing issue = has
>> been raised in DMM = Requirement document in RFC 7333, which should = be
> critically considered in = the solutions.
> 
> Sorry, I don't understand what you meant = here.
> have = understood.
>>> = Besides, in case sustained IP address allocation is used = default,
>>> = there
>> may be multiple = sustained IP addresses including newly = obtained
>> = sustained IP address over the new access network in the IP = stack.
>> However, when an app. = is initiated, the IP stack may not select = the
>> new one in the context = of the default source IP address = selection
> = mechanism [RFC6724][RFC5014].
>>> 
>> 
>> OK, is the issue following: When there are = multiple sustained IP
>> addresses, how does the IP stack pick one among = them? (*)
>>>> As mentioned and specified in our = draft

To: "'Alper Yegin'" References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> <005d01d09de5$dadd6b40$909841c0$@av.it.pt> <3620CF9B-EF59-4DF0-993F-4442D91604DC@yegin.org> In-Reply-To: <3620CF9B-EF59-4DF0-993F-4442D91604DC@yegin.org> Date: Wed, 3 Jun 2015 11:59:33 +0100 Message-ID: <007601d09dec$601c8970$20559c50$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01D09DF4.C1EA6750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXyJVonWC/jWHjoPLHEPQMMWOBzAGkZzt5AU1BkT0C/VzGWQLvqnHwAhDpQpMCH8V98AJIAZ16Aps88YoBmwV+dQH2sBSYnGAkxBA= Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 10:59:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0077_01D09DF4.C1EA6750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK, Alper. I agree on your suggested way. Regards, Seil From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, June 03, 2015 11:34 AM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support OK, so now at least I fully understand what this is. My recommendation is: - Please refine the issue definition in the tracker, so that people can understand this the same way, - And then let's ask the WG members their opinion about the issue (whether it's something worth tackling or not), - And if they agree to the issue, then we move to the solution space discussion. Alper On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote: - A Sustained IP address that just got allocated from the currently serving network (hence the "mobility is not activated" until the MN moves off link)? > Yes. Thanks for your elaboration. Regards, Seil From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, June 03, 2015 7:03 AM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support So, the idea is, when this flag is set along with a Sustained IP address request from the app: - if the host stack is already configured with a Sustained IP address allocated from the serving network, then it gets selected (irrespective of the presence or absence of any other Sustained IP address). >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network. What exactly is "(an IP address) that does not activate IP mobility"? Please elaborate. Is it - A nomadic IP address? - A Sustained IP address that just got allocated from the currently serving network (hence the "mobility is not activated" until the MN moves off link)? - something else? Alper On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote: Hi Alper, Regards, Seil -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Monday, June 01, 2015 8:50 PM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. So, the idea is, when this flag is set along with a Sustained IP address request from the app: - if the host stack is already configured with a Sustained IP address allocated from the serving network, then it gets selected (irrespective of the presence or absence of any other Sustained IP address). >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network. - if the host stack is not already configured with a Sustained IP address allocated from the serving network (irrespective of the presence or absence of any Sustained IP address from any other network), then the host makes an attempt to configure one with the serving network. >> Yes. -- if the configuration succeeds, then the newly configured IP address is selected. >> Yes. -- if the configuration fails. then the call fails (?? or some other behavior -- you can define here). >> You mean the configuration fails when there is no sustained IP address, right? In my opinion, this issue belongs to address configuration mechanism based on definition of the three DMM APIs. Those jobs are/will be asked on each configuration mechanism, according to discussion of the previous teleconference in the WT you're leading. At that time, if I see any something related to our proposal, we will raise our voice. Alper >>> #49: full on-demand mobility support >>> >>> The three proposed flags express a "type" of source IP address an >> application wants to get to the IP stack. Particularly, the sustained >> IP address is proposed to provide on-demand IP session continuity, >> which activates IP mobility once the terminal moves across other >> access > network. >>> While the terminal stays at the same network where the session is >> initiated, regular IP routing is applied. >>> >>> The on-demand draft does not assure provide the full on-demand >>> mobility >> for all scenarios by merely indicating the Socket API, >> IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned >> issue is as follows; >>> >>> 0. The MN is configured with one or more Nomadic IP addresses. >>> >>> 1. Once an app. requests "sustained IP address" to the IP stack, and >>> it >> will obtain a sustained IP address through a protocol procedure >> between the terminal and network. >>> >>> 2. Other app. initiated over the same access network will use the >>> same >> sustained IP address while the terminal remains connected at the same >> access network. >>> >>> 3. The terminal moves to another access network and a new app. >>> requests a >> sustained IP address with the Socket API to the IP stack. Since a >> sustained IP address is already available in the IP stack, the >> sustained IP address is assigned to the new app. >>> >> >> Yes, that's what happens. >> You are not pointing to an issue up until this point, right? Because, >> you continuing your email with a "Besides" gives the impression that >> you are pointing to an issue, but I don't see any issue captured in >> the > above text. >> >>>> There is an issue. Maybe, we need to be synchronized how have you >>>> thought >> and defined the meaning of "on-demand mobility". As far as I know, >> there are two meanings; one is that by imposing capability among IP >> address reachability and IP session continuity, needed for an >> application, into a source IP address, on-demand mobility could be >> achieved; as the other meaning, it can be rephrased and detailed with >> dynamic mobility, which should be applied in the use of sustained IP >> address. A new application needs to have non-anchored sustained IP >> address. This is our consistent claim. Non-optimal routing issue has >> been raised in DMM Requirement document in RFC 7333, which should be > critically considered in the solutions. >> > > Sorry, I don't understand what you meant here. > >>>> You answer doesn't make us progress. Please specify where and what >>>> you > have understood. > > >>> Besides, in case sustained IP address allocation is used default, >>> there >> may be multiple sustained IP addresses including newly obtained >> sustained IP address over the new access network in the IP stack. >> However, when an app. is initiated, the IP stack may not select the >> new one in the context of the default source IP address selection > mechanism [RFC6724][RFC5014]. >>> >> >> OK, is the issue following: When there are multiple sustained IP >> addresses, how does the IP stack pick one among them? (*) >> >>>> As mentioned and specified in our draft >> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, >> if there is no additional preference, we can leave selection to the >> default source address selection mechanism. BUT if we have specific >> preference among multiple sustained IP addresses and an initiated >> application wants to have non-anchored sustained IP address over >> currently attached access network, the proposed flag is essential. >> > > I think you are meaning the same thing as I said above (*). > Do you agree? > >>>> Yes. > >>> For providing the full on-demand mobility, a new flag is needed, >>> letting >> the IP stack request a new sustained IP address or choose a sustained >> IP address not requiring IP mobility anchoring when an application is >> initiated, among the existing ones in the IP stack. >>> >> >> Your flag is not a solution to what I captured above. It does >> something >> else: Instruct the IP stack to go get a new sustained IP address >> whether there is already one or more configured on the stack or not. >> (**) >> >>>> Answered in the above. >> > > There's a discrepancy between (*) and your solution (**). > > Are we talking about (*), (**), or something else? > >>>> There is no discrepancy between them. I said "a new flag", just an > additional flag not intending to get a new sustained IP address all > the time. And it should not request a new sustained IP address whether > there is already one or more configured on the stack or not. It is > given with the same expression in the ticket, though our draft is > saying the meaning of a new sustained IP address, which will be revised in next update. > > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. > > > Seil Jeon > > > > >> Alper >> >> >> >>> -- >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>> Reporter: | Owner: draft-ietf-dmm-ondemand- >>> seiljeon@av.it.pt | mobility@tools.ietf.org >>> Type: defect | Status: new >>> Priority: critical | Milestone: >>> Component: ondemand- | Version: >>> mobility | Keywords: on-demand mobility >>> Severity: Submitted | >>> WG Document | >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>> >>> Ticket URL: < http://trac.tools.ietf.org/wg/dmm/trac/ticket/49> >>> dmm < http://tools.ietf.org/dmm/> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> > > ------=_NextPart_000_0077_01D09DF4.C1EA6750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK, Alper.

I agree on your suggested way.

 

Regards,

Seil

 

 

 

OK, so now = at least I fully understand what this is.

 



From:=  Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, June 03, 2015 7:03 = AM
To: Seil = Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 = (ondemand-mobility): full on-demand mobility = support

 

So, the idea = is, when this flag is set along with a Sustained IP address request from = the app:

- if the = host stack is already configured with a Sustained IP address allocated = from the serving network, then it gets selected (irrespective of the = presence or absence of any other Sustained IP = address).

&= nbsp;

>> No. I said "one that does not activate IP mobility" = over the serving network, among the existing ones in the IP stack, gets = selected. If no one in the IP stack is not matched, it will make an = attempt to get a new sustained IP address from the serving = network.

<= div>

 

 

What exactly is "(an IP address) that does not = activate IP mobility"? Please = elaborate.

 

Is it

- A nomadic IP = address?

 

- A = Sustained IP address that just got allocated from the currently serving = network (hence the "mobility is not activated" until the MN = moves off link)?

 

- something = else?

 

Alper

 

 

 

 

On Jun 2, 2015, at 2:11 AM, Seil Jeon = wrote:




Hi = Alper,

 =

Regards,

Seil

 =

 =

-----Original= Message-----
From: Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Monday, June = 01, 2015 8:50 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] = [dmm] #49 (ondemand-mobility): full on-demand mobility = support

 =

> The = point is that when the IP stack receives a flag with sustained = IP

> address = flag, it will check it has a sustained IP address, and if = it

> has one = or more, one that does not activate IP mobility will = be

> = selected. If not, the MN will be triggered to get a new IP = sustained

> address = not activing IP mobility.

 =

So, the idea = is, when this flag is set along with a Sustained IP address request from = the app:

- if the = host stack is already configured with a Sustained IP address allocated = from the serving network, then it gets selected (irrespective of the = presence or absence of any other Sustained IP = address).

&= nbsp;

>> No. I said "one that does not activate IP mobility" = over the serving network, among the existing ones in the IP stack, gets = selected. If no one in the IP stack is not matched, it will make an = attempt to get a new sustained IP address from the serving = network.

&= nbsp;

- if the = host stack is not already configured with a Sustained IP address = allocated from the serving network (irrespective of the presence or = absence of any Sustained IP address from any other network), then the = host makes an attempt to configure one with the serving = network.

&= nbsp;

>> Yes.

&= nbsp;

-- if the = configuration succeeds, then the newly configured IP address is = selected.

&= nbsp;

>> Yes.

&= nbsp;

-- if the = configuration fails. then the call fails (?? or some other behavior -- = you can define here).

 

>> You mean the configuration fails when there is no sustained IP = address, right?

In my opinion, this issue belongs to address configuration mechanism = based on definition of the three DMM APIs. Those jobs are/will be asked = on each configuration mechanism, according to discussion of the previous = teleconference in the WT you’re leading. At that time, if I see = any something related to our proposal, we will raise our = voice.

 

&= nbsp;

&= nbsp;

&= nbsp;

Alper<= o:p>

 =

 =

 =

 =

 =

 =

>>> = #49: full on-demand mobility = support

>>>&= nbsp;

>>> = The three proposed flags express a "type" of source IP address = an

>> = application wants to get to the IP stack. Particularly, the = sustained

>> IP = address is proposed to provide on-demand IP session = continuity,

>> = which activates IP mobility once the terminal moves across = other

>> = access

> = network.

>>> = While the terminal stays at the same network where the session = is

>> = initiated, regular IP routing is = applied.

>>>&= nbsp;

>>> = The on-demand draft does not assure provide the full = on-demand

>>> = mobility

>> for = all scenarios by merely indicating the Socket = API,

>> = IPV6_REQ_SUSTAINED_IP. An example scenario raising the = aforementioned

>> = issue is as follows;

>>>&= nbsp;

>>> = 0. The MN is configured with one or more Nomadic IP = addresses.

>>>&= nbsp;

>>> = 1. Once an app. requests "sustained IP address" to the IP = stack, and

>>> = it

>> = will obtain a sustained IP address through a protocol = procedure

>> = between  the terminal and = network.

>>>&= nbsp;

>>> = 2. Other app. initiated over the same access network will use = the

>>> = same

>> = sustained IP address while the terminal remains connected at the = same

>> = access network.

>>>&= nbsp;

>>> = 3. The terminal moves to another access network and a new = app.

>>> = requests a

>> = sustained IP address with the Socket API to the IP stack. Since = a

>> = sustained IP address is already available in the IP stack, = the

>> = sustained  IP address is assigned to the new = app.

>>>&= nbsp;

>> = ;

>> = Yes, that's what happens.

>> You = are not pointing to an issue up until this point, right? = Because,

>> you = continuing your email with a "Besides" gives the impression = that

>> you = are pointing to an issue, but I don't see any issue captured = in

>> = the

> above = text.

>> = ;

>>>&= gt; There is an issue. Maybe, we need to be synchronized how have = you

>>>&= gt; thought

>> and = defined the meaning of "on-demand mobility". As far as I = know,

>> = there are two meanings; one is that by imposing capability among = IP

>> = address reachability and IP session continuity, needed for = an

>> = application, into a source IP address, on-demand mobility could = be

>> = achieved; as the other meaning, it can be rephrased and detailed = with

>> = dynamic mobility, which should be applied in the use of sustained = IP

>> = address. A new application needs to have non-anchored sustained = IP

>> = address. This is our consistent claim. Non-optimal routing issue = has

>> = been raised in DMM Requirement document in RFC 7333, which should = be

> = critically considered in the = solutions.

>> = ;

> 

> Sorry, = I don't understand what you meant = here.

> 

>>>&= gt; You answer doesn't make us progress. Please specify where and = what

>>>&= gt; you

> have = understood.

> 

> 

>>> = Besides, in case sustained IP address allocation is used = default,

>>> = there

>> may = be multiple sustained IP addresses including newly = obtained

>> = sustained IP address over the new access network in the IP = stack.

>> = However, when an app. is initiated, the IP stack may not select = the

>> new = one in the context of the default source IP address = selection

> = mechanism = [RFC6724][RFC5014].

>>>&= nbsp;

>> = ;

>> OK, = is the issue following: When there are multiple sustained = IP

>> = addresses, how does the IP stack pick one among them? = (*)

>> = ;

>>>&= gt; As mentioned and specified in our = draft

>> if = there is no additional preference, we can leave selection to = the

>> = default source address selection mechanism. BUT if we have = specific

>> = preference among multiple sustained IP addresses and an = initiated

>> = application wants to have non-anchored sustained IP address = over

>> = currently attached access network, the proposed flag is = essential.

>> = ;

> 

> I think = you are meaning the same thing as I said above = (*).

> Do you = agree?

> 

>>>&= gt; Yes.

> 

>>> = For providing the full on-demand mobility, a new flag is = needed,

>>> = letting

>> the = IP stack request a new sustained IP address or choose a = sustained

>> IP = address not requiring IP mobility anchoring when an application = is

>> = initiated, among the existing ones in the IP = stack.

>>>&= nbsp;

>> = ;

>> = Your flag is not a solution to what I captured above. It = does

>> = something

>> = else: Instruct the IP stack to go get a new sustained IP = address

>> = whether there is already one or more configured on the stack or = not.

>> = (**)

>> = ;

>>>&= gt; Answered in the above.

>> = ;

> 

> There's = a discrepancy between (*) and your solution = (**).

> 

> Are we = talking about (*), (**), or something = else?

> 

>>>&= gt; There is no discrepancy between them. I said "a new flag", = just an

> = additional flag not intending to get a new sustained IP address = all

> the = time. And it should not request a new sustained IP address = whether

> there = is already one or more configured on the stack or not. It = is

> given = with the same expression in the ticket, though our draft = is

> saying = the meaning of a new sustained IP address, which will be revised in next = update.

> 

> The = point is that when the IP stack receives a flag with sustained = IP

> address = flag, it will check it has a sustained IP address, and if = it

> has one = or more, one that does not activate IP mobility will = be

> = selected. If not, the MN will be triggered to get a new IP = sustained

> address = not activing IP mobility.

> 

> 

> Seil = Jeon

> 

> 

> 

> 

>> = Alper

>> = ;

>> = ;

>> = ;

>>> = --

>>> = -------------------------+------------------------------------------

>>> = -------------------------+-

>>> = -------------------------+---

=

>>> = -------------------------+---

=

>>> = Reporter:          &nbs= p;    |      Owner:  = draft-ietf-dmm-ondemand-

>>><= span class=3Dapple-converted-space> seiljeon@av.it.pt<= /a>      |  mobility@tools.ietf.org

>>>&= nbsp;  Type:  defect       = |     Status:  = new

>>> = Priority:  critical     |  = Milestone:

>>> = Component:  ondemand-    |    = Version:

>>> = mobility           = ;    |   Keywords:  on-demand = mobility

>>> = Severity:  Submitted    = |

>>> = WG = Document           = ; |

>>> = -------------------------+------------------------------------------

>>> = -------------------------+-

>>> = -------------------------+---

=

>>> = -------------------------+---

=

>>>&= nbsp;

<= div>

>>>&= nbsp;

>>>&= nbsp;

>>> = _______________________________________________

>>> = dmm mailing list

>>><= span class=3Dapple-converted-space> dmm@ietf.org

>>><= span class=3Dapple-converted-space> https://www.ietf.org/mail= man/listinfo/dmm

>> = ;

>> = ;

> 

> 

 

------=_NextPart_000_0077_01D09DF4.C1EA6750-- From nobody Wed Jun 3 08:36:05 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB571A9055 for ; Wed, 3 Jun 2015 08:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chDpdcgKIEJZ for ; Wed, 3 Jun 2015 08:36:01 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A1E1A9061 for ; Wed, 3 Jun 2015 08:35:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t53FZhqN028100; Wed, 3 Jun 2015 17:35:43 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DD990208AC7; Wed, 3 Jun 2015 17:38:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CFCEE20464F; Wed, 3 Jun 2015 17:38:08 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t53FZfrC027380; Wed, 3 Jun 2015 17:35:42 +0200 Message-ID: <556F1ECD.70801@gmail.com> Date: Wed, 03 Jun 2015 17:35:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , Satoru Matsushima References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:36:03 -0000 Le 29/05/2015 20:21, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Friday, May 29, 2015 10:59 AM >> To: Satoru Matsushima >> Cc: dmm >> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >> >> Le 29/05/2015 15:30, Satoru Matsushima a écrit : >>> Ah OK. thanks. >>> Slightly off-topic, I think that there is still chance for tethering >>> with single /64 if it is allocated as a off-link prefix. >> >> Yes, there is still such a chance. But it can not tether more than one >> single subnet. Connected vehicles need several subnets. > > How would it be if the vehicle received a single prefix, but it could be > shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting > be satisfied if it received a shorter prefix from which many /64s > could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. Alex > > Thanks - Fred > fred.l.templin@boeing.com > > >> >> Alex >> >>> >>> But yes, I agree with you. >>> >>> cheers, >>> --satoru >>> >>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu >>> > wrote: >>> >>> Hi, >>> >>> In addition to what Behcet says. >>> >>> I read the example below. I think it is just an example, but just >>> to make sure. >>> >>> Please - do not allocate /64s to end users in a cellular network. >>> Allocate at least /62s to end users. >>> >>> This is to allow the smartphone to perform tethering (small network >>> of wifi devices connecting through the smartphone to the Internet). >>> >>> The assumption of /64 to end user is not good at all. >>> >>> (and yes, I agree that these /62s may be aggregated into a larger >>> prefix and advertised upstream as a single prefix instead of >>> multiple host-based routes). >>> >>> Yours, >>> >>> Alex Petrescu >>> >>> Le 26/05/2015 22:34, Behcet Sarikaya a écrit : >>> >>> Hi Satoru, >>> >>> Thanks for your reply. >>> >>> Let me continue the discussion with your text in Section 3.2 >>> where you mention >>> vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) >>> that defines FPCP Agent function and Client function. >>> >>> I don't understand how you could justify defining a new forwarding >>> policy configuration protocol to do this Agent/Client functionality? >>> Why not use similar Agent/Client models that are being defined >>> rather >>> than defining a new protocol? >>> I think this point requires much stronger justification which I >>> could >>> not see in Section 3.2. >>> >>> Are you that we have to to reinvent the wheel, rather than reusing >>> something that is already available? How are we going to >>> reinvent that >>> wheel also remains to be seen, I think. >>> >>> Regards, >>> >>> Behcet >>> >>> >>> >>> On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima >>> >> > wrote: >>> >>> Hi Bechet-san, >>> >>> Thank you for your question. >>> In step (15), I meant that EPC-E advertises prefix including >>> UE assigned >>> prefixes. >>> >>> For example, in the case of /64 prefixes assigned to UEs >>> from a /56 space, >>> that /56 >>> is advertised by EPC-E to upstream routers. So the >>> advertised route isn't >>> host routes. >>> >>> Depends on configuration policy, but one case is that the >>> source of that >>> advertised >>> /56 route might be statically configured in EPC-E. >>> >>> Regards, >>> --satoru >>> >>> >>> >>> On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya >>> > >>> wrote: >>> >>> >>> Hi Matsushima-san, >>> >>> I have a question on your draft: >>> In Sec. 3.2, page 11, you say >>> In step (15), the EPC-E advertises routes to upstream >>> routers ... >>> >>> Are these routes static/host routes? >>> >>> Regards, >>> >>> Behcet >>> >>> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Jun 3 20:42:45 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF181B340E for ; Wed, 3 Jun 2015 20:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP6S8_sCHlMI for ; Wed, 3 Jun 2015 20:42:36 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 0F9381B339D for ; Wed, 3 Jun 2015 20:42:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t543gIM3032637; Wed, 3 Jun 2015 20:42:18 -0700 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t543gGCD032495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Jun 2015 20:42:16 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.197]) with mapi id 14.03.0235.001; Wed, 3 Jun 2015 20:42:16 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Satoru Matsushima Thread-Topic: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Thread-Index: AQHQmjkkJI//M3dql0O3DI0sVGxml52TQ0XQgAgjhoCAAFQrEA== Date: Thu, 4 Jun 2015 03:42:15 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> In-Reply-To: <556F1ECD.70801@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 03:42:42 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cnUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBXZWRuZXNkYXksIEp1bmUgMDMsIDIwMTUgODozNiBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBM OyBTYXRvcnUgTWF0c3VzaGltYQ0KPiBDYzogZG1tDQo+IFN1YmplY3Q6IFJlOiBbRE1NXSB2ZXBj IGRyYWZ0IFJldi4gMDQgLSAvNjJzIHRvIFVFLCBub3QgLzY0cw0KPiANCj4gTGUgMjkvMDUvMjAx NSAyMDoyMSwgVGVtcGxpbiwgRnJlZCBMIGEgw6ljcml0IDoNCj4gPiBIaSBBbGV4LA0KPiA+DQo+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGRtbSBbbWFpbHRvOmRt bS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJ1IFBldHJlc2N1DQo+ID4+ IFNlbnQ6IEZyaWRheSwgTWF5IDI5LCAyMDE1IDEwOjU5IEFNDQo+ID4+IFRvOiBTYXRvcnUgTWF0 c3VzaGltYQ0KPiA+PiBDYzogZG1tDQo+ID4+IFN1YmplY3Q6IFJlOiBbRE1NXSB2ZXBjIGRyYWZ0 IFJldi4gMDQgLSAvNjJzIHRvIFVFLCBub3QgLzY0cw0KPiA+Pg0KPiA+PiBMZSAyOS8wNS8yMDE1 IDE1OjMwLCBTYXRvcnUgTWF0c3VzaGltYSBhIMOpY3JpdCA6DQo+ID4+PiBBaCBPSy4gdGhhbmtz Lg0KPiA+Pj4gU2xpZ2h0bHkgb2ZmLXRvcGljLCBJIHRoaW5rIHRoYXQgdGhlcmUgaXMgc3RpbGwg Y2hhbmNlIGZvciB0ZXRoZXJpbmcNCj4gPj4+IHdpdGggc2luZ2xlIC82NCBpZiBpdCBpcyBhbGxv Y2F0ZWQgYXMgYSBvZmYtbGluayBwcmVmaXguDQo+ID4+DQo+ID4+IFllcywgdGhlcmUgaXMgc3Rp bGwgc3VjaCBhIGNoYW5jZS4gIEJ1dCBpdCBjYW4gbm90IHRldGhlciBtb3JlIHRoYW4gb25lDQo+ ID4+IHNpbmdsZSBzdWJuZXQuICBDb25uZWN0ZWQgdmVoaWNsZXMgbmVlZCBzZXZlcmFsIHN1Ym5l dHMuDQo+ID4NCj4gPiBIb3cgd291bGQgaXQgYmUgaWYgdGhlIHZlaGljbGUgcmVjZWl2ZWQgYSBz aW5nbGUgcHJlZml4LCBidXQgaXQgY291bGQgYmUNCj4gPiBzaG9ydGVyIHRoYW4gLzY0IChlLmcu LCAvNTYsIC80OC4gZXRjLik/IFdvdWxkIHRoZSB2ZWhpY2xlIHN1Ym5ldHRpbmcNCj4gPiBiZSBz YXRpc2ZpZWQgaWYgaXQgcmVjZWl2ZWQgYSBzaG9ydGVyIHByZWZpeCBmcm9tIHdoaWNoIG1hbnkg LzY0cw0KPiA+IGNvdWxkIGJlIGFsbG9jYXRlZD8NCj4gDQo+IENlcnRhaW5seSB5ZXMuDQo+IA0K PiBFYWNoIHZlaGljbGUgbmVlZHMgc3VjaCBhIHNob3J0ZXItdGhhbi02NCBwcmVmaXggYWxsb2Nh dGVkIHRvIGl0Lg0KPiANCj4gRm9yIGV4YW1wbGUsIGFuIGF1dG9tb2JpbGUgY29ubmVjdGluZyB0 byBMVEUgcmVjZWl2ZXMgYSAvNjIgZnJvbSB0aGUNCj4gb3BlcmF0b3IgYW5kIG1ha2VzIGZvdXIg LzY0cyBvdXQgb2YgaXQ6IG9uZSBmb3IgaXRzIENBTi1lbnRlcnRhaW5tZW50LA0KPiBvbmUgZm9y IGl0cyBDQU4tc2FmZXR5LCBvbmUgZm9yIGl0cyBXaUZpIGFuZCBvbmUgZm9yIGl0cyBCbHVldG9v dGguDQo+IA0KPiBUaGlzIGlzIGEgTVVTVC4NCj4gDQo+IEFsbG9jYXRpbmcgYSBzaW5nbGUgLzY0 IHRvIGEgdmVoaWNsZSBjYW4gbm90IGFjY29tbW9kYXRlIGFsbCB0aGVzZQ0KPiB1bmJyaWRnZWFi bGUgc3VibmV0cy4NCg0KT0ssIHRoYXQgaXMgZ29vZC4gR2l2aW5nIGEgbW9iaWxlIHJvdXRlciBz b21ldGhpbmcgc2hvcnRlciB0aGFuIC82NA0Kc2hvdWxkIGJlIG5vIHByb2JsZW0sIGF0IGxlYXN0 IHVwIHRvIHByYWN0aWNhbCBsaW1pdGF0aW9ucyBvZiB0aGUgcHJlZml4DQpkZWxlZ2F0aW9uIGF1 dGhvcml0eSdzIGF2YWlsYWJsZSBwcmVmaXggc3BhY2UuIERIQ1B2NiBQRCBwcm92aWRlcyBhbGwN CnRoYXQgaXMgbmVlZGVkIHRvIGdpdmUgb3V0IHJpZ2h0LXNpemVkIHByZWZpeGVzLg0KDQpUaGFu a3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQogDQo+IA0KPiBBbGV4DQo+IA0K PiA+DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4g Pg0KPiA+DQo+ID4+DQo+ID4+IEFsZXgNCj4gPj4NCj4gPj4+DQo+ID4+PiBCdXQgeWVzLCBJIGFn cmVlIHdpdGggeW91Lg0KPiA+Pj4NCj4gPj4+IGNoZWVycywNCj4gPj4+IC0tc2F0b3J1DQo+ID4+ Pg0KPiA+Pj4gT24gV2VkLCBNYXkgMjcsIDIwMTUgYXQgODozMSBQTSwgQWxleGFuZHJ1IFBldHJl c2N1DQo+ID4+PiA8YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbSA8bWFpbHRvOmFsZXhhbmRy dS5wZXRyZXNjdUBnbWFpbC5jb20+PiB3cm90ZToNCj4gPj4+DQo+ID4+PiAgICAgIEhpLA0KPiA+ Pj4NCj4gPj4+ICAgICAgSW4gYWRkaXRpb24gdG8gd2hhdCBCZWhjZXQgc2F5cy4NCj4gPj4+DQo+ ID4+PiAgICAgIEkgcmVhZCB0aGUgZXhhbXBsZSBiZWxvdy4gIEkgdGhpbmsgaXQgaXMganVzdCBh biBleGFtcGxlLCBidXQganVzdA0KPiA+Pj4gICAgICB0byBtYWtlIHN1cmUuDQo+ID4+Pg0KPiA+ Pj4gICAgICBQbGVhc2UgLSBkbyBub3QgYWxsb2NhdGUgLzY0cyB0byBlbmQgdXNlcnMgaW4gYSBj ZWxsdWxhciBuZXR3b3JrLg0KPiA+Pj4gICAgICBBbGxvY2F0ZSBhdCBsZWFzdCAvNjJzIHRvIGVu ZCB1c2Vycy4NCj4gPj4+DQo+ID4+PiAgICAgIFRoaXMgaXMgdG8gYWxsb3cgdGhlIHNtYXJ0cGhv bmUgdG8gcGVyZm9ybSB0ZXRoZXJpbmcgKHNtYWxsIG5ldHdvcmsNCj4gPj4+ICAgICAgb2Ygd2lm aSBkZXZpY2VzIGNvbm5lY3RpbmcgdGhyb3VnaCB0aGUgc21hcnRwaG9uZSB0byB0aGUgSW50ZXJu ZXQpLg0KPiA+Pj4NCj4gPj4+ICAgICAgVGhlIGFzc3VtcHRpb24gb2YgLzY0IHRvIGVuZCB1c2Vy IGlzIG5vdCBnb29kIGF0IGFsbC4NCj4gPj4+DQo+ID4+PiAgICAgIChhbmQgeWVzLCBJIGFncmVl IHRoYXQgdGhlc2UgLzYycyBtYXkgYmUgYWdncmVnYXRlZCBpbnRvIGEgbGFyZ2VyDQo+ID4+PiAg ICAgIHByZWZpeCBhbmQgYWR2ZXJ0aXNlZCB1cHN0cmVhbSBhcyBhIHNpbmdsZSBwcmVmaXggaW5z dGVhZCBvZg0KPiA+Pj4gICAgICBtdWx0aXBsZSBob3N0LWJhc2VkIHJvdXRlcykuDQo+ID4+Pg0K PiA+Pj4gICAgICBZb3VycywNCj4gPj4+DQo+ID4+PiAgICAgIEFsZXggUGV0cmVzY3UNCj4gPj4+ DQo+ID4+PiAgICAgIExlIDI2LzA1LzIwMTUgMjI6MzQsIEJlaGNldCBTYXJpa2F5YSBhIMOpY3Jp dCA6DQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgSGkgU2F0b3J1LA0KPiA+Pj4NCj4gPj4+ICAgICAg ICAgIFRoYW5rcyBmb3IgeW91ciByZXBseS4NCj4gPj4+DQo+ID4+PiAgICAgICAgICBMZXQgbWUg Y29udGludWUgdGhlIGRpc2N1c3Npb24gd2l0aCB5b3VyIHRleHQgaW4gU2VjdGlvbiAzLjINCj4g Pj4+ICAgICAgICAgIHdoZXJlIHlvdSBtZW50aW9uDQo+ID4+PiAgICAgICAgICB2RVBDIG1heSB1 dGlsaXplcyBGb3J3YXJkaW5nIFBvbGljeSBDb25maWd1cmF0aW9uIFByb3RvY29sIChGUENQKQ0K PiA+Pj4gICAgICAgICAgdGhhdCBkZWZpbmVzIEZQQ1AgQWdlbnQgZnVuY3Rpb24gYW5kIENsaWVu dCBmdW5jdGlvbi4NCj4gPj4+DQo+ID4+PiAgICAgICAgICBJIGRvbid0IHVuZGVyc3RhbmQgaG93 IHlvdSBjb3VsZCBqdXN0aWZ5IGRlZmluaW5nIGEgbmV3IGZvcndhcmRpbmcNCj4gPj4+ICAgICAg ICAgIHBvbGljeSBjb25maWd1cmF0aW9uIHByb3RvY29sIHRvIGRvIHRoaXMgQWdlbnQvQ2xpZW50 IGZ1bmN0aW9uYWxpdHk/DQo+ID4+PiAgICAgICAgICBXaHkgbm90IHVzZSBzaW1pbGFyIEFnZW50 L0NsaWVudCBtb2RlbHMgdGhhdCBhcmUgYmVpbmcgZGVmaW5lZA0KPiA+Pj4gICAgICAgICAgcmF0 aGVyDQo+ID4+PiAgICAgICAgICB0aGFuIGRlZmluaW5nIGEgbmV3IHByb3RvY29sPw0KPiA+Pj4g ICAgICAgICAgSSB0aGluayB0aGlzIHBvaW50IHJlcXVpcmVzIG11Y2ggc3Ryb25nZXIganVzdGlm aWNhdGlvbiB3aGljaCBJDQo+ID4+PiAgICAgICAgICBjb3VsZA0KPiA+Pj4gICAgICAgICAgbm90 IHNlZSBpbiBTZWN0aW9uIDMuMi4NCj4gPj4+DQo+ID4+PiAgICAgICAgICBBcmUgeW91IHRoYXQg d2UgaGF2ZSB0byB0byByZWludmVudCB0aGUgd2hlZWwsIHJhdGhlciB0aGFuIHJldXNpbmcNCj4g Pj4+ICAgICAgICAgIHNvbWV0aGluZyB0aGF0IGlzIGFscmVhZHkgYXZhaWxhYmxlPyBIb3cgYXJl IHdlIGdvaW5nIHRvDQo+ID4+PiAgICAgICAgICByZWludmVudCB0aGF0DQo+ID4+PiAgICAgICAg ICB3aGVlbCBhbHNvIHJlbWFpbnMgdG8gYmUgc2VlbiwgSSB0aGluay4NCj4gPj4+DQo+ID4+PiAg ICAgICAgICBSZWdhcmRzLA0KPiA+Pj4NCj4gPj4+ICAgICAgICAgIEJlaGNldA0KPiA+Pj4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgT24gU2F0LCBNYXkgMTYsIDIwMTUgYXQgODowMSBB TSwgU2F0b3J1IE1hdHN1c2hpbWENCj4gPj4+ICAgICAgICAgIDxzYXRvcnUubWF0c3VzaGltYUBn bWFpbC5jb20NCj4gPj4+ICAgICAgICAgIDxtYWlsdG86c2F0b3J1Lm1hdHN1c2hpbWFAZ21haWwu Y29tPj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgICAgIEhpIEJlY2hldC1zYW4sDQo+ ID4+Pg0KPiA+Pj4gICAgICAgICAgICAgIFRoYW5rIHlvdSBmb3IgeW91ciBxdWVzdGlvbi4NCj4g Pj4+ICAgICAgICAgICAgICBJbiBzdGVwICgxNSksIEkgbWVhbnQgdGhhdCBFUEMtRSBhZHZlcnRp c2VzIHByZWZpeCBpbmNsdWRpbmcNCj4gPj4+ICAgICAgICAgICAgICBVRSBhc3NpZ25lZA0KPiA+ Pj4gICAgICAgICAgICAgIHByZWZpeGVzLg0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICAgICBGb3Ig ZXhhbXBsZSwgaW4gdGhlIGNhc2Ugb2YgLzY0IHByZWZpeGVzIGFzc2lnbmVkIHRvIFVFcw0KPiA+ Pj4gICAgICAgICAgICAgIGZyb20gYSAvNTYgc3BhY2UsDQo+ID4+PiAgICAgICAgICAgICAgdGhh dCAvNTYNCj4gPj4+ICAgICAgICAgICAgICBpcyBhZHZlcnRpc2VkIGJ5IEVQQy1FIHRvIHVwc3Ry ZWFtIHJvdXRlcnMuIFNvIHRoZQ0KPiA+Pj4gICAgICAgICAgICAgIGFkdmVydGlzZWQgcm91dGUg aXNuJ3QNCj4gPj4+ICAgICAgICAgICAgICBob3N0IHJvdXRlcy4NCj4gPj4+DQo+ID4+PiAgICAg ICAgICAgICAgRGVwZW5kcyBvbiBjb25maWd1cmF0aW9uIHBvbGljeSwgYnV0IG9uZSBjYXNlIGlz IHRoYXQgdGhlDQo+ID4+PiAgICAgICAgICAgICAgc291cmNlIG9mIHRoYXQNCj4gPj4+ICAgICAg ICAgICAgICBhZHZlcnRpc2VkDQo+ID4+PiAgICAgICAgICAgICAgLzU2IHJvdXRlIG1pZ2h0IGJl IHN0YXRpY2FsbHkgY29uZmlndXJlZCBpbiBFUEMtRS4NCj4gPj4+DQo+ID4+PiAgICAgICAgICAg ICAgUmVnYXJkcywNCj4gPj4+ICAgICAgICAgICAgICAtLXNhdG9ydQ0KPiA+Pj4NCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4gICAgICAgICAgICAgIE9uIFdlZCwgTWF5IDEzLCAyMDE1IGF0IDQ6NTEgQU0s IEJlaGNldCBTYXJpa2F5YQ0KPiA+Pj4gICAgICAgICAgICAgIDxzYXJpa2F5YTIwMTJAZ21haWwu Y29tIDxtYWlsdG86c2FyaWtheWEyMDEyQGdtYWlsLmNvbT4+DQo+ID4+PiAgICAgICAgICAgICAg d3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICAgICAgICAgICAgSGkgTWF0c3Vz aGltYS1zYW4sDQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgICAgICAgICBJIGhhdmUgYSBxdWVzdGlv biBvbiB5b3VyIGRyYWZ0Og0KPiA+Pj4gICAgICAgICAgICAgICAgICBJbiBTZWMuIDMuMiwgcGFn ZSAxMSwgeW91IHNheQ0KPiA+Pj4gICAgICAgICAgICAgICAgICBJbiBzdGVwICgxNSksIHRoZSBF UEMtRSBhZHZlcnRpc2VzIHJvdXRlcyB0byB1cHN0cmVhbQ0KPiA+Pj4gICAgICAgICAgICAgICAg ICByb3V0ZXJzIC4uLg0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICAgICAgICAgQXJlIHRoZXNlIHJv dXRlcyBzdGF0aWMvaG9zdCByb3V0ZXM/DQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgICAgICAgICBS ZWdhcmRzLA0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICAgICAgICAgQmVoY2V0DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ICAgICAgICAgIGRtbSBtYWlsaW5nIGxpc3QN Cj4gPj4+ICAgICAgICAgIGRtbUBpZXRmLm9yZyA8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCj4gPj4+ ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gICAgICBkbW0gbWFpbGluZyBsaXN0DQo+ ID4+PiAgICAgIGRtbUBpZXRmLm9yZyA8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCj4gPj4+ICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4gPj4+DQo+ID4+Pg0K PiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+PiBkbW0gbWFpbGluZyBsaXN0DQo+ID4+IGRtbUBpZXRmLm9yZw0KPiA+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPiANCg0K From nobody Thu Jun 4 07:08:50 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8931A8853 for ; Thu, 4 Jun 2015 07:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NizchZVCP-c2 for ; Thu, 4 Jun 2015 07:08:46 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40811B34E5 for ; Thu, 4 Jun 2015 07:08:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t54E8dkP005689; Thu, 4 Jun 2015 16:08:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A9C4520902A; Thu, 4 Jun 2015 16:11:06 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9B135208FFB; Thu, 4 Jun 2015 16:11:06 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t54E8cBu021228; Thu, 4 Jun 2015 16:08:39 +0200 Message-ID: <55705BE6.50205@gmail.com> Date: Thu, 04 Jun 2015 16:08:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , Satoru Matsushima References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 14:08:49 -0000 Le 04/06/2015 05:42, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Wednesday, June 03, 2015 8:36 AM >> To: Templin, Fred L; Satoru Matsushima >> Cc: dmm >> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >> >> Le 29/05/2015 20:21, Templin, Fred L a écrit : >>> Hi Alex, >>> >>>> -----Original Message----- >>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: Friday, May 29, 2015 10:59 AM >>>> To: Satoru Matsushima >>>> Cc: dmm >>>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >>>> >>>> Le 29/05/2015 15:30, Satoru Matsushima a écrit : >>>>> Ah OK. thanks. >>>>> Slightly off-topic, I think that there is still chance for tethering >>>>> with single /64 if it is allocated as a off-link prefix. >>>> >>>> Yes, there is still such a chance. But it can not tether more than one >>>> single subnet. Connected vehicles need several subnets. >>> >>> How would it be if the vehicle received a single prefix, but it could be >>> shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting >>> be satisfied if it received a shorter prefix from which many /64s >>> could be allocated? >> >> Certainly yes. >> >> Each vehicle needs such a shorter-than-64 prefix allocated to it. >> >> For example, an automobile connecting to LTE receives a /62 from the >> operator and makes four /64s out of it: one for its CAN-entertainment, >> one for its CAN-safety, one for its WiFi and one for its Bluetooth. >> >> This is a MUST. >> >> Allocating a single /64 to a vehicle can not accommodate all these >> unbridgeable subnets. > > OK, that is good. Giving a mobile router something shorter than /64 > should be no problem, at least up to practical limitations of the prefix > delegation authority's available prefix space. DHCPv6 PD provides all > that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. Alex > > Thanks - Fred > fred.l.templin@boeing.com > >> >> Alex >> >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>> >>>> >>>> Alex >>>> >>>>> >>>>> But yes, I agree with you. >>>>> >>>>> cheers, >>>>> --satoru >>>>> >>>>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu >>>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> In addition to what Behcet says. >>>>> >>>>> I read the example below. I think it is just an example, but just >>>>> to make sure. >>>>> >>>>> Please - do not allocate /64s to end users in a cellular network. >>>>> Allocate at least /62s to end users. >>>>> >>>>> This is to allow the smartphone to perform tethering (small network >>>>> of wifi devices connecting through the smartphone to the Internet). >>>>> >>>>> The assumption of /64 to end user is not good at all. >>>>> >>>>> (and yes, I agree that these /62s may be aggregated into a larger >>>>> prefix and advertised upstream as a single prefix instead of >>>>> multiple host-based routes). >>>>> >>>>> Yours, >>>>> >>>>> Alex Petrescu >>>>> >>>>> Le 26/05/2015 22:34, Behcet Sarikaya a écrit : >>>>> >>>>> Hi Satoru, >>>>> >>>>> Thanks for your reply. >>>>> >>>>> Let me continue the discussion with your text in Section 3.2 >>>>> where you mention >>>>> vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) >>>>> that defines FPCP Agent function and Client function. >>>>> >>>>> I don't understand how you could justify defining a new forwarding >>>>> policy configuration protocol to do this Agent/Client functionality? >>>>> Why not use similar Agent/Client models that are being defined >>>>> rather >>>>> than defining a new protocol? >>>>> I think this point requires much stronger justification which I >>>>> could >>>>> not see in Section 3.2. >>>>> >>>>> Are you that we have to to reinvent the wheel, rather than reusing >>>>> something that is already available? How are we going to >>>>> reinvent that >>>>> wheel also remains to be seen, I think. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> >>>>> >>>>> On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima >>>>> >>>> > wrote: >>>>> >>>>> Hi Bechet-san, >>>>> >>>>> Thank you for your question. >>>>> In step (15), I meant that EPC-E advertises prefix including >>>>> UE assigned >>>>> prefixes. >>>>> >>>>> For example, in the case of /64 prefixes assigned to UEs >>>>> from a /56 space, >>>>> that /56 >>>>> is advertised by EPC-E to upstream routers. So the >>>>> advertised route isn't >>>>> host routes. >>>>> >>>>> Depends on configuration policy, but one case is that the >>>>> source of that >>>>> advertised >>>>> /56 route might be statically configured in EPC-E. >>>>> >>>>> Regards, >>>>> --satoru >>>>> >>>>> >>>>> >>>>> On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> Hi Matsushima-san, >>>>> >>>>> I have a question on your draft: >>>>> In Sec. 3.2, page 11, you say >>>>> In step (15), the EPC-E advertises routes to upstream >>>>> routers ... >>>>> >>>>> Are these routes static/host routes? >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >> > From nobody Thu Jun 4 08:10:25 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EB31B33CC for ; Thu, 4 Jun 2015 08:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKvbRfIQllUi for ; Thu, 4 Jun 2015 08:10:21 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EDC1B32FE for ; Thu, 4 Jun 2015 08:10:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t54FALHj028230; Thu, 4 Jun 2015 08:10:21 -0700 Received: from XCH-BLV-406.nw.nos.boeing.com (xch-blv-406.nw.nos.boeing.com [130.247.25.162]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t54FAFnP028183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 4 Jun 2015 08:10:15 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.216]) with mapi id 14.03.0235.001; Thu, 4 Jun 2015 08:10:15 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Satoru Matsushima Thread-Topic: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Thread-Index: AQHQmjkkJI//M3dql0O3DI0sVGxml52TQ0XQgAgjhoCAAFQrEIABJdgA//+aLYA= Date: Thu, 4 Jun 2015 15:10:14 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E827AF@XCH-BLV-504.nw.nos.boeing.com> References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> In-Reply-To: <55705BE6.50205@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 15:10:24 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cnUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBUaHVyc2RheSwgSnVuZSAwNCwgMjAxNSA3OjA5IEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEw7 IFNhdG9ydSBNYXRzdXNoaW1hDQo+IENjOiBkbW0NCj4gU3ViamVjdDogUmU6IFtETU1dIHZlcGMg ZHJhZnQgUmV2LiAwNCAtIC82MnMgdG8gVUUsIG5vdCAvNjRzDQo+IA0KPiBMZSAwNC8wNi8yMDE1 IDA1OjQyLCBUZW1wbGluLCBGcmVkIEwgYSDDqWNyaXQgOg0KPiA+IEhpIEFsZXgsDQo+ID4NCj4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQWxleGFuZHJ1IFBldHJl c2N1IFttYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbV0NCj4gPj4gU2VudDogV2Vk bmVzZGF5LCBKdW5lIDAzLCAyMDE1IDg6MzYgQU0NCj4gPj4gVG86IFRlbXBsaW4sIEZyZWQgTDsg U2F0b3J1IE1hdHN1c2hpbWENCj4gPj4gQ2M6IGRtbQ0KPiA+PiBTdWJqZWN0OiBSZTogW0RNTV0g dmVwYyBkcmFmdCBSZXYuIDA0IC0gLzYycyB0byBVRSwgbm90IC82NHMNCj4gPj4NCj4gPj4gTGUg MjkvMDUvMjAxNSAyMDoyMSwgVGVtcGxpbiwgRnJlZCBMIGEgw6ljcml0IDoNCj4gPj4+IEhpIEFs ZXgsDQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJv bTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5k cnUgUGV0cmVzY3UNCj4gPj4+PiBTZW50OiBGcmlkYXksIE1heSAyOSwgMjAxNSAxMDo1OSBBTQ0K PiA+Pj4+IFRvOiBTYXRvcnUgTWF0c3VzaGltYQ0KPiA+Pj4+IENjOiBkbW0NCj4gPj4+PiBTdWJq ZWN0OiBSZTogW0RNTV0gdmVwYyBkcmFmdCBSZXYuIDA0IC0gLzYycyB0byBVRSwgbm90IC82NHMN Cj4gPj4+Pg0KPiA+Pj4+IExlIDI5LzA1LzIwMTUgMTU6MzAsIFNhdG9ydSBNYXRzdXNoaW1hIGEg w6ljcml0IDoNCj4gPj4+Pj4gQWggT0suIHRoYW5rcy4NCj4gPj4+Pj4gU2xpZ2h0bHkgb2ZmLXRv cGljLCBJIHRoaW5rIHRoYXQgdGhlcmUgaXMgc3RpbGwgY2hhbmNlIGZvciB0ZXRoZXJpbmcNCj4g Pj4+Pj4gd2l0aCBzaW5nbGUgLzY0IGlmIGl0IGlzIGFsbG9jYXRlZCBhcyBhIG9mZi1saW5rIHBy ZWZpeC4NCj4gPj4+Pg0KPiA+Pj4+IFllcywgdGhlcmUgaXMgc3RpbGwgc3VjaCBhIGNoYW5jZS4g IEJ1dCBpdCBjYW4gbm90IHRldGhlciBtb3JlIHRoYW4gb25lDQo+ID4+Pj4gc2luZ2xlIHN1Ym5l dC4gIENvbm5lY3RlZCB2ZWhpY2xlcyBuZWVkIHNldmVyYWwgc3VibmV0cy4NCj4gPj4+DQo+ID4+ PiBIb3cgd291bGQgaXQgYmUgaWYgdGhlIHZlaGljbGUgcmVjZWl2ZWQgYSBzaW5nbGUgcHJlZml4 LCBidXQgaXQgY291bGQgYmUNCj4gPj4+IHNob3J0ZXIgdGhhbiAvNjQgKGUuZy4sIC81NiwgLzQ4 LiBldGMuKT8gV291bGQgdGhlIHZlaGljbGUgc3VibmV0dGluZw0KPiA+Pj4gYmUgc2F0aXNmaWVk IGlmIGl0IHJlY2VpdmVkIGEgc2hvcnRlciBwcmVmaXggZnJvbSB3aGljaCBtYW55IC82NHMNCj4g Pj4+IGNvdWxkIGJlIGFsbG9jYXRlZD8NCj4gPj4NCj4gPj4gQ2VydGFpbmx5IHllcy4NCj4gPj4N Cj4gPj4gRWFjaCB2ZWhpY2xlIG5lZWRzIHN1Y2ggYSBzaG9ydGVyLXRoYW4tNjQgcHJlZml4IGFs bG9jYXRlZCB0byBpdC4NCj4gPj4NCj4gPj4gRm9yIGV4YW1wbGUsIGFuIGF1dG9tb2JpbGUgY29u bmVjdGluZyB0byBMVEUgcmVjZWl2ZXMgYSAvNjIgZnJvbSB0aGUNCj4gPj4gb3BlcmF0b3IgYW5k IG1ha2VzIGZvdXIgLzY0cyBvdXQgb2YgaXQ6IG9uZSBmb3IgaXRzIENBTi1lbnRlcnRhaW5tZW50 LA0KPiA+PiBvbmUgZm9yIGl0cyBDQU4tc2FmZXR5LCBvbmUgZm9yIGl0cyBXaUZpIGFuZCBvbmUg Zm9yIGl0cyBCbHVldG9vdGguDQo+ID4+DQo+ID4+IFRoaXMgaXMgYSBNVVNULg0KPiA+Pg0KPiA+ PiBBbGxvY2F0aW5nIGEgc2luZ2xlIC82NCB0byBhIHZlaGljbGUgY2FuIG5vdCBhY2NvbW1vZGF0 ZSBhbGwgdGhlc2UNCj4gPj4gdW5icmlkZ2VhYmxlIHN1Ym5ldHMuDQo+ID4NCj4gPiBPSywgdGhh dCBpcyBnb29kLiBHaXZpbmcgYSBtb2JpbGUgcm91dGVyIHNvbWV0aGluZyBzaG9ydGVyIHRoYW4g LzY0DQo+ID4gc2hvdWxkIGJlIG5vIHByb2JsZW0sIGF0IGxlYXN0IHVwIHRvIHByYWN0aWNhbCBs aW1pdGF0aW9ucyBvZiB0aGUgcHJlZml4DQo+ID4gZGVsZWdhdGlvbiBhdXRob3JpdHkncyBhdmFp bGFibGUgcHJlZml4IHNwYWNlLiBESENQdjYgUEQgcHJvdmlkZXMgYWxsDQo+ID4gdGhhdCBpcyBu ZWVkZWQgdG8gZ2l2ZSBvdXQgcmlnaHQtc2l6ZWQgcHJlZml4ZXMuDQo+IA0KPiBJIGFncmVlIERI Q1AtUEQgcHJvdmlkZXMgdGhlIG5lY2Vzc2FyeSB0b29sLiAgQnV0IHVuZm9ydHVuYXRlbHkgdGhl DQo+IGNlbGx1bGFyIG9wZXJhdG9ycyBoYXZlIG5vdCBkZXBsb3llZCBESENQdjYtUEQgKGFsdGhv dWdoIHllcyB0aGVyZSBpcw0KPiBzb21lIERIQ1Atbm9uLVBEIGluIHNvbWUgSVB2Ni80RyBkZXBs b3ltZW50cykuDQoNClRoYXQgaXMgYSBwaXR5LCBiZWNhdXNlIERIQ1B2NiBQRCAoYWxvbmcgd2l0 aCBJUHY2IE5EIGFuZCBCR1ApIGFyZSBhbGwNCnRoYXQgYXJlIG5lY2Vzc2FyeSBmb3IgZGlzdHJp YnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVudC4NCg0KPiBUaGUgY29tbW9uIHRoaW5raW5nIGF0IG9w ZXJhdG9ycyBhbmQgYWR2aXNlcnMgaXMgc3RpbGwgdGhhdCBhIC82NCBzaG91bGQNCj4gYmUgZ2l2 ZW4gdG8gYW4gVXNlciBFcXVpcG1lbnQuDQo+IA0KPiBUaGlzIG11c3QgY2hhbmdlOiB0aGUgM0dQ UCBzcGVjcyBhbmQgb3BlcmF0b3IgZGVwbG95bWVudHMgbXVzdCBnaXZlIC82Mg0KPiB0byBVRXMs IGFuZCBub3QgLzY0Lg0KDQpXaHkgbm90IGEgL04gaW5zdGVhZCBvZiBqdXN0IGEgLzYyIG9yIC82 ND8gTiBjb3VsZCBiZSBhbnl0aGluZyAoNjIsIDYwLCA1NiwNCjQ4LCBldGMuKSBhcyBsb25nIGFz IGl0IGlzIGEgcHJvcGVyIHN1YnNldCBvZiB0aGUgcHJlZml4IHNwYWNlIHRoZSBvcGVyYXRvciBo YXMNCmF2YWlsYWJsZSBmb3IgZGVsZWdhdGlvbi4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRl bXBsaW5AYm9laW5nLmNvbQ0KDQo+IEFsZXgNCj4gDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ ID4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+ID4+DQo+ID4+IEFsZXgNCj4gPj4N Cj4gPj4+DQo+ID4+PiBUaGFua3MgLSBGcmVkDQo+ID4+PiBmcmVkLmwudGVtcGxpbkBib2Vpbmcu Y29tDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+IEFsZXgNCj4gPj4+Pg0KPiA+Pj4+Pg0K PiA+Pj4+PiBCdXQgeWVzLCBJIGFncmVlIHdpdGggeW91Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBjaGVl cnMsDQo+ID4+Pj4+IC0tc2F0b3J1DQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIFdlZCwgTWF5IDI3LCAy MDE1IGF0IDg6MzEgUE0sIEFsZXhhbmRydSBQZXRyZXNjdQ0KPiA+Pj4+PiA8YWxleGFuZHJ1LnBl dHJlc2N1QGdtYWlsLmNvbSA8bWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20+PiB3 cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgSGksDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAg IEluIGFkZGl0aW9uIHRvIHdoYXQgQmVoY2V0IHNheXMuDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAg IEkgcmVhZCB0aGUgZXhhbXBsZSBiZWxvdy4gIEkgdGhpbmsgaXQgaXMganVzdCBhbiBleGFtcGxl LCBidXQganVzdA0KPiA+Pj4+PiAgICAgICB0byBtYWtlIHN1cmUuDQo+ID4+Pj4+DQo+ID4+Pj4+ ICAgICAgIFBsZWFzZSAtIGRvIG5vdCBhbGxvY2F0ZSAvNjRzIHRvIGVuZCB1c2VycyBpbiBhIGNl bGx1bGFyIG5ldHdvcmsuDQo+ID4+Pj4+ICAgICAgIEFsbG9jYXRlIGF0IGxlYXN0IC82MnMgdG8g ZW5kIHVzZXJzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBUaGlzIGlzIHRvIGFsbG93IHRoZSBz bWFydHBob25lIHRvIHBlcmZvcm0gdGV0aGVyaW5nIChzbWFsbCBuZXR3b3JrDQo+ID4+Pj4+ICAg ICAgIG9mIHdpZmkgZGV2aWNlcyBjb25uZWN0aW5nIHRocm91Z2ggdGhlIHNtYXJ0cGhvbmUgdG8g dGhlIEludGVybmV0KS4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgVGhlIGFzc3VtcHRpb24gb2Yg LzY0IHRvIGVuZCB1c2VyIGlzIG5vdCBnb29kIGF0IGFsbC4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAg ICAgKGFuZCB5ZXMsIEkgYWdyZWUgdGhhdCB0aGVzZSAvNjJzIG1heSBiZSBhZ2dyZWdhdGVkIGlu dG8gYSBsYXJnZXINCj4gPj4+Pj4gICAgICAgcHJlZml4IGFuZCBhZHZlcnRpc2VkIHVwc3RyZWFt IGFzIGEgc2luZ2xlIHByZWZpeCBpbnN0ZWFkIG9mDQo+ID4+Pj4+ICAgICAgIG11bHRpcGxlIGhv c3QtYmFzZWQgcm91dGVzKS4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgWW91cnMsDQo+ID4+Pj4+ DQo+ID4+Pj4+ICAgICAgIEFsZXggUGV0cmVzY3UNCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgTGUg MjYvMDUvMjAxNSAyMjozNCwgQmVoY2V0IFNhcmlrYXlhIGEgw6ljcml0IDoNCj4gPj4+Pj4NCj4g Pj4+Pj4gICAgICAgICAgIEhpIFNhdG9ydSwNCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgICAgIFRo YW5rcyBmb3IgeW91ciByZXBseS4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgICAgIExldCBtZSBj b250aW51ZSB0aGUgZGlzY3Vzc2lvbiB3aXRoIHlvdXIgdGV4dCBpbiBTZWN0aW9uIDMuMg0KPiA+ Pj4+PiAgICAgICAgICAgd2hlcmUgeW91IG1lbnRpb24NCj4gPj4+Pj4gICAgICAgICAgIHZFUEMg bWF5IHV0aWxpemVzIEZvcndhcmRpbmcgUG9saWN5IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKEZQ Q1ApDQo+ID4+Pj4+ICAgICAgICAgICB0aGF0IGRlZmluZXMgRlBDUCBBZ2VudCBmdW5jdGlvbiBh bmQgQ2xpZW50IGZ1bmN0aW9uLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAgSSBkb24ndCB1 bmRlcnN0YW5kIGhvdyB5b3UgY291bGQganVzdGlmeSBkZWZpbmluZyBhIG5ldyBmb3J3YXJkaW5n DQo+ID4+Pj4+ICAgICAgICAgICBwb2xpY3kgY29uZmlndXJhdGlvbiBwcm90b2NvbCB0byBkbyB0 aGlzIEFnZW50L0NsaWVudCBmdW5jdGlvbmFsaXR5Pw0KPiA+Pj4+PiAgICAgICAgICAgV2h5IG5v dCB1c2Ugc2ltaWxhciBBZ2VudC9DbGllbnQgbW9kZWxzIHRoYXQgYXJlIGJlaW5nIGRlZmluZWQN Cj4gPj4+Pj4gICAgICAgICAgIHJhdGhlcg0KPiA+Pj4+PiAgICAgICAgICAgdGhhbiBkZWZpbmlu ZyBhIG5ldyBwcm90b2NvbD8NCj4gPj4+Pj4gICAgICAgICAgIEkgdGhpbmsgdGhpcyBwb2ludCBy ZXF1aXJlcyBtdWNoIHN0cm9uZ2VyIGp1c3RpZmljYXRpb24gd2hpY2ggSQ0KPiA+Pj4+PiAgICAg ICAgICAgY291bGQNCj4gPj4+Pj4gICAgICAgICAgIG5vdCBzZWUgaW4gU2VjdGlvbiAzLjIuDQo+ ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICBBcmUgeW91IHRoYXQgd2UgaGF2ZSB0byB0byByZWlu dmVudCB0aGUgd2hlZWwsIHJhdGhlciB0aGFuIHJldXNpbmcNCj4gPj4+Pj4gICAgICAgICAgIHNv bWV0aGluZyB0aGF0IGlzIGFscmVhZHkgYXZhaWxhYmxlPyBIb3cgYXJlIHdlIGdvaW5nIHRvDQo+ ID4+Pj4+ICAgICAgICAgICByZWludmVudCB0aGF0DQo+ID4+Pj4+ICAgICAgICAgICB3aGVlbCBh bHNvIHJlbWFpbnMgdG8gYmUgc2VlbiwgSSB0aGluay4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAg ICAgIFJlZ2FyZHMsDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICBCZWhjZXQNCj4gPj4+Pj4N Cj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgICAgIE9uIFNhdCwgTWF5IDE2LCAyMDE1 IGF0IDg6MDEgQU0sIFNhdG9ydSBNYXRzdXNoaW1hDQo+ID4+Pj4+ICAgICAgICAgICA8c2F0b3J1 Lm1hdHN1c2hpbWFAZ21haWwuY29tDQo+ID4+Pj4+ICAgICAgICAgICA8bWFpbHRvOnNhdG9ydS5t YXRzdXNoaW1hQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAg ICAgIEhpIEJlY2hldC1zYW4sDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICAgICAgVGhhbmsg eW91IGZvciB5b3VyIHF1ZXN0aW9uLg0KPiA+Pj4+PiAgICAgICAgICAgICAgIEluIHN0ZXAgKDE1 KSwgSSBtZWFudCB0aGF0IEVQQy1FIGFkdmVydGlzZXMgcHJlZml4IGluY2x1ZGluZw0KPiA+Pj4+ PiAgICAgICAgICAgICAgIFVFIGFzc2lnbmVkDQo+ID4+Pj4+ICAgICAgICAgICAgICAgcHJlZml4 ZXMuDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIGluIHRoZSBj YXNlIG9mIC82NCBwcmVmaXhlcyBhc3NpZ25lZCB0byBVRXMNCj4gPj4+Pj4gICAgICAgICAgICAg ICBmcm9tIGEgLzU2IHNwYWNlLA0KPiA+Pj4+PiAgICAgICAgICAgICAgIHRoYXQgLzU2DQo+ID4+ Pj4+ICAgICAgICAgICAgICAgaXMgYWR2ZXJ0aXNlZCBieSBFUEMtRSB0byB1cHN0cmVhbSByb3V0 ZXJzLiBTbyB0aGUNCj4gPj4+Pj4gICAgICAgICAgICAgICBhZHZlcnRpc2VkIHJvdXRlIGlzbid0 DQo+ID4+Pj4+ICAgICAgICAgICAgICAgaG9zdCByb3V0ZXMuDQo+ID4+Pj4+DQo+ID4+Pj4+ICAg ICAgICAgICAgICAgRGVwZW5kcyBvbiBjb25maWd1cmF0aW9uIHBvbGljeSwgYnV0IG9uZSBjYXNl IGlzIHRoYXQgdGhlDQo+ID4+Pj4+ICAgICAgICAgICAgICAgc291cmNlIG9mIHRoYXQNCj4gPj4+ Pj4gICAgICAgICAgICAgICBhZHZlcnRpc2VkDQo+ID4+Pj4+ICAgICAgICAgICAgICAgLzU2IHJv dXRlIG1pZ2h0IGJlIHN0YXRpY2FsbHkgY29uZmlndXJlZCBpbiBFUEMtRS4NCj4gPj4+Pj4NCj4g Pj4+Pj4gICAgICAgICAgICAgICBSZWdhcmRzLA0KPiA+Pj4+PiAgICAgICAgICAgICAgIC0tc2F0 b3J1DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICAgICAgT24g V2VkLCBNYXkgMTMsIDIwMTUgYXQgNDo1MSBBTSwgQmVoY2V0IFNhcmlrYXlhDQo+ID4+Pj4+ICAg ICAgICAgICAgICAgPHNhcmlrYXlhMjAxMkBnbWFpbC5jb20gPG1haWx0bzpzYXJpa2F5YTIwMTJA Z21haWwuY29tPj4NCj4gPj4+Pj4gICAgICAgICAgICAgICB3cm90ZToNCj4gPj4+Pj4NCj4gPj4+ Pj4NCj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgSGkgTWF0c3VzaGltYS1zYW4sDQo+ID4+ Pj4+DQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgIEkgaGF2ZSBhIHF1ZXN0aW9uIG9uIHlvdXIg ZHJhZnQ6DQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgIEluIFNlYy4gMy4yLCBwYWdlIDExLCB5 b3Ugc2F5DQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgIEluIHN0ZXAgKDE1KSwgdGhlIEVQQy1F IGFkdmVydGlzZXMgcm91dGVzIHRvIHVwc3RyZWFtDQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAg IHJvdXRlcnMgLi4uDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgIEFyZSB0aGVz ZSByb3V0ZXMgc3RhdGljL2hvc3Qgcm91dGVzPw0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAg ICAgICAgICBSZWdhcmRzLA0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAgICAgICAgICBCZWhj ZXQNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+ ICAgICAgICAgICBkbW0gbWFpbGluZyBsaXN0DQo+ID4+Pj4+ICAgICAgICAgICBkbW1AaWV0Zi5v cmcgPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQo+ID4+Pj4+ICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0K PiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+Pj4+PiAgICAgICBkbW0gbWFpbGluZyBsaXN0DQo+ID4+Pj4+ICAg ICAgIGRtbUBpZXRmLm9yZyA8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCj4gPj4+Pj4gICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4gPj4+Pj4NCj4gPj4+Pj4N Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4+PiBkbW0gbWFpbGluZyBsaXN0DQo+ID4+Pj4gZG1tQGlldGYu b3JnDQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4g Pj4NCj4gPg0KPiANCg0K From nobody Fri Jun 5 09:29:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4361A899E for ; Fri, 5 Jun 2015 09:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0b8lnj1UW78p for ; Fri, 5 Jun 2015 09:29:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3DE1A1B4C for ; Fri, 5 Jun 2015 09:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7671; q=dns/txt; s=iport; t=1433521760; x=1434731360; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ryfl8Vs9d48a4uCqeu6siiVqQtJQSXOPu3xUntCzFSg=; b=YT+IgYr5bUZv6fp9xoLdT1mX3Utgc+c0CqEOy76CZhLkryv/Jlad7kTR MtzEX6SpNIYpqcu0NhigHDxJbvn/PonrO3gIKZcUXTW0JUgFnV+s2HlKQ +JhnqT0fBOBEdEO8Z8UQR0qUCRPAl7Ys5yhN2cNjXEB6WouD7wwsyA3iE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A3BAA5zXFV/5BdJa1bgkVLVF4GvXxmCYFXhXsCgTI4FAEBAQEBAQGBCoQiAQIEgQsBCBEDAQIoORQJCAIEE4gtDagfs2cBAQEBBgEBAQEBARyLQ4JXgh4YhC0FkF+CQIQ/hmiBbZVoJGGBKByBUm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,559,1427760000"; d="scan'208,217";a="4851192" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP; 05 Jun 2015 16:29:18 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t55GTIJf021651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 5 Jun 2015 16:29:18 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.121]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 11:29:18 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: [DMM] WT#4 - Conf Call Timing Poll Thread-Index: AQHQn6zE636Ph7iUkkm44BTmjcXI4A== Date: Fri, 5 Jun 2015 16:29:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.217] Content-Type: multipart/alternative; boundary="_000_D1971C071C4062sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] WT#4 - Conf Call Timing Poll X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 16:29:21 -0000 --_000_D1971C071C4062sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So, far I=92ve received two presentation slot requests. I plan to close the= poll Monday and confirm the dates. From: Sri Gundavelli > Date: Tuesday, May 26, 2015 at 8:17 AM To: "dmm@ietf.org" > Subject: [DMM] WT#4 - Conf Call Timing Poll Links to the poll. Call-1: http://doodle.com/ipcwup5wpin3un59 Call-2: http://doodle.com/5iq3g4nit6qnhmch From: Sri Gundavelli > Date: Tuesday, May 26, 2015 at 8:06 AM To: "dmm@ietf.org" > Subject: [DMM] WT#4 - Conf Call Folks: I=92m trying to schedule one or two calls to discuss the work items under W= T#4. We did have few discussions including f2f meetings in the past, but no= w doing it more formally. Scope of WT#4 per chairs suggestion was to cover, architectural/deployment = models and to tie the different work items under the overall DMM scope. If = you have any topics to present in this call, send me a note and we can cove= r that. I will schedule these calls for the weeks of June 15 and June 27th. I will = send out a poll. Regards Sri --_000_D1971C071C4062sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <576702747035C443800798DDE0F53557@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
So, far I=92ve received two presentation slot requests. I plan to clos= e the poll Monday and confirm the dates.



From: Sri Gundavelli <sgundave@cisco.com>
Date: Tuesday, May 26, 2015 at 8:17= AM
To: "dmm@ietf.org" <dmm@ietf.= org>
Subject: [DMM] WT#4 - Conf Call Tim= ing Poll

Links to the poll.

Call-1:


Call-2:





From: Sri Gundavelli <sgundave@cisco.com>
Date: Tuesday, May 26, 2015 at 8:06= AM
To: "dmm@ietf.org" <dmm@ietf.= org>
Subject: [DMM] WT#4 - Conf Call

Folks:

I=92m trying to schedule one or two calls to discuss the work items un= der WT#4. We did have few discussions including f2f meetings in the past, b= ut now doing it more formally.

Scope of WT#4 per chairs suggestion was to cover, architectural/deploy= ment models and to tie the different work items under the overall DMM scope= . If you have any topics to present in this call, send me a note and we can= cover that.

I will schedule these calls for the weeks of June 15 and June 27th. I = will send out a poll.


Regards
Sri





 --_000_D1971C071C4062sgundaveciscocom_-- From nobody Fri Jun 5 11:45:22 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323181A1BF5 for ; Fri, 5 Jun 2015 11:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ91R_FDpsOu for ; Fri, 5 Jun 2015 11:45:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD631A1BF3 for ; Fri, 5 Jun 2015 11:45:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTL78687; Fri, 05 Jun 2015 18:45:14 +0000 (GMT) Received: from SZXEML428-HUB.china.huawei.com (10.82.67.183) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 5 Jun 2015 19:45:12 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.62]) by szxeml428-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.03.0158.001; Sat, 6 Jun 2015 02:45:06 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: Enhanced mobility anchoring Thread-Index: AQFGEGaWJT3TZ6nriYRUsVAU8Df9ggHdjCPnnpLOh8CAAb1AwIABrYvQgA4bWvA= Date: Fri, 5 Jun 2015 18:45:05 +0000 Message-ID: <6E31144C030982429702B11D6746B98C522001C3@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.196] Content-Type: multipart/mixed; boundary="_004_6E31144C030982429702B11D6746B98C522001C3szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 18:45:21 -0000 --_004_6E31144C030982429702B11D6746B98C522001C3szxeml557mbxchi_ Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C522001C3szxeml557mbxchi_" --_000_6E31144C030982429702B11D6746B98C522001C3szxeml557mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGZpcnN0IHBhcnQgb2YgdGhlIHRlbGVjb25mZXJlbmNlIHdhcyBhdCA5OjMwLTEwOjMwIENl bnRyYWwgRGF5bGlnaHQgVGltZSBvbiBGcmlkYXkgTWF5IDIyLg0KVGhlIHNlY29uZCBwYXJ0IG9m IHRoZSB0ZWxlY29uZmVyZW5jZSB3YXMgYXQgOTozMC0xMDozMCBDZW50cmFsIERheWxpZ2h0IFRp bWUgb24gV2VkbmVzZGF5IE1heSAyNy4NCg0KQXR0ZW5kYW5jZTogU2VpbCBKb24sIENhcmxvcyBC ZXJuYXJkb3MsIEZyZWQgVGVtcGxpbiwgSm9uZy1IeW91ayBMZWUsIEFudGhvbnkgQ2hhbg0KDQpT ZWlsIHByZXNlbnRlZCB1c2luZyB0aGUgc2xpZGVzIGF0Og0KaHR0cHM6Ly93d3cuZHJvcGJveC5j b20vcy9ycHk2Z2Z4b243NnF3aG0vMjAxNS4wNS4yMl9lbmhhbmNlZCUyMG1vYmlsaXR5JTIwYW5j aG9yaW5nXyUyOFNlaWxfSmVvbiUyOS5wZGY/ZGw9MA0KDQpEaWZmZXJlbnQgY2FzZXMgYXJlIGRl c2NyaWJlZCBiYXNlZCBvbiBkaWZmZXJlbnQgY29uZmlndXJhdGlvbnMgb2YgdGhlIGZ1bmN0aW9u cyBkZWZpbmVkIGluIFJGQzc0MjkuDQoNCkNhcmxvcyBjb21tZW50ZWQgdGhhdCBBbmNob3Jpbmcg RnVuY3Rpb24gYXMgZGVmaW5lZCBpbiBSRkM3NDI5IGlzIG9ubHkgZGVzY3JpYmluZyBvbmUgb2Yg dGhlIGZ1bmN0aW9ucyBvZiBhIG1vYmlsaXR5IGFuY2hvciBpbiB0aGUgY29udHJvbCBwbGFuZS4g Rm9yIGV4YW1wbGUgaW4gTUlQLCB0aGUgbW9iaWxpdHkgYW5jaG9yIGFsc28gaGFzIGRhdGEgcGxh bmUgZnVuY3Rpb25zLiBTdWdnZXN0IGRpc2N1c3Npb25zIG9uIHRoZSBmdW5jdGlvbnMgb2YgYW5j aG9yLg0KDQpGcmVkIHN1Z2dlc3RlZCB0byBnZW5lcmFsaXplIGNhc2UgIzMgaW50byAyIGNhc2Vz IGZvciB3aGljaCBMTSBtYXkgYmUgZWl0aGVyIGNlbnRyYWxpemVkIG9yIGRpc3RyaWJ1dGVkLiBU aGUgY2FzZSB3aXRoIGRpc3RyaWJ1dGVkIExNIGlzIGNvbnNpc3RlbnQgd2l0aCBBRVJPLg0KDQpE aXNjdXNzaW9ucyBvbiB0aGUgYW5jaG9yIGZ1bmN0aW9ucyB3ZXJlIG1hZGUuDQoNCkFudGhvbnkg ZGlzY3Vzc2VkIHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVudCBmdW5jdGlvbnMgb2YgdGhlIGFuY2hv ciBpbiBkaWZmZXJlbnQgcHJvcG9zZWQgc29sdXRpb25zLiBXaGF0IGFyZSBjb21tb24gYW1vbmcg dGhlbSBzZWVtcyB0byBiZSBvbiBhbGxvY2F0aW9uIG9mIElQIHByZWZpeGVzIGFuZCByb3V0ZSBh ZHZlcnRpc2VtZW50Lg0KDQpTZWlsIHN1Z2dlc3RzIHRvIHNwbGl0IHRoZSBBRiBkZWZpbml0aW9u IGludG8gY29udHJvbCBwbGFuZTogQUYtQ1AgYW5kIGRhdGEgcGxhbmU6IEFGLURQLg0KSm9uZy1I eW91ayBzdWdnZXN0cyB0ZXh0IGZvciBzdWNoIGNoYW5nZXMuDQpIZXJlLCBBRi1DUCBhcmUgdGhl IGZ1bmN0aW9ucyBvZiBDb250cm9sIFBsYW5lIGFuY2hvciwgd2hlcmVhcyB0aGUgQUYtRFAgYXJl IHRoZSBmdW5jdGlvbnMgb2YgRGF0YSBQbGFuZSBhbmNob3IuIFRoZSBuYW1lIGdpdmVuIHRvIHRo ZSBmdW5jdGlvbnMgb2YgcHJlZml4IGFsbG9jYXRpb24gYW5kIHJvdXRlciBhZHZlcnRpc2VtZW50 IGlzIHRoZW4gQUYtQ1AuDQoNCkNhcmxvcyBjb21tZW50ZWQgdGhhdCBhbmNob3Jpbmcgc2hvdWxk IGJlIGEgZGF0YSBwbGFuZSBjb25jZXB0LCB3aGlsZSBjb250cm9sIHBsYW5lIGZ1bmN0aW9ucyBh cmUgbWFraW5nIGl0IHRvIGhhcHBlbi4NCg0KU2VpbCBhc2tlZCB3aGV0aGVyIHRvIGNoYW5nZSB0 aGUgbmFtZSB0byBhZGRyZXNzIG1hbmFnZW1lbnQuDQoNCkJlZm9yZSB3ZSBjYW4gZmluZCBhIHN1 aXRhYmxlIG5hbWUsIGl0IG1heSBiZSBwb3NzaWJsZSB0byBzaW1wbHkgZGVzY3JpYmUgSVAgYWRk cmVzcyBhbmNob3JpbmcgYXMgaW4gc2xpZGUgIzUgaW4gdGhlIGF0dGFjaGVkIGZpbGUuDQoNCkgg QW50aG9ueSBDaGFuDQoNCkZyb206IGggY2hhbg0KU2VudDogVHVlc2RheSwgTWF5IDE5LCAyMDE1 IDEyOjM3IFBNDQpUbzogJ2RtbUBpZXRmLm9yZycNClN1YmplY3Q6IFJFOiBFbmhhbmNlZCBtb2Jp bGl0eSBhbmNob3JpbmcNCg0KTGV0IHVzIHNjaGVkdWxlIDIgdGVsZWNvbmZlcmVuY2VzIChvbmUg aG91ciBlYWNoKSB0byBhY2NvbW1vZGF0ZSBldmVyeW9uZSBpbiB0aGUgZG9vZGxlIGxpc3Q6DQoN CjFzdCB0ZWxlY29uZmVyZW5jZTogRnJpZGF5IE1heSAyMiBhdCA5OjMwLTEwOjMwQU0gVVMgQ2Vu dHJhbCBUaW1lDQoNCjJuZCB0ZWxlY29uZmVyZW5jZTogV2VkbmVzZGF5IE1heSAyNyBhdCA5OjMw LTEwOjMwQU0gVVMgQ2VudHJhbCBUaW1lDQoNClRoYW5rcy4NCg0KSCBBbnRob255IENoYW4NCg== --_000_6E31144C030982429702B11D6746B98C522001C3szxeml557mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoZSBmaXJzdCBwYXJ0IG9mIHRoZSB0ZWxlY29uZmVyZW5jZSB3YXMgYXQgOToz MC0xMDozMCBDZW50cmFsIERheWxpZ2h0IFRpbWUgb24gRnJpZGF5IE1heSAyMi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHNlY29uZCBwYXJ0IG9mIHRoZSB0ZWxlY29uZmVyZW5j ZSB3YXMgYXQgOTozMC0xMDozMCBDZW50cmFsIERheWxpZ2h0IFRpbWUgb24gV2VkbmVzZGF5IE1h eSAyNy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkF0dGVuZGFuY2U6IFNlaWwgSm9uLCBDYXJsb3MgQmVybmFyZG9zLCBG cmVkIFRlbXBsaW4sIEpvbmctSHlvdWsgTGVlLCBBbnRob255IENoYW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlaWwg cHJlc2VudGVkIHVzaW5nIHRoZSBzbGlkZXMgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48YSBocmVmPSJodHRwczovL3d3dy5kcm9wYm94LmNvbS9zL3JweTZnZnhvbjc2cXdobS8yMDE1 LjA1LjIyX2VuaGFuY2VkJTIwbW9iaWxpdHklMjBhbmNob3JpbmdfJTI4U2VpbF9KZW9uJTI5LnBk Zj9kbD0wIj5odHRwczovL3d3dy5kcm9wYm94LmNvbS9zL3JweTZnZnhvbjc2cXdobS8yMDE1LjA1 LjIyX2VuaGFuY2VkJTIwbW9iaWxpdHklMjBhbmNob3JpbmdfJTI4U2VpbF9KZW9uJTI5LnBkZj9k bD0wPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+RGlmZmVyZW50IGNhc2VzIGFyZSBkZXNjcmliZWQgYmFzZWQgb24g ZGlmZmVyZW50IGNvbmZpZ3VyYXRpb25zIG9mIHRoZSBmdW5jdGlvbnMgZGVmaW5lZCBpbiBSRkM3 NDI5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DYXJsb3MgY29tbWVudGVkIHRoYXQgQW5jaG9yaW5nIEZ1bmN0aW9u IGFzIGRlZmluZWQgaW4gUkZDNzQyOSBpcyBvbmx5IGRlc2NyaWJpbmcgb25lIG9mIHRoZSBmdW5j dGlvbnMgb2YgYSBtb2JpbGl0eSBhbmNob3IgaW4gdGhlIGNvbnRyb2wgcGxhbmUuIEZvciBleGFt cGxlDQogaW4gTUlQLCB0aGUgbW9iaWxpdHkgYW5jaG9yIGFsc28gaGFzIGRhdGEgcGxhbmUgZnVu Y3Rpb25zLiBTdWdnZXN0IGRpc2N1c3Npb25zIG9uIHRoZSBmdW5jdGlvbnMgb2YgYW5jaG9yLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5GcmVkIHN1Z2dlc3RlZCB0byBnZW5lcmFsaXplIGNhc2UgIzMgaW50byAyIGNh c2VzIGZvciB3aGljaCBMTSBtYXkgYmUgZWl0aGVyIGNlbnRyYWxpemVkIG9yIGRpc3RyaWJ1dGVk LiBUaGUgY2FzZSB3aXRoIGRpc3RyaWJ1dGVkIExNIGlzIGNvbnNpc3RlbnQgd2l0aCBBRVJPLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5EaXNjdXNzaW9ucyBvbiB0aGUgYW5jaG9yIGZ1bmN0aW9ucyB3ZXJlIG1hZGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BbnRob255IGRpc2N1c3NlZCB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQgZnVu Y3Rpb25zIG9mIHRoZSBhbmNob3IgaW4gZGlmZmVyZW50IHByb3Bvc2VkIHNvbHV0aW9ucy4gV2hh dCBhcmUgY29tbW9uIGFtb25nIHRoZW0gc2VlbXMgdG8gYmUgb24gYWxsb2NhdGlvbiBvZg0KIElQ IHByZWZpeGVzIGFuZCByb3V0ZSBhZHZlcnRpc2VtZW50LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlaWwgc3VnZ2Vz dHMgdG8gc3BsaXQgdGhlIEFGIGRlZmluaXRpb24gaW50byBjb250cm9sIHBsYW5lOiBBRi1DUCBh bmQgZGF0YSBwbGFuZTogQUYtRFAuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Sm9u Zy1IeW91ayBzdWdnZXN0cyB0ZXh0IGZvciBzdWNoIGNoYW5nZXMuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGVyZSwgQUYtQ1AgYXJlIHRoZSBmdW5jdGlvbnMgb2YgQ29udHJvbCBQ bGFuZSBhbmNob3IsIHdoZXJlYXMgdGhlIEFGLURQIGFyZSB0aGUgZnVuY3Rpb25zIG9mIERhdGEg UGxhbmUgYW5jaG9yLiBUaGUgbmFtZSBnaXZlbiB0byB0aGUgZnVuY3Rpb25zIG9mIHByZWZpeCBh bGxvY2F0aW9uDQogYW5kIHJvdXRlciBhZHZlcnRpc2VtZW50IGlzIHRoZW4gQUYtQ1AuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DYXJsb3MgY29tbWVudGVkIHRoYXQgYW5jaG9yaW5nIHNob3VsZCBiZSBhIGRhdGEgcGxh bmUgY29uY2VwdCwgd2hpbGUgY29udHJvbCBwbGFuZSBmdW5jdGlvbnMgYXJlIG1ha2luZyBpdCB0 byBoYXBwZW4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlaWwgYXNrZWQgd2hldGhlciB0byBjaGFuZ2UgdGhlIG5h bWUgdG8gYWRkcmVzcyBtYW5hZ2VtZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZWZvcmUgd2UgY2FuIGZpbmQg YSBzdWl0YWJsZSBuYW1lLCBpdCBtYXkgYmUgcG9zc2libGUgdG8gc2ltcGx5IGRlc2NyaWJlIElQ IGFkZHJlc3MgYW5jaG9yaW5nIGFzIGluIHNsaWRlICM1IGluIHRoZSBhdHRhY2hlZCBmaWxlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkggQW50aG9ueSBDaGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBoIGNoYW4NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgMTksIDIwMTUgMTI6Mzcg UE08YnI+DQo8Yj5Ubzo8L2I+ICdkbW1AaWV0Zi5vcmcnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJF OiBFbmhhbmNlZCBtb2JpbGl0eSBhbmNob3Jpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+TGV0IHVzIHNjaGVkdWxlIDIgdGVsZWNvbmZlcmVuY2VzIChvbmUgaG91ciBlYWNoKSB0 byBhY2NvbW1vZGF0ZSBldmVyeW9uZSBpbiB0aGUgZG9vZGxlIGxpc3Q6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xc3Qg dGVsZWNvbmZlcmVuY2U6IEZyaWRheSBNYXkgMjIgYXQgOTozMC0xMDozMEFNIFVTIENlbnRyYWwg VGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Mm5kIHRlbGVjb25mZXJlbmNlOiBXZWRuZXNkYXkgTWF5IDI3IGF0IDk6 MzAtMTA6MzBBTSBVUyBDZW50cmFsIFRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcy4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkggQW50aG9ueSBDaGFuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_6E31144C030982429702B11D6746B98C522001C3szxeml557mbxchi_-- --_004_6E31144C030982429702B11D6746B98C522001C3szxeml557mbxchi_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="EnhancedMobilityAnchor.20150527.4.pptx" Content-Description: EnhancedMobilityAnchor.20150527.4.pptx Content-Disposition: attachment; filename="EnhancedMobilityAnchor.20150527.4.pptx"; size=88858; creation-date="Tue, 02 Jun 2015 22:07:20 GMT"; modification-date="Fri, 05 Jun 2015 18:41:43 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAts5PXlwIAAHQVAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE WNuOmzAQfa/Uf0C8VsFh2263Vcg+9PLUy0q7/QAXJgkt2BZ20s3fd4CQGsTGZh0rL0FO4pnDzJmZ Yy9uH8si2EElc86SMI7mYQAs5VnO1kn48+HL7CYMpKIsowVnkIR7kOHt8uWLxcNegAxwN5NJuFFK fCBEphsoqYy4AIa/rHhVUoXLak0ETf/QNZCr+fyapJwpYGqmahvhcvEDAVR5BsEdrdR3WqIfIoQi ssAvZft4G6HFMPjYbq29JyEVoshTqhA72bFs4HfGV6s8hYyn2xK9RaICic/m72URNcZf1UaJHYLr yyH4Svd8qw6RaBfvvKBpbVtFZQTTzaUxfaNSIZdbxrSL2Aum1rZVnA5oXnvBMQXBm4sgqKvuruJC ntv70bBVDEbY6icebhXkp8u5YfLT9+wwKRwoQJrPK2cCNWZMbNE8upeslUd9yvnpVqZ31hG4h/k5 c1aLunsI7KM+0hX8vL8d25s8jGByJ+JYTvqYPsGKbgsVfH5Eadaqwd8C1gPFlZe1iGt+QNU0sqeC Qg72GFTaQRlGuLORZnKTC9kxdsTDaRlo0HN6HJz7iW4MBaW+jEqas+4lbORt7CfHkyD4GYgmCIwr kJ1w0xbufUBPCOZHs23C9FQhnh2T5ugUJjzDNBqKYC050xbqCs8gmwmUZVCpHI7lZsXUuTOCQWKa IJx6/eFZMPaTh0kQ/MwJEwRFfxVwr/YFnF1Pa6ZNKDTW9s6knvLSH1RjHD3WR7qVipfOBG3NTC2Q kckd+ykWc0SGJePnusCKKAeK+LkcmILgvTMvntO4Nnh5hpc33YTrLc/ex3rWTbHZ5fDXy9H8aNiE 4KlG4idT5qr530d4BdPZ0knZFHePNA/S3Jku/wEAAP//AwBQSwMEFAAGAAgAAAAhAEe/GtATAQAA dQMAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs00tLxDAQAOC74H8IuW/TXR+IbLoXEfYmUn/AmEzb aPMgmcruvzcUfBRqFdxjMo98yZDt7mB79oYxGe8kXxclZ+iU18a1kj/V96sbzhKB09B7h5IfMfFd dX62fcQeKBelzoTEcheXJO+Iwq0QSXVoIRU+oMuRxkcLlJexFQHUK7QoNmV5LeL3Hrya9GR7LXnc 6wvO6mPIJ/+nt7BIoIFAKB9xFWKWRTL5LqyG2CJJrr16yNtpzCiymot50Oa0IOoG++zA9DOUz1jx ErD9CbT+O8g3jVF459Vg0dHMEMQ048sUAokQMeWycexLL3R1SpAaEnn7y8jGnCXS5SlJeCB0GvUy CkL4EInJZ6neAQAA//8DAFBLAwQUAAYACAAAACEAFGs7hb8AAAA3AQAAIAAAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGU2LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17 c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQ PGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5 juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyvI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc4SPwQrCMBBE74L/ EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306r HQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYq zRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9z mw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTQueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3m zU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul 2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWD s3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3 AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI Uy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7B k4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZ akhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP// AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54 bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4 UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJ F6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPB Yuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAgAAAA cHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBT cT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oM XXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62 BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsD BBQABgAIAAAAIQAUazuFvwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTcueG1sLnJl bHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yG taxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnE XGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQ cn7nudjK8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAFGs7hb8AAAA3AQAAIAAAAHBwdC9z bGlkZXMvX3JlbHMvc2xpZGU4LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2w TUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBc Qty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8O besMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyvI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgA AAAhABRrO4W/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOS54bWwucmVsc4SPwQrC MBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E6 32m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPA jtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52Mry PqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTE0LnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogtCa0S 6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+aMZcQjy5 yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0/88Ow+AM nYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBLAwQUAAYACAAAACEA FGs7hb8AAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMy54bWwucmVsc4SPwQrCMBBE 74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4 306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSm qrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MryPqim Vl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQAUazuFvwAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVs cy9zbGlkZTEyLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wg eJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvo c457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTz jwrFg7N0wSk8c8Fi6ihrkHJ+57nYyvI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhABRrO4W/ AAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTEueG1sLnJlbHOEj8EKwjAQRO+C/xD2 blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0I zugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z 0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjK8j6oplZfc5sP AAAA//8DAFBLAwQUAAYACAAAACEAFGs7hb8AAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGUxMC54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebN Tn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY 9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOz dMEpPHPBYuooa5Byfue52MryPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQDNqI32mgEAANYL AAAfAAgBcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAALyWzW7CMAyA75P2DlXuI035GUwULtMkDpOmjT1A1pq2WptUcWDj7RcV VFqEvEvUC5JdcD59sU2X69+qDA5gsNAqZmIUsgBUotNCZTH73L48zFmAVqpUllpBzI6AbL26v1u+ Qymt+xHmRY2Bq6IwZrm19RPnmORQSRzpGpR7stOmktaFJuO1TL5lBjwKwxk33Rps1asZbNKYmU3q zt8ea3fy/7X1blck8KyTfQXK3jiCY1mk4ApKk4GNWRPiKfs4cqSM34YQ44EoRERieJVRG8A3o2u8 CGlTFMVQLkgVkfB5I1Z+lfBhj6Xr7rY7OklKx6NPEKJBZxSEiAaiEILE8Cojd2tH7+2rRAvmci+9 NPJeSNIN5ohUNPN5U0pbwGtBnSTyTkDLcZvf36K17g+gs2ibkDefJITXoW5m6dpNJ3le/KdvkFhe r4wY8SnZOP7lXGaqgToLESGFMfXZJoSLCQUhhqIQNIbXmSFkLEgZC59Xcijg5+qtoE1RFBOfEISK MQXh1QQBMacgxFAqROuC997GV38AAAD//wMAUEsDBBQABgAIAAAAIQC5NjULRQMAAFoRAAAUAAAA cHB0L3ByZXNlbnRhdGlvbi54bWzsmM1u4jAQgO8r7TtEvq5YyH+CCBXtCqkSK6GlfQCTGIjqOJFt WOjT79hxwQEq9cJlxS3x/NjzjWcmMHrYV9TZES7KmmXI/TlADmF5XZRsnaHXl2kvQY6QmBWY1oxk 6EAEehh//zZqhg0ngjCJJZg64IaJIc7QRspm2O+LfEMqLH7WDWEgW9W8whJe+bpfcPwX3Fe07w0G Ub/CJUPGnn/Fvl6typz8qvNtBdu3Tjih+hxiUzbiw1vzFW92FN0jCcnLXE5LLuSEFTMs5NMGc5Eh YCTwjiy2S0HktGYS1lw0BiSCFr9Bj/DnYibk2YpTFhny3CAOEj8KPeTwoVoBXRf1x6P+NXNWSyLO XHbWLCeR8dKRm2NsIIP1Vp55Olu1fMXG15nGKSg7wOdCh+b6IZA5BuUpFzqmozyyg/Yv5Wls2QeX 8gQu49F/eCmP7f01ju7+aWTZ6xC78sSWJ5f+09CyT6/IfUvuDq4o2ABcnfbuCdLA9nAFYeraCtcY 2gzcaxBT24Om2F49O6WLdyffZyh1g2AwAI/5IUOhG0CG4UUeGugEIueEMDfaGxD62hm72HdDKO7W Lo0GrnrR16EgK7yl8oXs5UIeKBmP8BDW5nNunv7MuUOx6j6E9V4Xyqpvq9AddRvQwXQNDYtCLJLq kiR4xh75m35eQVFOtMISC4IcuMZraDnzLculUlB7iSZ/JCvzNM+ls8PaUbthRzpZQS1ri2t6RgpR qLOLd2gGkYp9qbqC80a4aqwKgPZR07KYlpTqF9UkyRPl7d5y3zYC2MnWUp2NaegrnAP4CS8xxN2U Mt9McVVSyI0P9yZX3Yno+CAGPCTYMvpRsR7BiiYe5uJMkIsTZohBEzeclT48egp5hfksQ0EY69Te E3DzBCjqJgH+KQFtUaJ7Bdy+AhR1k4DglADXj9sKv5fAzUtAYTcZCK0MJF6SqB57z8DNM6CwmwxE pwx4XgJDzs4AzL8XvFzA+PtoUBeTGcahHmanQd0dzOojWs/6/2yQKm4GYWwhjAO/O0nvCFnvk28R xc0gTE4IFT/4QLX6wB3hpwgVN4MwtRBGYaw/V4+t9I7wU4SKm/6lDozOfsbAbyj7r4TxPwAAAP// AwBQSwMEFAAGAAgAAAAhABbRvAlqBgAAjxoAABUAAABwcHQvc2xpZGVzL3NsaWRlMS54bWzsWUtz 2zYQvnem/4HhsTOOCFJ8SLUcxXbidia2M7HcW2cCk5DJlgQZApLt/Pp+AAhZlCXHnk5PlQ4iBCz2 8e1ihV0evruvSmfJWlHUfOKSt57rMJ7WWcFvJ+717ONB4jpCUp7RsuZs4j4w4b47+vmnw2YsyszB bi7GdOLmUjbjwUCkOauoeFs3jGNtXrcVlfjZ3g6ylt6Ba1UOfM+LBhUtuNvtb1+yv57Pi5Sd1umi YlwaJi0rqYTmIi8aYbk1L+HWtEyAjd7dU+kIlqVXZaaeopm1jKkRX561zVXzudXLF8vPrVNkwMt1 OK0AizvoFjoy/ZODDIPBxvZby4mO7+dtdXRIx7DNuZ+4AP9BfWMTHbN76aRmMn2cTfPLLbRp/mEL 9cAKgAYrocoqY9EWc4I49IOhNeoLS+H525I5/so+s4mCyac6/Vs4vIbFBoj6JAc1e9+29V3OaCbU tLE/vVhaaQoUJb/JHfnQALpUtrNClqwjNesaM7tFAHcNqLw/rrMHBc4NnnqSjkshr+RDyTRoMI2O wR9fcFEJfSYu4wfXV65DS/lJ//6eH5xcIKq/T9xh6AHzrGilRtgRlTwpGcVJ8FztA6qVnNMUil4V 1dUCMdsUMs0/0qooscl3nTSnrWBy4h4QXwMF3CFd7ZdHHzhASVnmnNc3RVnIB+c9T/O6FYegkgiO Tl3Gs8+0pV82td6ipYKUjmEpQLKIYGjc+iPnhk+dG/yHzhWLG+NcHBfEso2H1zhZ4ciRR94vZD0v pLHe+F8tPXX/EygzdnD6YZeb/xWakUXzVIqrnDbsAtkAkphIkdOm4XQ0jZNgGnhxOPS9JBgeJ8Mo OJv6x6eBd+Ylk+mv1/ianh9HfjQK3ujP8e+/XU7/XM2Q1cc7iaJpdOydkj9ykVVZ254I/pWlX2t2 mS2WXPzVXmc3SIcVn+dZO/j2bWE47r/3COwR2COwR2CPwB6BPQL/ZwTIGxRteZFlTNW7z1x9X1zN qBukKvHWyxXn5u68zlA0UNxadSmxtdTT5cJjqUfCBOW2qvYIGZm7si3h6DhdCHnGal0v0uUnoW7C dHybYWQGXSk6Q0Uzr0rU5L8MHOIlkefcOT6JUOl0OywhgFgR+iSJnXw7HWqcR7qRn+ziF6zRQbDn 7WKICnPF8FkNUa2sCLUJuzjiIr4iJEkU+7t0jNcJn9MRjnjkGEejYex7DkCEVVEYBtEmmKN1ehKP omHyLD1Zd1OYjBJ/+Dz9ureep1z3V+gF8S4syLrDfD/eGQCk5zCYv5vlusdIEPV5omxdxSvNbQin 97yLYYwcXaLPEn1mmlqotoiKaJyJmT0RIFMR/0g96lHDfEWty1pIfEIN5NV2yxy2KfJQOXQrOemR I9IUebxObrZ1RrTomjilUheKoCswUzCjGpwpFG/UU4uCAlQqDLQuGDp36CboY+rkdqTWqnrJZrWm kgoNfWC0EurMdmo8EqWLmyI9Zt/7W4Yhwgd6k3jYRW6jmY1CH4GrFjySmJDuFjyoqRbiQOcNZWKP c/+X2RQnkdlEwi6zmfkoSsx8l4LMbDjsRLxcwJDEWwX4o5GZD7Gus5wRQUYRDrwyL/BWDv6hGYSE JuIswPCVRktxV9wC3zR67Lw/NDE39P2X22JEAIQeKJZVFEa9eSs6DkfW530PlLzvceR9resq88OD lsY+jVW+Z9FbY25J+kK6DQS5TTPf1LKLX0D0xK7VnleB5KP5sQNzDx2VzkJzDKw34PTA+ON1Xk8s xptBFA/9rVFHIr8LiJd7HaGFSFRB1HMvCeJguww/7uhfcxCJT2KTqDbPNSF+aDLeZirYmlf67k/L Wqg+K0JJJa/VQGcxnSEeryiiLovsY1GWKnPp1wLspGydJUVqpGmK3rtN5z3Kkqs8SGC1ydK9xQ02 8n4ri6qQDL3fopq4uIPgYzKCakl/4FnXdeZ4m+EqUaJynVLdBTHQmUPSovwxnT5NyjQ2nyPhAwGF i+rCmva2bczaVrVz11L0yY1YdITRAtatbyOzfNLDftLENF3sDnwtyoroer/6Yd5XYGhfYaRle06b y2Wr/0qoADRwA6YavIsxKq+RoKFcVFhQDXpp/pXRqafYDI4zbt95ZAsoX/CMzQsOsPH3xvCOqMWf HWd4l4SmKO6+M93dl9WXupbKSiilOeHZsVajThyGeJ109A8AAAD//wMAUEsDBBQABgAIAAAAIQAD tjx+Yg0AAAl7AAAVAAAAcHB0L3NsaWRlcy9zbGlkZTkueG1s7F1JbyRJFb4j8R9SdRo07XHlUqva HtnV7caS22PZHuYclZnlyuncyIzy0ggJiQM3OCAhBBJqtoEDw4W5IIH4L4juGU78Bb4XkVtt7nJ1 Vle5O/vQjqyMiIz34sXb4sWLhx9fe65yaUexE/g7NfWjek2xfTOwHP9ip/bp+cFWu6bEnPkWcwPf 3qnd2HHt491vf+th2I1dS0FrP+6yndqQ87C7vR2bQ9tj8UdBaPt4Nwgij3E8RhfbVsSu0Kvnbmv1 enPbY45fS9pHi7QPBgPHtB8F5sizfS47iWyXcYw8HjphnPYWLtJbGNkxuhGtx4a0C8jMM9eiv3F4 Htk2lfzLJ1F4Fp5E4vXx5UmkOBbwVVN85gEtte3kRVJNPPqohsL2RPOLtCfWvR5E3u5D1gVsyvVO Dci/of/RiHXta66Y8kcz/9UcfjKjrjl8PKP2dvoBjCD7KEElIZoGp5GC8+rFT/77u18qRgaWrMvQ 9igwn8WKHwBQgl/CZx5fpr0R0NR/OFT4TQjUcIe7dlJPvhQISevHQKrAFr/eD6wbgryPv9QJ6/qg n70RDwYOVwaBz89M5qLLTh3/RJfFym7Mz/iNawvsAUbWFX1EmCuXETnb/tanZzWFufxIPD8fbvWO a4rlRFwgWIk93nNthoWQzAHf7Q1RFWSrHJ4ozLJANfFD4JVjWpP++2/4FfSTdCGG/Eaj/SAZosJ8 cxhEtqU4vmKOogikrvg2vwqiZ0owUBjnzBzSOvrOBDS2b52wiJ1mw0iQlCEtQWKGNCIA1gW6Mavp FKIoiWw+qTVTUnv5s799/dcvX/7hK6VBM4rFJ2lJlIsrqEgwSv/qaWCBEhiIo0Z4m1hJekdranXQ MybW0NR6vTGxqtSGZhARKbS2DL2tygoAJe0pjGL+xA48hQo7tci5GPK9KAquxPfY5VEMImDdCyth Acz6HOxg4LnghpfMVRopkY7X0Yp1Wo12vZkQctIjITP5MnXvBweO6wqSdn3lCrTf0ACWybD6BmB+ KHohOFHsXxBlX4B2TR6JIcaB61jUmvqJo4t+z40UjAzUjX8HB8l3x6rRpx+xeCjriVdUDaQejHxL lIY2sx77VrK6fUiFGo3Ls62a4tr4PpVETc4cd5GaANn16SP2YGCbHIhFc0FDkpWkZJUudpJXmBEQ +HN8OiJUxN8fsQgDcQ/9eKfWwnRiLrh40Dv1Nh6i4pt+8Y0/8noBsEKVuCuKoAu5giQ2k4ceh6BC LTPwQsaP/LPQpGcaOeHt/PozFoUJuXCw7+PgbMhCO6cXAqtYVzzm3G6agYE3Kh6LjoghUeFUFBzf wsoVRTnjLpiYPThn/bPnO7VmC8DrAhZRxWZH/n70TIyceOieIJI+iwldkH9+8hpfSHjdycg30b2E zCUwBQWF5onJJWGotHZSDlyssW8PJuum1eLQzN/uDcTiwW9Zn4V6ydv+CBR7fi1oqT86e54VDwBG 9nAMCkzIrZ+QDnAs5UdEgyEB8GzkOV7wuSMwcqs0iIFCtUmcoS9QJpuMdmqS0mMeOc/AePzgTJSS pShfkrhirvPc/q74DuHYdUhrQm8ZwxyTMjQ+SfvZQs9Ww9jCXHD9FlcQeqbpFQt1wEwM40Pv8y2X y8Vps8KLV7/4+6svf//yT7/6zz9/XlNCh5vDA+Y5Lngj+JU5ZFFsgyK2VE2Trc240HovchhIMKuW ziQQT/DxXS+4tOfLmRlzM0foVHNT2tzkcl7yJMFwU0a7gPxWW6kAPwen2w+uFVUIskx+K9QZ1Feh IpIGnOvCRUlOBJJK3EQL1utGGwuGaK/RaDZUQU65PtxUW0YLXyfBrevtRkNoqVg1aTep+EwFN0TK LBZMsp2+ni880lrmSBwpZeQqz4UENY9DUlAPHCGzUglFL6a5ecaNFmdAtzKOZRjEfJYADGYL9tjm 6vwFK4e/yBotDl8gawmV5NYRvzEZw7yVFlxGxi3icGWQsVFv1w3oaqDTltZpqkK/regY/oSCmbUS qijSsf5+0HFnio7bJdFxs9WAPpkyZEPVWhVDnuEvWDkha+8QIV/AaBs65kEE55l0Rj0p/CJlMPwA UNzJy6ZnusY3v/3zqxf/UPRc1ZhsB2O70NM8Z9Vkq3H9ZPptqlpMayjtTkeFeSkMkNRjp+lYJcT5 SUVR1Y7eTmylMNNRkkES0STFR4wzZRQ5izgvJ1ypnPXhYaO+eF8Y+/gD1A0cGKWnAWxz2Kx9uHCT sqhITYS37NDa/UGjp2kNw9jbaj1+3NwydEPb2ocSttVu7D/qdQ4eqT1974eC/IrNxA/0peTLTyIH XlMCyLFgRZNTIMUE0AP1AsNK6/BIGdLE1ttGXY5c2JipAprqUQKt04oUmcXS8o0k5pfTrIQTJTHr yJQvaitTQmoxK43c33bmZ+lfSAcptMSi4rOokVbUyA59GJDQZOHsfh0fmOPmHDOeAOoM6Es1WMtG xbSqBzOf6G2KGvKatzt+3x+MlLY+NppCMrVv4AZXHxyeqA/+/aMvJh3c7wEqwG5uvIJ/5jPsX9CG HnbI5rp2hF+nyHD+9+MXhycTrGYFuNvSyE/+5u6xUrlNKQjcOy1LY7uVU08hkFjieoRVzncznxKE fratx02pKrj+EekGZEikYug1OxmZi0Y6z9ezQXEkEXt6H8d+Ksd+fh/Hfi7Hvn/HsY9pXGPe8ya8 +810122s2vp2v/YJyIzMSVcWi0UUpO4seO+7qjYvtjm5jN68d6p2Vy/FShBgq0OBsir4N2tLq6i8 nO6R+jep+uXyKbELFnRhz5C/GeiSOU2uXil/x3jLGAui3dPZG/B3oPEcnJLF7fxxbyLrXFIu3y8g lxTg9wvIStILTg1JT3KfXHn4W3APFp9RpqC+cTfq5DNFLeY1ptyq2d5X6lbNt74m22XjEC7bFblV x3Ya2m29Y1SO1aLTtHKspgFslWO1RB/ztB5ROVbTIFjBcqWXmXS8KVezsMrgd3y3Hc2ZY/WgcqyW 4Vh9ejxhkuVLcB2WSam+U6gsOTTp8iF9pvIDpoHc63MzLWlGZI6pdfpfK+sgtQ6wmN7R7fPVOcGw G9NVhFtIq9xC0ml1112Y++VMqNxCy5wM2kQHX8X4U8b/VtxCCMhKQqJTt1AniyRdu1vI0IxWR7vN LZTElFHEWRVut1HhdtmeyZKxdYspB7ceF8gM2afH5ewKlhoPVSaA5Wz6bdKUHZ5oDybM5uW8L8/s iFIdIAvBm4cdLTtl/uxzeB96/pbNZEzr2BE7emHG9AIyIKNiRQS6bTRSDg5orzMZ+JgGOb1Qy0EK 6GSjMTJ/73dVGJkVBpn7aO7mcco4Qtkb39PAp2dVV+lRGqPIsS36TdSEK5umsmnmpHTYRHLdnwyL mRXU9nZsGpyAkcc8E5sGRg5kqTjluRabRi8cDlXrLU1ri4DE/HRoenKmOkOUYkLqPlNniHDGVtU7 NSI1Xp0hsicTPRTVxeoMUa71pDtT1Vb3are6i8bWjDjKUu3nUvYxyzFCyj+B9B4hspTjN+WdX1oY 81NHcZZ0dK2ZjktBf3mnn5ZH/+Im6poxvkoLdyP27pc0XDdi7FXMRCFz4L01M6uYiTy14m2J4Yr2 wt6pnsRMlOJQvVX9K0t2LuaQv8Mpm8zZ3jteFRYyn+qS+sLqYK5CZaQOUYXK3Cm/7CZKiSXF+P3a IKhCZQSPjoR3Z/UnqAwkRx13K4vIlDW6lZH3up2kvdYo77V2m1u5CpURKRnlDkQVKlNID1zUAnvH 3RLjDMrUde4SW1DYTM40urIiBcqE6S7RAbNgelBS0p7cMft2NfNbwwCymStJF9+oiVNmJKvK9yuq KI2ZNxlsoqa5pLPrfmmalTr9roSi7K8wSsO8xu0RMsFrj4qTKQgM3FMhFeivf/3Vq5/+Ud4E882/ fkPlv3yhQMFOwzSS9uKxmEy+0C9lb599MwwUGCfEpQwIA6HS96hEYCf5XI2GoekdZJlFvlZNa3aS nPJ5NAZd+kG5XHWj3RB5laEgpTlhJ9LN44IIRlfF9ALfR77OIJJfEre7yBCGtMEY3ilnG2W4KuN6 l/l60QpPHjJxNY6EUKa/KTrZxI0CNPsoZESRFfzLwizmeX8N4zXUoZdDHQVKaHWQ/RbhJOLeoHpH bbXE7QI5JVDGOqKEhtHoiM9vNCXM1ybvFyVo2ZmU2XxCLYlPFCih0erIEHHiCXW9rU/eINXRdQO/ SXJAhmekUE7CnCvOMHbx0xKc4aKQtub1+cFxKc24G0bPc9+vJ7ovu8HE0Jq62qzOKxXC9u5NFptN sg6r80ozr26czOC9SVNG+ael42xOJurKuBc6+JvbvRYuLCTR+xZuKVybbf8WYTwlTLr+XZMF36t5 XNtG2Vucx32axyyEinY5ZuQUpp/vnGlQWHPyamSy55Lbkk03esrCTy5h5bEuLoHmdoQsZfgpRO55 MgxRNa+C22Ij5scO3WiBl3h0PNQTJR/3OFIhZOgLrc799LZla4QrOOn+y4HjOxw3WOJCXs7oNlDf xq2g0ANxLey5vHfYOw0CcdkhPix6wl8uu6ZS8jkUcZH17v8BAAD//wMAUEsDBBQABgAIAAAAIQBC CvWtaw4AAOODAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTEwLnhtbOxdS2/kWBXeI/EfrFo1ms6k/Kin Oj1KKp2eSOlMlGSY9S3blfK0X9iudNIICYkFO1ggIQQSal4DC4YNs0EC8V8Q3TOs+At8516/qsqV VCquRwf3omOXr6/vOfe877nnPvnoyrGlSzMILc/dqckf1muS6eqeYbkXO7VPzw+22jUpjJhrMNtz zZ3atRnWPnr67W898buhbUh42w27bKc2jCK/u70d6kPTYeGHnm+6eDbwAodFuA0uto2AvUKvjr2t 1OvNbYdZbi1+P5jnfW8wsHRz39NHjulGopPAtFmEkYdDyw+T3vx5evMDM0Q3/O2xIT0FZPqZbdDf 0D8PTJOu3MvngX/mnwT88fHlSSBZBvBVk1zmAC217fhB3IzfumiGi+2J1y+Snlj3ahA4T5+wLmCT rnZqQP41/Y+XWNe8iiRd/Khnv+rDTwra6sNnBa23kw9gBOlHCSoB0TQ4jQScd29+/J/f/kLSUrBE W4Z3jzz9ZSi5HgAl+AV8+vFl0hsBTf37Qym69oGayIpsM24nHnKEJO1DIJVjK7ra84xrgryPv9QJ 67qgn91R5A2sSBp4bnSmMxtddur4x7vMN7bD6Cy6tk2OPcDIuryPAHNlMyJn09369KwmMTs64vev h1u945pkWEHEESyFTtSzTQZGiOcgevrCuwTRSocnEjMM0Ez4BFiNMKlx7/17fgP9xF3wAd9rrI/i IUrM1YdeYBrSxGDvOVYC3HKX0Kk+CgIwo+Sa0SsveCl5A4lFEdOHxOnfmQDCdI0TFrDTFFXxNKbT Gk9zOq1EoqwLggDdJUSGS8EGs5mhmTDD25/+9eu/fPn2919JDaI5iAdB7fw6z+N5kpb6r154BmiV gXxrNLcTvK52lKZSB8eB9DRFrtcbE3wvNxSNyFwi7tfUtiwaAJSkJz8Io+em50h0sVMLrIthtBsE 3iv+PXZ5FIJQWffCiIUUMz6HwBo4NuT1JbOlRsJG422UfJtWo11vxqwW90jIjL9M3bvegWXbnOls V3oF7mwoAEtnkA8DiGdcOj5kZeheEO9dgLv0KOBDDD3bMuht6icMLvo9O5AwMvAf/h0cxN8da0af 3mfhULTjj6gZ2NEbuQa/GprMeOYasfxxobdqNC7HNGqSbeL7dMVbRsyy52kJkG2XPmIOBqYeAbF4 ndOQEHYJWSXiiDQqZgRM+BqfDggV4fdGLMBA7EM33Km1MJ2Yi4jfqJ16GzdB/kk//8QdOT0PWKFG kc0vQReCywU245teBFWKVrrn+Cw6cs98ne5p5IS386vPWODH5BJBwRx7Z0Pmmxm9EFj5tvw2k8fT IhbSW3JYcEQiky5O+YXlGuBcfilm3IaYNQfnrH/2eqfWbAF4lcPCm5jsyN0LXvKRk5Tf5UTSZyGh CxrajR/jC0MIbsjjk5Gro3sBmU1gcgry9RM9EoQhE+8kOiLfYs8cTLZNmoW+nj3dHXDmwW9pn7l2 8dP+CBR7fsVpqT86e51eHgCM9OYYFBiTWz8mHeBYaLiABkMq6uXIsRzvc4tj5EZ9FQKFcpMkQ5+j TLwy2qkJSg+jwHoJweN6Z/wqZkXxkBQqs63X5sf8O4Rj2yK7Dr2lAnNMD9L4BO2njJ5ywxhjzsm/ eQ5CzzS9nFEHTMcwPnA+37IjwZwmyz149/O/vfvyd2//+Mt//+NnNcm3In14wBzLhmyEvNKHLAhN UMSWrCjibT3Mvb0bWAwkmDZLZhKIJ/iip453ac7WMwVzM0PpVHNT2txkel7IJC5wE0E7h/6WW4kC P4ek2/OuJJkrslR/S9QZDGxuxJKNnlnreU1OBJJo3NhOV+taGwxDtNdoNBsyJ6fMYm/KLa2Fr5Pi VtV2o8HtaHBN0k2iPhPFDZVSJIJJt9PXM8Yjq2WGxhFaRnB5piTo9dAnE/rA4jor0VD0YFqap9Jo fgF0o+BYREDMFgnAYMqwx2Ykz2ZYMfx5eDQ/fI6sBUySG0d8bzKGAy58zJSMWyThyiBjrd6ua7DV QKctpdOUuX1b0TEiHjlHcClUkadj9f+DjjtTdNwuiY6brQbsyUQga7LSqgRyQURj6YSsPCBCvoDT NrT0gwDhPREue577RehgxAFguFMcUE1tjW9+86d3b/4uqZmpMfkenO1cT7PCaZNvjdsn008T02La Qml3OjLcS+6AJDFFRQWXkOQnE0WWO2o79pX81EaJB0lEE1/us4hJo8CaJ7w6EeyNWB8xQOor6nNn H3+AuoEFp/TUg28On7WPIHN8zRvSKzyed2g8/X6jpygNTdvdaj171tzSVE3Z2oMRttVu7O33Ogf7 ck/d/QEnv/xr/Af6Uvzl54GFuC4BZBnwoikokGAC6IF5gWElbaJAGtLE1ttaXYyc+5iJAZrYURyt 04YUucXC8w0E5hezrHgQJXbryJXPWytTSmo+L40C9GYaZ+lfiBAurMS84TOvk5a3yA5dOJCwZBGO v00OzAjEjjlPALUA+lId1rJRMW3qwc0nepuihqzlzaHpVWMkH4I7OMhFUBaljgzQxImbhZLSGKRU EikdIanhd/TiNi6Z0325kUu2FAry5mI7RI7zCYrSQZ+mBZK46apPpAs5bbtHJJjJiktkwMJh5CbC ZM0kfD1Gw+NhZAMB5VhOLzuKfCRm4PQhw3gqYDx/yDCeCxj3HjKMewRjFn0Ct3IeJbaFMUR/uNTe CFPppRlQAgNyCwoNh7KD270eyQugYEyq3GY3ucXB7Q8cd8tkQgCNxa3pgR7GX0pVx+6p3J1QHotp z1twtjRNSobFOhG42BL2HMZYmVRWiv2V0szp7qPDE3nRtfS7gC7k4qTkEDbHGLOMLRiVAm1lYZBx V1kYCyQcbKClWFkYsYVBfyhshL+5UFT+HteU4jYespu8pxy+rMVUCC9dZ0lCeNkyy+R76Th4eHBJ IbyxqHa7rXa0KoiXD9BVQbwkWaoK4pUYz5y2IWZFrLKWVRCv7Cj30lyPUuzM1KpeZhAv9SUqg1ok iI6H7Lgr8dBjdqsEcm1Bu1UCuTabepVAvk9hu4LVi1TwLbjCWfrCRSrud0+VrsQjKcrjKpqyxvWa VXLT2sIpqwSyEv6L7FKZN2i0ypmcS/ivJKKCvJk4czWJqHTIXuOJq2uPqGiK1uooN0VU4tQfWuWp sqI2KiuqTAOBlqKKN5rdmNWdmgQvjstZiluaw3tfAMtZK9ukKTs8UR6Xvny6LgDLWVGWBrb36tFG I2V24GaaUctBCiz8jcbIXTi7HIw8/tcPvyhrCTllmMXCW3cBPtlSCKsni9ny5SPaFI7FpY3IQVul kVj5NA/F3K8CWpyDA8HIS18lxhrsuE8DJ2etPo2a28Mn11uK0ubprtkmvmSDQ7XVI8GEyNub2uqB rZCy2qmROqLsxrxaEAUQ8F7Rntmp5H7QotjSf6dNtEsIhJa9vyF1eqqtHtN2xPu2Slw2ccyPkcX4 Y5W5qqXgphyTmztm8ESKTO8KkbckTSM7+9rJlQH5DKVjqLIdSsXNrCDCy4fAKUiF3X9/9ObwpHRH sEDcZyGgqV07C66ErZmOS0E/1twmkJ9JmjjvZs6NUnNLkCn0c8XP6z/lN0MUpTSvGePL9HBT0KHp 1laDa0HHdSPGfirI6K67ojZi7JWbmbiZ8Ase6M7wfN7E7PDabVuccsG2VIXunqpx3sSEKF/MglmJ 7lweNnrHy8JCGlNd0F5YHsxlRY0Lpj4Fen4tXTqcmUlShZVtd/V7m1cZO19QjfMhFtY63cQskkrf J/qe1oeWH1ZGDUtR5C1OlRF7fdaXKqOiPHE7rk6sUHli5aawcpUqwyvnCVKpUmVyVVzzgZTecVfk GZQUTik/XjKfXTCdb1Bk85Zk5aXWzVJNuvlAKidrpkyI7pIUUjRJFFgtxRgvE6jZvtd801Qlady9 3vwm2mALxrreL0OzsqYfSibKHvnfabCSbKGCYkELWtP6FWr8izKcPbqc3Lyv4TQBYT9//auv3v3k D+K8jm/++Wu6/vMXksZXdbg5Hb/PkzbyJb9z/VKN7eLzO2C/WD5K5yMLhK6+S1cEdlx1U2toitpB LVBU1VSUZieu/J0lY9DRDFRxU9XaDV79FvhIKndOFAVHGX9GB3r0PNdFVUUvEF/iZ3CIDIbkhTG8 UwEQKklVxiEcs7XrEhcAGD/AREAoVljyEUde951mHxcpUaQX7mVuFrPqrJp2C3WoaQ5P/P5i1JGj hFYHNUqRTcJPd6l35FaL14DPKIGqVBElNLRGh39+oylhtknyflGCkm5JKZYTcklyIkcJjVZHFCUj mVBX2+rkOT8dVdXwmyAH1OFFoVsix42mh/dFMsw+3Qlbf2KNkR3vhN8445d1vlM7KUquNhtNtTVR Xb863+kgpvMxi3WJAkUUUoZynDoJCsx2g67Jjg1Lqj5X5ztV5ztV5zsV8m/eWgNXVec74ey36uwt mDfJEV3J2VsFa6aZoOV2Pjl8dyvihsO/xtdR1OyMkbVsOc5OitKUpio3qw3Hubz796aC2yZFd6sN x4WH+E5WqN2kKaNVhmTlqzCROxOFd8toTYEkf1MYsPkAXFGCaglLXNloNy7ZparjTyduz/ZzEJS9 y4m3awvOr3Ae15bpskIYlxmavyHEkgblk5MLxdmsPAxPMfzFD+BUNBVZKajYi6Ca2lJxwBUv1puF V2XkrKh0wnJ1BudYdGWs5vrsqO5stw2RkjStd+/5yeOT/e2z/eOJNfRMQ9xDn5U+7mxUqd6acji4 33EemDjzjVYYzmyDFyyygxfM/+QS6w6s67AwMgNUnMVPPjYTUawWTbMm6DRgbmjRSVg8nhhZDtpR R5GL85/pwmfoC2+du/z8OBCqMcLR3XRu9sByrQgnXwdmGDE6Rdw1cZo4/BocJ39+TfI9ck49jx+S jA/znvA37pqu4s/hMsT4/wcAAP//AwBQSwMEFAAGAAgAAAAhAAqji8abDQAAcX8AABYAAABwcHQv c2xpZGVzL3NsaWRlMTEueG1s7B3LbuPI8R4g/0DoNMGO1+JDT4y9sD2jiRGP17C92XOLpCzOkE2G bPkxQYAAOeSWHAIEQQIEk9cmh2wu2UuABPmXRWZ2c8ovpKqbjxYleWW5ZckezmHcFJvNrup6d7Hr yUeXga+du3HihXSrpn9Yr2kutUPHo2dbtU9OexvtmpYwQh3ih9Tdql25Se2j7W9/60nUTXxHg6dp 0iVbtSFjUXdzM7GHbkCSD8PIpXBvEMYBYXAZn206MbmAUQN/06jXm5sB8WgtfT6e5/lwMPBs92lo jwKXMjFI7PqEwcyToRcl2WjRPKNFsZvAMPzpsSltA2T2ie/g3yQ6jV0XW/T8eRydREcxv314fhRr ngP4qmmUBICW2mZ6I+3GLyl0g8Zm6fGzbCTSvRzEwfYT0gXYtMutGiD/Cv+Hh0jXvWSaLX60i1/t 4cdT+trDZ1N6b2YvgBnkL0WoBEST4DQycN69+el/f/8rzcrBEn0JPHsQ2q8SjYYAKMIv4LMPz7PR EGgcPxpq7CoC1DCP+W7aT9zkCMn6J4BUji12uRs6Vwh5H/7iIKRLgX52RiwceEwbhJSd2MSHITt1 +MeHlDv7CTthV77LsQcwki4fI4a18gmSs0s3PjmpacRnB/z69XBj77CmOV7MOIK1JGB7vkuAEdI1 YNvfc90IqFbbP9KI4wDRJE8ArQxWNR2+f8uXwDjpEHzGt5rso3SKGqH2MIxdRytN9jZzxekloe85 Pc/3+UV81t/zY+2c+Fu1Xk9aE6kbokmsJdumIVM4H77MbFvzqGaP4hiYWaMuuwjjV1o40AhjxB6i pPhO6Z0udY5ITI5zTKdkkJNFSiY5WSCJky4QFNBtRqTQFGw0m5maGTO9/fnfv/rb52//+IXWQJoF 8SK4hbdlGSGzhNa/eBE6QOsEyL+G6C7JCrNjNI06cCyQrmXo9XqjJDf0hmEhm2goPSyzrYsOAEo2 UhQn7LkbBho2tmqxdzZkO3EcXvD3kfODBOicdM+cVMgR5yUIvEHgg7yHRdca2ZKP9zHkPq1Gu95M WTUdEZGZvhmHpyESFF9Nn2oXwN0NA8CyCciXAYh3aAYRyNqEniHvngF32izmU5ToDGhTJkecWa+X vnesG776KUmGgmz5LewGZBqOqMNbQ5c4z6iTyi8Keq+G8wpcp6b5LrwfW7wnI54/T08A2af4Encw cG0GiIXHOQ0JYZmRVSbOUCPDigAPv4ZXx4iK5AcjEsNE/H2abNVasJywFoxfmJ16Gy5i+U5fvkNH wV4ITIqdmM+bQBdCSAhsphd7DFQx9LLDICLsgJ5ENl7jzBFvp5efkjhKyYWBgjoMT4Ykcgt6QbDk vvyykOeTIhqkvxaQ+IArP2gc84ZHHeBc3hQr7oOYdgenpH/yeqvWbAHwJoeFd3HJAd2NX/GZo5bY 4UTSJwmiCzQ8TW8DzEMQ/CDOj0bUhuEFZD6CiSAmkX1kM0EYOvJOpmPkHrvuoNw36wbPF3d3Bpx5 5DGlfund/ggE6Oklp6X+6OR13uwBGPnFIVBgSm79lHQAx0KqxjgZVHGvRoEXhC89jpFr9V0CKNSb KBn6HGXikdFWTVB6wmLvFQgeGp7wVsqK4iYqZOJ7r93v8vcgjn0P7UIYLReYY3oU5ydoP2f0nBvG GHNO/pU5CEbG5eWMOiA2TOOD4OWGzwRzukS68e6X/3j3+R/e/vnX//nXL2pa5DF72COB54NsBHll D0mcuEARG7phiKftRHp6J/YIkGDeLVvJXLUF4bk7W89MWZsZSqdaG2VrU+h5IZO4wM0E7Rz6W29l CvwUJN1ueKnpXJHl+lvDwcBA50Yw2viFtS9rcmSATOOmdr5Zt9rAMEh7jUazoXNyKiz+pt6yWvB2 VNym2W40uB0OXJMNk6nPTHGDSpkmglG349sLxkOrZYbGEVpGcHmhJPDxJEITvOdxnZVpKM7WCxrc Y0R+reBYREDMFgmAwZxhD12mz2ZYIT/n4VF5+hxZMy3k2SbJtTO+NRmDAy981JyMWyjhVJCxVW/X LbDVgE5bRqepc/u2omOImEiO5FKoQqZj8/2g484EHbcV0XGz1QB7MhPIlm60KoE8JSKydEI2HhAh n4HTNvTsXgzhQRFuey79InQwxAHAcMc4opnbGl//7i/v3vxTMwtTo/wcONvSSLPCceWnxu2TybuZ aTFpobQ7HR3cS+6AZDFJwwQuQcmPJoqud8x26itFuY2SThKJJm0+JYxoo9ibJzxbChYz0ocYIo7F +jz2BH8AdQMPnNLjEHxz8Fn7EKRO27wjPsLjgfvO9g8be4bRsKydjdazZ80Ny7SMjV0wwjbajd2n e53eU33P3PkRJz/5Mf4Dvil98/PYg7gwAuQ54EVjUCDDBKAHzAuYVtaHxdoQF7betupi5tzHzAzQ zI7iaJ3uFgvPNxaY51MAqX99KLNsWfEgSurWoSsvWysTSmo+Lw0D/G4e9uufiRBwKTQ4r5MmW2T7 FBxIsGQhnP9NcmBGIHcO6JU6rKpRMWnqgZuP9IZBkjFqKHremh4eCEaU8cda4yM3+wZ+ePFo/0h/ /OWPPysHuN8DVIC4uQqk+MynENPDLUvYA5wZ2uFxHVng/O8nb/aPSqJmCbjbMDBOfvvwmFJpowSB O8eqLLYpeqrgwwkEokhcjbIq5G4eUwKln29cMluYCj49QNsAHQlY+Hl2MvIQjQier2aD4kAg9vg+ zv1YzP30Ps79VMx994Zznx0ca0J0v5ntuo11W93u1y4CmZM52sqcWXhD2M5c9j5Us3m+zclF7Oad Y727fC2mQIEtDwWLpTnM4S6s15aWbLwc7zxa1qKrBHpWWsj4Tvh1+3gy0GDw3gegZ0f6F+Hvsnlf 2CCp7zfnNsUUGytfaaGAyhJa2Fhj+kPxJi0sbgGOYpNq9rzXUT0uaHvdLyAXNNLuF5CVNcdlNFhz aNthuBb+SiFg+RramJo6HiovX2PubdFjInSe729mofNie7P8XD4PHpZfUuh8bDep3TY7VhU8lwPj VfA8y5mtgucK9xEm7YgqeJ4lOnORK3YS0Mab2E7gnreKzaUiaKfAX1Qa8JTdiF4VPFcRPH9xWHLG ChZchWeimlwKaDL2QXumivVmyfqrCyUu6EbkwcdVxtgr7yDzDoCZHmiKxPICnbDj1tUg9Ld/ZFRh IRG0uulO2/0KJlRhoUW+/lrHAF8l+DPBfzdhoTxdOAsLFdnCKwkLFd98WEbT1JvXBYXSrEHMKawS KtcqoTLfMVkwe3I+0+DaD0LyHLAXh2r2fZU67SoBVLOtu05Lhhl7Gs/dK7nOi0VgVII2e6d2PmpU tTerEqbZG7HzwTQtu7IIC9wsyJHDpXqv9VpQitkqDmLc3ox24CP8NLd92V/er8yKvkMYFwyK3Kt1 XJkNfYfruFvOwpiWJ3cnJjR8t5J+OZqZ0J38g7uVmNDyzqplWK2OURnR0hdH92ZjNVeFlRGdJbLP FsO3tWEeohFtPFZiPr9yYzzzDo6ju/3XGYv6PXT6cSUfBHTDJcI8GjuJBG/YCd6QdzQV+hTLQspN /As1SFHlkSwLIzfhbDUYqfyZBY4SW8dg8socGq6n7shrW5lHc5dArsyluUsg18ingYMCxGk4qU8D Tg7oUn4Yzkp8GlM6Q0evtwyjzb/bKg7RyQ4YqI5ayDAhbB/J8RF5BHAUkW52aug+s+qoBbd8Hp5s LlZHLUzGRats0eVmi8pW9JRPkZRuQilJBVRjcqs/qOE9QqSSUwrUHfMwN+YnTixYMNC1YjpWgn51 h0Qsjv75t9xWjHFQ0pOaCYP9VdpxlXZ8m7PHKzczyz6r0o6LE+jn/e5+59hM046VxN2vNf9U6c75 AvKLfJC/d7gsLNzNxtgiMFfZ5sKGqLLNb1SGYx1j51VY+aGk1K9RWBlqSIyHlXlmygrDylAeqJ1W BzKwPJBxXVi5yjfnJ9ejo7VmB/jejUVwbQppnm++d9hVmGegErKb5BZk9WHG4uGKzpVSCdNNsgOm wfRY0dmmRWD2bi3zeWlSiS2+VgunfTl5pm8RFaqyzqfWH1xHS7PK0ngolmYVPsvCZ8JG4tmHZ+JU LizrIF9De/JML/sSiuyJOhh72Cyf4mVBOT9hQH/1my/e/exPomDm1//+Lbb/+plm8dO7uT2dPs+z NuSaW9K4WORqegFNMGC8CGrXQRoItr6PLfTs07IXVsMyzA4U44CyFobR7KSlt4psDKyNiCUvTKvd 4B+UAj6y0hmlqlxQR49gRc29kFIoaxDG4k28CKZIYcgewAlIh1Ooq4I52y5a4uEdhFcQFRCKEyTl gBMvvIarD42cKPIGPZdWsSiPYlnfQB1mnsSTPr8YdUiU0OpAkRBIJ+HlVesdvdXiRdgKSoCcYU4J DavR4a9fa0qYbU3eL0ow8m9SpssJXZGckCih0eqIFHGUCXWzbZYL7XZM04LfBDlAIRyoNJPmZ1eS Yaw+7o0lAxcWogQ7iou0Krvtxy9I9PE5CBHShWLzzI3hHDn4CQt1o9yBrkUXqNkcE5p4WFeGSwXm BdAPdRGjUE0VGxGBseCpU5pVdXdGUAgXq9AOPOoxqCMLlb8ZwZq81IXavCCOoDjzqahvHhyHIS85 Ci/mI8HfdGhspa+DZgJV5f8PAAD//wMAUEsDBBQABgAIAAAAIQCIhM1Xkw4AADOMAAAWAAAAcHB0 L3NsaWRlcy9zbGlkZTEzLnhtbOxdSW/cyBW+B8h/IHiaYEaj5tIrLA+ktuUxIGsESc6cq0m2mja3 kGxZchAgQA45BEgOAYIgAZLJNskhM5fMJUCC/Jcg9kxO+Qv5XhW3XtXqZqtliT5YxWaxyPfq7e9V 1YOPLlxHOrfCyPa9HVn5sCZLlmf4pu2d7cjPT/e3WrIUxcwzmeN71o58aUXyRw+//a0HQSdyTAlP e1GH7ciDOA4629uRMbBcFn3oB5aHe30/dFmMy/Bs2wzZK4zqOttqrdbYdpntycnz4SLP+/2+bViP fGPoWl4sBgkth8X48mhgB1E6WrDIaEFoRRiGPz3ySQ8BmXHimPQ3Ck5Dy6KWd/4kDE6Co5DfPjw/ CiXbBL5kyWMu0CJvJzeSbvzSQzc0tsceP0tHYp2Lfug+fMA6gE262JGB/Ev6Hw+xjnURS4b40ch/ NQafTOlrDB5P6b2dvgBfkL2UoBIQTYJTT8F5+9mP//v7X0p6Bpboy/DsgW+8jCTPB6AEv4DPODxP RyOgafxgIMWXAVAT27FjJf3ETY6QtH8EpHJsxRd7vnlJkPfwlwZhHQ/0szuM/b4dS33fi08M5mDI dg3/+JDFzk4Un8SXjsWxBxhZh48RYq4cRuRseVvPT2SJOfEBv3492OoeypJphzFHsBS5cdexGBgh mYP4YXeAriBbyfbQzzKI2h4AsTHmNXlBb8XXYJxkCP7NK33uey8tK6DPfXokMdMEkUffGftcyzOP WMiOs/ckaMjQkqApQwtNMesAoZi3dJLQFGQ0m5gaKTG9+dnfvv7yizd//Eqq05yBvQS18HaRR4ok IfVePfNNzDXD9MuEmDFe0dpqQ62BYjF1uqrUavUxvlHqqk5kIhH36FpLER0ASjpSEEbxE8t3JWrs yKF9Noh3w9B/xd/Hzg8izDLrnJkJkzPzBRi+7zqQd+fMkeopGY72UYt9mvVWrZGQajIiITN5Mw3v +fu243CidTzpFai7rgIsg4G/+hBvaLoBZE3knRHtnoE6jTjknxj5jm3S0zROFJ71uk4o4ctAv/i3 v5+8d6QbvfoRiwaiH79F3UDL/tAzeWtgMfOxZyb860Huy/RdrmXKkmPh/dTiPWNmO4v0BMiORy+x +n3wEBCLxzkNCWGRklXKzqSRMCMDP3yNV4eEiuh7QxbiQ5ynXrQjNzGdmIuYX2jtWgsXYfFOr3jH G7pdH1ihTrHDm6AL5hl4gcBmctGNcY1ehu8GLD7wTgKDrunLCW+nF5+yMEjIJYaAPvRPBiywcnoh sIp9+WUuzyZFFKSf5LLwgEQONY55A8IGyok3xYw7EFNW/5T1Tl7vyI0mgNc4LLyLxQ68vfAl/3KS krucSHosInRBw3nJbbwhkWZHQ8/A8AIyh8DkFBQYR0YsCEMh3kllbLHHntUf75t2iwIjv7vb58yD 37IxC/2Su70hKPb0gtNSb3jyOmvuA4zs4hAUmJBbLyEd4FhoiJA+hkT8y6Fru/4Lm2NkrryPgEKl QZKhx1EmHhnuyILSozi0X0LweP4JbyWsKG6SQmKO/dr6mL+HcOzYZBdhtExgjugR+j5B+xmjZ9ww wpgL8m+RgzAyTS9n1D4z8Bnvuy+2nFgwp8UKN97+4u9vv/jDmz//6j///LksBXZsDPaZazuQjZBX xoCFkQWK2FJUVTxtRIWnd0ObgQSzbulMAvEEX/zQ9c+t2XpmytzMUDrV3JQ2N7meFzKJC9xU0Gb6 27gA9wt7sEtNIY+hocFS3MKFnBEm7te//urtT/8kNPk3//oNtf/6uaRwcuE6PXkenEoGb276FsYl Y+9KzV5vthW4CFyzqzWtpY1r9ram6fiNK3alVaup0JdC8M7Q7GBpRsq963se1I8fCsHH9bF4cO0K eX+/IE9H+H6NCplxY0ZAOEf/ghgyMogCaRhZe2dkVQgFQZM5hS70lC5y8w46iU/+8vadFPqklpot vaZoda5WE9dIaTeg5eGMksBSmu22yn2P3E1SWq2aSh3I3NMUTYV9MJco1mLuKbBFlFby4un2XmXk JQ7eFCNPKNkpJh64fYp5h18r045bfsBEZdohUkWmHSzXe2XavfnyJ+sx6gw/uCzNqKtmZTVTezFz bnY4RmmmCvsUjuuefyEpPC6RhWMksg0Rb+Rqc9SCS9U/mW9k76dmVqKbtZreAssRfPV6o65w7yDX zA2lqTfxdq6YtVa9zsOKcILSYVLjK43DwETjqv8q+2xeAEEEDYQ+yX1++vgooIjivs1DEGnAgXtp S8YPR3wW4GG2Hzhi9y3o78328IDBzP86tGJlNqsKd3gRl6v4+RxZS0SY5n7xymQMC0/4IxkZN0es zhXIWK+1ajpCbyDkptpuKNyrqOgYarUQF18LVRTpWLsfdNyeoGPuNpQgjhvNOsKDqUDWFbVZCeQp CZ61E7J6hwj5DDH4gW3sh8h2ivjOk8Iv40EjLbM1vvndX95+9g9Jy02N8eeQOymMNCu7OP7UqH0y eTc1LSYtlFa7rSBbgNBALtlVDVxCkp9MFEVpawgqcR8+yGyU5CPpqaT5iMVMGob2Itnmsdx3zHpI idJYcY/nbvAHgbG+jRzDsY9UC1IQPeTckzbvSI/w9OZT8+H3613EvHR9d6v5+HFjS9d0dWsPRthW q773qNvef6R0td0fcPIrPsZ/oDclb34S2khzE0C2iaQI5XhSTIjICT4r7ROH0gBxlWYNoRnx5Txl kMYTUzuKo3XpLEdYzHK0FZ37DLDe5mQ5eHpw+SwHBeXSYPaMLEccJSm1JKozK8sxpd+KWQ7WQc7n WARSJxMei+c4oApeWiGVd/CwKs8sJrkOym/h9tryGLPDnlflMbzpeYz3XW/LYoJ9R1IUdMOIkjnK 7In9Zx2p7/iv3nt6pHzw7x9+Pp4M56yA3vMrBMYt/PuETThMl24hFfQpqguoOiiak0XiOYGie/K/ H322e1yWPlwY+1sqZejnOWTXT8xtiKAn3SYIBJLdlFARKeJQMEXe83o0/W5IhTS7CeLKAU3zW7NQ shyTv3MIyYTeAYQe5N2Y+XkfsFCSsPot5NXTo/Xj73YJqJS3SkFieeJ+Lh9OYJBk4k1K9RRpUwUS fswN5NgQhrfjHZClTW45dBOHbukyrwbKWBppedlIdHGNWWVhOk4rCAO8gE5MwfGdBvJYAHl6p4E8 FUDu3Wkg9wjIYmmW4FNiXXi49IcrztX93xErrTRlPDvZcH0pSL7w9KLRq5y1ghTMrJDdY6WzfhVa snlfLgqkdcFf5qwv79FMm/XjXXK1x93s3FZPnJIFc1FTdH8GuhBO49wrqH5EFY4k2kqBNgcndT0q TX9XzZlK0y+z/uA2GqYLaXpiZIrJ428hzl+8RpuWU43mQ8avab1Y3mMiP5IlsdP8SJ7DHn8u+w6e e1lTfmQkZdhqaW29ypAQHaTZj5vJkKzHQlxbbL9cW6n8KP0U4+EW46KUqAviVs8OR4xOyDERJyZD 6Z0MFq9OZqugdtLUSxF6ZeB9Yzbu6hgD1UwCTqoxW6NbRbOWXJl5Gy2jysa9VzYuxbRWreZYj62S OfcTJYfXj2aV4ukXolnj6et7EMLrSDyco97ecE6l6pJVy9PSMeDz66zPrxI3d0ULVIkb7gNBQpPN uvZwDioikzUJaTinTbU4vJR74+EcXdWbE4tl0zJPsSZHFHVSyWdV75pGfG6FhVSmOTRbU85dr5MZ QM8Oy8nmbSAEsxiA5STrbtOUPT1SPxgJBiUbVmFOr1cbWKy43BSA5dQDi2LgW42U2X7LJB2Xg5Sy agXvDplMKxXPA2LXy2FnDLNcwnpJuZ1/LTeCaPe2Knx3RyvuqvDdXXHc9sbLWaYVo92MT4MlaGKd deLTwMnZqE+jFVZnK7WmqrZ43Wu1iO/ai/iwyB3bFMlEalTiWFQLYqfCahGf2P8VjIbFftUivtkW 6VV1oeXYp9UiPrG14/LYXCUDnkUAFlvEN2OT5fu8hBJyZNIcX7iMoEKole5tWljhuzhCEQUWO8RW C6YXWDBd5trBYjzgJouxNqGvSpKwJa48XBj7E2voNpp837CSK2/d4vL4J4F1k/UOy6N8qmYj/7Sq E7uLSzurQNO9CjSBj+9BndjsAPtV3u209W+7x1pSNVVKkmmu2bQOxV0uNrqH68JCllUpwVgpF+aq WE7YL9UuB9c6saeqC9/QsURVsRyX0QiTkOG+/mI5HDczmlhKNpzGqREbKZbTcJJYKzlITKWTxNR5 iaVkB8SqWK64PPJWmIk3YxFM1uBMswK7h2LbwVKsn2IgYVNArhQiyDII2BqidIzk9YQ3aw5PEkI5 OCrJZL47RHO7Sxhnx5rXRSBVtd74Jq9Vtd4SJ4TeRn+jWoF0V+KLlVO1olOVHcjnnRfOT8zPZdSv OJdRL+lcRhTM2wEOO0U5ILW+Sy2K7yQb6+t1XdXa2O6fDv9RG+3kcJ+8Ko8O06VN9TW9VU/PxUs3 5x8796c6pTFN+xUDz9khR2hkRJE1ZlFHdjrj9FM7QT1pMWdCXfxylVM7m20cQ4CyQqIEvdZWmk1+ zFNOCbTZKVFCXa+3+esRbri9lDA7JrzGnVWXOK/zrLDN1NUHc6gTKxXzQ2c2E3zJjg7T1YamNOZt O1WFXtJjbgs7U1WhFwrFFU5Cq9Ypbj0/weH2TnzAvLMdOdmFaLz+clOBpGnRMni0H8w9pSMv9quW XtHBzGSAjexquqgzZ7JoQJof/OIPPZO3BhYzH3smP+KDTr33LJk2fHYtU5YcC6fGUIv3fDd2k7hB GDdWD3ODMG7Mk7tBGPeII67aA3yp7Bi33k9DC4emkf1+4ph8XwgnfMaCT86Rc2Mdl0WxFXb5TwEO 1iF9hq55lwBlOMyL7Nj2PdzEpe2iH295B1FMjYBhLDx16km2yb01cxjuyLaHE6Rsz47B06EVxSzE 8eqedW7hpC3PN63Ty8DakWP32PdjHlVLRsIHxGJoaiWvQzPC9/8fAAD//wMAUEsDBBQABgAIAAAA IQBMSftWPwIAAHkFAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTE0LnhtbMRUy27bMBC8F+g/ELwnctu0 KATLAeo+LmlixMoHbMi1JYQvkGvH/vsuKSlB2gTIIUAvEh+7w53hcOfnB2vEHmPqvWvkh9OZFOiU 173bNvKm/XnyVYpE4DQY77CRR0zyfPH+3TzUyWjB2S7V0MiOKNRVlVSHFtKpD+h4b+OjBeJp3FY6 wj2jWlN9nM2+VBZ6J8f8+Jp8v9n0Cr97tbPoaACJaIC48tT1IU1o4TVoIWJimJL9pKQFM1Nro/M/ hTYi5pHb/4phHVaxbF/uV1H0mvWSwoFlWWQ1boxhZeo4jAfVX+nbCQnqwybaxRxq5iYOjWTxj/nL SVDjgYQaFtXjququnolV3Y9noqvpAK7g4dDMamD0L53PE522J4Pi7IHVEAqceuHVXRLOM89Mf6Cn LvcTWOac4UMn6BhYGUWxoI2hw36RZEpJLGvRiw7fvD5m7rf8L4tQm0RrOhosmnDlUDM+f/gGDGST oju5WUuh+0hFJpEsLQ0C23lUkhZLb7NpkmAji7TbbjEV2wiIKO7RKG9xznIR39Z4ADq9ggjXL56T qUPNFTGZqXIeDuq+rPHZpPHSO+KaxMqAws4bjVF8egvF0+52UJwtyv6ZLun/KN924O7E0e/eUN6i 8vAyeTg9VmXibwhX+2IP7kGEcVmWAned0aePIXxnveWN7FVyF4lvnk0Lw/tu3fS69Y57U+80bnrX E0rBbYMgUiMdctfku/Qa22J0stfe02jzgpSNMUDn0XhcLp67yx8AAAD//wMAUEsDBBQABgAIAAAA IQCBONUzFggAAJg/AAAVAAAAcHB0L3NsaWRlcy9zbGlkZTgueG1s7FvJbhs3GL4X6DsQc0rRKLL2 BbYDbzIMOI4hO+iZmqGsaWY4Aw69pShQoIe+Qo9pD0Ufok/TQ9Ce+gr9SM6mkeXIihQvkQ8WZ4bb //NfP5LrL698j1wwEbkB37AqL9YswrgdOC4/27DenPZKbYtEknKHegFnG9Y1i6yXm19/tR52I88h aM2jLt2wRlKG3XI5skfMp9GLIGQc34aB8KnEozgrO4JeolffK1fX1ppln7rcituLWdoHw6Frs93A PvcZl6YTwTwqMfNo5IZR0ls4S2+hYBG60a3HprQJyuwTz1G/UXgqGFMlfrEvwpPwWOjPRxfHgrgO +GURTn2wxSrHH+Jq+pGjGgrlQvOzpCfavRoKf3OddkEbudqwwPxr9R+NaJddSWKbl3b21h69vqGu Pdq7oXY5GQAzSAdVVBmKJslpJOR8eP/Lv7//SuopWaYuRdvDwH4bER6AUEW/oc8+ukh6U0Sr/sMR kdchWCNd6bG4nvmoGZLUj8BUzS15tR0414ryAX5VJ7TLIT9b5zIYupIMAy5PbOqhy84a/nSX+cpe JE/ktcc090Aj7eo+BNbKo0qcGS+9ObEI9eShfn43Ku0cWcRxhdQMJpEvdzxGoQjxGsjNLceBpESE cnsUCOaQZ/0tPDjkWLChe4XOvMDWUvTNOvgtsdzxuINPHB39xF1oUuajQjWNAs91eq7n6QdxNtjx BLmg3obV6+UYmaumSDALIDd5IAuEfSJdiknE5cQ+FwIaSDiTl4F4S4IhoVJSe6TUuzAk484xFbSf MiFeunQp46VNl1KJJe1CCCBriWChaER/ugJUWokGnEL9toMrUmkqOYNJMBJOVGdQSi34Sq8zDc8L tOJ0Qbdra/W20e9qo9FsVApa3qy06i2MrlS9Vms3Glr3QEPSTSgiuc8Cn6jChiWYLS01DL04jGRM blxFveaBWnH1XlFtVDJhRKI05FJQKDGHYbeIkN5OAJlY071GoVK7nhv3nGnkvEoWvQPTmtBaMlBj TFE6LaFTxVUJa68X631OXGlXeQGu7c2Q2jAQ3/rflzwZ10xF+YjJypyCNXX6S5lxJu5zinFnQozb CxLjZqvRqNQSQa5Xqq2VIN/gPZYiFnlBrj4hQT6DGRq5dk8glDKhyX7ujbFdsL9xzFVLbfQ/v/35 4f1fpJaZ6GI7irgn63ta6FJsNW7XJ78mJjmO2nKWvd3pVNraN2TxW7UGLakjtFKmvVLp1Npx7BKm tj2epBKauLhLJSXnwp0llC0E1pIOEG+pvuRAu3z8gHVDF96hH1wq30UGiGDisq6omujY6cDZ/KGx U6026vWtUmtvr1mq1+rV0jacV6nd2N7d6fR2Kzu1rR+1+OWb6RdqpHjkfeEihlYEuQ4cC8HACSeM t8K0kjpSkBHcXmutXTfuR9q6l0JEiHYw9RNRHrwbwrAzRG1CGblZw76iSbczXxiF9keclMfVQJmT xbz0mzGvpJMhlkZbgzMTLhciMjYcwpcbJz6rJzvgiHTQCqnPx+zAlKB3BuoHNGKeq5K+W/31/bBi 0kXqcA//itKQ1bw9DfhyOKJVFM7kafMj9ZZDL7h8dnBcef73T38Uk7QvgBUwN9d+Ljb+DiCMgneA l4SutEc96rseXFMVHmpERcSQXVSLofN/P78/OC6YmiXwrlRtqMz+luzgHqzNQhi41V9UxHaDn8os 9QQDtcu8F2eV2d00iUFIkrp0aZtQweOHKjZQiQQWXhM3RDqHoh8CYYv4mUJslHe3pbDGvC6MPWKa XRqNDJyhnW8cAgTn3NHBwIhRZw94jQGjTK6L8XzmWMRj6FaVdE1JXW+WmkjKMWnD2P5jnHvfzP30 Mc791Mx9+45zH4/L8hhYE6BEU2cQWNexavcnXNtjYo55GWXRBa1MUtvepxo255dnOuYzT9y81a90 l+/FFuDAlscCsiz6U+x1DEY36lqU55uSpTzJ04BpZNVzZEv9LRX+FUO/zD/FcfAUTHmGvCAl/R6p zchZsLsds4lRfpUeoumc0y8/LiLndOCPi8iVp9eWGp5e+X0F5eE3Bw/mn1FWW7wZ1Klg1OKz2sPO akzAqtjoN3vZCazaUmGx3vkqtkvnoSHbJcGqYzsN7XatU18Bq0oOEtB0Bawm29grYHWBGPNkHLEC VpPDB9rk6pMl5l8RatZZ2ZcDrPZWwOoigNVXR4WULFPB+8hM1Am+RW5aZdQk6qPimRUOaI7n3CeG OWcake563ufcV9lBkh1AmZ7o9nkea1g0DljtEg0LVR8uLLQQkpdmfR8XmLCChabvpz2ulVwZ/sTw fxZYCAeyCrBQ5+HAQvVqvdWp3gYLxWfKAGQBIEvO7cXAmALr4+LquB14kcXk5ri33hRf2nG7dM9k AdtF0z3lbAfDXx0tZlcwO4fx2bYAZyNwMZt+D2nJDo6rzwtp83zoy1smcAikgjtpn37saLaAdXLJ eHxZAdubNHdS61uflxg1h1PsqPDBjtQH+ID0nBvRB90eNFOm7+suiynY+H3QHLmL6VqMmNx0DDLL Eu6GOKUWYb6N77sQn7vQk812wYjS44qEVznNKqeZcrHzIZ7M2C4eArrpUNtcOY2+4mhuaqOYXN62 PfGKhq8vdFiAO+mSCWyT4VWIw88mIchVwTVRQXnkqisV+IhH10c9XeK4nKEKIUVfGOCUJ5e/nXNc XXe5g6vA3JXqFiXDZXmBE9Sc4VI9UqfAYafmGrTfDwJzJTHuCXOVpmtViodTtODy+f8AAAD//wMA UEsDBBQABgAIAAAAIQBVTXRWPQ4AAAmEAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTEyLnhtbOxdS2/c yBG+B8h/IOa0wa5WQw7nwYHlhSRbXgGyVpC02XMPh6Phmq+QLVlyECBADrklhwBBkACJ89rkkM0l ewmQIP8liL2bU/5Cvurma56iRhzNSKYPFjlsNruqq6u+qurHo48uXUe5sMLI9r2tmvphvaZYnun3 be9sq/bp6d5Gp6ZEnHl95vietVW7sqLaR4+//a1HQTdy+gre9qIu26oNOQ+6m5uRObRcFn3oB5aH ZwM/dBnHbXi22Q/ZS9TqOptavd7adJnt1eL3wyLv+4OBbVpPfPPctTwuKwkth3G0PBraQZTUFhSp LQitCNWIt0ea9BiUmSdOn/5GwWloWXTlXTwLg5PgKBSPDy+OQsXug181xWMu2FLbjB/ExcSth2K4 2Bx7/SypiXUvB6H7+BHrgjblcqsG5l/R/3iJda1LrpjyRzP71Rx+MqWsOXw6pfRm8gG0IP0oUSUp miSnmZDz9vWP//u7Xyh6SpYsy/DugW++iBTPB6FEv6TPPLxIaiOiqf5gqPCrAKzhNnesuJx8KBiS lI/AVMEtfrnj96+I8h7+UiWs60F+ts+5P7C5MvA9fmIyB1UadfwTVeYLOxE/4VeOJbgHGllX1BGi rxxG4mx5G5+e1BTm8ANx/2q4sXtYU/p2yAWDlcjlu47FMBDiPuCP9z08tkwSMsUfKEwZOP7LR+As R8fGX+jd8juoJ65CNPpW7X3vhWUFGGbK/pHC+n1IefSdseZaXv+Ihew4/U7Mh5QvMZ9SvlAfsy44 io5LegmXUo5mS1MrkaY3P/3b13/98s0fvlKa1GkYX1JcxHV+kORlQum9fO730dkM/V8jxowNloah tbQ6RBZ9p2tqvd4cGzhqU9NJThQaPnqjo8oCICWpKQgj/szyXYUutmqhfTbk22HovxTfYxcHEXqZ dc/68Shn/c8x4geuA4V3wRylmcjhaBktX6bd7NRbsazGNRIz4y9T9Z6/ZzuOkFrHU15CvJsayDIZ BtgA+g2XbgBlE3lnJLxnEE+Th6KJke/YfXqb6onCs96uEypoGQQY//b24u+OFKNPP2HRUJYTj6gY ZNk/9/riamix/lOvHw9gD4q/Ru1yrX5NcSx8n65ESc5sp0hJkOx49BFrMMBoAmPxupAhqS0SsUrG M5kk9MjQD1/h0yGxIvreOQvREGffi7ZqbXQn+oKLm4ZR7+AmzD/p5Z945+6uD65QIe6IS8gF80x8 QHIzvtnluEcp03cDxg+8k8Cke2o58e308jMWBrG4cGjoQ/9kyAIrkxciK19W3GYKbVJHQf0pLgsP SOfQxbG4sL0+rJO4lD3uQE9Zg1PWO3m1VWu1QXxD0CKKWOzA2wlfiJaTmtwWQtJjEbELJs6LH+ML Q2g+qIejc89E9ZIyh8gUEhSYRyaXgqHS2EmUbL7EjjUYL5sUiwIze7o9EIMHv6V15srFT3vnkNjT SyFLvfOTV+nlHshIbw4hgbG49WLRAY+liQipMaTjX5y7tut/bguOzFX4EViotkgz9ATL5CvnWzUp 6REP7RdQPJ5/Iq7ioSgfkkVijv3K+lh8h3js2ASMUFuqMEcMCbVPyn460NPRMDIwC47f/AhCzdS9 YqAOmIlmvO9+vuFwOTgtlnvw9ud/f/vl79/86Zf/+efPakpgc3O4x1zbgW6EvjKHLIwsSMSGqmny bTPKvb0d2gwimBZLehKMJ/r4Y9e/sGbbmSl9M8PoVH1TWt9kdl7qJKFwE0Wb2m/zEqNfAsJdupT6 GBYaQ0pAXJgiiXG//tVXb3/yR2nJv/nXr+n6L18oagYS4/cxUgnxZtg3Vy+hvemWHcDKDr6bqKQY EGu61sBIFTa+YRh1oy0QRAaOdc1QjRaaSDYeJj6RyxkWHkObkZHf9T0PZsgPpQIUdjnT3AQJSKrT 8UoDuCzDvLeX06sj43+JhpkJUCMpnGOHIRSpOKQX3kWu/3JykcK7GXKRYb34/VvIBZSt7KlULlSj AThH2A/epNEelwsD0FCAKBRQO6qhyQJQvJVkjEC2BSRjNuJX24muOAU22vEvFVVA3xTxK6R+4NMK v3FUSSSahzQEDb6kn+Ieb9T1TtzfzWarKQd6pgdaaltv4+tCDTQ6zabQSrO7m1y6aaBtYujPw6gS l0pckMFKanwUkNe6ZwuUm2BaejCJ/1L8UhyyzIUaIyqlIKSYDSLAwdTEH1pcnW3iZfOLWPV88wWz FnBi5ra4mOGbI8aIeUmTl4pxmzBRGWKs1zt1HfYKeqmtGS11zJ5VckxIeilSkZfjxrshx8aEHHdK kuNWuwkPNFHIuqq1BfKqFDKi5bkg4tIFWXtAgnyGMM/QNvdCRNSlC/Es98u4X9JIscY3v/3z29f/ UBoZ1Bh/D+G5XE2zItjjb43ik8mnsxFKxzAAOmMnPA7Maw2MEtL8BFFUwNdOHF0JUqgTN5KEJr58 wjhTzkO7SEZjLL/CWQ9hd6qL90R4EH/gew1shLGOfUTzEOXqIa8TX4uC9IoIoe/3H3+/uatpTV3f 3mg/fdra0Bu6trEDELbRae482TX2nqi7je0fCPHLvyZ+oC/FX34W2kilEEF2H3E38qISTkh3BM1K yvBQGcKLa9c7urQBXESlEpc1wVF4bxqQIs+yQCAtzAfSDFVHmOu6QJqIQC8eSCN/L/FLZwTSeBRH bUlmgLlmBdKmlLtlII11EVY8lr76ZEztRpj0hRVSChH+GIScIrZxOI1CqPhpaaGy2R71daEyb3qo 7H3X27CYHL4jUTB6YEZxH6V4Yu95V2SF3ts/Uj/49w+/GM+3LIbw3yVuQuCv3Fy08TNEqCkDjZTu zECliFLm3ZP//ej19nFZ9rAw9zc0SgKVG/tdkUBPuk1QCKRrSbPKLEQY27TxDOKMzOpIMBdMKszV d42hlYq4icI9gMKFrh2DvhUPr+NhSWr2N9C0+0d3y/2HomZL6YJ1MHMCg4uMfpolgTGWuYXZIci1 sWxoa+ZWcFO6K453QP4JBTNggG43/6KF/HIrmfcxwpAlpnkk4J42U0P0zYHstOMHTeSxJPL0QRN5 KoncedBE7hCRee0ixykNXcQF6I8w+bePGoxg28VgxBR/d71mg4BdqcO6fax2SzHfU6hempdPQZTp E9qu8/KTCTF5FijLor/MXl/cWk4j+XibAhTjwYnM6YsnyRbM4E3p+pR0qZzGR+/ysEGO2oycdM5L ZekfKJypLP0iE4PXEZgWsvRk8CmTgb+57Ej+Hte00GE0izR+Tys5shITWaU09Z9klbLM//h7aTtE xmpJWaWRRGun0zD0Kq9EcpDkjO4mr1QCQlxV7HNx3FROdoTWyzyMzMgqOFlKvAjxuueHI4AXOlRG 9gmk3fvw/n3rmEmQmnTHtYmWguj8GmVzS6S+Cn5DYifZRpAgXTVYRfEWXCq2joiwwvbvFLanWN5t 5/6UgNHmBTUm5vXdfE1XufGcySzQOxC67CoijKWtbxhrceNYhbFyS4th2pGOk5HEKmF1o6Xf62jP q4SV8L+goQmzLj2Mhfmz8QqWJIxl0MwtsYBl5WEsXdPbhjYvjBVPAaa5sNXs6CTStRYIKfUcS4BD sy3l3NVdaRrz+WE5WcwVpCyLEVhOknKdumz/SPtgJBCFrDTZePTp/D165s0kXRWB5cRH5dTxtWbK bL9lUo7LYcoyZnfebzGZtrAgC4jdLHefckLCa/o/P83mukT9gno7a60AQbSdVBW+q1Lzxbazqnya Fe3ZtTOuHaZNwrsbnwYLFuWq/NingZOzUp+mkVvLr9bbmtYR832zNdDJQsdqyWfCCbm6MZe+l04N tkRQG0aNRO3GSz7XM+xL26Ba6WZ8vTPh7WKYjMwEX2TiYm4/yjHMmNnXm0HpKUHvUj2islmR0Zng iMLZ04LL1B4uR27vbN0L3pTjhNzvmSulDLvFGVnWxJX7utDsIbB/MsOY6d6beZzXzEfJ7M3EOr/i LuqKOQ7jnnEnsUwlebipdw5Lt7LdexdMxq1F24+lGN10UdhatL1KnQmgK6DLWuRApkCgNKK21LTI Iv7C9nEjnjMx5i4sBgWn0D5Hea8dN3YPl8WF9ZWAaqqMVP7V2u57P4tkQTM+EnQZ2RK1CitXYWXs fj8aVhaxutVNlWngYJNOfK4J9j9X69q8sHI1VUbsoCszENVUmdz5D2BJOlVm9zDdoq4UALQqzDc5 3yA3aTZHbSlE3g2kK0bSes+aqSaIIHM1AixuMkdi8SBrfoiXIyHrJPNTttLMImw3iz+mZBUPJxY7 TGvu6M1aW3I88H4B2gUDh/eLyMo1eacWrEm8KYZ1vMEEbdWdv8f15GYU1x2qo+NQt3mHLeli11vh m5R0qM7UY5f0Js5dMrDBOrYq17SWER+nks1soRPyaBvzht5piiMFwI9kO3TKUOQOVayOXEq2RcyH b9NjZXCRCkV6MePIJV2/Rjoa6YSoW0kHGcn42J22gY3fMTVHHLJZN9R2Wxysk0kCbZRIktDUm4b4 /FpLwmxYtsS82gJHLMU6peBRCNrEap/smI+VrPbJDmvStRYOcKvW+uSmvN2bHWtS0LzUNM5cBJ26 9NVan6lHV48vi1mnLqPTEOaei5C5R5UzN/UM56LZiT5Oc5Yb8y/9COeV+XJ3SOPKXLk7pHFlk0ru kMYdwrHpFB7y2MQ+3+JCeGq0fzDd3Xg5tkDvp6GFY6oIv584fbG22gmfs+CTC9TKui6LuBViBjh+ CnCUiVzLbGZFAmx5wrzI5rbviWUM3HZRjiriHg65pouAoS584NSTR/HimJFznE9Oh4MPbM/mFk4u siLO6Kh0z8KR6fAP/L51ehXgJGjuHvu+OAkabRQ14W9cNV3Fn8NlhPb/HwAA//8DAFBLAwQUAAYA CAAAACEA6VZru9wFAADzIwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU2LnhtbOxaW3PaOBR+35n9Dxq/ t9gG35iQTkubbmeaNrNJf4BiC/DUSF5ZIeTf7yfJFyCQZFi6G3Z4AV+ko3OOP53LZ5+9W84LsmCy ygUfOd5b1yGMpyLL+XTk/Li5eBM7pFKUZ7QQnI2cB1Y5785//+2sHFZFRjCbV0M6cmZKlcNer0pn bE6rt6JkHPcmQs6pwqmc9jJJ7yF1XvR81w17c5pzp54vXzJfTCZ5yj6K9G7OuLJCJCuogubVLC+r Rlr5EmmlZBXEmNlrKp3DsvS6yPR/Vd5IxvQRX3yW5XV5Jc3tb4srSfIM/nIIp3O4xenVN+ph5pRj GA56G9OnjSQ6XE7k/PyMDmEbWY4cOP9B/2ISHbKlIqm9mHZX09n3LWPT2acto3vNAtCgXVRbZS16 bI7fmHOTq4IRr7XKDqWY+lWkPyvCBezU5lvz0m+LRpi2WYsvZ0Q9lPCM0qLqcfam8UczvoJPjbPU 8oPIHrTht/g3F+mwqNS1eiiYcQjUpkMIxw/cX1CNUMbf/Lh2SJZLZXxEqrkaF4wCy7Ub1fmYKjYV 8uEM/lB4HLUQxrMrKumfO2Vp2+gQq0LhRjscWvftduKgdSKe4AexJP01NxItCo+1du4qRlZ9os3c QMebOE5cCxGv74WhbwR3QBkM3DiIEodouPT7cRAMjN87QaWs1Gcm5kQfjBzJUuXohejia6Vqc+sh +jIXF3lRGN8XXF+oRJFn+po5kdPbcSHJghYjJ3ZdNzYeh8tWhuFMTzVus8BoPNk8Z3IvKaDEEV0c IlUxFhDnGrWq8v2dgg61ahYXeumXwuJWS9oBjqftgTnueFy7b90egE/PVefvswxBpCKUpzMhWUZy TtI7KRFWCGeKiAmhStF0puPVC8G3ofHeSnbg3g/EwSaIDZQQGe1O3x/Eg8EggG9NoNuO4ijwQh+R 6ITiOrhtYGItxO0NkN0o3kDq9oC7v04XF3pvPb2zuFDkF6uhlXhug/+P9nO4uZ+DAyWl2PX6djf7 A6ScMNFyu5zku8kg6R/pbq7+uqPy2LLSeIbCCHU2+XJFqM1QG1upyw3rRdTGnt47tHTy98s9HvBk q+qbuoIyoDpA8glQE/kRCjQUSFvh6iV9lFXYLKfk868kn5+MlceN1bYDbLAK9CICHgCswGEc6r3w BFijuI/+/BjBepSx9VIsjhutXYNfR1Zvvcf/B3V9GPiIngat/SiMos3u1EsQek/d6QppsZFvD1zX f+EgRdDggx0znSiZFOL+2CoB4Gm9EvD8A0XXMAKB4oMs0VzJNrz6buAGIcL7MUbXI2RT2ro174D7 KuGaLvl1zaCO9eEjTrjlTq6VpPl0psh7KcU9GQvOsSGFJF7HprQiQJspnBhaGRVqnoEjNGBHM8Wz 5g5KU3PHNtCmymglaJq5I5xXLmuOldzeX4oMfCwFpWbYNc0uIijk5R+ajNTVfs1Ce54fBQlWwtbw wiDwomi9qUtiBHLoqHcGKpB+YvQE1dcQlhs8Y1X7oXWAXW4H67jCtsEn+n0Ca2lGmqbg0iztvMYz apqR3ENfP9LkUqopxQneDeBwXoKor/jUIbSYghdOlTTWrq/zEjITZDDY0Y+0mlnS00iwrpHijmem 850xmn3iWc1+240Ixaq5QwqG5XFgximaF904qhGib9SEKR76ZAKw1LysZp01zsCjpg382gO+WHnW IOiadxOoDG3w3I1D82DXUbSKQyB5Bw51XXpIIK7AL4x9N0ZdshN+fhDXYfkEPgOlVwg+v+2LdoLP 7xqlFr9rsU5j4BdhzPe8oJ/Y3mpriPN83/f69buUE8xeLcyQhZ6JcbYP2R3j2kj2ONmi2DwoALdm 2yD04yC2jRMapMh71Dh5ySB2aygmiRu27Pkp3dLhq0m3fvQ8FEOd4feDIgDyi2Ih8q0p4QzPtA2A SYh0XNNMJ/z9N6HQvEC3H6PoGrD+PiUt5CUtvy9QGdIhPrtRTKJUxiVNqkJRPbQbomXgu5a/AQAA //8DAFBLAwQUAAYACAAAACEAWDGkKO4CAAAzBwAAFQAAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbMxV 204bMRB9r9R/GO1zIBBo2q5IkJpCX1pAED5gsCdZC99km1z+vmPvLqgQVKr2oS+Jb3Nm5vj47Mnp xmhYUYjK2Ul1uH9QAVnhpLLLSXU7P9/7VEFMaCVqZ2lSbSlWp9P37058HbUEjraxxknVpOTr4TCK hgzGfefJ8t7CBYOJp2E5lAHXjGr0cHRwMB4aVLbq4sNb4t1ioQR9deLBkE0tSCCNiSuPjfKxR/Nv QfOBIsOU6F9KmnJn4kbL/B/9PBDlkV19C/7GX4WyfbG6CqAk81WBRcO0VMNuoztWppaP8WD4LHzZ I2G9WQQzPcGae4PNpGLyt/mXg7CmTQLRLoqnVdFc7jgrmrMdp4d9Aq7gMWnuqu3oZTujvp25Sprg 8LGr9ihy6Hcn7iNYx33m9tv2xMWqB8s9Z3jfQNp6ZiZlqO5cu1n46M9H5rSQlTZfnNzmxu/4vyxi rWO6SVtNhRAuG2sG5x+mX2NWKNm925sKpAqpcATRpJkmZC13NKbpmW3QCpJg3J3SKm2Bp40LLEZY u3APKpEBZeGECUt8X32W36SiwLplBexIKY35Q7AdICAa9InCMySy8goDXr/KQb4TrJktJrpnlYft tb9++Uf95c+cTfw04EqjoMZpSQFGfycFJVnIvVr+OxXUIGmhLIEPLjnhNESnH4qvADsYICwx0Rqz cF6oCDBGtbTZk9ptJfci8ZqzzwUHca2SaLLuUoMJlg7uaOsYc52nDUaek4XoSaiFIjko6WmDxmsa ZIlen89gfPD54wDGx+OjQcn44fB4tA/zgNkg2ayJirS5LicUF87wKvFzbKgTflcHqAioo2PcvSjY sUEtmAkyHIGeufAhh+//Q/0VGbaeysPeZoUOP9Bfrsrb5q8Ha35WljxT1TnM0xEWtTK8kV0m2e+R XyzbDbbOPLe9L8sHfp3KlpvlB14BG37CkCaVJf7esdidpHlrUebaudR5VEHKL6eFzqMuXS6evws/ AQAA//8DAFBLAwQUAAYACAAAACEAmAsLdKcDAADMCAAAFQAAAHBwdC9zbGlkZXMvc2xpZGUzLnht bKxV224bNxB9L9B/GOxTCzhaxb2lC8tB4taNAUsRLOUD6OWsRGiXXJDU7e97SC4dq5WRBO3LiiJn DmfOnBlevT10Le3YOmX0pHg9GhfEujZS6dWk+LS8ffWmIOeFlqI1mifFkV3x9vr77676yrWS4K1d JSbF2vu+KktXr7kTbmR61jhrjO2Ex1+7KqUVe6B2bXk5Hv9adkLpYvC3X+NvmkbV/Ieptx1rn0As t8IjcrdWvcto/deg9ZYdYKL3SUjXyKxetDL8un5pmcNK7/6y/aKf23g8280tKQm+CtKiAy1FORwM ZvGvhhkW5T/cVxlJVIfGdtdXokJudJgUIP8YvnASFR881Wmz/rxbrz+esa3Xf56xLvMFiODp0pBV yujf6VzmdJbKt0yvn7JKpgKu96beONIGeYb0U3r1bJfBQs4Bvl+TP/ZgxgeowS4dRj6yvQOnkSx/ eG/kMST+iN+4KarW+YU/thwJQdiiAjg+oL8VQaGsX31aFCSV9ZEjcp2/aVlAywON/vq9qDcra7Za VnQ/JWiZbqekND3c3vz28+XvV+DJo0wRHF/cgxBzPFgmwl6m7adM243RHqKieStqXptWsqXL/0ai kpBA5vlb+As8abTfu603jfLUILZFLVqU5M0v4zGk1upFXz+w3NahhXALdiNp4CDVIGD8LyW4Ay9W s98buyFIKLYdTYUWKw7dTD/cT3+kZqtjKBV14QTDIhZrw9yHtbcoJJmG/JpRvmeIbUbEodA0nY1o CZunbaXTIEKagD7SI5OgR6XDlMuAd3MSEoPQK8cSS4kB4UqMiUYdLohHq9EFnSjly1pki8GGEXFG kx/Mu28EOwNCxtKH2fyCvImcIAXI3EfeUvw5ueks2AZ20LqSYS0wXEAVeNkLK6kHtewdSXbwBwED ZKDyzpNy8KyhIGta6tF6/FSs0SkrqX9iE32ZoDM53aaAQg7P5XF7Io8h3CSCmvug3yiVIZ2oFlM2 1nSZmNOCknBOrU7yvKBHESoPpJf19UxI0ISCoc1MJeaSsME1+HOmYzLRJkuf2yT3yP9Gm72jtdkH 41yIcHcuRqqBskNVIvboRDYnbLOWc2HFw4vDMQzrF8ZbnHLpscMyv391a6ei/7iLQxfPOlruJm6F fhxG/2cTzEzV4SCMf6/vHWYq3gGRnsylzg+m3KIr0HtoLK08F4RG88L6SaEZ/YdZCoUu09vRPRjj h8cjIoXBnKDDarguBI8H+28AAAD//wMAUEsDBBQABgAIAAAAIQCBCL3MAAgAAPk/AAAVAAAAcHB0 L3NsaWRlcy9zbGlkZTcueG1s7FvLbhs3FN0X6D8Qs0rRKLLeD9gO/IgMA45jyA66pmYoaZoZzoBD v1IUKNBFf6HLtIuiH9Gv6SJoV/2FHpLzkEaWo8hSZCXyQubMkJe8l/fNy+3nN75HrpiI3IDvWKVn WxZh3A4clw92rNcXnULTIpGk3KFewNmOdcsi6/nu119th+3IcwhG86hNd6yhlGG7WIzsIfNp9CwI Gce3fiB8KvEoBkVH0GtA9b1ieWurXvSpy614vJhlfNDvuzY7DOxLn3FpgAjmUYmVR0M3jBJo4SzQ QsEigNGjx5a0C8zsc89R/6PwQjCmWvzqSITn4ZnQn0+vzgRxHdDLIpz6IItVjD/E3fQjRzc0irnh gwQSbd/0hb+7TdvAjdzsWCD+rfrFINpmN5LY5qWdvbWHr+7oaw9f3NG7mEyAFaSTKqwMRpPo1BJ0 3r/75d/ffyXVFC3Tl2LsSWC/iQgPgKjC3+Bnn14l0BTSCn44JPI2BGmkKz0W9zMfNUGS/hGIqqkl b/YD51Zh3sN/BYS2Ofhn71IGfVeSfsDluU09gGxt4U+DHO3sRfJc3npMUw840raGIbBXHlXszHjh 9blFqCdP9PPbYeHg1CKOK6QmMIl8eeAxCkGI90Du7jkOOCUilNvDQDCHPOnu4cEhZ4L13RsA8wJb c9E326C3xHbH8/YeODvgxCA0Kg/CwuXEvhQCDE84k9eBeEOCPqFSUnuopCm3dMadMypoN50zplRK uZiSKeUUF9A2aI6tTfYRTcNp0/mt1EgY7gLcvh/ckFJdbSsk0DAUUcAgA5rPlBhlAjXKP4pAOVGq bFWbRpzKtVq9VsoJVb3UqDYwu5KsSqVZq2lWBw4JmFBE8ogFPlGNHUswW1pqGnp1EskY3biLes2D jut56r3C2khAQoiER8m1oJAZDj1qESG9g8BTjKaGR6Hi8o4bQ84EYF6ejt6CaHUICempOabwuJ46 8FxHLV4/iEHvwBPkiqql4a/TicUsGu2mlC7X4t2nNuTxW//7gifjnpA3BUrunjJZmpOxpi5/KSvO 2H1ONm5NsHFzQWxcb9RqpUrCyNVSubFh5DuU9VLYYpSRy58RIw+ghoau3RHwXIwncDTyxugu6N/Y xamkOvqf3/58/+4vUslUdH4chZuRwZ7mKeRHjev1ya+JSo6dpBHN3my1Sk1tGzJ3qVyBlFThySjV Xiq1Ks3YVQhT3R4vUjFN3DykkpJL4c7iOeb8WEl7cG+0xutpHSp7HkjXd2EdusG1sl2kB4chbuuO aoh2VY6d3R9qB+VyrVrdKzRevKgXqpVqubAP41Vo1vYPD1qdw9JBZe9HzX6jw/QLNVM885Fw4bIq hFwHhoVg4oQSxlphWUkfKcgQZq+x1awa8yNtDSXngGEcbU8aIFg3eD0DOElCKblZvay8SrczWxiF 9geMlMfVRJmRxbr0mzGrpGMPlpqv3sB4p7Cuo7aL9fuw5caIA8xMluyYw9PBKEQaH9IDU3zMGbDv 0Yh5roqx7rXXqyHFpInU7h5+8tyQ9bzf6/5yKKJF9INRyLrTI7WWfS+4fnJ8Vnr6909/5GOiL4AU UDe3/ohv/B1yHiqbgvRE6Ep72KG+68E0lWGhhlREDNFFOe86//fzu+OznKpZAu0K5ZoKpO+JDlag bRZCwL3uojy2O+xUpqknCKhN5kqMVaZ30yAGQVhq0qVtXAWPnyjfQAUS2HiNXB9GEE0/REIr4gOV IFHW3ZbCGrO6UPbwaQ5pNDTxoTarsQsQXHJHOwNDRp0XSI+Y3I+JdTGfzxyLeAxgVUv3lNT1ZumJ oByLNoTtruPau2btF+u49guz9v2PXPuYxxWNJhXqSErUdQSBfR3rtjrm2h9jc6zLCItuaGGSWvd+ rm7z6PZMz/nM4zfvdUvt5VuxBRiw5ZGALAv/NPc6lrU24prn57uCpeWh3N1T7l/e9cvsUxwXTMkp z+AHp6ivENsMnQWb2zGd+OhV55x2eb2QnNOArxeSG0uvNTUsvbL7KpWH/yPpwdFntNWJapbqVGnU /LM6Ms56TKRVca5ujo6TtGpDucX65Cs/Ll2HTtkuKa06dtLQbFZa1U1iVfFBkjTdJFaTc8FNYnWB OeZJP2KTWE2KD7TK1YUc5iefatZR2ZeTWO1sEquLSKy+PM2FZJkIriIyUQVzizy0yrBJxEf5M5s8 oCnPWWUOc84wIj31XOXaN9FBEh1AmD7T4/PlZYRwGtNei0RYp6MSoPFp3Fj8Pk/6UyfCyo83EbYQ bJdmb8bIv0mEZUWaqzsomdOCrddObkxdYuo+SSIMJWi5RFjr8STCquVqo1W+LxEWV9EhdYeUYFKp GKcC1fFE3NwUGIIWWRRiCtx1GcDSCgzTU6KlHpDNVkD48nQx56BZ5cknO/ScDcHFeHePacuOz8pP c4mC+fJNb5hA2UsJl94eXmg1m4s+uWU8vp6BMmk6Upv2rc8LjJpyHDvKfbCj2A9OK/uILu171ESZ 7tIuiyjgk0dNkekVHcuiyF2Fn1mU8HE5tlQjLPqofxL5kStM2WoXnENbL094c7g/vSpyvXZyE9M8 KKbRlzrNVXA0k9vhtide0vDVlXYLcOldMoGDQbwKUe5tAoKRLrgYKyiPXHWJRB/0S9dHP3XkLzmu o6hGSAELE1zw5Ha5c4m78S53cNeYu1LdG2W4jS9QM84Zbu0jdAocdmHuWfvdIDCXMGNIWGsMWrXi 6RQuuN3+PwAAAP//AwBQSwMEFAAGAAgAAAAhAACJMjmwAwAAPQwAABUAAABwcHQvc2xpZGVzL3Ns aWRlNC54bWy0Vl1v2zYUfR+w/0DoqQFay3G3oRViF0m2dgPaxIjdH8CSVxZRihRIyrP//Q4pKZlT L4kTzw8yJV6e+3Xu5T37sKk1W5PzypppdjoaZ4yMsFKZ1TT7uvz45l3GfOBGcm0NTbMt+ezD7Oef zprCa8lw2viCT7MqhKbIcy8qqrkf2YYM9krrah7w6la5dPxvoNY6n4zHv+U1Vybrz7unnLdlqQT9 bkVbkwkdiCPNAyz3lWr8gNY8Ba1x5AGTTu+YNINnYqFl/PfN0hHFlVl/cs2imbu0fbWeO6Yk4pUx w2uEJcv7jV4svRqIYZHfO74akHixKV09O+MFfGObaYbgb+MTh3hBm8BE91HcfRXV9R5ZUf2xRzof FMCCW6XRq86jH92ZDO4sVdDETm+96kQ5jn624rtnxsLP6H7nnrhaD2DR5wjfVCxsG0QmRKherttM 8RjkPWKaghU2F1Zuo+Pf8B9BeGFAn/M22FKFqOjfW9qHRdhqSqGCQ7xIJxwSo3nkLpk3XxcZk8qF FD3m63CpiYPlfYDD7IKL7ytnWyMLFuFDUtIBJciD0D62RiQyMmXWVq9JYsG4EZV1IP49BWTknDt+ 82QVsA9+InhDpLDsUvnfCX07JPTSmgC6s7nmgiqrJTk2eVl6lQQ5Bwa8ILOshG0LwTXI8n7y6xhF oM2iETck2xRPaBnjlzh0dAosK4IBWtvYm1h5m0JPVDPysUcorlmwd4ksdjLZpSXlBo+YzbXu4/Is Tp7DFpHaErMl+2vO0KlKtcl3lD6OTA5NFe1pD+u5lO5AtD0oiIdkN7YNxLjEBRKUp9iYRzvQO9F5 JuX72D6jvq9DBZ7fJRUB7coxFqZUZUkuFsWOxY+Hdk8wGmcb67n2BaOXo3FRHcGmwW2mYr8OzJAA n7lTehs5FZmd+pMGu1EE3uo2da//l96vTk9Yg7ZLwaOo8tLZOqn/csWC43EQIbyjJ6+qB5h0hDp7 NTmB+7geKDWZ14xGq9FrFlpjSN9v1zs0Pobyt1F5Nx1hfBmUf4sGoQ0dSKEHav1Pe34g2B52p1I/ EOYBmy5/sOlljeEY+fjlhKEgpGdgHjpa20geaEhL62NSLj7N78XgUbO7oWXvrZ0u7266xHIYOIV2 X3hzvU69DnN0IHeZPjWwIKJB9E4Eo4CqsRHnrWA+e4wvGLw4DkNsaYYJVba4CsAsXCNGBcoYij9w F6aZIRQcRgQradkNa/WNtaGf1hISNPbQcdWrwxLD/+wfAAAA//8DAFBLAwQUAAYACAAAACEAKY3B AOMCAADIBwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbMRV204bMRB9r9R/GO0TSJAAlapqlYAo tKVSGyISPsDYk6yF117ZTkj+vsd7CSINAlSkvux67Zmzc85cPDhblYaW7IN2dpgd944yYiud0nY+ zG6n3w+/ZBSisEoYZ3mYrTlkZ6cfPwyqPBhF8LYhF8OsiLHK+/0gCy5F6LmKLc5mzpci4tPP+8qL B6CWpn9ydPS5Xwpts9bfv8bfzWZa8qWTi5JtbEA8GxEReSh0FTq06jVolecAmNr7SUinYCYnRqV3 qKaeOa3s8oevJtXY18ej5diTVtArIytKyJL124PWrP60MMOiv+U+75BEvpr58nQgcnCj1TCD+Ov0 hJPIeRVJNpvycVcW1ztsZfFth3W/+wEi2Pw0sWoY/U3npKMz1dEwHW9YNaYCrr+cvA9kHXgm+g09 OVp2YIlzgq8KiusKysQE1do1h7UenX2AprVYcfXVqXUifod3vSlyE+Ikrg3XgiBskQMcD8hvRKpQ toe3k4yU9rHWiEIZLwwL1HIrYzy95CC9rlKd0ACaRKSkA3o72ruA/ByTUAolGEhYWTiPxtgKja0a Cy9uXk0VnKAQxO2UxLJJ9fMJ/9Ql/MLZiHagsRGSC2cUezr5t/RrheLtKuT/ZP78PRL+mKsD0j3u HdCVK5nO2/ztbeXtpQJlj2mHubGjUK/c+RvBdoDsH5DzhPE206snAY84Pjh/T+P6iPauRuN9EsY4 KSIrio4Ele5Oo/GtU0w6YK9yxs21hNm6rdTOtLZ5KNhSLLg92ziKO6AkRIWrJeoAA5LOWpbpV94t IvAtDJJv+kT9Y2PmRYh+IePCM+HuaKA3ISITDS8OvS2hXuyWNKieaZC6T5pBj2U3+6Xxv0V1vazz iSstsr+otyrE2o69RxN0nS5xkEZftL8CZgxmoKhHoZza7rJQCyRfW4XkWB05I4yAKHwcZpahFLoR yk+buVneOBfbwVkjpdZuoNOq/V0KHpfVHwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEA ACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4SPwQrCMBBE 74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/h dj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTW VbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2 6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTb BtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj 5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/ dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgA AAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54 bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrF kxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZI vjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSw mHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc4SPwQrCMBBE74L/EPZu 0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4 o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A 9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEA AP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxz L3NsaWRlTGF5b3V0OC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo 35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUW heJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQ zGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANwR 2Ja5CgAAxkEAACEAAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsXM1y27oV3nem 74Bhl61i8VeUJ/YdW4mTdJxbz7XvZA2RkMVrilRJyLHT6UzeoZuuu+ortMv2TfIk/Q4AUpRE2XKs OvG1vZApAsTPh+8cfOeA9ssfriYpuxRFmeTZnmW/6FpMZFEeJ9n5nvXz2VEntFgpeRbzNM/EnnUt SuuH/d/+5uV0t0zj97yUomBoIyt3+Z41lnK6u7NTRmMx4eWLfCoylI3yYsIlvhbnO3HBP6LtSbrj dLvBzoQnmWWeLzZ5Ph+Nkki8yqPZRGRSN1KIlEuMvxwn07JqbbpJa9NClGhGPb04JFVSXGLGtrWP yUanaUy/h+f686TYf8l3zwseHyVpyopcfkjk+HTMp3iki0dQWB6XUl+waV5Wt8vifDhIC3bJ0z1r MDg6Ggysnf2XO/RAs7bfxY9qaOGJI/ysecKmJ1oeWelE9WUGlyYZ47TYTk8/zsqIpyKmiZthmUnS 4MRoJCKJR6mI0CAc1AXBUk7PCiHoKrt8U0xPp1QK7H68PClYoppkGZ8AIWpaFZhq6muGarrdhcfP q5b47tWomNAwwAJ2RYCya/rEQxjalWSRvhnN70bjP7XUjcavW2oDFt0BJlR3SrPSM1qdThj4TuhY Zk4/ARkgmQrm1NPTz3C0cZxHFyXL8sEYdcRBUeQfx4LHoIXGWaFRddFEorpXAk02/Pg+j4Efn8lc cWMJEdsPYbCYfhD6IbiwgEzf9hzPxngJH9v2XF2hnjbfnRalfCPyCaOLPavAjFQv/NIs+byKoup9 6e+6gX90SKNcof86MptHVPd8MuFqhjLJpDYoM+UEDDKlaNkYUN2L6myZ/763Af/TjH3cs/q+4ytc spysXw1hkpAnTJPJngXg8aOxpzV+ncV6lDxJ9TUGkGaKtIv2RGtMZJNXh3l8TRWG+I11/1hwOLQM LtiCtUbjHM4ykoXuIy3lqbxOheoEZIUtZPEJL/hPeDJVxi2yzs+nBmfUAMGrLnCpCX4Lzd2K5mdk aIf5FXOpvZq2jBqE+ZG7fEC+uz07ANZEedsHo/0lzvtdp4+dxnAeV7augRWoTOeOpG+suWaDTZ7z bnRg8pr2Cb2eIFQ5sVgqsAHjokmVW+rdh0aqm1XmkJPh6TmG8suslHowbWx6cwhd8Am7BqzGYkPj hTGgr2OXV7Fr7kS9BXotkgq7BjHtLu6UqDodG0BlIlNB7YP95GvNxZ1cbevmAxdLbkTTbe6Dt8i2 h/c9UIfYC+ByPlnGD5V/nvECnih9l2H/UnO2mFRfPL/nYPpFs2TYLMlmk0EO5YPVazoy82Ug4dgI vnwy5fI4O51GlUshMz27+sCLqdmdJBzRj7mSXMr6ljYpXVf5fO1EiULthE8vMSDjOMAFvlssOU6Y hDxWjvTTuHP2wWJxUkglMlg5kYNUcBiMaUDuD9IkumAyZyJOJDMaWVEOUhp+mjY7CEN8EvG+1mT8 VZPx/48mQxhaEHHKxd/PchzX7vUwfAAYQoX0l1x2GIRdD15ayRSv69h9t5Ki23LZv0IjkpU9/YpN iJSHsqCyxYSUHeGDTJfsWXFGmdh97flURHkWY4O+FOkGHSv1v5WOz8ZJsXm/So9tpd+jfFbI8cYT Vjv1djpORjf0+xWqtbfqJHs3OMmNgzM2K0XxCrkMSprUQuJO+sH1+mFIbg5u0HF6gQeXqEQZsZwC 2QUt4bqh7yugt6glHo9y1fLvAFHvUaJyD1Vk1L6ptynW+8U//dX4x95yALQFTkFUgU1e6Aau3V9k k+MHboghm121a9tq231mE2mZm9m0mSSkaIiSFiYaUozN00TlB9UXSoqKOvPHowiZR7VXoPuyWVNw FaaMeIQY8eQ90qXHyc8WmyYyGh/xSZJijW2keaIxL0oBbd6xobn1PKBcqTO5/2HMJXvHxvxSsKRk eZZes2FOaScRs1GBHM+bPGZlzqSuOOHXDD4NtXM5Rj74BXvLDjI5zrNrRm6xZeO7uz/ut4hW+ybV +pAOOQh8j3JmtQlpUOeZRccL57kE1+3b/cCg/nh1qQnhnC4JchPCBV0X7DIhnC4xIZwqUWSebuyL 5xkFk676KnNaE3Hdw8rozCBrGNpbkV4KmUR8ydJc5CZqS6tClW1Y6Ak/F2zBrPjuKI1Vovwvg75j vzrsHnR8N+h1PLfndQ4Pfa/TP8CJgXPwKnj16uCvWDGVRyrhZgQCa4vguDV2VY5KJc1U2ubxQrjC LLn/5fO/fvfl87/nqAJQBcrXIDPn3OPFSO6vpVivO+h2+0d+pxu89kGxg27nsO8OOgM/eH3Yfe3Y zqBbUyzmEsYxEd4dOLaVzfAbm2kLx/44ywTz/8Ac5JJXiLZGea4kkJbUwqOm2nzO69NZ0ArV6SAu q9PUKC3e8ykbntt7ViqhXuUVruILXA3PHbqH0yp5hav4AldaM6GGuajuoLySU6aOW92B4NVFXnUH 7lzf8as72Pn0naC6E1hsjIPRC6Q96ZfFRnn6Vt+ormjnx5zS+Jhf5zP5LlbnSQt3lCd3bK9HgtzH SIpdOgQt3sUqZLyhLsZY11US8Ya6GH1d10QkjVEtjgHzquua/Praugid67pGoq2tS3KhmpvSRDeM t9+oa2Lxde0GEGN1u+EK4gtzC8CZuq6KfdaPIQCX6ro6Drqh8sLCVcF+Y8hm4eWVOoTDGT4O1+h8 QX2lnQPpKHvuR+jYjhVSZZzBq0weqOOWIS+F8q3lNDoUI7XjTKOTqHmuSYFCs/RgpN4vwL22eqY0 FiM6B1SHNSRvV/ey5gsJAYRBUMnahahk2RH/fvJLJ5W0KFDITT1EBYLrgqhsKCwqiEoqwET0sNSl wcdA5XwXULl0aLgtqA6KhKe3ysoVUAgJA4r7DAqRBkwhJAwo3jMoBhRCwoDiP4NiQCEkDCgBgTLh xTGSY3RAiX1FH3J/Q2f8PXgYwsVA1JtDpBPPzxApf0O4GIjCOUR29d7JM43gkwkYg1G/gVHohCqf 9owRMCJgoHYWtSHeoMSx+opQ1J7K9Zw+eaokQ3KHsrzVDY0nBMWdVSQ8H1rUAuzuSnI4O4JcbQi6 0+vJMF8WNguZaXMWOpwhkVuoNNqe9Z9/am14uzDdOGO+qk2zddo0W6dNs021qV6dHlaHTu/q1XFC v0c3vt3q4GyBrFC9fb180KDjFpxzzEytlcX8gHMGeu27XBKqiJXq9Gfbcv737w+4nLdqZL04+uXW hdVxQpXy/IarM7eAL5//sYoZvUinlq95FNS6lmoVgMQt4VllAiuYLUtogxnwUcpozujvC7O/rWJG 3uxhMFtW2Bozp+v31AuQ3ytmLTx7OMzaBbjj254yxWfMWhIh7Yrc6fdsJaWeMWvBrF2ia7X0uPaA h7PNdsnuhmHwXe8B39Sf1RK+Idqnu+p1iVrCQ9Se6GDIyNvVv7+YVzGJT5OZaGpH1Dnjw1O8UlIF 45XWF/w4OyxwMoF8t5K95iuepr8sgoA7mWURwgX9hxhmFOq4SXmQC1HQO2u0yrftnDiMoS13c6Wx kgjeltheTNog4niy+CznhLUOqUhSq9sni88abbuYrnnKBGoXsvZiruYpA7RGtapY6NlFY8taI1F7 nspoz/MfT9YHrdGj2HJVrPjspNeIz8DvLeZoniyDaqXZFJfqddvqHQN6n6b6/wv7/wMAAP//AwBQ SwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0OS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj 7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz 3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39U KB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAA NwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHOEj8EK wjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E 63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKa O/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ 3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF 9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBv l4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE 9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQU AAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlv dXQ3LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92 mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVm oAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2l M3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAA LAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzhI/BCsIwEETv gv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2 Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZV tVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbq a277AQAA//8DAFBLAwQUAAYACAAAACEAaaJfIR4BAADHBwAALAAAAHBwdC9zbGlkZU1hc3RlcnMv X3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzxNXdasMgFAfw+8HeQc79YpK26Qc1vRmDwq5G9wAS Tz5YoqJ2LG8/KQwSKI5CwJuAiuf8+CvmePoZevKNxnZKMsiSFAjKSolONgw+L28vOyDWcSl4ryQy GNHCqXx+On5gz53fZNtOW+KrSMugdU4fKLVViwO3idIo/UqtzMCdH5qGal598QZpnqYFNdMaUM5q krNgYM7C97+M2nf+v7aq667CV1VdB5TuTgtq+07gOx/V1fmy3DToGCTJdN5OB7vE84Hel61iylYh 2TambBuSZfmSNOevGc4O8jZDb98s5FiU8eitykOybMmAHpUFMytiyopgZnFDC6a2iZnaJpiaf+vj Pa1ZGrKtY9LWIdk+pmz/J6Oz32/5CwAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzhI/BCsIwEETvgv8Q 9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62 IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFp zoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277 AQAA//8DAFBLAwQUAAYACAAAACEAJ24TDf8DAADKDQAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQ4LnhtbMxX3ZKbNhi970zfQcN9YgPGYGbtzNRJerPZ7MTOA8ggLyRCMELr2H36Hgnk BerUeNuL3NhYPjr6/s73ibt3x4KTA5N1Xoql476dOoSJpExz8bR0vm4/vokcUisqUspLwZbOidXO u9Xvv91Vcc3Te3oqnxUBh6hjunQypap4MqmTjBW0fltWTOC/fSkLqvBTPk1SSX+Au+ATbzqdTwqa C6fdL8fsL/f7PGHvy+S5YEI1JJJxqmB/neVVbdmqMWyVZDVozO6+SepUwdty9217dIiByQMWXGcF z5MNT4mgBRbWpVBgID9ylZE1rbQdBlNXW8mYRovDn7LaVI/SbH04PEqSp5qqpXAm7R8tzPwUgOFh Mtj+ZJlofNzLYnVHY0SEHJcOEnfSn9hEY3ZUJGkWk5fVJPt8AZtkHy6gJ/YAWHA+FDmvGo/+6Y5n 3dnmijPinr1qoBRb78vke01ECT+1+417ycPBkmmfNX2VkSb8SlO1uOZPEw+Lr01MraHnSMyC0JsG JhzedBZGYT8m/nQa+a7vEB2ZKHQDPzJHWB4c0RBXsTr+UaYnHdAdvpE3KpKsRJ3uGkpeq406cWSZ xvzAXdhDKH+CkDhqgMYp23/BUv3X0kG1I0M76/cZjxTjucODANMYYcAHtnKqdcjEm68b6LBQa84o 6Ns0q9Wa58l3okrC0lyRT7RWTBITNqgWlml2Zc4wlEykj1RSbVSXWWeCxjgZvlufTRh0Nn6ecsSw L4JHThOWlTyFEZ4OEaRi03tjAeQpytfWyPjc+0EYTINGCzr5i4EgAtd1gWiSP/OjReQHY7NvlNVN VZvyQaZ9pLql7ADw6LXl2q2KqIu1AGD9C9hZF2sBwM4uYHW1NVntAPAYXMNaALDza1gLADa8hrUA YKNrWAsAdnEN2wAuaQg7CRjOYvmPmtIt1Uiq7mmq0Y0RDz7skaZwb5DxhiWlSAlnB8ZH0Btt3UC/ zXI5nt3XlXMD+8fyWWL4jTV+dit9vr/Ijin3v3azme1mW53qbiszAXl9K2tmmZ4gaOEYBRnlewdX ADQ4k0gz0/TkMw8bU/F2BtmhdGm4udNw7ntmeL1M/N508wM38hZm/qFOmwuD6evNnLWt3o63nzU4 UlB5b24YuUhx2dGPukJ2zw+4E5pdnZ7m9vqUnokaCyXq9tZSmRGNLjyKr9dPBz2y5Vu4M33qOL5e bxz00ZbP9UN3PpZw8S+91vJFXqRb/SgDe3yDftzyeV4E817DN+jZli+cmbF1u32Dvt7yabLRCen5 O+j9lm8ehK/Lx68xHyA6KzajP6N1+4aAFf1CYW5LXH6i1eeDkQzeoHCbW5ulCu9Mep4D+gLRVPYd bPU3AAAA//8DAFBLAwQUAAYACAAAACEA/+70YUIBAABwAgAAIQAAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQ3LnhtbIxSy07DMBC8I/EPlu/ULQeEoiaVeF6AVmr5gMVxmgi/tHZD8vds3AQE 6qEXaz2eGe94vVx1RrNWYWiczfliNudMWenKxu5z/r57urrlLESwJWhnVc57FfiquLxY+izo8gV6 d4iMPGzIIOd1jD4TIshaGQgz55Wls8qhgUhb3IsS4Yu8jRbX8/mNMNBYPurxHL2rqkaqBycPRtl4 NEGlIVL/oW58mNz8OW4eVSCbpP7bUuw9pf3QYD85SzRsCVjwgpLLrS6ZBUPAXWIMYPA7VGqobPuM fus3mLhv7QZZUw7aUcPFeDDS0tYSjQrxT76fnCDrKjTFEjJ6AtblnCbVDyuJIFNdZPIIyl9U1usT XFk/nmCL6QLq4OdSqqdYVA6xU+caX8GvW8oHGc05KrxPkKfJHjPIX8rgMf2U4hsAAP//AwBQSwME FAAGAAgAAAAhALhSHtjcAQAAwgMAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54 bWyMU8tu2zAQvBfoPxC8J7JzKArCUoA4bS9JbNTOB2yptSWEIglyo0p/3yUlJW2aQy58LGeHO8Pl 5nrojOgxxNbZUq4vV1Kg1a5u7bmUj8fvF1+liAS2BuMslnLEKK+rz582XkVT38Honkkwh40KStkQ eVUUUTfYQbx0Hi2fnVzogHgbzkUd4Ddzd6a4Wq2+FB20Vs754SP57nRqNd46/dyhpYkkoAHi+mPT +riw+Y+w+YCRaXL2vyXR6FkttWRwZ80oRYaGnoNrWbF6fTC1sNBx4JhQIsPSSfTHgJhWtv8R/MHv Q0546PdBtHUimBNlMR/MsLy1DONF8Sb9vDCBGk6hqzag2AsxlJKfbEwjJ4HCgYSegvo1qpvdO1jd fHsHXSwXcAUvlyZVk6L/5VwtciYf1i+qJihw6p3TT1FYxzqT/EmefugXsqQ50ftG/GX8jJsOsx8L PrKn2Swablw9JuG/eM5BUCbSgUaD2RAuGxST88D2G0h9jfbi8cB93dHWIHDfz+ZRtTWtfhLkBNYt iXuIhEHkLuBfwJQbdof4cWZKtPUeAvx8w5z0geKbueilQl4mC/M09QcvUxPlFjDhHvyuz3Xyz+Fb tznk+a/Mbr1CEsfy96o/AAAA//8DAFBLAwQUAAYACAAAACEAfs777ZQEAACnFwAAIQAAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbOxYwXLiOBC9b9X+g8r3GcAYY1yBqdrMZi+ZTGrJ fIBii9g1suyVhDfs12+3ZGE7AcpkOHKhhP301GpZr5908+W14KRmUuWlWHqTz2OPMJGUaS5elt6P p7tPkUeUpiKlvBRs6e2Y8r6sfv/tpooVT+/prtxqAhxCxXTpZVpX8WikkowVVH0uKybg3aaUBdXw V76MUkn/Be6Cj/zxOBwVNBde018O6V9uNnnCvpbJtmBCWxLJONUQv8rySjm2aghbJZkCGtO7H5J5 I2uY8cQjW8XkVwgcM+StYOrJmqdE0AJe35ZFRWWuSmHeqOpJMoYYUf8lq3X1KE2Hh/pRkjw1dLaj N2peNDDzVwAMGqM33V8cE41fN7JY3dAYEkFelx6s1w5/oRON2asmiX2YtE+T7PsBbJL9eQA9cgNA BPtBYakrO6P305l6TR6ecPBHThOWlTxlkvj7CdpeFFjuy+SnIqKEKWMm7EyTh9rx4vRxpCojeldB dp/LdOdB3mBSDm4xJkOumzJZdqHvc+NPJ/PIJigKg9ls2s9S4IfB2J95BHMVzBeRb0LupsASV7F+ /QMCwRRjQLCSVCRZCR/ss6XkSq/1jsO605jXfALxkILKe7M+uUjhG8OmIdg+wEYyy5Wyzd8AVP8t PT8YQ6DPbpZ7lobQbwmD2Rx2DuRkCOv4PStSNazTlnUxCUwEQ1gn0XtWpGpYg5Z1Mp1PwqHBWmQ/ BcjV0M46tJEfmRgGRWsC6NMiV0MbtrS+HwF2YGoPRYtcDe28QzsPpoNX7BAtcjW0UUuLnMOX7EAS kKuhXXRow9n8l5YMuUDA4Avu7AmQDxrjILA59mplRpf4kGKxYeLTj7VH0lxqo11EFfqWMwqi28ib Xt3yPPlJdElYmmvyjSoNQqNReRRuP4XjajO6jQHGBaFwuxeaVsiOyxmogVXnd3IWXE7OcMP/s6US gm+0zSiTkTSTPFT/tckjRmyX6Y3uB2EQ+ePAqP9V3OwHV/OruNX8Km4gMldx2wsI2CvQWLSe8724 5ZozYgwVeFlnvz5k0DRSNUZuuDOzpuyNa7UeBF6hHwujGZZ4dIjO1xn5RjFsFd35MWOnXMExf0zF OVxhBtcVkyVTWHp1BXy2SB+ppGjeurXLBnt2zYETljtKCA1O8ZIuGktNRvnGeWibUawvQwtNx0RP pkEYhqdc9DSIFmAgPrRsjRdB74zNrjluv4TGXDdYJ/ddLHoiuxCAdQBoOofaxaLb22MdALDOdnaw xvTusQ4AWCe3R7EOAFhnEI9iHQCwzvUdxToAYJ3aHcU6AGCtP+vltz+3XzVwg7fXSdsGdrHnGY1Y 0Xjwjl6zpBQp4axmvLd7QU4sc4/enPzOoH/Kcjmcvdkyg4O/K7dSZ4ODN9b0jODv8s1B9ksL2+KU sJmcfLz6vBE2e3I/R9esgQa/D8XmKmzOQF+FDWXh8Ea99MnUCZE7Fp+UuJODX1LsTg50Qdk7Oc4l BfD0QOdKYXs/ccLtGadq74GhiZfF5qqXy2+0+l6brwuux+H4f2seVXAhjmwAbSHI4S7YV/8DAAD/ /wMAUEsDBBQABgAIAAAAIQBSb6cRIQMAAG8NAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDQueG1s7FfBUtswEL13pv+g8R0cOyYETxJmmpZeoGSa8AHCVrCLLHkkEZJ+fZ9kC0IITTL0 0hkuiSy/fdp92l3Jg/NlxcmCKV1KMQyi405AmMhkXoq7YXAzuzjqB0QbKnLKpWDDYMV0cD76/GlQ p5rnl3QlHwwBh9ApHQaFMXUahjorWEX1sayZwLu5VBU1eFR3Ya7oI7grHsadTi+saCmC1l7tYy/n 8zJjX2X2UDFhGhLFODXwXxdlrT1bvQ9brZgGjbN+6ZJZ1YjWPMrr218BcTi1wEwUjBB6NuU5EbTC xOxRkrEUBjTula5nijELEovvqp7WE+UsfiwmipS5ZWgtg7B90cLcowAMg3DD/M4z0XQ5V9VoQFMo QZbDABu2sr8woilbGpI1k9nzbFZcb8Fmxbct6NAvAA+eFsVe101Er8OJfTiz0nBGoqeoGiiF6aXM 7jUREnHa8Jvwsh8LT2ZjtvR1QVrZLVWLa146PTxeQ1Mnlll+kfnKBn6LfzdJU67N1Kw4c4LAbZqC HD+Qn1Ob1Uwc3UyR1ZUZc0aR9a14ZjTmZXZPjCQsLw25otowRYyLS1vKAdQx2JyWkol8QhX9ucFs 46MpVobT3kMMGwnfFrLrhWyziUw4zVgheQ4n4vfJqn+jGiifB8hApIffgze0tXJtZFncjU77Tar1 o6R7tpFvSdxLOvFJQGzWYRSddZs1PJGLv9llL8nWTbNL8wWPXNXQNGdzq651P+533KKQdg2AYbwF m6xjPQDY7hZsZx3rAcAmr7HRCx88ANiTXVgPALa3C+sBwJ7uwnoAsP1dWA8A9mwXtgFYrdtqshvj igmWBAxPVfPO4rIdy9WWflFcTQFtLuly6oB6nrJMipxwtmB8D3pXZAfQz4pS7c/etSV8APuFfFCm 2Nv55FD6cr6VHYfIP21ryd/amtMEx6k/Cw48LTbamts/d1LYTuMG60fGlraW9JJ+3EHfQtv66Gu2 RFDaH33toDrdfmn46GtvXbL+o77mbi3NdR5De+l3N3aurmh9vXAnHz5zcEkcu6kaHzb28gfoM8Ry +A+l0R8AAAD//wMAUEsDBBQABgAIAAAAIQCp9dYvKgMAAAsJAAAhAAAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDMueG1snJbbctowEEDfO9N/0Pg98Q1j4glkpuntIRemkA9YZBF7IsseSaHQ r++ubINpkw7lBYS8e/a++PpmW0m2EdqUtZp64WXgMaF4nZfqeeo9Lb9eTDxmLKgcZK3E1NsJ493M Pn64bjIj8zvY1a+WIUOZDKZeYW2T+b7hhajAXNaNUPhsXesKLP7Uz36u4SeyK+lHQTD2KyiV1+nr U/Tr9brk4nPNXyuhbAvRQoJF/01RNqanNafQGi0MYpz2sUt212C0RvDvAnKPOUG9wavQm2HsfCFz pqDCi4XgZJyRoNDuqWmWWgiSU5tvulk0c+2UHjZzzcqcIJ2y53cPOjH3U6EYHvw/1J97EmTbta5m 15BhNth26mHRdvSJSpCJrWW8veSHW148viHLiy9vSPu9AfRgbxTr3bQR/R1O1IezLK0ULNxH1YoC qt7V/MUwVWOcFH4bHn/Y9DCKmfBNwdrUW0J1cu1Dl49e3ric9o7uM5FGURzGLh1xHCRhOj5OSpqm 0SjAfFFqwiAKk8RJDENu0U1mt5/qfEcpXeE3Vg4UL2rsUtsypbELu5NYZ8jkRoboEQP5jGMksQsg y8X6B16ZX1MPTaLNlSs8B8wASOli22tiufE8IGKyIcOU4AdCJNA8CnXxtMB5rOytFICGupLb2a0s +QuzNRN5adk9GCs0cynE6UUfiW6dDYcUKp+DBnJvSKaqQIaWMdV99HhsC/9++THf7SgsqffmErgo aonDwCIKEqelr/NZnUDZ93BssKf7xjmrIaJwEgRx8q+GCKMkHLmk/ldDrN5viAr0nRvQUuW4aehI NV29PuA6dfM6aBNcib3xrqFIFo8R9VaLGiUpimE+TuBRwIc2I0jHiw+8q3DkBuIk3njII0jHGx14 YZyGJHaag2S67TqMkigdMBkAJ9GE4jgDSJQOOD4Ao2iCDp4FJEoHTAfAdBSfXpOjkInSAScHINFO L8oRkCgd8GoAHCfpmUUhytvLifBYtf0WcnbPX1a0O9yuMkfL6r2F5PZS+zeLR/o/dptG6ntoHjfO F3wFwTV4664afOmgRkPRgwgx+peY2W8AAAD//wMAUEsDBBQABgAIAAAAIQCLO1bETwIAAJ8GAAAh AAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIueG1srJXLbtswEEX3BfoPBPeJbKcoCsF2 gLpNN3kYtfMBE3JssaFIgqRV6+87pCQHSV3ARrrRg5q5nHs4pKbX+1qzBn1Q1sz4+HLEGRphpTLb GX9c31x84SxEMBK0NTjjLQZ+Pf/4YerKoOUttHYXGWmYUMKMVzG6siiCqLCGcGkdGvq2sb6GSK9+ W0gPv0m71sVkNPpc1KAM7/P9Kfl2s1ECv1mxq9HETsSjhkj1h0q5MKi5U9Scx0AyOft1SbF15NY+ /eIsB/mGXsd8Tr7FSktmoKaBtYoaGdFhC2siKeWA4NYeMYWa5od3K7f0Oe++WXqmZNLp83nRf+jD 8quhMHoo3qRvByUo9xtfz6dQEgy2n3FaszZdKQlK3EcmukHxMiqqhyOxovp+JLoYJqAKDpPScrvO 0d92JoOdDsf44KoLBUq9teI5MGPJZ7Lf2RP3zSCWPCd5V7GOfExk+7juY+YxxAdimmHF/Vcr22T8 ie55EEod4iq2GjMQKhtKEqcL4deQGhvNxeOKGruOC41Ajd/Di/OFVuKZRctQqsjuIET0LBdD24Ak p0Qn0uL0kmjkEjz8fKOc/EFJM1PRQ4X02CH8N8irAWTfTWypQWBltaQiJu/DqiQ1xUD+PxClBWC6 0Qd07ySc2jYDDq8IdxQzSroMU2YbZyzqCoWlPaqxQX2CfCZ9hvy6Uv509au0jmeo39idj9XJxX86 V15tjqrTSXJ2b+cW784+ekznZD7etL8D99DkDqHfAu2oRR5y9CNIO4VCX0KSxvBjmf8BAAD//wMA UEsDBBQABgAIAAAAIQBE/3ulDAYAALQWAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDEueG1s7FjbbttGEH0v0H9YsK9VxItIXRA5kGXLSWEnRuwgzytyZbJZLondlWylKJDfaj8nX9KZ IWnRih1fgyZo/SDzMpzdPXPmzOw+f3GRS7YS2mSFGjveM9dhQsVFkqmzsfPudNYZOMxYrhIuCyXG zloY58XOzz89L0dGJod8XSwtAx/KjPjYSa0tR92uiVORc/OsKIWCd4tC59zCrT7rJpqfg+9cdn3X jbo5z5RTf6/v8n2xWGSx2CviZS6UrZxoIbmF+Zs0K03jrbyLt1ILA27o66tTMmlxfsSNFfoEPAEq dl3C8m1mpXAYfadX8MBzdgCK+EQmTPEcHpyiBTuRWSLolSlPtRBopFYHujwpjzV98Xp1rFmWoIf6 S6dbv6jN6FaBGVx0tz4/azzx0cVC5zvP+QiQYRc01TX+wkd8JC4si6uH8eZpnL65xjZO96+x7jYD wAwuB4XYl9WKvlzOIIoCN2rWdIoz2C0umH+5OvyE2Qt4WKHHwdlhEX8wTBXTlKszMdG6OE8FTwxa VKuPX6+asdqQNM8MOp2fHxUJhIAvbQHYNzO/hMYL+l7kQiwBCi/sBW64BVPo+kOgpcMQLA+uvMri EgQ+KrWxB6LIgQLGjh0tYktD8dWhsTjVjQnOQBWzTEqKhVTsHL32YYCtV3kGPGMyy8fOwMW/KnoI wb5KauopyD8HXZjcYVJAtsIFebY8k7fbwcykIlIsFjDreroYyoqRGJJkjQZz+A9wnmsO1KdhqwUY e2LXUtANxB9WClZcnsFUfl8aW01GqOSYa/4WXkkI5tgRqnOwCyLycez4PQR3XtMToSJmNyMDxSpe 3cKufsOut7AOGAPyLcDBIQ8blrRJBemEPLoPvdBXmdbAx1ZTUuMQlIeIF1202Yd4bKVi4LtRPyS6 RYNw4FIObJJyAHSLgGAV2zzXD70hjdE4IjyuD86VgODQciU9CiQfJWKB6CPgPQQcp90ywOs6khRD /IEFwU87ZO9OHAitPaQQfkw7p+/RDx/ZnanM4g/MFkwkmWWVRjLSRSgUQA8czNKQCNNDYwxlp9LT TYx7OINvFGOznFcxBkkmXULQUHMfEGvf871oSLO9Idh+5Hv9MHpssFnO9SEpfqYSKGN0WeUjcJZE Zr6cFcoSkRc8Bm08WefzQkIFy2ycznieSZQ6QDtOuTYCfNQsnS9fg+BQzCtCISLfmkYQhqdmkgcJ ts0kQv4GJt25BLGlEXoP2hnsmyiUyJe2JNxakILecAAqQArh+/2oB2pBiDd1e+hhBtcSEQSDMCRa QRwaqfnv1CNUH1NOoLbPsrrSVoUKXzSKRuhRbbquDoGoVSy+d90ZNiS6bGi8qyXn0R3NE9AJahwk c28QREFVSTby44dRMIApU60BSnmQFhUU/xMJsulrRLpTbaRq61GqUntDZC1gE4DtH93glkhMpWYr LqFFjWMQbJJaGN60LQVvyfXxEWyWDrN3XxPsDnSqdTChhONgdud9yi17xVK+EiwzrFByzeYF9tUi YQsN/etBkTBTMFsZ5nzNQM7AurAp7AafsZdsomxaqDVDRXx0Ub9Ohj1Su+9Ah6Mo7EHjvUmfCtBW +vQGm41BEAy94dXivWn6H7ovGIZ+SBW7tWP4+raApK5u/atUvl97L18p2F/BsrBFtXTTi9wAWgHd fjNvvSEi312CN9sDXZW1B6USSzJtQdcgPCa3Uyk4FNxqC3Ulb+jQ4U4ZhqcFqpVkL4VcCZvFfCvL gl6rLar3ZE+Sncf8TLArKcVHCzhBwOOAP6ZD39vbdSedMIj6nV7Q73V2d8NeZziZzmb+ZC/a25v8 2ZxHGDxnUMucqHNbA1+JFO2AHytS/zKEXzDL7nz+9Ncvnz/9vUEVAEW+3oNzG2Q2nCPKt+X5B6LZ jRTru1PXHc7Cjhvth0CxidvZHQbTzjSM9nfdfdjATN1LiiXcQnLkoncPjj1JIfz+OPbbUgkW/sp8 OBj6gmg3NJzbu+jtTuGHptpmzTdv9ekUozoDhUs8KaVdvNRHvHyzovSEs2I4AIPmCB6V0PBgOQPT jQn6aE6bd/4BAAD//wMAUEsDBBQABgAIAAAAIQCgQB3SaQIAANYGAAAiAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDEwLnhtbKxVTW8bIRC9V+p/QNyTzUdVVSvbkeo2veTDqp3epyz2orCA gGztf98H7CZK6kq22gvLwsxj3psZmFxtO8166YOyZsrPT884k0bYRpnNlD+srk8+cRYimYa0NXLK dzLwq9n7dxNXB93c0M4+RQYME2qa8jZGV1dVEK3sKJxaJw321tZ3FPHrN1Xj6RewO11dnJ19rDpS hg/+/hB/u14rIb9Y8dRJEwuIl5oi4g+tcmFEc4egOS8DYLL365DizoEthImrLWfZzvdYOeczUBdL 3TBDHRZWKmrJIBD7AWMlSLOV3MZsFtzKS5kcTP/Nu6Vb+Ox91y88U01CG1B4NWwMZvnXwAyT6o37 ZkSierv23WxCNVRh2ylH8nZphBPVCIKJsiheVkV7v8dWtF/3WFfjAYjg+VDk3RVGf9K5GOkUUc6f WRVTguuNFY+BGQueiX6hJ+76ESxxTvCuZSUFMek72JXNrMdoH6BpFituP9tml4j/xDcvUq1DXMad llkQhE01wDFAfk2pwqU5eViiwrs415LQAYN4cTbXSjyyaJlsVGS3FKL0LAeDfgDkBOpEJGeAlKZZ kKfvb5ATP6pxMoIeI8S0SPh3IS9HIV/VFFtoErK1ukEoF/9D3CQVZ9YrNEGpdo66RNGMmTlG8XSN AEVSCjpFt09/pIvpXj8L/Y/5SEWe0xFe5aNonoXHMB6ZSR1RAkspLPpay17qA+BzRo6AX7XKH45+ WRQ9WK9r++Rje3DwH46FV+u96Lh3ju6E3BDlpsQ03a35MtT+ltx9nxnjNUH/zfOSw/uR+gqmLyYJ Y3yPZr8BAAD//wMAUEsDBBQABgAIAAAAIQCO/6eZpAMAADoNAAAhAAAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDkueG1svJfLbts4FIb3BeYdCO1bS7LkixA7QDOXTZoYjfsAjERHQilKoBjX nqfvfyjKlmbiwnCMbhJZPvx4rj/pm9tdKdlW6Kao1MILPvkeEyqtskK9LLxv678/zjzWGK4yLisl Ft5eNN7t8o8PN3XSyOye76tXw8BQTcIXXm5MnYxGTZqLkjefqloofLepdMkNPuqXUab5D7BLOQp9 fzIqeaE8t16fs77abIpU/Fmlr6VQpoVoIbmB/01e1E1Hq8+h1Vo0wNjVQ5fMvka0dZGudx6zZnqL F4G3ROTpk8yY4iVerIrUvGrBfhQmZ3e8Jj+sTVOvtRBkrbb/6PqpXmm79GG70qzICOUQ3sh94czs RwUzPIz+s/ylI/Fkt9Hl8oYnyAjbLTwUbk9/sYgnYmdY2r5Mj2/T/PEN2zT/6w3rUbcBPDhsiprX bUT/DyfswlkXRgoWHKJqTTmW3lfp94apCnFS+G146cO2g1HMhK9z1qbfEMrZtV/afHT2jc1p5+gh E8F0HoYz9C0iH098P4rtXsesxNFsEvlIGOUmCmM/juwmHQmbtOg6MbvPVbanlD7jPyrHVZpX6NRn WsET2Zgns5eoM563MoBHjMsXjJJEF/AkE5uveNX8u/DQ79jyuYv8YI8iDzlIMU+QCPzBUslpEoX6 +O0Jk1iaOyk48K7QZnkni/Q7MxUTWWHYF94YoZlNHOYWnhHd2D0sUqhsxTUnp/pkqgVPsDNi72K2 aaB6nC76uCt6NwYryVORVzKDEyGlCMPSFfiiFsAEehgX9HLXMJc1QhTP49mv+mDszyYBKtRmoh2u XzTCyeqXXN/baSxUBmmhRyrl8+sD9NOu6vXEGE3hdnTdQ7Z4DKmRWlQUT8mKncMLZ30eQRxvfOTN g8g2/1k8smwzAqcI4njRkReMpwGm7EwHaQgOQKI4YNwDzjC9lwGJ4oCTIxBqAAcv8pAoDjjtAaeR rdx5NRmETBQHnB2BRDu/KAMgURxw3gNO4umFRSHK25p0Xe2IOu1Y02nVF44xdch7hYP0GoIJ4c25 3DgNsZKEqb5QQ/wwxmFB3p04TCb+eBJNXYP/Jg0JBjNKJ5Brhws1JBho0vs1BKLaG/kraMi8z7uC hAx4V1CQAe8KAjLgXUE/BrwryMeAd1o9SJxwiByuLrZNL7/hkGjYC04zuOGcusXYo7y9keORLvBW YqT+wuvHrfUFv1hwd7qzr2r8RqFjCqZHE2J0v3mWPwEAAP//AwBQSwMEFAAGAAgAAAAhALJyYLOh AgAApwcAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1stFVdb9sgFH2ftP+A eG+djzbLrCTV1q176Ue0pHtnmNRWMSCgXvLvdwA7VdNMcjftxR9w7+Gec7gwu9jWkjTCukqrOR2e DigRiuuiUg9zer++OplS4jxTBZNaiTndCUcvFu/fzUzuZHHNdvrJE2Aol7M5Lb03eZY5XoqauVNt hMLcRtuaefzah6yw7Bewa5mNBoNJVrNK0Tbf9snXm03FxRfNn2qhfAKxQjKP+l1ZGdehmT5oxgoH mJj9siS/M2ALYfy68lJ8UsV6S0mMtw1mhnQBCfhKFkSxGgM/EFpxJkmMJ1CMrMXWxzBn1laIkKCa b9aszNLG7NtmaUlVBLQWhWbtRBsWfxXC8JEdpD90SCzfbmy9mLEc6pDtnMLEXXgiieUogvA0yJ9H eXl3JJaXX49EZ90CqGC/KPw3idFrOqOOzoEowz29lMOAca35oyNKg3DQIfHkt02HGsiHdUxJkic+ +EGJthWcSxa1WSk0ytRluyh1V/9eoMn0fDoYJJlGL2UajaaTOBXEOpuOJ+Phx4jfgQA/oZrcbz/r YhdE/ok3vAz7ZU4FC7wTrHR+5XdSRCsgGMvBBg8ESxZ6TKiT+xV6rPaXUjD0YGubX1zKij8Sr4ko Kk9umPPCksgeHQnIGXzx2BYtpFDFkln2/QA5CMpyrIy6u3ojhSDqny0cv7YwbKSlZFyUWhYoJQqH Hui8+is3g3AHZqIjsF27rdDf1KN2Tj4MzuEnJf/LTmwwIhu59+0f7Q0iR3fdC3uThdFHPLolo0Zv 2FErwTXOJSkaIXvAt53Rm9G6rGx/9HFqkN7oV/rJ+rJ38Wdvha82R9FxgL65sWJ/pSMfn+GSiKe6 tDfM3DWRMa5HtPNlHDK4ENtz7zkkYHQX7OI3AAAA//8DAFBLAwQUAAYACAAAACEAtM9YGbsAAAAk AQAALAAAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxzhI/BCsIw EETvgv8Q9m7S9iAiTXoRoVepHxDSbRpsk5BEsX9voBcLgpeFmWXfzNbNe57IC0M0znIoaQEErXK9 sZrDvbseTkBikraXk7PIYcEIjdjv6htOMuWjOBofSabYyGFMyZ8Zi2rEWUbqPNq8GVyYZcoyaOal ekiNrCqKIwvfDBAbJml7DqHtSyDd4nPyf7YbBqPw4tRzRpt+RLCUe2EGyqAxcaB0ddZZ0dwVmKjZ 5jfxAQAA//8DAFBLAwQUAAYACAAAACEAaTBx4x4JAABQMgAAFAAAAHBwdC90aGVtZS90aGVtZTEu eG1s7Fptb+M2Ev5+wP0HQd+38XviYL2F49jXA7K9IE7Rjwdaki1tqJeT5Gyyv/6eGZKyaDly0uTa vTYWkFDUaMh5eWaGpD7++BBL5z7IiyhNJm73h47rBImX+lGymbi/3C4+nLlOUYrEFzJNgon7GBTu j5/+/reP4rwMgzhw8H5SnIuJG5Zldn5yUnjoFsUPaRYkeLZO81iUuM03J34uvoJvLE96nc7oJBZR 4jqJiMG29+/l9LNzO/98fTW9nbufDPu5xBhJWVCHJ/MlMQ8OvuN0+S3/rku0Rb5ZzWTu3As5cTv8 c08+fTwR55pAlk26Bf80nSbw73rH+DGBLJt04xFdFT8mEJ4HeZpjdzqz2XisaWtEqtnk3cdvNrPo a/z7jTlbsimmTKSagwa9pbMakWoOG/TT6bw3m1rzYSJFP2rQ9y57lxe2vEwUyii5a1DP8FssNPeK ZJ3Knw6SX/To0uQ7Kli/8iEaYp0mZYtHuUQTiy9pvgAh3UhRRolTPmbBWnjw2mkeCUnDiPNA1PpV l1fsdWF8i10cJW/Ke8cOI+2EY1FjW9J/rdeRF7CE60jKZfkog6uChSxSGfkLdNJ7jOagQlIWoqn1 atFtcsHvOHla/hqV4TIUGRSkMLkpNOtN4WRpAUDywAd506BQcqmQOyQ3VNosRPk59VV3vw7oig3D e8OhwgzUJwbPHax/+rrBumpWT6rNFq3LU2PfsUSrRIYNm6Khs9ImXN8RFKa7I8RTmrtTeEIGPuld BTtjFhratN/EREUo/EDbiORu2qjLRjK+wnEbvnPARmc89Vat1UYbE9tXjPYcI9WHGzwxnLHea6zE cpBFNXhYOftwlEkdnDJxvk7c8bA3dB1PZBN3jZiEZpzB6kWycR0hN0jkXpkrtz8KZlb8zppjIxi8 r4a4bsf0NwS24kCWF+WlKELlGvxIu4BMaCQ1/94Qan0rAZSn/4ZZ9M/gDH/YLKBH27TBeh14Zd3Y tR7SnbrVoTTdlkG+DP2vzkpu8xsB85OrQh4/KkoUVOYmn7ikbX5kB2cdGA9USjSakFkodLgliBok K3J21WoOfFebHmQ7OHcW7uWiMOQh11uIUnfjv5golE+CJOj7ZAEPZXcuHMLrxE3zMkwRhbIw8hY5 ih2OHfAWB9GF0rWD4p//58E9/VeYUzyIm4w2YXkTbZw8Qj4qwzwIrhGW2GRHmHV17lIsDSP2qNp0 i0xNexXcB/KWYuCIcrvrhHB1jiY6DDDdvv/Z9xpBqw0VOXW8WTGkyr0KA7935aPADKHsOMwFjdF/ NUXWll35qPf5dZN764LQg12ZNTCowGC1VDDWsP+NU3hhqlURqyFxb2gmBys2JUZnVRBlogwd+oP8 F+We3NW3t+kNYquDtSAxg9vAqz+owsOhqKI6VyicVKdyJmKlVFsl6F2yfpMyameCatw9ZdPMnmPv Fyq7Ks7s4SwsvqWytYYtXau+J1UNy+5DFF1rs5Bhw/AWRH2PIF19gaEvsT7bSrVrUGS4Yxxk17mz +opFBBYmYlumHOQe1nlMT9P12nngEPeoAxxy2EPpeOjsokhArymqzSvetij/EaT8urhHVGHf3fim JULT8h4S08y1HyofxF+oBH/hemxlcU5Op4ghbX2ItuikVtlmghalqri6PSxuXl/rlA8Hx3ii6hPn ebpNfFZLGAh/nvi8Ip64CfaSXIriRYzcEiC3oMF0pYjkcTqoRtWTVdGh3KiAjcmaq9R/hLWxrwWg h2n+DYMhvWGY/2xFjqHlPxOsQ8fdwYAMwTeD4WmP7FF/sqo/SbbxLEUIgTuIxANXZDrTnJXKjl4a w4BXyTLziJDmQsq5ffhV5JnOtiX86ud0SStkJjC+A6F2tOzeSgxiIgtVGVLbD9bXEC4W+RX7Dho3 3IgSH3tL3FSrAIkUHKxvxWr5TQtLApa0JYZtPnGVXOR33KbNgikvHFaiIPXQRsfucYhlJjburreJ x+x5RiQjNYrMu0Zs5Z02HYWUMVDeVhQXBoM72iqqZd7u6XSt9iBqPGt0+ulqi5Xk7QP7y2q7/FY1 aZ+muvkZPqZdamXQB23cQHV32ziK0y8Ryy55DR0kH35ZYgENRXVHBBUgEoZWJFvjsUWZR3cIH0m6 5JZGlHJnbObEQkbfgp+YL2kSS3RQg1sRlzMZCC6ilPbob5JSCWK0xcpsWa89Ab46BOAoB7eonCwq vXAh4kgikPUHmHco8iJga6rxlWrY7ZSDcXPnd/DOKpTK5NLY8z2mvnYZ/oRZ32Pqe0x9j6l/+piq Qymia7N0RZ2QC6S6Ja/gkMMoQ9id1OMZivdzMeS293MxHP287lwMDvVZZM5q0524OAZFgfyAFg5O URVtetTXoz60cDqKClgdaWJRpRqmB89VT0XTNz19QzMwPShJFPHQ9GCHW/WMTM8I2z103oeSnv65 jhEU2+BaZL0z1QRJs+cIbHpcm/9ex8nV4aY+bz50nExHuNVegCbQKufSsb6Ru1iMsXujtVEjUs1e g77TIe4WPRMp+uZx8hS/PfrW4+TLKV0W/wFNQvFvHicvFjOMYNG3Hid3OvPT+alF33KcTHrs9zX1 8eNk6xzfeBqXx5UP6ThcwYaBwbBhADFsGEAMGwaQtopxblpVMn7+v2HTfxPYVF82tHyFMcavMmIL bM46teOLI7Dp92s8tYF2btqEDe/a2TBrhQ2BbG4+TFD8W2HDu382/1bYTC8Bm0sLBq2wOa32AVGA qPm0wIZAU1nmOGyA4dnIfP7yPNj8ZbPN4E1gU0XkFthYLtUCm/6YLu1KR2Azu6DLcjv+wkkHtEa2 ORvRZdEfhU0l2/8ANvMeXdZ82mEzPsVl0bfAZnBJl6Y+Dpv5lC5N/g6b1m/+ht8dbMYLurT1jsDG CpDKrVthQ9Ddg8EfChvKZRdnFgxaYUPzf36RNpvRN5HPhs2sQ9c7bAJdiqpNg8NbAqPvDjZWRjgC m5dmG3xrPPqeYPPSbNPpDGfPh80L1zadTm2h+J5tWrPN6XcHG2tlegQ2tLbZg0FrtiHqKv7WKrla /WV9ZU9rmz3+b7622ePfmm3OpvPTl3xh/qJsc/G8L8z/fDtpWCfaW2m8LY1e/hTj038BAAD//wMA UEsDBBQABgAIAAAAIQDL+7cb1QYAAL8kAAAhAAAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3Rl cjEueG1s7Frdbts2FL4fsHcQtMshjSXLv4hTJG6zFUizIHbRa1qiLSEUpZFM4nQY0NfaHqdPsu+Q kn+SIPXitMVW5yKhyEMenY/nXzl4Oc+Fd82Vzgo58IMXDd/jMi6STM4G/rvxyV7X97RhMmGikHzg 33Ltvzz88YeDsi8Lw/Vbpg1XHk6Rus8GfmpM2d/f13HKc6ZfFCWXWJsWKmcGj2q2nyh2g9NzsR82 Gu39nGXSr/arTfYX02kW81dFfJVzadwhigtmIIFOs1LXp5WbnFYqrnGM3b32SoeQMB6JhP5OZu73 uTo8YH1diCw5yYSwDyQoHwrlXTMx8CezwN8/PNi/Q8WnUx6bU21ojc6jk+yADtblWHFOI3n9iypH Ja2C+9n1ufKyBNfie5LlQJ/OtgsVmX2UIHPnrm2f1Sex/nyqcnpZQOfNBz7u+JZ+YxPr87nxYjcZ L2fj9LcHaOP09QPUENYxgEALpiSVk+i+OGEYhS3olZPpAsgwORPcCxfiuT0AsTwt4kvtyQICOxyK YQpqfqRUcZNylmiaduIDsJoZYULsy9QztyWQSxMFRf4w8H+/YgoaW21xdHhxudiqAb83uXlbJNjG rkzhE0ybQNgMOo2wCcEIyKjTg5SWzXJ3qbT5hRe5R4OBryC6PZ1dV7rB+jUJMZUFqZm9JiG9G0ga dhoNu2NlKc/IAkWWD/xug36IKesTOK9lUskvYb0+HaFz3xMcto6BpTMsE5+nwyULafVlXZUJLQLa zI+L5JYIJvgLBOFTIGFaqA9gqxhuTxP0eAnxRuLSeo2gA6iMfYhajW7P99TqymR1RV7lwwL2BUtg MsapA9/Uw6HBE3Q6LvKSmVM5KmMipHchMMfz90yVFeIG6n5WjFJW8oeAd7TWfp0YdIjQZmRuBQwU 42sRkH4kfDpmkxH0ieSo7gSTF1gjLQvg23xvUlkZgec22qNXD4SRwAZlcs4Uo80Cyj3wudx7N4J8 wpza5w/p3vh9pUvYAX2t8cbQGdpnzA3o3jW3Jh1ovcnzm1uC28kSuJXaNp9qaFEQRb128yGP5cyt szO3/7+5MTGDx4IH/6/ZXRte4K7dRRvZ3UUB90mBvw54ukS0WJ9ai4GgHMO7vU4ySwXbhm94LCRq kbzJZ5Wd2tiLDU+201bHujxEPgw6LvIts4t21GggODlbbbYbDXj8yp/VkbUOfE+Njb0WmJI3Xc/P 1GyyyM5sdKz5rpE9HkNX4yTh+mgs3NAjtxdJ3TIBsunCyqU9ZwJE8Ww9A3IO2kaBLS6+14notimj jFrtRrfbpXtd3nyr2W51cNkuKWoGvVa388w3v8uK6lToG2RF9rJtFkN5EdKcRWWBvJD11WdyGk/n Zig4g3uv8lZzOBRZfOmZwuPwZV5VYVLmhkoUeZgmAzTWDMECY8eduC1ewaYd4P7UVxjxuEDuLPg1 Fxuws95zC3bjNFObc7MmuwW3k+JKmXRj4Wy82oZdNn2EG1zPv8xl2+H9mNreKKY+rXScmjulo3Oc FpYtHCdcInxmLwiDTsc6/qXP3BWSZLdfq5Cc1N5zV0hSPfh4IUml2N2E1sbzL5S2IEk9u0LLYrV1 4+zP9Va2yFhXKstHrHBXX36dds43tcIvVF9ORQJdHfh/nATDIDjpvdrrdo+CvWjYO97rBketvWZ4 HA6P0DNsnER/ohlmW5Ua7WWOhpctZpb5k+sBLXtCrkfk0i/bAKak6NPHv3769PHvZcqCVyBfun2H yZY1rk+NYd0Zj4V6y0oPbe+BLwxKGjPHKLnEaDILaQ7B2swxSi4xYnGMZjsoqkE9g3U3s6Bp1jPw N24pqmeieqZVz6D8cDTteqbte6nI5CU6kPTH96aF+NVN1COXMdiPGPfae04fBDqSxuaz2C7NkW1C TJh2rUNdxsd8SuBidB4b9wGgWTdgkZeuURxNkbKu0y4q0TKuVu91EC+5os8yVFrb3Y98egDyVV21 VtnShxFpNWvKYnS0x1nOtXfGb7yLImf49FJmJk5PWJ4JpCMBda9TpjRHE6FKyDlb2f5zLvc4I0as H+s7C7Gu3sDJ4SrluvFpe6AhZeg5U6dULbqOwQ7r58SaAKa7QSHWXGLdQ6yj7ssO6+fEmgCusI6W WAfNToAG1w7s53UihHAFdmsF7G7YtX3FnWY/p2YTwhXY7SXYYdiFYq9q9ko7vvIwdcDk7FQeK8Rf ZAI2BFWP2E3fb/EPAOdX0vWzidFXCHwUuYRxkWvrkEaoVAB1VgDqRE3bBV9o43cLEKFSAdRdAkTo rAei7xYgQqUCqLcCEJrl68HjuwWIUEEGiQKf/s+oStHrR9cUPvwHAAD//wMAUEsDBBQABgAIAAAA IQB01TLFQQQAAMcRAAAlAAAAcHB0L2hhbmRvdXRNYXN0ZXJzL2hhbmRvdXRNYXN0ZXIxLnhtbOxY bW/bNhD+PmD/QeA+u7ZsOX5B5KJxm65AkgV1in6mJdoSQpEaSTtOhgH9W9vP6S/Zc6SVOC/ogq7p sCH+YJ+Od0fd8R7enfdfbioZrYWxpVYpi190WCRUpvNSLVP24eywNWSRdVzlXGolUnYpLHs5+fGH /XpcgKtX7phbJ0wEO8qOecoK5+pxu22zQlTcvtC1UFhbaFNxh0ezbOeGX8B+JdvdTmevXfFSsa2+ eYy+XizKTLzW2aoSygUjRkju4IMtyto21urHWKuNsDDjtW+90gQ+ZjOZ0+98Gb5PzWSfj62WZX5Y SukfyFExlSZac5my+TJm7cl++46UWCxE5o6sozWyR5Y8QYZtfWaEIEqt35p6VtMqdj9Zn5qozHEw LFK8QvzJtl/YivlHBbFg95b6srHEx5uFqehlEbpokzKc8iV9Q4mPxcZFWWBmN9ys+OUB2ax484A0 nA0bwKHrTcmr4NF9d/aSfpw0Lr1HYLhaShF1r70LKohhfaSzcxspDX9DGPQUibcUr4zRF4XguSV2 8B7xavaikNDudRG5yxqBK3KDTL5K2a8rbpCwW5Ugh/dW16oW0Y/mF8c6hxpfOc0oSo+JYC8edLo9 IIbimAxGSbfvt7nRro11b4WuIiJSZuC6t87X29Tg40aENlWassyfklTRBTztDjodr7GzVJUEQFlW KRt26EOb8jEF543Kt/4rwJeRCVuxSAqAHYSXc7yUfy+HM5bKp8vtTKZoUaDd5kDnlyQwxy8iiEsF HhbaXGFbw3F6lkKPl5DvFA5t1IkHCJXzD0m/MxyxyOyuzHdX1KqaasALQOAqg9WUuYacOjwhpTNd 1dwdqVmdkSC9CwXzbPORm3obcYdsP9GzgtfiocAHWQ/f4AYZkdbN3KUEPkGvZUz5kYvFGZ/PkE/k x/ZMwHyPNcqyGFcbi+ZbkFHwgqI3vWsQGAEEVX7KDSdlieROmVCtDzP4J92Rf74qWmcft7kEDeRr E2+QAWdfRlv/Ptp6ZM/fJd8ebTkOZxdsuMRwwzQ4/VrQJXGSjPZ6D11eAXqDZ+j9/6HH5RK3F27z /xoG9+5jMHlCDC7cnYoXQOiLrC942xbkqyrfKO7Gg4EvbzcdxHP9o8v8e9W/+XP9Q7/xyPqHyhAa 6Jtu0yfvE9U/K/OTFRqt+zXQV91/AL/dGvgFED5Xwu/ThP6rIHyiSriQuR86f0sOht3Dg2Gv9aoz fd1KDkbD1qg3mLYO+/EQrdig3x90f0cL7wcsi5lYoE33bbW57mRD53rTyYbO1g8e6KPDADL5/OmP nz5/+pOmZuc7ZLzCt+mL/fUQhmuQzTifSXPM6wizesqkw0zhNqDyc1DzZZd4XeKBys9B8SzDPwSQ 2BINB+uBcy3TazhoUsNS0nAw7wZOv+GgJw+cvYaDDqGQpTrH3EQ/LFpo+XNgNJQfAu78+TL5CwAA //8DAFBLAwQUAAYACAAAACEAk6p9mLsAAAAkAQAAMAAAAHBwdC9oYW5kb3V0TWFzdGVycy9fcmVs cy9oYW5kb3V0TWFzdGVyMS54bWwucmVsc4SPwQrCMBBE74L/EPZu0iqISNNeROhV6geEZJsG2yQk UezfG+jFguBlYWbZN7NV855G8sIQjbMcSloAQSudMlZzuHfX3QlITMIqMTqLHGaM0NTbTXXDUaR8 FAfjI8kUGzkMKfkzY1EOOIlInUebN70Lk0hZBs28kA+hke2L4sjCNwPqFZO0ikNoVQmkm31O/s92 fW8kXpx8TmjTjwiWci/MQBE0Jg6ULs4yDzR3BVZXbPVb/QEAAP//AwBQSwMEFAAGAAgAAAAhALn6 T89eBgAAMhsAABQAAABwcHQvdGhlbWUvdGhlbWUyLnhtbOxZT28cNRS/I/EdrLm3+68JSdRNlexm G2jTRtltUY/eWe+Mu57xyPYm3Rtqj0hIiIK4IHHjgIBKrcSlfJpAERSpX4Fne2bXzsySpI0AQTdS dsb++f1/z8/eq9ceJAwdEiEpT9tB43I9QCQN+YimUTu4M+hdWguQVDgdYcZT0g5mRAbXNt995yre UDFJCIL1qdzA7SBWKtuo1WQIw1he5hlJYW7MRYIVvIqoNhL4COgmrNas11drCaZpgFKcANnb4zEN CRpoksFmQXyHwWuqpB4Imehr0iRfYVCjSUPPSRENO0ygQ8zaQd18gtrm1RreyAFMlXE988lxOWA0 aZ5GzwCYKuPW6vpvTs8AcBiC/GXe9Xqns76eYx2QfSzTbsGn0/HwDv1WSWZPN0vUgOzjlRLes5kD so8rJfzW1k6zs+XJY0AWv1rCN7vN7ravrwHFjKaTEroDn14vpz6HjDnbrYRvN/VfDl+gwPvzmNEs xjxVXgTZmAv0XILvc9EDgH5hWNEUqVlGxjiE2OxgRoeCagZ4g2Bnxg6FsjSkeSEZCpqpdvBBhiHO F/RePf/u1fOn6NXzJ8cPnx0//PH40aPjhz9YWt7CXZxG7sKX33z6x1cfod+ffv3y8efVeOnif/n+ 459/+qwaqFzgiy+e/PrsyYsvP/nt28cV8C2Bhy58QBMi0S1yhA54AroZw/iSk6E434pBjKm7YiuN JE6x5lJBf0fFHvrWDDNcgdsmvgXvCgqVrAJ4fXrfE7gfi6nKXe5pdiNOPOAe52ybi0or3NC8HMcP pmlUzVxMXdwBxodVvDs49fy7M82gINIqkp2YeGLuM5wqHJGUKKTn+ISQCjPco9Sz6x4NBZd8rNA9 irYxrTTJgA69aFos2qUJ+GVWJSD427PN3l20zVmV1l1y6CMhKzCrEH5AmGfG63iqcFJFcoAT5hr8 JlZxlZD9mQhd3I5U4OmIMI52RkTKqjW3BejrOP0GVI9qt++xWeIjhaKTKpo3MecusssnnRgnWRW2 T9PYxb4vJxCiGO1zVQXf436G6HfwA06XuvsuJZ67T68Gd2jkibQIED0zFdqXUK29IpzQ9G1FPnNF 3hK0MiV2T9ThZbiT1bfDxYj++4tvF0/TfQLxXt6B3tbet7U3+M/X3mX5fNaKuyiyUH91n2MbZNMu J0u75TFlrK9mjNyUpmGWsGGMejCo15nzH5mfxrIYHvMC7+Eigc0aJLj6kKq4H+MMmu2G6ccjmZOO JMq4hEOdGa6krZlCw67s6W9FH2VsPZBY7fGRHW65h8I5GbPtROZ4WTBqaQJnZdZ6782YNaxUS83m q9YwoplS56k2Vxl8WFYNBufWhE4EQf8CVl6FE7iWHQ4pmJGRtrvdhAu3aNbF84W4SMZ4RHIfab3L PmoYJxWxYs76EDsVPlozov+l1Rxu65rsG3A7i5NcdleWsCu89yZeKq4XCs8Y45xMR5a6yclSdNQO 1leaKwEKcdYOxnC+hcckA69L3fxhFsHVT6iEDftTk9kYfuHN9UIxiD4n4xr1YryksFcHMiFVF8vY hoaZykOApZqTlb+5Ama9KAVspL+GFK01CIZ/TAqwo+9aMh6TULnOdka07exrXkr5VBHRj0dHaMim 4gCD+3Wogj4jKuGawlQE/SLagba2mfKLc14YK27bNDfMshjn5VanaJHJFm5CdS6DeXPEA90qZTfK nV8Vk/IXpIobxv8zVfR+AlcGrZH2QAgXtQIjna/tgAsVc6hCWUzDnoDGwdQOiBYE1UVv1wiui823 IIf62+acpaGpMTj5qQMaIUFhP1KxIGQfypKJvlOINfK9y5IsCJmIcsSVmRV7SA4JG+gauKr39gDF EOqmmuRlwOBOxp//nmfQMNJNjptvXg2Z7702B/7uzscmMyjl12HT0BT2n4torOV3Pna9WV7sva4i emLRZl0psgKYOVvBep72rynCObdaW7FKGjdXCuHAi2WNYXDeEGVw8YP0P9j/qAiZ/e1Bb6gDfgC1 FcHvCZoYhA1E9SXbeCBdIO3gEBonO2iDSZOyps27W221YrO+kDZq4YI53xPG1pKdxd/nNPa8OfPZ ebl4kcbOLezZ2o4tNTV49mSKwtC4OMgYx5gfrdzflfjwPji6C3f9U6akCSbyAK75oPXsmzyA5Lcc zdLNPwEAAP//AwBQSwMECgAAAAAAAAAhABrNY/8AQAAAAEAAABcAAABkb2NQcm9wcy90aHVtYm5h aWwuanBlZ//Y/+AAEEpGSUYAAQEBAHgAeAAA/9sAQwABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/9sAQwEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/8AAEQgA kAEAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5 +v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR AD8A/tQp4Qnrx/P/AOt/ninhQPr6/wCelOr+dz+W4w76vsv6/IQADp/n60tFPCE9eP5//W/zxWbn 2+//AC/4J0Rpt9Pkv1e39bjAM8CpAnr+X+J/w/OpAvYD/Pv/APXqQJ6/l/8AX/z9azb6t/1/XQ66 dC9tP8un3+r0fUYFJ4A/wFSBAOvJ/T/6/wDnipVQntgf56D/ACPepQoHQZPr3/Cs3Pt953UsP5f8 N/T6WWm5GEJ68fz/APrf54qULjgD/E/WnhCevH8//rf54qZU9Bgev+eT1+nvWMprvd/1u/8AI9Gl hvJ+nX06W/4C3Ignr+X+J/w/Op1Q9+B6f56f54qVU9Bn3P8Anjr0HNSqgHXk/wCfzrCU+7+S/r8z 06OFvbT+tPw/DuluRqnpwPX1/wAf5VMqAdOT/np6VIEJ68e3f/P+cVOsf4D9f8/Xp6VjKp3dl2X9 f8A9WjhNvd/rr933rpdEKx5xn8h/U/5+tWFj9fyH+f5fnUqp6DA9f88nr9PepgoHQZPr3/CsJVPO y/H/AD+49WjhNnb+v+D06aaNPQjVD34Hp/np/nipQuOAP8T9aeEJ68fz/wDrf54qZU9Bgev+eT1+ nvWEpvpou/X/AIH9anqUcLbp/Wn9eemjIgnr+X+J/wAPzqdUPfgen+en+eKeFA+vr/npUgUn2Hqf 8/8A1vesXNLbX8v+CejSw1rafP7v6tvpokMAA6f5+tSBCevH8/8A63+eKeFA+vr/AJ6U8AnoPx7V k23q3956FOja2nn8/Jb/ADflZDQAOn+frTwpPsPWnhAOvJ/T/wCvT6zc+33/AOX/AATshR8v6835 22GhQPc+v+HpTqcFJ9h6n/P/ANb3qQKB9fX/AD0rNu+rOmNNLpfyX9a/P7hgQnrx/P8A+t/nipAA On+frS0Um0tzeMO/3L+vy+8KKKKhz7feaJJbBRRRSUW9Xdeu7/rzA8PpwUn2Hqf8/wD1vepAgHuf 89qkCk+w9a++bb1b/wAkfyXCj5f1pu/0XyGBQOg5/X/P0qQIT14H6/8A1qkVcdBk/wCfyqUJ6/lW bnbbXz6f8E7qWH8vw/4fXbuyNV9B+P8AifxqUIB15P6f5+tfB3g79uLXvia3jS7+E37Fn7V3xN8M eCPib8SPhNeeM9B1v9jbw/oWreKvhX4w1XwP4rbRrD4jftd+B/FzaXHrujXi6fd6t4Y0mW9tPKuB axhyi/d2mTTXthYXlzp15pNzd2drdXGk6i+ny3+lzzwpLLp99JpN9qmlSXllI7W11Jpup6jp7TxO 1lfXduY7iTrzHLcblns/rqw9OpUUWqEMdga+Jp89OFWP1jC4bE1cRhXKnOEksTSpN3tbmTS+jx2Q Y7KKzw+YQw9HERq16FXD0sdgMXiMNXws1TxFDF0MHicRVwVelUbpzpYuFGqqlOrT5eelVULAUn2H qf8AP/1veplT0H4n/Pv2rxj4wfHTwh8EtU+Cek+LNO8Sahc/Hj40aD8CvCDeHrPTLuDTfF3iHwr4 z8X2Wo+JG1HWNJktPDkWm+BtWgurvS49Y1NL6406KLSJ7ea5urT3JU9eB6f56V59WjXp0KGJqU5Q w+JdaOHqP4aroShGso63bpynBS0VnJW6m/8AZmIoQwlWtRnTp43DvFYSckrV8PHFYjBSqws9YrFY PFUG3Z89GaTateJU9sn9P8/X9KmCev5f4/8A1qlVewHH+e/+TUyx/j7noP8AP4muGVT5L8f68kdt HCeX4b7fl56d7MiVCe2B/noP8j3qdY/Qfiev4fn7D3qVU59T/n/PNTBPX8qwdTtou7/q35nq0cJt p8rdrf139URqnoPxP+fftUoQDryf0/z9akCk9B/gK+Q7D9tT4VX/AOzD8Z/2sYfD/wAQV+HfwLuf 2gbbxbosuleHF8aahJ+zd4q8Y+EfHDeHNNTxW+hXaarqXgnVZ/Ch1PxHpJvrK40+XV10K4luba01 oYTGYyE6mFw9StCnXwuGnOKTUa+NlUhhaTu0+avKlUjDo3B3sfRZdkmNxzpLB4WpiHWzDAZTS9mk +fMcyjip4DBxu1++xUcDi3TWkbYed5R0v9ehSfYep/z/APW96mVPQfif8+/avCPgD+0b8Nf2i/2f PBH7S3gufVdH+HPjfwlceL0j8YW1jpOveGLbTJL628RaT4us7DUtX0/S9c8LajpeqaX4gtbXVdQt bPUNOu44r66hjWZ+Z/Y4/a5+Gv7b/wAEdN+Pnwl0XxzoPgzVfE3i/wALWdh8RNG0rQfExvPBevXf h7UbqbS9H1/xJbW1jeXVm9xp3nail81pJEb+xsLnzLWPTE5Lm+EWcPE5fiaX+r+OpZZnTnCyy3MK 9XGUKOExTv7lepVy/G04w1blhqvSNz0Y5NjaWGr4yphasMNhcwpZXiK04WhSzKrRxleng5Xs3XdL L8ZUlFJ8ioT52m4KX1EEA68n9P8AP1qQAnoPx7V4/wDFb42eE/g7rXwU0LxPp/iG/vPjx8YNP+Cn hGTQbTTbm203xVqPgbx78QINQ8SPqGraXLaeH00b4ea1bS3Wlw6xqK6ndaXCmlSWk93e2PoXi7Xd U8N6Fcavo3gvxL8QNQhu9ItovC3hG68H2Wu3cOpavYaZeX9vcePPFfgnwytpoFleXHiDVkuvEdrf zaRpd/BoNlrevyaZoeo+c8LinDCVJU/Z0sdUlSwtWrOnRo1JwqQpVHKtVnCnShSnUh7WrWnClSi3 OpOMIykuuOX1qbwntIezWNoLE4aVWUKcKuHeLxWBVVVJyjCNNYrBYqi5TlCMZ0KnM1Fcz6IIB15P 6f5+tSAE9K+bdI/aX0PxT47/AGifhp4J+HXxL8a+Nv2aPFvwp8IeNNE0dfh1pf8AwkFz8WfCHhTx 5Yar4M1Lxh8RPDGkXmk+FfCniyLVfFn/AAkV/wCGdVH9jaxY+FtK8U6kdHs9Y7/wX8avAXj74mfG T4S+F7y/vPFvwFvvA2k/EhZtNubPTtM1r4heEoPHWgaTY3t0Ijq1yvhO/wBG1i/ubCGbS7ZdasrC PUJ9VtdYsNLurlmYUYTqSwlS1LL8JmtZRcZzoZXmFHKK+BzGvThKVSjgcXDPsojhsVVjChWq46lh 4VHXVSnD0HleLpRnKeHmlSoUcVUS5ZSpYbERwk8PiKkItypUayx2EVGrNRjOVaMIOU1KMfVgnr+X +P8A9apKUAnpXy98af2uvhL8Bvi38C/gz45HiGTxP8e9Wu9M0PUNHtdGn8OeC4V13wr4N0TWfiNq Go69pd5oWk+MfiF468HfDnwc+m6drl9rvjLxBbWMNgljZavqWm8uBwONzXF0sDgMPVxmMrqtKjhq EeetVVChVxNZUqa96coUKNWpyRTnKMHyqT0e2FwNfEyqRw9GdaVHDYnF1Y01dww2DoTxOJqyf8tK jSnNpayaUIKU5RjL6hAJ6D8e1SBAOvJ/T/P1p9FcYRp/Jfj/AF5sKK8P/aL+Pvg79mT4Tax8Y/Hu m+JdX8MaJ4i+Hfhm7sfCNnpd/r0l/wDEz4jeE/hjoM1va6zrOgae9paa/wCMdMu9Xkk1SKaDSIL+ 4s7e/vYrfT7r3CtZ4fERwdLHujP6nXxeLwFHEu3s6mMwFDAYrGYeLvd1KGHzTL6tS6SUcVSabu0u p4epChTxLpyVCtVrUadV25Z1cPGhOtBPfmpxxFCUlZK1WNtwooorkSlLfbu/0MwoopCQOp/DvWii l5vu/wCv+D5kuSXm/wCtxaaWA9z6f4/5z7VGXJ9h/nvTaoxlPu/kv6/M8lVAPc/56CpQmevHt3/+ tUgUDoP8TUoT1/KvsJT7v0X+Xc/m6lh/JdP66XW2mi3smRgdgP8APv8A4mpQnryfT/PWpVTj0H+f 881Mqeg/E/5/lWMpv0X9deh6NLC3tp/Wn9fnE/FT9gr4H/Evxv4C+PfiHw1+2F+0X8H9IuP23v21 IIvAvw58Mfsk6n4WsZbT9ozx7DPd2l58W/2W/ij42e41KRTd3q33jC9tUuJHXTrWwtRHbJ2HjT4C fCX45f8ABV7xZ4d+Nngbw78XvCvh7/gnj8GtTg8F/EnR9M8W+AtT14/tEfHSwtfFGveAdVs5/Bmu eI9JtZdSh8P6rqOhTTeHV1zXToQ09tUuC32jrv7BH7DHirXNZ8T+KP2MP2T/ABL4m8R6rqGueIfE Wv8A7Onwg1jXNe1vVruW/wBU1jWdW1Hwfc3+qarqV9PPeahqF9cT3l5dzTXFxNJNI7n33w98Lfht 4T1Wx1zwt8PPA3hnW9M8E6H8NNN1fw/4S0DRtV0/4ceGbm6vPDfw/sdQ03T7a7tPBPh+8vr260Pw pbzJoWk3N5dT2Fhby3Erv99jONMN9dxGZ4GeLo4uvlOKy+nGjleWZXWwdXE5fQwft/7XwOIljsx5 J0eaMsXSp1YxlKUJRnKal+t5hxTRr5hxPmmWVcZhsVxFHMPYyoZXluS18seP4nyfPnGpmGV4mWKz eSw+X18FLF4qNLESnUddL/asTBfzlyeCvDvjX4Q/syfAjXbO5n+FHgH/AILwfGr4I+FvB8OravBY 6X8HvBjftUQeHPhhBKt8buPwJp+gn/hDU8MR3EekHwT/AMUobX+x2e2b6h8cr8Kv2L/2hv27fDPw x8M6n8C/gLpv/BMnw9+0J4n8E/sx6V4e8BXei/EHT/HPx58Fat8TPhf4VisF+HXhn4qXfg7QfDtg PFE3hsW95d+FPC154mGoWmi7T+xcPwX+EMH2LyvhV8N4f7N+I2pfGLThF4G8MR/YPi5rP9q/2x8U 7IppY+y/EbVv7d1v+0/HEGzxNf8A9sar9q1SX+0Lvzuhufh54Dv/ABDqvi++8EeELvxXrvhGLwBr fii78NaNc+ItZ8BwXupalB4K1XWprJ9S1HwlDqWsavqEXhy8uptGjvdV1K7SzE99dSSvF+INLFKV Crhswq4CvSzJ4/BvGRjSx2Nx8Mtn9crRnCtSniI4vAzxTxNehXqRr1IV1Cc4yT9+rxrhsXja8q2C x08oryqVZZV9bjCi61XxMnxvUqqKU6VOvPLJvKPrCpSnGpKUrOheD/Af4BeEm+B//BQv9iXwfp3w Z/Zo/Zkvvin+yt+0Hf8AjPwb+z/8YL/4reOPjFpOkaT8LtY8IeOP2ivFb/Br4IWfjjxRDrNr4nuP D3iefS/iBfaxrlv8Rtct/Ht7b3d1APDfhr8CfhB8Of8Agjj+y3+1j4Y+Hvhq2/ab8MeJ/wBlXxHo X7QFxYi5+Munf2z+1f8AD3wHfeGbX4luy+MrfwE3w+13VPh/D8P4Naj8HQeCrp/D0WipZYSv6HPA 37Jf7K3wwn0O5+Gv7M/7P3w9uvDPiC/8WeG7nwP8Gvhz4TuPD/irVdDPhnVPE2hzaB4b0+TSfEGp eGyfD9/rNg1vqN5ohOk3FzJYE29d6nwX+EKfD3TvhGPhV8Nk+FGkHRzpPwwXwN4YHw90w+HtbtPE ugf2f4LGljw3Zf2H4j0+w8QaP9m02P8AszW7K01Wy8i/tobhPQr+KGFp4vK6uCoZpGnhc64NxuZP 6zWpTzXLeHeJeOs8x+W13iMwzPFVKGPwnF2FyyGHxmYY2i4ZZzVXGhPD4TDejDjOnGWEhThmFSm8 Tw5POZTr1YSzrC5PU4ipYrCY2FfG4+tiaGNy/OMPg4UMfjMby4ajPB4ieKhTjiK/5Z+H/hD+zp+0 r+0j/wAFIm/bN8I+AvHt98GvGXw/8O+CU+LDW6p8Cf2bdQ/Z48GeJtO+IXws1zWNUj1D4Lr4r8dT /FvX9c+LfgC98G65c+JvB/2xvFS3nw/0ePwz8sX3gO//AGk/2h/23jqfwn/Zb/aG8MfC7QvhBpXw B+Jv7RX7XvxA8DeLfgf+zvqPwE8LeKPCfxy+APia0/Zv/aMv9Lg8VeNbjxt40vP2ptD+J2ieLfFX jbwnLFe6wW+HunXcX7t/Ez9m39nn42ax4c8RfGX4C/Bf4ta/4PV18Ja78Tfhd4H8e6z4XWS6gvpF 8O6n4q0PVb3RFkvba2vHGmz2oe6t4LhsyxRuq/FL9mn9nL45apoOt/Gv4A/BT4w614Vimg8Max8U /hX4F+IOqeHILi4hu7iHQdQ8W6Dq93o8U93bwXU0enS2yS3EEM7q0kaMvh5fx3hMI6HtXnHI+GsB kEMNTxOIjhcixGX0eH6VbO8njgc1ynE1cfnryOs8wlSxeSVaFPN8fRq4nN1OrLEdeX8V4fD15VpR zOUamAy/C0aMq9Z0MolgXkrnh8uhh8fgpTwuM/siKkpVMPKnD+z4YijmCy+s8x/IX4J/C7wv+0L8 evCvw7/b41T4P/tVWngb/gnB+zZ4u+Eeqa1faf8AFD4CfFDWNe1Xxtpv7Tn7R3w5PiXQbDwx4p8Q y3el/BeC4+KdlpNtr3hvwv4t0WXTZ/D+nePri0ufLfgkPDn/AA4U/bY/4Q7xJdeMvCP9h/8ABTE+ FvF994huPFt74r8OD4p/HP8AsPxJeeK7ue7u/E91ruli11S48Q3V1c3GtTXT6lPcTSXLSN+8fxV+ AnwO+POlaTofxx+DPwo+Muh6DfvquhaP8V/h14Q+Iml6Lqcls9m+paTp3i/R9YtNOv3tHe1e8s4Y LhrZ3hMhiYqdq3+EPwntPA/iH4ZW3ww+Hlv8N/Fp8VHxX8PoPBfhuLwR4nbx1e6hqXjc+IfCkemr oOtHxlqOrapqHio6jYXP/CQ3up6hdav9snvLmSScb4g0MZgpUvq+Pw7q5zkmZ/2Th6lClkOAWUYn Mq9apl+GpqEYYnNf7QVXExhhsLSoYuliq0ZV6OPo4bLO/DcW0ISyKpKhjOTLOJ+Dc/eWQqUYZZl9 LhXJsblOJoZRSVoUqufVsUs1xrWHwtOGM9qpxxUnGtH8GtI1LUPhzH4r/wCCbNhO2kt+2h4n+Bfx U+Cz6fLcxSr8Cfj/AKTqHiH9uHTLKO08p7GfwYfhN8adauL+CeO106/+PPw6jmZLnUba2vPLv2av CvgT4k/Hf4RfAH46aXouv/s2+KP2nf8Agrtr+k/CjxhbWl18J/id8fPA37T2gp8PvDni3wrqUy+G vHl94V+HeqfEzxb4O8GeINN12yt7zSrzxVYaK2o+G7fVtF/pFb4Z/DqbxL4U8ZyeAPBMnjDwFoep +GPA3iyTwroTeJfBnhvW4rGHWfD3hPXWsDqnh3Q9Xh0vTItU0nR7qzsL+PTrFLu3lS0txHy/iD9n T9n3xb4I1j4Z+LPgX8HPFHw48ReKNR8ceIPh/wCIvhj4K1rwRrnjXV9Zn8R6r4v1jwnqWiXOg6n4 o1PxDc3Ovaj4gvbCfVr3WbifVLm7lvZpJ26/+Im4FVK9T+zsZRrZhSxUsdiqNejLEUszxOXVsho5 xhG1TnLEYDLsPlOc0YVq0a9TiWGaYmnjsHTxlCrhNMLxPQp5c8CqGKws8RPA43FY/D1IVMTDPHkO fZRnmc4aUnRn7TOK+ZYCvicJ7alCdDD4+jDEYepjIVaP86nj3wt8LNU1Lw18CNb1iyt/2KfCf/Bc Hwj8IvhTo58QXWk+CtM0LWf2QPHlx8UPgH4f1ATWunj4Pn46+JfFvwqf4fabIfDlpb614v8AhNAk OiWyaLYdF+1n4R8I/CvSP+CjHwg+Amk6H4V/Zt8KeJv+CXGsP8OfAlppWlfC/wCGP7RPiP8Aax8L v8S/D/g/wxokyaJ4K1bX/h5Y/CDxb428L6LpWkWZv9V0vxPeadHq3ie91LWf6EdR/Z/+A+r+AvDf wq1b4J/CPU/hf4Nt5bTwh8N9R+G/g298BeFbWfw7rXhCe28N+D7nRpfD2h283hPxL4j8MSw6Zp1r HJ4d1/WtFdTpuq31tOzQ/wBnX4A+G/hunwb8OfAz4O+HvhAmqWuuR/CrRPhl4K0r4bprVl4gs/Fl lrCeBrDRLfwwuqWninTtP8S2uoDSxd2+v2NnrMMy6jawXKXhfFHCYfEZNXlh83rwyrMcgxGIwtXE UXQzZ5Nm/B+Y188xvvt/2/mC4Wr18RKUa6qZjm0sRPHOGErQzL1J8YUKlXA1vYYzlw0sBGWDqVac qEJYPjHEcU1M2ozTjH+2sbQnDKcbiFhqKr0MXmUuenSrLDS/A39rsf8AKZr/ALO1/wCCUJ/P/hjz /Gut8WfsZeGPil8Zf+CzNx8Jfhd8PfC/7Qvhv4m/sw/F74A+OrPwPomka/Y/F3wn8FPhb8e9KuLH xFp2lQ6zFZ+PPjP4emv/ABxLY3J/4SLXNY17VNX+2avc3dw37w6v8Fvg74g/4TP+3/hP8NNc/wCF j6v4T1/4h/2x4E8L6n/wnmveAv7G/wCEG1vxn9t0qf8A4SjV/Bf/AAjvh/8A4RPUtb+3Xnhz+wtH /seaz/syy8jkviH8FLHUNT8V/FL4O6L8FPhx+1DrvhC08B6b+0N4x+CNh8SPElj4Rj1nTNTuvDeu HQ/Fvwu8b+J/Dvl2Bm0rw6/xL0vQ9P8AEEWk65d6fq0Glvo9/wAGB8SJ4LL8Lgsv+s5bjaOWZVga OYSl7bC4fGZXlPgxg8PjMRhqTVSvhVjfCzFTxFKMatVYDOEoUMTWo1MLX3y/i6FKGHw0Iyw0HHLa VWWKlVqZfUeEjwdRk8wo4WNTEVcE6fDuMVeNHD4mvLD4z2NOhVlKcX8Mf8E8PiJY/tlfEb41f8FC bA6gngTx94Z+GnwA+AOk6lHcxPoXgP4d6LH4x+LeoxQXKQNb3/iP46eM/EnhLXF+zJJKnwg0JpJH 8tY4fkXxR8Nv2l/28L39uz4tfCn4a/BrxN8NfjQtp+zX+zj8SviD+0v8QvhV4u8BaH+yr4t1e40z 4ofD/wAGeH/2VPjHo96L39qK08R/EfRdbufG/hmfXoPCfhC2exsrLS7DxNqn7ZfAD4IeF/2e/gl8 Pfgf4bmm1jRPA3hmDRLvWNVtNPh1HxfrF001/wCLPF/iC10+2ttMbXPG3iO+1fxP4hFpaw2k2q6x fNFBHC6xj0Xwl4Q8J+APDWieC/Anhfw74K8HeGtPg0nw54T8JaJpvhzw14f0q1XbbaZomhaPbWWl 6Vp9uvywWVhawW0K8RxqOK8rF8Z5dlufZ3j+H8vjKjTjl2T8LrE18Z7HL8lynE0K9PGqeGqZZjYZ vi8RleXYypXg6EK08dnaxeGcsY4nl0OIaOAxuYY3A4NVqlXGZTTy95nKdV0MkyCpQnlOFxkMLWw9 PE4+nLKeHauIxWlKpVyzEN0Zxx0/Z/gavijwX/wUD+N3/BIbxL8bPA9nq0XiX4Kft36Z8c/g54kt 2n8KSfFz4ZW/wF8JfEv4eePvB93LPpvinwx4a+K3hvVLy28KeLbS/wBMubzQ/Dmr6jpbXlhbLFwv xTms/gF4R/4KhfBD4WF/gp+zf4I/bE/YL0nW9H+Gl5qXgTQPgv8AA3496F+zff8A7UN94J/4RvVt BtPhb4X1fRdY8Za54kuPC8vh3S9DTxH4q1+OTS5ribUrX9/9F+CXwY8N+I4fGHh34RfDDQfFttrv jvxTb+KdF8A+FNL8RweJvijJpk3xN8Rw63Y6TBqcWu/EWbRdGl8d6ul0uoeLpNJ0x/EFxqDWFqYu gtvh74Bs9Q8b6vaeB/B9rqvxNNkfiRqdt4a0WDUPiCdN0KDwvpx8b3sVktz4sNh4Ztrbw7ZHXpb8 2uhW8GkQeXp8UduvfS8RsDh8Tg4YXKMU8jwGCccPw5UxkVlkMa/Fyn4iq0JQxFL2UMm9vwvHFVMN WxU6FRyqU54edTDvvwvFWFwksLh6VDHzyrLaMqOV4Sri1OpgZw4lxebYTH0Z1FUpQzTC5Zi6uEhj VRlJ4qpWnKEsNWqUZ/h9/wAFKv2cP2L/AIL/ALK3xu8HfArwt8MvgT8SPiMP2RF8SfDX4H+I4PhR c6z8OrH9tX4OaZYfE5fg74E1nQ/D/wDbmla5rl3oVh8cYfBn/CY2jz23hlPGgsre00uL2Pxd8IPh t+yl+35+yfov7LPwt8EfBxPjV+zx+2hafEnQfhn4csfCWmfFPWPhXp3wW8R/DHWPHuk6Eun6f438 XeGtc8SeJBpXi3xTBqviaOHxX4jt21YprF2X/Qnwl+yP+yl4B8LeIvA3gT9mP9nvwV4K8Yap4c1z xb4P8JfBf4b+HPC3ijWvB+p2+teEdX8ReH9H8NWek63qnhbWbS11bw5qGp2l1d6Jqdtb3+mTWt1D HKvr+o+C/B2r+J/DfjbVvCfhnU/Gfgyz1/T/AAh4u1HQtLvfE/hSw8Vx6dF4psvDev3NrLquhWfi SLR9Jj1+20u7tYdYj0vTk1FLlbG2EXEuOJUsvhlUsw4izbDSq8d1MdiMzxbjPMpcUcCZXwvk/wBY wn1vGQ5OH8yy6OYYenWxeL5Iwp18LOhXl7KjzUeKfq+Ho4OtLG5lhIVc1rYijj6jnQzGpi8pyrA4 GWKwrrVocuDxeV0MTSpzq15YanSw0KFeVXDxqn833gHwn8K9H/Yg/YD/AGtfhp/Yk3/BQD4p/tCf swaT4s+NHmC7+Onxb+MPj34o6N4d/au+D3xX8UQTX3jPxZ4R0Lwa3xa0/wAW/C/xDqP/AAjnw48O +ArS70/RPCI8A6Kui6/gH9k74V/FL9nz/goN4ttvEPwW+EXx68d/8FKf2n/Avh342/GfS9LudM8R aXF+1TpUml/sr+KfEcmqeHfGX/CjPj/qmnyfDvxn8LfCHiizh8U3HxF8SXUHhzxPq2vX+ha7+9ej /s+fADw58Udb+OHh34G/B7QfjV4lgurbxF8YNG+GfgvS/ijr9tex2cN5b614/sdEg8WarBdw6fYR XUV/q08c8djZpKrpbQhNeX4P/CWfwp418BzfC74dS+BviTqPinV/iL4Mk8E+GX8J+PtW8c3E1541 1Txp4dbTDo/inUfGF3cT3Xim91yzvrnxBcTzTatLdySOzexiPE5c+Iq4GOaYetic5WcU60q2GnLK 8JPN8kzOHCuDp1I1cPiOHsn/ALHnHLcNiaMMDiKmPxXt8nw+HqVMPV6qvGzgoLDVMxVRZ7l2a1Mf i50cTi61DCVOI6/1LE021SxdHD1s6wtWjSqShCvXwuKxV8F9boUMD+fP7Ax8P/DD4x/tGfs2Tfso fB79ln4neFvC3wR+K/jrTf2WfiRqPjL9mDxxaePNG8R+FtH8YeF/A8ngr4V2fwa8fXuofD/xBpXi Xw5f/C7RvE3irQdB8Ma5f+L/AB/pdho+q2n6l15Z8KPgd8E/gLomoeGvgb8H/hb8GPDer6o2uar4 f+FHw+8J/DrRNT1t7S1sH1jUNK8H6Ro9je6o9jZWdk2oXNvLdtaWltbmYw28SJ6cXJ6cfz/+tXwP E2aYfPM4rZjhaeJhCrh8DSnPF1sVVq1q2FwWHw1avbGY/Na+Hp1Z0XKlhP7QxVLC0nChh5U8PClQ pfE5vj6OMzDEYrDwrU6NWOEjCOIrV8TiJSoYHC4avWqVcTiMVWf1nE0a2KhSq4nEPCUq0MFGvXjh o1qkhYDr+XeoixPsP89ab9ajL+n514iil5vueLOtv+Ov5t/p6M4NU9B+J/z7dqnVPQZPr/ngdPr7 1Kqev5D/AD/L86lVM9Bgev8AnrXvyn21fd7f8E/H6OEfb/gf5efrqupGEA68n9P/AK9TBCevA/X8 BUqx+34n+n5f/XqdU9Bk+v8AngdPr71hKp53f4f5fcerRwm2mmn6f1310bREseO2Pr1P+cew9qmV PQfif8+3apQgHXn+X/1/88VKFJ6DA9f8KwnU7/ctv6/E9WjhNrr+tPw+5ejIwoHufU/5/wDr+9Sh CevA/X/P1qRU9Bk+v+eB0+vvUwQDrz/L/wCv/nisZT7uy7f1q/xPTpYbbTz8/wDgf8FasiVPQfif 8+3apgoHufU/5/8Ar+9PAJ4AqQIB15/l/wDX/wA8Vi53208+v/APRpYdaafd2/rvZa7DApPT8zUg UD3Pqf8AP/1/enAdgPwFSBPX8v8A6/8An61m2lq3/mzuhR8v603f6L5DACegqQIB15P6f/Xp4AHS lAJ6Cs3NvbRfj/XodcKPl+GnyXX8hKcFJ6fmaeEA68/y/wDr/wCeKfUHRGHZX83/AF/wRoUD3Pqf 8/8A1/enUUVLklv93U2UEt9X+H/B/rQKKKKhylLRL5L9X2/AsKKKKah3+7/N/wCX3ibS3YUU0sB9 fT/PSoyxPsPT/H/OPatDOU+2i7v+tB5cDpyf0/z9KjJJ6n8O1JTC4HTk/p/9emk3ojCVRL/N/wCW 7H1GX9Pz/wAP/r0wknqfw7UwsB9fT/PStFBLfV/h/wAE5Z1vPX8f8l/Vh5JPWoy4HTk/p/n6UwsT 7D0/x/zj2qMsB9fT/PStFFvZf5I46lf+u/f1/Ba7jySep/DtUZcDpyf0/wA/So2f1OB6f55PX6e1 QlyenH8//rf55rSMEt9X26f8H+tDz6uJtfX+tPS3ysn3ZlLHn3P6D6/559KnVB35Pp/nr/niplQ9 +B6f56f54qULjgD/ABP1rslU7uy7Ld/19x89Rwm2n9afl03fa6Iwnr+X+J/w/OpQueAP/rfWnhPX 8v8AE/4fnU6oe/A9P89P88Vg5v0X9df+GPUo4XbT8Pvsvv8AR9EQqg78n0/z1/zxU4T1/L/E/wCH 508ADp/n61IEJ68fz/8Arf54rFz7feelSw6VtP6/Xra2q7oYB2A/CpAnr+X+J/w/OngAdP8AP1p4 Un2HrWbfVv7/AOvwR3U6Fraf59Pu9Xquo0DHAp4QnrwP1/8Arf54p4UD3Pr/AIelOrNz7fedkKPl /Xm/K+wgAHSlp4Qnrx/P/wCt/nipAAOn+frWZ0xpra132tov67sYE9fy/wAT/h+dSAY4FFFJtLdm yh3+7/g/16hRRRWbm3otPzf+RoFFFFCg3q9Pz/r+rAFFBOOTUZf0/M/4f4/lWiSWyM3Pt948kDrU Zcnpx/P/AOt/nmmUhIHWmYyqJat3+en3/wCQtNLAe59P8fSmFyenA/X/AOt/nmmE45NaKHf7v+D/ AF6nNOt5/wCXyXXf/hxxYn2HpTCQOtML+n5n/D/H8qjJ7k/ia0S6Jf15/wCbOOpXS6/jr6dbddFr 6Dy5PTj+f/1v881GSB1phf0/M/4f4/lUDOO3J9f89f8APNaKHf7v+D/XqcFXEWvr/wAHv3/G79CZ nPbgev8Anp/nmoC/p+Z/w/x/KmM2eSf/AK30qIv6fmf8P8fyraMH6L+unQ86rilrr+P/AA/yd3r1 RIzY5J/xP0qJnPbgev8Anp/nmoWcduT6/wCev+eagaTPuf0H+f19a3jT7K3m93t/XY8uti99fx/H 5a+fe6NUIT14/n/9b/PFTKnoMD1/zyev096kCAdeT+n+frUgBPQfj2rklNd7v+t3/kfRUsMtNP6/ Rb+vZjAoH19f89KkCk+w9T/n/wCt708IB15P6f5+tSAE9Kybb1b/AMkd9OglbTt+my3f4J9hgUD6 +v8AnpTwCeg/HtTwnr+X+P8A9apKzc7ba+fT/gnZCl5f5/5JDAgHXk/p/wDXp9KAT0H49qkCAdeT +n+frWbbe7OqNNLp8l+vVsYFJ9h6n/P/ANb3qQKB9fX/AD0p1FI3jB9dF26/8D+tAooorNz7ff8A 5f8ABNEktEFFFFSoylq+vV/p/VhhRRTSwHufT/H/ADn2rVRS2+8hzS21f4f16DqYXA6c/wAv/r/5 5phYnr+VNpmUp938l/X5ikk9TSEgdaYXA6cn9P8A69Rkk9TVqDe+i/H/AIH9aHNOrvqv0+b6/L8B 5f0/P/63+fpUZPcn8TTSwHufT/H/ADn2qMsT1/KtFFLZf5s5KlZLr/wF5L9X26jy4HTn+X/1/wDP NRkk8k0wsB7n0/x/zn2qFn9T+A/z7d60UG99F+P/AADhqYi19fx/4bT7l6kpcDpz/L/6/wDnmoWf 1OT6f54HT6+1RlyenA/X/P0qIsB7n0/x/wA59q2jDsrLv/W551XE+dvz6bba/dfsyRmJ6nA9P8ai LgdOf5f/AF/881Ez+p/Af59u9QtJjvj+Z/zj2HvW0afZX83stv67nmVsVvr+Xyv0/TToyVn9Tk+n +eB0+vtUDydefwH9fy/+tUTOT04H6/iahLgdOT+n/wBet409ur79F/Xn8jyq2L8/+B899PTprdEj PnqcD0/z1qJn9PzP+f5/lUTP6nJ9P88Dp9faoGf1P4D/AD7d63jBddX2/rf+tDyq2L319fw8/u19 Ox3gT1/KpPpTgpPsP89KlCgdPz714Dml5v8ArqfsEKVraejt+S/X8SMIT14/n/8AWqQADgUtPCZ6 8e3f/wCtWTk3v9x1QpW30/N/5eg0AnpTwnr+VSAAdKKR0Rh2Vl/X3+oUUUVDmltq/wAP+CaqKW33 9QoooqPek/6sv6+8YUUUEgda0UUvN/1sS5Jevb+tgpCQOp/DvUZfPTj37/8A1qZVGUp93Zdv63HF yfYf5702kLAdfy71EWJ9h/nrVKLfku5zzq20Wn5/8D+tyQsB7n0qIsT1/KkJA61EXz049+//ANat FFLzfc5J1l3+7b59/l+BISB1P4d6iLk+w/z3ppOOSaiZ/Tgep6//AFq0UW/JdziqYi1/6ttp1/Xz sSEgdT+Heomfj0H+f88VEz+nJ9T/AJ5qInuT+f8An9BW0YdEvVv/AD/Q8+rifNd/+D1v579dUSF/ T86iLAdT/iajZ/Tgep6//WqFnxnHPqT0/wDr1rGn83+H9eunkeZWxW+v5/8ADq/Xrpe7JWfj0H+f 88VA0mOnA9T/AEH/AOuoWk59T6np+H+RULNjknJ/X/8AV+ldEae19X2/z7/l8jyq2L8/66eX+etr MlZz2/M9T/n3qFnA9z/nqf8AJqNn9eB/n8/pUDP6cD1PX/61bqHf7l/X5feeVWxe+v8AWl/6S9e5 Kz+p/Af5/nULPx6D/P8Aniomf05Pqf8APNRE9yfz/wA/oK3jT26Lt1/r118jy62J8/PT87/8Hur9 CQv6fnURYDqf8TUZfPTj37//AFqiZwPc/wCeprWMOy9X/wAH9F9x5tXE7/1pp6afd8z1qnBCfYf5 7VIFA9z6n/P/ANf3p1fHn9JRh2Xzf+f6IQADoPx70tFFS5Jeb7f59jZRS833Ciiis25SdvwX6/8A BKCiiirUEt9fy/4Im0twophcDpyf0/z9KjJJ6n8O1WZym/Rf116Dy/p+dMJJ60lRl/T8/wDD/wCv TSb2Xz6HPKolt9/X5IeSByajLk9OP5//AFqaST1qMuB05P6f5+laKCW+r/D/AIP9aHLOrbrb56+V 306f8Ef9ajL+n50wknqfw7VGXA6cn9P8/StFFvb7+hxVK6V9fl06en428h5OeSajL+n51Gz+p/Af 59+9QlifYen+P+ce1axh2V3/AF93qcFXE+f4/ntpr5b7MkZ+fU/5/wA8VEWJ6n/AVGXA6cn9P8/S omf1P4D/AD7962UO/wBy/r8vvPMrYpa6/jpvt5/p2RIX9PzqFn59T/n/ADxUTSep/Adfx/P2HtUD OT3wP89T/ke1bxp7X08l/Wh5dbF+f4/j3/X1RK0n4+3Yf5/E1CzdyeP89v8AJqIv6fn/AIf/AF6h Z/fJ/T/P0/St40/kvx/r118jyq2L31/Ha/8AX+VmSs/pwPX/AD0qFn9OT6n/ADz+NRM/qfwH+ffv UJYn2Hp/j/nHtW8YdlZd31/z/I8qtivP8dfu7PTp11XUkZ+fU/5/zxURYnqf8BUZcDpyf0/z9KiZ vU/h/wDW/Gtowtsrvv8A1sv6uebVxO+u/n6ff+PyJC/p+dRM2Opyf8/lUZcnpwP1/wDrVGWA6nn9 f8/WtlBLfX8v+CefUxF76/j+vfV66v0HlifYelRlwPc/571GWJ9h6f4/5x7U2tFFvZf5I4ala/X+ vJPf1fc9wor4o/aS+N8Xww8aabpF3+058CfgTaX/AIKfUY7H4zeIPDvhSObURe641vrNnqfiew/s 7VYJ7bSL1JdFh1zTr6Kx0HWdSit5oYbi6svFfDH7RHxm8P6F4h8QftHftVfsI+AdH1/xFpmj/BLx R4a1LxB8M/D3i7StW+E2r+JdGv8AVbH43avqp1DxPrOr+M/hr4tfwz4K8Wa/p+k+GdPfTG1+/wBR k1SPU+7LfCziPNsmw+dYWvgoU8bQp4jAYGphOInmGYwniI4eccvhQyGthsdUw7brYiGExVV08PGV ZOUbc39VVMXSpVvYSUnNRc5cnJJRpKg6/tWlPm9mlF0puMW6NbljXVKNSlKf6g0V+UmmftN/tJ6N 4f8AD3jHx1+09/wSkl8B638UtMfTvHOmePvHvhbw/wCKfgDoaeGL/wCIWteHr3WPiJ4g0ZPikuh6 pqOq6ZpMHiDX/BfhlLvwx/bniLWbPUJ7+O5rP7T/AMeIrS3XSv2o/wDglzo1npWt/EXxL4u8U+Jf iP4r8QNpPwF0yx8N+FfAvjh9B03xt4IsZPEmm/FzUb3QfiZPd+JPD/gX7Nf+HtH0LWNK8RXr2q+o vBLih1o045jkVSjKpiKMcVTnncsO62Fp1ZVqCX9hrEyxMatJ4P6nDDyxjxs4YZUPacyjnDMKE0ml O8nFQinSn7RS9vyzp1KdSdGpTbhhYqcKsk55nlkPjxLjT/U+ivxo8S/ttfGK9+HfhA/Cv9qz/gmX pnxW0nU/EejePdM/aJ+K9x4a03V9Eg03w7pHhHxdYaF4F8UP4l0zUvEnjW8s9SsI9Tt/C9rf+BPG 3hy6n8H6F4l1iw0DRfWbj45/ti+G/HPxm8G+KPip/wAE/b/Ufh/4K0vxppvhbRdO+Pdj8RfD2nXe k3AluvHng631zxdqF3o+qeIdY8H2HgjUfDEZv/Gsi+ItC0fRJPENsbXT+mv4HcV4SkpYnMMgw2Ik sfKnl9arnNLHVaWX5tl+UVq9OjPJFB0KlbNMBiMPVlVjGrhMVSqJqrJUTGOa0KrjGnGq3ywdRWpt 0XUxMsLGFS1RxcpVouNJUnVWJh+9wrr0/fP08LAfX0/z0qMsT7D0/wAf849q/F7WP2qv2pfCvhbx TpnxA/bA/wCCVfgf9orwpr2q2DeEdR8c+NbP4BwWjeGPAt7b6B471rxBqOkfELw58QdOvdP+JuuL odl4hF3F4Vv/AA5rt94f1Kws75Lf07xV8dP2jNR8BeH/ABT4C/aC/Ze+KmvWfxdvdEms/wBnWx8c 6zoN3Bc6bPZeHPA3jPw/4U+HP7anj/xnZ6D4h0XxZd/Ev/hCU+AWsXGgaY+qx/EX4V2fg7xJ/b21 bwK4povAqWbcOyjmWKqYTB1oviNYStKOHjiqFenjp8OQwNTCY6lUprAYqniJ0cXUn7OlNzhVVPn/ ALWw7ipuNSKaxMpOo6UXTWE9t7X2idbmV1RfJo1LmWq5Kqp/qjTC4HTk/p/9evx++E37UP7Xfj/W Phj4VT9o3/gk54x8f618YrOx+JXgX4f/ABN+Juoa/H8IbTw7oV3rujfDHwpPqS+ME+NdvqHhf43X 0+k+N7ObRdP03w/pQvrezl0TxbDZ/r2SB1r4/jXgHNeA8ZhMDnOMyvEYnGUsRXhSy6vi6k6VGhiJ YaNWvDF4LBVYUsTUhUlhKkYTp14U5zjO0WhU8fDEOcYxqwlCKc41YxjKLdavR5HFSlyzvh3Nppfu 6lKW87JxJPU/h2phYD6+n+elMLk9OP5//W/zzUZIHWvjUr6JETrpdfx1e3XX8PRjyxPsPT/H/OPa oywH19P89KYzntwPX/PT/PNQF/T8z/h/j+Vaxguur7dP+D/WhwVcQu/3f1576+bRKz+pwPT/ADye v09qhLk9OP5//W/zzTGbHJP+J+lRM57cD1/z0/zzWyg+ui7df+B/Wh5tbFb6/wBf59u992SMwHU5 Pp3/ABqFn9Tgen+eT1+ntUTSen5n/P8AP8qrtJnOPzP9B/n6VvGn5WX4v+vM8uti/PT+vlr6W72e pM0n4D9f8/Tp61AXJ6ce/f8Az/nNRs4HXk/56+lQs/rwPT1/x/lW8afZW83u9v67HlVsXvq/L9P6 3XmiRnA6cn/P51Ez+pz7f56dep5qJnPbgev+en+eagL+n5n/AA/x/Ktow7K/m/6032Wp5VbFb6/5 en37a21VmtiVn9Tgen+eT1+ntUJcnpx/P/63+eaYzY5J/wAT9KiLk9OP5/8A1v8APNbRglvq/wCv vPMq4nfX59en3fh8yRmA6nJ9O/41Ezk98D/PU/5HtURcDpyf0/8Ar/55qMsTyT/gK3UO/wB3+f8A wDzqmIvfV/1/w+zsvJjy/p+f/wBb/P0qMt3J/wA+3/1qjL+n5n/D/H8q+Xfjd8efiP8AB3X7i707 9mv4nfGH4XaN8Pbzxb4m8WfCS60jxJ4+h8Uv4htNE0HwB4R+EFz/AGbrPjnUtVtZbzXdQ1PStet7 Xw5penvJqluPtdgbj2sjyLMeIcfTyvKYYSpjasZSo0sXmWW5VCtKNlGjSxGa4vBYari685Qo4TBw rSxeNxE6eHwlGtXqQpy5OadaXLTtKTlTgouUU5Sq1oUIRipOLm3Uqx5lFNU6fPWny0aVScfqEuT0 4/n/APW/zzTK+Ifhf+19qP7QvhXxvq/wh+DXxa8J3Hg278GyWmvfFzwXpU/gjxxYan4w1TRfFum/ D7Xfht4+8Vab4r8SeGdP8NazZ+IbC31m1m8C67qWiQeKLJ7+01jw5D6r8Q/2hk8A+Kb/AMJWXwa+ PfxI1O3srBrGT4c/C7XtQ0fVNavLO81VtDi8beJ08JfDOz8vSbeG4/t+/wDHdt4Yg1OSXwvq+saR 4pOl6Pq/0GJ8PeK8FmlfJMVlqp5xhJVvr2XfXMFKpgKVHD5biZYrHYiOIeCw2E9lmuFbxFTFKnTa rKvKl7GZy/vJ1J0oq9Snz+0V0uTkpqrK7bUFam1KSvdbNJ2v9E00sB9fT/PSvj/wV+1P4g8f32ii x/Z/+MPgDStb+GHxL8bxj4zeCfH3gfxPYeJvAnjG58K6R4Iv9G0DwH470L7Z4zsdM1bxjpFpp3jD UPiFc+ERo+t6B8M/E1jqN9caNyPhn9q34va1oXg/VdU/ZZ8b6JdeJ/iJ4X8E31k9r8ZpV8O6dr0v gI33iLU4tR/Z40XxFbWmj2XibxHeTapqnhnSfh/E/hm10/XviJ4c1C78W2/w/wC1eGfGiqYik8pw 9OphKsaNeFXOshoyhVnWx+HUYqrmcPafvssxsZOlzxgqUJzcYYjDSrYVI1Ixc3FpJ1Y8zau3Rpe2 q8sb801TpXnJxTilGWr5ZJf/2QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwMEFAAGAAgAAAAhALn6T89eBgAAMhsA ABQAAABwcHQvdGhlbWUvdGhlbWUzLnhtbOxZT28cNRS/I/EdrLm3+68JSdRNlexmG2jTRtltUY/e We+Mu57xyPYm3Rtqj0hIiIK4IHHjgIBKrcSlfJpAERSpX4Fne2bXzsySpI0AQTdSdsb++f1/z8/e q9ceJAwdEiEpT9tB43I9QCQN+YimUTu4M+hdWguQVDgdYcZT0g5mRAbXNt995yreUDFJCIL1qdzA 7SBWKtuo1WQIw1he5hlJYW7MRYIVvIqoNhL4COgmrNas11drCaZpgFKcANnb4zENCRpoksFmQXyH wWuqpB4Imehr0iRfYVCjSUPPSRENO0ygQ8zaQd18gtrm1RreyAFMlXE988lxOWA0aZ5GzwCYKuPW 6vpvTs8AcBiC/GXe9Xqns76eYx2QfSzTbsGn0/HwDv1WSWZPN0vUgOzjlRLes5kDso8rJfzW1k6z s+XJY0AWv1rCN7vN7ravrwHFjKaTEroDn14vpz6HjDnbrYRvN/VfDl+gwPvzmNEsxjxVXgTZmAv0 XILvc9EDgH5hWNEUqVlGxjiE2OxgRoeCagZ4g2Bnxg6FsjSkeSEZCpqpdvBBhiHOF/RePf/u1fOn 6NXzJ8cPnx0//PH40aPjhz9YWt7CXZxG7sKX33z6x1cfod+ffv3y8efVeOnif/n+459/+qwaqFzg iy+e/PrsyYsvP/nt28cV8C2Bhy58QBMi0S1yhA54AroZw/iSk6E434pBjKm7YiuNJE6x5lJBf0fF HvrWDDNcgdsmvgXvCgqVrAJ4fXrfE7gfi6nKXe5pdiNOPOAe52ybi0or3NC8HMcPpmlUzVxMXdwB xodVvDs49fy7M82gINIqkp2YeGLuM5wqHJGUKKTn+ISQCjPco9Sz6x4NBZd8rNA9irYxrTTJgA69 aFos2qUJ+GVWJSD427PN3l20zVmV1l1y6CMhKzCrEH5AmGfG63iqcFJFcoAT5hr8JlZxlZD9mQhd 3I5U4OmIMI52RkTKqjW3BejrOP0GVI9qt++xWeIjhaKTKpo3MecusssnnRgnWRW2T9PYxb4vJxCi GO1zVQXf436G6HfwA06XuvsuJZ67T68Gd2jkibQIED0zFdqXUK29IpzQ9G1FPnNF3hK0MiV2T9Th ZbiT1bfDxYj++4tvF0/TfQLxXt6B3tbet7U3+M/X3mX5fNaKuyiyUH91n2MbZNMuJ0u75TFlrK9m jNyUpmGWsGGMejCo15nzH5mfxrIYHvMC7+Eigc0aJLj6kKq4H+MMmu2G6ccjmZOOJMq4hEOdGa6k rZlCw67s6W9FH2VsPZBY7fGRHW65h8I5GbPtROZ4WTBqaQJnZdZ6782YNaxUS83mq9YwoplS56k2 Vxl8WFYNBufWhE4EQf8CVl6FE7iWHQ4pmJGRtrvdhAu3aNbF84W4SMZ4RHIfab3LPmoYJxWxYs76 EDsVPlozov+l1Rxu65rsG3A7i5NcdleWsCu89yZeKq4XCs8Y45xMR5a6yclSdNQO1leaKwEKcdYO xnC+hcckA69L3fxhFsHVT6iEDftTk9kYfuHN9UIxiD4n4xr1YryksFcHMiFVF8vYhoaZykOApZqT lb+5Ama9KAVspL+GFK01CIZ/TAqwo+9aMh6TULnOdka07exrXkr5VBHRj0dHaMim4gCD+3Wogj4j KuGawlQE/SLagba2mfKLc14YK27bNDfMshjn5VanaJHJFm5CdS6DeXPEA90qZTfKnV8Vk/IXpIob xv8zVfR+AlcGrZH2QAgXtQIjna/tgAsVc6hCWUzDnoDGwdQOiBYE1UVv1wiui823IIf62+acpaGp MTj5qQMaIUFhP1KxIGQfypKJvlOINfK9y5IsCJmIcsSVmRV7SA4JG+gauKr39gDFEOqmmuRlwOBO xp//nmfQMNJNjptvXg2Z7702B/7uzscmMyjl12HT0BT2n4torOV3Pna9WV7sva4iemLRZl0psgKY OVvBep72rynCObdaW7FKGjdXCuHAi2WNYXDeEGVw8YP0P9j/qAiZ/e1Bb6gDfgC1FcHvCZoYhA1E 9SXbeCBdIO3gEBonO2iDSZOyps27W221YrO+kDZq4YI53xPG1pKdxd/nNPa8OfPZebl4kcbOLezZ 2o4tNTV49mSKwtC4OMgYx5gfrdzflfjwPji6C3f9U6akCSbyAK75oPXsmzyA5LcczdLNPwEAAP// AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAABMAAABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIw GEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGijEuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97 g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQpmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h7 05UkgecdieKTBtSJnsE3qoIgorTAp8vliGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQU AAYACAAAACEAAqjBcSwCAADxBQAAEQAAAHBwdC92aWV3UHJvcHMueG1spFTLbtswELwX6D8QvDuS LD9Uw3LQomgvARrATu8MRUsMKJIgKcf213dJ+SkrQdreuKt9zAyHmt9va4E2zFiuZI6TuxgjJqkq uCxz/LT6Mcgwso7IggglWY53zOL7xedPcz3bcPb6aBAMkHZGclw5p2dRZGnFamLvlGYSvq2VqYmD 0JRRYcgrDK5FNIzjSVQTLvGh33ykX63XnLLvijY1k64dYpggDsDbimt7nKY/Mk0bZmFM6L6GJIh1 v4Fdjq0oVlVTP0vChc/gBRCXnlIIgX6lzP4bMUuYA/LUZMtrvmdFKIQFThlWPLC1Q3YP+o7SGBQm jVNfi5fGuhzHOPIzj6UrpUNlNhqPxj2V0fV632oFL5gH92h8SJeiaCNkJdEr9dPwwu85hL+eXxh1 FsAEjPTcaSkRbDEnM7tFYIYJtEBjAogBImR3t1mAc+jSM2V4ySXa5niQTcE2OzgkceKboexiT9kA 4AfrPNpwRtAKNwGXBmJipBWgSyfjVpm2IuSGX5LpYdx5hp99ohxWdQRRjRNcXir0JuU07aN8ne2n DFoB36DUJVk436yXyjG7YttgscOdvYnIq99zC53032LqgWCVccyccVzcV8cXU/DlrS+us+8BSsDa XVP4+g6AgPECz+mO/9PWHemOvu6k+wkMknTYGhsexz/6Oh4G9kfrt8ZO46Mk7xm7I0kJD3upCYVf KqLw7KZZPMwybxgKXjxFLc5N+4P4AwAA//8DAFBLAwQUAAYACAAAACEAaF/1S/sAAABAAgAAEQAA AHBwdC9wcmVzUHJvcHMueG1sjJDLSsQwFIb3gu8QsnfSUShtaTqLSHbCLPQBYpteIDdOMqO+vWcc xRFTmLNK+Pi/c2l379aQo4a4eMfpdlNQol3vh8VNnL48y7uKkpiUG5TxTnP6oSPddbc3bWgC6Khd UgmjeyAocrFRnM4phYax2M/aqrjxQTtkowerEn5hYgOoN2xgDbsvipJZtTj6nYdr8n4cl14/+v5g cYCzBLT5miTOS4g/tnCN7XKPPyN1uGRv4AkOXauaCNOrMECOynBaYAlB2T9QIaiKDDglpMyAB6ws OCXKMpMQYkUlRF1nVVKugLJc6VHXQpxV7PcI+Lw81h66TwAAAP//AwBQSwMEFAAGAAgAAAAhAHVJ 09omAwAANQgAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAtFbdb9owEH+ftP/BysPUPbQBRNuVmUyMFrVas6KRbY+TZ1+IhWNHtoGyv37npFAQ qO02DfFwPt/nz/cR+uG+VGQB1kmj+1H7pBUR0NwIqaf96Gs2On4XEeeZFkwZDf1oBS76kLx+RcfW VGC9BEfQhHb9qPC+6sWx4wWUzJ3gtcab3NiSeTzaaWzyXHK4NHxegvZxp9U6i+HegxYgjquNwaix 2Fv4vzUqDA/xuW/ZqsKAE5pBWSnmIaHxI5kZz1QmS0i67067HbzaMOh3Y4VLzi7OadyQdFBVSnLm EagkldwaZ3JP7uqUyNgswY6N1J7G24IIEzjMtVYb1VAkd/rYcQugyaQwS3LUPutdvKXxAUk6ZpZN LasKl7RPWyjzeKYTJQUgv0vjB5J+Nh45KNcQ9FoKAfrhFtk7Z5qmQyWrWn5N0glnCoYIXZIz5QBN bxj0GlgoizGT1iV04XsL4N5Y4uQvLIxuRH4yBwHwfrRgVjLtEfgg1hxqWlXO2yTDCkHbeNeca3Jb bJuW3aRdCyDxpGBjq86WZNIrcH/iAmHEePZ8BGaTJzrfRaDxcZfjo/gDgLRPtxGpg2vwaOLs/JgM UpJdpePbQXa1HekGlitdMM1BkNT8lEr6FRloXhi7k9e+dLmWRmWUxicjS2NnRHooidRElCXhBas8 2INuPzI+m1oz16JHblOCvU9GaVD8MhqedzsXzyqN5pqHNnGotDBqgRmg9iaag/qXgD0hq6BG8H8z JkwI7B33jN4Qm3pq7Oqg0cGOCQzj6Mugzgd7LZf3hCllmo5+GyLkc2uxV4kGXwNmcsK8Z7wI0+qf HWjj/87JEKtgGl5xC5SjXXQahJ+MHyfMplRCVzZVmJrFf7L8CaB61vRLMDkc+I0W0uL8qesF34nk KszS2Z7Xw+obTOWWnZdrmzKURKhNQdx8OgXX1DuzQJaguDkw3uphGfZPPZo2Y2NoyorpVTLI3rCy ep/ReM2ht1LP3NcqM5dhcz0M5F0mnRToU+BKXd8/Mug1zmKrgpE6XRBrmf2LsN2+NV8BSbtz0sJf vcjWvLCe1vs++Q0AAP//AwBQSwMEFAAGAAgAAAAhAKNIIPeAAQAA1AIAABEACAFkb2NQcm9wcy9j b3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHySXU/DIBiF7038Dw33 HdDuS9KxRM2u1JisRuMdgXcbsaUNoHP/XsrWOqPxEs7h4bwHiuVnXSUfYJ1uzALREUEJGNkobbYL 9FSu0jlKnBdGiaoxsEAHcGjJLy8K2TLZWHi0TQvWa3BJIBnHZLtAO+9bhrGTO6iFGwWHCeKmsbXw YWm3uBXyTWwBZ4RMcQ1eKOEF7oBpOxDRCankgGzfbRUBSmKooAbjHaYjir+9Hmzt/jwQlTNnrf2h DTOd4p6zlTyKg/vT6cG43+9H+zzGCPkpfrm/W8dRU226riQgXijJvPYV8IcmWVdaQVJ2ywIPQmeR FoRvLN8JuRMmiv1W13AlnL8Pj7HRoK4PXM7y2Twr8G+lM1v40N0zckrm02gadnrWo9XGg+IhNknJ OKWkzCjLrlhOXgdsbwr5YmPHkKCS0AE7NtYrz/nNbblCJ16e0jzyMjaZBl7vihOFWwdgfRrpXyKd pGSakklJ52xM2Tg/I/YAHkP//If8CwAA//8DAFBLAwQUAAYACAAAACEAxlBTZa8GAABODAAAEwAI AWRvY1Byb3BzL2N1c3RvbS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 l0eP49gVRvcF1H8o1MoDooY5Dbp6wEyJOYvaNChmiUnMlOH/bjV6NHYNejY2akm8h8N3Dy7f/fjl 97WuXua0H8q2eX+Ff4VeX9ImbpOyyd9fPVd8o15fhjFqkqhqm/T9dUuH19+/Pj99Mfu2S/uxTIeX O6IZ3l+Lcex+A8EhLtI6Gn69Lzf3lazt62i8P/Y52GZZGad8G0912owgAkEEGE/D2NZv3Z+41x+8 3+bxf0Umbfz9dIPvbt39uF+//AHfXrJ6LJP313/yOMfzOIS/IQLNvcEQzL7RKE2+QRQEISzCiTQj /Ov1pfu+GXl9aaL6Xvq3evjW7fhvJIKjGHrHzuNvVbcMY//1H/gv15ArgFHF+5O9F44rRxal405O m5tI5uGXkcCoa2F5e0rDRn/tTo5Fp1ARUajvZrtUZoAh1ypKUr6tEAQl316KmI1lPPAVDcWAqqKA elPGcZWnM1T2e9mfVhlm7VKYPePMV9OkuIDans+5GmEw3WhRtneug7g3HzwalcE60o2pbLdwOgYH nlm3EEchLMR45FZRFkgka63WNk6Wi+4lKZGQclWhwM4XC8TbmPCQzQb94EU7+mpTHCaSMO75y8ZF X8D/CPkCPpz/n/bRn9uHP+g/sB2bxMNFZanUhOnA8Rs6wFCGj/vGzLsNBxi0L3MxyLmuN1W0pApQ 7h+VGBVsFji9CZ4SbNLeYFXIQcOwobLFRsXW6rMAYYaC6jpe4LEVrSeh9mXwGODFDVaPBwmSNtlA 5gdvR+YWkhkWvV5nzyM61cl1mM9Pih7TVIBI40qn7NXateSZKk2C32vzUNgaRp3TusvshC8uc9nc mgdP65arhgxrPdRdV0aFSyM0UcJai5bojp340HTwT3GP/dw98sG92vhxYlnojTX3pHkQllDy1C4L O2nXKEQZSXBfPyrxBbmjxG7VywaRtYrPKvwQ+BDGn9szpjBsFNjQTQZSvosNawfZNhnSVkuddSZ1 6XMrtYK67jHw9uDB4maCE+T3l2MfjDJggot/Ub11WqfoNh1InOMGHjNFBiAEJ71OTLmFzeHW2nlc SkdvH0YWaO404cHLstXAbQVpdSNwBZuL04wKaEwcio3rbAdDXAXzUsnZ1mHXbrkknnV36T/FPf5z 9x+vnaynWMFaaL64gTZ0drzyUUkcA1Gd8ZdrfHG4GOhoeadmJ8tY1t6UaFA9ut7laHQBkGaiYvq9 6CZ2gwB0UrsjIBW7uVNj88bgD54JiSdjkQRxgn0qzMCUMq+04sm8nzDw3jU2FuSqua5dlWZqT+7F 0bcTLit9EO87ynFWoooxE60ePHGU0xASw5CyT9euENdMLsmDYLFudsiuaFsbXI1oOCmBpj1xp2qX EZaWr2a9sKUGoO6gL8wYQfKnuCd+7h770PePSo4OFY62GLXT3gLhgpZr60roBAv5fGjR5IhbF8ot Z+lQR5GCADcyAmPsajCoQHQ8HEk2cS5tFHQfvNxySM8kcFzOxHQc06kLLxwQlbdzeO1cJ6lUCijk hZ1m2CRdP51IWDm2QM5u4fun2CD/tNGky3/NwL+OQPQXer7J8BL07BWI73tlmgYbtD3lHbnq9EEq BJA77fYmhGgnLN6DbLtgVeBOkYPMwmzfhL5qQqdnjOcnV2x9dB7zA9lk4dI7q2ZHoGuUvasRWHW2 gZXXOdzN6mUjQPuCTcqqqaTvF5bBsronDbKgk3MNPj8lMXnrb4tkVCxsJ7HuDgSoqmFZ6hN8LMYq napLg1eyWPCUmZC4Kbo+Kp7Zm6F4g9ATS6zcGodjnp/i3BljTykh+rhMJkbIn9N897z1R9z4q+6P M6/vjzsT2/RYpym8EQXlUEtWetpldSVRs6YaHUxu7O4wHs7bVhG4SODOoj8/bbhrogNVCyAKoIGG 3ej1iMJ5HXuxPXvyofCQ1JRXprwQ1lGvxTWWL7dO9ONaVchb5SvwxGe7cP/8dELsldc4jQwUTE6h vdG5JqSw83XN2KMWR3QNSbbhOQXF6RVaEJKcHVxRZ3gRzMrDEbTMIwk3UPb8BGRXL7kwUT0G4x41 mKIjLrujUdu3/f3lYJOMLvcpvU3/reyPQ247ABzlhBVT+sS2yEEARHhfqEur6HtsT3Uq4t3VQkBl Q0zVEJyJomcy5FtOpByLQVxKmw1QSJYCzMgEDrj8nOVwc5mwqHSFQurGyIvinbbfO+z1qD0/DRif F8Z8bhF/yzKzb3pKrJn3z/nA4Xvm/9FyQ1ZF+YdbDsZQFEfweyz+O//g96j940fg678BAAD//wMA UEsBAi0AFAAGAAgAAAAhAC2zk9eXAgAAdBUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5 cGVzXS54bWxQSwECLQAUAAYACAAAACEAR78a0BMBAAB1AwAACwAAAAAAAAAAAAAAAADQBAAAX3Jl bHMvLnJlbHNQSwECLQAUAAYACAAAACEAFGs7hb8AAAA3AQAAIAAAAAAAAAAAAAAAAAAUCAAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTYueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAA IAAAAAAAAAAAAAAAAAARCQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHNQSwECLQAU AAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAAAOCgAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAAAL CwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8A AAA3AQAAIAAAAAAAAAAAAAAAAAAIDAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHNQ SwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAAAAAAAAAAAAAAAFDQAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAFGs7hb8AAAA3AQAAIAAAAAAAAAAA AAAAAAAEDgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTcueG1sLnJlbHNQSwECLQAUAAYACAAAACEA FGs7hb8AAAA3AQAAIAAAAAAAAAAAAAAAAAABDwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTgueG1s LnJlbHNQSwECLQAUAAYACAAAACEAFGs7hb8AAAA3AQAAIAAAAAAAAAAAAAAAAAD+DwAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTkueG1sLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIQAA AAAAAAAAAAAAAAD7EAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTE0LnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhABRrO4W/AAAANwEAACEAAAAAAAAAAAAAAAAA+xEAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGUxMy54bWwucmVsc1BLAQItABQABgAIAAAAIQAUazuFvwAAADcBAAAhAAAAAAAAAAAAAAAAAPkS AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAFGs7hb8A AAA3AQAAIQAAAAAAAAAAAAAAAAD3EwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTExLnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhABRrO4W/AAAANwEAACEAAAAAAAAAAAAAAAAA9RQAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGUxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDNqI32mgEAANYLAAAfAAAAAAAA AAAAAAAAAPMVAABwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh ALk2NQtFAwAAWhEAABQAAAAAAAAAAAAAAAAA0hgAAHBwdC9wcmVzZW50YXRpb24ueG1sUEsBAi0A FAAGAAgAAAAhABbRvAlqBgAAjxoAABUAAAAAAAAAAAAAAAAASRwAAHBwdC9zbGlkZXMvc2xpZGUx LnhtbFBLAQItABQABgAIAAAAIQADtjx+Yg0AAAl7AAAVAAAAAAAAAAAAAAAAAOYiAABwcHQvc2xp ZGVzL3NsaWRlOS54bWxQSwECLQAUAAYACAAAACEAQgr1rWsOAADjgwAAFgAAAAAAAAAAAAAAAAB7 MAAAcHB0L3NsaWRlcy9zbGlkZTEwLnhtbFBLAQItABQABgAIAAAAIQAKo4vGmw0AAHF/AAAWAAAA AAAAAAAAAAAAABo/AABwcHQvc2xpZGVzL3NsaWRlMTEueG1sUEsBAi0AFAAGAAgAAAAhAIiEzVeT DgAAM4wAABYAAAAAAAAAAAAAAAAA6UwAAHBwdC9zbGlkZXMvc2xpZGUxMy54bWxQSwECLQAUAAYA CAAAACEATEn7Vj8CAAB5BQAAFgAAAAAAAAAAAAAAAACwWwAAcHB0L3NsaWRlcy9zbGlkZTE0Lnht bFBLAQItABQABgAIAAAAIQCBONUzFggAAJg/AAAVAAAAAAAAAAAAAAAAACNeAABwcHQvc2xpZGVz L3NsaWRlOC54bWxQSwECLQAUAAYACAAAACEAVU10Vj0OAAAJhAAAFgAAAAAAAAAAAAAAAABsZgAA cHB0L3NsaWRlcy9zbGlkZTEyLnhtbFBLAQItABQABgAIAAAAIQDpVmu73AUAAPMjAAAVAAAAAAAA AAAAAAAAAN10AABwcHQvc2xpZGVzL3NsaWRlNi54bWxQSwECLQAUAAYACAAAACEAWDGkKO4CAAAz BwAAFQAAAAAAAAAAAAAAAADsegAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsBAi0AFAAGAAgAAAAh AJgLC3SnAwAAzAgAABUAAAAAAAAAAAAAAAAADX4AAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQIt ABQABgAIAAAAIQCBCL3MAAgAAPk/AAAVAAAAAAAAAAAAAAAAAOeBAABwcHQvc2xpZGVzL3NsaWRl Ny54bWxQSwECLQAUAAYACAAAACEAAIkyObADAAA9DAAAFQAAAAAAAAAAAAAAAAAaigAAcHB0L3Ns aWRlcy9zbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAhACmNwQDjAgAAyAcAABUAAAAAAAAAAAAAAAAA /Y0AAHBwdC9zbGlkZXMvc2xpZGU1LnhtbFBLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA AAAAAAAAAAAAABORAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVs c1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAABuSAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAA ADcBAAAsAAAAAAAAAAAAAAAAACOTAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAACuUAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc1BLAQItABQABgAIAAAA IQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAADOVAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0OC54bWwucmVsc1BLAQItABQABgAIAAAAIQDcEdiWuQoAAMZBAAAhAAAAAAAAAAAA AAAAADuWAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAAzoQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDkueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAA AAA7ogAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAARKMAAHBwdC9zbGlkZUxheW91dHMv X3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAs AAAAAAAAAAAAAAAAAE2kAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwu cmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAFWlAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQBpol8h HgEAAMcHAAAsAAAAAAAAAAAAAAAAAF2mAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFz dGVyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAMWn AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc1BLAQItABQABgAI AAAAIQAnbhMN/wMAAMoNAAAhAAAAAAAAAAAAAAAAAM2oAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0OC54bWxQSwECLQAUAAYACAAAACEA/+70YUIBAABwAgAAIQAAAAAAAAAAAAAAAAALrQAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1sUEsBAi0AFAAGAAgAAAAhALhSHtjcAQAA wgMAACEAAAAAAAAAAAAAAAAAjK4AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ2LnhtbFBL AQItABQABgAIAAAAIQB+zvvtlAQAAKcXAAAhAAAAAAAAAAAAAAAAAKewAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0NS54bWxQSwECLQAUAAYACAAAACEAUm+nESEDAABvDQAAIQAAAAAAAAAA AAAAAAB6tQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAh AKn11i8qAwAACwkAACEAAAAAAAAAAAAAAAAA2rgAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQzLnhtbFBLAQItABQABgAIAAAAIQCLO1bETwIAAJ8GAAAhAAAAAAAAAAAAAAAAAEO8AABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWxQSwECLQAUAAYACAAAACEARP97pQwGAAC0FgAA IQAAAAAAAAAAAAAAAADRvgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0A FAAGAAgAAAAhAKBAHdJpAgAA1gYAACIAAAAAAAAAAAAAAAAAHMUAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYACAAAACEAjv+nmaQDAAA6DQAAIQAAAAAAAAAAAAAA AADFxwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1sUEsBAi0AFAAGAAgAAAAhALJy YLOhAgAApwcAACIAAAAAAAAAAAAAAAAAqMsAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQx MS54bWxQSwECLQAUAAYACAAAACEAtM9YGbsAAAAkAQAALAAAAAAAAAAAAAAAAACJzgAAcHB0L25v dGVzTWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAaTBx 4x4JAABQMgAAFAAAAAAAAAAAAAAAAACOzwAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYA CAAAACEAy/u3G9UGAAC/JAAAIQAAAAAAAAAAAAAAAADe2AAAcHB0L25vdGVzTWFzdGVycy9ub3Rl c01hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhAHTVMsVBBAAAxxEAACUAAAAAAAAAAAAAAAAA8t8A AHBwdC9oYW5kb3V0TWFzdGVycy9oYW5kb3V0TWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEAk6p9 mLsAAAAkAQAAMAAAAAAAAAAAAAAAAAB25AAAcHB0L2hhbmRvdXRNYXN0ZXJzL19yZWxzL2hhbmRv dXRNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALn6T89eBgAAMhsAABQAAAAAAAAAAAAA AAAAf+UAAHBwdC90aGVtZS90aGVtZTIueG1sUEsBAi0ACgAAAAAAAAAhABrNY/8AQAAAAEAAABcA AAAAAAAAAAAAAAAAD+wAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVnUEsBAi0AFAAGAAgAAAAhALn6 T89eBgAAMhsAABQAAAAAAAAAAAAAAAAARCwBAHBwdC90aGVtZS90aGVtZTMueG1sUEsBAi0AFAAG AAgAAAAhANj9jY+sAAAAtgAAABMAAAAAAAAAAAAAAAAA1DIBAHBwdC90YWJsZVN0eWxlcy54bWxQ SwECLQAUAAYACAAAACEAAqjBcSwCAADxBQAAEQAAAAAAAAAAAAAAAACxMwEAcHB0L3ZpZXdQcm9w cy54bWxQSwECLQAUAAYACAAAACEAaF/1S/sAAABAAgAAEQAAAAAAAAAAAAAAAAAMNgEAcHB0L3By ZXNQcm9wcy54bWxQSwECLQAUAAYACAAAACEAdUnT2iYDAAA1CAAAEAAAAAAAAAAAAAAAAAA2NwEA ZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQCjSCD3gAEAANQCAAARAAAAAAAAAAAAAAAA AJI7AQBkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQDGUFNlrwYAAE4MAAATAAAAAAAA AAAAAAAAAEk+AQBkb2NQcm9wcy9jdXN0b20ueG1sUEsFBgAAAABGAEYA0xQAADFGAQAAAA== --_004_6E31144C030982429702B11D6746B98C522001C3szxeml557mbxchi_-- From nobody Mon Jun 8 08:57:11 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC841B2FB6 for ; Mon, 8 Jun 2015 08:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgEcyjyXUrh2 for ; Mon, 8 Jun 2015 08:56:57 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3BB1B2FB5 for ; Mon, 8 Jun 2015 08:56:48 -0700 (PDT) Received: from [192.168.31.218] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77796467; Mon, 08 Jun 2015 16:56:46 +0100 From: "Seil Jeon" To: , "Dapeng Liu" References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> <005d01d09de5$dadd6b40$909841c0$@av.it.pt> <3620CF9B-EF59-4DF0-993F-4442D91604DC@yegin.org> In-Reply-To: <3620CF9B-EF59-4DF0-993F-4442D91604DC@yegin.org> Date: Mon, 8 Jun 2015 16:56:45 +0100 Message-ID: <000301d0a203$b8ccde60$2a669b20$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01D0A20C.1A9FC550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXyJVonWC/jWHjoPLHEPQMMWOBzAGkZzt5AU1BkT0C/VzGWQLvqnHwAhDpQpMCH8V98AJIAZ16Aps88YoBmwV+dQH2sBSYnGhSa9A= Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: [DMM] FW: [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:57:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01D0A20C.1A9FC550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Chairs, We want to elaborate the issue created in the tracker for clarity. What Action should I take in "Modify Ticket"? - leave as new - resolve as . - reassign to . Regards, Seil From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, June 03, 2015 11:34 AM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support OK, so now at least I fully understand what this is. My recommendation is: - Please refine the issue definition in the tracker, so that people can understand this the same way, - And then let's ask the WG members their opinion about the issue (whether it's something worth tackling or not), - And if they agree to the issue, then we move to the solution space discussion. Alper On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote: - A Sustained IP address that just got allocated from the currently serving network (hence the "mobility is not activated" until the MN moves off link)? > Yes. Thanks for your elaboration. Regards, Seil From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, June 03, 2015 7:03 AM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support So, the idea is, when this flag is set along with a Sustained IP address request from the app: - if the host stack is already configured with a Sustained IP address allocated from the serving network, then it gets selected (irrespective of the presence or absence of any other Sustained IP address). >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network. What exactly is "(an IP address) that does not activate IP mobility"? Please elaborate. Is it - A nomadic IP address? - A Sustained IP address that just got allocated from the currently serving network (hence the "mobility is not activated" until the MN moves off link)? - something else? Alper On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote: Hi Alper, Regards, Seil -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Monday, June 01, 2015 8:50 PM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. So, the idea is, when this flag is set along with a Sustained IP address request from the app: - if the host stack is already configured with a Sustained IP address allocated from the serving network, then it gets selected (irrespective of the presence or absence of any other Sustained IP address). >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network. - if the host stack is not already configured with a Sustained IP address allocated from the serving network (irrespective of the presence or absence of any Sustained IP address from any other network), then the host makes an attempt to configure one with the serving network. >> Yes. -- if the configuration succeeds, then the newly configured IP address is selected. >> Yes. -- if the configuration fails. then the call fails (?? or some other behavior -- you can define here). >> You mean the configuration fails when there is no sustained IP address, right? In my opinion, this issue belongs to address configuration mechanism based on definition of the three DMM APIs. Those jobs are/will be asked on each configuration mechanism, according to discussion of the previous teleconference in the WT you're leading. At that time, if I see any something related to our proposal, we will raise our voice. Alper >>> #49: full on-demand mobility support >>> >>> The three proposed flags express a "type" of source IP address an >> application wants to get to the IP stack. Particularly, the sustained >> IP address is proposed to provide on-demand IP session continuity, >> which activates IP mobility once the terminal moves across other >> access > network. >>> While the terminal stays at the same network where the session is >> initiated, regular IP routing is applied. >>> >>> The on-demand draft does not assure provide the full on-demand >>> mobility >> for all scenarios by merely indicating the Socket API, >> IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned >> issue is as follows; >>> >>> 0. The MN is configured with one or more Nomadic IP addresses. >>> >>> 1. Once an app. requests "sustained IP address" to the IP stack, and >>> it >> will obtain a sustained IP address through a protocol procedure >> between the terminal and network. >>> >>> 2. Other app. initiated over the same access network will use the >>> same >> sustained IP address while the terminal remains connected at the same >> access network. >>> >>> 3. The terminal moves to another access network and a new app. >>> requests a >> sustained IP address with the Socket API to the IP stack. Since a >> sustained IP address is already available in the IP stack, the >> sustained IP address is assigned to the new app. >>> >> >> Yes, that's what happens. >> You are not pointing to an issue up until this point, right? Because, >> you continuing your email with a "Besides" gives the impression that >> you are pointing to an issue, but I don't see any issue captured in >> the > above text. >> >>>> There is an issue. Maybe, we need to be synchronized how have you >>>> thought >> and defined the meaning of "on-demand mobility". As far as I know, >> there are two meanings; one is that by imposing capability among IP >> address reachability and IP session continuity, needed for an >> application, into a source IP address, on-demand mobility could be >> achieved; as the other meaning, it can be rephrased and detailed with >> dynamic mobility, which should be applied in the use of sustained IP >> address. A new application needs to have non-anchored sustained IP >> address. This is our consistent claim. Non-optimal routing issue has >> been raised in DMM Requirement document in RFC 7333, which should be > critically considered in the solutions. >> > > Sorry, I don't understand what you meant here. > >>>> You answer doesn't make us progress. Please specify where and what >>>> you > have understood. > > >>> Besides, in case sustained IP address allocation is used default, >>> there >> may be multiple sustained IP addresses including newly obtained >> sustained IP address over the new access network in the IP stack. >> However, when an app. is initiated, the IP stack may not select the >> new one in the context of the default source IP address selection > mechanism [RFC6724][RFC5014]. >>> >> >> OK, is the issue following: When there are multiple sustained IP >> addresses, how does the IP stack pick one among them? (*) >> >>>> As mentioned and specified in our draft >> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, >> if there is no additional preference, we can leave selection to the >> default source address selection mechanism. BUT if we have specific >> preference among multiple sustained IP addresses and an initiated >> application wants to have non-anchored sustained IP address over >> currently attached access network, the proposed flag is essential. >> > > I think you are meaning the same thing as I said above (*). > Do you agree? > >>>> Yes. > >>> For providing the full on-demand mobility, a new flag is needed, >>> letting >> the IP stack request a new sustained IP address or choose a sustained >> IP address not requiring IP mobility anchoring when an application is >> initiated, among the existing ones in the IP stack. >>> >> >> Your flag is not a solution to what I captured above. It does >> something >> else: Instruct the IP stack to go get a new sustained IP address >> whether there is already one or more configured on the stack or not. >> (**) >> >>>> Answered in the above. >> > > There's a discrepancy between (*) and your solution (**). > > Are we talking about (*), (**), or something else? > >>>> There is no discrepancy between them. I said "a new flag", just an > additional flag not intending to get a new sustained IP address all > the time. And it should not request a new sustained IP address whether > there is already one or more configured on the stack or not. It is > given with the same expression in the ticket, though our draft is > saying the meaning of a new sustained IP address, which will be revised in next update. > > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. > > > Seil Jeon > > > > >> Alper >> >> >> >>> -- >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>> Reporter: | Owner: draft-ietf-dmm-ondemand- >>> seiljeon@av.it.pt | mobility@tools.ietf.org >>> Type: defect | Status: new >>> Priority: critical | Milestone: >>> Component: ondemand- | Version: >>> mobility | Keywords: on-demand mobility >>> Severity: Submitted | >>> WG Document | >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>> >>> Ticket URL: < http://trac.tools.ietf.org/wg/dmm/trac/ticket/49> >>> dmm < http://tools.ietf.org/dmm/> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> > > ------=_NextPart_000_0004_01D0A20C.1A9FC550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chairs,

 

We want to elaborate the issue created in the tracker for clarity. What = Action should I take in “Modify = Ticket”?

 

- leave as new

- resolve as …

- reassign to …

 

 

Regards,

Seil

 

From:= = Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, = June 03, 2015 11:34 AM
To: Seil Jeon
Cc: = dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): = full on-demand mobility support

 

OK, so now = at least I fully understand what this is.

 

My recommendation is:

- Please refine the issue definition in the tracker, = so that people can understand this the same = way,

- And then let's ask = the WG members their opinion about the issue (whether it's something = worth tackling or not),

- = And if they agree to the issue, then we move to the solution space = discussion.

 

Alper

 

 

On = Jun 3, 2015, at 1:12 PM, Seil Jeon wrote:



- A Sustained IP address that just got allocated from = the currently serving network (hence the "mobility is not = activated" until the MN moves off = link)?

> Yes. Thanks for = your elaboration.

 

 

R= egards,

S= eil

 

 

From:=  Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, June 03, 2015 7:03 = AM
To: Seil = Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 = (ondemand-mobility): full on-demand mobility = support

 

So, the idea = is, when this flag is set along with a Sustained IP address request from = the app:

- if the = host stack is already configured with a Sustained IP address allocated = from the serving network, then it gets selected (irrespective of the = presence or absence of any other Sustained IP = address).

&= nbsp;

>> No. I said "one that does not activate IP mobility" = over the serving network, among the existing ones in the IP stack, gets = selected. If no one in the IP stack is not matched, it will make an = attempt to get a new sustained IP address from the serving = network.

<= div>

 

 

What exactly is "(an IP address) that does not = activate IP mobility"? Please = elaborate.

 

Is it

- A nomadic IP = address?

 

- A = Sustained IP address that just got allocated from the currently serving = network (hence the "mobility is not activated" until the MN = moves off link)?

 

- something = else?

 

Alper

 

 

 

 

On Jun 2, 2015, at 2:11 AM, Seil Jeon = wrote:




Hi = Alper,

 =

Regards,

Seil

 =

 =

-----Original= Message-----
From: Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Monday, June = 01, 2015 8:50 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] = [dmm] #49 (ondemand-mobility): full on-demand mobility = support

 =

> The = point is that when the IP stack receives a flag with sustained = IP

> address = flag, it will check it has a sustained IP address, and if = it

> has one = or more, one that does not activate IP mobility will = be

> = selected. If not, the MN will be triggered to get a new IP = sustained

> address = not activing IP mobility.

 =

So, the idea = is, when this flag is set along with a Sustained IP address request from = the app:

- if the = host stack is already configured with a Sustained IP address allocated = from the serving network, then it gets selected (irrespective of the = presence or absence of any other Sustained IP = address).

&= nbsp;

>> No. I said "one that does not activate IP mobility" = over the serving network, among the existing ones in the IP stack, gets = selected. If no one in the IP stack is not matched, it will make an = attempt to get a new sustained IP address from the serving = network.

&= nbsp;

- if the = host stack is not already configured with a Sustained IP address = allocated from the serving network (irrespective of the presence or = absence of any Sustained IP address from any other network), then the = host makes an attempt to configure one with the serving = network.

&= nbsp;

>> Yes.

&= nbsp;

-- if the = configuration succeeds, then the newly configured IP address is = selected.

&= nbsp;

>> Yes.

&= nbsp;

-- if the = configuration fails. then the call fails (?? or some other behavior -- = you can define here).

 

>> You mean the configuration fails when there is no sustained IP = address, right?

In my opinion, this issue belongs to address configuration mechanism = based on definition of the three DMM APIs. Those jobs are/will be asked = on each configuration mechanism, according to discussion of the previous = teleconference in the WT you’re leading. At that time, if I see = any something related to our proposal, we will raise our = voice.

 

&= nbsp;

&= nbsp;

&= nbsp;

Alper<= o:p>

 =

 =

 =

 =

 =

 =

>>> = #49: full on-demand mobility = support

>>>&= nbsp;

>>> = The three proposed flags express a "type" of source IP address = an

>> = application wants to get to the IP stack. Particularly, the = sustained

>> IP = address is proposed to provide on-demand IP session = continuity,

>> = which activates IP mobility once the terminal moves across = other

>> = access

> = network.

>>> = While the terminal stays at the same network where the session = is

>> = initiated, regular IP routing is = applied.

>>>&= nbsp;

>>> = The on-demand draft does not assure provide the full = on-demand

>>> = mobility

>> for = all scenarios by merely indicating the Socket = API,

>> = IPV6_REQ_SUSTAINED_IP. An example scenario raising the = aforementioned

>> = issue is as follows;

>>>&= nbsp;

>>> = 0. The MN is configured with one or more Nomadic IP = addresses.

>>>&= nbsp;

>>> = 1. Once an app. requests "sustained IP address" to the IP = stack, and

>>> = it

>> = will obtain a sustained IP address through a protocol = procedure

>> = between  the terminal and = network.

>>>&= nbsp;

>>> = 2. Other app. initiated over the same access network will use = the

>>> = same

>> = sustained IP address while the terminal remains connected at the = same

>> = access network.

>>>&= nbsp;

>>> = 3. The terminal moves to another access network and a new = app.

>>> = requests a

>> = sustained IP address with the Socket API to the IP stack. Since = a

>> = sustained IP address is already available in the IP stack, = the

>> = sustained  IP address is assigned to the new = app.

>>>&= nbsp;

>> = ;

>> = Yes, that's what happens.

>> You = are not pointing to an issue up until this point, right? = Because,

>> you = continuing your email with a "Besides" gives the impression = that

>> you = are pointing to an issue, but I don't see any issue captured = in

>> = the

> above = text.

>> = ;

>>>&= gt; There is an issue. Maybe, we need to be synchronized how have = you

>>>&= gt; thought

>> and = defined the meaning of "on-demand mobility". As far as I = know,

>> = there are two meanings; one is that by imposing capability among = IP

>> = address reachability and IP session continuity, needed for = an

>> = application, into a source IP address, on-demand mobility could = be

>> = achieved; as the other meaning, it can be rephrased and detailed = with

>> = dynamic mobility, which should be applied in the use of sustained = IP

>> = address. A new application needs to have non-anchored sustained = IP

>> = address. This is our consistent claim. Non-optimal routing issue = has

>> = been raised in DMM Requirement document in RFC 7333, which should = be

> = critically considered in the = solutions.

>> = ;

> 

> Sorry, = I don't understand what you meant = here.

> 

>>>&= gt; You answer doesn't make us progress. Please specify where and = what

>>>&= gt; you

> have = understood.

> 

> 

>>> = Besides, in case sustained IP address allocation is used = default,

>>> = there

>> may = be multiple sustained IP addresses including newly = obtained

>> = sustained IP address over the new access network in the IP = stack.

>> = However, when an app. is initiated, the IP stack may not select = the

>> new = one in the context of the default source IP address = selection

> = mechanism = [RFC6724][RFC5014].

>>>&= nbsp;

>> = ;

>> OK, = is the issue following: When there are multiple sustained = IP

>> = addresses, how does the IP stack pick one among them? = (*)

>> = ;

>>>&= gt; As mentioned and specified in our = draft

>> if = there is no additional preference, we can leave selection to = the

>> = default source address selection mechanism. BUT if we have = specific

>> = preference among multiple sustained IP addresses and an = initiated

>> = application wants to have non-anchored sustained IP address = over

>> = currently attached access network, the proposed flag is = essential.

>> = ;

> 

> I think = you are meaning the same thing as I said above = (*).

> Do you = agree?

> 

>>>&= gt; Yes.

> 

>>> = For providing the full on-demand mobility, a new flag is = needed,

>>> = letting

>> the = IP stack request a new sustained IP address or choose a = sustained

>> IP = address not requiring IP mobility anchoring when an application = is

>> = initiated, among the existing ones in the IP = stack.

>>>&= nbsp;

>> = ;

>> = Your flag is not a solution to what I captured above. It = does

>> = something

>> = else: Instruct the IP stack to go get a new sustained IP = address

>> = whether there is already one or more configured on the stack or = not.

>> = (**)

>> = ;

>>>&= gt; Answered in the above.

>> = ;

> 

> There's = a discrepancy between (*) and your solution = (**).

> 

> Are we = talking about (*), (**), or something = else?

> 

>>>&= gt; There is no discrepancy between them. I said "a new flag", = just an

> = additional flag not intending to get a new sustained IP address = all

> the = time. And it should not request a new sustained IP address = whether

> there = is already one or more configured on the stack or not. It = is

> given = with the same expression in the ticket, though our draft = is

> saying = the meaning of a new sustained IP address, which will be revised in next = update.

> 

> The = point is that when the IP stack receives a flag with sustained = IP

> address = flag, it will check it has a sustained IP address, and if = it

> has one = or more, one that does not activate IP mobility will = be

> = selected. If not, the MN will be triggered to get a new IP = sustained

> address = not activing IP mobility.

> 

> 

> Seil = Jeon

> 

> 

> 

> 

>> = Alper

>> = ;

>> = ;

>> = ;

>>> = --

>>> = -------------------------+------------------------------------------

>>> = -------------------------+-

>>> = -------------------------+---

=

>>> = -------------------------+---

=

>>> = Reporter:          &nbs= p;    |      Owner:  = draft-ietf-dmm-ondemand-

>>><= span class=3Dapple-converted-space> seiljeon@av.it.pt<= /a>      |  mobility@tools.ietf.org

>>>&= nbsp;  Type:  defect       = |     Status:  = new

>>> = Priority:  critical     |  = Milestone:

>>> = Component:  ondemand-    |    = Version:

>>> = mobility           = ;    |   Keywords:  on-demand = mobility

>>> = Severity:  Submitted    = |

>>> = WG = Document           = ; |

>>> = -------------------------+------------------------------------------

>>> = -------------------------+-

>>> = -------------------------+---

=

>>> = -------------------------+---

=

>>>&= nbsp;

<= div>

>>>&= nbsp;

>>>&= nbsp;

>>> = _______________________________________________

>>> = dmm mailing list

>>><= span class=3Dapple-converted-space> dmm@ietf.org

>>><= span class=3Dapple-converted-space> https://www.ietf.org/mail= man/listinfo/dmm

>> = ;

>> = ;

> 

> 

 

------=_NextPart_000_0004_01D0A20C.1A9FC550-- From nobody Mon Jun 8 09:43:08 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7FB1B307D for ; Mon, 8 Jun 2015 09:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kUcrc0SVGCi for ; Mon, 8 Jun 2015 09:43:04 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F3A1B3080 for ; Mon, 8 Jun 2015 09:43:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t58Ggs0m019861; Mon, 8 Jun 2015 18:42:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D698720AABD; Mon, 8 Jun 2015 18:45:27 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C700020A8D4; Mon, 8 Jun 2015 18:45:27 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t58GgpnC006798; Mon, 8 Jun 2015 18:42:54 +0200 Message-ID: <5575C60B.8030709@gmail.com> Date: Mon, 08 Jun 2015 18:42:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Templin, Fred L" , Satoru Matsushima References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <2134F8430051B64F815C691A62D9831832E827AF@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E827AF@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 16:43:07 -0000 Hi Fred, Le 04/06/2015 17:10, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, June 04, >> 2015 7:09 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm >> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >> >> Le 04/06/2015 05:42, Templin, Fred L a écrit : >>> Hi Alex, >>> >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, June >>>> 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm >>>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >>>> >>>> Le 29/05/2015 20:21, Templin, Fred L a écrit : >>>>> Hi Alex, >>>>> >>>>>> -----Original Message----- From: dmm >>>>>> [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru >>>>>> Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru >>>>>> Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - >>>>>> /62s to UE, not /64s >>>>>> >>>>>> Le 29/05/2015 15:30, Satoru Matsushima a écrit : >>>>>>> Ah OK. thanks. Slightly off-topic, I think that there is >>>>>>> still chance for tethering with single /64 if it is >>>>>>> allocated as a off-link prefix. >>>>>> >>>>>> Yes, there is still such a chance. But it can not tether >>>>>> more than one single subnet. Connected vehicles need >>>>>> several subnets. >>>>> >>>>> How would it be if the vehicle received a single prefix, but >>>>> it could be shorter than /64 (e.g., /56, /48. etc.)? Would >>>>> the vehicle subnetting be satisfied if it received a shorter >>>>> prefix from which many /64s could be allocated? >>>> >>>> Certainly yes. >>>> >>>> Each vehicle needs such a shorter-than-64 prefix allocated to >>>> it. >>>> >>>> For example, an automobile connecting to LTE receives a /62 >>>> from the operator and makes four /64s out of it: one for its >>>> CAN-entertainment, one for its CAN-safety, one for its WiFi >>>> and one for its Bluetooth. >>>> >>>> This is a MUST. >>>> >>>> Allocating a single /64 to a vehicle can not accommodate all >>>> these unbridgeable subnets. >>> >>> OK, that is good. Giving a mobile router something shorter than >>> /64 should be no problem, at least up to practical limitations >>> of the prefix delegation authority's available prefix space. >>> DHCPv6 PD provides all that is needed to give out right-sized >>> prefixes. >> >> I agree DHCP-PD provides the necessary tool. But unfortunately the >> cellular operators have not deployed DHCPv6-PD (although yes there >> is some DHCP-non-PD in some IPv6/4G deployments). > > That is a pity, because DHCPv6 PD (along with IPv6 ND and BGP) are > all that are necessary for distributed mobility management. I agree. A dynamic routing protocol like BGP was demonstrated to feature distributed mobility management on a wide geographical scale. >> The common thinking at operators and advisers is still that a /64 >> should be given to an User Equipment. >> >> This must change: the 3GPP specs and operator deployments must >> give /62 to UEs, and not /64. > > Why not a /N instead of just a /62 or /64? N could be anything (62, > 60, 56, 48, etc.) as long as it is a proper subset of the prefix > space the operator has available for delegation. I agree that in general it's good to be more generic with the prefix length. But in this particular case we are too generic if we just say '/N'. The readers will assume '/64' to be a good example of N, and that is not so. We can't say 'non-/64' either, because it means too much. We could say N between /48 and /63 in one bit steps. But to be clear that /64 is forbidden. (I can imagine the pressure that may put on the operatos, but we may also think there are enough of these addresses and that the pressure is simply a misunderstanding.) Alex > > Thanks - Fred fred.l.templin@boeing.com > >> Alex >> >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>>> >>>> Alex >>>> >>>>> >>>>> Thanks - Fred fred.l.templin@boeing.com >>>>> >>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> But yes, I agree with you. >>>>>>> >>>>>>> cheers, --satoru >>>>>>> >>>>>>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> In addition to what Behcet says. >>>>>>> >>>>>>> I read the example below. I think it is just an >>>>>>> example, but just to make sure. >>>>>>> >>>>>>> Please - do not allocate /64s to end users in a cellular >>>>>>> network. Allocate at least /62s to end users. >>>>>>> >>>>>>> This is to allow the smartphone to perform tethering >>>>>>> (small network of wifi devices connecting through the >>>>>>> smartphone to the Internet). >>>>>>> >>>>>>> The assumption of /64 to end user is not good at all. >>>>>>> >>>>>>> (and yes, I agree that these /62s may be aggregated into >>>>>>> a larger prefix and advertised upstream as a single >>>>>>> prefix instead of multiple host-based routes). >>>>>>> >>>>>>> Yours, >>>>>>> >>>>>>> Alex Petrescu >>>>>>> >>>>>>> Le 26/05/2015 22:34, Behcet Sarikaya a écrit : >>>>>>> >>>>>>> Hi Satoru, >>>>>>> >>>>>>> Thanks for your reply. >>>>>>> >>>>>>> Let me continue the discussion with your text in Section >>>>>>> 3.2 where you mention vEPC may utilizes Forwarding >>>>>>> Policy Configuration Protocol (FPCP) that defines FPCP >>>>>>> Agent function and Client function. >>>>>>> >>>>>>> I don't understand how you could justify defining a new >>>>>>> forwarding policy configuration protocol to do this >>>>>>> Agent/Client functionality? Why not use similar >>>>>>> Agent/Client models that are being defined rather than >>>>>>> defining a new protocol? I think this point requires >>>>>>> much stronger justification which I could not see in >>>>>>> Section 3.2. >>>>>>> >>>>>>> Are you that we have to to reinvent the wheel, rather >>>>>>> than reusing something that is already available? How >>>>>>> are we going to reinvent that wheel also remains to be >>>>>>> seen, I think. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi Bechet-san, >>>>>>> >>>>>>> Thank you for your question. In step (15), I meant that >>>>>>> EPC-E advertises prefix including UE assigned prefixes. >>>>>>> >>>>>>> For example, in the case of /64 prefixes assigned to UEs >>>>>>> from a /56 space, that /56 is advertised by EPC-E to >>>>>>> upstream routers. So the advertised route isn't host >>>>>>> routes. >>>>>>> >>>>>>> Depends on configuration policy, but one case is that the >>>>>>> source of that advertised /56 route might be statically >>>>>>> configured in EPC-E. >>>>>>> >>>>>>> Regards, --satoru >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Matsushima-san, >>>>>>> >>>>>>> I have a question on your draft: In Sec. 3.2, page 11, >>>>>>> you say In step (15), the EPC-E advertises routes to >>>>>>> upstream routers ... >>>>>>> >>>>>>> Are these routes static/host routes? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ dmm >>>>>>> mailing list dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ dmm >>>>>>> mailing list dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ dmm >>>>>> mailing list dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>> >>> >> > From nobody Mon Jun 8 10:08:11 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D311B30D0 for ; Mon, 8 Jun 2015 10:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thtFKBInj2eN for ; Mon, 8 Jun 2015 10:08:07 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B796F1B30CA for ; Mon, 8 Jun 2015 10:08:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t58H87lK005464; Mon, 8 Jun 2015 10:08:07 -0700 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t58H801m005388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 8 Jun 2015 10:08:00 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-PHX-312.sw.nos.boeing.com ([169.254.12.54]) with mapi id 14.03.0235.001; Mon, 8 Jun 2015 10:08:00 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Satoru Matsushima Thread-Topic: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Thread-Index: AQHQmjkkJI//M3dql0O3DI0sVGxml52TQ0XQgAgjhoCAAFQrEIABJdgA//+aLYCABto8gP//kHkw Date: Mon, 8 Jun 2015 17:08:00 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E84B2D@XCH-BLV-504.nw.nos.boeing.com> References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <2134F8430051B64F815C691A62D9831832E827AF@XCH-BLV-504.nw.nos.boeing.com> <5575C60B.8030709@gmail.com> In-Reply-To: <5575C60B.8030709@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 17:08:10 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cnUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBNb25kYXksIEp1bmUgMDgsIDIwMTUgOTo0MyBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMOyBT YXRvcnUgTWF0c3VzaGltYQ0KPiBDYzogZG1tDQo+IFN1YmplY3Q6IFJlOiBbRE1NXSB2ZXBjIGRy YWZ0IFJldi4gMDQgLSAvNjJzIHRvIFVFLCBub3QgLzY0cw0KPiANCj4gSGkgRnJlZCwNCj4gDQo+ IExlIDA0LzA2LzIwMTUgMTc6MTAsIFRlbXBsaW4sIEZyZWQgTCBhIMOpY3JpdCA6DQo+ID4gSGkg QWxleCwNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBBbGV4YW5k cnUgUGV0cmVzY3UNCj4gPj4gW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXSBT ZW50OiBUaHVyc2RheSwgSnVuZSAwNCwNCj4gPj4gMjAxNSA3OjA5IEFNIFRvOiBUZW1wbGluLCBG cmVkIEw7IFNhdG9ydSBNYXRzdXNoaW1hIENjOiBkbW0NCj4gPj4gU3ViamVjdDogUmU6IFtETU1d IHZlcGMgZHJhZnQgUmV2LiAwNCAtIC82MnMgdG8gVUUsIG5vdCAvNjRzDQo+ID4+DQo+ID4+IExl IDA0LzA2LzIwMTUgMDU6NDIsIFRlbXBsaW4sIEZyZWQgTCBhIMOpY3JpdCA6DQo+ID4+PiBIaSBB bGV4LA0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBBbGV4 YW5kcnUgUGV0cmVzY3UNCj4gPj4+PiBbbWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5j b21dIFNlbnQ6IFdlZG5lc2RheSwgSnVuZQ0KPiA+Pj4+IDAzLCAyMDE1IDg6MzYgQU0gVG86IFRl bXBsaW4sIEZyZWQgTDsgU2F0b3J1IE1hdHN1c2hpbWEgQ2M6IGRtbQ0KPiA+Pj4+ICBTdWJqZWN0 OiBSZTogW0RNTV0gdmVwYyBkcmFmdCBSZXYuIDA0IC0gLzYycyB0byBVRSwgbm90IC82NHMNCj4g Pj4+Pg0KPiA+Pj4+IExlIDI5LzA1LzIwMTUgMjA6MjEsIFRlbXBsaW4sIEZyZWQgTCBhIMOpY3Jp dCA6DQo+ID4+Pj4+IEhpIEFsZXgsDQo+ID4+Pj4+DQo+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLSBGcm9tOiBkbW0NCj4gPj4+Pj4+IFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcnUNCj4gPj4+Pj4+IFBldHJlc2N1IFNlbnQ6IEZyaWRh eSwgTWF5IDI5LCAyMDE1IDEwOjU5IEFNIFRvOiBTYXRvcnUNCj4gPj4+Pj4+IE1hdHN1c2hpbWEg Q2M6IGRtbSBTdWJqZWN0OiBSZTogW0RNTV0gdmVwYyBkcmFmdCBSZXYuIDA0IC0NCj4gPj4+Pj4+ IC82MnMgdG8gVUUsIG5vdCAvNjRzDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gTGUgMjkvMDUvMjAxNSAx NTozMCwgU2F0b3J1IE1hdHN1c2hpbWEgYSDDqWNyaXQgOg0KPiA+Pj4+Pj4+IEFoIE9LLiB0aGFu a3MuIFNsaWdodGx5IG9mZi10b3BpYywgSSB0aGluayB0aGF0IHRoZXJlIGlzDQo+ID4+Pj4+Pj4g c3RpbGwgY2hhbmNlIGZvciB0ZXRoZXJpbmcgd2l0aCBzaW5nbGUgLzY0IGlmIGl0IGlzDQo+ID4+ Pj4+Pj4gYWxsb2NhdGVkIGFzIGEgb2ZmLWxpbmsgcHJlZml4Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IFllcywgdGhlcmUgaXMgc3RpbGwgc3VjaCBhIGNoYW5jZS4gIEJ1dCBpdCBjYW4gbm90IHRldGhl cg0KPiA+Pj4+Pj4gbW9yZSB0aGFuIG9uZSBzaW5nbGUgc3VibmV0LiAgQ29ubmVjdGVkIHZlaGlj bGVzIG5lZWQNCj4gPj4+Pj4+IHNldmVyYWwgc3VibmV0cy4NCj4gPj4+Pj4NCj4gPj4+Pj4gSG93 IHdvdWxkIGl0IGJlIGlmIHRoZSB2ZWhpY2xlIHJlY2VpdmVkIGEgc2luZ2xlIHByZWZpeCwgYnV0 DQo+ID4+Pj4+IGl0IGNvdWxkIGJlIHNob3J0ZXIgdGhhbiAvNjQgKGUuZy4sIC81NiwgLzQ4LiBl dGMuKT8gV291bGQNCj4gPj4+Pj4gdGhlIHZlaGljbGUgc3VibmV0dGluZyBiZSBzYXRpc2ZpZWQg aWYgaXQgcmVjZWl2ZWQgYSBzaG9ydGVyDQo+ID4+Pj4+IHByZWZpeCBmcm9tIHdoaWNoIG1hbnkg LzY0cyBjb3VsZCBiZSBhbGxvY2F0ZWQ/DQo+ID4+Pj4NCj4gPj4+PiBDZXJ0YWlubHkgeWVzLg0K PiA+Pj4+DQo+ID4+Pj4gRWFjaCB2ZWhpY2xlIG5lZWRzIHN1Y2ggYSBzaG9ydGVyLXRoYW4tNjQg cHJlZml4IGFsbG9jYXRlZCB0bw0KPiA+Pj4+IGl0Lg0KPiA+Pj4+DQo+ID4+Pj4gRm9yIGV4YW1w bGUsIGFuIGF1dG9tb2JpbGUgY29ubmVjdGluZyB0byBMVEUgcmVjZWl2ZXMgYSAvNjINCj4gPj4+ PiBmcm9tIHRoZSBvcGVyYXRvciBhbmQgbWFrZXMgZm91ciAvNjRzIG91dCBvZiBpdDogb25lIGZv ciBpdHMNCj4gPj4+PiBDQU4tZW50ZXJ0YWlubWVudCwgb25lIGZvciBpdHMgQ0FOLXNhZmV0eSwg b25lIGZvciBpdHMgV2lGaQ0KPiA+Pj4+IGFuZCBvbmUgZm9yIGl0cyBCbHVldG9vdGguDQo+ID4+ Pj4NCj4gPj4+PiBUaGlzIGlzIGEgTVVTVC4NCj4gPj4+Pg0KPiA+Pj4+IEFsbG9jYXRpbmcgYSBz aW5nbGUgLzY0IHRvIGEgdmVoaWNsZSBjYW4gbm90IGFjY29tbW9kYXRlIGFsbA0KPiA+Pj4+IHRo ZXNlIHVuYnJpZGdlYWJsZSBzdWJuZXRzLg0KPiA+Pj4NCj4gPj4+IE9LLCB0aGF0IGlzIGdvb2Qu IEdpdmluZyBhIG1vYmlsZSByb3V0ZXIgc29tZXRoaW5nIHNob3J0ZXIgdGhhbg0KPiA+Pj4gLzY0 IHNob3VsZCBiZSBubyBwcm9ibGVtLCBhdCBsZWFzdCB1cCB0byBwcmFjdGljYWwgbGltaXRhdGlv bnMNCj4gPj4+IG9mIHRoZSBwcmVmaXggZGVsZWdhdGlvbiBhdXRob3JpdHkncyBhdmFpbGFibGUg cHJlZml4IHNwYWNlLg0KPiA+Pj4gREhDUHY2IFBEIHByb3ZpZGVzIGFsbCB0aGF0IGlzIG5lZWRl ZCB0byBnaXZlIG91dCByaWdodC1zaXplZA0KPiA+Pj4gcHJlZml4ZXMuDQo+ID4+DQo+ID4+IEkg YWdyZWUgREhDUC1QRCBwcm92aWRlcyB0aGUgbmVjZXNzYXJ5IHRvb2wuICBCdXQgdW5mb3J0dW5h dGVseSB0aGUNCj4gPj4gY2VsbHVsYXIgb3BlcmF0b3JzIGhhdmUgbm90IGRlcGxveWVkIERIQ1B2 Ni1QRCAoYWx0aG91Z2ggeWVzIHRoZXJlDQo+ID4+IGlzIHNvbWUgREhDUC1ub24tUEQgaW4gc29t ZSBJUHY2LzRHIGRlcGxveW1lbnRzKS4NCj4gPg0KPiA+IFRoYXQgaXMgYSBwaXR5LCBiZWNhdXNl IERIQ1B2NiBQRCAoYWxvbmcgd2l0aCBJUHY2IE5EIGFuZCBCR1ApIGFyZQ0KPiA+IGFsbCB0aGF0 IGFyZSBuZWNlc3NhcnkgZm9yIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQuDQo+IA0K PiBJIGFncmVlLiAgQSBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2wgbGlrZSBCR1Agd2FzIGRlbW9u c3RyYXRlZCB0bw0KPiBmZWF0dXJlIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQgb24g YSB3aWRlIGdlb2dyYXBoaWNhbCBzY2FsZS4NCj4gDQo+ID4+IFRoZSBjb21tb24gdGhpbmtpbmcg YXQgb3BlcmF0b3JzIGFuZCBhZHZpc2VycyBpcyBzdGlsbCB0aGF0IGEgLzY0DQo+ID4+IHNob3Vs ZCBiZSBnaXZlbiB0byBhbiBVc2VyIEVxdWlwbWVudC4NCj4gPj4NCj4gPj4gVGhpcyBtdXN0IGNo YW5nZTogdGhlIDNHUFAgc3BlY3MgYW5kIG9wZXJhdG9yIGRlcGxveW1lbnRzIG11c3QNCj4gPj4g Z2l2ZSAvNjIgdG8gVUVzLCBhbmQgbm90IC82NC4NCj4gPg0KPiA+IFdoeSBub3QgYSAvTiBpbnN0 ZWFkIG9mIGp1c3QgYSAvNjIgb3IgLzY0PyBOIGNvdWxkIGJlIGFueXRoaW5nICg2MiwNCj4gPiA2 MCwgNTYsIDQ4LCBldGMuKSBhcyBsb25nIGFzIGl0IGlzIGEgcHJvcGVyIHN1YnNldCBvZiB0aGUg cHJlZml4DQo+ID4gc3BhY2UgdGhlIG9wZXJhdG9yIGhhcyBhdmFpbGFibGUgZm9yIGRlbGVnYXRp b24uDQo+IA0KPiBJIGFncmVlIHRoYXQgaW4gZ2VuZXJhbCBpdCdzIGdvb2QgdG8gYmUgbW9yZSBn ZW5lcmljIHdpdGggdGhlIHByZWZpeCBsZW5ndGguDQo+IA0KPiBCdXQgaW4gdGhpcyBwYXJ0aWN1 bGFyIGNhc2Ugd2UgYXJlIHRvbyBnZW5lcmljIGlmIHdlIGp1c3Qgc2F5ICcvTicuICBUaGUNCj4g cmVhZGVycyB3aWxsIGFzc3VtZSAnLzY0JyB0byBiZSBhIGdvb2QgZXhhbXBsZSBvZiBOLCBhbmQg dGhhdCBpcyBub3Qgc28uDQo+IA0KPiBXZSBjYW4ndCBzYXkgJ25vbi0vNjQnIGVpdGhlciwgYmVj YXVzZSBpdCBtZWFucyB0b28gbXVjaC4NCj4gDQo+IFdlIGNvdWxkIHNheSBOIGJldHdlZW4gLzQ4 IGFuZCAvNjMgaW4gb25lIGJpdCBzdGVwcy4gIEJ1dCB0byBiZSBjbGVhcg0KPiB0aGF0IC82NCBp cyBmb3JiaWRkZW4uDQo+IA0KPiAoSSBjYW4gaW1hZ2luZSB0aGUgcHJlc3N1cmUgdGhhdCBtYXkg cHV0IG9uIHRoZSBvcGVyYXRvcywgYnV0IHdlIG1heQ0KPiBhbHNvIHRoaW5rIHRoZXJlIGFyZSBl bm91Z2ggb2YgdGhlc2UgYWRkcmVzc2VzIGFuZCB0aGF0IHRoZSBwcmVzc3VyZSBpcw0KPiBzaW1w bHkgYSBtaXN1bmRlcnN0YW5kaW5nLikNCg0KV2hhdCBJIHdhcyB0aGlua2luZyB3YXMgdGhhdCB1 c2VycyBjb3VsZCBwYXkgZm9yIGRpZmZlcmVudCBjbGFzc2VzIG9mIHNlcnZpY2UuDQpCYXNpYyBz ZXJ2aWNlIGNvdWxkIGJlIGEgLzY0IChvciAvNjMgb3IgLzYyKS4gUHJlbWl1bSBzZXJ2aWNlIGNv dWxkIGJlIGEgLzYwLg0KU3VwZXItcHJlbWl1bSBjb3VsZCBiZSBhIC81NiwgZXRjLg0KDQpQb2lu dCBiZWluZyB0aGF0IHRoZSBtZWNoYW5pc20gc2hvdWxkIHN1cHBvcnQgYW55IHByZWZpeCBkZWxl Z2F0aW9uDQpzaXplIHRoYXQgdGhlIHVzZXIgaGFzIGNvbnRyYWN0ZWQgd2l0aCB0aGUgc2Vydmlj ZSBwcm92aWRlciBmb3I7IG5vdA0KanVzdCBhIGZpeGVkIG9uZS1zaXplLWZpdHMtYWxsIHNpemUg Zm9yIGFsbCB1c2Vycy4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNv bQ0KDQo+IA0KPiBBbGV4DQo+IA0KPiANCj4gDQo+IA0KPiA+DQo+ID4gVGhhbmtzIC0gRnJlZCBm cmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+ID4NCj4gPj4gQWxleA0KPiA+Pg0KPiA+Pj4NCj4g Pj4+IFRoYW5rcyAtIEZyZWQgZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+Pj4NCj4gPj4+ Pg0KPiA+Pj4+IEFsZXgNCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3MgLSBGcmVkIGZy ZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBBbGV4DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gQnV0IHllcywgSSBhZ3Jl ZSB3aXRoIHlvdS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IGNoZWVycywgLS1zYXRvcnUNCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+IE9uIFdlZCwgTWF5IDI3LCAyMDE1IGF0IDg6MzEgUE0sIEFsZXhhbmRy dSBQZXRyZXNjdQ0KPiA+Pj4+Pj4+IDxhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tDQo+ID4+ Pj4+Pj4gPG1haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPj4gd3JvdGU6DQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiBIaSwNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEluIGFkZGl0aW9uIHRv IHdoYXQgQmVoY2V0IHNheXMuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJIHJlYWQgdGhlIGV4YW1w bGUgYmVsb3cuICBJIHRoaW5rIGl0IGlzIGp1c3QgYW4NCj4gPj4+Pj4+PiBleGFtcGxlLCBidXQg anVzdCB0byBtYWtlIHN1cmUuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBQbGVhc2UgLSBkbyBub3Qg YWxsb2NhdGUgLzY0cyB0byBlbmQgdXNlcnMgaW4gYSBjZWxsdWxhcg0KPiA+Pj4+Pj4+IG5ldHdv cmsuIEFsbG9jYXRlIGF0IGxlYXN0IC82MnMgdG8gZW5kIHVzZXJzLg0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4gVGhpcyBpcyB0byBhbGxvdyB0aGUgc21hcnRwaG9uZSB0byBwZXJmb3JtIHRldGhlcmlu Zw0KPiA+Pj4+Pj4+IChzbWFsbCBuZXR3b3JrIG9mIHdpZmkgZGV2aWNlcyBjb25uZWN0aW5nIHRo cm91Z2ggdGhlDQo+ID4+Pj4+Pj4gc21hcnRwaG9uZSB0byB0aGUgSW50ZXJuZXQpLg0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4gVGhlIGFzc3VtcHRpb24gb2YgLzY0IHRvIGVuZCB1c2VyIGlzIG5vdCBn b29kIGF0IGFsbC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IChhbmQgeWVzLCBJIGFncmVlIHRoYXQg dGhlc2UgLzYycyBtYXkgYmUgYWdncmVnYXRlZCBpbnRvDQo+ID4+Pj4+Pj4gYSBsYXJnZXIgcHJl Zml4IGFuZCBhZHZlcnRpc2VkIHVwc3RyZWFtIGFzIGEgc2luZ2xlDQo+ID4+Pj4+Pj4gcHJlZml4 IGluc3RlYWQgb2YgbXVsdGlwbGUgaG9zdC1iYXNlZCByb3V0ZXMpLg0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4gWW91cnMsDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBBbGV4IFBldHJlc2N1DQo+ID4+Pj4+ Pj4NCj4gPj4+Pj4+PiBMZSAyNi8wNS8yMDE1IDIyOjM0LCBCZWhjZXQgU2FyaWtheWEgYSDDqWNy aXQgOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSGkgU2F0b3J1LA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+ Pj4gVGhhbmtzIGZvciB5b3VyIHJlcGx5Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gTGV0IG1lIGNv bnRpbnVlIHRoZSBkaXNjdXNzaW9uIHdpdGggeW91ciB0ZXh0IGluIFNlY3Rpb24NCj4gPj4+Pj4+ PiAzLjIgd2hlcmUgeW91IG1lbnRpb24gdkVQQyBtYXkgdXRpbGl6ZXMgRm9yd2FyZGluZw0KPiA+ Pj4+Pj4+IFBvbGljeSBDb25maWd1cmF0aW9uIFByb3RvY29sIChGUENQKSB0aGF0IGRlZmluZXMg RlBDUA0KPiA+Pj4+Pj4+IEFnZW50IGZ1bmN0aW9uIGFuZCBDbGllbnQgZnVuY3Rpb24uDQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHlvdSBjb3VsZCBqdXN0aWZ5 IGRlZmluaW5nIGEgbmV3DQo+ID4+Pj4+Pj4gZm9yd2FyZGluZyBwb2xpY3kgY29uZmlndXJhdGlv biBwcm90b2NvbCB0byBkbyB0aGlzDQo+ID4+Pj4+Pj4gQWdlbnQvQ2xpZW50IGZ1bmN0aW9uYWxp dHk/IFdoeSBub3QgdXNlIHNpbWlsYXINCj4gPj4+Pj4+PiBBZ2VudC9DbGllbnQgbW9kZWxzIHRo YXQgYXJlIGJlaW5nIGRlZmluZWQgcmF0aGVyIHRoYW4NCj4gPj4+Pj4+PiBkZWZpbmluZyBhIG5l dyBwcm90b2NvbD8gSSB0aGluayB0aGlzIHBvaW50IHJlcXVpcmVzDQo+ID4+Pj4+Pj4gbXVjaCBz dHJvbmdlciBqdXN0aWZpY2F0aW9uIHdoaWNoIEkgY291bGQgbm90IHNlZSBpbg0KPiA+Pj4+Pj4+ IFNlY3Rpb24gMy4yLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gQXJlIHlvdSB0aGF0IHdlIGhhdmUg dG8gdG8gcmVpbnZlbnQgdGhlIHdoZWVsLCByYXRoZXINCj4gPj4+Pj4+PiB0aGFuIHJldXNpbmcg c29tZXRoaW5nIHRoYXQgaXMgYWxyZWFkeSBhdmFpbGFibGU/IEhvdw0KPiA+Pj4+Pj4+IGFyZSB3 ZSBnb2luZyB0byByZWludmVudCB0aGF0IHdoZWVsIGFsc28gcmVtYWlucyB0byBiZQ0KPiA+Pj4+ Pj4+IHNlZW4sIEkgdGhpbmsuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBSZWdhcmRzLA0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4gQmVoY2V0DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ ID4+Pj4+Pj4gT24gU2F0LCBNYXkgMTYsIDIwMTUgYXQgODowMSBBTSwgU2F0b3J1IE1hdHN1c2hp bWENCj4gPj4+Pj4+PiA8c2F0b3J1Lm1hdHN1c2hpbWFAZ21haWwuY29tDQo+ID4+Pj4+Pj4gPG1h aWx0bzpzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb20+PiB3cm90ZToNCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+IEhpIEJlY2hldC1zYW4sDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGFuayB5b3UgZm9y IHlvdXIgcXVlc3Rpb24uIEluIHN0ZXAgKDE1KSwgSSBtZWFudCB0aGF0DQo+ID4+Pj4+Pj4gRVBD LUUgYWR2ZXJ0aXNlcyBwcmVmaXggaW5jbHVkaW5nIFVFIGFzc2lnbmVkIHByZWZpeGVzLg0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+Pj4gRm9yIGV4YW1wbGUsIGluIHRoZSBjYXNlIG9mIC82NCBwcmVmaXhl cyBhc3NpZ25lZCB0byBVRXMNCj4gPj4+Pj4+PiAgZnJvbSBhIC81NiBzcGFjZSwgdGhhdCAvNTYg aXMgYWR2ZXJ0aXNlZCBieSBFUEMtRSB0bw0KPiA+Pj4+Pj4+IHVwc3RyZWFtIHJvdXRlcnMuIFNv IHRoZSBhZHZlcnRpc2VkIHJvdXRlIGlzbid0IGhvc3QNCj4gPj4+Pj4+PiByb3V0ZXMuDQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiBEZXBlbmRzIG9uIGNvbmZpZ3VyYXRpb24gcG9saWN5LCBidXQgb25l IGNhc2UgaXMgdGhhdCB0aGUNCj4gPj4+Pj4+PiBzb3VyY2Ugb2YgdGhhdCBhZHZlcnRpc2VkIC81 NiByb3V0ZSBtaWdodCBiZSBzdGF0aWNhbGx5DQo+ID4+Pj4+Pj4gY29uZmlndXJlZCBpbiBFUEMt RS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFJlZ2FyZHMsIC0tc2F0b3J1DQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gV2VkLCBNYXkgMTMsIDIwMTUgYXQgNDo1 MSBBTSwgQmVoY2V0IFNhcmlrYXlhDQo+ID4+Pj4+Pj4gPHNhcmlrYXlhMjAxMkBnbWFpbC5jb20g PG1haWx0bzpzYXJpa2F5YTIwMTJAZ21haWwuY29tPj4NCj4gPj4+Pj4+PiAgd3JvdGU6DQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEhpIE1hdHN1c2hpbWEtc2FuLA0KPiA+Pj4+Pj4+ DQo+ID4+Pj4+Pj4gSSBoYXZlIGEgcXVlc3Rpb24gb24geW91ciBkcmFmdDogSW4gU2VjLiAzLjIs IHBhZ2UgMTEsDQo+ID4+Pj4+Pj4geW91IHNheSBJbiBzdGVwICgxNSksIHRoZSBFUEMtRSBhZHZl cnRpc2VzIHJvdXRlcyB0bw0KPiA+Pj4+Pj4+IHVwc3RyZWFtIHJvdXRlcnMgLi4uDQo+ID4+Pj4+ Pj4NCj4gPj4+Pj4+PiBBcmUgdGhlc2Ugcm91dGVzIHN0YXRpYy9ob3N0IHJvdXRlcz8NCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBCZWhjZXQNCj4g Pj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGRtbQ0KPiA+Pj4+Pj4+ IG1haWxpbmcgbGlzdCBkbW1AaWV0Zi5vcmcgPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQo+ID4+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGRtbQ0KPiA+Pj4+Pj4+IG1haWxpbmcg bGlzdCBkbW1AaWV0Zi5vcmcgPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQo+ID4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIGRtbQ0KPiA+Pj4+Pj4gbWFpbGluZyBsaXN0IGRtbUBpZXRm Lm9yZw0KPiA+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0N Cj4gPj4+Pg0KPiA+Pj4NCj4gPj4NCj4gPg0KDQo= From nobody Mon Jun 8 13:42:47 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB141A8A27 for ; Mon, 8 Jun 2015 13:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AtrkrR4u4ut for ; Mon, 8 Jun 2015 13:42:44 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942401A8A1F for ; Mon, 8 Jun 2015 13:42:44 -0700 (PDT) Received: by qczw4 with SMTP id w4so55177187qcz.2 for ; Mon, 08 Jun 2015 13:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4bimOWkAFokvKtCYSHfP3PpOz/3TT2ySVNogP2jBC54=; b=05saMdvk5ExcSwe4rgUqkICaQV+2vNdTEcSMskdXCsIlIK+ZuuGdjXBcvZdv72Jdwe 1RVOjY5d/gII1M9d8UabheaehQrar6SKhYX1Eh474qqzOw1c+6QM41c1ZBiQJy2EFG/1 nTPNeLizNZncGRxUGBWKKTBW/IqDFEsF3nud+8B76i9yyXfvvy1ExhTc4KsKDh+CBSVj n8JKzSGI1ibwMggDH/7WjrqVo4yDVuN4E+GUxhpEocRfceJCER/yNXm5clD6yu0D1S4v diGkA3TLZ0K5Xt0sa4Nql2PjX1JuOGNQlHj5IJb3f+Uyyxua2vs1ndnwvkBnUcZ+R9Od HdCQ== X-Received: by 10.140.32.38 with SMTP id g35mr21276181qgg.74.1433796163868; Mon, 08 Jun 2015 13:42:43 -0700 (PDT) Received: from [10.16.11.141] ([216.31.219.19]) by mx.google.com with ESMTPSA id 104sm1719266qgj.43.2015.06.08.13.42.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2015 13:42:43 -0700 (PDT) Message-ID: <5575FE41.9010103@gmail.com> Date: Mon, 08 Jun 2015 13:42:41 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dmm@ietf.org" , =?UTF-8?B?5oiQIOm5jw==?= References: <553D5C40.5050301@gmail.com> In-Reply-To: <553D5C40.5050301@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] IETF93 meeting.. and forming the agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 20:42:45 -0000 Folks, Just reminding you all. We got two early bird requests so far. - Jouni & Dapeng 4/26/2015, 2:44 PM, Jouni Korhonen kirjoitti: > Folks, > > Summer is getting closer as well as the Prague meeting. If you feel like > having a presentation slot in the meeting let the chairs know (with I-D > name, time requested and a reason why you need a slot). > > The WG I-Ds will have precedence and the rest of the available time will > be divided using secret formula to individual contributions. > > We'd like to emphasize that for any I-Ds having discussion on the > mailing list prior the meeting is a great plus and for a new work almost > a prerequisite. > > > > Jouni & dapeng From nobody Mon Jun 8 14:29:36 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0541A8AE4 for ; Mon, 8 Jun 2015 14:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dHj7JEADwmN for ; Mon, 8 Jun 2015 14:29:32 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AA11A8F36 for ; Mon, 8 Jun 2015 14:29:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t58LTWik030834; Mon, 8 Jun 2015 16:29:32 -0500 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t58LTPfV030789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 8 Jun 2015 16:29:26 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.226]) with mapi id 14.03.0235.001; Mon, 8 Jun 2015 14:29:25 -0700 From: "Templin, Fred L" To: dmm Thread-Topic: Scaling properties of AERO Thread-Index: AdCiMU2vkCk188h2SG+1hIBCXKsmQw== Date: Mon, 8 Jun 2015 21:29:24 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E84ED7@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [DMM] Scaling properties of AERO X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 21:29:35 -0000 Hi, I finally had a chance to sit back and think about the scaling properties o= f AERO, and I think it is within reason for each AERO link to service O(10^9) Clien= ts. Here is what I wrote in the latest AERO draft version: "Scaling properties of the AERO routing system are therefore limited by the number of BGP routes that can be carried by Relays. Assuming O(10^6) as a maximum number of BGP routes, this means that at most O(10^6) Clients can be serviced by Relays within a single BGP instance. A means of increasing scaling would be to assign a different set of Relays for each set of ASPs, and still have each Server peer with each Relay but with a distinct BGP instance for each Relay set. Another possibility would be for Servers to institute route filters within a single BGP instance so that each set of Relays only receives BGP updates for the ASPs they aggregate. Assuming up to O(10^3) sets of Relays, scaling can then accommodate O(10^9) Clients with no additional overhead for Servers and Relays. In this way, each set of Relays services a specific set of ASPs that they advertise to peers outside of the AERO link, and each Server configures ASP-specific routes that list the correct set of Relays as next hops." https://datatracker.ietf.org/doc/draft-templin-aerolink/ Comments? Thanks - Fred fred.l.templin@boeing.com From nobody Mon Jun 8 16:07:25 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28DF1ACD0B for ; Mon, 8 Jun 2015 16:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.461 X-Spam-Level: X-Spam-Status: No, score=-4.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-3Obwo-jHqZ for ; Mon, 8 Jun 2015 16:07:23 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 935F71ACD00 for ; Mon, 8 Jun 2015 16:07:23 -0700 (PDT) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 08 Jun 2015 16:07:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,576,1427785200"; d="scan'208";a="505115835" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by FMSMGA003.fm.intel.com with ESMTP; 08 Jun 2015 16:07:21 -0700 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by irsmsx105.ger.corp.intel.com (163.33.3.28) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 9 Jun 2015 00:07:20 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.194]) by LCSMSX154.ger.corp.intel.com ([169.254.7.170]) with mapi id 14.03.0224.002; Tue, 9 Jun 2015 02:07:18 +0300 From: "Moses, Danny" To: Jouni Korhonen , "dmm@ietf.org" , ? ? Thread-Topic: [DMM] IETF93 meeting.. and forming the agenda Thread-Index: AQHQoivGl1v6CojDU02HlAK4BHjrF52jO0RQ Date: Mon, 8 Jun 2015 23:07:18 +0000 Message-ID: References: <553D5C40.5050301@gmail.com> <5575FE41.9010103@gmail.com> In-Reply-To: <5575FE41.9010103@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="gb2312" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [DMM] IETF93 meeting.. and forming the agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 23:07:24 -0000 SGksDQoNCkkgd291bGQgbGlrZSBhIDIwIG1pbnV0ZSBzbG90IHRvIGRpc2N1c3MgdGhlIERIQ1Ag b24tZGVtYW5kIGRyYWZ0Lg0KDQpUaGFua3MsDQoJL0Rhbm55DQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEpvdW5pIEtvcmhvbmVuDQpTZW50OiBNb25kYXksIEp1bmUgMDgsIDIwMTUgMjM6NDMN ClRvOiBkbW1AaWV0Zi5vcmc7ILPJIMX0DQpTdWJqZWN0OiBSZTogW0RNTV0gSUVURjkzIG1lZXRp bmcuLiBhbmQgZm9ybWluZyB0aGUgYWdlbmRhDQoNCkZvbGtzLA0KDQpKdXN0IHJlbWluZGluZyB5 b3UgYWxsLiBXZSBnb3QgdHdvIGVhcmx5IGJpcmQgcmVxdWVzdHMgc28gZmFyLg0KDQotIEpvdW5p ICYgRGFwZW5nDQoNCjQvMjYvMjAxNSwgMjo0NCBQTSwgSm91bmkgS29yaG9uZW4ga2lyam9pdHRp Og0KPiBGb2xrcywNCj4NCj4gU3VtbWVyIGlzIGdldHRpbmcgY2xvc2VyIGFzIHdlbGwgYXMgdGhl IFByYWd1ZSBtZWV0aW5nLiBJZiB5b3UgZmVlbCANCj4gbGlrZSBoYXZpbmcgYSBwcmVzZW50YXRp b24gc2xvdCBpbiB0aGUgbWVldGluZyBsZXQgdGhlIGNoYWlycyBrbm93IA0KPiAod2l0aCBJLUQg bmFtZSwgdGltZSByZXF1ZXN0ZWQgYW5kIGEgcmVhc29uIHdoeSB5b3UgbmVlZCBhIHNsb3QpLg0K Pg0KPiBUaGUgV0cgSS1EcyB3aWxsIGhhdmUgcHJlY2VkZW5jZSBhbmQgdGhlIHJlc3Qgb2YgdGhl IGF2YWlsYWJsZSB0aW1lIA0KPiB3aWxsIGJlIGRpdmlkZWQgdXNpbmcgc2VjcmV0IGZvcm11bGEg dG8gaW5kaXZpZHVhbCBjb250cmlidXRpb25zLg0KPg0KPiBXZSdkIGxpa2UgdG8gZW1waGFzaXpl IHRoYXQgZm9yIGFueSBJLURzIGhhdmluZyBkaXNjdXNzaW9uIG9uIHRoZSANCj4gbWFpbGluZyBs aXN0IHByaW9yIHRoZSBtZWV0aW5nIGlzIGEgZ3JlYXQgcGx1cyBhbmQgZm9yIGEgbmV3IHdvcmsg DQo+IGFsbW9zdCBhIHByZXJlcXVpc2l0ZS4NCj4NCj4NCj4NCj4gSm91bmkgJiBkYXBlbmcNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWls aW5nIGxpc3QNCmRtbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kbW0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24g Z3JvdXAgb2YgY29tcGFuaWVzCgpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3IKdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRl bmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uCmJ5IG90aGVycyBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBp ZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4K From nobody Mon Jun 8 18:08:00 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B961A0193 for ; Mon, 8 Jun 2015 18:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.539 X-Spam-Level: *** X-Spam-Status: No, score=3.539 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFCxK3RT969Q for ; Mon, 8 Jun 2015 18:07:57 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4568F1A0171 for ; Mon, 8 Jun 2015 18:07:52 -0700 (PDT) Received: from Foxmail (unknown [218.241.103.94]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0DJ0HxjPHZVG51oBw--.60559S2; Tue, 09 Jun 2015 09:07:47 +0800 (CST) Date: Tue, 9 Jun 2015 09:07:47 +0800 From: "Z.W. Yan" To: "Jouni Korhonen" , "dmm@ietf.org" , "=?gb2312?B?s8kgxfQ=?=" References: <553D5C40.5050301@gmail.com>, <5575FE41.9010103@gmail.com> Message-ID: <201506090907465388265@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon165458334544_=====" X-CM-TRANSID: AQAAf0DJ0HxjPHZVG51oBw--.60559S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZr13tr4ftryDur4UKF4DJwb_yoWkZFb_ur 1jgry8Aw1rtr10qF43tF1UGrnrWr42g3WUZ34DXry7ZryIyw4DXwn8Kry3W3WIyrW7Cry5 KFWSyr1kGrZrWjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb3AYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I 8E87Iv6xkF7I0E14v26r4UJVWxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAI xVCFxsxG0wAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6x CaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC 0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7x kEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E 67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCw CI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E 3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCT nIWIevJa73UjIFyTuYvjxUzAwIDUUUU X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Cc: xl Subject: Re: [DMM] IETF93 meeting.. and forming the agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 01:07:59 -0000 This is a multi-part message in MIME format. --=====003_Dragon165458334544_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEpvdW5pLA0KSSB3b3VsZCBsaWtlIHRvIGhhdmUgMTAgbWludXRlcyB0byBwcmVzZW50IHRo ZSBITlAtcmVudW1iZXJpbmcgZHJhZnQ6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFm dC15YW4tZG1tLWhucHJlbnVtLTAxLnR4dCANCg0KVGhhbmsgeW91IHNvIG11Y2ghDQpCUiwNCg0K DQoyMDE1LTA2LTA5IA0KDQoNCg0KWi5XLiBZYW4gDQoNCg0KDQq3orz+yMujuiBKb3VuaSBLb3Jo b25lbiANCreiy83Ksbzko7ogMjAxNS0wNi0wOSAgMDQ6NDI6NTEgDQrK1bz+yMujuiBkbW1AaWV0 Zi5vcmc7ILPJIMX0IA0Ks63LzaO6IA0K1vfM4qO6IFJlOiBbRE1NXSBJRVRGOTMgbWVldGluZy4u IGFuZCBmb3JtaW5nIHRoZSBhZ2VuZGEgDQogDQpGb2xrcywNCkp1c3QgcmVtaW5kaW5nIHlvdSBh bGwuIFdlIGdvdCB0d28gZWFybHkgYmlyZCByZXF1ZXN0cyBzbyBmYXIuDQotIEpvdW5pICYgRGFw ZW5nDQo0LzI2LzIwMTUsIDI6NDQgUE0sIEpvdW5pIEtvcmhvbmVuIGtpcmpvaXR0aToNCj4gRm9s a3MsDQo+DQo+IFN1bW1lciBpcyBnZXR0aW5nIGNsb3NlciBhcyB3ZWxsIGFzIHRoZSBQcmFndWUg bWVldGluZy4gSWYgeW91IGZlZWwgbGlrZQ0KPiBoYXZpbmcgYSBwcmVzZW50YXRpb24gc2xvdCBp biB0aGUgbWVldGluZyBsZXQgdGhlIGNoYWlycyBrbm93ICh3aXRoIEktRA0KPiBuYW1lLCB0aW1l IHJlcXVlc3RlZCBhbmQgYSByZWFzb24gd2h5IHlvdSBuZWVkIGEgc2xvdCkuDQo+DQo+IFRoZSBX RyBJLURzIHdpbGwgaGF2ZSBwcmVjZWRlbmNlIGFuZCB0aGUgcmVzdCBvZiB0aGUgYXZhaWxhYmxl IHRpbWUgd2lsbA0KPiBiZSBkaXZpZGVkIHVzaW5nIHNlY3JldCBmb3JtdWxhIHRvIGluZGl2aWR1 YWwgY29udHJpYnV0aW9ucy4NCj4NCj4gV2UnZCBsaWtlIHRvIGVtcGhhc2l6ZSB0aGF0IGZvciBh bnkgSS1EcyBoYXZpbmcgZGlzY3Vzc2lvbiBvbiB0aGUNCj4gbWFpbGluZyBsaXN0IHByaW9yIHRo ZSBtZWV0aW5nIGlzIGEgZ3JlYXQgcGx1cyBhbmQgZm9yIGEgbmV3IHdvcmsgYWxtb3N0DQo+IGEg cHJlcmVxdWlzaXRlLg0KPg0KPg0KPg0KPiBKb3VuaSAmIGRhcGVuZw0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg== --=====003_Dragon165458334544_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgMTAuMDAuOTIwMC4xNzM1NyI+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9u dC1mYW1pbHk6IMvOzOU7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFuYTsN Cn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBAy87M5TsNCn0NCkBwYWdlIFNlY3Rpb24x IHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAx MC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlm eTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0N CkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMg TmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVY VC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZPTlQtU0la RTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1 c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBo DQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0K fQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVu ZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBs ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglG T05ULUZBTUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3Rl eHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28tc3R5bGUt dHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9u MQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsNCglNQVJH SU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW07IE1BUkdJTi1UT1A6IDBweA0KfQ0KT0wg ew0KCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQpVTCB7DQoJTUFSR0lO LUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgTUFSR0lOOiAx MHB4Ij4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPkhpLCBK b3VuaSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+SSB3b3VsZCBsaWtl IHRvIGhhdmUgMTAgbWludXRlcyB0byBwcmVzZW50IHRoZSANCkhOUC1yZW51bWJlcmluZyBkcmFm dDo8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48QSANCmhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC15YW4tZG1tLWhucHJlbnVtLTAxLnR4dCI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXlhbi1kbW0taG5wcmVudW0tMDEudHh0PC9BPiANCjwv RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgY29sb3I9IzAwMDA4MD5UaGFuayB5b3Ugc28gbXVjaCE8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwODA+QlIsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j MDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxNS0wNi0wOSA8 L0ZPTlQ+PC9ESVY+PEZPTlQgDQpjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8 SFIgc3R5bGU9IldJRFRIOiAxMDBweCIgYWxpZ249bGVmdCBjb2xvcj0jYjVjNGRmIFNJWkU9MT4N CjwvRk9OVD4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjxT UEFOPlouVy4gWWFuPC9TUEFOPiA8L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1YzRkZiBTSVpF PTE+DQoNCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPreivP7Iy6O6PC9T VFJPTkc+IEpvdW5pIEtvcmhvbmVuIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIg ZmFjZT1WZXJkYW5hPjxTVFJPTkc+t6LLzcqxvOSjujwvU1RST05HPiAyMDE1LTA2LTA5Jm5ic3A7 IDA0OjQyOjUxIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5h PjxTVFJPTkc+ytW8/sjLo7o8L1NUUk9ORz4gZG1tQGlldGYub3JnOyCzySDF9CANCjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPrOty82jujwvU1RS T05HPiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9O Rz7W98zio7o8L1NUUk9ORz4gUmU6IFtETU1dIElFVEY5MyBtZWV0aW5nLi4gDQphbmQgZm9ybWlu ZyB0aGUgYWdlbmRhIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFu YT48L0ZPTlQ+IDwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJVj5G b2xrcyw8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkp1c3QmbmJzcDtyZW1pbmRpbmcmbmJzcDt5 b3UmbmJzcDthbGwuJm5ic3A7V2UmbmJzcDtnb3QmbmJzcDt0d28mbmJzcDtlYXJseSZuYnNwO2Jp cmQmbmJzcDtyZXF1ZXN0cyZuYnNwO3NvJm5ic3A7ZmFyLjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+LSZuYnNwO0pvdW5pJm5ic3A7JmFtcDsmbmJzcDtEYXBlbmc8L0RJVj4NCjxESVY+PC9ESVY+ DQo8RElWPjQvMjYvMjAxNSwmbmJzcDsyOjQ0Jm5ic3A7UE0sJm5ic3A7Sm91bmkmbmJzcDtLb3Jo b25lbiZuYnNwO2tpcmpvaXR0aTo8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0ZvbGtzLDwvRElWPg0K PERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtTdW1tZXImbmJzcDtpcyZuYnNwO2dldHRp bmcmbmJzcDtjbG9zZXImbmJzcDthcyZuYnNwO3dlbGwmbmJzcDthcyZuYnNwO3RoZSZuYnNwO1By YWd1ZSZuYnNwO21lZXRpbmcuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtmZWVsJm5ic3A7bGlrZTwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7aGF2aW5nJm5ic3A7YSZuYnNwO3ByZXNlbnRhdGlvbiZuYnNw O3Nsb3QmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO21lZXRpbmcmbmJzcDtsZXQmbmJzcDt0aGUmbmJz cDtjaGFpcnMmbmJzcDtrbm93Jm5ic3A7KHdpdGgmbmJzcDtJLUQ8L0RJVj4NCjxESVY+Jmd0OyZu YnNwO25hbWUsJm5ic3A7dGltZSZuYnNwO3JlcXVlc3RlZCZuYnNwO2FuZCZuYnNwO2EmbmJzcDty ZWFzb24mbmJzcDt3aHkmbmJzcDt5b3UmbmJzcDtuZWVkJm5ic3A7YSZuYnNwO3Nsb3QpLjwvRElW Pg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtUaGUmbmJzcDtXRyZuYnNwO0ktRHMm bmJzcDt3aWxsJm5ic3A7aGF2ZSZuYnNwO3ByZWNlZGVuY2UmbmJzcDthbmQmbmJzcDt0aGUmbmJz cDtyZXN0Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDthdmFpbGFibGUmbmJzcDt0aW1lJm5ic3A7d2ls bDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7YmUmbmJzcDtkaXZpZGVkJm5ic3A7dXNpbmcmbmJzcDtz ZWNyZXQmbmJzcDtmb3JtdWxhJm5ic3A7dG8mbmJzcDtpbmRpdmlkdWFsJm5ic3A7Y29udHJpYnV0 aW9ucy48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7V2UnZCZuYnNwO2xp a2UmbmJzcDt0byZuYnNwO2VtcGhhc2l6ZSZuYnNwO3RoYXQmbmJzcDtmb3ImbmJzcDthbnkmbmJz cDtJLURzJm5ic3A7aGF2aW5nJm5ic3A7ZGlzY3Vzc2lvbiZuYnNwO29uJm5ic3A7dGhlPC9ESVY+ DQo8RElWPiZndDsmbmJzcDttYWlsaW5nJm5ic3A7bGlzdCZuYnNwO3ByaW9yJm5ic3A7dGhlJm5i c3A7bWVldGluZyZuYnNwO2lzJm5ic3A7YSZuYnNwO2dyZWF0Jm5ic3A7cGx1cyZuYnNwO2FuZCZu YnNwO2ZvciZuYnNwO2EmbmJzcDtuZXcmbmJzcDt3b3JrJm5ic3A7YWxtb3N0PC9ESVY+DQo8RElW PiZndDsmbmJzcDthJm5ic3A7cHJlcmVxdWlzaXRlLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8 RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Sm91bmkmbmJz cDsmYW1wOyZuYnNwO2RhcGVuZzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4NCjxESVY+ZG1tJm5ic3A7 bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+ZG1tQGlldGYub3JnPC9ESVY+DQo8RElWPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9ESVY+PC9GT05UPjwvRElW PjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon165458334544_=====-- From nobody Tue Jun 9 07:48:03 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356741A882D for ; Tue, 9 Jun 2015 07:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJLjDlM7B-FB for ; Tue, 9 Jun 2015 07:47:57 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::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 717BC1A882B for ; Tue, 9 Jun 2015 07:47:57 -0700 (PDT) Received: by pdbnf5 with SMTP id nf5so16795249pdb.2 for ; Tue, 09 Jun 2015 07:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=SbRwfEfOx3JI/EPyX2jokzupJ6YX18PNOdx9Ahj72rI=; b=0vgBYKlf1aFMJnkFVWfinv3kgzkWlPwz/mrsIZjhFAxr2mzIn3eewgfW0lJlVMKo6v gfpozhpEggtZnpQpBCS9lkxvgTKlhC6M5bx+sp5Wf6dKeY5KMOfEpcxC4jCYzilwbkOw KArgheR/+tS7q5TOPOShLmjDG9CyljHJzEmI/rZaHvo2kc2qd6Z9YupN7781HAzBnXVb qz4fp+nFKODmhk7ZcMYMUABaAtoLUFguZKLs2mCBimVZygwiJOhFjAL1JMsg3wRIE3cN 6Bu8H+anyp1+i/l05aZvEp9eqVbVa/9ZBbp8sz252o8g1/AY+t1mYs2Iwlgt7QUYhmTm CLhA== X-Received: by 10.68.231.98 with SMTP id tf2mr39996352pbc.12.1433861276950; Tue, 09 Jun 2015 07:47:56 -0700 (PDT) Received: from [192.168.0.104] ([115.171.8.139]) by mx.google.com with ESMTPSA id w7sm5877601pbs.69.2015.06.09.07.47.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jun 2015 07:47:55 -0700 (PDT) Date: Tue, 9 Jun 2015 22:43:33 +0800 From: Dapeng Liu To: Seil Jeon Message-ID: In-Reply-To: <000301d0a203$b8ccde60$2a669b20$@av.it.pt> References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> <005d01d09de5$dadd6b40$909841c0$@av.it.pt> <3620CF9B-EF59-4DF0-993F-4442D91604DC@yegin.org> <000301d0a203$b8ccde60$2a669b20$@av.it.pt> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5576fc49_6b68079a_117" Archived-At: Cc: Dapeng Liu , dmm@ietf.org Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= FW: [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 14:48:02 -0000 --5576fc49_6b68079a_117 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Seil, =20 You can refer to this: http://trac.tools.ietf.org/wg/dmm/trac/wiki/TracTi= ckets =20 A simple way would be adding comment to the existing ticket. -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B46=E6=9C=888=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF= =BC=8C=E4=B8=8B=E5=8D=8811:56=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A= > Hi Chairs, > =20 > We want to elaborate the issue created in the tracker for clarity. What= Action should I take in =E2=80=9CModify Ticket=E2=80=9D=3F > =20 > - leave as new > - resolve as =E2=80=A6 > - reassign to =E2=80=A6 > =20 > =20 > Regards, > Seil > =20 > =46rom: Alper Yegin =5Bmailto:alper.yegin=40yegin.org=5D =20 > Sent: Wednesday, June 03, 2015 11:34 AM > To: Seil Jeon > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: Re: =5BDMM=5D =5Bdmm=5D =2349 (ondemand-mobility): full on-dem= and mobility support > =20 > OK, so now at least I fully understand what this is. > =20 > =20 > My recommendation is: > =20 > - Please refine the issue definition in the tracker, so that people can= understand this the same way, > =20 > - And then let's ask the WG members their opinion about the issue (whet= her it's something worth tackling or not), > =20 > - And if they agree to the issue, then we move to the solution space di= scussion. > =20 > =20 > =20 > Alper > =20 > =20 > =20 > =20 > On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote: > =20 > =20 > =20 > - A Sustained IP address that just got allocated from the currently ser= ving network (hence the =22mobility is not activated=22 until the MN move= s off link)=3F > > Yes. Thanks for your elaboration. > =20 > =20 > =20 > =20 > =20 > Regards, > =20 > Seil > =20 > =20 > =20 > =20 > =20 > =46rom: Alper Yegin =5Bmailto:alper.yegin=40yegin.org=5D =20 > Sent: Wednesday, June 03, 2015 7:03 AM > To: Seil Jeon > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: Re: =5BDMM=5D =5Bdmm=5D =2349 (ondemand-mobility): full on-dem= and mobility support > =20 > =20 > > So, the idea is, when this flag is set along with a Sustained IP addr= ess request from the app: > > =20 > > =20 > > - if the host stack is already configured with a Sustained IP address= allocated from the serving network, then it gets selected (irrespective = of the presence or absence of any other Sustained IP address). > > =20 > > =20 > > =20 > > =20 > > =20 > > >> No. I said =22one that does not activate IP mobility=22 over the s= erving network, among the existing ones in the IP stack, gets selected. I= f no one in the IP stack is not matched, it will make an attempt to get a= new sustained IP address from the serving network. > > =20 > > =20 > > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > What exactly is =22(an IP address) that does not activate IP mobility=22= =3F Please elaborate. > =20 > =20 > =20 > =20 > =20 > Is it > =20 > =20 > - A nomadic IP address=3F > =20 > =20 > =20 > =20 > - A Sustained IP address that just got allocated from the currently ser= ving network (hence the =22mobility is not activated=22 until the MN move= s off link)=3F > =20 > =20 > =20 > =20 > - something else=3F > =20 > =20 > =20 > =20 > =20 > Alper > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote: > =20 > =20 > =20 > =20 > =20 > Hi Alper, > =20 > =20 > =20 > Regards, > =20 > =20 > Seil > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > -----Original Message----- > =46rom: Alper Yegin =5Bmailto:alper.yegin=40yegin.org=5D =20 > Sent: Monday, June 01, 2015 8:50 PM > To: Seil Jeon > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: Re: =5BDMM=5D =5Bdmm=5D =2349 (ondemand-mobility): full on-dem= and mobility support > =20 > =20 > =20 > > The point is that when the IP stack receives a flag with sustained IP= > =20 > =20 > > address flag, it will check it has a sustained IP address, and if it > =20 > =20 > > has one or more, one that does not activate IP mobility will be > =20 > =20 > > selected. If not, the MN will be triggered to get a new IP sustained > =20 > =20 > > address not activing IP mobility. > =20 > =20 > =20 > =20 > =20 > So, the idea is, when this flag is set along with a Sustained IP addres= s request from the app: > =20 > =20 > - if the host stack is already configured with a Sustained IP address a= llocated from the serving network, then it gets selected (irrespective of= the presence or absence of any other Sustained IP address). > =20 > =20 > =20 > =20 > =20 > >> No. I said =22one that does not activate IP mobility=22 over the ser= ving network, among the existing ones in the IP stack, gets selected. If = no one in the IP stack is not matched, it will make an attempt to get a n= ew sustained IP address from the serving network. > =20 > =20 > =20 > =20 > =20 > - if the host stack is not already configured with a Sustained IP addre= ss allocated from the serving network (irrespective of the presence or ab= sence of any Sustained IP address from any other network), then the host = makes an attempt to configure one with the serving network. > =20 > =20 > =20 > =20 > =20 > >> Yes. > =20 > =20 > =20 > =20 > =20 > -- if the configuration succeeds, then the newly configured IP address = is selected. > =20 > =20 > =20 > =20 > =20 > >> Yes. > =20 > =20 > =20 > =20 > =20 > -- if the configuration fails. then the call fails (=3F=3F or some othe= r behavior -- you can define here). > =20 > =20 > =20 > =20 > =20 > >> You mean the configuration fails when there is no sustained IP addre= ss, right=3F > =20 > =20 > In my opinion, this issue belongs to address configuration mechanism ba= sed on definition of the three DMM APIs. Those jobs are/will be asked on = each configuration mechanism, according to discussion of the previous tel= econference in the WT you=E2=80=99re leading. At that time, if I see any = something related to our proposal, we will raise our voice. > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > Alper > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > >>> =2349: full on-demand mobility support > =20 > =20 > >>> =20 > =20 > =20 > >>> The three proposed flags express a =22type=22 of source IP address = an > =20 > =20 > >> application wants to get to the IP stack. Particularly, the sustaine= d > =20 > =20 > >> IP address is proposed to provide on-demand IP session continuity, > =20 > =20 > >> which activates IP mobility once the terminal moves across other > =20 > =20 > >> access > =20 > =20 > > network. > =20 > =20 > >>> While the terminal stays at the same network where the session is > =20 > =20 > >> initiated, regular IP routing is applied. > =20 > =20 > >>> =20 > =20 > =20 > >>> The on-demand draft does not assure provide the full on-demand > =20 > =20 > >>> mobility > =20 > =20 > >> for all scenarios by merely indicating the Socket API, > =20 > =20 > >> IPV6=5FREQ=5FSUSTAINED=5FIP. An example scenario raising the aforeme= ntioned > =20 > =20 > >> issue is as follows; > =20 > =20 > >>> =20 > =20 > =20 > >>> 0. The MN is configured with one or more Nomadic IP addresses. > =20 > =20 > >>> =20 > =20 > =20 > >>> 1. Once an app. requests =22sustained IP address=22 to the IP stack= , and > =20 > =20 > >>> it > =20 > =20 > >> will obtain a sustained IP address through a protocol procedure > =20 > =20 > >> between the terminal and network. > =20 > =20 > >>> =20 > =20 > =20 > >>> 2. Other app. initiated over the same access network will use the > =20 > =20 > >>> same > =20 > =20 > >> sustained IP address while the terminal remains connected at the sam= e > =20 > =20 > >> access network. > =20 > =20 > >>> =20 > =20 > =20 > >>> 3. The terminal moves to another access network and a new app. > =20 > =20 > >>> requests a > =20 > =20 > >> sustained IP address with the Socket API to the IP stack. Since a > =20 > =20 > >> sustained IP address is already available in the IP stack, the > =20 > =20 > >> sustained IP address is assigned to the new app. > =20 > =20 > >>> =20 > =20 > =20 > >> =20 > =20 > =20 > >> Yes, that's what happens. > =20 > =20 > >> You are not pointing to an issue up until this point, right=3F Becau= se, > =20 > =20 > >> you continuing your email with a =22Besides=22 gives the impression = that > =20 > =20 > >> you are pointing to an issue, but I don't see any issue captured in > =20 > =20 > >> the > =20 > =20 > > above text. > =20 > =20 > >> =20 > =20 > =20 > >>>> There is an issue. Maybe, we need to be synchronized how have you > =20 > =20 > >>>> thought > =20 > =20 > >> and defined the meaning of =22on-demand mobility=22. As far as I kno= w, > =20 > =20 > >> there are two meanings; one is that by imposing capability among IP > =20 > =20 > >> address reachability and IP session continuity, needed for an > =20 > =20 > >> application, into a source IP address, on-demand mobility could be > =20 > =20 > >> achieved; as the other meaning, it can be rephrased and detailed wit= h > =20 > =20 > >> dynamic mobility, which should be applied in the use of sustained IP= > =20 > =20 > >> address. A new application needs to have non-anchored sustained IP > =20 > =20 > >> address. This is our consistent claim. Non-optimal routing issue has= > =20 > =20 > >> been raised in DMM Requirement document in R=46C 7333, which should = be > =20 > =20 > > critically considered in the solutions. > =20 > =20 > >> =20 > =20 > =20 > > =20 > =20 > =20 > > Sorry, I don't understand what you meant here. > =20 > =20 > > =20 > =20 > =20 > >>>> You answer doesn't make us progress. Please specify where and what= > =20 > =20 > >>>> you > =20 > =20 > > have understood. > =20 > =20 > > =20 > =20 > =20 > > =20 > =20 > =20 > >>> Besides, in case sustained IP address allocation is used default, > =20 > =20 > >>> there > =20 > =20 > >> may be multiple sustained IP addresses including newly obtained > =20 > =20 > >> sustained IP address over the new access network in the IP stack. > =20 > =20 > >> However, when an app. is initiated, the IP stack may not select the > =20 > =20 > >> new one in the context of the default source IP address selection > =20 > =20 > > mechanism =5BR=46C6724=5D=5BR=46C5014=5D. > =20 > =20 > >>> =20 > =20 > =20 > >> =20 > =20 > =20 > >> OK, is the issue following: When there are multiple sustained IP > =20 > =20 > >> addresses, how does the IP stack pick one among them=3F (*) > =20 > =20 > >> =20 > =20 > =20 > >>>> As mentioned and specified in our draft > =20 > =20 > >> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00,= > =20 > =20 > >> if there is no additional preference, we can leave selection to the > =20 > =20 > >> default source address selection mechanism. BUT if we have specific > =20 > =20 > >> preference among multiple sustained IP addresses and an initiated > =20 > =20 > >> application wants to have non-anchored sustained IP address over > =20 > =20 > >> currently attached access network, the proposed flag is essential. > =20 > =20 > >> =20 > =20 > =20 > > =20 > =20 > =20 > > I think you are meaning the same thing as I said above (*). > =20 > =20 > > Do you agree=3F > =20 > =20 > > =20 > =20 > =20 > >>>> Yes. > =20 > =20 > > =20 > =20 > =20 > >>> =46or providing the full on-demand mobility, a new flag is needed, > =20 > =20 > >>> letting > =20 > =20 > >> the IP stack request a new sustained IP address or choose a sustaine= d > =20 > =20 > >> IP address not requiring IP mobility anchoring when an application i= s > =20 > =20 > >> initiated, among the existing ones in the IP stack. > =20 > =20 > >>> =20 > =20 > =20 > >> =20 > =20 > =20 > >> Your flag is not a solution to what I captured above. It does > =20 > =20 > >> something > =20 > =20 > >> else: Instruct the IP stack to go get a new sustained IP address > =20 > =20 > >> whether there is already one or more configured on the stack or not.= > =20 > =20 > >> (**) > =20 > =20 > >> =20 > =20 > =20 > >>>> Answered in the above. > =20 > =20 > >> =20 > =20 > =20 > > =20 > =20 > =20 > > There's a discrepancy between (*) and your solution (**). > =20 > =20 > > =20 > =20 > =20 > > Are we talking about (*), (**), or something else=3F > =20 > =20 > > =20 > =20 > =20 > >>>> There is no discrepancy between them. I said =22a new flag=22, jus= t an > =20 > =20 > > additional flag not intending to get a new sustained IP address all > =20 > =20 > > the time. And it should not request a new sustained IP address whethe= r > =20 > =20 > > there is already one or more configured on the stack or not. It is > =20 > =20 > > given with the same expression in the ticket, though our draft is > =20 > =20 > > saying the meaning of a new sustained IP address, which will be revis= ed in next update. > =20 > =20 > > =20 > =20 > =20 > > The point is that when the IP stack receives a flag with sustained IP= > =20 > =20 > > address flag, it will check it has a sustained IP address, and if it > =20 > =20 > > has one or more, one that does not activate IP mobility will be > =20 > =20 > > selected. If not, the MN will be triggered to get a new IP sustained > =20 > =20 > > address not activing IP mobility. > =20 > =20 > > =20 > =20 > =20 > > =20 > =20 > =20 > > Seil Jeon > =20 > =20 > > =20 > =20 > =20 > > =20 > =20 > =20 > > =20 > =20 > =20 > > =20 > =20 > =20 > >> Alper > =20 > =20 > >> =20 > =20 > =20 > >> =20 > =20 > =20 > >> =20 > =20 > =20 > >>> -- > =20 > =20 > >>> -------------------------+-----------------------------------------= - > =20 > =20 > >>> -------------------------+- > =20 > =20 > >>> -------------------------+--- > =20 > =20 > >>> -------------------------+--- > =20 > =20 > >>> Reporter: =7C Owner: draft-ietf-dmm-ondemand- > =20 > =20 > >>> seiljeon=40av.it.pt (mailto:seiljeon=40av.it.pt) =7C mobility= =40tools.ietf.org (mailto:mobility=40tools.ietf.org) > =20 > =20 > >>> Type: defect =7C Status: new > =20 > =20 > >>> Priority: critical =7C Milestone: > =20 > =20 > >>> Component: ondemand- =7C Version: > =20 > =20 > >>> mobility =7C Keywords: on-demand mobility > =20 > =20 > >>> Severity: Submitted =7C > =20 > =20 > >>> WG Document =7C > =20 > =20 > >>> -------------------------+-----------------------------------------= - > =20 > =20 > >>> -------------------------+- > =20 > =20 > >>> -------------------------+--- > =20 > =20 > >>> -------------------------+--- > =20 > =20 > >>> =20 > =20 > =20 > >>> Ticket URL: > =20 > =20 > >>> dmm > =20 > =20 > >>> =20 > =20 > =20 > >>> =20 > =20 > =20 > >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > =20 > =20 > >>> dmm mailing list > =20 > =20 > >>> dmm=40ietf.org (mailto:dmm=40ietf.org) > =20 > =20 > >>> https://www.ietf.org/mailman/listinfo/dmm > =20 > =20 > >> =20 > =20 > =20 > >> =20 > =20 > =20 > > =20 > =20 > =20 > > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > dmm mailing list > dmm=40ietf.org (mailto:dmm=40ietf.org) > https://www.ietf.org/mailman/listinfo/dmm > =20 > =20 > =20 --5576fc49_6b68079a_117 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Seil,


A simple way would be adding com= ment to the existing ticket.

-- 
= Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 6=E6=9C=888=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D=88= 11:56=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A

<=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

Hi Chairs,

 

We want to elaborate the issue created in the tracker for clarity.= What Action should I take in =E2=80=9CModify Ticket=E2=80=9D=3F

 

- leave as new

- resolve as =E2=80=A6=

- reassign to =E2=80=A6

 =

 

Regards,

Seil

 

=46rom: Alper Yegin =5Bmailto:alper.yegin=40yegin.org=5D=
Sent: Wednesday, June 03, 2015 11:34 AM
To: Seil Je= on
Cc: dmm=40ietf.org=
Subject: Re: =5BDMM=5D =5Bdmm=5D =2349 (ondemand-mobility): fu= ll on-demand mobility support

 

OK,= so now at least I fully understand what this is.

 

My recommendation is:

- Please refine the issue definition in the tracker, s= o that people can understand this the same way,

=

- And then let's ask the WG members their o= pinion about the issue (whether it's something worth tackling or not),

- And if they agree = to the issue, then we move to the solution space discussion.

 

Alper

 

 

On J= un 3, 2015, at 1:12 PM, Seil Jeon wrote:



- A Sustained IP address that just got allocated from the currently= serving network (hence the =22mobility is not activated=22 until the MN = moves off link)=3F

> Yes. Thanks for = your elaboration.

 

=  

Regards,

Seil

 

 

=
=46rom:=  Alper Yegin =5Bmailto:alper.yegin=40yegin.o= rg=5D 
Sent: Wednesday,= June 03, 2015 7:03 AM
To: Seil Jeon
Cc= : dmm=40ietf.= org
Subject: Re: =5BDMM=5D =5Bdmm=5D =234= 9 (ondemand-mobility): full on-demand mobility support<= /p>

 =

So, th= e idea is, when this flag is set along with a Sustained IP address reques= t from the app:

- if the host stack is already configure= d with a Sustained IP address allocated from the serving network, then it= gets selected (irrespective of the presence or absence of any other Sust= ained IP address).

 <= /p>

>> No. I said =22one that does not activate IP mobil= ity=22 over the serving network, among the existing ones in the IP stack,= gets selected. If no one in the IP stack is not matched, it will make an= attempt to get a new sustained IP address from the serving network.

 

 

What exactly is =22(an IP address) that does not activ= ate IP mobility=22=3F Please elaborate.

 

Is it

- A nomadic IP address=3F

<= /div>

 

- A Sustained IP address that just got allocated from the current= ly serving network (hence the =22mobility is not activated=22 until the M= N moves off link)=3F

 

- something else=3F=

 =

Alper<= /p>

 <= /p>

 <= /p>

 <= /p>

 

On Jun 2, 2015, at 2:11 = AM, Seil Jeon wrote:




Hi Alper,

 

Regards,

Seil

 =

 

-----Original Message-----
=46rom: Alper= Yegin =5Bmailto:alper.yeg= in=40yegin.org=5D 
Sent: Monday, June 01, 2015 8= :50 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: Re: =5BDMM=5D =5Bdmm=5D =2349 = (ondemand-mobility): full on-demand mobility support

&nb= sp;

> The point is that when the IP stack receives a = flag with sustained IP

> address flag, it will check = it has a sustained IP address, and if it

> has one or= more, one that does not activate IP mobility will be

&g= t; selected. If not, the MN will be triggered to get a new IP sustained

<= span style=3D=22font-size:11.0pt;font-family:"Arial","sans= -serif"=22>> address not activing IP mobility.<= /p>

&= nbsp;

So, the idea is, when this flag is set along with = a Sustained IP address request from the app:

<= /div>

- if the ho= st stack is already configured with a Sustained IP address allocated from= the serving network, then it gets selected (irrespective of the presence= or absence of any other Sustained IP address).

 

>> No. I said =22one th= at does not activate IP mobility=22 over the serving network, among the e= xisting ones in the IP stack, gets selected. If no one in the IP stack is= not matched, it will make an attempt to get a new sustained IP address f= rom the serving network.

 <= /o:p>

- if the host stack is not already configured with a Sustained IP addres= s allocated from the serving network (irrespective of the presence or abs= ence of any Sustained IP address from any other network), then the host m= akes an attempt to configure one with the serving network.

 

>> Yes.

 

-- if the configuration = succeeds, then the newly configured IP address is selected.

 

>> Yes.

 

-- if the configuration = fails. then the call fails (=3F=3F or some other behavior -- you can defi= ne here).

 

>> You mean the configuration fails when there is no sust= ained IP address, right=3F

In my opinion= , this issue belongs to address configuration mechanism based on definiti= on of the three DMM APIs. Those jobs are/will be asked on each configurat= ion mechanism, according to discussion of the previous teleconference in = the WT you=E2=80=99re leading. At that time, if I see any something relat= ed to our proposal, we will raise our voice.

<= /div>

 

 

 

 

Alper

 

 

 =

 

 

=

 

>>> =2349: full on-demand mobility support

>>> 

>>> The three proposed flags= express a =22type=22 of source IP address an

=

>> a= pplication wants to get to the IP stack. Particularly, the sustained

>> IP address is proposed to provide on-demand IP sess= ion continuity,

>> which activates IP mobility onc= e the terminal moves across other

<= div>

>> access=

> network.

>>> While the terminal= stays at the same network where the session is

>>= initiated, regular IP routing is applied.

>>>&= nbsp;

>>> The on-demand draft does not assure p= rovide the full on-demand

>>> mobility

>> for all scenarios by merely indicating the Socket API,<= /span>

= >> IPV6=5FREQ=5FSUSTAINED=5FIP. An example scenari= o raising the aforementioned

<= p style=3D=22margin: 0px;=22>>> issue is as follow= s;

>>> 

>>> 0. The= MN is configured with one or more Nomadic IP addresses.

= >>> 

>>> 1. Once an app. requests= =22sustained IP address=22 to the IP stack, and

>>= ;> it

>> will obtain a sustained IP address thr= ough a protocol procedure

>> between  the ter= minal and network.

>>> <= /p>

&= gt;>> 2. Other app. initiated over the same access network will use= the

>>> same

=

>> sustain= ed IP address while the terminal remains connected at the same

>> access network.

>>> 

>>> 3. The terminal moves to another access network = and a new app.

>>> requests a=

= >> sustained IP address with the Socket API to the IP stack. Since = a

>> sustained IP address is already available in t= he IP stack, the

>> sustained  IP address is a= ssigned to the new app.

>>> 

>> 

>> Yes, that's what happens.

>> You are not pointing to an issue up until this point= , right=3F Because,

>> you continuing your email wi= th a =22Besides=22 gives the impression that

<= /div>

>> yo= u are pointing to an issue, but I don't see any issue captured in<= o:p>

>> the

> above text.

= >> 

>>>> There is an issue. Maybe= , we need to be synchronized how have you

>>>&g= t; thought

>> and defined the meaning of =22on-dem= and mobility=22. As far as I know,

=

>> there are tw= o meanings; one is that by imposing capability among IP=

= >> address reachability and IP session continuity, needed for an

>> application, into a source IP address, on-demand = mobility could be

>> achieved; as the other meaning,= it can be rephrased and detailed with

<= div>

>> dynamic = mobility, which should be applied in the use of sustained IP<= /o:p>

>> address. A new application needs to have non-anchored sustained= IP

>> address. This is our consistent claim. Non-= optimal routing issue has

>> been raised in DMM Re= quirement document in R=46C 7333, which should be

> c= ritically considered in the solutions.

<= div>

>> 

> 

> Sorry, I don't understand= what you meant here.

> 

>&g= t;>> You answer doesn't make us progress. Please specify where and = what

>>>> you

> have und= erstood.

> 

> 

>>> Besides, in case sustained IP address allocation is= used default,

>>> there

<= /div>

>&= gt; may be multiple sustained IP addresses including newly obtained

>> sustained IP address over the new access network in = the IP stack.

>> However, when an app. is initiate= d, the IP stack may not select the

=

>> new one in t= he context of the default source IP address selection

&g= t; mechanism =5BR=46C6724=5D=5BR=46C5014=5D.

<= /div>

>>>= ; 

>> 

=

>> OK, is = the issue following: When there are multiple sustained IP

= >> addresses, how does the IP stack pick one among them=3F (*)

>> 

>>>> As mentione= d and specified in our draft

<= /div>

>>>= ;   Type:  defect       =7C&= nbsp;    Status:  new

>>> P= riority:  critical     =7C  Milestone:

>>> Component:  ondemand-    =7C=     Version:

>>> mobility &= nbsp;           &n= bsp; =7C   Keywords:  on-demand mobility=

= >>> Severity:  Submitted    =7C<= /o:p>

>>> WG Document        =     =7C

>>> --------------------= -----+------------------------------------------

>>= ;> -------------------------+-

<= div>

>>> ---------= ----------------+---

>>> ------------------------= -+---

>>> 

>>> 

=

>= >> 

>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

>>> dmm ma= iling list

>> 

>> 

> 

=

>=  

 

=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
dm= m mailing list
=20 =20 =20 =20

--5576fc49_6b68079a_117-- From nobody Tue Jun 9 07:58:41 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074831A884D for ; Tue, 9 Jun 2015 07:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olR64KU6ItMQ for ; Tue, 9 Jun 2015 07:58:37 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A10E1A882E for ; Tue, 9 Jun 2015 07:58:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t59EwUqm014585; Tue, 9 Jun 2015 16:58:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0FCB220B8C3; Tue, 9 Jun 2015 17:01:05 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0040B20B66B; Tue, 9 Jun 2015 17:01:04 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t59EwRgZ028787; Tue, 9 Jun 2015 16:58:30 +0200 Message-ID: <5576FF13.2080000@gmail.com> Date: Tue, 09 Jun 2015 16:58:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Templin, Fred L" , Satoru Matsushima References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <2134F8430051B64F815C691A62D9831832E827AF@XCH-BLV-504.nw.nos.boeing.com> <5575C60B.8030709@gmail.com> <2134F8430051B64F815C691A62D9831832E84B2D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E84B2D@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 14:58:40 -0000 Fred, Le 08/06/2015 19:08, Templin, Fred L a écrit : [...] >>>> The common thinking at operators and advisers is still that a >>>> /64 should be given to an User Equipment. >>>> >>>> This must change: the 3GPP specs and operator deployments must >>>> give /62 to UEs, and not /64. >>> >>> Why not a /N instead of just a /62 or /64? N could be anything >>> (62, 60, 56, 48, etc.) as long as it is a proper subset of the >>> prefix space the operator has available for delegation. >> >> I agree that in general it's good to be more generic with the >> prefix length. >> >> But in this particular case we are too generic if we just say '/N'. >> The readers will assume '/64' to be a good example of N, and that >> is not so. >> >> We can't say 'non-/64' either, because it means too much. >> >> We could say N between /48 and /63 in one bit steps. But to be >> clear that /64 is forbidden. >> >> (I can imagine the pressure that may put on the operatos, but we >> may also think there are enough of these addresses and that the >> pressure is simply a misunderstanding.) > > What I was thinking was that users could pay for different classes of > service. Basic service could be a /64 (or /63 or /62). Premium > service could be a /60. Super-premium could be a /56, etc. Well it looks like a good idea. It is a bit new compared to IPv4 in cellular networks (there is no concept of premium service delivery of several IPv4 addresses per single device, and there is no StdsTrack PD for DHCPv4). Do you think cellular operators may create such new payment schemes for classes of service in IPv6? Or rather migrate the existing IPv4 payment schemes from IPv4 - a one to one mapping between concepts, modulo the address length being bigger? > Point being that the mechanism should support any prefix delegation > size that the user has contracted with the service provider for; not > just a fixed one-size-fits-all size for all users. I agree - the mechanism is there. Why the cellular operators dont respond to DHCPv6 Prefix Delegation requests from the User Equipments? Alex > > Thanks - Fred fred.l.templin@boeing.com > >> >> Alex >> >> >> >> >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>>> Alex >>>> >>>>> >>>>> Thanks - Fred fred.l.templin@boeing.com >>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Thanks - Fred fred.l.templin@boeing.com >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>>> >>>>>>>>> But yes, I agree with you. >>>>>>>>> >>>>>>>>> cheers, --satoru >>>>>>>>> >>>>>>>>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> In addition to what Behcet says. >>>>>>>>> >>>>>>>>> I read the example below. I think it is just an >>>>>>>>> example, but just to make sure. >>>>>>>>> >>>>>>>>> Please - do not allocate /64s to end users in a >>>>>>>>> cellular network. Allocate at least /62s to end >>>>>>>>> users. >>>>>>>>> >>>>>>>>> This is to allow the smartphone to perform tethering >>>>>>>>> (small network of wifi devices connecting through >>>>>>>>> the smartphone to the Internet). >>>>>>>>> >>>>>>>>> The assumption of /64 to end user is not good at >>>>>>>>> all. >>>>>>>>> >>>>>>>>> (and yes, I agree that these /62s may be aggregated >>>>>>>>> into a larger prefix and advertised upstream as a >>>>>>>>> single prefix instead of multiple host-based >>>>>>>>> routes). >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> >>>>>>>>> Alex Petrescu >>>>>>>>> >>>>>>>>> Le 26/05/2015 22:34, Behcet Sarikaya a écrit : >>>>>>>>> >>>>>>>>> Hi Satoru, >>>>>>>>> >>>>>>>>> Thanks for your reply. >>>>>>>>> >>>>>>>>> Let me continue the discussion with your text in >>>>>>>>> Section 3.2 where you mention vEPC may utilizes >>>>>>>>> Forwarding Policy Configuration Protocol (FPCP) that >>>>>>>>> defines FPCP Agent function and Client function. >>>>>>>>> >>>>>>>>> I don't understand how you could justify defining a >>>>>>>>> new forwarding policy configuration protocol to do >>>>>>>>> this Agent/Client functionality? Why not use similar >>>>>>>>> Agent/Client models that are being defined rather >>>>>>>>> than defining a new protocol? I think this point >>>>>>>>> requires much stronger justification which I could >>>>>>>>> not see in Section 3.2. >>>>>>>>> >>>>>>>>> Are you that we have to to reinvent the wheel, >>>>>>>>> rather than reusing something that is already >>>>>>>>> available? How are we going to reinvent that wheel >>>>>>>>> also remains to be seen, I think. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Behcet >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi Bechet-san, >>>>>>>>> >>>>>>>>> Thank you for your question. In step (15), I meant >>>>>>>>> that EPC-E advertises prefix including UE assigned >>>>>>>>> prefixes. >>>>>>>>> >>>>>>>>> For example, in the case of /64 prefixes assigned to >>>>>>>>> UEs from a /56 space, that /56 is advertised by EPC-E >>>>>>>>> to upstream routers. So the advertised route isn't >>>>>>>>> host routes. >>>>>>>>> >>>>>>>>> Depends on configuration policy, but one case is that >>>>>>>>> the source of that advertised /56 route might be >>>>>>>>> statically configured in EPC-E. >>>>>>>>> >>>>>>>>> Regards, --satoru >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Matsushima-san, >>>>>>>>> >>>>>>>>> I have a question on your draft: In Sec. 3.2, page >>>>>>>>> 11, you say In step (15), the EPC-E advertises routes >>>>>>>>> to upstream routers ... >>>>>>>>> >>>>>>>>> Are these routes static/host routes? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Behcet >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ dmm >>>>>>>>> mailing list dmm@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ dmm >>>>>>>>> mailing list dmm@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ dmm >>>>>>>> mailing list dmm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>> >>>>> >>>> >>> > From nobody Tue Jun 9 08:14:38 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500CE1A8879 for ; Tue, 9 Jun 2015 08:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjIvcrBhPQL8 for ; Tue, 9 Jun 2015 08:14:30 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D4A1A8898 for ; Tue, 9 Jun 2015 08:14:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t59FESb9022263 for ; Tue, 9 Jun 2015 17:14:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 65C6F20B83B for ; Tue, 9 Jun 2015 17:17:02 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5E49C20B6CC for ; Tue, 9 Jun 2015 17:17:02 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t59FEOtM001380 for ; Tue, 9 Jun 2015 17:14:27 +0200 Message-ID: <557702D0.40805@gmail.com> Date: Tue, 09 Jun 2015 17:14:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dmm@ietf.org References: <2134F8430051B64F815C691A62D9831832E84ED7@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E84ED7@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] Scaling properties of AERO X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 15:14:32 -0000 Le 08/06/2015 23:29, Templin, Fred L a écrit : > Hi, > > I finally had a chance to sit back and think about the scaling > properties of AERO, and I think it is within reason for each AERO > link to service O(10^9) Clients. Here is what I wrote in the latest > AERO draft version: > > "Scaling properties of the AERO routing system are therefore limited > by the number of BGP routes that can be carried by Relays. Assuming > O(10^6) as a maximum number of BGP routes, Deserves explanation of the O notation, and deserves expalining why you assume 10^6 (and not 10^7). Another maximum number of BGP routes can be found in the routers in the Default-Free Zone: 535593 as of January 30th, 2015. Do you want the AERO system to scale as much as the entire existing Internet? Or be part of it? > this means that at most O(10^6) Clients can be serviced by Relays > within a single BGP instance. The O explanation would include the fact that several Clients behind a Mobile Router keeps the same order of magnitude? > A means of increasing scaling would be to assign a different set of > Relays for each set of ASPs, and still have each Server peer with > each Relay but with a distinct BGP instance for each Relay set. > Another possibility would be for Servers to institute route filters > within a single BGP instance so that each set of Relays only > receives BGP updates for the ASPs they aggregate. > > Assuming up to O(10^3) sets of Relays, scaling can then accommodate > O(10^9) Clients with no additional overhead for Servers and Relays. > In this way, each set of Relays services a specific set of ASPs that > they advertise to peers outside of the AERO link, and each Server > configures ASP-specific routes that list the correct set of Relays > as next hops." > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ I still have to understand this draft. But when talking scaling of a routing system, I think it is worth characterizing it with maybe a few more parameters. The maximum number of IP hops in a shortest path between the BGP routers which exchanged a route respective to a Moving Network. The positive influence of the default routes on the reduction of route update messages. The influence of aggregating prefixes in the reduction of routes in the routing tables (centralized and well-planned addressing architecture). It is also worth making affirmative statements of the fact that BGP worked to support mobility of a network the size of an airliner over two continents, with an IP hop count of maximum 4(?) between the BGP routers on the ground which injected the respective route. This would hint at the fact that a BGP system part of AERO is scalable to support mobility. Alex > > Comments? > > Thanks - Fred fred.l.templin@boeing.com > > _______________________________________________ dmm mailing list > dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > From nobody Tue Jun 9 08:34:18 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171461A888B for ; Tue, 9 Jun 2015 08:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woxLB_VTfi4u for ; Tue, 9 Jun 2015 08:34:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 813A81A886E for ; Tue, 9 Jun 2015 08:34:15 -0700 (PDT) Received: from localhost ([::1]:37666 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2LXa-0007mF-0f; Tue, 09 Jun 2015 08:34:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dmm issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dmm-ondemand-mobility@tools.ietf.org, seiljeon@av.it.pt X-Trac-Project: dmm Date: Tue, 09 Jun 2015 15:34:13 -0000 X-URL: http://tools.ietf.org/dmm/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dmm/trac/ticket/49#comment:1 Message-ID: <070.17080360fd066de6cfdc51a04666ceaa@tools.ietf.org> References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dmm-ondemand-mobility@tools.ietf.org, seiljeon@av.it.pt, dmm@ietf.org X-SA-Exim-Mail-From: trac+dmm@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20150609153415.813A81A886E@ietfa.amsl.com> Resent-Date: Tue, 9 Jun 2015 08:34:15 -0700 (PDT) Resent-From: trac+dmm@tools.ietf.org Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): observation of on-demand mobility (was: full on-demand mobility support) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 15:34:17 -0000 #49: observation of on-demand mobility Changes (by seiljeon@av.it.pt): * cc: seiljeon@av.it.pt (added) Comment: The on-demand draft proposed three source IP address types, enabling applications to configure the required type in the IP stack, according to IP mobility requirements. Particularly, the sustained IP address is proposed to provide on-demand IP mobility, which aims at activating IP mobility support operation upon an MN's movement. Delivering the defined flag, IPV6_REQ_SUSTAINED_IP, from an application to the IP stack through the socket API does not ensure the observation of on- demand mobility principle where IP mobility is provided upon an MN’s movement, because an initiated application may be served with IP mobility even though the MN has not moved from the current serving network where the IP prefix/address was assigned for the application. As a result, IP mobility is activated before needed. An example scenario raising the aforementioned issue is as follows; 1. The MN is configured with one or more Nomadic IP addresses. 2. Once an application requests “sustained IP address†to the IP stack, it will obtain a sustained IP address through a protocol procedure between the MN and network. 3. Other application initiated over the same serving network will use the same sustained IP address while the MN remains connected at the same serving network. 4. The MN moves to another access network, and the previous (mobile) sessions are working. A new application requests a sustained IP address. The existing sustained IP address is assigned to the new application as a sustained IP address is already available in the IP stack. 5. As a consequence, the new session is served by a remote IP mobility anchor with necessary management functions, though the MN has not moved yet. Moreover, we can suppose an example over a different address assignment strategy, where each network assigns sustained IP addresses, i.e. sustained IP address assignment by default, enables an MN to have multiple sustained IP addresses. When a new application is initiated and needs a sustained IP address, the IP stack may or not select the locally assigned one in the context of the default source IP address selection mechanism [RFC6724][RFC5014], as the application has no means to explicitly request such a demand to the IP stack. For providing the full on-demand mobility when using sustained IP address, a new address preference flag will be needed, letting the IP stack select a sustained IP address assigned from the current serving network. If not available, it should request a sustained IP address from the serving network. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dmm-ondemand- seiljeon@av.it.pt | mobility@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: ondemand- | Version: mobility | Resolution: Severity: Submitted | WG Document | Keywords: on-demand | mobility | -------------------------+------------------------------------------------- Ticket URL: dmm From nobody Tue Jun 9 08:39:16 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BCE1A88D9 for ; Tue, 9 Jun 2015 08:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw1vMuCbNSyi for ; Tue, 9 Jun 2015 08:39:12 -0700 (PDT) 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 79E071A88D1 for ; Tue, 9 Jun 2015 08:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13159; q=dns/txt; s=iport; t=1433864352; x=1435073952; h=from:to:subject:date:message-id:mime-version; bh=YLRAZuqSQDgv/HF/3RW828kTADgcI68MvOkgh6uwNf8=; b=aXhLKNvWmtsPMNhfGLPNf6W/iVFz7TVcMx92f8MZ5hZAoIrqHpmff1Cp +F9duUre395j/uiciCJEFKxJKr27YDskXgROXzULgiqEvMflmXJzKU6+D kSlaSTI2Oa3eHD7Z8lQTRVZj94unP7zm8UJ57fIjNr+I5wHERjXsKopq7 w=; X-Files: WebEx_Meeting.ics : 4152 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DuAQDCB3dV/5NdJa1CFwOCRUsBU14GvgmBVARpEYV3gUhMAQEBAQEBgQALhCcCZiEEARwYBAwMGRckAwQhiCANOpw+lQ6eegEBAQEBAQEDAQEBAQEBAQEBGQSOKoFXKQoBDBwHhBUFkz6CGIFJYWGDcYIcgTAUg2eKUoQTg1skYoEoHIEDT28BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,581,1427760000"; d="ics'?scan'208,217";a="157656551" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 09 Jun 2015 15:39:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t59Fd7IW013789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Jun 2015 15:39:07 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.121]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 9 Jun 2015 10:39:07 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: DMM WT#4 Conf Call Thread-Index: AQHQospsGhTQyWG3tEOCMXkgUuWIiA== Date: Tue, 9 Jun 2015 15:39:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.24.78.150] Content-Type: multipart/mixed; boundary="_004_D19C545A1B5F55sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: [DMM] DMM WT#4 Conf Call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 15:39:14 -0000 --_004_D19C545A1B5F55sgundaveciscocom_ Content-Type: multipart/alternative; boundary="_000_D19C545A1B5F55sgundaveciscocom_" --_000_D19C545A1B5F55sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Poll is now closed for the first meeting. Date: Tuesday, June 16th at 7AM PDT Agenda: 1. Fu Qiao will present on "Virtual CPE Support in DMM Architectures" 2. Anthony Chen will talk about "Functions of Anchor" 3. I will provide an update on the Deployment Models/Architectural Consi= derations 4. Discussion on the DMM Function Selection based on Service Attributes DMM WT#4 Updates Tuesday, June 16, 2015 7:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 2 hrs Join WebEx meeting Meeting number: 205 745 742 Meeting password: dmm Join by phone +1-408-525-6800 Call-in toll number (US/Canada) +1-866-432-9903 Call-in toll-free number (US/Canada) Access code: 205 745 742 Global call-in numbers | Toll-free calling restric= tions Add this meeting to your calendar. Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. You should inform all meeting attendees prior to re= cording if you intend to record the meeting. --_000_D19C545A1B5F55sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5B78CF9BE0E3784CBFFF5BD3A3A282F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Poll is now closed for the first meeting.

Date: Tuesday, June 16th at 7AM PDT

Agenda:
  1. Fu Qiao will present on "Virtual CPE Support in DMM Architectures&= quot; 
  2. Anthony Chen will talk about "Functions of Anchor&= quot;
  3. I will provide an update on the Deployment Models/Architectur= al Considerations
  4. Discussion on the DMM Function Selection based on= Service Attributes


DMM WT#4 Updates
Tuesday, June 16, 2015
7:00 am  |  Pacific Daylight Time (San Francisco, G= MT-07:00)  |  2 hrs
 
Join WebEx meeting
Meeting number: 205 745 742
Meeting password: dmm
 
Join by phone
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 205 745 742
Global call-in numbers  | = ; Toll-free calling restrictions
 
Add this meeting to your calendar.
 
Can't join= the meeting? Contact support.
 
IMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during the = session to be recorded, which may be discoverable in a legal matter. You sh= ould inform all meeting attendees prior to recording if you intend to record the meeting.
--_000_D19C545A1B5F55sgundaveciscocom_-- --_004_D19C545A1B5F55sgundaveciscocom_ Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=4152; creation-date="Tue, 09 Jun 2015 15:39:07 GMT"; modification-date="Tue, 09 Jun 2015 15:39:07 GMT" Content-ID: <87DB5B7666A65143BEDF46E842F4E31E@emea.cisco.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpQYWNpZmljIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA3MDAKVFpPRkZTRVRUTzotMDgwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDgw MApUWk9GRlNFVFRPOi0wNzAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJTcmkgR3VuZGF2ZWxs aSI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTpNQUlMVE86c2d1bmRhdmVAY2lzY28u Y29tCk9SR0FOSVpFUjtDTj0id2ViZXgiOk1BSUxUTzptZXNzZW5nZXJAd2ViZXguY29tCkRUU1RB UlQ7VFpJRD0iUGFjaWZpYyBUaW1lIjoyMDE1MDYxNlQwNzAwMDAKRFRFTkQ7VFpJRD0iUGFjaWZp YyBUaW1lIjoyMDE1MDYxNlQwOTAwMDAKTE9DQVRJT046aHR0cHM6Ly9jaXNjby53ZWJleC5jb20v Y2lzY29zYWxlcwpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjE0MzM4NjM2OTgKVUlEOjFmNDYzYjE3 LWE5ZjYtNGQ2YS04NDZlLWRlOTVjMGVmZDAxNApEVFNUQU1QOjIwMTUwNjE2VDE0MDAwMFoKREVT Q1JJUFRJT046XG5Ib3N0IGtleTogMjQ3ODMzXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRw czovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bTJlZjM2ZjJkOTk0M2Vi Y2UzYThkZTgxZWNiMDBhOGJhXG5NZWV0aW5nIG51bWJlcjogMjA1IDc0NSA3NDJcbk1lZXRpbmcg cGFzc3dvcmQ6IGRtbVxuXG5cbkpPSU4gQlkgUEhPTkVcbisxLTQwOC01MjUtNjgwMCBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG4rMS04NjYtNDMyLTk5MDMgQ2FsbC1pbiB0b2xsLWZy ZWUgbnVtYmVyIChVUy9DYW5hZGEpXG5BY2Nlc3MgY29kZTogMjA1IDc0NSA3NDJcblxuR2xvYmFs IGNhbGwtaW4gbnVtYmVyczpcbmh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvZ2xv YmFsY2FsbGluLnBocD9zZXJ2aWNlVHlwZT1NQyZFRD0zMTU5ODIyNDImdG9sbEZyZWU9MVxuXG5U b2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxuaHR0cDovL3d3dy53ZWJleC5jb20vcGRm L3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/ IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxl cy9tY1xuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBz ZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhl IHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBs ZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5mb3JtIGFsbCBtZWV0aW5nIGF0dGVuZGVlcyBwcmlv ciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byByZWNvcmQgdGhlIG1lZXRpbmcuXG4KWC1B TFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPjxG T05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJBcmlhbCI+ICZuYnNwOzxCUj5Ib3N0 IGtleTogMjQ3ODMzPC9GT05UPiZuYnNwOzxCUj4mbmJzcDs8QlI+Jm5ic3A7PEJSPiA8Rk9OVCBT SVpFPSI0IiBGQUNFPSJBUklBTCI+CQk8YQkJCQkJaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5j b20vY2lzY29zYWxlcy9qLnBocD9NVElEPW0yZWYzNmYyZDk5NDNlYmNlM2E4ZGU4MWVjYjAwYThi YSI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4 IG1lZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9G T05UPgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPjIwNSA3NDUgNzQyPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8 L3RhYmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+ZG1tPC9GT05UPjwvdGQ+PC90cj48L3Rh YmxlPgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7 PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+ PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPisxLTQw OC01MjUtNjgwMDwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8 L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPjxzdHJvbmc+KzEtODY2LTQzMi05OTAzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsLWZy ZWUgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogMjA1IDc0NSA3NDI8L0ZPTlQ+ Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2ds b2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9TUMmRUQ9MzE1OTgyMjQyJnRvbGxGcmVlPTEiPjxG T05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+R2xvYmFsIGNhbGwtaW4g bnVtYmVyczwvRk9OVD48L2E+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDs8L0ZPTlQ+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3Rv bGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBG QUNFPSJhcmlhbCI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5i c3A7IDxCUj48L0ZPTlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4J PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9tYyI+CTxGT05UIFNJ WkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Q29udGFjdCBzdXBwb3J0LjwvRk9O VD48L2E+CSZuYnNwOzxCUj4mbmJzcDs8QlI+PEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEi IEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2Vi RXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5n IHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGlu IGEgbGVnYWwgbWF0dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMg cHJpb3IgdG8gcmVjb3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLjwv Rk9OVD48L0ZPTlQ+ClNVTU1BUlk6RE1NIFdUIzQgVXBkYXRlcwpQUklPUklUWTo1CkNMQVNTOlBV QkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQxNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJ T046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK --_004_D19C545A1B5F55sgundaveciscocom_-- From nobody Tue Jun 9 08:39:27 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C9A1A8907 for ; Tue, 9 Jun 2015 08:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbuuAK2QJ0EM for ; Tue, 9 Jun 2015 08:39:20 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 726621A8908 for ; Tue, 9 Jun 2015 08:39:18 -0700 (PDT) Received: from [193.136.93.95] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77803634; Tue, 09 Jun 2015 16:39:17 +0100 From: "Seil Jeon" To: "Alper Yegin" References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <070.17080360fd066de6cfdc51a04666ceaa@tools.ietf.org> In-Reply-To: <070.17080360fd066de6cfdc51a04666ceaa@tools.ietf.org> Date: Tue, 9 Jun 2015 16:39:16 +0100 Message-ID: <001301d0a2ca$71dee170$559ca450$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXyJVonWC/jWHjoPLHEPQMMWOBzAIqZUu9nQSv1WA= Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: [DMM] FW: [dmm] #49 (ondemand-mobility): observation of on-demand mobility (was: full on-demand mobility support) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 15:39:26 -0000 Hi Alper and DMM folks, We have tried to refine the issue in the on-demand WG draft as = forwarded. I hope the issue has been clearly defined through the = elaborated texts. I'd like to get opinions on it. Regards, Seil -----Original Message----- From: dmm issue tracker [mailto:trac+dmm@tools.ietf.org]=20 Sent: Tuesday, June 09, 2015 4:34 PM To: draft-ietf-dmm-ondemand-mobility@tools.ietf.org; seiljeon@av.it.pt Cc: dmm@ietf.org Subject: Re: [dmm] #49 (ondemand-mobility): observation of on-demand = mobility (was: full on-demand mobility support) #49: observation of on-demand mobility Changes (by seiljeon@av.it.pt): * cc: seiljeon@av.it.pt (added) Comment: The on-demand draft proposed three source IP address types, enabling = applications to configure the required type in the IP stack, according = to IP mobility requirements. Particularly, the sustained IP address is = proposed to provide on-demand IP mobility, which aims at activating IP = mobility support operation upon an MN's movement. Delivering the defined flag, IPV6_REQ_SUSTAINED_IP, from an application = to the IP stack through the socket API does not ensure the observation = of on- demand mobility principle where IP mobility is provided upon an = MN=E2=80=99s movement, because an initiated application may be served = with IP mobility even though the MN has not moved from the current = serving network where the IP prefix/address was assigned for the = application. As a result, IP mobility is activated before needed. An example scenario raising the aforementioned issue is as follows; 1. The MN is configured with one or more Nomadic IP addresses. 2. Once an application requests =E2=80=9Csustained IP address=E2=80=9D = to the IP stack, it will obtain a sustained IP address through a = protocol procedure between the MN and network. 3. Other application initiated over the same serving network will use = the same sustained IP address while the MN remains connected at the = same serving network. 4. The MN moves to another access network, and the previous (mobile) = sessions are working. A new application requests a sustained IP address. The existing sustained IP address is assigned to the new application as = a sustained IP address is already available in the IP stack. 5. As a consequence, the new session is served by a remote IP mobility = anchor with necessary management functions, though the MN has not moved = yet. Moreover, we can suppose an example over a different address assignment = strategy, where each network assigns sustained IP addresses, i.e. sustained IP address assignment by default, enables an MN to have = multiple sustained IP addresses. When a new application is initiated = and needs a sustained IP address, the IP stack may or not select the = locally assigned one in the context of the default source IP address = selection mechanism [RFC6724][RFC5014], as the application has no means = to explicitly request such a demand to the IP stack. For providing the full on-demand mobility when using sustained IP = address, a new address preference flag will be needed, letting the IP = stack select a sustained IP address assigned from the current serving = network. If not available, it should request a sustained IP address = from the serving network. --=20 -------------------------+---------------------------------------------- -------------------------+--- Reporter: | Owner: draft-ietf-dmm-ondemand- seiljeon@av.it.pt | mobility@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: ondemand- | Version: mobility | Resolution: Severity: Submitted | WG Document | Keywords: on-demand | mobility | -------------------------+---------------------------------------------- -------------------------+--- Ticket URL: dmm From nobody Tue Jun 9 08:54:47 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2FA1A897D for ; Tue, 9 Jun 2015 08:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1BpgKc2ZeWS for ; Tue, 9 Jun 2015 08:54:42 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBD51A8991 for ; Tue, 9 Jun 2015 08:54:34 -0700 (PDT) Received: from [193.136.93.95] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77803705; Tue, 09 Jun 2015 16:54:33 +0100 From: "Seil Jeon" To: "'Dapeng Liu'" References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> <005d01d09de5$dadd6b40$909841c0$@av.it.pt> <3620CF9B-EF59-4DF0-993F-4442D91604DC@yegin.org> <000301d0a203$b8ccde60$2a669b20$@av.it.pt> In-Reply-To: Date: Tue, 9 Jun 2015 16:54:33 +0100 Message-ID: <000001d0a2cc$93f94780$bbebd680$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D0A2D4.F5C96F50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXyJVonWC/jWHjoPLHEPQMMWOBzAGkZzt5AU1BkT0C/VzGWQLvqnHwAhDpQpMCH8V98AJIAZ16Aps88YoBmwV+dQH2sBSYAvUNesACkdGbd5w9rhaQ Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaICBGVzogW2RtbV0gIzQ5IChvbmRlbWFuZC1t?= =?utf-8?q?obility=29=3A_full_on-demand_mobility_support?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 15:54:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D0A2D4.F5C96F50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Dapeng, =20 Thanks to your advice, we=E2=80=99ve tried to update the issue = description. =20 Regards, Seil Jeon =20 =20 From: Dapeng Liu [mailto:maxpassion@gmail.com]=20 Sent: Tuesday, June 09, 2015 3:44 PM To: Seil Jeon Cc: jouni.nospam@gmail.com; Dapeng Liu; dmm@ietf.org Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A [DMM] FW: [dmm] #49 = (ondemand-mobility): full on-demand mobility support =20 Hi Seil,=20 =20 You can refer to this: = http://trac.tools.ietf.org/wg/dmm/trac/wiki/TracTickets =20 A simple way would be adding comment to the existing ticket. =20 --=20 Dapeng Liu =20 =E5=9C=A8 2015=E5=B9=B46=E6=9C=888=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D=8811:56=EF=BC=8CSeil = Jeon =E5=86=99=E9=81=93=EF=BC=9A Hi Chairs, =20 We want to elaborate the issue created in the tracker for clarity. What = Action should I take in =E2=80=9CModify Ticket=E2=80=9D? =20 - leave as new - resolve as =E2=80=A6 - reassign to =E2=80=A6 =20 =20 Regards, Seil =20 From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 Sent: Wednesday, June 03, 2015 11:34 AM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand = mobility support =20 OK, so now at least I fully understand what this is. =20 My recommendation is: - Please refine the issue definition in the tracker, so that people can = understand this the same way, - And then let's ask the WG members their opinion about the issue = (whether it's something worth tackling or not), - And if they agree to the issue, then we move to the solution space = discussion. =20 Alper =20 =20 On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote: =20 - A Sustained IP address that just got allocated from the currently = serving network (hence the "mobility is not activated" until the MN = moves off link)? > Yes. Thanks for your elaboration. =20 =20 Regards, Seil =20 =20 From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 Sent: Wednesday, June 03, 2015 7:03 AM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand = mobility support =20 So, the idea is, when this flag is set along with a Sustained IP address = request from the app: - if the host stack is already configured with a Sustained IP address = allocated from the serving network, then it gets selected (irrespective = of the presence or absence of any other Sustained IP address). =20 >> No. I said "one that does not activate IP mobility" over the serving = network, among the existing ones in the IP stack, gets selected. If no = one in the IP stack is not matched, it will make an attempt to get a new = sustained IP address from the serving network. =20 =20 What exactly is "(an IP address) that does not activate IP mobility"? = Please elaborate. =20 Is it - A nomadic IP address? =20 - A Sustained IP address that just got allocated from the currently = serving network (hence the "mobility is not activated" until the MN = moves off link)? =20 - something else? =20 Alper =20 =20 =20 =20 On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote: Hi Alper, =20 Regards, Seil =20 =20 -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 Sent: Monday, June 01, 2015 8:50 PM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand = mobility support =20 > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. =20 So, the idea is, when this flag is set along with a Sustained IP address = request from the app: - if the host stack is already configured with a Sustained IP address = allocated from the serving network, then it gets selected (irrespective = of the presence or absence of any other Sustained IP address). =20 >> No. I said "one that does not activate IP mobility" over the serving = network, among the existing ones in the IP stack, gets selected. If no = one in the IP stack is not matched, it will make an attempt to get a new = sustained IP address from the serving network. =20 - if the host stack is not already configured with a Sustained IP = address allocated from the serving network (irrespective of the presence = or absence of any Sustained IP address from any other network), then the = host makes an attempt to configure one with the serving network. =20 >> Yes. =20 -- if the configuration succeeds, then the newly configured IP address = is selected. =20 >> Yes. =20 -- if the configuration fails. then the call fails (?? or some other = behavior -- you can define here). =20 >> You mean the configuration fails when there is no sustained IP = address, right? In my opinion, this issue belongs to address configuration mechanism = based on definition of the three DMM APIs. Those jobs are/will be asked = on each configuration mechanism, according to discussion of the previous = teleconference in the WT you=E2=80=99re leading. At that time, if I see = any something related to our proposal, we will raise our voice. =20 =20 =20 =20 Alper =20 =20 =20 =20 =20 =20 >>> #49: full on-demand mobility support >>>=20 >>> The three proposed flags express a "type" of source IP address an >> application wants to get to the IP stack. Particularly, the sustained >> IP address is proposed to provide on-demand IP session continuity, >> which activates IP mobility once the terminal moves across other >> access > network. >>> While the terminal stays at the same network where the session is >> initiated, regular IP routing is applied. >>>=20 >>> The on-demand draft does not assure provide the full on-demand >>> mobility >> for all scenarios by merely indicating the Socket API, >> IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned >> issue is as follows; >>>=20 >>> 0. The MN is configured with one or more Nomadic IP addresses. >>>=20 >>> 1. Once an app. requests "sustained IP address" to the IP stack, and >>> it >> will obtain a sustained IP address through a protocol procedure >> between the terminal and network. >>>=20 >>> 2. Other app. initiated over the same access network will use the >>> same >> sustained IP address while the terminal remains connected at the same >> access network. >>>=20 >>> 3. The terminal moves to another access network and a new app. >>> requests a >> sustained IP address with the Socket API to the IP stack. Since a >> sustained IP address is already available in the IP stack, the >> sustained IP address is assigned to the new app. >>>=20 >>=20 >> Yes, that's what happens. >> You are not pointing to an issue up until this point, right? Because, >> you continuing your email with a "Besides" gives the impression that >> you are pointing to an issue, but I don't see any issue captured in >> the > above text. >>=20 >>>> There is an issue. Maybe, we need to be synchronized how have you >>>> thought >> and defined the meaning of "on-demand mobility". As far as I know, >> there are two meanings; one is that by imposing capability among IP >> address reachability and IP session continuity, needed for an >> application, into a source IP address, on-demand mobility could be >> achieved; as the other meaning, it can be rephrased and detailed with >> dynamic mobility, which should be applied in the use of sustained IP >> address. A new application needs to have non-anchored sustained IP >> address. This is our consistent claim. Non-optimal routing issue has >> been raised in DMM Requirement document in RFC 7333, which should be > critically considered in the solutions. >>=20 >=20 > Sorry, I don't understand what you meant here. >=20 >>>> You answer doesn't make us progress. Please specify where and what >>>> you > have understood. >=20 >=20 >>> Besides, in case sustained IP address allocation is used default, >>> there >> may be multiple sustained IP addresses including newly obtained >> sustained IP address over the new access network in the IP stack. >> However, when an app. is initiated, the IP stack may not select the >> new one in the context of the default source IP address selection > mechanism [RFC6724][RFC5014]. >>>=20 >>=20 >> OK, is the issue following: When there are multiple sustained IP >> addresses, how does the IP stack pick one among them? (*) >>=20 >>>> As mentioned and specified in our draft >> = = http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, >> if there is no additional preference, we can leave selection to the >> default source address selection mechanism. BUT if we have specific >> preference among multiple sustained IP addresses and an initiated >> application wants to have non-anchored sustained IP address over >> currently attached access network, the proposed flag is essential. >>=20 >=20 > I think you are meaning the same thing as I said above (*). > Do you agree? >=20 >>>> Yes. >=20 >>> For providing the full on-demand mobility, a new flag is needed, >>> letting >> the IP stack request a new sustained IP address or choose a sustained >> IP address not requiring IP mobility anchoring when an application is >> initiated, among the existing ones in the IP stack. >>>=20 >>=20 >> Your flag is not a solution to what I captured above. It does >> something >> else: Instruct the IP stack to go get a new sustained IP address >> whether there is already one or more configured on the stack or not. >> (**) >>=20 >>>> Answered in the above. >>=20 >=20 > There's a discrepancy between (*) and your solution (**). >=20 > Are we talking about (*), (**), or something else? >=20 >>>> There is no discrepancy between them. I said "a new flag", just an > additional flag not intending to get a new sustained IP address all > the time. And it should not request a new sustained IP address whether > there is already one or more configured on the stack or not. It is > given with the same expression in the ticket, though our draft is > saying the meaning of a new sustained IP address, which will be = revised in next update. >=20 > The point is that when the IP stack receives a flag with sustained IP > address flag, it will check it has a sustained IP address, and if it > has one or more, one that does not activate IP mobility will be > selected. If not, the MN will be triggered to get a new IP sustained > address not activing IP mobility. >=20 >=20 > Seil Jeon >=20 >=20 >=20 >=20 >> Alper >>=20 >>=20 >>=20 >>> -- >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>> Reporter: | Owner: draft-ietf-dmm-ondemand- >>> seiljeon@av.it.pt | = mobility@tools.ietf.org >>> Type: defect | Status: new >>> Priority: critical | Milestone: >>> Component: ondemand- | Version: >>> mobility | Keywords: on-demand mobility >>> Severity: Submitted | >>> WG Document | >>> -------------------------+------------------------------------------ >>> -------------------------+- >>> -------------------------+--- >>> -------------------------+--- >>>=20 >>> Ticket URL: < = http://trac.tools.ietf.org/wg/dmm/trac/ticket/49> >>> dmm < http://tools.ietf.org/dmm/> >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> = https://www.ietf.org/mailman/listinfo/dmm >>=20 >>=20 >=20 >=20 =20 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm =20 ------=_NextPart_000_0001_01D0A2D4.F5C96F50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Dapeng,

 

Thanks to your advice, we=E2=80=99ve tried to update the issue = description.

 

Regards,

Seil Jeon

 

 

From:= = Dapeng Liu [mailto:maxpassion@gmail.com]
Sent: Tuesday, June = 09, 2015 3:44 PM
To: Seil Jeon
Cc: = jouni.nospam@gmail.com; Dapeng Liu; dmm@ietf.org
Subject: = =E5=9B=9E=E5=A4=8D=EF=BC=9A [DMM] FW: = [dmm] #49 (ondemand-mobility): full on-demand mobility = support

 

Hi = Seil,

 

<= div>

 

A simple way would be adding comment to the existing = ticket.

 

-- 

Dapeng Liu

 

=E5=9C=A8= 2015=E5=B9=B4= 6=E6=9C=88= 8=E6=97=A5= =E6=98=9F= =E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B= =E5=8D=8811:56=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A

Hi Chairs,

 

We want to elaborate the issue created in the tracker for clarity. What = Action should I take in =E2=80=9CModify = Ticket=E2=80=9D?

 

- leave as new

- resolve as =E2=80=A6

- reassign to =E2=80=A6

 

 

Regards,

Seil

 

From:= = Alper Yegin [mailto:alper.yegin@yegin.org] =
Sent: Wednesday, June 03, 2015 11:34 AM
To: Seil = Jeon
Cc: dmm@ietf.org
Subject: Re: = [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility = support

 

OK, so now at least I fully = understand what this is.

 

My recommendation = is:

- Please refine the issue = definition in the tracker, so that people can understand this the same = way,

- And then let's ask the WG = members their opinion about the issue (whether it's something worth = tackling or not),

- And if they agree to the = issue, then we move to the solution space = discussion.

 

Alper

 

 

On Jun 3, 2015, at 1:12 = PM, Seil Jeon wrote:

 

- A Sustained IP address that = just got allocated from the currently serving network (hence the = "mobility is not activated" until the MN moves off = link)?

> Yes. Thanks for your = elaboration.

 

 

R= egards,

S= eil

 

 

From:=  Alper = Yegin [mailto:alper.yegin@yegin.org]&n= bsp;
Sent: Wednesday, June 03, 2015 7:03 = AM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re:= [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility = support

 

So, the idea = is, when this flag is set along with a Sustained IP address request from = the app:

- if the = host stack is already configured with a Sustained IP address allocated = from the serving network, then it gets selected (irrespective of the = presence or absence of any other Sustained IP = address).

&= nbsp;

>> No. I said "one that does not activate IP mobility" = over the serving network, among the existing ones in the IP stack, gets = selected. If no one in the IP stack is not matched, it will make an = attempt to get a new sustained IP address from the serving = network.

<= div>

 

 

What exactly = is "(an IP address) that does not activate IP mobility"? = Please elaborate.

 

Is = it

- A nomadic IP = address?

 

- A Sustained IP address that = just got allocated from the currently serving network (hence the = "mobility is not activated" until the MN moves off = link)?

 

- something = else?

 

Alper

 

 

 

 

On Jun 2, = 2015, at 2:11 AM, Seil Jeon wrote:



Hi = Alper,

 =

Regards,

Seil

 =

 =

-----Original= Message-----
From: Alper Yegin [mailto:alper.yegin@yegin.org]&n= bsp;
Sent: Monday, June 01, 2015 8:50 PM
To: Seil = Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] = [dmm] #49 (ondemand-mobility): full on-demand mobility = support

 =

> The = point is that when the IP stack receives a flag with sustained = IP

> address = flag, it will check it has a sustained IP address, and if = it

> has one = or more, one that does not activate IP mobility will = be

> = selected. If not, the MN will be triggered to get a new IP = sustained

> address = not activing IP mobility.

 =

So, the idea = is, when this flag is set along with a Sustained IP address request from = the app:

- if the = host stack is already configured with a Sustained IP address allocated = from the serving network, then it gets selected (irrespective of the = presence or absence of any other Sustained IP = address).

&= nbsp;

>> No. I said "one that does not activate IP mobility" = over the serving network, among the existing ones in the IP stack, gets = selected. If no one in the IP stack is not matched, it will make an = attempt to get a new sustained IP address from the serving = network.

&= nbsp;

- if the = host stack is not already configured with a Sustained IP address = allocated from the serving network (irrespective of the presence or = absence of any Sustained IP address from any other network), then the = host makes an attempt to configure one with the serving = network.

&= nbsp;

>> Yes.

&= nbsp;

-- if the = configuration succeeds, then the newly configured IP address is = selected.

&= nbsp;

>> Yes.

&= nbsp;

-- if the = configuration fails. then the call fails (?? or some other behavior -- = you can define here).

 

>> You mean the configuration fails when there is no sustained IP = address, right?

In my opinion, this issue belongs to address configuration mechanism = based on definition of the three DMM APIs. Those jobs are/will be asked = on each configuration mechanism, according to discussion of the previous = teleconference in the WT you=E2=80=99re leading. At that time, if I see = any something related to our proposal, we will raise our = voice.

 

&= nbsp;

&= nbsp;

&= nbsp;

Alper<= o:p>

 =

 =

 =

 =

 =

 =

>>> = #49: full on-demand mobility = support

>>>&= nbsp;

>>> = The three proposed flags express a "type" of source IP address = an

>> = application wants to get to the IP stack. Particularly, the = sustained

>> IP = address is proposed to provide on-demand IP session = continuity,

>> = which activates IP mobility once the terminal moves across = other

>> = access

> = network.

>>> = While the terminal stays at the same network where the session = is

>> = initiated, regular IP routing is = applied.

>>>&= nbsp;

>>> = The on-demand draft does not assure provide the full = on-demand

>>> = mobility

>> for = all scenarios by merely indicating the Socket = API,

>> = IPV6_REQ_SUSTAINED_IP. An example scenario raising the = aforementioned

>> = issue is as follows;

>>>&= nbsp;

>>> = 0. The MN is configured with one or more Nomadic IP = addresses.

>>>&= nbsp;

>>> = 1. Once an app. requests "sustained IP address" to the IP = stack, and

>>> = it

>> = will obtain a sustained IP address through a protocol = procedure

>> = between  the terminal and = network.

>>>&= nbsp;

>>> = 2. Other app. initiated over the same access network will use = the

>>> = same

>> = sustained IP address while the terminal remains connected at the = same

>> = access network.

>>>&= nbsp;

>>> = 3. The terminal moves to another access network and a new = app.

>>> = requests a

>> = sustained IP address with the Socket API to the IP stack. Since = a

>> = sustained IP address is already available in the IP stack, = the

>> = sustained  IP address is assigned to the new = app.

>>>&= nbsp;

>> = ;

>> = Yes, that's what happens.

>> You = are not pointing to an issue up until this point, right? = Because,

>> you = continuing your email with a "Besides" gives the impression = that

>> you = are pointing to an issue, but I don't see any issue captured = in

>> = the

> above = text.

>> = ;

>>>&= gt; There is an issue. Maybe, we need to be synchronized how have = you

>>>&= gt; thought

>> and = defined the meaning of "on-demand mobility". As far as I = know,

>> = there are two meanings; one is that by imposing capability among = IP

>> = address reachability and IP session continuity, needed for = an

>> = application, into a source IP address, on-demand mobility could = be

>> = achieved; as the other meaning, it can be rephrased and detailed = with

>> = dynamic mobility, which should be applied in the use of sustained = IP

>> = address. A new application needs to have non-anchored sustained = IP

>> = address. This is our consistent claim. Non-optimal routing issue = has

>> = been raised in DMM Requirement document in RFC 7333, which should = be

> = critically considered in the = solutions.

>> = ;

> 

> Sorry, = I don't understand what you meant = here.

> 

>>>&= gt; You answer doesn't make us progress. Please specify where and = what

>>>&= gt; you

> have = understood.

> 

> 

>>> = Besides, in case sustained IP address allocation is used = default,

>>> = there

>> may = be multiple sustained IP addresses including newly = obtained

>> = sustained IP address over the new access network in the IP = stack.

>> = However, when an app. is initiated, the IP stack may not select = the

>> new = one in the context of the default source IP address = selection

> = mechanism = [RFC6724][RFC5014].

>>>&= nbsp;

>> = ;

>> OK, = is the issue following: When there are multiple sustained = IP

>> = addresses, how does the IP stack pick one among them? = (*)

>> = ;

>>>&= gt; As mentioned and specified in our = draft

>> if = there is no additional preference, we can leave selection to = the

>> = default source address selection mechanism. BUT if we have = specific

>> = preference among multiple sustained IP addresses and an = initiated

>> = application wants to have non-anchored sustained IP address = over

>> = currently attached access network, the proposed flag is = essential.

>> = ;

> 

> I think = you are meaning the same thing as I said above = (*).

> Do you = agree?

> 

>>>&= gt; Yes.

> 

>>> = For providing the full on-demand mobility, a new flag is = needed,

>>> = letting

>> the = IP stack request a new sustained IP address or choose a = sustained

>> IP = address not requiring IP mobility anchoring when an application = is

>> = initiated, among the existing ones in the IP = stack.

>>>&= nbsp;

>> = ;

>> = Your flag is not a solution to what I captured above. It = does

>> = something

>> = else: Instruct the IP stack to go get a new sustained IP = address

>> = whether there is already one or more configured on the stack or = not.

>> = (**)

>> = ;

>>>&= gt; Answered in the above.

>> = ;

> 

> There's = a discrepancy between (*) and your solution = (**).

> 

> Are we = talking about (*), (**), or something = else?

> 

>>>&= gt; There is no discrepancy between them. I said "a new flag", = just an

> = additional flag not intending to get a new sustained IP address = all

> the = time. And it should not request a new sustained IP address = whether

> there = is already one or more configured on the stack or not. It = is

> given = with the same expression in the ticket, though our draft = is

> saying = the meaning of a new sustained IP address, which will be revised in next = update.

> 

> The = point is that when the IP stack receives a flag with sustained = IP

> address = flag, it will check it has a sustained IP address, and if = it

> has one = or more, one that does not activate IP mobility will = be

> = selected. If not, the MN will be triggered to get a new IP = sustained

> address = not activing IP mobility.

> 

> 

> Seil = Jeon

> 

> 

> 

> 

>> = Alper

>> = ;

>> = ;

>> = ;

>>> = --

>>> = -------------------------+------------------------------------------

>>> = -------------------------+-

>>> = -------------------------+---

=

>>> = -------------------------+---

=

>>> = Reporter:          &nbs= p;    |      Owner:  = draft-ietf-dmm-ondemand-

>>>&= nbsp;  Type:  defect       = |     Status:  = new

>>> = Priority:  critical     |  = Milestone:

>>> = Component:  ondemand-    |    = Version:

>>> = mobility           = ;    |   Keywords:  on-demand = mobility

>>> = Severity:  Submitted    = |

>>> = WG = Document           = ; |

>>> = -------------------------+------------------------------------------

>>> = -------------------------+-

>>> = -------------------------+---

=

>>> = -------------------------+---

=

>>>&= nbsp;

<= div>

>>>&= nbsp;

>>>&= nbsp;

>>> = _______________________________________________

>>> = dmm mailing list

>>>&= nbsp;dmm@ietf.org

>> = ;

>> = ;

> 

> 

 

_______________________________________________

dmm mailing = list

 

------=_NextPart_000_0001_01D0A2D4.F5C96F50-- From nobody Tue Jun 9 09:26:10 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0701AC41F for ; Tue, 9 Jun 2015 09:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVWahscXMokS for ; Tue, 9 Jun 2015 09:26:07 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBDE1AC3EC for ; Tue, 9 Jun 2015 09:26:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t59GQ78H024942; Tue, 9 Jun 2015 09:26:07 -0700 Received: from XCH-BLV-105.nw.nos.boeing.com (xch-blv-105.nw.nos.boeing.com [130.247.25.121]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t59GQ2sM024772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 9 Jun 2015 09:26:02 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.243]) with mapi id 14.03.0235.001; Tue, 9 Jun 2015 09:26:01 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Satoru Matsushima Thread-Topic: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Thread-Index: AQHQmjkkJI//M3dql0O3DI0sVGxml52TQ0XQgAgjhoCAAFQrEIABJdgA//+aLYCABto8gP//kHkwgAHksYD//6DIcA== Date: Tue, 9 Jun 2015 16:26:00 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E85664@XCH-BLV-504.nw.nos.boeing.com> References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <2134F8430051B64F815C691A62D9831832E827AF@XCH-BLV-504.nw.nos.boeing.com> <5575C60B.8030709@gmail.com> <2134F8430051B64F815C691A62D9831832E84B2D@XCH-BLV-504.nw.nos.boeing.com> <5576FF13.2080000@gmail.com> In-Reply-To: <5576FF13.2080000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:26:10 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cnUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBUdWVzZGF5LCBKdW5lIDA5LCAyMDE1IDc6NTggQU0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTDsg U2F0b3J1IE1hdHN1c2hpbWENCj4gQ2M6IGRtbQ0KPiBTdWJqZWN0OiBSZTogW0RNTV0gdmVwYyBk cmFmdCBSZXYuIDA0IC0gLzYycyB0byBVRSwgbm90IC82NHMNCj4gDQo+IEZyZWQsDQo+IA0KPiBM ZSAwOC8wNi8yMDE1IDE5OjA4LCBUZW1wbGluLCBGcmVkIEwgYSDDqWNyaXQgOg0KPiBbLi4uXQ0K PiANCj4gPj4+PiBUaGUgY29tbW9uIHRoaW5raW5nIGF0IG9wZXJhdG9ycyBhbmQgYWR2aXNlcnMg aXMgc3RpbGwgdGhhdCBhDQo+ID4+Pj4gLzY0IHNob3VsZCBiZSBnaXZlbiB0byBhbiBVc2VyIEVx dWlwbWVudC4NCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgbXVzdCBjaGFuZ2U6IHRoZSAzR1BQIHNwZWNz IGFuZCBvcGVyYXRvciBkZXBsb3ltZW50cyBtdXN0DQo+ID4+Pj4gZ2l2ZSAvNjIgdG8gVUVzLCBh bmQgbm90IC82NC4NCj4gPj4+DQo+ID4+PiBXaHkgbm90IGEgL04gaW5zdGVhZCBvZiBqdXN0IGEg LzYyIG9yIC82ND8gTiBjb3VsZCBiZSBhbnl0aGluZw0KPiA+Pj4gKDYyLCA2MCwgNTYsIDQ4LCBl dGMuKSBhcyBsb25nIGFzIGl0IGlzIGEgcHJvcGVyIHN1YnNldCBvZiB0aGUNCj4gPj4+IHByZWZp eCBzcGFjZSB0aGUgb3BlcmF0b3IgaGFzIGF2YWlsYWJsZSBmb3IgZGVsZWdhdGlvbi4NCj4gPj4N Cj4gPj4gSSBhZ3JlZSB0aGF0IGluIGdlbmVyYWwgaXQncyBnb29kIHRvIGJlIG1vcmUgZ2VuZXJp YyB3aXRoIHRoZQ0KPiA+PiBwcmVmaXggbGVuZ3RoLg0KPiA+Pg0KPiA+PiBCdXQgaW4gdGhpcyBw YXJ0aWN1bGFyIGNhc2Ugd2UgYXJlIHRvbyBnZW5lcmljIGlmIHdlIGp1c3Qgc2F5ICcvTicuDQo+ ID4+IFRoZSByZWFkZXJzIHdpbGwgYXNzdW1lICcvNjQnIHRvIGJlIGEgZ29vZCBleGFtcGxlIG9m IE4sIGFuZCB0aGF0DQo+ID4+IGlzIG5vdCBzby4NCj4gPj4NCj4gPj4gV2UgY2FuJ3Qgc2F5ICdu b24tLzY0JyBlaXRoZXIsIGJlY2F1c2UgaXQgbWVhbnMgdG9vIG11Y2guDQo+ID4+DQo+ID4+IFdl IGNvdWxkIHNheSBOIGJldHdlZW4gLzQ4IGFuZCAvNjMgaW4gb25lIGJpdCBzdGVwcy4gIEJ1dCB0 byBiZQ0KPiA+PiBjbGVhciB0aGF0IC82NCBpcyBmb3JiaWRkZW4uDQo+ID4+DQo+ID4+IChJIGNh biBpbWFnaW5lIHRoZSBwcmVzc3VyZSB0aGF0IG1heSBwdXQgb24gdGhlIG9wZXJhdG9zLCBidXQg d2UNCj4gPj4gbWF5IGFsc28gdGhpbmsgdGhlcmUgYXJlIGVub3VnaCBvZiB0aGVzZSBhZGRyZXNz ZXMgYW5kIHRoYXQgdGhlDQo+ID4+IHByZXNzdXJlIGlzIHNpbXBseSBhIG1pc3VuZGVyc3RhbmRp bmcuKQ0KPiA+DQo+ID4gV2hhdCBJIHdhcyB0aGlua2luZyB3YXMgdGhhdCB1c2VycyBjb3VsZCBw YXkgZm9yIGRpZmZlcmVudCBjbGFzc2VzIG9mDQo+ID4gc2VydmljZS4gQmFzaWMgc2VydmljZSBj b3VsZCBiZSBhIC82NCAob3IgLzYzIG9yIC82MikuIFByZW1pdW0NCj4gPiBzZXJ2aWNlIGNvdWxk IGJlIGEgLzYwLiBTdXBlci1wcmVtaXVtIGNvdWxkIGJlIGEgLzU2LCBldGMuDQo+IA0KPiBXZWxs IGl0IGxvb2tzIGxpa2UgYSBnb29kIGlkZWEuICBJdCBpcyBhIGJpdCBuZXcgY29tcGFyZWQgdG8g SVB2NCBpbg0KPiBjZWxsdWxhciBuZXR3b3JrcyAodGhlcmUgaXMgbm8gY29uY2VwdCBvZiBwcmVt aXVtIHNlcnZpY2UgZGVsaXZlcnkgb2YNCj4gc2V2ZXJhbCBJUHY0IGFkZHJlc3NlcyBwZXIgc2lu Z2xlIGRldmljZSwgYW5kIHRoZXJlIGlzIG5vIFN0ZHNUcmFjayBQRA0KPiBmb3IgREhDUHY0KS4g IERvIHlvdSB0aGluayBjZWxsdWxhciBvcGVyYXRvcnMgbWF5IGNyZWF0ZSBzdWNoIG5ldw0KPiBw YXltZW50IHNjaGVtZXMgZm9yIGNsYXNzZXMgb2Ygc2VydmljZSBpbiBJUHY2PyAgT3IgcmF0aGVy IG1pZ3JhdGUgdGhlDQo+IGV4aXN0aW5nIElQdjQgcGF5bWVudCBzY2hlbWVzIGZyb20gSVB2NCAt IGEgb25lIHRvIG9uZSBtYXBwaW5nIGJldHdlZW4NCj4gY29uY2VwdHMsIG1vZHVsbyB0aGUgYWRk cmVzcyBsZW5ndGggYmVpbmcgYmlnZ2VyPw0KDQpJIGRvbid0IGtub3cgbXVjaCBhYm91dCB0aGUg Y2VsbHVsYXIgb3BlcmF0b3IgYnVzaW5lc3MuIEkgYW0gY29uZmlkZW50DQpBRVJPIHdvdWxkIGJl IGEgZ29vZCBmaXQgZm9yIHRoYXQgZW52aXJvbm1lbnQsIGJ1dCBJIGhhdmUgYmVlbiBtb3JlDQpm b2N1c2VkIG9uIGVudGVycHJpc2UgbmV0d29ya3MsIGF2aWF0aW9uIG5ldHdvcmtzLCB1bm1hbm5l ZCBhaXINCnN5c3RlbSBuZXR3b3JrcywgZXRjLg0KDQpUYWtpbmcgYXZpYXRpb24gZm9yIGV4YW1w bGUsIEkgYmVsaWV2ZSB0aGF0IGFpcnBsYW5lcyB3aWxsIGhhdmUgbWFueQ0Kb25ib2FyZCBhZGRy ZXNzYWJsZSBkZXZpY2VzIGFuZCBuZXR3b3Jrcy4gU28sIGEgLzU2IChvciBwb3NzaWJseSBldmVu DQptb3JlKSBtaWdodCBiZSBhIG5hdHVyYWwgcHJlZml4IGRlbGVnYXRpb24gdW5pdCBmb3IgZWFj aCBhaXJwbGFuZS4NCg0KPiA+IFBvaW50IGJlaW5nIHRoYXQgdGhlIG1lY2hhbmlzbSBzaG91bGQg c3VwcG9ydCBhbnkgcHJlZml4IGRlbGVnYXRpb24NCj4gPiBzaXplIHRoYXQgdGhlIHVzZXIgaGFz IGNvbnRyYWN0ZWQgd2l0aCB0aGUgc2VydmljZSBwcm92aWRlciBmb3I7IG5vdA0KPiA+IGp1c3Qg YSBmaXhlZCBvbmUtc2l6ZS1maXRzLWFsbCBzaXplIGZvciBhbGwgdXNlcnMuDQo+IA0KPiBJIGFn cmVlIC0gdGhlIG1lY2hhbmlzbSBpcyB0aGVyZS4NCg0KT0suDQoNCj4gV2h5IHRoZSBjZWxsdWxh ciBvcGVyYXRvcnMgZG9udCByZXNwb25kIHRvIERIQ1B2NiBQcmVmaXggRGVsZWdhdGlvbg0KPiBy ZXF1ZXN0cyBmcm9tIHRoZSBVc2VyIEVxdWlwbWVudHM/DQoNCkkgZG9uJ3Qga25vdyB3aHkgLSBp dCBpcyByZWFsbHkgZWFzeSB0byBzZXQgdXAsIGFuZCBhIG5hdHVyYWwgd2F5IHRvIGdldA0KYW4g YXJiaXRyYXJ5LWxlbmd0aCBwcmVmaXggZGVsZWdhdGlvbiB0byB0aGUgVUUuDQoNClRoYW5rcyAt IEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiBBbGV4DQo+IA0KPiA+DQo+ID4g VGhhbmtzIC0gRnJlZCBmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+ID4NCj4gPj4NCj4gPj4g QWxleA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFRoYW5rcyAtIEZyZWQg ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+Pj4NCj4gPj4+PiBBbGV4DQo+ID4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pj4gVGhhbmtzIC0gRnJlZCBmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+ ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQWxleA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+IFRoYW5rcyAtIEZyZWQgZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+Pj4+Pj4+ DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gQWxleA0KPiA+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEJ1dCB5ZXMsIEkgYWdyZWUgd2l0aCB5b3UuDQo+ID4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4gY2hlZXJzLCAtLXNhdG9ydQ0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+IE9uIFdlZCwgTWF5IDI3LCAyMDE1IGF0IDg6MzEgUE0sIEFsZXhhbmRydSBQZXRyZXNjdQ0K PiA+Pj4+Pj4+Pj4gPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20NCj4gPj4+Pj4+Pj4+IDxt YWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbT4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+IEhpLA0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEluIGFkZGl0aW9uIHRv IHdoYXQgQmVoY2V0IHNheXMuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gSSByZWFkIHRoZSBl eGFtcGxlIGJlbG93LiAgSSB0aGluayBpdCBpcyBqdXN0IGFuDQo+ID4+Pj4+Pj4+PiBleGFtcGxl LCBidXQganVzdCB0byBtYWtlIHN1cmUuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gUGxlYXNl IC0gZG8gbm90IGFsbG9jYXRlIC82NHMgdG8gZW5kIHVzZXJzIGluIGENCj4gPj4+Pj4+Pj4+IGNl bGx1bGFyIG5ldHdvcmsuIEFsbG9jYXRlIGF0IGxlYXN0IC82MnMgdG8gZW5kDQo+ID4+Pj4+Pj4+ PiB1c2Vycy4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBUaGlzIGlzIHRvIGFsbG93IHRoZSBz bWFydHBob25lIHRvIHBlcmZvcm0gdGV0aGVyaW5nDQo+ID4+Pj4+Pj4+PiAoc21hbGwgbmV0d29y ayBvZiB3aWZpIGRldmljZXMgY29ubmVjdGluZyB0aHJvdWdoDQo+ID4+Pj4+Pj4+PiB0aGUgc21h cnRwaG9uZSB0byB0aGUgSW50ZXJuZXQpLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFRoZSBh c3N1bXB0aW9uIG9mIC82NCB0byBlbmQgdXNlciBpcyBub3QgZ29vZCBhdA0KPiA+Pj4+Pj4+Pj4g YWxsLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IChhbmQgeWVzLCBJIGFncmVlIHRoYXQgdGhl c2UgLzYycyBtYXkgYmUgYWdncmVnYXRlZA0KPiA+Pj4+Pj4+Pj4gaW50byBhIGxhcmdlciBwcmVm aXggYW5kIGFkdmVydGlzZWQgdXBzdHJlYW0gYXMgYQ0KPiA+Pj4+Pj4+Pj4gc2luZ2xlIHByZWZp eCBpbnN0ZWFkIG9mIG11bHRpcGxlIGhvc3QtYmFzZWQNCj4gPj4+Pj4+Pj4+IHJvdXRlcykuDQo+ ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gWW91cnMsDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4g QWxleCBQZXRyZXNjdQ0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IExlIDI2LzA1LzIwMTUgMjI6 MzQsIEJlaGNldCBTYXJpa2F5YSBhIMOpY3JpdCA6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4g SGkgU2F0b3J1LA0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFRoYW5rcyBmb3IgeW91ciByZXBs eS4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBMZXQgbWUgY29udGludWUgdGhlIGRpc2N1c3Np b24gd2l0aCB5b3VyIHRleHQgaW4NCj4gPj4+Pj4+Pj4+IFNlY3Rpb24gMy4yIHdoZXJlIHlvdSBt ZW50aW9uIHZFUEMgbWF5IHV0aWxpemVzDQo+ID4+Pj4+Pj4+PiBGb3J3YXJkaW5nIFBvbGljeSBD b25maWd1cmF0aW9uIFByb3RvY29sIChGUENQKSB0aGF0DQo+ID4+Pj4+Pj4+PiBkZWZpbmVzIEZQ Q1AgQWdlbnQgZnVuY3Rpb24gYW5kIENsaWVudCBmdW5jdGlvbi4NCj4gPj4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+PiBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHlvdSBjb3VsZCBqdXN0aWZ5IGRlZmluaW5n IGENCj4gPj4+Pj4+Pj4+IG5ldyBmb3J3YXJkaW5nIHBvbGljeSBjb25maWd1cmF0aW9uIHByb3Rv Y29sIHRvIGRvDQo+ID4+Pj4+Pj4+PiB0aGlzIEFnZW50L0NsaWVudCBmdW5jdGlvbmFsaXR5PyBX aHkgbm90IHVzZSBzaW1pbGFyDQo+ID4+Pj4+Pj4+PiBBZ2VudC9DbGllbnQgbW9kZWxzIHRoYXQg YXJlIGJlaW5nIGRlZmluZWQgcmF0aGVyDQo+ID4+Pj4+Pj4+PiB0aGFuIGRlZmluaW5nIGEgbmV3 IHByb3RvY29sPyBJIHRoaW5rIHRoaXMgcG9pbnQNCj4gPj4+Pj4+Pj4+IHJlcXVpcmVzIG11Y2gg c3Ryb25nZXIganVzdGlmaWNhdGlvbiB3aGljaCBJIGNvdWxkDQo+ID4+Pj4+Pj4+PiBub3Qgc2Vl IGluIFNlY3Rpb24gMy4yLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEFyZSB5b3UgdGhhdCB3 ZSBoYXZlIHRvIHRvIHJlaW52ZW50IHRoZSB3aGVlbCwNCj4gPj4+Pj4+Pj4+IHJhdGhlciB0aGFu IHJldXNpbmcgc29tZXRoaW5nIHRoYXQgaXMgYWxyZWFkeQ0KPiA+Pj4+Pj4+Pj4gYXZhaWxhYmxl PyBIb3cgYXJlIHdlIGdvaW5nIHRvIHJlaW52ZW50IHRoYXQgd2hlZWwNCj4gPj4+Pj4+Pj4+IGFs c28gcmVtYWlucyB0byBiZSBzZWVuLCBJIHRoaW5rLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ IFJlZ2FyZHMsDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gQmVoY2V0DQo+ID4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBPbiBTYXQsIE1heSAxNiwgMjAx NSBhdCA4OjAxIEFNLCBTYXRvcnUgTWF0c3VzaGltYQ0KPiA+Pj4+Pj4+Pj4gPHNhdG9ydS5tYXRz dXNoaW1hQGdtYWlsLmNvbQ0KPiA+Pj4+Pj4+Pj4gPG1haWx0bzpzYXRvcnUubWF0c3VzaGltYUBn bWFpbC5jb20+PiB3cm90ZToNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBIaSBCZWNoZXQtc2Fu LA0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFRoYW5rIHlvdSBmb3IgeW91ciBxdWVzdGlvbi4g SW4gc3RlcCAoMTUpLCBJIG1lYW50DQo+ID4+Pj4+Pj4+PiB0aGF0IEVQQy1FIGFkdmVydGlzZXMg cHJlZml4IGluY2x1ZGluZyBVRSBhc3NpZ25lZA0KPiA+Pj4+Pj4+Pj4gcHJlZml4ZXMuDQo+ID4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gRm9yIGV4YW1wbGUsIGluIHRoZSBjYXNlIG9mIC82NCBwcmVm aXhlcyBhc3NpZ25lZCB0bw0KPiA+Pj4+Pj4+Pj4gVUVzIGZyb20gYSAvNTYgc3BhY2UsIHRoYXQg LzU2IGlzIGFkdmVydGlzZWQgYnkgRVBDLUUNCj4gPj4+Pj4+Pj4+IHRvIHVwc3RyZWFtIHJvdXRl cnMuIFNvIHRoZSBhZHZlcnRpc2VkIHJvdXRlIGlzbid0DQo+ID4+Pj4+Pj4+PiBob3N0IHJvdXRl cy4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBEZXBlbmRzIG9uIGNvbmZpZ3VyYXRpb24gcG9s aWN5LCBidXQgb25lIGNhc2UgaXMgdGhhdA0KPiA+Pj4+Pj4+Pj4gdGhlIHNvdXJjZSBvZiB0aGF0 IGFkdmVydGlzZWQgLzU2IHJvdXRlIG1pZ2h0IGJlDQo+ID4+Pj4+Pj4+PiBzdGF0aWNhbGx5IGNv bmZpZ3VyZWQgaW4gRVBDLUUuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gUmVnYXJkcywgLS1z YXRvcnUNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ IE9uIFdlZCwgTWF5IDEzLCAyMDE1IGF0IDQ6NTEgQU0sIEJlaGNldCBTYXJpa2F5YQ0KPiA+Pj4+ Pj4+Pj4gPHNhcmlrYXlhMjAxMkBnbWFpbC5jb20NCj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2FyaWth eWEyMDEyQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+PiBIaSBNYXRzdXNoaW1hLXNhbiwNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBJIGhh dmUgYSBxdWVzdGlvbiBvbiB5b3VyIGRyYWZ0OiBJbiBTZWMuIDMuMiwgcGFnZQ0KPiA+Pj4+Pj4+ Pj4gMTEsIHlvdSBzYXkgSW4gc3RlcCAoMTUpLCB0aGUgRVBDLUUgYWR2ZXJ0aXNlcyByb3V0ZXMN Cj4gPj4+Pj4+Pj4+IHRvIHVwc3RyZWFtIHJvdXRlcnMgLi4uDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4gQXJlIHRoZXNlIHJvdXRlcyBzdGF0aWMvaG9zdCByb3V0ZXM/DQo+ID4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBCZWhjZXQNCj4g Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBkbW0N Cj4gPj4+Pj4+Pj4+IG1haWxpbmcgbGlzdCBkbW1AaWV0Zi5vcmcgPG1haWx0bzpkbW1AaWV0Zi5v cmc+DQo+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rt bQ0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IGRtbQ0KPiA+Pj4+Pj4+Pj4gbWFpbGluZyBsaXN0IGRtbUBpZXRmLm9yZyA8bWFpbHRvOmRtbUBp ZXRmLm9yZz4NCj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZG1tDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18gZG1tDQo+ID4+Pj4+Pj4+IG1haWxpbmcgbGlzdCBkbW1AaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4gPj4+Pj4+DQo+ID4+ Pj4+DQo+ID4+Pj4NCj4gPj4+DQo+ID4NCg0K From nobody Tue Jun 9 09:45:27 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369D31ACD04 for ; Tue, 9 Jun 2015 09:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8uvvT38Lqd1 for ; Tue, 9 Jun 2015 09:45:23 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 3ACC71A9231 for ; Tue, 9 Jun 2015 09:45:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t59GjMoO027992; Tue, 9 Jun 2015 09:45:22 -0700 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t59GjCdJ027549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 9 Jun 2015 09:45:12 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.72]) with mapi id 14.03.0235.001; Tue, 9 Jun 2015 09:45:12 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] Scaling properties of AERO Thread-Index: AdCiMU2vkCk188h2SG+1hIBCXKsmQwA0FaUAAAzBKdA= Date: Tue, 9 Jun 2015 16:45:11 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E856DB@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E84ED7@XCH-BLV-504.nw.nos.boeing.com> <557702D0.40805@gmail.com> In-Reply-To: <557702D0.40805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Scaling properties of AERO X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:45:26 -0000 Hi Alex, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Tuesday, June 09, 2015 8:14 AM > To: dmm@ietf.org > Subject: Re: [DMM] Scaling properties of AERO >=20 >=20 >=20 > Le 08/06/2015 23:29, Templin, Fred L a =E9crit : > > Hi, > > > > I finally had a chance to sit back and think about the scaling > > properties of AERO, and I think it is within reason for each AERO > > link to service O(10^9) Clients. Here is what I wrote in the latest > > AERO draft version: > > > > "Scaling properties of the AERO routing system are therefore limited > > by the number of BGP routes that can be carried by Relays. Assuming > > O(10^6) as a maximum number of BGP routes, >=20 > Deserves explanation of the O notation, and deserves expalining why you > assume 10^6 (and not 10^7). >=20 > Another maximum number of BGP routes can be found in the routers in the > Default-Free Zone: 535593 as of January 30th, 2015. Great; then, I think saying O(10^6) is not such a stretch whereas O(10^7) or more may also be possible but perhaps not as substantiated by current operational parameters? > Do you want the AERO system to scale as much as the entire existing > Internet? Or be part of it? Each AERO link is associated with a "home" network - for example, a major enterprise network, an ISP network, an aviation network, etc. It should be possible for each AERO link to accommodate large-scale deployments of mobile routers within each domain. O(10^9) mobile routers, each with an arbitrary-length prefix delegation, seems like reasonable scaling propertie= s. Also, given that there may be many thousands of AERO links worldwide there may indeed be considerable scaling advantages.=20 > > this means that at most O(10^6) Clients can be serviced by Relays > > within a single BGP instance. >=20 > The O explanation would include the fact that several Clients behind a > Mobile Router keeps the same order of magnitude? Each Client is a Mobile Router, and may connect an arbitrarily large networ= k of multitudes of hosts that travel along with it. Think of an airplane as a= good example. Your cellphone and its associated personal area network devices is another good example. > > A means of increasing scaling would be to assign a different set of > > Relays for each set of ASPs, and still have each Server peer with > > each Relay but with a distinct BGP instance for each Relay set. > > Another possibility would be for Servers to institute route filters > > within a single BGP instance so that each set of Relays only > > receives BGP updates for the ASPs they aggregate. > > > > Assuming up to O(10^3) sets of Relays, scaling can then accommodate > > O(10^9) Clients with no additional overhead for Servers and Relays. > > In this way, each set of Relays services a specific set of ASPs that > > they advertise to peers outside of the AERO link, and each Server > > configures ASP-specific routes that list the correct set of Relays > > as next hops." > > > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ >=20 > I still have to understand this draft. It is really very straightforward and something everyone on this list shoul= d examine. All it is is a virtual link model that uses DHCPv6 and IPv6 ND the same as for regular physical links like Ethernet. Also BGP as the routing system. > But when talking scaling of a routing system, I think it is worth > characterizing it with maybe a few more parameters. >=20 > The maximum number of IP hops in a shortest path between the BGP routers > which exchanged a route respective to a Moving Network. This is where AERO route optimization comes in. > The positive influence of the default routes on the reduction of route > update messages. Route update messages occur only when a Client changes from an old Server to a new Server which should happen very infrequently. That would constitute a "macro-mobility" event. Client "micro-mobility" events are coordinated between the Client and its Server and are not propagated into the routing system. > The influence of aggregating prefixes in the reduction of routes in the > routing tables (centralized and well-planned addressing architecture). Yes, aggregated prefixes known as AERO Service Prefixes (ASPs) are a fundamental design point in terms of scalability. > It is also worth making affirmative statements of the fact that BGP > worked to support mobility of a network the size of an airliner over two > continents, with an IP hop count of maximum 4(?) between the BGP routers > on the ground which injected the respective route. This would hint at > the fact that a BGP system part of AERO is scalable to support mobility. Need to be careful here. Although AERO uses BGP, it is not the same thing as Connexion By Boeing (CBB). CBB injected and withdrew BGP routes in the global BGP routing system which imparted unacceptable churn. AERO does not inject any mobile network prefixes into the global BGP routing system. The vepc people cited CBB, but they should also take a look at AERO as a viable BGP-based mobility solution. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 >=20 > > > > Comments? > > > > Thanks - Fred fred.l.templin@boeing.com > > > > _______________________________________________ dmm mailing list > > dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > > > >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Jun 10 08:45:13 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E820F1B2C8F for ; Wed, 10 Jun 2015 08:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7M7Ingqp1PD for ; Wed, 10 Jun 2015 08:45:09 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 B9CEA1B2C8C for ; Wed, 10 Jun 2015 08:45:08 -0700 (PDT) Received: by qgep100 with SMTP id p100so17680965qge.3 for ; Wed, 10 Jun 2015 08:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LmxTiRuNa0p42taDuzXUrywk9bl57MqKVIbZ0D+d64o=; b=pDJ0GyTJX3zQPTtBeq0WPOSWh+z+qa3mcRjp9SEpIcDzLmH3RcHAQtJfNZDVIa/n/b rUZwI9Tjdye9/cAQ3+CmCREXZIvVUUfl+Q27zo7NR2w5pDbiiF/gowk5bWZZnb4IncTS YCxOm7nQcYnlE+VbH44Col/IZsQBNZBoPhF/fQoBUUuFLq6Gra398p1Fo8S1G4UDCcQW bjF1fQTeLrukYRsY5tVC9nO3s95+63deFp6UgWA0NHAkdN2e64hbinntJH+NfnvpSuIQ InY5Hw2QIDw7n4iHJBqG+2S+QUyLyJIaSg1fVmU7P92OfPAZcKgOltg4iXonZMlTius5 vkbA== X-Received: by 10.55.18.9 with SMTP id c9mr8108769qkh.50.1433951107942; Wed, 10 Jun 2015 08:45:07 -0700 (PDT) Received: from [10.16.10.44] ([216.31.219.19]) by mx.google.com with ESMTPSA id i92sm4278982qkh.5.2015.06.10.08.45.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 08:45:07 -0700 (PDT) Message-ID: <55785B80.1050508@gmail.com> Date: Wed, 10 Jun 2015 08:45:04 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Seil Jeon , Dapeng Liu References: <055.11eed04efa98a7f2b790db5b6c2193d1@tools.ietf.org> <001501d092d8$fae22420$f0a66c60$@av.it.pt> <000c01d09482$34031160$9c093420$@av.it.pt> <007e01d09c71$cbe47950$63ad6bf0$@av.it.pt> <8FBCBACA-5118-438D-8840-31264CF0E6D8@yegin.org> <001801d09cc0$5a5f3ff0$0f1dbfd0$@av.it.pt> <005d01d09de5$dadd6b40$909841c0$@av.it.pt> <3620CF9B-EF59-4DF0-993F-4442D91604DC@yegin.org> <000301d0a203$b8ccde60$2a669b20$@av.it.pt> In-Reply-To: <000301d0a203$b8ccde60$2a669b20$@av.it.pt> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] FW: [dmm] #49 (ondemand-mobility): full on-demand mobility support X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 15:45:12 -0000 Add your comments/modifiactions to "add a comment" box and modify ticket "leave as new". - Jouni 6/8/2015, 8:56 AM, Seil Jeon kirjoitti: > Hi Chairs, > > We want to elaborate the issue created in the tracker for clarity. What > Action should I take in “Modify Ticket”? > > - leave as new > > - resolve as … > > - reassign to … > > Regards, > > Seil > > *From:*Alper Yegin [mailto:alper.yegin@yegin.org] > *Sent:* Wednesday, June 03, 2015 11:34 AM > *To:* Seil Jeon > *Cc:* dmm@ietf.org > *Subject:* Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand > mobility support > > OK, so now at least I fully understand what this is. > > My recommendation is: > > - Please refine the issue definition in the tracker, so that people can > understand this the same way, > > - And then let's ask the WG members their opinion about the issue > (whether it's something worth tackling or not), > > - And if they agree to the issue, then we move to the solution space > discussion. > > Alper > > On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote: > > > > - A Sustained IP address that just got allocated from the currently > serving network (hence the "mobility is not activated" until the MN > moves off link)? > >>Yes. Thanks for your elaboration. > > Regards, > > Seil > > *From:*Alper Yegin [mailto:alper.yegin@yegin.org] > *Sent:*Wednesday, June 03, 2015 7:03 AM > *To:*Seil Jeon > *Cc:*dmm@ietf.org > *Subject:*Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand > mobility support > > So, the idea is, when this flag is set along with a Sustained IP > address request from the app: > > - if the host stack is already configured with a Sustained IP > address allocated from the serving network, then it gets selected > (irrespective of the presence or absence of any other Sustained IP > address). > > >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network. > > What exactly is "(an IP address) that does not activate IP mobility"? > Please elaborate. > > Is it > > - A nomadic IP address? > > - A Sustained IP address that just got allocated from the currently > serving network (hence the "mobility is not activated" until the MN > moves off link)? > > - something else? > > Alper > > On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote: > > > > > Hi Alper, > > Regards, > > Seil > > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Monday, June 01, 2015 8:50 PM > To: Seil Jeon > Cc:dmm@ietf.org > Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand > mobility support > >> The point is that when the IP stack receives a flag with sustained IP > >> address flag, it will check it has a sustained IP address, and if it > >> has one or more, one that does not activate IP mobility will be > >> selected. If not, the MN will be triggered to get a new IP sustained > >> address not activing IP mobility. > > So, the idea is, when this flag is set along with a Sustained IP address > request from the app: > > - if the host stack is already configured with a Sustained IP address > allocated from the serving network, then it gets selected (irrespective > of the presence or absence of any other Sustained IP address). > >>> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network. > > - if the host stack is not already configured with a Sustained IP > address allocated from the serving network (irrespective of the presence > or absence of any Sustained IP address from any other network), then the > host makes an attempt to configure one with the serving network. > >>> Yes. > > -- if the configuration succeeds, then the newly configured IP address > is selected. > >>> Yes. > > -- if the configuration fails. then the call fails (?? or some other > behavior -- you can define here). > >>> You mean the configuration fails when there is no sustained IP address, right? > > In my opinion, this issue belongs to address configuration mechanism > based on definition of the three DMM APIs. Those jobs are/will be asked > on each configuration mechanism, according to discussion of the previous > teleconference in the WT you’re leading. At that time, if I see any > something related to our proposal, we will raise our voice. > > Alper > >>>> #49: full on-demand mobility support > >>>> > >>>> The three proposed flags express a "type" of source IP address an > >>> application wants to get to the IP stack. Particularly, the sustained > >>> IP address is proposed to provide on-demand IP session continuity, > >>> which activates IP mobility once the terminal moves across other > >>> access > >> network. > >>>> While the terminal stays at the same network where the session is > >>> initiated, regular IP routing is applied. > >>>> > >>>> The on-demand draft does not assure provide the full on-demand > >>>> mobility > >>> for all scenarios by merely indicating the Socket API, > >>> IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned > >>> issue is as follows; > >>>> > >>>> 0. The MN is configured with one or more Nomadic IP addresses. > >>>> > >>>> 1. Once an app. requests "sustained IP address" to the IP stack, and > >>>> it > >>> will obtain a sustained IP address through a protocol procedure > >>> between the terminal and network. > >>>> > >>>> 2. Other app. initiated over the same access network will use the > >>>> same > >>> sustained IP address while the terminal remains connected at the same > >>> access network. > >>>> > >>>> 3. The terminal moves to another access network and a new app. > >>>> requests a > >>> sustained IP address with the Socket API to the IP stack. Since a > >>> sustained IP address is already available in the IP stack, the > >>> sustained IP address is assigned to the new app. > >>>> > >>> > >>> Yes, that's what happens. > >>> You are not pointing to an issue up until this point, right? Because, > >>> you continuing your email with a "Besides" gives the impression that > >>> you are pointing to an issue, but I don't see any issue captured in > >>> the > >> above text. > >>> > >>>>> There is an issue. Maybe, we need to be synchronized how have you > >>>>> thought > >>> and defined the meaning of "on-demand mobility". As far as I know, > >>> there are two meanings; one is that by imposing capability among IP > >>> address reachability and IP session continuity, needed for an > >>> application, into a source IP address, on-demand mobility could be > >>> achieved; as the other meaning, it can be rephrased and detailed with > >>> dynamic mobility, which should be applied in the use of sustained IP > >>> address. A new application needs to have non-anchored sustained IP > >>> address. This is our consistent claim. Non-optimal routing issue has > >>> been raised in DMM Requirement document in RFC 7333, which should be > >> critically considered in the solutions. > >>> > >> > >> Sorry, I don't understand what you meant here. > >> > >>>>> You answer doesn't make us progress. Please specify where and what > >>>>> you > >> have understood. > >> > >> > >>>> Besides, in case sustained IP address allocation is used default, > >>>> there > >>> may be multiple sustained IP addresses including newly obtained > >>> sustained IP address over the new access network in the IP stack. > >>> However, when an app. is initiated, the IP stack may not select the > >>> new one in the context of the default source IP address selection > >> mechanism [RFC6724][RFC5014]. > >>>> > >>> > >>> OK, is the issue following: When there are multiple sustained IP > >>> addresses, how does the IP stack pick one among them? (*) > >>> > >>>>> As mentioned and specified in our draft > >>>http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, > >>> if there is no additional preference, we can leave selection to the > >>> default source address selection mechanism. BUT if we have specific > >>> preference among multiple sustained IP addresses and an initiated > >>> application wants to have non-anchored sustained IP address over > >>> currently attached access network, the proposed flag is essential. > >>> > >> > >> I think you are meaning the same thing as I said above (*). > >> Do you agree? > >> > >>>>> Yes. > >> > >>>> For providing the full on-demand mobility, a new flag is needed, > >>>> letting > >>> the IP stack request a new sustained IP address or choose a sustained > >>> IP address not requiring IP mobility anchoring when an application is > >>> initiated, among the existing ones in the IP stack. > >>>> > >>> > >>> Your flag is not a solution to what I captured above. It does > >>> something > >>> else: Instruct the IP stack to go get a new sustained IP address > >>> whether there is already one or more configured on the stack or not. > >>> (**) > >>> > >>>>> Answered in the above. > >>> > >> > >> There's a discrepancy between (*) and your solution (**). > >> > >> Are we talking about (*), (**), or something else? > >> > >>>>> There is no discrepancy between them. I said "a new flag", just an > >> additional flag not intending to get a new sustained IP address all > >> the time. And it should not request a new sustained IP address whether > >> there is already one or more configured on the stack or not. It is > >> given with the same expression in the ticket, though our draft is > >> saying the meaning of a new sustained IP address, which will be revised in next update. > >> > >> The point is that when the IP stack receives a flag with sustained IP > >> address flag, it will check it has a sustained IP address, and if it > >> has one or more, one that does not activate IP mobility will be > >> selected. If not, the MN will be triggered to get a new IP sustained > >> address not activing IP mobility. > >> > >> > >> Seil Jeon > >> > >> > >> > >> > >>> Alper > >>> > >>> > >>> > >>>> -- > >>>> -------------------------+------------------------------------------ > >>>> -------------------------+- > >>>> -------------------------+--- > >>>> -------------------------+--- > >>>> Reporter: | Owner: draft-ietf-dmm-ondemand- > >>>>seiljeon@av.it.pt | > mobility@tools.ietf.org > >>>> Type: defect | Status: new > >>>> Priority: critical | Milestone: > >>>> Component: ondemand- | Version: > >>>> mobility | Keywords: on-demand mobility > >>>> Severity: Submitted | > >>>> WG Document | > >>>> -------------------------+------------------------------------------ > >>>> -------------------------+- > >>>> -------------------------+--- > >>>> -------------------------+--- > >>>> > >>>> Ticket URL: > >>>> dmm > >>>> > >>>> > >>>> _______________________________________________ > >>>> dmm mailing list > >>>>dmm@ietf.org > >>>>https://www.ietf.org/mailman/listinfo/dmm > >>> > >>> > >> > >> > From nobody Thu Jun 11 09:02:47 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E8E1B2F9A for ; Thu, 11 Jun 2015 09:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAnYkBkMvNPD for ; Thu, 11 Jun 2015 09:02:43 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 408B31B2BCF for ; Thu, 11 Jun 2015 09:02:43 -0700 (PDT) Received: by qgf75 with SMTP id 75so3361777qgf.1 for ; Thu, 11 Jun 2015 09:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tvxQk82KnZXBN3SnU+XB7NXeZ8vOR5QUGIwi53vgbWo=; b=JRguwGeaAkdEIxQTs/4QFPXUdolDLAEFhn/AvMQNlKH7yzsGo2a8F9F3I3MEKvPqPH YRlnNv3ZwF6dWOGQDYrAiAXAyjDU9GeNITp2WkasRryk4wA8v/ncBrHMsR/jnPN0s6R+ W5Uzq1pePMYqk8t9y9VwdoURwmEVwXcM5mmF0n5lM0v2T09h668pIJsPqskh4pMTD6tZ DK5tFpOPZ3osnqFmfWAkQYmzFRpQD+F6HRyLePXJaL7KuB/v7UjEBPbTj+UdY+8VI5y3 ZS1g/TFehXDwE0eMOiD6JuFzVa0ys4MRmFY8r1SAPsZNnVG3kCfP6qAmpBG1ZorfA6XC KBsw== X-Received: by 10.140.150.78 with SMTP id 75mr13117021qhw.10.1434038562495; Thu, 11 Jun 2015 09:02:42 -0700 (PDT) Received: from [10.16.10.51] ([216.31.219.19]) by mx.google.com with ESMTPSA id t91sm417701qgd.45.2015.06.11.09.02.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2015 09:02:42 -0700 (PDT) Message-ID: <5579B120.1020806@gmail.com> Date: Thu, 11 Jun 2015 09:02:40 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alexandru Petrescu , "dmm@ietf.org" References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> In-Reply-To: <55705BE6.50205@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:02:45 -0000 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: > Le 04/06/2015 05:42, Templin, Fred L a écrit : >> Hi Alex, >> >>> -----Original Message----- >>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>> Sent: Wednesday, June 03, 2015 8:36 AM >>> To: Templin, Fred L; Satoru Matsushima >>> Cc: dmm >>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >>> >>> Le 29/05/2015 20:21, Templin, Fred L a écrit : >>>> Hi Alex, >>>> >>>>> -----Original Message----- >>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru >>>>> Petrescu >>>>> Sent: Friday, May 29, 2015 10:59 AM >>>>> To: Satoru Matsushima >>>>> Cc: dmm >>>>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >>>>> >>>>> Le 29/05/2015 15:30, Satoru Matsushima a écrit : >>>>>> Ah OK. thanks. >>>>>> Slightly off-topic, I think that there is still chance for tethering >>>>>> with single /64 if it is allocated as a off-link prefix. >>>>> >>>>> Yes, there is still such a chance. But it can not tether more than >>>>> one >>>>> single subnet. Connected vehicles need several subnets. >>>> >>>> How would it be if the vehicle received a single prefix, but it >>>> could be >>>> shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting >>>> be satisfied if it received a shorter prefix from which many /64s >>>> could be allocated? >>> >>> Certainly yes. >>> >>> Each vehicle needs such a shorter-than-64 prefix allocated to it. >>> >>> For example, an automobile connecting to LTE receives a /62 from the >>> operator and makes four /64s out of it: one for its CAN-entertainment, >>> one for its CAN-safety, one for its WiFi and one for its Bluetooth. >>> >>> This is a MUST. >>> >>> Allocating a single /64 to a vehicle can not accommodate all these >>> unbridgeable subnets. >> >> OK, that is good. Giving a mobile router something shorter than /64 >> should be no problem, at least up to practical limitations of the prefix >> delegation authority's available prefix space. DHCPv6 PD provides all >> that is needed to give out right-sized prefixes. > > I agree DHCP-PD provides the necessary tool. But unfortunately the > cellular operators have not deployed DHCPv6-PD (although yes there is > some DHCP-non-PD in some IPv6/4G deployments). > > The common thinking at operators and advisers is still that a /64 should > be given to an User Equipment. > > This must change: the 3GPP specs and operator deployments must give /62 > to UEs, and not /64. I think we are not in the position to force operators or 3GPP to do anything, unfortunately. The best we can do is to make sure the protocols we work here in IETF are not prohibiting better deployments (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. I know this is frustrating. For example some operators I know offer IPv6 PD on their fixed side of business but have no plans for similar on the cellular side.. reasons are many. I assume that identofying a strong enough use case would be the key. - Jouni > > Alex > >> >> Thanks - Fred >> fred.l.templin@boeing.com >> >>> >>> Alex >>> >>>> >>>> Thanks - Fred >>>> fred.l.templin@boeing.com >>>> >>>> >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> But yes, I agree with you. >>>>>> >>>>>> cheers, >>>>>> --satoru >>>>>> >>>>>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> In addition to what Behcet says. >>>>>> >>>>>> I read the example below. I think it is just an example, >>>>>> but just >>>>>> to make sure. >>>>>> >>>>>> Please - do not allocate /64s to end users in a cellular >>>>>> network. >>>>>> Allocate at least /62s to end users. >>>>>> >>>>>> This is to allow the smartphone to perform tethering (small >>>>>> network >>>>>> of wifi devices connecting through the smartphone to the >>>>>> Internet). >>>>>> >>>>>> The assumption of /64 to end user is not good at all. >>>>>> >>>>>> (and yes, I agree that these /62s may be aggregated into a >>>>>> larger >>>>>> prefix and advertised upstream as a single prefix instead of >>>>>> multiple host-based routes). >>>>>> >>>>>> Yours, >>>>>> >>>>>> Alex Petrescu >>>>>> >>>>>> Le 26/05/2015 22:34, Behcet Sarikaya a écrit : >>>>>> >>>>>> Hi Satoru, >>>>>> >>>>>> Thanks for your reply. >>>>>> >>>>>> Let me continue the discussion with your text in Section >>>>>> 3.2 >>>>>> where you mention >>>>>> vEPC may utilizes Forwarding Policy Configuration >>>>>> Protocol (FPCP) >>>>>> that defines FPCP Agent function and Client function. >>>>>> >>>>>> I don't understand how you could justify defining a new >>>>>> forwarding >>>>>> policy configuration protocol to do this Agent/Client >>>>>> functionality? >>>>>> Why not use similar Agent/Client models that are being >>>>>> defined >>>>>> rather >>>>>> than defining a new protocol? >>>>>> I think this point requires much stronger justification >>>>>> which I >>>>>> could >>>>>> not see in Section 3.2. >>>>>> >>>>>> Are you that we have to to reinvent the wheel, rather >>>>>> than reusing >>>>>> something that is already available? How are we going to >>>>>> reinvent that >>>>>> wheel also remains to be seen, I think. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> >>>>>> >>>>>> >>>>>> On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi Bechet-san, >>>>>> >>>>>> Thank you for your question. >>>>>> In step (15), I meant that EPC-E advertises prefix >>>>>> including >>>>>> UE assigned >>>>>> prefixes. >>>>>> >>>>>> For example, in the case of /64 prefixes assigned to >>>>>> UEs >>>>>> from a /56 space, >>>>>> that /56 >>>>>> is advertised by EPC-E to upstream routers. So the >>>>>> advertised route isn't >>>>>> host routes. >>>>>> >>>>>> Depends on configuration policy, but one case is >>>>>> that the >>>>>> source of that >>>>>> advertised >>>>>> /56 route might be statically configured in EPC-E. >>>>>> >>>>>> Regards, >>>>>> --satoru >>>>>> >>>>>> >>>>>> >>>>>> On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Matsushima-san, >>>>>> >>>>>> I have a question on your draft: >>>>>> In Sec. 3.2, page 11, you say >>>>>> In step (15), the EPC-E advertises routes to >>>>>> upstream >>>>>> routers ... >>>>>> >>>>>> Are these routes static/host routes? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>> >> > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Jun 11 09:19:40 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5299E1B29DD for ; Thu, 11 Jun 2015 09:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmvCzw6wszDX for ; Thu, 11 Jun 2015 09:19:36 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9B31B2AC8 for ; Thu, 11 Jun 2015 09:19:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5BGJW83005228; Thu, 11 Jun 2015 18:19:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ED14420BEC4; Thu, 11 Jun 2015 18:22:09 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E056A20BE71; Thu, 11 Jun 2015 18:22:09 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5BGJS3W007506; Thu, 11 Jun 2015 18:19:32 +0200 Message-ID: <5579B510.9020909@gmail.com> Date: Thu, 11 Jun 2015 18:19:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jouni Korhonen , "dmm@ietf.org" References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <5579B120.1020806@gmail.com> In-Reply-To: <5579B120.1020806@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:19:38 -0000 Le 11/06/2015 18:02, Jouni Korhonen a écrit : > > > 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: >> Le 04/06/2015 05:42, Templin, Fred L a écrit : >>> Hi Alex, >>> >>>> -----Original Message----- >>>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>>> Sent: Wednesday, June 03, 2015 8:36 AM >>>> To: Templin, Fred L; Satoru Matsushima >>>> Cc: dmm >>>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >>>> >>>> Le 29/05/2015 20:21, Templin, Fred L a écrit : >>>>> Hi Alex, >>>>> >>>>>> -----Original Message----- >>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru >>>>>> Petrescu >>>>>> Sent: Friday, May 29, 2015 10:59 AM >>>>>> To: Satoru Matsushima >>>>>> Cc: dmm >>>>>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >>>>>> >>>>>> Le 29/05/2015 15:30, Satoru Matsushima a écrit : >>>>>>> Ah OK. thanks. >>>>>>> Slightly off-topic, I think that there is still chance for tethering >>>>>>> with single /64 if it is allocated as a off-link prefix. >>>>>> >>>>>> Yes, there is still such a chance. But it can not tether more than >>>>>> one >>>>>> single subnet. Connected vehicles need several subnets. >>>>> >>>>> How would it be if the vehicle received a single prefix, but it >>>>> could be >>>>> shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting >>>>> be satisfied if it received a shorter prefix from which many /64s >>>>> could be allocated? >>>> >>>> Certainly yes. >>>> >>>> Each vehicle needs such a shorter-than-64 prefix allocated to it. >>>> >>>> For example, an automobile connecting to LTE receives a /62 from the >>>> operator and makes four /64s out of it: one for its CAN-entertainment, >>>> one for its CAN-safety, one for its WiFi and one for its Bluetooth. >>>> >>>> This is a MUST. >>>> >>>> Allocating a single /64 to a vehicle can not accommodate all these >>>> unbridgeable subnets. >>> >>> OK, that is good. Giving a mobile router something shorter than /64 >>> should be no problem, at least up to practical limitations of the prefix >>> delegation authority's available prefix space. DHCPv6 PD provides all >>> that is needed to give out right-sized prefixes. >> >> I agree DHCP-PD provides the necessary tool. But unfortunately the >> cellular operators have not deployed DHCPv6-PD (although yes there is >> some DHCP-non-PD in some IPv6/4G deployments). >> >> The common thinking at operators and advisers is still that a /64 should >> be given to an User Equipment. >> >> This must change: the 3GPP specs and operator deployments must give /62 >> to UEs, and not /64. > > I think we are not in the position to force operators or 3GPP to do > anything, unfortunately. The best we can do is to make sure the > protocols we work here in IETF are not prohibiting better deployments > (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. > > I know this is frustrating. For example some operators I know offer IPv6 > PD on their fixed side of business but have no plans for similar on the > cellular side.. reasons are many. I assume that identofying a strong > enough use case would be the key. I would like to discuss these use cases. Use cases of grouping devices under a unique cellular connection are very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on Personal Area Networks. All these devices need the cellular operator to deliver shorter-than-64 prefixes to a SIM connection. Alex > > - Jouni > > > >> >> Alex >> >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>>> >>>> Alex >>>> >>>>> >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com >>>>> >>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> But yes, I agree with you. >>>>>>> >>>>>>> cheers, >>>>>>> --satoru >>>>>>> >>>>>>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> In addition to what Behcet says. >>>>>>> >>>>>>> I read the example below. I think it is just an example, >>>>>>> but just >>>>>>> to make sure. >>>>>>> >>>>>>> Please - do not allocate /64s to end users in a cellular >>>>>>> network. >>>>>>> Allocate at least /62s to end users. >>>>>>> >>>>>>> This is to allow the smartphone to perform tethering (small >>>>>>> network >>>>>>> of wifi devices connecting through the smartphone to the >>>>>>> Internet). >>>>>>> >>>>>>> The assumption of /64 to end user is not good at all. >>>>>>> >>>>>>> (and yes, I agree that these /62s may be aggregated into a >>>>>>> larger >>>>>>> prefix and advertised upstream as a single prefix instead of >>>>>>> multiple host-based routes). >>>>>>> >>>>>>> Yours, >>>>>>> >>>>>>> Alex Petrescu >>>>>>> >>>>>>> Le 26/05/2015 22:34, Behcet Sarikaya a écrit : >>>>>>> >>>>>>> Hi Satoru, >>>>>>> >>>>>>> Thanks for your reply. >>>>>>> >>>>>>> Let me continue the discussion with your text in Section >>>>>>> 3.2 >>>>>>> where you mention >>>>>>> vEPC may utilizes Forwarding Policy Configuration >>>>>>> Protocol (FPCP) >>>>>>> that defines FPCP Agent function and Client function. >>>>>>> >>>>>>> I don't understand how you could justify defining a new >>>>>>> forwarding >>>>>>> policy configuration protocol to do this Agent/Client >>>>>>> functionality? >>>>>>> Why not use similar Agent/Client models that are being >>>>>>> defined >>>>>>> rather >>>>>>> than defining a new protocol? >>>>>>> I think this point requires much stronger justification >>>>>>> which I >>>>>>> could >>>>>>> not see in Section 3.2. >>>>>>> >>>>>>> Are you that we have to to reinvent the wheel, rather >>>>>>> than reusing >>>>>>> something that is already available? How are we going to >>>>>>> reinvent that >>>>>>> wheel also remains to be seen, I think. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi Bechet-san, >>>>>>> >>>>>>> Thank you for your question. >>>>>>> In step (15), I meant that EPC-E advertises prefix >>>>>>> including >>>>>>> UE assigned >>>>>>> prefixes. >>>>>>> >>>>>>> For example, in the case of /64 prefixes assigned to >>>>>>> UEs >>>>>>> from a /56 space, >>>>>>> that /56 >>>>>>> is advertised by EPC-E to upstream routers. So the >>>>>>> advertised route isn't >>>>>>> host routes. >>>>>>> >>>>>>> Depends on configuration policy, but one case is >>>>>>> that the >>>>>>> source of that >>>>>>> advertised >>>>>>> /56 route might be statically configured in EPC-E. >>>>>>> >>>>>>> Regards, >>>>>>> --satoru >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Matsushima-san, >>>>>>> >>>>>>> I have a question on your draft: >>>>>>> In Sec. 3.2, page 11, you say >>>>>>> In step (15), the EPC-E advertises routes to >>>>>>> upstream >>>>>>> routers ... >>>>>>> >>>>>>> Are these routes static/host routes? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>> >>> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > From nobody Thu Jun 11 09:47:26 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ACE1B30FF for ; Thu, 11 Jun 2015 09:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2Yg261kUH9o for ; Thu, 11 Jun 2015 09:47:11 -0700 (PDT) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0412E1B30FC for ; Thu, 11 Jun 2015 09:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=vhWhirkjmrt+Y7iFUPkaYL50apX9tmECgr9yQKgrtJU=; b=AWAg26naTDEz/f+eb66yu3LEkQ5GfL/Q7hZ2nVY5OebPvWdkAAZYcVK9fgiJCcw+XNI1NeNwaWGAv8ePSV4RqsFHEW8Qze1ufHAJIE1X2Pv/jsulu8Oz2C3WcVy0XeqX0fXOBjTs9QsoqD20UuLZeBJBBIXUMV206WKXDT2AMnqO4E1x; Received: from express.tndh.local ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Z35d3-000Io5-MU; Thu, 11 Jun 2015 09:47:09 -0700 From: "Tony Hain" To: "'Alexandru Petrescu'" , "'Jouni Korhonen'" , References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <5579B120.1020806@gmail.com> <5579B510.9020909@gmail.com> In-Reply-To: <5579B510.9020909@gmail.com> Date: Thu, 11 Jun 2015 09:46:56 -0700 Message-ID: <123c01d0a466$3a94e3c0$afbeab40$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLzAYbX+tczklVKp+C6hcHhQXiIbgJC4/zOAcXevwMBlLT6GAGyvW7VASL5HjsCBLNn7wFqGnxOAZmpP6MBnx26TAIjGX1tAf2pTcCayOegEA== Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: alh-ietf@tndh.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.net) Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:47:12 -0000 Alexandru Petrescu wrote: > Le 11/06/2015 18:02, Jouni Korhonen a =C3=A9crit : > > > > > > 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: > >> Le 04/06/2015 05:42, Templin, Fred L a =C3=A9crit : > >>> Hi Alex, > >>> > >>>> -----Original Message----- > >>>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >>>> Sent: Wednesday, June 03, 2015 8:36 AM > >>>> To: Templin, Fred L; Satoru Matsushima > >>>> Cc: dmm > >>>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s > >>>> > >>>> Le 29/05/2015 20:21, Templin, Fred L a =C3=A9crit : > >>>>> Hi Alex, > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru > >>>>>> Petrescu > >>>>>> Sent: Friday, May 29, 2015 10:59 AM > >>>>>> To: Satoru Matsushima > >>>>>> Cc: dmm > >>>>>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s > >>>>>> > >>>>>> Le 29/05/2015 15:30, Satoru Matsushima a =C3=A9crit : > >>>>>>> Ah OK. thanks. > >>>>>>> Slightly off-topic, I think that there is still chance for > >>>>>>> tethering with single /64 if it is allocated as a off-link = prefix. > >>>>>> > >>>>>> Yes, there is still such a chance. But it can not tether more > >>>>>> than one single subnet. Connected vehicles need several = subnets. > >>>>> > >>>>> How would it be if the vehicle received a single prefix, but it > >>>>> could be shorter than /64 (e.g., /56, /48. etc.)? Would the > >>>>> vehicle subnetting be satisfied if it received a shorter prefix > >>>>> from which many /64s could be allocated? > >>>> > >>>> Certainly yes. > >>>> > >>>> Each vehicle needs such a shorter-than-64 prefix allocated to it. > >>>> > >>>> For example, an automobile connecting to LTE receives a /62 from > >>>> the operator and makes four /64s out of it: one for its > >>>> CAN-entertainment, one for its CAN-safety, one for its WiFi and = one for its > Bluetooth. > >>>> > >>>> This is a MUST. > >>>> > >>>> Allocating a single /64 to a vehicle can not accommodate all = these > >>>> unbridgeable subnets. > >>> > >>> OK, that is good. Giving a mobile router something shorter than = /64 > >>> should be no problem, at least up to practical limitations of the > >>> prefix delegation authority's available prefix space. DHCPv6 PD > >>> provides all that is needed to give out right-sized prefixes. > >> > >> I agree DHCP-PD provides the necessary tool. But unfortunately the > >> cellular operators have not deployed DHCPv6-PD (although yes there = is > >> some DHCP-non-PD in some IPv6/4G deployments). > >> > >> The common thinking at operators and advisers is still that a /64 > >> should be given to an User Equipment. > >> > >> This must change: the 3GPP specs and operator deployments must give > >> /62 to UEs, and not /64. > > > > I think we are not in the position to force operators or 3GPP to do > > anything, unfortunately. The best we can do is to make sure the > > protocols we work here in IETF are not prohibiting better = deployments > > (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers = here. > > > > I know this is frustrating. For example some operators I know offer > > IPv6 PD on their fixed side of business but have no plans for = similar > > on the cellular side.. reasons are many. I assume that identofying a > > strong enough use case would be the key. >=20 > I would like to discuss these use cases. >=20 > Use cases of grouping devices under a unique cellular connection are = very > numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on > Personal Area Networks. >=20 > All these devices need the cellular operator to deliver = shorter-than-64 prefixes > to a SIM connection. For lack of a better description, the cellular side of businesses suffer = from "bell head:" thinking, where the UE is an application endpoint. = Nothing more occurs to them, because that is the product they have = always supported. A routing function implies higher aggregate data rates = than they have built the system to handle. I have been in front of many = of them holding up UE and saying, "this is a ROUTER, get over it", and = got nothing but blank stares back.=20 The first use case on the list should be a wireline alternative/backup = link for consumer CPE routers, and home control or security systems. = That is simpler to support because the UE doesn't move around, so they = can scale the infrastructure to align with demand without too much = concern about that shifting quickly. Once the fear of downstream subnets = is removed, working on the truly mobile use cases will be an easier = mental hurdle to overcome.=20 Tony ........... From nobody Thu Jun 11 09:53:43 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6861B1B3112 for ; Thu, 11 Jun 2015 09:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZjRSFJymrS3 for ; Thu, 11 Jun 2015 09:53:37 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F12C1B3107 for ; Thu, 11 Jun 2015 09:53:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t5BGraMa029004; Thu, 11 Jun 2015 11:53:36 -0500 Received: from XCH-BLV-305.nw.nos.boeing.com (xch-blv-305.nw.nos.boeing.com [130.247.25.217]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t5BGrUTL028924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 11 Jun 2015 11:53:31 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-BLV-305.nw.nos.boeing.com ([169.254.5.114]) with mapi id 14.03.0235.001; Thu, 11 Jun 2015 09:53:29 -0700 From: "Templin, Fred L" To: Tony Hain , "'Alexandru Petrescu'" , "'Jouni Korhonen'" , "dmm@ietf.org" Thread-Topic: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Thread-Index: AQHQmjkkJI//M3dql0O3DI0sVGxmlwJC4/zOAcXevwMBlLT6GAGyvW7VASL5HjsCBLNn7wFqGnxOAZmpP6MBnx26TAIjGX1tAf2pTcCayOegEIJE1RJA Date: Thu, 11 Jun 2015 16:53:29 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E8A2EF@XCH-BLV-504.nw.nos.boeing.com> References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <5579B120.1020806@gmail.com> <5579B510.9020909@gmail.com> <123c01d0a466$3a94e3c0$afbeab40$@tndh.net> In-Reply-To: <123c01d0a466$3a94e3c0$afbeab40$@tndh.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:53:40 -0000 UmVzcG9uZGluZyB0byB0d28gaW4gb25lOg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg VG9ueSBIYWluDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDExLCAyMDE1IDk6NDcgQU0NCj4gVG86 ICdBbGV4YW5kcnUgUGV0cmVzY3UnOyAnSm91bmkgS29yaG9uZW4nOyBkbW1AaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtETU1dIHZlcGMgZHJhZnQgUmV2LiAwNCAtIC82MnMgdG8gVUUsIG5vdCAv NjRzDQo+IA0KPiBBbGV4YW5kcnUgUGV0cmVzY3Ugd3JvdGU6DQo+ID4gTGUgMTEvMDYvMjAxNSAx ODowMiwgSm91bmkgS29yaG9uZW4gYSDDqWNyaXQgOg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA2LzQv MjAxNSwgNzowOCBBTSwgQWxleGFuZHJ1IFBldHJlc2N1IGtpcmpvaXR0aToNCj4gPiA+PiBMZSAw NC8wNi8yMDE1IDA1OjQyLCBUZW1wbGluLCBGcmVkIEwgYSDDqWNyaXQgOg0KPiA+ID4+PiBIaSBB bGV4LA0KPiA+ID4+Pg0KPiA+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ Pj4+IEZyb206IEFsZXhhbmRydSBQZXRyZXNjdSBbbWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBn bWFpbC5jb21dDQo+ID4gPj4+PiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDMsIDIwMTUgODozNiBB TQ0KPiA+ID4+Pj4gVG86IFRlbXBsaW4sIEZyZWQgTDsgU2F0b3J1IE1hdHN1c2hpbWENCj4gPiA+ Pj4+IENjOiBkbW0NCj4gPiA+Pj4+IFN1YmplY3Q6IFJlOiBbRE1NXSB2ZXBjIGRyYWZ0IFJldi4g MDQgLSAvNjJzIHRvIFVFLCBub3QgLzY0cw0KPiA+ID4+Pj4NCj4gPiA+Pj4+IExlIDI5LzA1LzIw MTUgMjA6MjEsIFRlbXBsaW4sIEZyZWQgTCBhIMOpY3JpdCA6DQo+ID4gPj4+Pj4gSGkgQWxleCwN Cj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+ Pj4+PiBGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEFsZXhhbmRydQ0KPiA+ID4+Pj4+PiBQZXRyZXNjdQ0KPiA+ID4+Pj4+PiBTZW50OiBGcmlkYXks IE1heSAyOSwgMjAxNSAxMDo1OSBBTQ0KPiA+ID4+Pj4+PiBUbzogU2F0b3J1IE1hdHN1c2hpbWEN Cj4gPiA+Pj4+Pj4gQ2M6IGRtbQ0KPiA+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW0RNTV0gdmVwYyBk cmFmdCBSZXYuIDA0IC0gLzYycyB0byBVRSwgbm90IC82NHMNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+ Pj4gTGUgMjkvMDUvMjAxNSAxNTozMCwgU2F0b3J1IE1hdHN1c2hpbWEgYSDDqWNyaXQgOg0KPiA+ ID4+Pj4+Pj4gQWggT0suIHRoYW5rcy4NCj4gPiA+Pj4+Pj4+IFNsaWdodGx5IG9mZi10b3BpYywg SSB0aGluayB0aGF0IHRoZXJlIGlzIHN0aWxsIGNoYW5jZSBmb3INCj4gPiA+Pj4+Pj4+IHRldGhl cmluZyB3aXRoIHNpbmdsZSAvNjQgaWYgaXQgaXMgYWxsb2NhdGVkIGFzIGEgb2ZmLWxpbmsgcHJl Zml4Lg0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBZZXMsIHRoZXJlIGlzIHN0aWxsIHN1Y2ggYSBj aGFuY2UuICBCdXQgaXQgY2FuIG5vdCB0ZXRoZXIgbW9yZQ0KPiA+ID4+Pj4+PiB0aGFuIG9uZSBz aW5nbGUgc3VibmV0LiAgQ29ubmVjdGVkIHZlaGljbGVzIG5lZWQgc2V2ZXJhbCBzdWJuZXRzLg0K PiA+ID4+Pj4+DQo+ID4gPj4+Pj4gSG93IHdvdWxkIGl0IGJlIGlmIHRoZSB2ZWhpY2xlIHJlY2Vp dmVkIGEgc2luZ2xlIHByZWZpeCwgYnV0IGl0DQo+ID4gPj4+Pj4gY291bGQgYmUgc2hvcnRlciB0 aGFuIC82NCAoZS5nLiwgLzU2LCAvNDguIGV0Yy4pPyBXb3VsZCB0aGUNCj4gPiA+Pj4+PiB2ZWhp Y2xlIHN1Ym5ldHRpbmcgYmUgc2F0aXNmaWVkIGlmIGl0IHJlY2VpdmVkIGEgc2hvcnRlciBwcmVm aXgNCj4gPiA+Pj4+PiBmcm9tIHdoaWNoIG1hbnkgLzY0cyBjb3VsZCBiZSBhbGxvY2F0ZWQ/DQo+ ID4gPj4+Pg0KPiA+ID4+Pj4gQ2VydGFpbmx5IHllcy4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBFYWNo IHZlaGljbGUgbmVlZHMgc3VjaCBhIHNob3J0ZXItdGhhbi02NCBwcmVmaXggYWxsb2NhdGVkIHRv IGl0Lg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IEZvciBleGFtcGxlLCBhbiBhdXRvbW9iaWxlIGNvbm5l Y3RpbmcgdG8gTFRFIHJlY2VpdmVzIGEgLzYyIGZyb20NCj4gPiA+Pj4+IHRoZSBvcGVyYXRvciBh bmQgbWFrZXMgZm91ciAvNjRzIG91dCBvZiBpdDogb25lIGZvciBpdHMNCj4gPiA+Pj4+IENBTi1l bnRlcnRhaW5tZW50LCBvbmUgZm9yIGl0cyBDQU4tc2FmZXR5LCBvbmUgZm9yIGl0cyBXaUZpIGFu ZCBvbmUgZm9yIGl0cw0KPiA+IEJsdWV0b290aC4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBUaGlzIGlz IGEgTVVTVC4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBBbGxvY2F0aW5nIGEgc2luZ2xlIC82NCB0byBh IHZlaGljbGUgY2FuIG5vdCBhY2NvbW1vZGF0ZSBhbGwgdGhlc2UNCj4gPiA+Pj4+IHVuYnJpZGdl YWJsZSBzdWJuZXRzLg0KPiA+ID4+Pg0KPiA+ID4+PiBPSywgdGhhdCBpcyBnb29kLiBHaXZpbmcg YSBtb2JpbGUgcm91dGVyIHNvbWV0aGluZyBzaG9ydGVyIHRoYW4gLzY0DQo+ID4gPj4+IHNob3Vs ZCBiZSBubyBwcm9ibGVtLCBhdCBsZWFzdCB1cCB0byBwcmFjdGljYWwgbGltaXRhdGlvbnMgb2Yg dGhlDQo+ID4gPj4+IHByZWZpeCBkZWxlZ2F0aW9uIGF1dGhvcml0eSdzIGF2YWlsYWJsZSBwcmVm aXggc3BhY2UuIERIQ1B2NiBQRA0KPiA+ID4+PiBwcm92aWRlcyBhbGwgdGhhdCBpcyBuZWVkZWQg dG8gZ2l2ZSBvdXQgcmlnaHQtc2l6ZWQgcHJlZml4ZXMuDQo+ID4gPj4NCj4gPiA+PiBJIGFncmVl IERIQ1AtUEQgcHJvdmlkZXMgdGhlIG5lY2Vzc2FyeSB0b29sLiAgQnV0IHVuZm9ydHVuYXRlbHkg dGhlDQo+ID4gPj4gY2VsbHVsYXIgb3BlcmF0b3JzIGhhdmUgbm90IGRlcGxveWVkIERIQ1B2Ni1Q RCAoYWx0aG91Z2ggeWVzIHRoZXJlIGlzDQo+ID4gPj4gc29tZSBESENQLW5vbi1QRCBpbiBzb21l IElQdjYvNEcgZGVwbG95bWVudHMpLg0KPiA+ID4+DQo+ID4gPj4gVGhlIGNvbW1vbiB0aGlua2lu ZyBhdCBvcGVyYXRvcnMgYW5kIGFkdmlzZXJzIGlzIHN0aWxsIHRoYXQgYSAvNjQNCj4gPiA+PiBz aG91bGQgYmUgZ2l2ZW4gdG8gYW4gVXNlciBFcXVpcG1lbnQuDQo+ID4gPj4NCj4gPiA+PiBUaGlz IG11c3QgY2hhbmdlOiB0aGUgM0dQUCBzcGVjcyBhbmQgb3BlcmF0b3IgZGVwbG95bWVudHMgbXVz dCBnaXZlDQo+ID4gPj4gLzYyIHRvIFVFcywgYW5kIG5vdCAvNjQuDQo+ID4gPg0KPiA+ID4gSSB0 aGluayB3ZSBhcmUgbm90IGluIHRoZSBwb3NpdGlvbiB0byBmb3JjZSBvcGVyYXRvcnMgb3IgM0dQ UCB0byBkbw0KPiA+ID4gYW55dGhpbmcsIHVuZm9ydHVuYXRlbHkuIFRoZSBiZXN0IHdlIGNhbiBk byBpcyB0byBtYWtlIHN1cmUgdGhlDQo+ID4gPiBwcm90b2NvbHMgd2Ugd29yayBoZXJlIGluIElF VEYgYXJlIG5vdCBwcm9oaWJpdGluZyBiZXR0ZXIgZGVwbG95bWVudHMNCj4gPiA+IChzZWUgZS5n LiBSRkM2NjAzIGVmZm9ydCkuIDNHUFAgc3BlY3MgYXJlIG5vdCB0aGUgc2hvdyBzdG9wcGVycyBo ZXJlLg0KPiA+ID4NCj4gPiA+IEkga25vdyB0aGlzIGlzIGZydXN0cmF0aW5nLiBGb3IgZXhhbXBs ZSBzb21lIG9wZXJhdG9ycyBJIGtub3cgb2ZmZXINCj4gPiA+IElQdjYgUEQgb24gdGhlaXIgZml4 ZWQgc2lkZSBvZiBidXNpbmVzcyBidXQgaGF2ZSBubyBwbGFucyBmb3Igc2ltaWxhcg0KPiA+ID4g b24gdGhlIGNlbGx1bGFyIHNpZGUuLiByZWFzb25zIGFyZSBtYW55LiBJIGFzc3VtZSB0aGF0IGlk ZW50b2Z5aW5nIGENCj4gPiA+IHN0cm9uZyBlbm91Z2ggdXNlIGNhc2Ugd291bGQgYmUgdGhlIGtl eS4NCj4gPg0KPiA+IEkgd291bGQgbGlrZSB0byBkaXNjdXNzIHRoZXNlIHVzZSBjYXNlcy4NCj4g Pg0KPiA+IFVzZSBjYXNlcyBvZiBncm91cGluZyBkZXZpY2VzIHVuZGVyIGEgdW5pcXVlIGNlbGx1 bGFyIGNvbm5lY3Rpb24gYXJlIHZlcnkNCj4gPiBudW1lcm91czogSVB2NiBhdXRvbW9iaWxlcywg SVB2NiB0ZXRoZXJpbmcgc21hcnRwaG9uZXMsIElQdjYgVGhpbmdzIG9uDQo+ID4gUGVyc29uYWwg QXJlYSBOZXR3b3Jrcy4NCg0KWWVzLCB5ZXMgYW5kIHllcy4gQWxzbyBJUHY2IGFpcnBsYW5lcy4N Cg0KPiA+IEFsbCB0aGVzZSBkZXZpY2VzIG5lZWQgdGhlIGNlbGx1bGFyIG9wZXJhdG9yIHRvIGRl bGl2ZXIgc2hvcnRlci10aGFuLTY0IHByZWZpeGVzDQo+ID4gdG8gYSBTSU0gY29ubmVjdGlvbi4N Cj4gDQo+IEZvciBsYWNrIG9mIGEgYmV0dGVyIGRlc2NyaXB0aW9uLCB0aGUgY2VsbHVsYXIgc2lk ZSBvZiBidXNpbmVzc2VzIHN1ZmZlciBmcm9tICJiZWxsIGhlYWQ6IiB0aGlua2luZywgd2hlcmUg dGhlIFVFIGlzIGFuIGFwcGxpY2F0aW9uDQo+IGVuZHBvaW50LiBOb3RoaW5nIG1vcmUgb2NjdXJz IHRvIHRoZW0sIGJlY2F1c2UgdGhhdCBpcyB0aGUgcHJvZHVjdCB0aGV5IGhhdmUgYWx3YXlzIHN1 cHBvcnRlZC4gQSByb3V0aW5nIGZ1bmN0aW9uIGltcGxpZXMgaGlnaGVyDQo+IGFnZ3JlZ2F0ZSBk YXRhIHJhdGVzIHRoYW4gdGhleSBoYXZlIGJ1aWx0IHRoZSBzeXN0ZW0gdG8gaGFuZGxlLiBJIGhh dmUgYmVlbiBpbiBmcm9udCBvZiBtYW55IG9mIHRoZW0gaG9sZGluZyB1cCBVRSBhbmQgc2F5aW5n LCAidGhpcyBpcw0KPiBhIFJPVVRFUiwgZ2V0IG92ZXIgaXQiLCBhbmQgZ290IG5vdGhpbmcgYnV0 IGJsYW5rIHN0YXJlcyBiYWNrLg0KDQpJbmRlZWQuIEJ1dCwgdGhpcyBpcyB0aGUgb25nb2luZyBk aWFsb2d1ZSB0aGF0IHdlIG5lZWQgdG8gY29udGludWUgbm8NCm1hdHRlciBob3cgbWFueSBibGFu ayBzdGFyZXMgd2UgZ2V0Lg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2Vpbmcu Y29tDQoNCj4gVGhlIGZpcnN0IHVzZSBjYXNlIG9uIHRoZSBsaXN0IHNob3VsZCBiZSBhIHdpcmVs aW5lIGFsdGVybmF0aXZlL2JhY2t1cCBsaW5rIGZvciBjb25zdW1lciBDUEUgcm91dGVycywgYW5k IGhvbWUgY29udHJvbCBvciBzZWN1cml0eQ0KPiBzeXN0ZW1zLiBUaGF0IGlzIHNpbXBsZXIgdG8g c3VwcG9ydCBiZWNhdXNlIHRoZSBVRSBkb2Vzbid0IG1vdmUgYXJvdW5kLCBzbyB0aGV5IGNhbiBz Y2FsZSB0aGUgaW5mcmFzdHJ1Y3R1cmUgdG8gYWxpZ24gd2l0aCBkZW1hbmQNCj4gd2l0aG91dCB0 b28gbXVjaCBjb25jZXJuIGFib3V0IHRoYXQgc2hpZnRpbmcgcXVpY2tseS4gT25jZSB0aGUgZmVh ciBvZiBkb3duc3RyZWFtIHN1Ym5ldHMgaXMgcmVtb3ZlZCwgd29ya2luZyBvbiB0aGUgdHJ1bHkg bW9iaWxlDQo+IHVzZSBjYXNlcyB3aWxsIGJlIGFuIGVhc2llciBtZW50YWwgaHVyZGxlIHRvIG92 ZXJjb21lLg0KPiANCj4gVG9ueQ0KPiANCj4gLi4uLi4uLi4uLi4NCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRtbSBtYWlsaW5nIGxpc3QN Cj4gZG1tQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG1tDQo= From nobody Thu Jun 11 12:21:59 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFA41B2D5F for ; Thu, 11 Jun 2015 12:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufNuxTnQvKOc for ; Thu, 11 Jun 2015 12:21:56 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 4E1281B2D1B for ; Thu, 11 Jun 2015 12:21:53 -0700 (PDT) Received: by ykfr66 with SMTP id r66so7115336ykf.0 for ; Thu, 11 Jun 2015 12:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ah+fuj/JNYD+Zd5Kx3HXwrf4dvIOXUqG947qbFDZ+wQ=; b=yVD/lEN4k2VtTz2hZ7QB8BL/+6iTqT0QxYFkSw3Wf/+rxSTntwfD5Txhhg7Xb/50MM RmE6iAvEXfgn6MKrtSAUGtQoc+a7krC3TRTojRs14zflKqslegRohjBujvoYC89D/Ykt 1efnq8ulDKsZxsRai7MzUg7HIP/86BayQQuu8f+K6nHPCJYKdTk0M7iMJP5X5wiDv2zA RdvYaKpZoYiVXPVPB4Qu/oU8GCaKzBlNZv3/cJjpMApXU1bgoX6Awu2uhHDZIAkkyYM+ K9trAh/LigZNvU4sR3tyNk28ubN+l3akMxuGUonGtIFKPqnEhFEcoV5RzTiiowXIbe8N j0aQ== MIME-Version: 1.0 X-Received: by 10.170.51.209 with SMTP id 200mr14106364ykt.77.1434050512659; Thu, 11 Jun 2015 12:21:52 -0700 (PDT) Received: by 10.13.212.131 with HTTP; Thu, 11 Jun 2015 12:21:52 -0700 (PDT) In-Reply-To: <123c01d0a466$3a94e3c0$afbeab40$@tndh.net> References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <5579B120.1020806@gmail.com> <5579B510.9020909@gmail.com> <123c01d0a466$3a94e3c0$afbeab40$@tndh.net> Date: Thu, 11 Jun 2015 12:21:52 -0700 Message-ID: From: jouni korhonen To: Tony Hain Content-Type: multipart/alternative; boundary=001a1137d56c65a988051842e7a8 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 19:21:57 -0000 --001a1137d56c65a988051842e7a8 Content-Type: text/plain; charset=UTF-8 For lack of a better description, the cellular side of businesses suffer > from "bell head:" thinking, where the UE is an application endpoint. > Nothing more occurs to them, because that is the product they have always > supported. A routing function implies higher aggregate data rates than they > have built the system to handle. I have been in front of many of them > holding up UE and saying, "this is a ROUTER, get over it", and got nothing > but blank stares back. > > The first use case on the list should be a wireline alternative/backup > link for consumer CPE routers, and home control or security systems. That > is simpler to support because the UE doesn't move around, so they can scale > the infrastructure to align with demand without too much concern about that > shifting quickly. Once the fear of downstream subnets is removed, working > on the truly mobile use cases will be an easier mental hurdle to overcome. > Amen. I know that such backup solutions with routed IPv4 networks were done for enterprise access (not a standard but easily doable). > > Tony > > ........... > > --001a1137d56c65a988051842e7a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


For lack of a better description, the ce= llular side of businesses suffer from "bell head:" thinking, wher= e the UE is an application endpoint. Nothing more occurs to them, because t= hat is the product they have always supported. A routing function implies h= igher aggregate data rates than they have built the system to handle. I hav= e been in front of many of them holding up UE and saying, "this is a R= OUTER, get over it", and got nothing but blank stares back.

The first use case on the list should be a wireline alternative/backup link= for consumer CPE routers, and home control or security systems. That is si= mpler to support because the UE doesn't move around, so they can scale = the infrastructure to align with demand without too much concern about that= shifting quickly. Once the fear of downstream subnets is removed, working = on the truly mobile use cases will be an easier mental hurdle to overcome.<= br>

Amen.

I know that suc= h backup solutions with routed IPv4 networks were done for enterprise acces= s (not a standard but easily doable).
=C2=A0

Tony

...........


--001a1137d56c65a988051842e7a8-- From nobody Fri Jun 12 06:02:32 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE511A8BB5 for ; Fri, 12 Jun 2015 06:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REvluo3LHaVa for ; Fri, 12 Jun 2015 06:02:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5867F1A9060 for ; Fri, 12 Jun 2015 06:02:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5CD2PDt019707 for ; Fri, 12 Jun 2015 15:02:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6F6302060DF for ; Fri, 12 Jun 2015 15:05:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 65AD820535C for ; Fri, 12 Jun 2015 15:05:03 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5CD2KMQ022420 for ; Fri, 12 Jun 2015 15:02:24 +0200 Message-ID: <557AD85C.3080603@gmail.com> Date: Fri, 12 Jun 2015 15:02:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dmm@ietf.org References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <5579B120.1020806@gmail.com> <5579B510.9020909@gmail.com> In-Reply-To: <5579B510.9020909@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 13:02:30 -0000 I was asked in private about this "SIM connection", I clarify below. Le 11/06/2015 18:19, Alexandru Petrescu a écrit : > > > Le 11/06/2015 18:02, Jouni Korhonen a écrit : >> >> >> 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: >>> Le 04/06/2015 05:42, Templin, Fred L a écrit : >>>> Hi Alex, >>>> >>>>> -----Original Message----- >>>>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>>>> Sent: Wednesday, June 03, 2015 8:36 AM >>>>> To: Templin, Fred L; Satoru Matsushima >>>>> Cc: dmm >>>>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >>>>> >>>>> Le 29/05/2015 20:21, Templin, Fred L a écrit : >>>>>> Hi Alex, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru >>>>>>> Petrescu >>>>>>> Sent: Friday, May 29, 2015 10:59 AM >>>>>>> To: Satoru Matsushima >>>>>>> Cc: dmm >>>>>>> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >>>>>>> >>>>>>> Le 29/05/2015 15:30, Satoru Matsushima a écrit : >>>>>>>> Ah OK. thanks. >>>>>>>> Slightly off-topic, I think that there is still chance for >>>>>>>> tethering >>>>>>>> with single /64 if it is allocated as a off-link prefix. >>>>>>> >>>>>>> Yes, there is still such a chance. But it can not tether more than >>>>>>> one >>>>>>> single subnet. Connected vehicles need several subnets. >>>>>> >>>>>> How would it be if the vehicle received a single prefix, but it >>>>>> could be >>>>>> shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting >>>>>> be satisfied if it received a shorter prefix from which many /64s >>>>>> could be allocated? >>>>> >>>>> Certainly yes. >>>>> >>>>> Each vehicle needs such a shorter-than-64 prefix allocated to it. >>>>> >>>>> For example, an automobile connecting to LTE receives a /62 from the >>>>> operator and makes four /64s out of it: one for its CAN-entertainment, >>>>> one for its CAN-safety, one for its WiFi and one for its Bluetooth. >>>>> >>>>> This is a MUST. >>>>> >>>>> Allocating a single /64 to a vehicle can not accommodate all these >>>>> unbridgeable subnets. >>>> >>>> OK, that is good. Giving a mobile router something shorter than /64 >>>> should be no problem, at least up to practical limitations of the >>>> prefix >>>> delegation authority's available prefix space. DHCPv6 PD provides all >>>> that is needed to give out right-sized prefixes. >>> >>> I agree DHCP-PD provides the necessary tool. But unfortunately the >>> cellular operators have not deployed DHCPv6-PD (although yes there is >>> some DHCP-non-PD in some IPv6/4G deployments). >>> >>> The common thinking at operators and advisers is still that a /64 should >>> be given to an User Equipment. >>> >>> This must change: the 3GPP specs and operator deployments must give /62 >>> to UEs, and not /64. >> >> I think we are not in the position to force operators or 3GPP to do >> anything, unfortunately. The best we can do is to make sure the >> protocols we work here in IETF are not prohibiting better deployments >> (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. >> >> I know this is frustrating. For example some operators I know offer IPv6 >> PD on their fixed side of business but have no plans for similar on the >> cellular side.. reasons are many. I assume that identofying a strong >> enough use case would be the key. > > I would like to discuss these use cases. > > Use cases of grouping devices under a unique cellular connection are > very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things > on Personal Area Networks. > > All these devices need the cellular operator to deliver shorter-than-64 > prefixes to a SIM connection. I meant to say a device holding a single SIM card should be able to get a shorter-than-64 prefix from the cellular operator. This is to distinguish from computers featuring multiple SIM cards, or automobiles featuring multiple SIMs (car's SIM, passengers' SIMs). SIM stands for Subscriber Identification Module. Alex > > Alex > >> >> - Jouni >> >> >> >>> >>> Alex >>> >>>> >>>> Thanks - Fred >>>> fred.l.templin@boeing.com >>>> >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Thanks - Fred >>>>>> fred.l.templin@boeing.com >>>>>> >>>>>> >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> >>>>>>>> But yes, I agree with you. >>>>>>>> >>>>>>>> cheers, >>>>>>>> --satoru >>>>>>>> >>>>>>>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> In addition to what Behcet says. >>>>>>>> >>>>>>>> I read the example below. I think it is just an example, >>>>>>>> but just >>>>>>>> to make sure. >>>>>>>> >>>>>>>> Please - do not allocate /64s to end users in a cellular >>>>>>>> network. >>>>>>>> Allocate at least /62s to end users. >>>>>>>> >>>>>>>> This is to allow the smartphone to perform tethering (small >>>>>>>> network >>>>>>>> of wifi devices connecting through the smartphone to the >>>>>>>> Internet). >>>>>>>> >>>>>>>> The assumption of /64 to end user is not good at all. >>>>>>>> >>>>>>>> (and yes, I agree that these /62s may be aggregated into a >>>>>>>> larger >>>>>>>> prefix and advertised upstream as a single prefix instead of >>>>>>>> multiple host-based routes). >>>>>>>> >>>>>>>> Yours, >>>>>>>> >>>>>>>> Alex Petrescu >>>>>>>> >>>>>>>> Le 26/05/2015 22:34, Behcet Sarikaya a écrit : >>>>>>>> >>>>>>>> Hi Satoru, >>>>>>>> >>>>>>>> Thanks for your reply. >>>>>>>> >>>>>>>> Let me continue the discussion with your text in Section >>>>>>>> 3.2 >>>>>>>> where you mention >>>>>>>> vEPC may utilizes Forwarding Policy Configuration >>>>>>>> Protocol (FPCP) >>>>>>>> that defines FPCP Agent function and Client function. >>>>>>>> >>>>>>>> I don't understand how you could justify defining a new >>>>>>>> forwarding >>>>>>>> policy configuration protocol to do this Agent/Client >>>>>>>> functionality? >>>>>>>> Why not use similar Agent/Client models that are being >>>>>>>> defined >>>>>>>> rather >>>>>>>> than defining a new protocol? >>>>>>>> I think this point requires much stronger justification >>>>>>>> which I >>>>>>>> could >>>>>>>> not see in Section 3.2. >>>>>>>> >>>>>>>> Are you that we have to to reinvent the wheel, rather >>>>>>>> than reusing >>>>>>>> something that is already available? How are we going to >>>>>>>> reinvent that >>>>>>>> wheel also remains to be seen, I think. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Behcet >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Bechet-san, >>>>>>>> >>>>>>>> Thank you for your question. >>>>>>>> In step (15), I meant that EPC-E advertises prefix >>>>>>>> including >>>>>>>> UE assigned >>>>>>>> prefixes. >>>>>>>> >>>>>>>> For example, in the case of /64 prefixes assigned to >>>>>>>> UEs >>>>>>>> from a /56 space, >>>>>>>> that /56 >>>>>>>> is advertised by EPC-E to upstream routers. So the >>>>>>>> advertised route isn't >>>>>>>> host routes. >>>>>>>> >>>>>>>> Depends on configuration policy, but one case is >>>>>>>> that the >>>>>>>> source of that >>>>>>>> advertised >>>>>>>> /56 route might be statically configured in EPC-E. >>>>>>>> >>>>>>>> Regards, >>>>>>>> --satoru >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya >>>>>>>> >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Matsushima-san, >>>>>>>> >>>>>>>> I have a question on your draft: >>>>>>>> In Sec. 3.2, page 11, you say >>>>>>>> In step (15), the EPC-E advertises routes to >>>>>>>> upstream >>>>>>>> routers ... >>>>>>>> >>>>>>>> Are these routes static/host routes? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Behcet >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dmm mailing list >>>>>>>> dmm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dmm mailing list >>>>>>>> dmm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri Jun 12 06:03:35 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C711A908E for ; Fri, 12 Jun 2015 06:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf7csMWFqJQJ for ; Fri, 12 Jun 2015 06:03:31 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1798F1A8BB5 for ; Fri, 12 Jun 2015 06:03:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5CD3OTU021829; Fri, 12 Jun 2015 15:03:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C93B3206102; Fri, 12 Jun 2015 15:06:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B75FD20535C; Fri, 12 Jun 2015 15:06:03 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5CD3OZH023584; Fri, 12 Jun 2015 15:03:25 +0200 Message-ID: <557AD89C.9080809@gmail.com> Date: Fri, 12 Jun 2015 15:03:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Templin, Fred L" , Tony Hain , "'Jouni Korhonen'" , "dmm@ietf.org" References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <5579B120.1020806@gmail.com> <5579B510.9020909@gmail.com> <123c01d0a466$3a94e3c0$afbeab40$@tndh.net> <2134F8430051B64F815C691A62D9831832E8A2EF@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E8A2EF@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 13:03:33 -0000 Le 11/06/2015 18:53, Templin, Fred L a écrit : > Responding to two in one: > >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] >> On Behalf Of Tony Hain Sent: Thursday, June 11, 2015 9:47 AM To: >> 'Alexandru Petrescu'; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: >> [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >> >> Alexandru Petrescu wrote: >>> Le 11/06/2015 18:02, Jouni Korhonen a écrit : >>>> >>>> >>>> 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: >>>>> Le 04/06/2015 05:42, Templin, Fred L a écrit : >>>>>> Hi Alex, >>>>>> >>>>>>> -----Original Message----- From: Alexandru Petrescu >>>>>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, >>>>>>> June 03, 2015 8:36 AM To: Templin, Fred L; Satoru >>>>>>> Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 >>>>>>> - /62s to UE, not /64s >>>>>>> >>>>>>> Le 29/05/2015 20:21, Templin, Fred L a écrit : >>>>>>>> Hi Alex, >>>>>>>> >>>>>>>>> -----Original Message----- From: dmm >>>>>>>>> [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru >>>>>>>>> Petrescu Sent: Friday, May 29, 2015 10:59 AM To: >>>>>>>>> Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc >>>>>>>>> draft Rev. 04 - /62s to UE, not /64s >>>>>>>>> >>>>>>>>> Le 29/05/2015 15:30, Satoru Matsushima a écrit : >>>>>>>>>> Ah OK. thanks. Slightly off-topic, I think that >>>>>>>>>> there is still chance for tethering with single /64 >>>>>>>>>> if it is allocated as a off-link prefix. >>>>>>>>> >>>>>>>>> Yes, there is still such a chance. But it can not >>>>>>>>> tether more than one single subnet. Connected >>>>>>>>> vehicles need several subnets. >>>>>>>> >>>>>>>> How would it be if the vehicle received a single >>>>>>>> prefix, but it could be shorter than /64 (e.g., /56, >>>>>>>> /48. etc.)? Would the vehicle subnetting be satisfied >>>>>>>> if it received a shorter prefix from which many /64s >>>>>>>> could be allocated? >>>>>>> >>>>>>> Certainly yes. >>>>>>> >>>>>>> Each vehicle needs such a shorter-than-64 prefix >>>>>>> allocated to it. >>>>>>> >>>>>>> For example, an automobile connecting to LTE receives a >>>>>>> /62 from the operator and makes four /64s out of it: one >>>>>>> for its CAN-entertainment, one for its CAN-safety, one >>>>>>> for its WiFi and one for its >>> Bluetooth. >>>>>>> >>>>>>> This is a MUST. >>>>>>> >>>>>>> Allocating a single /64 to a vehicle can not accommodate >>>>>>> all these unbridgeable subnets. >>>>>> >>>>>> OK, that is good. Giving a mobile router something shorter >>>>>> than /64 should be no problem, at least up to practical >>>>>> limitations of the prefix delegation authority's available >>>>>> prefix space. DHCPv6 PD provides all that is needed to give >>>>>> out right-sized prefixes. >>>>> >>>>> I agree DHCP-PD provides the necessary tool. But >>>>> unfortunately the cellular operators have not deployed >>>>> DHCPv6-PD (although yes there is some DHCP-non-PD in some >>>>> IPv6/4G deployments). >>>>> >>>>> The common thinking at operators and advisers is still that a >>>>> /64 should be given to an User Equipment. >>>>> >>>>> This must change: the 3GPP specs and operator deployments >>>>> must give /62 to UEs, and not /64. >>>> >>>> I think we are not in the position to force operators or 3GPP >>>> to do anything, unfortunately. The best we can do is to make >>>> sure the protocols we work here in IETF are not prohibiting >>>> better deployments (see e.g. RFC6603 effort). 3GPP specs are >>>> not the show stoppers here. >>>> >>>> I know this is frustrating. For example some operators I know >>>> offer IPv6 PD on their fixed side of business but have no plans >>>> for similar on the cellular side.. reasons are many. I assume >>>> that identofying a strong enough use case would be the key. >>> >>> I would like to discuss these use cases. >>> >>> Use cases of grouping devices under a unique cellular connection >>> are very numerous: IPv6 automobiles, IPv6 tethering smartphones, >>> IPv6 Things on Personal Area Networks. > > Yes, yes and yes. Also IPv6 airplanes. What is the use case when an airplane connects to a cellular operator? They are supposed to be on sattelite often, I guess. Alex > >>> All these devices need the cellular operator to deliver >>> shorter-than-64 prefixes to a SIM connection. >> >> For lack of a better description, the cellular side of businesses >> suffer from "bell head:" thinking, where the UE is an application >> endpoint. Nothing more occurs to them, because that is the product >> they have always supported. A routing function implies higher >> aggregate data rates than they have built the system to handle. I >> have been in front of many of them holding up UE and saying, "this >> is a ROUTER, get over it", and got nothing but blank stares back. > > Indeed. But, this is the ongoing dialogue that we need to continue > no matter how many blank stares we get. > > Thanks - Fred fred.l.templin@boeing.com > >> The first use case on the list should be a wireline >> alternative/backup link for consumer CPE routers, and home control >> or security systems. That is simpler to support because the UE >> doesn't move around, so they can scale the infrastructure to align >> with demand without too much concern about that shifting quickly. >> Once the fear of downstream subnets is removed, working on the >> truly mobile use cases will be an easier mental hurdle to >> overcome. >> >> Tony >> >> ........... >> >> _______________________________________________ dmm mailing list >> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From nobody Fri Jun 12 08:24:35 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358F1A00E7 for ; Fri, 12 Jun 2015 08:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qte-Tg1J-SCJ for ; Fri, 12 Jun 2015 08:24:31 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097731A0119 for ; Fri, 12 Jun 2015 08:24:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t5CFOTZK022199; Fri, 12 Jun 2015 10:24:29 -0500 Received: from XCH-PHX-311.sw.nos.boeing.com (xch-phx-311.sw.nos.boeing.com [130.247.25.171]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t5CFORaO022160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 12 Jun 2015 10:24:27 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-PHX-311.sw.nos.boeing.com ([169.254.11.82]) with mapi id 14.03.0235.001; Fri, 12 Jun 2015 08:24:26 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Tony Hain , "'Jouni Korhonen'" , "dmm@ietf.org" Thread-Topic: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Thread-Index: AQHQmjkkJI//M3dql0O3DI0sVGxmlwJC4/zOAcXevwMBlLT6GAGyvW7VASL5HjsCBLNn7wFqGnxOAZmpP6MBnx26TAIjGX1tAf2pTcCayOegEIJE1RJAgAHIWQD//7Fw4A== Date: Fri, 12 Jun 2015 15:24:25 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E8AF81@XCH-BLV-504.nw.nos.boeing.com> References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <5579B120.1020806@gmail.com> <5579B510.9020909@gmail.com> <123c01d0a466$3a94e3c0$afbeab40$@tndh.net> <2134F8430051B64F815C691A62D9831832E8A2EF@XCH-BLV-504.nw.nos.boeing.com> <557AD89C.9080809@gmail.com> In-Reply-To: <557AD89C.9080809@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 15:24:33 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cnUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBGcmlkYXksIEp1bmUgMTIsIDIwMTUgNjowMyBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMOyBU b255IEhhaW47ICdKb3VuaSBLb3Job25lbic7IGRtbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W0RNTV0gdmVwYyBkcmFmdCBSZXYuIDA0IC0gLzYycyB0byBVRSwgbm90IC82NHMNCj4gDQo+IA0K PiANCj4gTGUgMTEvMDYvMjAxNSAxODo1MywgVGVtcGxpbiwgRnJlZCBMIGEgw6ljcml0IDoNCj4g PiBSZXNwb25kaW5nIHRvIHR3byBpbiBvbmU6DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0gRnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddDQo+ID4+IE9u IEJlaGFsZiBPZiBUb255IEhhaW4gU2VudDogVGh1cnNkYXksIEp1bmUgMTEsIDIwMTUgOTo0NyBB TSBUbzoNCj4gPj4gJ0FsZXhhbmRydSBQZXRyZXNjdSc7ICdKb3VuaSBLb3Job25lbic7IGRtbUBp ZXRmLm9yZyBTdWJqZWN0OiBSZToNCj4gPj4gW0RNTV0gdmVwYyBkcmFmdCBSZXYuIDA0IC0gLzYy cyB0byBVRSwgbm90IC82NHMNCj4gPj4NCj4gPj4gQWxleGFuZHJ1IFBldHJlc2N1IHdyb3RlOg0K PiA+Pj4gTGUgMTEvMDYvMjAxNSAxODowMiwgSm91bmkgS29yaG9uZW4gYSDDqWNyaXQgOg0KPiA+ Pj4+DQo+ID4+Pj4NCj4gPj4+PiA2LzQvMjAxNSwgNzowOCBBTSwgQWxleGFuZHJ1IFBldHJlc2N1 IGtpcmpvaXR0aToNCj4gPj4+Pj4gTGUgMDQvMDYvMjAxNSAwNTo0MiwgVGVtcGxpbiwgRnJlZCBM IGEgw6ljcml0IDoNCj4gPj4+Pj4+IEhpIEFsZXgsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEFsZXhhbmRydSBQZXRyZXNjdQ0KPiA+Pj4+Pj4+ IFttYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbV0gU2VudDogV2VkbmVzZGF5LA0K PiA+Pj4+Pj4+IEp1bmUgMDMsIDIwMTUgODozNiBBTSBUbzogVGVtcGxpbiwgRnJlZCBMOyBTYXRv cnUNCj4gPj4+Pj4+PiBNYXRzdXNoaW1hIENjOiBkbW0gU3ViamVjdDogUmU6IFtETU1dIHZlcGMg ZHJhZnQgUmV2LiAwNA0KPiA+Pj4+Pj4+IC0gLzYycyB0byBVRSwgbm90IC82NHMNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IExlIDI5LzA1LzIwMTUgMjA6MjEsIFRlbXBsaW4sIEZyZWQgTCBhIMOpY3Jp dCA6DQo+ID4+Pj4+Pj4+IEhpIEFsZXgsDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBkbW0NCj4gPj4+Pj4+Pj4+IFttYWlsdG86ZG1tLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcnUNCj4gPj4+Pj4+Pj4+IFBldHJl c2N1IFNlbnQ6IEZyaWRheSwgTWF5IDI5LCAyMDE1IDEwOjU5IEFNIFRvOg0KPiA+Pj4+Pj4+Pj4g U2F0b3J1IE1hdHN1c2hpbWEgQ2M6IGRtbSBTdWJqZWN0OiBSZTogW0RNTV0gdmVwYw0KPiA+Pj4+ Pj4+Pj4gZHJhZnQgUmV2LiAwNCAtIC82MnMgdG8gVUUsIG5vdCAvNjRzDQo+ID4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4gTGUgMjkvMDUvMjAxNSAxNTozMCwgU2F0b3J1IE1hdHN1c2hpbWEgYSDDqWNy aXQgOg0KPiA+Pj4+Pj4+Pj4+IEFoIE9LLiB0aGFua3MuIFNsaWdodGx5IG9mZi10b3BpYywgSSB0 aGluayB0aGF0DQo+ID4+Pj4+Pj4+Pj4gdGhlcmUgaXMgc3RpbGwgY2hhbmNlIGZvciB0ZXRoZXJp bmcgd2l0aCBzaW5nbGUgLzY0DQo+ID4+Pj4+Pj4+Pj4gaWYgaXQgaXMgYWxsb2NhdGVkIGFzIGEg b2ZmLWxpbmsgcHJlZml4Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFllcywgdGhlcmUgaXMg c3RpbGwgc3VjaCBhIGNoYW5jZS4gIEJ1dCBpdCBjYW4gbm90DQo+ID4+Pj4+Pj4+PiB0ZXRoZXIg bW9yZSB0aGFuIG9uZSBzaW5nbGUgc3VibmV0LiAgQ29ubmVjdGVkDQo+ID4+Pj4+Pj4+PiB2ZWhp Y2xlcyBuZWVkIHNldmVyYWwgc3VibmV0cy4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gSG93IHdv dWxkIGl0IGJlIGlmIHRoZSB2ZWhpY2xlIHJlY2VpdmVkIGEgc2luZ2xlDQo+ID4+Pj4+Pj4+IHBy ZWZpeCwgYnV0IGl0IGNvdWxkIGJlIHNob3J0ZXIgdGhhbiAvNjQgKGUuZy4sIC81NiwNCj4gPj4+ Pj4+Pj4gLzQ4LiBldGMuKT8gV291bGQgdGhlIHZlaGljbGUgc3VibmV0dGluZyBiZSBzYXRpc2Zp ZWQNCj4gPj4+Pj4+Pj4gaWYgaXQgcmVjZWl2ZWQgYSBzaG9ydGVyIHByZWZpeCBmcm9tIHdoaWNo IG1hbnkgLzY0cw0KPiA+Pj4+Pj4+PiBjb3VsZCBiZSBhbGxvY2F0ZWQ/DQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PiBDZXJ0YWlubHkgeWVzLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gRWFjaCB2ZWhpY2xl IG5lZWRzIHN1Y2ggYSBzaG9ydGVyLXRoYW4tNjQgcHJlZml4DQo+ID4+Pj4+Pj4gYWxsb2NhdGVk IHRvIGl0Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gRm9yIGV4YW1wbGUsIGFuIGF1dG9tb2JpbGUg Y29ubmVjdGluZyB0byBMVEUgcmVjZWl2ZXMgYQ0KPiA+Pj4+Pj4+IC82MiBmcm9tIHRoZSBvcGVy YXRvciBhbmQgbWFrZXMgZm91ciAvNjRzIG91dCBvZiBpdDogb25lDQo+ID4+Pj4+Pj4gZm9yIGl0 cyBDQU4tZW50ZXJ0YWlubWVudCwgb25lIGZvciBpdHMgQ0FOLXNhZmV0eSwgb25lDQo+ID4+Pj4+ Pj4gZm9yIGl0cyBXaUZpIGFuZCBvbmUgZm9yIGl0cw0KPiA+Pj4gQmx1ZXRvb3RoLg0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4gVGhpcyBpcyBhIE1VU1QuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBBbGxv Y2F0aW5nIGEgc2luZ2xlIC82NCB0byBhIHZlaGljbGUgY2FuIG5vdCBhY2NvbW1vZGF0ZQ0KPiA+ Pj4+Pj4+IGFsbCB0aGVzZSB1bmJyaWRnZWFibGUgc3VibmV0cy4NCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBPSywgdGhhdCBpcyBnb29kLiBHaXZpbmcgYSBtb2JpbGUgcm91dGVyIHNvbWV0aGluZyBzaG9y dGVyDQo+ID4+Pj4+PiB0aGFuIC82NCBzaG91bGQgYmUgbm8gcHJvYmxlbSwgYXQgbGVhc3QgdXAg dG8gcHJhY3RpY2FsDQo+ID4+Pj4+PiBsaW1pdGF0aW9ucyBvZiB0aGUgcHJlZml4IGRlbGVnYXRp b24gYXV0aG9yaXR5J3MgYXZhaWxhYmxlDQo+ID4+Pj4+PiBwcmVmaXggc3BhY2UuIERIQ1B2NiBQ RCBwcm92aWRlcyBhbGwgdGhhdCBpcyBuZWVkZWQgdG8gZ2l2ZQ0KPiA+Pj4+Pj4gb3V0IHJpZ2h0 LXNpemVkIHByZWZpeGVzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIGFncmVlIERIQ1AtUEQgcHJvdmlk ZXMgdGhlIG5lY2Vzc2FyeSB0b29sLiAgQnV0DQo+ID4+Pj4+IHVuZm9ydHVuYXRlbHkgdGhlIGNl bGx1bGFyIG9wZXJhdG9ycyBoYXZlIG5vdCBkZXBsb3llZA0KPiA+Pj4+PiBESENQdjYtUEQgKGFs dGhvdWdoIHllcyB0aGVyZSBpcyBzb21lIERIQ1Atbm9uLVBEIGluIHNvbWUNCj4gPj4+Pj4gSVB2 Ni80RyBkZXBsb3ltZW50cykuDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZSBjb21tb24gdGhpbmtpbmcg YXQgb3BlcmF0b3JzIGFuZCBhZHZpc2VycyBpcyBzdGlsbCB0aGF0IGENCj4gPj4+Pj4gLzY0IHNo b3VsZCBiZSBnaXZlbiB0byBhbiBVc2VyIEVxdWlwbWVudC4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhp cyBtdXN0IGNoYW5nZTogdGhlIDNHUFAgc3BlY3MgYW5kIG9wZXJhdG9yIGRlcGxveW1lbnRzDQo+ ID4+Pj4+IG11c3QgZ2l2ZSAvNjIgdG8gVUVzLCBhbmQgbm90IC82NC4NCj4gPj4+Pg0KPiA+Pj4+ IEkgdGhpbmsgd2UgYXJlIG5vdCBpbiB0aGUgcG9zaXRpb24gdG8gZm9yY2Ugb3BlcmF0b3JzIG9y IDNHUFANCj4gPj4+PiB0byBkbyBhbnl0aGluZywgdW5mb3J0dW5hdGVseS4gVGhlIGJlc3Qgd2Ug Y2FuIGRvIGlzIHRvIG1ha2UNCj4gPj4+PiBzdXJlIHRoZSBwcm90b2NvbHMgd2Ugd29yayBoZXJl IGluIElFVEYgYXJlIG5vdCBwcm9oaWJpdGluZw0KPiA+Pj4+IGJldHRlciBkZXBsb3ltZW50cyAo c2VlIGUuZy4gUkZDNjYwMyBlZmZvcnQpLiAzR1BQIHNwZWNzIGFyZQ0KPiA+Pj4+IG5vdCB0aGUg c2hvdyBzdG9wcGVycyBoZXJlLg0KPiA+Pj4+DQo+ID4+Pj4gSSBrbm93IHRoaXMgaXMgZnJ1c3Ry YXRpbmcuIEZvciBleGFtcGxlIHNvbWUgb3BlcmF0b3JzIEkga25vdw0KPiA+Pj4+IG9mZmVyIElQ djYgUEQgb24gdGhlaXIgZml4ZWQgc2lkZSBvZiBidXNpbmVzcyBidXQgaGF2ZSBubyBwbGFucw0K PiA+Pj4+IGZvciBzaW1pbGFyIG9uIHRoZSBjZWxsdWxhciBzaWRlLi4gcmVhc29ucyBhcmUgbWFu eS4gSSBhc3N1bWUNCj4gPj4+PiB0aGF0IGlkZW50b2Z5aW5nIGEgc3Ryb25nIGVub3VnaCB1c2Ug Y2FzZSB3b3VsZCBiZSB0aGUga2V5Lg0KPiA+Pj4NCj4gPj4+IEkgd291bGQgbGlrZSB0byBkaXNj dXNzIHRoZXNlIHVzZSBjYXNlcy4NCj4gPj4+DQo+ID4+PiBVc2UgY2FzZXMgb2YgZ3JvdXBpbmcg ZGV2aWNlcyB1bmRlciBhIHVuaXF1ZSBjZWxsdWxhciBjb25uZWN0aW9uDQo+ID4+PiBhcmUgdmVy eSBudW1lcm91czogSVB2NiBhdXRvbW9iaWxlcywgSVB2NiB0ZXRoZXJpbmcgc21hcnRwaG9uZXMs DQo+ID4+PiBJUHY2IFRoaW5ncyBvbiBQZXJzb25hbCBBcmVhIE5ldHdvcmtzLg0KPiA+DQo+ID4g WWVzLCB5ZXMgYW5kIHllcy4gQWxzbyBJUHY2IGFpcnBsYW5lcy4NCj4gDQo+IFdoYXQgaXMgdGhl IHVzZSBjYXNlIHdoZW4gYW4gYWlycGxhbmUgY29ubmVjdHMgdG8gYSBjZWxsdWxhciBvcGVyYXRv cj8NCj4gVGhleSBhcmUgc3VwcG9zZWQgdG8gYmUgb24gc2F0dGVsaXRlIG9mdGVuLCBJIGd1ZXNz Lg0KDQpBaXJwbGFuZXMgaGF2ZSBsb3RzIG9mIGxpbmtzIC0gc29tZSBzYXRlbGxpdGUgeWVzLCBi dXQgdGhlcmUgYXJlIGFsc28NCmNlbGx1bGFyIGxpbmsgdHlwZXMgc3VjaCBhcyB0aGlzOg0KDQpo dHRwOi8vYWlyY2VsbC5jb20vDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWlu Zy5jb20NCg0KPiBBbGV4DQo+IA0KPiA+DQo+ID4+PiBBbGwgdGhlc2UgZGV2aWNlcyBuZWVkIHRo ZSBjZWxsdWxhciBvcGVyYXRvciB0byBkZWxpdmVyDQo+ID4+PiBzaG9ydGVyLXRoYW4tNjQgcHJl Zml4ZXMgdG8gYSBTSU0gY29ubmVjdGlvbi4NCj4gPj4NCj4gPj4gRm9yIGxhY2sgb2YgYSBiZXR0 ZXIgZGVzY3JpcHRpb24sIHRoZSBjZWxsdWxhciBzaWRlIG9mIGJ1c2luZXNzZXMNCj4gPj4gc3Vm ZmVyIGZyb20gImJlbGwgaGVhZDoiIHRoaW5raW5nLCB3aGVyZSB0aGUgVUUgaXMgYW4gYXBwbGlj YXRpb24NCj4gPj4gZW5kcG9pbnQuIE5vdGhpbmcgbW9yZSBvY2N1cnMgdG8gdGhlbSwgYmVjYXVz ZSB0aGF0IGlzIHRoZSBwcm9kdWN0DQo+ID4+IHRoZXkgaGF2ZSBhbHdheXMgc3VwcG9ydGVkLiBB IHJvdXRpbmcgZnVuY3Rpb24gaW1wbGllcyBoaWdoZXINCj4gPj4gYWdncmVnYXRlIGRhdGEgcmF0 ZXMgdGhhbiB0aGV5IGhhdmUgYnVpbHQgdGhlIHN5c3RlbSB0byBoYW5kbGUuIEkNCj4gPj4gaGF2 ZSBiZWVuIGluIGZyb250IG9mIG1hbnkgb2YgdGhlbSBob2xkaW5nIHVwIFVFIGFuZCBzYXlpbmcs ICJ0aGlzDQo+ID4+IGlzIGEgUk9VVEVSLCBnZXQgb3ZlciBpdCIsIGFuZCBnb3Qgbm90aGluZyBi dXQgYmxhbmsgc3RhcmVzIGJhY2suDQo+ID4NCj4gPiBJbmRlZWQuIEJ1dCwgdGhpcyBpcyB0aGUg b25nb2luZyBkaWFsb2d1ZSB0aGF0IHdlIG5lZWQgdG8gY29udGludWUNCj4gPiBubyBtYXR0ZXIg aG93IG1hbnkgYmxhbmsgc3RhcmVzIHdlIGdldC4NCj4gPg0KPiA+IFRoYW5rcyAtIEZyZWQgZnJl ZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+ID4+IFRoZSBmaXJzdCB1c2UgY2FzZSBvbiB0 aGUgbGlzdCBzaG91bGQgYmUgYSB3aXJlbGluZQ0KPiA+PiBhbHRlcm5hdGl2ZS9iYWNrdXAgbGlu ayBmb3IgY29uc3VtZXIgQ1BFIHJvdXRlcnMsIGFuZCBob21lIGNvbnRyb2wNCj4gPj4gb3Igc2Vj dXJpdHkgc3lzdGVtcy4gVGhhdCBpcyBzaW1wbGVyIHRvIHN1cHBvcnQgYmVjYXVzZSB0aGUgVUUN Cj4gPj4gZG9lc24ndCBtb3ZlIGFyb3VuZCwgc28gdGhleSBjYW4gc2NhbGUgdGhlIGluZnJhc3Ry dWN0dXJlIHRvIGFsaWduDQo+ID4+IHdpdGggZGVtYW5kIHdpdGhvdXQgdG9vIG11Y2ggY29uY2Vy biBhYm91dCB0aGF0IHNoaWZ0aW5nIHF1aWNrbHkuDQo+ID4+IE9uY2UgdGhlIGZlYXIgb2YgZG93 bnN0cmVhbSBzdWJuZXRzIGlzIHJlbW92ZWQsIHdvcmtpbmcgb24gdGhlDQo+ID4+IHRydWx5IG1v YmlsZSB1c2UgY2FzZXMgd2lsbCBiZSBhbiBlYXNpZXIgbWVudGFsIGh1cmRsZSB0bw0KPiA+PiBv dmVyY29tZS4NCj4gPj4NCj4gPj4gVG9ueQ0KPiA+Pg0KPiA+PiAuLi4uLi4uLi4uLg0KPiA+Pg0K PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBkbW0g bWFpbGluZyBsaXN0DQo+ID4+IGRtbUBpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RtbQ0KDQo= From nobody Fri Jun 12 08:53:38 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84191A1B3D for ; Fri, 12 Jun 2015 08:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNo7ikSOFntE for ; Fri, 12 Jun 2015 08:53:33 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1640D1A1B34 for ; Fri, 12 Jun 2015 08:53:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5CFrRal011517; Fri, 12 Jun 2015 17:53:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D479B206135; Fri, 12 Jun 2015 17:56:05 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C2F81205AC0; Fri, 12 Jun 2015 17:56:05 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5CFrQE1027648; Fri, 12 Jun 2015 17:53:26 +0200 Message-ID: <557B0076.7000501@gmail.com> Date: Fri, 12 Jun 2015 17:53:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Templin, Fred L" , Tony Hain , "'Jouni Korhonen'" , "dmm@ietf.org" References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <5579B120.1020806@gmail.com> <5579B510.9020909@gmail.com> <123c01d0a466$3a94e3c0$afbeab40$@tndh.net> <2134F8430051B64F815C691A62D9831832E8A2EF@XCH-BLV-504.nw.nos.boeing.com> <557AD89C.9080809@gmail.com> <2134F8430051B64F815C691A62D9831832E8AF81@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E8AF81@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 15:53:36 -0000 Hi Fred, Le 12/06/2015 17:24, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Friday, June 12, 2015 6:03 AM >> To: Templin, Fred L; Tony Hain; 'Jouni Korhonen'; dmm@ietf.org >> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >> >> >> >> Le 11/06/2015 18:53, Templin, Fred L a écrit : >>> Responding to two in one: >>> >>>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] >>>> On Behalf Of Tony Hain Sent: Thursday, June 11, 2015 9:47 AM To: >>>> 'Alexandru Petrescu'; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: >>>> [DMM] vepc draft Rev. 04 - /62s to UE, not /64s >>>> >>>> Alexandru Petrescu wrote: >>>>> Le 11/06/2015 18:02, Jouni Korhonen a écrit : >>>>>> >>>>>> >>>>>> 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: >>>>>>> Le 04/06/2015 05:42, Templin, Fred L a écrit : >>>>>>>> Hi Alex, >>>>>>>> >>>>>>>>> -----Original Message----- From: Alexandru Petrescu >>>>>>>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, >>>>>>>>> June 03, 2015 8:36 AM To: Templin, Fred L; Satoru >>>>>>>>> Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 >>>>>>>>> - /62s to UE, not /64s >>>>>>>>> >>>>>>>>> Le 29/05/2015 20:21, Templin, Fred L a écrit : >>>>>>>>>> Hi Alex, >>>>>>>>>> >>>>>>>>>>> -----Original Message----- From: dmm >>>>>>>>>>> [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru >>>>>>>>>>> Petrescu Sent: Friday, May 29, 2015 10:59 AM To: >>>>>>>>>>> Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc >>>>>>>>>>> draft Rev. 04 - /62s to UE, not /64s >>>>>>>>>>> >>>>>>>>>>> Le 29/05/2015 15:30, Satoru Matsushima a écrit : >>>>>>>>>>>> Ah OK. thanks. Slightly off-topic, I think that >>>>>>>>>>>> there is still chance for tethering with single /64 >>>>>>>>>>>> if it is allocated as a off-link prefix. >>>>>>>>>>> >>>>>>>>>>> Yes, there is still such a chance. But it can not >>>>>>>>>>> tether more than one single subnet. Connected >>>>>>>>>>> vehicles need several subnets. >>>>>>>>>> >>>>>>>>>> How would it be if the vehicle received a single >>>>>>>>>> prefix, but it could be shorter than /64 (e.g., /56, >>>>>>>>>> /48. etc.)? Would the vehicle subnetting be satisfied >>>>>>>>>> if it received a shorter prefix from which many /64s >>>>>>>>>> could be allocated? >>>>>>>>> >>>>>>>>> Certainly yes. >>>>>>>>> >>>>>>>>> Each vehicle needs such a shorter-than-64 prefix >>>>>>>>> allocated to it. >>>>>>>>> >>>>>>>>> For example, an automobile connecting to LTE receives a >>>>>>>>> /62 from the operator and makes four /64s out of it: one >>>>>>>>> for its CAN-entertainment, one for its CAN-safety, one >>>>>>>>> for its WiFi and one for its >>>>> Bluetooth. >>>>>>>>> >>>>>>>>> This is a MUST. >>>>>>>>> >>>>>>>>> Allocating a single /64 to a vehicle can not accommodate >>>>>>>>> all these unbridgeable subnets. >>>>>>>> >>>>>>>> OK, that is good. Giving a mobile router something shorter >>>>>>>> than /64 should be no problem, at least up to practical >>>>>>>> limitations of the prefix delegation authority's available >>>>>>>> prefix space. DHCPv6 PD provides all that is needed to give >>>>>>>> out right-sized prefixes. >>>>>>> >>>>>>> I agree DHCP-PD provides the necessary tool. But >>>>>>> unfortunately the cellular operators have not deployed >>>>>>> DHCPv6-PD (although yes there is some DHCP-non-PD in some >>>>>>> IPv6/4G deployments). >>>>>>> >>>>>>> The common thinking at operators and advisers is still that a >>>>>>> /64 should be given to an User Equipment. >>>>>>> >>>>>>> This must change: the 3GPP specs and operator deployments >>>>>>> must give /62 to UEs, and not /64. >>>>>> >>>>>> I think we are not in the position to force operators or 3GPP >>>>>> to do anything, unfortunately. The best we can do is to make >>>>>> sure the protocols we work here in IETF are not prohibiting >>>>>> better deployments (see e.g. RFC6603 effort). 3GPP specs are >>>>>> not the show stoppers here. >>>>>> >>>>>> I know this is frustrating. For example some operators I know >>>>>> offer IPv6 PD on their fixed side of business but have no plans >>>>>> for similar on the cellular side.. reasons are many. I assume >>>>>> that identofying a strong enough use case would be the key. >>>>> >>>>> I would like to discuss these use cases. >>>>> >>>>> Use cases of grouping devices under a unique cellular connection >>>>> are very numerous: IPv6 automobiles, IPv6 tethering smartphones, >>>>> IPv6 Things on Personal Area Networks. >>> >>> Yes, yes and yes. Also IPv6 airplanes. >> >> What is the use case when an airplane connects to a cellular operator? >> They are supposed to be on sattelite often, I guess. > > Airplanes have lots of links - some satellite yes, but there are also > cellular link types such as this: > > http://aircell.com/ That is a cellular link on-board of a plane, I think. Maybe it requires a shorter-than-64 prefix from the satellite operator... But is there a use-case with plane that connects to a cellular network while taxiing ? I.e. slow speed, spend 1hour on the tarmac, connect the plane to Verizon, give passengers free WiFi to smartphones so use Internet to announce safe landing. This latter certainly requires a shorter-than-64 prefix from the cellular operator. Alex > > Thanks - Fred > fred.l.templin@boeing.com > >> Alex >> >>> >>>>> All these devices need the cellular operator to deliver >>>>> shorter-than-64 prefixes to a SIM connection. >>>> >>>> For lack of a better description, the cellular side of businesses >>>> suffer from "bell head:" thinking, where the UE is an application >>>> endpoint. Nothing more occurs to them, because that is the product >>>> they have always supported. A routing function implies higher >>>> aggregate data rates than they have built the system to handle. I >>>> have been in front of many of them holding up UE and saying, "this >>>> is a ROUTER, get over it", and got nothing but blank stares back. >>> >>> Indeed. But, this is the ongoing dialogue that we need to continue >>> no matter how many blank stares we get. >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>>> The first use case on the list should be a wireline >>>> alternative/backup link for consumer CPE routers, and home control >>>> or security systems. That is simpler to support because the UE >>>> doesn't move around, so they can scale the infrastructure to align >>>> with demand without too much concern about that shifting quickly. >>>> Once the fear of downstream subnets is removed, working on the >>>> truly mobile use cases will be an easier mental hurdle to >>>> overcome. >>>> >>>> Tony >>>> >>>> ........... >>>> >>>> _______________________________________________ dmm mailing list >>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > From nobody Fri Jun 12 09:17:21 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907A01A8826 for ; Fri, 12 Jun 2015 09:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYs_7Z3zcLXp for ; Fri, 12 Jun 2015 09:17:06 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 14E391A1B3F for ; Fri, 12 Jun 2015 09:16:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t5CGGYq5016383; Fri, 12 Jun 2015 09:16:34 -0700 Received: from XCH-BLV-206.nw.nos.boeing.com (xch-blv-206.nw.nos.boeing.com [10.57.37.16]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t5CGGP3P016320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 12 Jun 2015 09:16:25 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-BLV-206.nw.nos.boeing.com ([169.254.6.134]) with mapi id 14.03.0235.001; Fri, 12 Jun 2015 09:16:24 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Tony Hain , "'Jouni Korhonen'" , "dmm@ietf.org" Thread-Topic: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Thread-Index: AQHQmjkkJI//M3dql0O3DI0sVGxmlwJC4/zOAcXevwMBlLT6GAGyvW7VASL5HjsCBLNn7wFqGnxOAZmpP6MBnx26TAIjGX1tAf2pTcCayOegEIJE1RJAgAHIWQD//7Fw4IAAfhIA//+NxpA= Date: Fri, 12 Jun 2015 16:16:23 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E8B12D@XCH-BLV-504.nw.nos.boeing.com> References: <5565AAFB.9030100@gmail.com> <5568A8D1.7030908@gmail.com> <2134F8430051B64F815C691A62D9831832E7AF5D@XCH-BLV-504.nw.nos.boeing.com> <556F1ECD.70801@gmail.com> <2134F8430051B64F815C691A62D9831832E82256@XCH-BLV-504.nw.nos.boeing.com> <55705BE6.50205@gmail.com> <5579B120.1020806@gmail.com> <5579B510.9020909@gmail.com> <123c01d0a466$3a94e3c0$afbeab40$@tndh.net> <2134F8430051B64F815C691A62D9831832E8A2EF@XCH-BLV-504.nw.nos.boeing.com> <557AD89C.9080809@gmail.com> <2134F8430051B64F815C691A62D9831832E8AF81@XCH-BLV-504.nw.nos.boeing.com> <557B0076.7000501@gmail.com> In-Reply-To: <557B0076.7000501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:17:14 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cnUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBGcmlkYXksIEp1bmUgMTIsIDIwMTUgODo1MyBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMOyBU b255IEhhaW47ICdKb3VuaSBLb3Job25lbic7IGRtbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W0RNTV0gdmVwYyBkcmFmdCBSZXYuIDA0IC0gLzYycyB0byBVRSwgbm90IC82NHMNCj4gDQo+IEhp IEZyZWQsDQo+IA0KPiBMZSAxMi8wNi8yMDE1IDE3OjI0LCBUZW1wbGluLCBGcmVkIEwgYSDDqWNy aXQgOg0KPiA+IEhpIEFsZXgsDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4gRnJvbTogQWxleGFuZHJ1IFBldHJlc2N1IFttYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1 QGdtYWlsLmNvbV0NCj4gPj4gU2VudDogRnJpZGF5LCBKdW5lIDEyLCAyMDE1IDY6MDMgQU0NCj4g Pj4gVG86IFRlbXBsaW4sIEZyZWQgTDsgVG9ueSBIYWluOyAnSm91bmkgS29yaG9uZW4nOyBkbW1A aWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtETU1dIHZlcGMgZHJhZnQgUmV2LiAwNCAtIC82 MnMgdG8gVUUsIG5vdCAvNjRzDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IExlIDExLzA2LzIwMTUg MTg6NTMsIFRlbXBsaW4sIEZyZWQgTCBhIMOpY3JpdCA6DQo+ID4+PiBSZXNwb25kaW5nIHRvIHR3 byBpbiBvbmU6DQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206 IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXQ0KPiA+Pj4+IE9uIEJlaGFsZiBPZiBU b255IEhhaW4gU2VudDogVGh1cnNkYXksIEp1bmUgMTEsIDIwMTUgOTo0NyBBTSBUbzoNCj4gPj4+ PiAnQWxleGFuZHJ1IFBldHJlc2N1JzsgJ0pvdW5pIEtvcmhvbmVuJzsgZG1tQGlldGYub3JnIFN1 YmplY3Q6IFJlOg0KPiA+Pj4+IFtETU1dIHZlcGMgZHJhZnQgUmV2LiAwNCAtIC82MnMgdG8gVUUs IG5vdCAvNjRzDQo+ID4+Pj4NCj4gPj4+PiBBbGV4YW5kcnUgUGV0cmVzY3Ugd3JvdGU6DQo+ID4+ Pj4+IExlIDExLzA2LzIwMTUgMTg6MDIsIEpvdW5pIEtvcmhvbmVuIGEgw6ljcml0IDoNCj4gPj4+ Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gNi80LzIwMTUsIDc6MDggQU0sIEFsZXhhbmRydSBQZXRy ZXNjdSBraXJqb2l0dGk6DQo+ID4+Pj4+Pj4gTGUgMDQvMDYvMjAxNSAwNTo0MiwgVGVtcGxpbiwg RnJlZCBMIGEgw6ljcml0IDoNCj4gPj4+Pj4+Pj4gSGkgQWxleCwNCj4gPj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEFsZXhhbmRydSBQZXRyZXNj dQ0KPiA+Pj4+Pj4+Pj4gW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXSBTZW50 OiBXZWRuZXNkYXksDQo+ID4+Pj4+Pj4+PiBKdW5lIDAzLCAyMDE1IDg6MzYgQU0gVG86IFRlbXBs aW4sIEZyZWQgTDsgU2F0b3J1DQo+ID4+Pj4+Pj4+PiBNYXRzdXNoaW1hIENjOiBkbW0gU3ViamVj dDogUmU6IFtETU1dIHZlcGMgZHJhZnQgUmV2LiAwNA0KPiA+Pj4+Pj4+Pj4gLSAvNjJzIHRvIFVF LCBub3QgLzY0cw0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IExlIDI5LzA1LzIwMTUgMjA6MjEs IFRlbXBsaW4sIEZyZWQgTCBhIMOpY3JpdCA6DQo+ID4+Pj4+Pj4+Pj4gSGkgQWxleCwNCj4gPj4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBk bW0NCj4gPj4+Pj4+Pj4+Pj4gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEFsZXhhbmRydQ0KPiA+Pj4+Pj4+Pj4+PiBQZXRyZXNjdSBTZW50OiBGcmlkYXksIE1heSAy OSwgMjAxNSAxMDo1OSBBTSBUbzoNCj4gPj4+Pj4+Pj4+Pj4gU2F0b3J1IE1hdHN1c2hpbWEgQ2M6 IGRtbSBTdWJqZWN0OiBSZTogW0RNTV0gdmVwYw0KPiA+Pj4+Pj4+Pj4+PiBkcmFmdCBSZXYuIDA0 IC0gLzYycyB0byBVRSwgbm90IC82NHMNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gTGUg MjkvMDUvMjAxNSAxNTozMCwgU2F0b3J1IE1hdHN1c2hpbWEgYSDDqWNyaXQgOg0KPiA+Pj4+Pj4+ Pj4+Pj4gQWggT0suIHRoYW5rcy4gU2xpZ2h0bHkgb2ZmLXRvcGljLCBJIHRoaW5rIHRoYXQNCj4g Pj4+Pj4+Pj4+Pj4+IHRoZXJlIGlzIHN0aWxsIGNoYW5jZSBmb3IgdGV0aGVyaW5nIHdpdGggc2lu Z2xlIC82NA0KPiA+Pj4+Pj4+Pj4+Pj4gaWYgaXQgaXMgYWxsb2NhdGVkIGFzIGEgb2ZmLWxpbmsg cHJlZml4Lg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBZZXMsIHRoZXJlIGlzIHN0aWxs IHN1Y2ggYSBjaGFuY2UuICBCdXQgaXQgY2FuIG5vdA0KPiA+Pj4+Pj4+Pj4+PiB0ZXRoZXIgbW9y ZSB0aGFuIG9uZSBzaW5nbGUgc3VibmV0LiAgQ29ubmVjdGVkDQo+ID4+Pj4+Pj4+Pj4+IHZlaGlj bGVzIG5lZWQgc2V2ZXJhbCBzdWJuZXRzLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gSG93 IHdvdWxkIGl0IGJlIGlmIHRoZSB2ZWhpY2xlIHJlY2VpdmVkIGEgc2luZ2xlDQo+ID4+Pj4+Pj4+ Pj4gcHJlZml4LCBidXQgaXQgY291bGQgYmUgc2hvcnRlciB0aGFuIC82NCAoZS5nLiwgLzU2LA0K PiA+Pj4+Pj4+Pj4+IC80OC4gZXRjLik/IFdvdWxkIHRoZSB2ZWhpY2xlIHN1Ym5ldHRpbmcgYmUg c2F0aXNmaWVkDQo+ID4+Pj4+Pj4+Pj4gaWYgaXQgcmVjZWl2ZWQgYSBzaG9ydGVyIHByZWZpeCBm cm9tIHdoaWNoIG1hbnkgLzY0cw0KPiA+Pj4+Pj4+Pj4+IGNvdWxkIGJlIGFsbG9jYXRlZD8NCj4g Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBDZXJ0YWlubHkgeWVzLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+IEVhY2ggdmVoaWNsZSBuZWVkcyBzdWNoIGEgc2hvcnRlci10aGFuLTY0IHByZWZpeA0K PiA+Pj4+Pj4+Pj4gYWxsb2NhdGVkIHRvIGl0Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEZv ciBleGFtcGxlLCBhbiBhdXRvbW9iaWxlIGNvbm5lY3RpbmcgdG8gTFRFIHJlY2VpdmVzIGENCj4g Pj4+Pj4+Pj4+IC82MiBmcm9tIHRoZSBvcGVyYXRvciBhbmQgbWFrZXMgZm91ciAvNjRzIG91dCBv ZiBpdDogb25lDQo+ID4+Pj4+Pj4+PiBmb3IgaXRzIENBTi1lbnRlcnRhaW5tZW50LCBvbmUgZm9y IGl0cyBDQU4tc2FmZXR5LCBvbmUNCj4gPj4+Pj4+Pj4+IGZvciBpdHMgV2lGaSBhbmQgb25lIGZv ciBpdHMNCj4gPj4+Pj4gQmx1ZXRvb3RoLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFRoaXMg aXMgYSBNVVNULg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEFsbG9jYXRpbmcgYSBzaW5nbGUg LzY0IHRvIGEgdmVoaWNsZSBjYW4gbm90IGFjY29tbW9kYXRlDQo+ID4+Pj4+Pj4+PiBhbGwgdGhl c2UgdW5icmlkZ2VhYmxlIHN1Ym5ldHMuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IE9LLCB0aGF0 IGlzIGdvb2QuIEdpdmluZyBhIG1vYmlsZSByb3V0ZXIgc29tZXRoaW5nIHNob3J0ZXINCj4gPj4+ Pj4+Pj4gdGhhbiAvNjQgc2hvdWxkIGJlIG5vIHByb2JsZW0sIGF0IGxlYXN0IHVwIHRvIHByYWN0 aWNhbA0KPiA+Pj4+Pj4+PiBsaW1pdGF0aW9ucyBvZiB0aGUgcHJlZml4IGRlbGVnYXRpb24gYXV0 aG9yaXR5J3MgYXZhaWxhYmxlDQo+ID4+Pj4+Pj4+IHByZWZpeCBzcGFjZS4gREhDUHY2IFBEIHBy b3ZpZGVzIGFsbCB0aGF0IGlzIG5lZWRlZCB0byBnaXZlDQo+ID4+Pj4+Pj4+IG91dCByaWdodC1z aXplZCBwcmVmaXhlcy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEkgYWdyZWUgREhDUC1QRCBwcm92 aWRlcyB0aGUgbmVjZXNzYXJ5IHRvb2wuICBCdXQNCj4gPj4+Pj4+PiB1bmZvcnR1bmF0ZWx5IHRo ZSBjZWxsdWxhciBvcGVyYXRvcnMgaGF2ZSBub3QgZGVwbG95ZWQNCj4gPj4+Pj4+PiBESENQdjYt UEQgKGFsdGhvdWdoIHllcyB0aGVyZSBpcyBzb21lIERIQ1Atbm9uLVBEIGluIHNvbWUNCj4gPj4+ Pj4+PiBJUHY2LzRHIGRlcGxveW1lbnRzKS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoZSBjb21t b24gdGhpbmtpbmcgYXQgb3BlcmF0b3JzIGFuZCBhZHZpc2VycyBpcyBzdGlsbCB0aGF0IGENCj4g Pj4+Pj4+PiAvNjQgc2hvdWxkIGJlIGdpdmVuIHRvIGFuIFVzZXIgRXF1aXBtZW50Lg0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4gVGhpcyBtdXN0IGNoYW5nZTogdGhlIDNHUFAgc3BlY3MgYW5kIG9wZXJh dG9yIGRlcGxveW1lbnRzDQo+ID4+Pj4+Pj4gbXVzdCBnaXZlIC82MiB0byBVRXMsIGFuZCBub3Qg LzY0Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgdGhpbmsgd2UgYXJlIG5vdCBpbiB0aGUgcG9zaXRp b24gdG8gZm9yY2Ugb3BlcmF0b3JzIG9yIDNHUFANCj4gPj4+Pj4+IHRvIGRvIGFueXRoaW5nLCB1 bmZvcnR1bmF0ZWx5LiBUaGUgYmVzdCB3ZSBjYW4gZG8gaXMgdG8gbWFrZQ0KPiA+Pj4+Pj4gc3Vy ZSB0aGUgcHJvdG9jb2xzIHdlIHdvcmsgaGVyZSBpbiBJRVRGIGFyZSBub3QgcHJvaGliaXRpbmcN Cj4gPj4+Pj4+IGJldHRlciBkZXBsb3ltZW50cyAoc2VlIGUuZy4gUkZDNjYwMyBlZmZvcnQpLiAz R1BQIHNwZWNzIGFyZQ0KPiA+Pj4+Pj4gbm90IHRoZSBzaG93IHN0b3BwZXJzIGhlcmUuDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gSSBrbm93IHRoaXMgaXMgZnJ1c3RyYXRpbmcuIEZvciBleGFtcGxlIHNv bWUgb3BlcmF0b3JzIEkga25vdw0KPiA+Pj4+Pj4gb2ZmZXIgSVB2NiBQRCBvbiB0aGVpciBmaXhl ZCBzaWRlIG9mIGJ1c2luZXNzIGJ1dCBoYXZlIG5vIHBsYW5zDQo+ID4+Pj4+PiBmb3Igc2ltaWxh ciBvbiB0aGUgY2VsbHVsYXIgc2lkZS4uIHJlYXNvbnMgYXJlIG1hbnkuIEkgYXNzdW1lDQo+ID4+ Pj4+PiB0aGF0IGlkZW50b2Z5aW5nIGEgc3Ryb25nIGVub3VnaCB1c2UgY2FzZSB3b3VsZCBiZSB0 aGUga2V5Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIHdvdWxkIGxpa2UgdG8gZGlzY3VzcyB0aGVzZSB1 c2UgY2FzZXMuDQo+ID4+Pj4+DQo+ID4+Pj4+IFVzZSBjYXNlcyBvZiBncm91cGluZyBkZXZpY2Vz IHVuZGVyIGEgdW5pcXVlIGNlbGx1bGFyIGNvbm5lY3Rpb24NCj4gPj4+Pj4gYXJlIHZlcnkgbnVt ZXJvdXM6IElQdjYgYXV0b21vYmlsZXMsIElQdjYgdGV0aGVyaW5nIHNtYXJ0cGhvbmVzLA0KPiA+ Pj4+PiBJUHY2IFRoaW5ncyBvbiBQZXJzb25hbCBBcmVhIE5ldHdvcmtzLg0KPiA+Pj4NCj4gPj4+ IFllcywgeWVzIGFuZCB5ZXMuIEFsc28gSVB2NiBhaXJwbGFuZXMuDQo+ID4+DQo+ID4+IFdoYXQg aXMgdGhlIHVzZSBjYXNlIHdoZW4gYW4gYWlycGxhbmUgY29ubmVjdHMgdG8gYSBjZWxsdWxhciBv cGVyYXRvcj8NCj4gPj4gVGhleSBhcmUgc3VwcG9zZWQgdG8gYmUgb24gc2F0dGVsaXRlIG9mdGVu LCBJIGd1ZXNzLg0KPiA+DQo+ID4gQWlycGxhbmVzIGhhdmUgbG90cyBvZiBsaW5rcyAtIHNvbWUg c2F0ZWxsaXRlIHllcywgYnV0IHRoZXJlIGFyZSBhbHNvDQo+ID4gY2VsbHVsYXIgbGluayB0eXBl cyBzdWNoIGFzIHRoaXM6DQo+ID4NCj4gPiBodHRwOi8vYWlyY2VsbC5jb20vDQo+IA0KPiBUaGF0 IGlzIGEgY2VsbHVsYXIgbGluayBvbi1ib2FyZCBvZiBhIHBsYW5lLCBJIHRoaW5rLiAgTWF5YmUg aXQgcmVxdWlyZXMNCj4gYSBzaG9ydGVyLXRoYW4tNjQgcHJlZml4IGZyb20gdGhlIHNhdGVsbGl0 ZSBvcGVyYXRvci4uLg0KDQpMYXN0IEkgY2hlY2tlZCwgR29nby9BaXJjZWxsIGlzIGJhc2VkIG9u IGEgY2VsbHVsYXIgZ3JvdW5kIG5ldHdvcmsgYW5kDQpnaXZlcyBwYXNzZW5nZXJzIG9uIGJvYXJk IGFuIEludGVybmV0LWNhcGFibGUgV2lGaSBzZXJ2aWNlLiBBaXJjZWxsIGFsc28NCm9mZmVycyBz YXRjb20gc2VydmljZXMgaW5jbHVkaW5nIElubWFyc2F0IGFuZCBJcmlkaXVtLCBidXQgSSB3YXMg cmVmZXJyaW5nDQp0byB0aGUgZ3JvdW5kLWJhc2VkIGNlbGx1bGFyIG5ldHdvcmsuDQoNCj4gQnV0 IGlzIHRoZXJlIGEgdXNlLWNhc2Ugd2l0aCBwbGFuZSB0aGF0IGNvbm5lY3RzIHRvIGEgY2VsbHVs YXIgbmV0d29yaw0KPiB3aGlsZSB0YXhpaW5nID8gIEkuZS4gc2xvdyBzcGVlZCwgc3BlbmQgMWhv dXIgb24gdGhlIHRhcm1hYywgY29ubmVjdCB0aGUNCj4gcGxhbmUgdG8gVmVyaXpvbiwgZ2l2ZSBw YXNzZW5nZXJzIGZyZWUgV2lGaSB0byBzbWFydHBob25lcyBzbyB1c2UNCj4gSW50ZXJuZXQgdG8g YW5ub3VuY2Ugc2FmZSBsYW5kaW5nLg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgcGFzc2Vu Z2VyLWRvbWFpbiBjb21tdW5pY2F0aW9ucyBhcmUNCm9ubHkgYWJvdmUgMTBLZnQuIEhvd2V2ZXIs IEFpciBUcmFmZmljIENvbnRyb2wgZG9tYWluIGhhcyB0aGluZ3MNCmxpa2UgZ2F0ZWxpbmsgV2lG aSwgQUVST01BQ1MsIGV0Yy4gaW4gdGhlIHRlcm1pbmFsIGFuZCBncm91bmQNCmRvbWFpbiBhcmVh Lg0KDQpUaGluayBvZiBhaXJjcmFmdCBhcyBoYXZpbmcgKGF0IGxlYXN0KSB0aHJlZSBkaXN0aW5j dCBjb21tdW5pY2F0aW9uDQpkb21haW5zIC0gQWlyIFRyYWZmaWMgQ29udHJvbCAoQVRDKSwgQWly bGluZSBPcGVyYXRpb25zIENvbnRyb2wNCihBT0MpIGFuZCBQYXNzZW5nZXIgSW4tZmxpZ2h0IEVu dGVydGFpbm1lbnQgKFBJRVMpLiBPYnZpb3VzbHksDQp0aGUgcGFzc2VuZ2VyIGRvbWFpbiBuZWVk cyB0byBiZSBrZXB0IHNlcGFyYXRlIGZyb20gdGhlDQpzYWZldHktb2YtZmxpZ2h0LWNyaXRpY2Fs IGRvbWFpbnMuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0K PiBUaGlzIGxhdHRlciBjZXJ0YWlubHkgcmVxdWlyZXMgYSBzaG9ydGVyLXRoYW4tNjQgcHJlZml4 IGZyb20gdGhlDQo+IGNlbGx1bGFyIG9wZXJhdG9yLg0KPiANCj4gQWxleA0KPiANCj4gPg0KPiA+ IFRoYW5rcyAtIEZyZWQNCj4gPiBmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+ID4NCj4gPj4g QWxleA0KPiA+Pg0KPiA+Pj4NCj4gPj4+Pj4gQWxsIHRoZXNlIGRldmljZXMgbmVlZCB0aGUgY2Vs bHVsYXIgb3BlcmF0b3IgdG8gZGVsaXZlcg0KPiA+Pj4+PiBzaG9ydGVyLXRoYW4tNjQgcHJlZml4 ZXMgdG8gYSBTSU0gY29ubmVjdGlvbi4NCj4gPj4+Pg0KPiA+Pj4+IEZvciBsYWNrIG9mIGEgYmV0 dGVyIGRlc2NyaXB0aW9uLCB0aGUgY2VsbHVsYXIgc2lkZSBvZiBidXNpbmVzc2VzDQo+ID4+Pj4g c3VmZmVyIGZyb20gImJlbGwgaGVhZDoiIHRoaW5raW5nLCB3aGVyZSB0aGUgVUUgaXMgYW4gYXBw bGljYXRpb24NCj4gPj4+PiBlbmRwb2ludC4gTm90aGluZyBtb3JlIG9jY3VycyB0byB0aGVtLCBi ZWNhdXNlIHRoYXQgaXMgdGhlIHByb2R1Y3QNCj4gPj4+PiB0aGV5IGhhdmUgYWx3YXlzIHN1cHBv cnRlZC4gQSByb3V0aW5nIGZ1bmN0aW9uIGltcGxpZXMgaGlnaGVyDQo+ID4+Pj4gYWdncmVnYXRl IGRhdGEgcmF0ZXMgdGhhbiB0aGV5IGhhdmUgYnVpbHQgdGhlIHN5c3RlbSB0byBoYW5kbGUuIEkN Cj4gPj4+PiBoYXZlIGJlZW4gaW4gZnJvbnQgb2YgbWFueSBvZiB0aGVtIGhvbGRpbmcgdXAgVUUg YW5kIHNheWluZywgInRoaXMNCj4gPj4+PiBpcyBhIFJPVVRFUiwgZ2V0IG92ZXIgaXQiLCBhbmQg Z290IG5vdGhpbmcgYnV0IGJsYW5rIHN0YXJlcyBiYWNrLg0KPiA+Pj4NCj4gPj4+IEluZGVlZC4g QnV0LCB0aGlzIGlzIHRoZSBvbmdvaW5nIGRpYWxvZ3VlIHRoYXQgd2UgbmVlZCB0byBjb250aW51 ZQ0KPiA+Pj4gbm8gbWF0dGVyIGhvdyBtYW55IGJsYW5rIHN0YXJlcyB3ZSBnZXQuDQo+ID4+Pg0K PiA+Pj4gVGhhbmtzIC0gRnJlZCBmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+ID4+Pg0KPiA+ Pj4+IFRoZSBmaXJzdCB1c2UgY2FzZSBvbiB0aGUgbGlzdCBzaG91bGQgYmUgYSB3aXJlbGluZQ0K PiA+Pj4+IGFsdGVybmF0aXZlL2JhY2t1cCBsaW5rIGZvciBjb25zdW1lciBDUEUgcm91dGVycywg YW5kIGhvbWUgY29udHJvbA0KPiA+Pj4+IG9yIHNlY3VyaXR5IHN5c3RlbXMuIFRoYXQgaXMgc2lt cGxlciB0byBzdXBwb3J0IGJlY2F1c2UgdGhlIFVFDQo+ID4+Pj4gZG9lc24ndCBtb3ZlIGFyb3Vu ZCwgc28gdGhleSBjYW4gc2NhbGUgdGhlIGluZnJhc3RydWN0dXJlIHRvIGFsaWduDQo+ID4+Pj4g d2l0aCBkZW1hbmQgd2l0aG91dCB0b28gbXVjaCBjb25jZXJuIGFib3V0IHRoYXQgc2hpZnRpbmcg cXVpY2tseS4NCj4gPj4+PiBPbmNlIHRoZSBmZWFyIG9mIGRvd25zdHJlYW0gc3VibmV0cyBpcyBy ZW1vdmVkLCB3b3JraW5nIG9uIHRoZQ0KPiA+Pj4+IHRydWx5IG1vYmlsZSB1c2UgY2FzZXMgd2ls bCBiZSBhbiBlYXNpZXIgbWVudGFsIGh1cmRsZSB0bw0KPiA+Pj4+IG92ZXJjb21lLg0KPiA+Pj4+ DQo+ID4+Pj4gVG9ueQ0KPiA+Pj4+DQo+ID4+Pj4gLi4uLi4uLi4uLi4NCj4gPj4+Pg0KPiA+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGRtbSBtYWls aW5nIGxpc3QNCj4gPj4+PiBkbW1AaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kbW0NCj4gPg0KDQo= From nobody Wed Jun 17 01:21:03 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D0F1A6F33 for ; Wed, 17 Jun 2015 01:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3YxdtERcu63 for ; Wed, 17 Jun 2015 01:21:00 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id AF7E41A6F22 for ; Wed, 17 Jun 2015 01:21:00 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 17 Jun 2015 01:21:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,631,1427785200"; d="scan'208,217";a="589400323" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga003.jf.intel.com with ESMTP; 17 Jun 2015 01:21:01 -0700 Received: from hasmsx108.ger.corp.intel.com (10.184.198.18) by IRSMSX106.ger.corp.intel.com (163.33.3.31) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 17 Jun 2015 09:20:41 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.220]) by hasmsx108.ger.corp.intel.com ([169.254.9.206]) with mapi id 14.03.0224.002; Wed, 17 Jun 2015 11:20:40 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: New revision of the draft-moses-dmm-dhcp-ondemand-mobility I-D Thread-Index: AdCo1n5b18AzoxvZSg6NcUSyCyOLLQ== Date: Wed, 17 Jun 2015 08:20:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813493F0E1HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] New revision of the draft-moses-dmm-dhcp-ondemand-mobility I-D X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 08:21:02 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813493F0E1HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, We have uploaded a new revision of the draft-moses-dmm-dhcp-ondemand-mobili= ty I-D. This revision includes the following: 1. Support for requesting a specific type for an IPv6 prefix as well a= s an IPv6 address 2. Add a new DHCPv6 option for a client to request a specific prefix (= expressing its desire to be served by a specific Mobility Anchor) 3. Added diagrams and corrected text The first addition was in reply for a request from several people to includ= e prefix delegation support. Please review and send us comments. Thanks, Alper and Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC2813493F0E1HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Hi,
 
We have uploaded a new revision of the draft-moses-dmm-dhcp-ondemand-m= obility I-D.
 
This revision includes the following:
  1. Support for requesting a specific type for an IPv6 prefix as well as an= IPv6 address
  2. Add a new DHCPv6 option for a client to request a spe= cific prefix (expressing its desire to be served by a specific Mobility Anc= hor)
  3. Added diagrams and corrected text
 
The first addition was in reply for a request from several people to i= nclude prefix delegation support.
 
Please review and send us comments.
 
Thanks,
        Alper and Danny
 
 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC2813493F0E1HASMSX106gercor_-- From nobody Wed Jun 17 17:05:37 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000301B2EB5 for ; Wed, 17 Jun 2015 17:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MwgV7a9Fg2e for ; Wed, 17 Jun 2015 17:05:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF491B2EB6 for ; Wed, 17 Jun 2015 17:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14645; q=dns/txt; s=iport; t=1434585934; x=1435795534; h=from:to:subject:date:message-id:mime-version; bh=/R+vrAzsoEwjgHDxyRB0K16YauFF234LlylIb26qC6k=; b=A7BV7UocGXwlpLCcQ4I8zJDPSntnRwXdDhpLZJgvBynSULeWqOhnUjhn Od/+QjJzjP4bZ+wm18KROA0EZGoP/4b04IGrOK0YcqmUw1C9bNuoD++D3 0OhJML1PTnnDuXcB0w/hG/kbS7nAmRQ3kM6QxhlE462jlqe4HIvObnjAw E=; X-Files: WebEx_Meeting.ics : 4155 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BzAQAPCoJV/49dJa1CFwOCRUtUXwa8eWYJZwV7hXaBOTgUAQEBAQEBAYEKhCcCZgwVBAEcGAQMDBkXJAMEIYghDTqeSpUOkR0BAQEBAQEBAwEBAQEBAQEBARkEjiyBVykKAQwcB4QTBZNrAYIhgU1kYoN0gh6BNBSDdo8Ig1smY4EoHIEDT28BgUWBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,636,1427760000"; d="ics'?scan'208,217";a="4432671" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jun 2015 00:05:33 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5I05Xse030516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jun 2015 00:05:33 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 19:05:33 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: DMM WT#4 - 2 Discussion Thread-Index: AQHQqVp+RxL3wk/aWEWip5z76V5+ZA== Date: Thu, 18 Jun 2015 00:05:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [10.32.246.217] Content-Type: multipart/mixed; boundary="_004_D1A7551B1C50F2sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: [DMM] DMM WT#4 - 2 Discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 00:05:37 -0000 --_004_D1A7551B1C50F2sgundaveciscocom_ Content-Type: multipart/alternative; boundary="_000_D1A7551B1C50F2sgundaveciscocom_" --_000_D1A7551B1C50F2sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for all the discussion on the WT#4 call. Attendees: Marco Liebsch, D= anny Moses, Jouni Korhonen, Dapeng Liu, Seil, Vic Liu, Fu Qiao, Sri .. The Poll is now closed for the next call. Date: Tuesday, June 23rd at 7AM PDT WebEx Details below Agenda: 1. Seil Jeon will present his new proposal 2. Anthony Chen will talk about "Functions of Anchor=94 (Tentative) 3. Follow up discussion on the attribute based node selection/Deployment= models 4. Follow up discussion on the CP/DP interface in relation to the WT4 di= scussions Hi, Sri Gundavelli, You are the host for this WebEx meeting. Host key: 480131 (Use this to reclaim host privileges.) DMM WT#4 Discussion Tuesday, June 23, 2015 7:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 1 hr 30 mi= ns Join WebEx meeting Meeting number: 209 370 954 Meeting password: DMM Join by phone +1-408-525-6800 Call-in toll number (US/Canada) +1-866-432-9903 Call-in toll-free number (US/Canada) Access code: 209 370 954 Global call-in numbers | Toll-free calling restric= tions Add this meeting to your calendar. Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. You should inform all meeting attendees prior to re= cording if you intend to record the meeting. --_000_D1A7551B1C50F2sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks for all the discussion on the WT#4 call. Attendees: Marco Liebs= ch, Danny Moses, Jouni Korhonen, Dapeng Liu, Seil, Vic Liu, Fu Qiao,  = Sri ..

The Poll is now closed for the next call.

Date: Tuesday, June 23rd at 7AM PDT
WebEx Details below
Agenda:
  1. Seil Jeon will present his new proposal
  2. Anthony Chen will talk = about "Functions of Anchor=94 (Tentative)
  3. Follow up discussion= on the attribute based node selection/Deployment models
  4. Follow up = discussion on the CP/DP interface in relation to the WT4 discussions




Hi, Sri Gundavelli,
You are the host for this Web= Ex meeting.
Host key: 480131 (Use this to reclaim host priv= ileges.)
 
DMM WT#4 Discussion
Tuesday, June 23, 2015
7:00 am  |  Pacific Daylight Time (San Francisco, G= MT-07:00)  |  1 hr 30 mins
 
Join WebEx meeting
Meeting number: 209 370 954
Meeting password: DMM
 
Join by phone
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 209 370 954
Global call-in numbers  | = ; Toll-free calling restrictions
 
Add this meeting to your calendar.
 
Can't join= the meeting? Contact support.
 
IMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during the = session to be recorded, which may be discoverable in a legal matter. You sh= ould inform all meeting attendees prior to recording if you intend to record the meeting.
--_000_D1A7551B1C50F2sgundaveciscocom_-- --_004_D1A7551B1C50F2sgundaveciscocom_ Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=4155; creation-date="Thu, 18 Jun 2015 00:05:33 GMT"; modification-date="Thu, 18 Jun 2015 00:05:33 GMT" Content-ID: <7FA738A108801B41ABCCE762AAD64196@emea.cisco.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpQYWNpZmljIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA3MDAKVFpPRkZTRVRUTzotMDgwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDgw MApUWk9GRlNFVFRPOi0wNzAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJTcmkgR3VuZGF2ZWxs aSI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1GQUxTRTpNQUlMVE86c2d1bmRhdmVAY2lzY28u Y29tCk9SR0FOSVpFUjtDTj0id2ViZXgiOk1BSUxUTzptZXNzZW5nZXJAd2ViZXguY29tCkRUU1RB UlQ7VFpJRD0iUGFjaWZpYyBUaW1lIjoyMDE1MDYyM1QwNzAwMDAKRFRFTkQ7VFpJRD0iUGFjaWZp YyBUaW1lIjoyMDE1MDYyM1QwODMwMDAKTE9DQVRJT046aHR0cHM6Ly9jaXNjby53ZWJleC5jb20v Y2lzY29zYWxlcwpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjE0MzQ1ODQ3NzMKVUlEOjE2YzFlMTYw LTIyNDMtNDM1OS04ODlmLWRiNGFhNTYzOTEyZgpEVFNUQU1QOjIwMTUwNjIzVDE0MDAwMFoKREVT Q1JJUFRJT046XG5Ib3N0IGtleTogNDgwMTMxXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRw czovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bWE2ZDdlNWMxZjk3ZTRk ODc0N2Y4YmFkZjdhYjRjNDZlXG5NZWV0aW5nIG51bWJlcjogMjA5IDM3MCA5NTRcbk1lZXRpbmcg cGFzc3dvcmQ6IERNTVxuXG5cbkpPSU4gQlkgUEhPTkVcbisxLTQwOC01MjUtNjgwMCBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG4rMS04NjYtNDMyLTk5MDMgQ2FsbC1pbiB0b2xsLWZy ZWUgbnVtYmVyIChVUy9DYW5hZGEpXG5BY2Nlc3MgY29kZTogMjA5IDM3MCA5NTRcblxuR2xvYmFs IGNhbGwtaW4gbnVtYmVyczpcbmh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvZ2xv YmFsY2FsbGluLnBocD9zZXJ2aWNlVHlwZT1NQyZFRD0zMTY5MzIyMDcmdG9sbEZyZWU9MVxuXG5U b2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxuaHR0cDovL3d3dy53ZWJleC5jb20vcGRm L3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/ IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxl cy9tY1xuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBz ZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhl IHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBs ZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5mb3JtIGFsbCBtZWV0aW5nIGF0dGVuZGVlcyBwcmlv ciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byByZWNvcmQgdGhlIG1lZXRpbmcuXG4KWC1B TFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPjxG T05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJBcmlhbCI+ICZuYnNwOzxCUj5Ib3N0 IGtleTogNDgwMTMxPC9GT05UPiZuYnNwOzxCUj4mbmJzcDs8QlI+Jm5ic3A7PEJSPiA8Rk9OVCBT SVpFPSI0IiBGQUNFPSJBUklBTCI+CQk8YQkJCQkJaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5j b20vY2lzY29zYWxlcy9qLnBocD9NVElEPW1hNmQ3ZTVjMWY5N2U0ZDg3NDdmOGJhZGY3YWI0YzQ2 ZSI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4 IG1lZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9G T05UPgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPjIwOSAzNzAgOTU0PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8 L3RhYmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+RE1NPC9GT05UPjwvdGQ+PC90cj48L3Rh YmxlPgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7 PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+ PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPisxLTQw OC01MjUtNjgwMDwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8 L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPjxzdHJvbmc+KzEtODY2LTQzMi05OTAzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsLWZy ZWUgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogMjA5IDM3MCA5NTQ8L0ZPTlQ+ Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2ds b2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9TUMmRUQ9MzE2OTMyMjA3JnRvbGxGcmVlPTEiPjxG T05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+R2xvYmFsIGNhbGwtaW4g bnVtYmVyczwvRk9OVD48L2E+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDs8L0ZPTlQ+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3Rv bGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBG QUNFPSJhcmlhbCI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5i c3A7IDxCUj48L0ZPTlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4J PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9tYyI+CTxGT05UIFNJ WkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Q29udGFjdCBzdXBwb3J0LjwvRk9O VD48L2E+CSZuYnNwOzxCUj4mbmJzcDs8QlI+PEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEi IEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2Vi RXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5n IHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGlu IGEgbGVnYWwgbWF0dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMg cHJpb3IgdG8gcmVjb3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLjwv Rk9OVD48L0ZPTlQ+ClNVTU1BUlk6RE1NIFdUIzQgRGlzY3Vzc2lvbgpQUklPUklUWTo1CkNMQVNT OlBVQkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQxNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJ UFRJT046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK --_004_D1A7551B1C50F2sgundaveciscocom_-- From nobody Fri Jun 19 06:44:51 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7211A011E for ; Fri, 19 Jun 2015 06:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj9GGloAkUcA for ; Fri, 19 Jun 2015 06:44:47 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E3B1A0117 for ; Fri, 19 Jun 2015 06:44:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AE4FE10A0A2 for ; Fri, 19 Jun 2015 15:44:45 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCnavEp47Bpc for ; Fri, 19 Jun 2015 15:44:45 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 8AC7710A0A1 for ; Fri, 19 Jun 2015 15:44:13 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.4]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 15:36:21 +0200 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: draft-ietf-dmm-fpc-cpdp-00 - update plans Thread-Index: AdCqlHXxklWEzLGaQkiXxrLVjUwt7g== Date: Fri, 19 Jun 2015 13:36:21 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D99B10FDA@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D99B10FDAPALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 13:44:50 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D99B10FDAPALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, draft-ietf-dmm-fpc-cpdp-00 is out since May. So far we did not receive any= serious issue to address, which is good. Driving the draft towards a more mature state, I see the following main ite= ms to address: (1) Completion of properties and attributes (2) Adoption of a standard conform modelling In terms of (1), the importance to include QoS attributes has been raised f= rom different sides. I'll make a proposal how to cover this in an update on the DMM ML using a s= eparate eMail. Other attributes we may need to cover are about monitoring/reporting. In terms of (2) we heard different opinions about keeping this document at = the level of information models or be more specific by adopting data modeling. So far the document is prett= y hybrid ;-), core part is more about clear definition and description of messages and information to apply betwe= en Client and Agent. In the appendix the draft includes a (so far experimental) YANG model. Please state your opinion here to see what the WG expects from the document= . If we adopt information modeling, this seems straightforward from a version which is complete in terms of mes= sages/attributes. If we adopt data modeling, we may need to spend more cycles in agreeing for= mats, alignment, etc. Hope we can discuss on the ML. I'd also like to schedule a WebExt before th= e draft deadline. Will send a doodle around for that. marco --_000_69756203DDDDE64E987BC4F70B71A26D99B10FDAPALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

draft-ietf-dmm-fpc-cpdp-00  is out since May. So far we did not receiv= e any serious issue to address, which is good.

Driving the draft towards a more mature state, I see= the following main items to address:

 

(1)    Completion of properties and attributes<= /p>

(2)    Adoption of a standard conform modelling=

 

In terms of (1), the importance to include QoS attri= butes has been raised from different sides.

I’ll make a proposal how to cover this in an u= pdate on the DMM ML using a separate eMail.

Other attributes we may need to cover are about moni= toring/reporting.

 

In terms of (2) we heard different opinions about ke= eping this document at the level of information models
or be more specific by adopting data modeling. So far the document is prett= y hybrid ;-), core part is more about
clear definition and description of messages and information to apply betwe= en Client and Agent. In the appendix
the draft includes a (so far experimental) YANG model.

 

Please state your opinion here to see what the WG ex= pects from the document. If we adopt information modeling,
this seems straightforward from a version which is complete in terms of mes= sages/attributes.
If we adopt data modeling, we may need to spend more cycles in agreeing for= mats, alignment, etc.

 

Hope we can discuss on the ML. I’d also like t= o schedule a WebExt before the draft deadline. Will send a
doodle around for that.

 

marco

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D99B10FDAPALLENEofficehd_-- From nobody Fri Jun 19 07:39:32 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2794F1A1C06 for ; Fri, 19 Jun 2015 07:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy1ZCK68i8m7 for ; Fri, 19 Jun 2015 07:39:29 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871E31A1DBC for ; Fri, 19 Jun 2015 07:39:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5E52410A0A5 for ; Fri, 19 Jun 2015 16:39:28 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzWjmumSlBxD for ; Fri, 19 Jun 2015 16:39:28 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 3418910A0A1 for ; Fri, 19 Jun 2015 16:38:56 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.4]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 16:31:58 +0200 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: How to cover QoS in draft-ietf-dmm-fpc-cpdp-00 Thread-Index: AdCqlqG+vSDwdR/7TbmtOhQkgpX/0w== Date: Fri, 19 Jun 2015 14:31:58 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D99B110C5@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D99B110C5PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: [DMM] How to cover QoS in draft-ietf-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 14:39:31 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D99B110C5PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, as announced in my previous eMail, please find below a proposal how to addr= ess QoS in draft-ietf-dmm-fpc-cpdp-00. The draft adopts a model to abstract forwarding and policy configuration fo= r DMM using logical ports which bind properties. This can be applied at Agents to any D= ata-Plane Node (DPN) configuration, routers, network controllers, switches. Adding QoS properties per port should be in-line with RFC7222 in case of GB= R and MBR. More needs to be considered for aggregates, such as per-MN-AMBR, per-Sessio= n-AMBR. Here, the Control-Plane logic may accomplish configuration of the Data-Plan= e for an MN or Session using a single port or multiple ports. This can be tackled by permitting a Client to bind an AMBR attribute/value = to a single port or to a group of ports. Whether the aggregate applies per-MN or per Session, s= hould be kept in the application logic and be kept transparent to the Data-Plane. Information coming with an AMBR attribute needs to comprise a list of port identifies (PRT_ID) to which the aggregate applies, like: QOS_AMBR_CONF: Aggregate Bitrate //gives the maximum aggregate value List of Port-IDs //defines the group of ports where metering applies Please let me know if anything is missing. marco --_000_69756203DDDDE64E987BC4F70B71A26D99B110C5PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

as announced in my previous eMail, please find below a proposal how to addr= ess QoS in
draft-ietf-dmm-fpc-cpdp-00.

 

The draft adopts a model to abstract forwarding and = policy configuration for DMM using
logical ports which bind properties. This can be applied at Agents to any D= ata-Plane Node (DPN)
configuration, routers, network controllers, switches.

 

Adding QoS properties per port should be in-line wit= h RFC7222 in case of GBR and MBR.

More needs to be considered for aggregates, such as = per-MN-AMBR, per-Session-AMBR.
Here, the Control-Plane logic may accomplish configuration of the Data-Plan= e for an
MN or Session using a single port or multiple ports.

 

This can be tackled by permitting a Client to bind a= n AMBR attribute/value to a single port or
to a group of ports. Whether the aggregate applies per-MN or per Session, s= hould be kept
in the application logic and be kept transparent to the Data-Plane.

Information coming with an AMBR attribute needs to c= omprise a list
of port identifies (PRT_ID) to which the aggregate applies, like:

 

= QOS_AMBR_CONF:

=   Aggregate Bitrate  //gives the maximum aggregate value

=   List of Port-IDs   //defines the group of ports where mete= ring applies          

=     

Please let me know if anything is missing.

 

marco

 

 

 

 

 

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D99B110C5PALLENEofficehd_-- From nobody Mon Jun 22 13:04:15 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EDA1ACD24 for ; Mon, 22 Jun 2015 13:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2XcbhISTAFb for ; Mon, 22 Jun 2015 13:04:11 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7460C1A9024 for ; Mon, 22 Jun 2015 13:04:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 73C47109FEC for ; Mon, 22 Jun 2015 22:04:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRblTO6OEY3c for ; Mon, 22 Jun 2015 22:04:09 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 418EE109D49 for ; Mon, 22 Jun 2015 22:04:07 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.4]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Mon, 22 Jun 2015 22:04:07 +0200 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fpc-cpdp-00 - update plans Thread-Index: AdCtJVIe3OBuE4buSNqKrvsgKxXIAQ== Date: Mon, 22 Jun 2015 20:04:06 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D99B1357A@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.211] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D99B1357APALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fpc-cpdp-00 - update plans X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 20:04:14 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D99B1357APALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find a link to a doodle below to find a suitable date for a WebEx wh= ere we can discuss and agree on the FPC draft update. Please also think about the open items I addressed in my previous eMails or= any additional item you have in mind and which we need to consider for a draft update. Ple= ase use the mailing list or the issue tracker to address these items for discussion. http://doodle.com/5s9dhzcy6w8ds6ae Thanks, Marco From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Freitag, 19. Juni 2015 15:36 To: dmm@ietf.org Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans Folks, draft-ietf-dmm-fpc-cpdp-00 is out since May. So far we did not receive any= serious issue to address, which is good. Driving the draft towards a more mature state, I see the following main ite= ms to address: (1) Completion of properties and attributes (2) Adoption of a standard conform modelling In terms of (1), the importance to include QoS attributes has been raised f= rom different sides. I'll make a proposal how to cover this in an update on the DMM ML using a s= eparate eMail. Other attributes we may need to cover are about monitoring/reporting. In terms of (2) we heard different opinions about keeping this document at = the level of information models or be more specific by adopting data modeling. So far the document is prett= y hybrid ;-), core part is more about clear definition and description of messages and information to apply betwe= en Client and Agent. In the appendix the draft includes a (so far experimental) YANG model. Please state your opinion here to see what the WG expects from the document= . If we adopt information modeling, this seems straightforward from a version which is complete in terms of mes= sages/attributes. If we adopt data modeling, we may need to spend more cycles in agreeing for= mats, alignment, etc. Hope we can discuss on the ML. I'd also like to schedule a WebExt before th= e draft deadline. Will send a doodle around for that. marco --_000_69756203DDDDE64E987BC4F70B71A26D99B1357APALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find a link to = a doodle below to find a suitable date for a WebEx where we
can discuss and agree on the FPC draft update.

 

Please also think abou= t the open items I addressed in my previous eMails or any additional
item you have in mind and which we need to consider for a draft update. Ple= ase use the mailing
list or the issue tracker to address these items for discussion.=

 

ht= tp://doodle.com/5s9dhzcy6w8ds6ae

 

Thanks,

Marco

 

 

 

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 19. Juni 2015 15:36
To: dmm@ietf.org
Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans<= /span>

 

Folks,

draft-ietf-dmm-fpc-cpdp-00  is out since May. So far we did not receiv= e any serious issue to address, which is good.

Driving the draft towards a more mature state, I see= the following main items to address:

 

(1)    Completion of properties and attributes<= /p>

(2)    Adoption of a standard conform modelling=

 

In terms of (1), the importance to include QoS attri= butes has been raised from different sides.

I’ll make a proposal how to cover this in an u= pdate on the DMM ML using a separate eMail.

Other attributes we may need to cover are about moni= toring/reporting.

 

In terms of (2) we heard different opinions about ke= eping this document at the level of information models
or be more specific by adopting data modeling. So far the document is prett= y hybrid ;-), core part is more about
clear definition and description of messages and information to apply betwe= en Client and Agent. In the appendix
the draft includes a (so far experimental) YANG model.

 

Please state your opinion here to see what the WG ex= pects from the document. If we adopt information modeling,
this seems straightforward from a version which is complete in terms of mes= sages/attributes.
If we adopt data modeling, we may need to spend more cycles in agreeing for= mats, alignment, etc.

 

Hope we can discuss on the ML. I’d also like t= o schedule a WebExt before the draft deadline. Will send a
doodle around for that.

 

marco

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D99B1357APALLENEofficehd_-- From nobody Tue Jun 23 08:37:17 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706A91A6EF4 for ; Tue, 23 Jun 2015 08:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh0jqelfW3K0 for ; Tue, 23 Jun 2015 08:37:13 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D141A6EE6 for ; Tue, 23 Jun 2015 08:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10659; q=dns/txt; s=iport; t=1435073833; x=1436283433; h=from:to:subject:date:message-id:mime-version; bh=nNwEDGUvdXEblwxcOGfjsyFjH0F/yb5ozQ9JBjVgfaA=; b=TM+jtyoXs63ifmg2WWLsSGKv7dyahP2+0K5LFEZAuRH66BQ//8C1AWWr VDL9Gjpkj1+ftP2hwez3bnjHgUNfhvuiGsUWdDEwIGPqc+yIMmUPL9bY8 CPxb8DmYldsGg1/6KexjbUuihcF2xVDvOF5fNUzJFuZ0C/Npx5MqyTORC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BeAQD1e4lV/4gNJK1BFwOCRUtUXwa8eWYJaAV7hXYCgUw4FAEBAQEBAQGBCoQiAQICAmYMFQQBCBEDAQIVBAwDIhcUCQcDBBOILw06pX2VDpETAQEBAQEBBAEBAQEBAQEBGgSLRoRCMwEMChIHhBMFk38BhFdig3mCHoE6FIN8imqEJoNbJmOBKRyBA09vAYFFgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,666,1427760000"; d="scan'208,217";a="162040395" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 23 Jun 2015 15:37:12 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t5NFbCP8027038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Jun 2015 15:37:12 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.60]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 10:37:12 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: [DMM] DMM WT#4 - 2 Discussion Thread-Index: AQHQrcp5zd6/9Pzly0+Pp0y7ZUqENw== Date: Tue, 23 Jun 2015 15:37:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.32.246.217] Content-Type: multipart/alternative; boundary="_000_D1AEC8DC1C614Dsgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] DMM WT#4 - 2 Discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 15:37:15 -0000 --_000_D1AEC8DC1C614Dsgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for all the discussion today on the WT#4 call. Attendees: Carlos Jes= =FAs Bernardos, Satoru Matsushima, Seil Jeon, KJ Sun, Anthony Chen & Sri - Update from Seil - Update from Anthony - CPA/DPA sub-functions and roles; Session Re-anchoring; Flow stitching - Next steps on coming out with consolidated initial docs from WT#4 From: dmm > on behalf of = Sri Gundavelli > Date: Wednesday, June 17, 2015 at 5:05 PM To: "dmm@ietf.org" > Subject: [DMM] DMM WT#4 - 2 Discussion Thanks for all the discussion on the WT#4 call. Attendees: Marco Liebsch, D= anny Moses, Jouni Korhonen, Dapeng Liu, Seil, Vic Liu, Fu Qiao, Sri .. The Poll is now closed for the next call. Date: Tuesday, June 23rd at 7AM PDT WebEx Details below Agenda: 1. Seil Jeon will present his new proposal 2. Anthony Chen will talk about "Functions of Anchor=94 (Tentative) 3. Follow up discussion on the attribute based node selection/Deployment= models 4. Follow up discussion on the CP/DP interface in relation to the WT4 di= scussions Hi, Sri Gundavelli, You are the host for this WebEx meeting. Host key: 480131 (Use this to reclaim host privileges.) DMM WT#4 Discussion Tuesday, June 23, 2015 7:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 1 hr 30 mi= ns Join WebEx meeting Meeting number: 209 370 954 Meeting password: DMM Join by phone +1-408-525-6800 Call-in toll number (US/Canada) +1-866-432-9903 Call-in toll-free number (US/Canada) Access code: 209 370 954 Global call-in numbers | Toll-free calling restric= tions Add this meeting to your calendar. Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. You should inform all meeting attendees prior to re= cording if you intend to record the meeting. --_000_D1AEC8DC1C614Dsgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <265F3BBD2AC6A0408BA36519F28C4D03@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks for all the discussion today on the WT#4 call. Attendees: Carlo= s Jes=FAs Bernardos, Satoru Matsushima, Seil Jeon, KJ  Sun, = Anthony Chen & Sri 

- Update from Seil
- Update from Anthony
- CPA/DPA sub-functions and roles; Session Re-anchoring; Flow stitchin= g 
- Next steps on coming out with consolidated initial docs from WT#4



From: dmm <dmm-bounces@ietf.org> on behalf of Sri Gundavelli= <sgundave@cisco.com>
Date: Wednesday, June 17, 2015 at 5= :05 PM
To: "dmm@ietf.org" <dmm@ietf.= org>
Subject: [DMM] DMM WT#4 - 2 Discuss= ion

Thanks for all the discussion on the WT#4 call. Attendees: Marco Liebs= ch, Danny Moses, Jouni Korhonen, Dapeng Liu, Seil, Vic Liu, Fu Qiao,  = Sri ..

The Poll is now closed for the next call.

Date: Tuesday, June 23rd at 7AM PDT
WebEx Details below
Agenda:
  1. Seil Jeon will present his new proposal
  2. Anthony Chen will talk = about "Functions of Anchor=94 (Tentative)
  3. Follow up discussion= on the attribute based node selection/Deployment models
  4. Follow up = discussion on the CP/DP interface in relation to the WT4 discussions




Hi, Sri Gundavelli,
You are the host for this Web= Ex meeting.
Host key: 480131 (Use this to reclaim host priv= ileges.)
 
DMM WT#4 Discussion
Tuesday, June 23, 2015
7:00 am  |  Pacific Daylight Time (San Francisco, G= MT-07:00)  |  1 hr 30 mins
 
Join WebEx meeting
Meeting number: 209 370 954
Meeting password: DMM
 
Join by phone
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 209 370 954
Global call-in numbers  | = ; Toll-free calling restrictions
 
Add this meeting to your calendar.
 
Can't join= the meeting? Contact support.
 
IMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during the = session to be recorded, which may be discoverable in a legal matter. You sh= ould inform all meeting attendees prior to recording if you intend to record the meeting.
--_000_D1AEC8DC1C614Dsgundaveciscocom_-- From nobody Wed Jun 24 16:33:57 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C8F1B2FA1 for ; Wed, 24 Jun 2015 16:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z15QuKemUlOh for ; Wed, 24 Jun 2015 16:33:54 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2507B1B2FF9 for ; Wed, 24 Jun 2015 16:33:51 -0700 (PDT) Received: from [2.81.122.46] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77875906 for dmm@ietf.org; Thu, 25 Jun 2015 00:33:50 +0100 From: "Seil Jeon" To: References: <20150624232634.16784.6332.idtracker@ietfa.amsl.com> In-Reply-To: <20150624232634.16784.6332.idtracker@ietfa.amsl.com> Date: Thu, 25 Jun 2015 00:33:51 +0100 Message-ID: <000001d0aed6$3a919c40$afb4d4c0$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF7hNtgGMRlfaOE8JwQFp0uT7yGQ55moTyQ Content-Language: ko Archived-At: Subject: [DMM] FW: New Version Notification for draft-sijeon-dmm-use-cases-api-source-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 23:33:56 -0000 We just have submitted the update of the use cases and API extension = draft (-01), based on the discussion in the list. Regards, Seil Jeon -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, June 25, 2015 12:27 AM To: Young-Han Kim; Younghan Kim; Sergio Figueiredo; Seil Jeon; Seil = Jeon; Sergio Figueiredo Subject: New Version Notification for = draft-sijeon-dmm-use-cases-api-source-01.txt A new version of I-D, draft-sijeon-dmm-use-cases-api-source-01.txt has been successfully submitted by Seil Jeon and posted to the IETF = repository. Name: draft-sijeon-dmm-use-cases-api-source Revision: 01 Title: Use Cases and API Extension for Source IP Address Selection Document date: 2015-06-24 Group: Individual Submission Pages: 7 URL: = https://www.ietf.org/internet-drafts/draft-sijeon-dmm-use-cases-api-sourc= e-01.txt Status: = https://datatracker.ietf.org/doc/draft-sijeon-dmm-use-cases-api-source/ Htmlized: = https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-01 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-sijeon-dmm-use-cases-api-source= -01 Abstract: This draft specifies and analyzes the expected cases regarding the selection of a proper source IP address and address type based on the application features over a distributed mobility management (DMM) network. It also provides available selection methods to better achieve DMM goals in the specified scenarios. = =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. The IETF Secretariat From nobody Thu Jun 25 03:22:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002A51B3515 for ; Thu, 25 Jun 2015 03:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-u9ay86jNiW for ; Thu, 25 Jun 2015 03:22:49 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 7EFF21B32DC for ; Thu, 25 Jun 2015 03:22:47 -0700 (PDT) Received: by igin14 with SMTP id n14so52237778igi.1 for ; Thu, 25 Jun 2015 03:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9bfXqCMlYnaJu+qf1LYU8JW1NI15wrkFrRDmTWAnEcM=; b=tj5dxA5gt2a1iSIjyc5nL46MTvJ6gPSIsfaoPFmbKQfZ7Dgb9gCF5EXGV2ShNYIGGP bsTe2mjwK/dFfJYH4103nrqtbwcoXlAGO5zQldTcPLY5FptbzDoiI9r7dwg60jQyrPiy Yy2wfaJtCo+xkrkp4jzq4E7m98KWhH2jPMjhwo16H2l+k8udxVqnNleMsb0MEdeCJN2K AR7j8CNT9jF01h7RnuoA47d2RIvtFk1sW+TlQ4Ag8xPmsAb6VaVWf7mJicH3s0DO7Nkz D5UW3zNYoZRedst46aaeKB2+5282d167J4iO2T5YM5Y8zLmauUceT5BNURKrql7+hB+K 5jcQ== MIME-Version: 1.0 X-Received: by 10.43.164.66 with SMTP id mr2mr41854356icc.85.1435227766974; Thu, 25 Jun 2015 03:22:46 -0700 (PDT) Received: by 10.36.155.139 with HTTP; Thu, 25 Jun 2015 03:22:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jun 2015 19:22:46 +0900 Message-ID: From: Satoru Matsushima To: "sarikaya@ieee.org" Content-Type: multipart/alternative; boundary=001a11c2f3b238f002051955011f Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] vepc draft Rev. 04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 10:22:51 -0000 --001a11c2f3b238f002051955011f Content-Type: text/plain; charset=UTF-8 Hi Behcet, Sorry for my late response. As I looked over your dmm-for-wifi draft, I found two protocols to be used to separate control and data plane such as XMPP and OpenFlow. It seems like you want to work on that protocols to be implemented in data plane nodes. OpenFlow is another forum controlled protocol so I don't touch it in the IETF. XMPP sounds nice. If you adopt XMPP with same model of draft-ietf-l3vpn-end-system, it almost same with using BGP like the vEPC draft. But what I mentioned FPCP in vEPC is as a way to export mobility info to BGP speaker from control-plane nodes of mobility management. And more, many parameters should be aligned for these nodes to utilizing data-plane network so that the config data model should also be defined in FPCP. I think that's not part of signaling protocol roles. Thought? Regards, --satoru On Wed, Jun 3, 2015 at 4:25 AM, Behcet Sarikaya wrote: > Hi Matsushima-san, > > On Fri, May 29, 2015 at 8:24 AM, Satoru Matsushima > wrote: > > Hi Behcet-san, > > > > On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya > > > wrote: > >> > >> Hi Satoru, > >> > >> Thanks for your reply. > >> > >> Let me continue the discussion with your text in Section 3.2 where you > >> mention > >> vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) > >> that defines FPCP Agent function and Client function. > >> > >> I don't understand how you could justify defining a new forwarding > >> policy configuration protocol to do this Agent/Client functionality? > >> Why not use similar Agent/Client models that are being defined rather > >> than defining a new protocol? > >> I think this point requires much stronger justification which I could > >> not see in Section 3.2. > >> > > > > The text just describes about a part of where FPCP may be applicable in > > vEPC. > > > > > > > >> > >> Are you that we have to to reinvent the wheel, rather than reusing > >> something that is already available? How are we going to reinvent that > >> wheel also remains to be seen, I think. > >> > > > > Point taken. Which kind of wheel do you have in mind? > > Please check this draft: > https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-02 > > Regards, > > Behcet > > > > cheers, > > --satoru > > > --001a11c2f3b238f002051955011f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Behcet,=C2=A0

Sorry for my late resp= onse.

As I looked over your dmm-for-wifi draft, I = found two protocols to be used to separate
control and data plane= such as XMPP and OpenFlow.

It seems like you want= to work on that protocols to be implemented in data plane nodes.
OpenFlow is another forum controlled protocol so I don't touch it in t= he IETF.
XMPP sounds nice. If you adopt XMPP with same model of d= raft-ietf-l3vpn-end-system,=C2=A0
it almost same with using BGP l= ike the vEPC draft.

But what I mentioned FPCP in v= EPC is as a way to export mobility info to BGP speaker
from contr= ol-plane nodes of mobility management.=C2=A0

And m= ore, many parameters should be aligned for these nodes to utilizing data-pl= ane=C2=A0
network so that the config data model should also be de= fined in FPCP. I think that's not=C2=A0
part of signaling pro= tocol roles.

Thought?

Reg= ards,
--satoru



=

On Wed, Jun= 3, 2015 at 4:25 AM, Behcet Sarikaya <sarikaya2012@gmail.com><= /span> wrote:
=C2=A0Hi Matsushima-san,

On Fri, May 29, 2015 at 8:24 AM, Satoru Matsushima
<satoru.matsushima@gmail.= com> wrote:
> Hi Behcet-san,
>
> On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya <sarikaya2012@gmail.com>
> wrote:
>>
>> Hi Satoru,
>>
>> Thanks for your reply.
>>
>> Let me continue the discussion with your text in Section 3.2 where= you
>> mention
>> vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)<= br> >> that defines FPCP Agent function and Client function.
>>
>> I don't understand how you could justify defining a new forwar= ding
>> policy configuration protocol to do this Agent/Client functionalit= y?
>> Why not use similar Agent/Client models that are being defined rat= her
>> than defining a new protocol?
>> I think this point requires much stronger justification which I co= uld
>> not see in Section 3.2.
>>
>
> The text just describes about a part of where FPCP may be applicable i= n
> vEPC.
>
>
>
>>
>> Are you that we have to to reinvent the wheel, rather than reusing=
>> something that is already available? How are we going to reinvent = that
>> wheel also remains to be seen, I think.
>>
>
> Point taken. Which kind of wheel do you have in mind?

=C2=A0Please check this draft:
https://tools.ietf.org/html/draft-sarikay= a-dmm-for-wifi-02

Regards,

Behcet
>
> cheers,
> --satoru
>

--001a11c2f3b238f002051955011f-- From nobody Fri Jun 26 01:48:07 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644421A03C7 for ; Fri, 26 Jun 2015 01:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHF7_XMizMtt for ; Fri, 26 Jun 2015 01:48:02 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929841A03B3 for ; Fri, 26 Jun 2015 01:48:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 176AE10A12E for ; Fri, 26 Jun 2015 10:48:01 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIQY-Ej1H4Dh for ; Fri, 26 Jun 2015 10:48:00 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id E58AD10A12D for ; Fri, 26 Jun 2015 10:47:58 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.4]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Fri, 26 Jun 2015 10:47:58 +0200 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fpc-cpdp-00 - update plans Thread-Index: AdCtJVIe3OBuE4buSNqKrvsgKxXIAQCxyO6g Date: Fri, 26 Jun 2015 08:47:58 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D99B15229@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D99B1357A@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D99B1357A@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D99B15229PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fpc-cpdp-00 - update plans X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:48:06 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D99B15229PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, the WebEx about progressing the FPC draft will be on Wednesday, 1st July 2015, Time: 16:00 CEST, Duration: 90 min. I'll send WebEx details and an agenda around in a separate eMail. marco From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Montag, 22. Juni 2015 22:04 To: dmm@ietf.org Subject: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fp= c-cpdp-00 - update plans Please find a link to a doodle below to find a suitable date for a WebEx wh= ere we can discuss and agree on the FPC draft update. Please also think about the open items I addressed in my previous eMails or= any additional item you have in mind and which we need to consider for a draft update. Ple= ase use the mailing list or the issue tracker to address these items for discussion. http://doodle.com/5s9dhzcy6w8ds6ae Thanks, Marco From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Freitag, 19. Juni 2015 15:36 To: dmm@ietf.org Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans Folks, draft-ietf-dmm-fpc-cpdp-00 is out since May. So far we did not receive any= serious issue to address, which is good. Driving the draft towards a more mature state, I see the following main ite= ms to address: (1) Completion of properties and attributes (2) Adoption of a standard conform modelling In terms of (1), the importance to include QoS attributes has been raised f= rom different sides. I'll make a proposal how to cover this in an update on the DMM ML using a s= eparate eMail. Other attributes we may need to cover are about monitoring/reporting. In terms of (2) we heard different opinions about keeping this document at = the level of information models or be more specific by adopting data modeling. So far the document is prett= y hybrid ;-), core part is more about clear definition and description of messages and information to apply betwe= en Client and Agent. In the appendix the draft includes a (so far experimental) YANG model. Please state your opinion here to see what the WG expects from the document= . If we adopt information modeling, this seems straightforward from a version which is complete in terms of mes= sages/attributes. If we adopt data modeling, we may need to spend more cycles in agreeing for= mats, alignment, etc. Hope we can discuss on the ML. I'd also like to schedule a WebExt before th= e draft deadline. Will send a doodle around for that. marco --_000_69756203DDDDE64E987BC4F70B71A26D99B15229PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks, the WebEx about= progressing the FPC draft will be on

 

Wednesday, 1st July 2015,

Time: 16:00 CEST,=

Duration: 90 min.=

 

I’ll send WebEx = details and an agenda around in a separate eMail.

 

marco

 

 

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Montag, 22. Juni 2015 22:04
To: dmm@ietf.org
Subject: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf= -dmm-fpc-cpdp-00 - update plans

 

Please find a link to = a doodle below to find a suitable date for a WebEx where we
can discuss and agree on the FPC draft update.

 

Please also think abou= t the open items I addressed in my previous eMails or any additional
item you have in mind and which we need to consider for a draft update. Ple= ase use the mailing
list or the issue tracker to address these items for discussion.=

 

ht= tp://doodle.com/5s9dhzcy6w8ds6ae

 

Thanks,

Marco

 

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 19. Juni 2015 15:36
To: dmm@ietf.org
Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans<= /span>

 

Folks,

draft-ietf-dmm-fpc-cpdp-00  is out since May. So far we did not receiv= e any serious issue to address, which is good.

Driving the draft towards a more mature state, I see= the following main items to address:

 

(1)    Completion of properties and attributes<= /p>

(2)    Adoption of a standard conform modelling=

 

In terms of (1), the importance to include QoS attri= butes has been raised from different sides.

I’ll make a proposal how to cover this in an u= pdate on the DMM ML using a separate eMail.

Other attributes we may need to cover are about moni= toring/reporting.

 

In terms of (2) we heard different opinions about ke= eping this document at the level of information models
or be more specific by adopting data modeling. So far the document is prett= y hybrid ;-), core part is more about
clear definition and description of messages and information to apply betwe= en Client and Agent. In the appendix
the draft includes a (so far experimental) YANG model.

 

Please state your opinion here to see what the WG ex= pects from the document. If we adopt information modeling,
this seems straightforward from a version which is complete in terms of mes= sages/attributes.
If we adopt data modeling, we may need to spend more cycles in agreeing for= mats, alignment, etc.

 

Hope we can discuss on the ML. I’d also like t= o schedule a WebExt before the draft deadline. Will send a
doodle around for that.

 

marco

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D99B15229PALLENEofficehd_-- From nobody Fri Jun 26 02:55:33 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A501A889F for ; Fri, 26 Jun 2015 02:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNW0BibMmoAM for ; Fri, 26 Jun 2015 02:55:30 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C352C1A8899 for ; Fri, 26 Jun 2015 02:55:29 -0700 (PDT) Received: by igin14 with SMTP id n14so9973350igi.1 for ; Fri, 26 Jun 2015 02:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TywYoW1MUekpu/1MIkz1hd9F2JkE+0zrjJ9GpfiK9M4=; b=nJ/dSpo2+xU5fWF9LVkxST1BrWgHa/0+fKoPE4ofDuFH7Gc5qCCkEGGrMH+tejmFFl p/ZLACLEf9eDpx+lZ+sr0bCFNy9UIkR4bkMHnA5ziXFFfNlNEqURtaEcL623f/MUsRJV Y7LpsJ3Tb1soIA4pvv1jEurGVkIEz5WHVJydgp7pntQihV3EUyIFDs2GikSJ8p4lUiAm fQ+tk/jBOUJb4bx0SL0TwIm6NOgnCzT1Eesi7W2IN0HSzL2/wFJrxx6kmUm3nDwZ6bTL QV/ai0GurrIkhvrgSHrurGygXHVgIyeXuDwQKBGRDKjmmZzOI5dhpsz9RqGgDhQp0ykN PGGA== MIME-Version: 1.0 X-Received: by 10.50.13.98 with SMTP id g2mr2205642igc.16.1435312529255; Fri, 26 Jun 2015 02:55:29 -0700 (PDT) Received: by 10.36.155.139 with HTTP; Fri, 26 Jun 2015 02:55:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Jun 2015 18:55:29 +0900 Message-ID: From: Satoru Matsushima To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=089e0129464c72d6b2051968bd48 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] DMM WT#4 - 2 Discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 09:55:32 -0000 --089e0129464c72d6b2051968bd48 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mainly for Anthony, To support IPv4 for anchor node which connected to IPv6-only network, some IPv6 transition solutions would be one of the anchor function. Please take a look at http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-04#sectio= n-3.5 Regards, --satoru On Wed, Jun 24, 2015 at 12:37 AM, Sri Gundavelli (sgundave) < sgundave@cisco.com> wrote: > Thanks for all the discussion today on the WT#4 call. Attendees: Carlos > Jes=C3=BAs Bernardos, Satoru Matsushima, Seil Jeon, KJ Sun, Anthony Chen= & Sri > > - Update from Seil > - Update from Anthony > - CPA/DPA sub-functions and roles; Session Re-anchoring; Flow stitching > - Next steps on coming out with consolidated initial docs from WT#4 > > > > From: dmm on behalf of Sri Gundavelli < > sgundave@cisco.com> > Date: Wednesday, June 17, 2015 at 5:05 PM > To: "dmm@ietf.org" > Subject: [DMM] DMM WT#4 - 2 Discussion > > Thanks for all the discussion on the WT#4 call. Attendees: Marco > Liebsch, Danny Moses, Jouni Korhonen, Dapeng Liu, Seil, Vic Liu, Fu Qiao, > Sri .. > > The Poll is now closed for the next call. > > Date: Tuesday, June 23rd at 7AM PDT > WebEx Details below > Agenda: > > 1. Seil Jeon will present his new proposal > 2. Anthony Chen will talk about "Functions of Anchor=E2=80=9D (Tentati= ve) > 3. Follow up discussion on the attribute based node > selection/Deployment models > 4. Follow up discussion on the CP/DP interface in relation to the WT4 > discussions > > > > > > Hi, Sri Gundavelli, You are the host for this WebEx meeting. H= ost > key: 480131 (Use this to reclaim host privileges.) *DMM WT#4 > Discussion* Tuesday, June 23, 2015 7:00 am | Pacific Daylight Time > (San Francisco, GMT-07:00) | 1 hr 30 mins *Join WebEx meeting* > Meeting > number: 209 370 954 Meeting password: DMM *Join by phone* *+1-4= 08-525-6800 > <%2B1-408-525-6800>* Call-in toll number (US/Canada) *+1-866-432-9903 > <%2B1-866-432-9903>* Call-in toll-free number (US/Canada) Access > code: 209 370 954 Global call-in numbers > > | Toll-free calling restrictions > Add this > meeting > > to your calendar. Can't join the meeting? Contact support. > IMPORTANT NOTICE: Please > note that this WebEx service allows audio and other information sent duri= ng > the session to be recorded, which may be discoverable in a legal matter. > You should inform all meeting attendees prior to recording if you intend = to > record the meeting. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > --089e0129464c72d6b2051968bd48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mainly for Anthony,

To support IPv4 for= anchor node which connected to IPv6-only network,=C2=A0
some IPv= 6 transition solutions would be one of the anchor function.

Regar= ds,
--satoru=C2=A0

On Wed, Jun 24, 2015 at 12:37 AM, Sri Gundavelli (sg= undave) <sgundave@cisco.com> wrote:
Thanks for all the discussion today on the WT#4 call. Attendees: Carlo= s Jes=C3=BAs Bernardos,=C2=A0Satoru Matsushima,=C2=A0Seil Jeon, KJ =C2=A0Su= n, Anthony Chen & Sri=C2=A0

- Update from Seil
- Update from Anthony
- CPA/DPA sub-functions and roles; Session Re-anchoring; Flow stitchin= g=C2=A0
- Next steps on coming out with consolidated initial docs from WT#4



From: dmm <dmm-bounces@ietf.org> on behalf= of Sri Gundavelli <sgundave@cisco.com>
Date: Wednesday, June 17, 2015 at 5= :05 PM
To: "dmm@ietf.org" <dmm@ietf.org>
Subject: [DMM] DMM WT#4 - 2 Discuss= ion

Thanks for all the discussion on the WT#4 call. Attendees: Marco Liebs= ch, Danny Moses, Jouni Korhonen, Dapeng Liu, Seil, Vic Liu, Fu Qiao, =C2=A0= Sri ..

The Poll is now closed for the next call.

Date: Tuesday, June 23rd at 7AM PDT
WebEx Details below
Agenda:
  1. Seil Jeon will present his new proposal
  2. Anthony Chen will talk = about "Functions of Anchor=E2=80=9D (Tentative)
  3. Follow up disc= ussion on the attribute based node selection/Deployment models
  4. Foll= ow up discussion on the CP/DP interface in relation to the WT4 discussions<= /li>




Hi, Sri Gundavelli,
You are the host for this WebE= x meeting.
Host key: 480131 (Use this to reclaim host priv= ileges.)
=C2=A0
DMM WT#4 Discussion
Tuesday, June 23, 2015
7:00 am=C2=A0=C2=A0|=C2=A0=C2=A0Pacific Daylight Time (San Francisco, G= MT-07:00)=C2=A0=C2=A0|=C2=A0=C2=A01 hr 30 mins
=C2=A0
Join We= bEx meeting
Meeting number: 209 370 954
Meeting password: DMM
=C2=A0
Join by phone
+1-408-525-6800=C2=A0Call-in toll number (US/Canada)
+1-866-432-9903=C2=A0Call-in toll-free number (US/Canada)
Access code:=C2=A0209 370 954
Global call-in numbers= =C2=A0=C2=A0|=C2=A0=C2=A0Toll-free calling restrictions
=C2=A0
Add this meeting to = your calendar.
=C2=A0
Can't join= the meeting? Contact support.
=C2=A0
IMPORTANT NOTICE: Please note th= at this WebEx service allows audio and other information sent during the se= ssion to be recorded, which may be discoverable in a legal matter. You shou= ld inform all meeting attendees prior to recording if you intend to record the meeting.

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


--089e0129464c72d6b2051968bd48-- From nobody Fri Jun 26 07:51:09 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA7C1B302F for ; Fri, 26 Jun 2015 07:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgDC3vvmdYuN for ; Fri, 26 Jun 2015 07:51:05 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 8F3C81B302E for ; Fri, 26 Jun 2015 07:51:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t5QEp5ir007232; Fri, 26 Jun 2015 07:51:05 -0700 Received: from XCH-BLV-207.nw.nos.boeing.com (xch-blv-207.nw.nos.boeing.com [10.57.37.63]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t5QEp3gq007206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 26 Jun 2015 07:51:03 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.238]) by XCH-BLV-207.nw.nos.boeing.com ([169.254.7.6]) with mapi id 14.03.0235.001; Fri, 26 Jun 2015 07:51:02 -0700 From: "Templin, Fred L" To: Satoru Matsushima , "Sri Gundavelli (sgundave)" Thread-Topic: [DMM] DMM WT#4 - 2 Discussion Thread-Index: AQHQr/ZAKQE69Avfek+IFNyTc8Ak8J2+3ovA Date: Fri, 26 Jun 2015 14:51:01 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E9B0F6@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832E9B0F6XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] DMM WT#4 - 2 Discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 14:51:08 -0000 --_000_2134F8430051B64F815C691A62D9831832E9B0F6XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkp1c3QgdG8gbWVudGlvbiwgQUVSTyBzdXBwb3J0cyBhbnkgY29tYmluYXRpb24gb2Yg SVB2NCBvciBJUHY2IGluIHRoZQ0KYW5jaG9yaW5nIG5ldHdvcmsgdmlhIElQKi1pbi1JUCogdHVu bmVsaW5nLiBUaGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbg0KcHJvdmlkZXMgbW9iaWxlcyB3aXRo IElQdjYgcHJlZml4ZXMgYnV0IHR1bm5lbHMgb3ZlciBhbiBJUHY0IGFjY2Vzcw0KbmV0d29yayBh bmQgbW9iaWxpdHkgYW5jaG9ycy4NCg0KVGhhbmtzIOKAkyBGcmVkDQpmcmVkLmwudGVtcGxpbkBi b2VpbmcuY29tPG1haWx0bzpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPg0KDQoNCkZyb206IGRt bSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2F0b3J1IE1hdHN1 c2hpbWENClNlbnQ6IEZyaWRheSwgSnVuZSAyNiwgMjAxNSAyOjU1IEFNDQpUbzogU3JpIEd1bmRh dmVsbGkgKHNndW5kYXZlKQ0KQ2M6IGRtbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtETU1dIERN TSBXVCM0IC0gMiBEaXNjdXNzaW9uDQoNCk1haW5seSBmb3IgQW50aG9ueSwNCg0KVG8gc3VwcG9y dCBJUHY0IGZvciBhbmNob3Igbm9kZSB3aGljaCBjb25uZWN0ZWQgdG8gSVB2Ni1vbmx5IG5ldHdv cmssDQpzb21lIElQdjYgdHJhbnNpdGlvbiBzb2x1dGlvbnMgd291bGQgYmUgb25lIG9mIHRoZSBh bmNob3IgZnVuY3Rpb24uDQpQbGVhc2UgdGFrZSBhIGxvb2sgYXQgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWF0c3VzaGltYS1zdGF0ZWxlc3MtdXBsYW5lLXZlcGMtMDQjc2VjdGlv bi0zLjUNCg0KUmVnYXJkcywNCi0tc2F0b3J1DQoNCk9uIFdlZCwgSnVuIDI0LCAyMDE1IGF0IDEy OjM3IEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIDxzZ3VuZGF2ZUBjaXNjby5jb208bWFp bHRvOnNndW5kYXZlQGNpc2NvLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciBhbGwgdGhlIGRpc2N1 c3Npb24gdG9kYXkgb24gdGhlIFdUIzQgY2FsbC4gQXR0ZW5kZWVzOiBDYXJsb3MgSmVzw7pzIEJl cm5hcmRvcywgU2F0b3J1IE1hdHN1c2hpbWEsIFNlaWwgSmVvbiwgS0ogIFN1biwgQW50aG9ueSBD aGVuICYgU3JpDQoNCi0gVXBkYXRlIGZyb20gU2VpbA0KLSBVcGRhdGUgZnJvbSBBbnRob255DQot IENQQS9EUEEgc3ViLWZ1bmN0aW9ucyBhbmQgcm9sZXM7IFNlc3Npb24gUmUtYW5jaG9yaW5nOyBG bG93IHN0aXRjaGluZw0KLSBOZXh0IHN0ZXBzIG9uIGNvbWluZyBvdXQgd2l0aCBjb25zb2xpZGF0 ZWQgaW5pdGlhbCBkb2NzIGZyb20gV1QjNA0KDQoNCg0KRnJvbTogZG1tIDxkbW0tYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3JpIEd1 bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4N CkRhdGU6IFdlZG5lc2RheSwgSnVuZSAxNywgMjAxNSBhdCA1OjA1IFBNDQpUbzogImRtbUBpZXRm Lm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiIgPGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYu b3JnPj4NClN1YmplY3Q6IFtETU1dIERNTSBXVCM0IC0gMiBEaXNjdXNzaW9uDQoNClRoYW5rcyBm b3IgYWxsIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBXVCM0IGNhbGwuIEF0dGVuZGVlczogTWFyY28g TGllYnNjaCwgRGFubnkgTW9zZXMsIEpvdW5pIEtvcmhvbmVuLCBEYXBlbmcgTGl1LCBTZWlsLCBW aWMgTGl1LCBGdSBRaWFvLCAgU3JpIC4uDQoNClRoZSBQb2xsIGlzIG5vdyBjbG9zZWQgZm9yIHRo ZSBuZXh0IGNhbGwuDQoNCkRhdGU6IFR1ZXNkYXksIEp1bmUgMjNyZCBhdCA3QU0gUERUDQpXZWJF eCBEZXRhaWxzIGJlbG93DQpBZ2VuZGE6DQoNCiAgMS4gIFNlaWwgSmVvbiB3aWxsIHByZXNlbnQg aGlzIG5ldyBwcm9wb3NhbA0KICAyLiAgQW50aG9ueSBDaGVuIHdpbGwgdGFsayBhYm91dCAiRnVu Y3Rpb25zIG9mIEFuY2hvcuKAnSAoVGVudGF0aXZlKQ0KICAzLiAgRm9sbG93IHVwIGRpc2N1c3Np b24gb24gdGhlIGF0dHJpYnV0ZSBiYXNlZCBub2RlIHNlbGVjdGlvbi9EZXBsb3ltZW50IG1vZGVs cw0KICA0LiAgRm9sbG93IHVwIGRpc2N1c3Npb24gb24gdGhlIENQL0RQIGludGVyZmFjZSBpbiBy ZWxhdGlvbiB0byB0aGUgV1Q0IGRpc2N1c3Npb25zDQoNCg0KDQoNCkhpLCBTcmkgR3VuZGF2ZWxs aSwNCg0KWW91IGFyZSB0aGUgaG9zdCBmb3IgdGhpcyBXZWJFeCBtZWV0aW5nLg0KDQoNCkhvc3Qg a2V5OiA0ODAxMzEgKFVzZSB0aGlzIHRvIHJlY2xhaW0gaG9zdCBwcml2aWxlZ2VzLikNCg0KDQoN Cg0KDQpETU0gV1QjNCBEaXNjdXNzaW9uDQoNClR1ZXNkYXksIEp1bmUgMjMsIDIwMTUNCg0KNzow MCBhbSAgfCAgUGFjaWZpYyBEYXlsaWdodCBUaW1lIChTYW4gRnJhbmNpc2NvLCBHTVQtMDc6MDAp ICB8ICAxIGhyIDMwIG1pbnMNCg0KDQoNCg0KDQpKb2luIFdlYkV4IG1lZXRpbmc8aHR0cHM6Ly9j aXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9NVElEPW1hNmQ3ZTVjMWY5N2U0ZDg3NDdm OGJhZGY3YWI0YzQ2ZT4NCg0KDQpNZWV0aW5nIG51bWJlcjoNCg0KMjA5IDM3MCA5NTQNCg0KTWVl dGluZyBwYXNzd29yZDoNCg0KRE1NDQoNCg0KDQoNCg0KSm9pbiBieSBwaG9uZQ0KDQorMS00MDgt NTI1LTY4MDA8dGVsOiUyQjEtNDA4LTUyNS02ODAwPiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9D YW5hZGEpDQoNCisxLTg2Ni00MzItOTkwMzx0ZWw6JTJCMS04NjYtNDMyLTk5MDM+IENhbGwtaW4g dG9sbC1mcmVlIG51bWJlciAoVVMvQ2FuYWRhKQ0KDQpBY2Nlc3MgY29kZTogMjA5IDM3MCA5NTQN Cg0KR2xvYmFsIGNhbGwtaW4gbnVtYmVyczxodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3Nh bGVzL2dsb2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9TUMmRUQ9MzE2OTMyMjA3JnRvbGxGcmVl PTE+ICB8ICBUb2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8aHR0cDovL3d3dy53ZWJleC5j b20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGY+DQoNCg0KDQoNCg0KQWRkIHRoaXMgbWVl dGluZzxodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bTMzZGQ5 NDc0NjNhNTVmZWZmYWU0YjQwZjVkZmU5YjE2PiB0byB5b3VyIGNhbGVuZGFyLg0KDQoNCg0KDQoN CkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydC48aHR0cHM6Ly9jaXNjby53 ZWJleC5jb20vY2lzY29zYWxlcy9tYz4NCg0KDQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBh bGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8gcmVjb3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8g cmVjb3JkIHRoZSBtZWV0aW5nLg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0 bzpkbW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rt bQ0KDQo= --_000_2134F8430051B64F815C691A62D9831832E9B0F6XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE5Mjk4NDU0Mjc7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi02MTU3MzMxNTQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkp1c3QgdG8gbWVudGlvbiwg QUVSTyBzdXBwb3J0cyBhbnkgY29tYmluYXRpb24gb2YgSVB2NCBvciBJUHY2IGluIHRoZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5hbmNob3JpbmcgbmV0d29yayB2aWEgSVAqLWluLUlQKiB0dW5uZWxpbmcu IFRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnByb3ZpZGVzIG1v YmlsZXMgd2l0aCBJUHY2IHByZWZpeGVzIGJ1dCB0dW5uZWxzIG92ZXIgYW4gSVB2NCBhY2Nlc3M8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+bmV0d29yayBhbmQgbW9iaWxpdHkgYW5jaG9ycy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyDigJMgRnJlZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48YSBocmVmPSJtYWlsdG86ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbSI+ZnJl ZC5sLnRlbXBsaW5AYm9laW5nLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlNhdG9ydSBNYXRzdXNoaW1hPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVuZSAyNiwg MjAxNSAyOjU1IEFNPGJyPg0KPGI+VG86PC9iPiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpPGJy Pg0KPGI+Q2M6PC9iPiBkbW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtETU1d IERNTSBXVCM0IC0gMiBEaXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haW5seSBmb3IgQW50aG9ueSw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHN1cHBvcnQgSVB2NCBmb3IgYW5jaG9y IG5vZGUgd2hpY2ggY29ubmVjdGVkIHRvIElQdjYtb25seSBuZXR3b3JrLCZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c29tZSBJUHY2IHRy YW5zaXRpb24gc29sdXRpb25zIHdvdWxkIGJlIG9uZSBvZiB0aGUgYW5jaG9yIGZ1bmN0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNl IHRha2UgYSBsb29rIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LW1hdHN1c2hpbWEtc3RhdGVsZXNzLXVwbGFuZS12ZXBjLTA0I3NlY3Rpb24tMy41Ij4NCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHN1c2hpbWEtc3RhdGVsZXNzLXVwbGFuZS12 ZXBjLTA0I3NlY3Rpb24tMy41PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1zYXRvcnUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdW4gMjQsIDIwMTUg YXQgMTI6MzcgQU0sIFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgJmx0OzxhIGhyZWY9Im1haWx0 bzpzZ3VuZGF2ZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5zZ3VuZGF2ZUBjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhhbmtz IGZvciBhbGwgdGhlIGRpc2N1c3Npb24gdG9kYXkgb24gdGhlIFdUIzQgY2FsbC4gQXR0ZW5kZWVz OiBDYXJsb3MgSmVzw7pzIEJlcm5hcmRvcywmbmJzcDtTYXRvcnUgTWF0c3VzaGltYSwmbmJzcDtT ZWlsIEplb24sIEtKICZuYnNwO1N1biwgQW50aG9ueSBDaGVuICZhbXA7IFNyaSZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4tIFVwZGF0ZSBmcm9tIFNlaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pi0gVXBkYXRlIGZyb20gQW50aG9ueTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LSBD UEEvRFBBIHN1Yi1mdW5jdGlvbnMgYW5kIHJvbGVzOyBTZXNzaW9uIFJlLWFuY2hvcmluZzsgRmxv dyBzdGl0Y2hpbmcmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi0gTmV4dCBz dGVwcyBvbiBjb21pbmcgb3V0IHdpdGggY29uc29saWRhdGVkIGluaXRpYWwgZG9jcyBmcm9tIFdU IzQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5kbW0gJmx0Ozxh IGhyZWY9Im1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbS1i b3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFNyaSBHdW5kYXZlbGxpICZsdDs8 YSBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c2d1bmRh dmVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdW5lIDE3 LCAyMDE1IGF0IDU6MDUgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpk bW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0RNTV0gRE1NIFdUIzQgLSAyIERpc2N1c3Np b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFua3Mg Zm9yIGFsbCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgV1QjNCBjYWxsLiBBdHRlbmRlZXM6IE1hcmNv IExpZWJzY2gsIERhbm55IE1vc2VzLCBKb3VuaSBLb3Job25lbiwgRGFwZW5nIExpdSwgU2VpbCwg VmljIExpdSwgRnUgUWlhbywgJm5ic3A7U3JpIC4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBQb2xsIGlzIG5v dyBjbG9zZWQgZm9yIHRoZSBuZXh0IGNhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkRhdGU6IFR1ZXNkYXksIEp1 bmUgMjNyZCBhdCA3QU0gUERUPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5XZWJFeCBE ZXRhaWxzIGJlbG93PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5BZ2VuZGE6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlNlaWwgSmVvbiB3aWxsIHByZXNlbnQgaGlzIG5ldyBwcm9wb3NhbDxv OnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpi bGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFudGhvbnkgQ2hlbiB3 aWxsIHRhbGsgYWJvdXQgJnF1b3Q7RnVuY3Rpb25zIG9mIEFuY2hvcuKAnSAoVGVudGF0aXZlKTxv OnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpi bGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZvbGxvdyB1cCBkaXNj dXNzaW9uIG9uIHRoZSBhdHRyaWJ1dGUgYmFzZWQgbm9kZSBzZWxlY3Rpb24vRGVwbG95bWVudCBt b2RlbHM8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gb2xsb3cg dXAgZGlzY3Vzc2lvbiBvbiB0aGUgQ1AvRFAgaW50ZXJmYWNlIGluIHJlbGF0aW9uIHRvIHRoZSBX VDQgZGlzY3Vzc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBh ZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+ DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6My43NXB0IDBpbiAwaW4gMGluIj4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IGFsaWduPSJsZWZ0IiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQ7bWFyZ2luLWxl ZnQ6My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJs ZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM0RDRENEQiPkhpLCBTcmkgR3VuZGF2ZWxs aSwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6Ny41cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM0RDRENEQiPllvdSBhcmUgdGhlIGhvc3Qg Zm9yIHRoaXMgV2ViRXggbWVldGluZy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi Pg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJjb2xv cjojNEQ0RDREIj5Ib3N0IGtleTogNDgwMTMxIChVc2UgdGhpcyB0byByZWNsYWltIGhvc3QgcHJp dmlsZWdlcy4pDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8 dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6IzRENEQ0RCI+RE1NIFdUIzQg RGlzY3Vzc2lvbjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RDRENEQiPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6 Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KVHVlc2RheSwgSnVuZSAyMywgMjAxNSA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFt ZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hv ci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1u O21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjc6MDAgYW0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5i c3A7UGFjaWZpYyBEYXlsaWdodCBUaW1lIChTYW4gRnJhbmNpc2NvLCBHTVQtMDc6MDApJm5ic3A7 Jm5ic3A7fCZuYnNwOyZuYnNwOzEgaHIgMzAgbWlucyA8bzpwPg0KPC9vOnA+PC9wPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9 IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFk ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBpbjt3aWR0aDphdXRvIWlt cG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQg Ljc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZy YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMwMEFGRjkiPjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nv c2FsZXMvai5waHA/TVRJRD1tYTZkN2U1YzFmOTdlNGQ4NzQ3ZjhiYWRmN2FiNGM0NmUiIHRhcmdl dD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246 bm9uZSI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9zcGFuPjwvYj48L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGluO3dpZHRoOmF1dG8haW1w b3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAzLjc1cHQg Ljc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZy YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KTWVldGluZyBu dW1iZXI6IDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAu NzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQoyMDkg MzcwIDk1NCA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOi43NXB0IDMuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQpNZWV0aW5nIHBhc3N3b3JkOjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQpETU08bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4N Cjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L3RkPg0K PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQg Ljc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+Sm9pbiBieSBwaG9u ZTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRk aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1l bGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7 bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFj dGx5Ij4NCjxiPjxhIGhyZWY9InRlbDolMkIxLTQwOC01MjUtNjgwMCIgdGFyZ2V0PSJfYmxhbmsi PiYjNDM7MS00MDgtNTI1LTY4MDA8L2E+PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVT L0NhbmFkYSk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxiPjxhIGhyZWY9InRlbDolMkIxLTg2Ni00MzItOTkwMyIgdGFyZ2V0PSJfYmxh bmsiPiYjNDM7MS04NjYtNDMyLTk5MDM8L2E+PC9iPiZuYnNwO0NhbGwtaW4gdG9sbC1mcmVlIG51 bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQg c3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KQWNjZXNzIGNvZGU6Jm5ic3A7MjA5IDM3MCA5NTQ8bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxhIGhyZWY9 Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvZ2xvYmFsY2FsbGluLnBocD9zZXJ2 aWNlVHlwZT1NQyZhbXA7RUQ9MzE2OTMyMjA3JmFtcDt0b2xsRnJlZT0xIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzAwQUZGOTt0ZXh0LWRlY29y YXRpb246bm9uZSI+R2xvYmFsIGNhbGwtaW4gbnVtYmVyczwvc3Bhbj48L2E+Jm5ic3A7Jm5ic3A7 fCZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9y ZXN0cmljdGlvbnMucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+VG9sbC1mcmVlDQogY2Fs bGluZyByZXN0cmljdGlvbnM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxz cGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0K PHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzou NzVwdCAuNzVwdCAuNzVwdCAuNzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVw dCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20v Y2lzY29zYWxlcy9qLnBocD9NVElEPW0zM2RkOTQ3NDYzYTU1ZmVmZmFlNGI0MGY1ZGZlOWIxNiIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlv bjpub25lIj5BZGQgdGhpcyBtZWV0aW5nPC9zcGFuPjwvYT4gdG8geW91ciBjYWxlbmRhci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJs ZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdo dDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2hl aWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1 LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJk aXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0i TXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRy Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Q2Fu J3Qgam9pbiB0aGUgbWVldGluZz8NCjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Np c2Nvc2FsZXMvbWMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0 ZXh0LWRlY29yYXRpb246bm9uZSI+Q29udGFjdCBzdXBwb3J0Ljwvc3Bhbj48L2E+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo3 LjVwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0 OjcuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0 OjcuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtj b2xvcjojQTBBMEEwIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2Vi RXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5n IHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGlu IGEgbGVnYWwgbWF0dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMN CiBwcmlvciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byByZWNvcmQgdGhlIG1lZXRpbmcu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KZG1tIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmci PmRtbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG1tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2134F8430051B64F815C691A62D9831832E9B0F6XCHBLV504nwnosb_-- From nobody Mon Jun 29 08:36:22 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460B91ACDEF for ; Mon, 29 Jun 2015 08:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGOP445egQsd for ; Mon, 29 Jun 2015 08:36:17 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EADC1ACD3B for ; Mon, 29 Jun 2015 08:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 129F610A183 for ; Mon, 29 Jun 2015 17:36:16 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCJfCPgDo-LZ for ; Mon, 29 Jun 2015 17:36:15 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id D9DB510A182 for ; Mon, 29 Jun 2015 17:36:13 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.4]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Mon, 29 Jun 2015 17:36:14 +0200 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fpc-cpdp-00 - update plans Thread-Index: AQHQr+zbQ6UfT0L6Qk+qpud16x64rZ3DoH2Q Date: Mon, 29 Jun 2015 15:36:13 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D99B18E8C@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D99B1357A@PALLENE.office.hd> <69756203DDDDE64E987BC4F70B71A26D99B15229@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D99B15229@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D99B18E8CPALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fpc-cpdp-00 - update plans X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 15:36:21 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D99B18E8CPALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find the WebEx information for the call on Wednesday below. This is on the agenda so far: ( ) Brief summary and confirmation of open items ( ) Missing attributes and format ( ) Revision of existing attributes ( ) Modelling vs. concrete protocol design Please let me know about further items you'd like to address. Best regards, Marco DMM - CP/DP Draft discussion Wednesday, July 1, 2015 7:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 1 hr 30 mi= ns Join WebEx meeting Meeting number: 201 675 355 Meeting password: dmm Join by phone +1-408-525-6800 Call-in toll number (US/Canada) +1-866-432-9903 Call-in toll-free number (US/Canada) Access code: 201 675 355 Global call-in numbers | Toll-free calling restric= tions Add this meeting to your calendar. Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. You should inform all meeting attendees prior to re= cording if you intend to record the meeting. From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Freitag, 26. Juni 2015 10:48 To: dmm@ietf.org Subject: Re: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dm= m-fpc-cpdp-00 - update plans Folks, the WebEx about progressing the FPC draft will be on Wednesday, 1st July 2015, Time: 16:00 CEST, Duration: 90 min. I'll send WebEx details and an agenda around in a separate eMail. marco From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Montag, 22. Juni 2015 22:04 To: dmm@ietf.org Subject: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fp= c-cpdp-00 - update plans Please find a link to a doodle below to find a suitable date for a WebEx wh= ere we can discuss and agree on the FPC draft update. Please also think about the open items I addressed in my previous eMails or= any additional item you have in mind and which we need to consider for a draft update. Ple= ase use the mailing list or the issue tracker to address these items for discussion. http://doodle.com/5s9dhzcy6w8ds6ae Thanks, Marco From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Freitag, 19. Juni 2015 15:36 To: dmm@ietf.org Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans Folks, draft-ietf-dmm-fpc-cpdp-00 is out since May. So far we did not receive any= serious issue to address, which is good. Driving the draft towards a more mature state, I see the following main ite= ms to address: (1) Completion of properties and attributes (2) Adoption of a standard conform modelling In terms of (1), the importance to include QoS attributes has been raised f= rom different sides. I'll make a proposal how to cover this in an update on the DMM ML using a s= eparate eMail. Other attributes we may need to cover are about monitoring/reporting. In terms of (2) we heard different opinions about keeping this document at = the level of information models or be more specific by adopting data modeling. So far the document is prett= y hybrid ;-), core part is more about clear definition and description of messages and information to apply betwe= en Client and Agent. In the appendix the draft includes a (so far experimental) YANG model. Please state your opinion here to see what the WG expects from the document= . If we adopt information modeling, this seems straightforward from a version which is complete in terms of mes= sages/attributes. If we adopt data modeling, we may need to spend more cycles in agreeing for= mats, alignment, etc. Hope we can discuss on the ML. I'd also like to schedule a WebExt before th= e draft deadline. Will send a doodle around for that. marco --_000_69756203DDDDE64E987BC4F70B71A26D99B18E8CPALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find the WebEx = information for the call on Wednesday below.

 

This is on the agenda = so far:

 

( ) Brief summary and = confirmation of open items

( ) Missing attributes= and format

( ) Revision of existi= ng attributes

( ) Modelling vs. conc= rete protocol design

 

Please let me know abo= ut further items you’d like to address.

 

Best regards,

Marco

 

 

 

 

 

 

DMM - CP/DP Draft discussion

Wednesday, July 1, 2015

7:00 am  |  Pacific Daylight T= ime (San Francisco, GMT-07:00)  |  1 hr 30 mins

 

 

 

Join WebEx meeting

 

Meeting number:

201 675 355

Meeting password:

dmm

 

 

 

Join by phone

+1-408-525-6800 Call-in toll number (US/Canada)

+1-866-432-9903 Call-in toll-free number (US/Canada)

Access code: 201 675 355

Global call-in numbers  |  Toll-free calling restrictions

 

 

 

= Add this meeting to your calendar.

 

 

 

Can't join the meeting? Contact support.

 

 

 

IMPORTANT NOTICE: Please note that this WebEx servi= ce allows audio and other information sent during the session to be recorde= d, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record th= e meeting.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 26. Juni 2015 10:48
To: dmm@ietf.org
Subject: Re: [DMM] Planning WebEx about FPC draft update /RE: draft-= ietf-dmm-fpc-cpdp-00 - update plans

 

Folks, the WebEx about= progressing the FPC draft will be on

 

Wednesday, 1st July 2015,

Time: 16:00 CEST,=

Duration: 90 min.=

 

I’ll send WebEx = details and an agenda around in a separate eMail.

 

marco

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Montag, 22. Juni 2015 22:04
To: dmm@ietf.org
Subject: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf= -dmm-fpc-cpdp-00 - update plans

 

Please find a link to = a doodle below to find a suitable date for a WebEx where we
can discuss and agree on the FPC draft update.

 

Please also think abou= t the open items I addressed in my previous eMails or any additional
item you have in mind and which we need to consider for a draft update. Ple= ase use the mailing
list or the issue tracker to address these items for discussion.=

 

ht= tp://doodle.com/5s9dhzcy6w8ds6ae

 

Thanks,

Marco

 

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 19. Juni 2015 15:36
To: dmm@ietf.org
Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans<= /span>

 

Folks,

draft-ietf-dmm-fpc-cpdp-00  is out since May. So far we did not receiv= e any serious issue to address, which is good.

Driving the draft towards a more mature state, I see= the following main items to address:

 

(1)    Completion of properties and attributes<= /p>

(2)    Adoption of a standard conform modelling=

 

In terms of (1), the importance to include QoS attri= butes has been raised from different sides.

I’ll make a proposal how to cover this in an u= pdate on the DMM ML using a separate eMail.

Other attributes we may need to cover are about moni= toring/reporting.

 

In terms of (2) we heard different opinions about ke= eping this document at the level of information models
or be more specific by adopting data modeling. So far the document is prett= y hybrid ;-), core part is more about
clear definition and description of messages and information to apply betwe= en Client and Agent. In the appendix
the draft includes a (so far experimental) YANG model.

 

Please state your opinion here to see what the WG ex= pects from the document. If we adopt information modeling,
this seems straightforward from a version which is complete in terms of mes= sages/attributes.
If we adopt data modeling, we may need to spend more cycles in agreeing for= mats, alignment, etc.

 

Hope we can discuss on the ML. I’d also like t= o schedule a WebExt before the draft deadline. Will send a
doodle around for that.

 

marco

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D99B18E8CPALLENEofficehd_-- From nobody Mon Jun 29 09:24:14 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0E51AD0EA for ; Mon, 29 Jun 2015 09:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWozF19HuNS9 for ; Mon, 29 Jun 2015 09:24:11 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::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 BAF851AD0CD for ; Mon, 29 Jun 2015 09:24:10 -0700 (PDT) Received: by lagx9 with SMTP id x9so132055591lag.1 for ; Mon, 29 Jun 2015 09:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wGnYokSm9JGzlR4rktM6DZ0EDrdE7GzG32JkNbWIW4c=; b=rrEp3aANbRFYZVkRvXKaSVbFG7M1yflRPy0bjd9ZCx9jkMefY0HRH71Lf2qL6HdIQC QnfR1k/dFxCh+VtkN1bQsXlQN9tai/7PFkec0nsj5cdpBxENdFBscp243pW+Yk+xhJ3j gw9g0R835p/35Dv99PBJpeeL1ToK+/WWrUuQMqoLC/v/VU+KMZJLCd1vL7RZMVMAxhrP us2H9pJHulZz+O/z9CUQZTtr/cDdOObCrmM6nrfUVI01ZMU1h5NmLtSLizu1ZA6CeaMb iuKM/GM/y4SVNrXs+rJQRsjzO3K69x9kBKodUfZiieoLjbCzx/YRBBCLFW/XTT/O3U38 ywSA== MIME-Version: 1.0 X-Received: by 10.152.20.138 with SMTP id n10mr14870874lae.115.1435595049187; Mon, 29 Jun 2015 09:24:09 -0700 (PDT) Received: by 10.114.12.68 with HTTP; Mon, 29 Jun 2015 09:24:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jun 2015 11:24:09 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] vepc draft Rev. 04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 16:24:12 -0000 Hi Satoru, Thank you for your comments. My replies inline. Regards, Behcet On Thu, Jun 25, 2015 at 5:22 AM, Satoru Matsushima wrote: > Hi Behcet, > > Sorry for my late response. > > As I looked over your dmm-for-wifi draft, I found two protocols to be used > to separate > control and data plane such as XMPP and OpenFlow. > > It seems like you want to work on that protocols to be implemented in data > plane nodes. > OpenFlow is another forum controlled protocol so I don't touch it in the > IETF. > XMPP sounds nice. If you adopt XMPP with same model of > draft-ietf-l3vpn-end-system, > it almost same with using BGP like the vEPC draft. > Wait a minute, there is more. It seems like you have not read Sections 4.2 and 4.3. Yes, XMPP and OpenFlow are for Section 4.1 for switch control on mobile backhaul. This is related to a university project we were involved which used public domain OpenFlow tools like OpenDayLight. In route establishment, I am using Netconf or RPC protocol which you missed big and that was one of the main additions in Rev. 02. Please check it again. > But what I mentioned FPCP in vEPC is as a way to export mobility info to BGP > speaker > from control-plane nodes of mobility management. > > And more, many parameters should be aligned for these nodes to utilizing > data-plane > network so that the config data model should also be defined in FPCP. I > think that's not > part of signaling protocol roles. > As I said in my mail before, I wonder why we need all those things? Why do we need another client/server system maybe other than what i2rs is defining? I think this is a big question FPCP lovers should answer? My point is that at least you should not need it in vEPC, I am saying that as someone who supports vEPC :-) > Thought? Another main addition is Rev. 02 was Section 5 on multicast support which you missed or not commented? > > Regards, > --satoru > > > > > On Wed, Jun 3, 2015 at 4:25 AM, Behcet Sarikaya > wrote: >> >> Hi Matsushima-san, >> >> On Fri, May 29, 2015 at 8:24 AM, Satoru Matsushima >> wrote: >> > Hi Behcet-san, >> > >> > On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya >> > >> > wrote: >> >> >> >> Hi Satoru, >> >> >> >> Thanks for your reply. >> >> >> >> Let me continue the discussion with your text in Section 3.2 where you >> >> mention >> >> vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) >> >> that defines FPCP Agent function and Client function. >> >> >> >> I don't understand how you could justify defining a new forwarding >> >> policy configuration protocol to do this Agent/Client functionality? >> >> Why not use similar Agent/Client models that are being defined rather >> >> than defining a new protocol? >> >> I think this point requires much stronger justification which I could >> >> not see in Section 3.2. >> >> >> > >> > The text just describes about a part of where FPCP may be applicable in >> > vEPC. >> > >> > >> > >> >> >> >> Are you that we have to to reinvent the wheel, rather than reusing >> >> something that is already available? How are we going to reinvent that >> >> wheel also remains to be seen, I think. >> >> >> > >> > Point taken. Which kind of wheel do you have in mind? >> >> Please check this draft: >> https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-02 >> >> Regards, >> >> Behcet >> > >> > cheers, >> > --satoru >> > > > From nobody Tue Jun 30 01:21:36 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1291A1AC1 for ; Tue, 30 Jun 2015 01:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPF_-zgoxDgp for ; Tue, 30 Jun 2015 01:21:29 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::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 317C01A1AFF for ; Tue, 30 Jun 2015 01:21:29 -0700 (PDT) Received: by iecvh10 with SMTP id vh10so7207532iec.3 for ; Tue, 30 Jun 2015 01:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f4V9zty9No61RBMx37mANOPwwPsyIELFpQRnXNd+44o=; b=N88Z0KZwH+byMoj/6qFa0UvQjAiqU8vLCI8WWj8eGCYtR8Yg6CE6tmVZa8Lygp0Kfc +isJTFwPwtSB2ybf6sL5l0QW2S1Werjtbj+LEPuJt+Kw42uczOBsICXJL6yaRPnZJeZd nzjMNJAdn1Mp2/i5nSia1qjK2lGD4M6hr/Bf++ibro19GmUfGARiS1dQpMiuoYhqXS3c 8SAtFAJ0Lv0Z7pCbhYQmkr2sX6THuQrVR6D1NQGFpD6JQ22vBQR9Yj7k1znybp1huQda VSURggkFLjVeEWoHEU21h0EpoBJS1q4lSb2hDf331euUlKyD3IkkB1QCIW1J6JT2N5Ow gLfg== MIME-Version: 1.0 X-Received: by 10.42.131.202 with SMTP id a10mr24898262ict.49.1435652488668; Tue, 30 Jun 2015 01:21:28 -0700 (PDT) Received: by 10.36.155.139 with HTTP; Tue, 30 Jun 2015 01:21:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jun 2015 17:21:28 +0900 Message-ID: From: Satoru Matsushima To: "sarikaya@ieee.org" Content-Type: multipart/alternative; boundary=bcaec55237809babfe0519b7e472 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] vepc draft Rev. 04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 08:21:35 -0000 --bcaec55237809babfe0519b7e472 Content-Type: text/plain; charset=UTF-8 Behcet, On Tue, Jun 30, 2015 at 1:24 AM, Behcet Sarikaya wrote: -- snip -- > Wait a minute, there is more. > It seems like you have not read Sections 4.2 and 4.3. > Yes, XMPP and OpenFlow are for Section 4.1 for switch control on > mobile backhaul. > This is related to a university project we were involved which used > public domain OpenFlow tools like OpenDayLight. > > In route establishment, I am using Netconf or RPC protocol which you > missed big and that was one of the main additions in Rev. 02. > Please check it again. > Wow, thanks. I had overlooked it. I had jumped to conclusions when I read section 4.1 that cover not only L2 but also L3 hand-over. I couldn't imagine that each layer has different technique for hand-over. Why is that? I want to clarify one thing on your drat. Sec 4.3 in the draft mentions that i2rs agent as netconf client but it is opposite as far as I know. Am I wrong? > > > But what I mentioned FPCP in vEPC is as a way to export mobility info to > BGP > > speaker > > from control-plane nodes of mobility management. > > > > And more, many parameters should be aligned for these nodes to utilizing > > data-plane > > network so that the config data model should also be defined in FPCP. I > > think that's not > > part of signaling protocol roles. > > > > As I said in my mail before, I wonder why we need all those things? > Why do we need another client/server system maybe other than what i2rs > is defining? > I think this is a big question FPCP lovers should answer? My point is > that at least you should not need it in vEPC, I am saying that as > someone who supports vEPC :-) > AFAIK, FPCP design is alined with i2rs architecture so that it has the data-model with yang schema based on its information model of data-plane node abstraction (Marco's idea) but currently it's an appendix. The information model would make clear what are the mobility specific things that might augment i2rs model. If nothing, there's no need to define it, yes. As a co-author of FPCP, you are welcome to review the parameters which FPCP defined whether each of those are really needed or not. > > > Thought? > > Another main addition is Rev. 02 was Section 5 on multicast support > which you missed or not commented? > Cool. Does mobile node really need multicast? Is there any document that justify for that? cheers, --satoru --bcaec55237809babfe0519b7e472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Behcet,

On Tue, Jun 30, 2015 at 1:24 AM= , Behcet Sarikaya <sarikaya2012@gmail.com> wrote:

-- snip --
=C2=A0
Wait a minute, there is more.
It seems like you have not read Sections 4.2 and 4.3.
Yes, XMPP and OpenFlow are for Section 4.1 for switch control on
mobile backhaul.
This is related to a university project we were involved which used
public domain OpenFlow tools like OpenDayLight.

In route establishment, I am using Netconf or RPC protocol which you
missed big and that was one of the main additions in Rev. 02.
Please check it again.

Wow, thanks. I h= ad overlooked it.
I had jumped to conclusions when I read section= 4.1 that cover not only L2 but also L3 hand-over.
I couldn't= imagine that each layer has different technique for hand-over. Why is that= ?

I want to clarify one thing on your drat. Sec 4.= 3 in the draft mentions that i2rs agent as netconf client but it is opposit= e
as far as I know. Am I wrong?

=C2=A0

> But what I mentioned FPCP in vEPC is as a way to export mobility info = to BGP
> speaker
> from control-plane nodes of mobility management.
>
> And more, many parameters should be aligned for these nodes to utilizi= ng
> data-plane
> network so that the config data model should also be defined in FPCP. = I
> think that's not
> part of signaling protocol roles.
>

As I said in my mail before, I wonder why we need all those things?<= br> Why do we need another client/server system maybe other than what i2rs
is defining?
I think this is a big question FPCP lovers should answer? My point is
that at least you should not need it in vEPC, I am saying that as
someone who supports vEPC :-)

AFAIK, FP= CP design is alined with i2rs architecture so that it has the data-model wi= th yang schema based on its information model of data-plane node abstractio= n (Marco's idea) but currently it's an appendix. The information mo= del would make clear what are the mobility specific things that might augme= nt i2rs model. If nothing, there's no need to define it, yes. As a co-a= uthor of FPCP, you are welcome to review the parameters which FPCP defined = whether each of those are really needed or not.
=C2=A0

> Thought?

Another main addition is Rev. 02 was Section 5 on multicast support
which you missed or not commented?

Cool= .
Does mobile node really need multicast? Is there any document t= hat justify for that?

cheers,
--satoru
--bcaec55237809babfe0519b7e472--